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: PGP signature
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
