Hi, I think we’re past this, but just to be clear:
There are a VAST number of devices that run off of iDevIDs: they never transition off of them. I’m not a fan, but that’s what they do. Eliot > On 14 May 2021, at 02:22, Michael Richardson <mcr+i...@sandelman.ca> wrote: > > Signed PGP part > > I read the document before it was adopted (before SECDISPATCH), and I didn't > see any problems with it. > > I have re-read it in the context of IoT or enterprise (routers) devices that > might contain long-lived IDevID (sometimes called Manufacturer Installed > Certificates, confusingly appreviated "MIC"). > CISCO calls them Secure Unique Device Identifier (SUDI), and there are many > other manufacturers with their own interesting names. > I believe that the CHIP/MATTER effort also mandates such a thing for the > purposes of identity and device attestation. > > In BRSKI (about to be RFC8995) TLS connections are initiated from a client > (the pledge) to a Registrar. The TLS connections make use of > ClientCertificates for identification. RFC6125 rules are not relevant > to validation of the client certificate. > If a CN=, emailAddress= or DC= was present in the ClientCertificate it would > not be used as part of the validation in a compliant Registrar. > The Registrar cares about the X520SerialNumber (aka "serialNumber=") only. > > In the other direction, the pledge does not initially validate the Registrar > ServerCertificate at all. It is taken as given, provisionally, until such > time as the pledge gets corroboration from an RFC8366 voucher. In general, > the Registrar certificate is issued from a private (enterprise) PKI, and the > corroboration depends upon a sales relationship with the vendor (the MASA). > > RFC6125 DNS-ID validations may occur in the MASA, depending upon policy. > The new rules from use-san should apply without a problem, if any 6125 > validation (vs explicit pinning) was used. > The Registrar->MASA connection is already explicitely RFC6125 DNS-ID only. > > In summary, I don't see anything in use-san that will affect BRSKI. > > It may be that Cisco and other manufacturers use their certificates in other > ways, and I can't speak for whether they might be affected. > > > Some nits: > >> While not discussed in [RFC6125] this section also implicitly >> prohibits the use of the Domain Component or emailAddress RDN's. > > 1) it seems like, since it's mentioned here, that it's not "implicit" at all. > It seems rather explicit to me. > > 2) I think that the deprecation of a sequence of "DC=" probably warrants a > sentence of its own. > > 3) I'm unclear how emailAddress was used when a DNS name was desired. > Were there rules that allowed the client to say, "connect to example.com" > and then validation was okay if the certificate says > emailAddress=f...@example.com? > If so, then I think that this situation should be more clearly deprecated. > > 4) I suggest that section 3 "The New Rules" should be in positive language > only. Most of the language is what not to do. I think that this is > important to list, but I suggest it be split up into a section "Do this" > and a section "Do not do this" > > -- > Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
