Hannes Tschofenig <hannes.tschofe...@arm.com> wrote:
mcr> 2) A long thread at LAMPS two years suggests that the term
mcr> "Intermediate CA" applies only to cross-certification authoritiy
mcr> bridges, and the term "Subordinate CA" should be used. That this
mcr> is consistent with history going back to RFC4949.
hannes> [hannes] We can note in the terminology section that the terms
hannes> "Intermediate CA" and "Subordinate CA" are used interchangeably
hannes> in this document because with regards to this document the
hannes> distinction is not relevant.
My view is that we have confused people by using them interchangeably, and we
should stop doing that. Why not just use subordinate CA then?
The relevance has to do with how path validation is managed.
mcr> Given that such an involved discussion is not in scope for this
mcr> document, it might be better just to refer to the ADD WG without
mcr> mentioning specific solutions. I am, in general, not convinced
mcr> that encrypted SNI serves any purpose for most IoT devices.
hannes> [hannes] Major IoT service providers have cared about hiding
hannes> client identity information by utilizing session resumption in
hannes> TLS 1.2 to accomplish what is now available in TLS 1.3 with
hannes> earlier encryption of handshake messages. While I personally
hannes> haven't heard anyone asking for SNI encryption yet, I expect the
hannes> same companies who cared about hiding the client identifiers to
hannes> also take a look at the SNI encryption. While there are pros and
hannes> cons of using these mechanisms, I am only suggesting to reference
hannes> ongoing IETF work. Companies then need to decide whether a
hannes> specific solution matches their requirements.
Yes, what I'm saying is that just reference it.
Trying to say much more about ongoing work is a recipe for getting something
wrong and having to revise the document late in the process.
mcr> 4) section 15 There is much discussion about what goes into the
mcr> certificates. I didn't really understand why that is in this
mcr> document. Validation of server certificates is well covered in
mcr> RFC6125, I think.
hannes> [hannes] In my experience, validation of server certificates has
hannes> been a source of confusion in IoT and RFC 6125 does not talk
hannes> about the use of IoT protocols like CoAP and MQTT. I have seen
hannes> various companies and organizations creating their own profiles
hannes> of RFC 6125 in the past, which has resulted in the text of this
hannes> section.
Okay, so either we have to do much more, or we have to do much less here.
mcr> As the (industrial) IoT market embraces IDevID certificates,
mcr> there is some concern that different markets will put different
mcr> requirements on IDevID contents. So far it does not appear that
mcr> anyone has created a situation where a single (fat) IDevID
mcr> certificate couldn't be used in a variety of market verticals,
mcr> the concern remains.
mcr> It was my intention to introduce a document about this issue. I
mcr> think that it's something that only the IETF can do. Perhaps
mcr> that would fit into this UTA document, or perhaps parts of this
mcr> section 15 goes into another document.
hannes> [hannes] This section was difficult to write because - there are
hannes> lots of different IoT verticals, - companies often do not want to
hannes> share information about what they do in their deployments, and -
hannes> there are many different identifier formats.
hannes> It would, of course, be worthwhile to ask around again to see
hannes> what current deployments are using. I could check the public
hannes> documentation of major IoT service providers to get this process
hannes> started.
Thomas suggested that this was welcome in this document.
I will attempt to write some text to go here.
The TL;DR summary is: "don't shoot yourself in the foot" :-)
Or, be tolerant of things you don't understand.
I agree that it needs a road show to bring this to many other verticals, but
I think that ultimately, those other entities are looking to us to give them
something to cite. The question is whether the TLS profile is the right
place for it.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
