Re: [Iotops] BRSKI and IDevID (non-!)issues with draft-ietf-uta-use-san

[Eliot Lear <[e-mail]>]

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 <[e-mail]> 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=[e-mail]?
>   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 <[e-mail]>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 
> 
>