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

From: Michael Richardson <[email-masked]>
Date: Thu, 13 May 2021 20:22:46 -0400

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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 May 2021 20:39:11 -0400

Sorry that this email is three weeks old.
I felt that it deserved a proper reply.

Eliot Lear <lear=[email-masked]> wrote:
    > The issue for me is library support.  If libraries take the doc too
    > seriously, it screws the apps that really need to do the right thing
    > for their use cases.

I partly agree.
There are two parties here:
  1) the validating end
  2) the long-lived certificate end

The long-lived certificate end might have a SAN-less (an "insane certificate"?)
certificate, but it does not typically validate that.

So, the thing that we are worried about is the validating end that is subject
to regular updates.  It might be built decades after the certificate end.
Note that it needs a trust anchor to be able to validate the long-lived-certificate,
or nothing works.
Can we agree that this is therefore *not* a simple call to "libcurl"?
I've been through this on Android and iOS and once you need to introduce the
new trust anchor, you get into the much more harry aspects of the API.

The parts of the API where you actually have to say how to you are validating.

It seems extremely unlikely that it would be validating with CN-ID in that
case.  (Many of us in IoTSF ManySecured WG are trying to find a way to easily
validate via current DNS-ID rules)

What I'm saying is that I think that your strawman does not hold water.
(Is that the right idiom?)

    > Let's turn the question around, because perhaps I am missing something.
    > Bearing in mind that there are literally hundreds of millions of
    > devices with long-lived certificates fielded today, what advice would
    > you give to those who support applications that have to interact with
    > them?  What harm comes to any use case for there to be a non-default
    > library flag, as Victor mentioned there is with OpenSSL?

The default is that you get the stock verification function.
The non-default case is that you provide your own verification function.
There actually isn't really anything else in between.

    > Causing the app developers to write their own X.509 validation code –

It's where they already are.

    > To Jim’s point, maybe it would be possible to say that the flag should
    > be unavailable for certs issued after a certain date, but that date
    > would have to be well into the future, and coordinated at least with
    > IEEE.  That seems like a lot of work for something that, as Rich
    > rightly alludes, is really a vendor decision to intelligently make.

Should some of these non-DNS-ID (and also non-CN-ID) verifications become
common place, I can see that one might want to have a policy OID in a CA
certificate that informed a library how it "ought" to verify.  Perhaps that
is already a thing.... probably...
(I remember drinking a lot during pki4ipsec WG, but not much else about it)

Eliot Lear <lear=[email-masked]> wrote:
    > Actually, according to 802.1AR-2009, the subject MUST contain requires
    > a DN with serial number, and it may contain a SAN (e.g., don’t count on
    > it).  That’s the major concern.  To me, the rest is really negotiable.

I have built IDevID certificates with SANs, with via public anchors,
but they aren't long-lived.

So the only way we get into trouble is when the application specifies a
private trust anchor, asks for CN-ID/DNS-ID validation, and the certificate
is long-lived.
CABFORUM trust anchors are supposed to be limited to 13 months now
(if issues after September 2020),  and I believe that this duration is now
getting baked into browsers, and I assume some libraries.
(someone will correct me if I'm wrong)

So, *today* in order to combine:
    a) long-lived IDevID signed by private-CA
    b) CN-ID verification
    c) private-trust anchor

The application developer already needed to tweak flags.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 14 May 2021 01:05:19 +0000

>    In summary, I don't see anything in use-san that will affect BRSKI.

That is great to hear, thanks for the careful analysis.

>    Some nits:

All look like good things to do, I'll make a PR soonish.

What do you think of just rewriting this to completely replace 6125, rather than trying to be a "diff RFC"?

---

From: Eliot Lear <[email-masked]>
Date: Fri, 14 May 2021 08:52:36 +0200

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 <[email-masked]> wrote:
> 
> Signed PGP part
>

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 14 May 2021 14:02:39 +0000

>    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.

Okay, so this draft doesn't apply to them.  There doesn't seem to be a problem with, say, not using TLS 1.3 in cases, or not using ECDH in some cases, so why is this draft different from those situation?

---

From: Eliot Lear <[email-masked]>
Date: Fri, 14 May 2021 16:08:11 +0200

Rich,

As I wrote, I think we’re past it, because this is about domain/IP address validation and not client cert validation.  Correct?

Eliot

> On 14 May 2021, at 16:02, Salz, Rich <[email-masked]> wrote:
>

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 14 May 2021 15:14:36 +0000

>    As I wrote, I think we’re past it, because this is about domain/IP address validation and not client cert validation.  Correct?

Ah, right.  Thanks.  Too many balls in the air :)

---

From: Michael Richardson <[email-masked]>
Date: Fri, 14 May 2021 14:51:58 -0400

> rather than trying to be a "diff RFC"?

If you mean, rfc6125bis, then it seems like it would risk opening wounds.
But, wholesale, "replace section X with ...."  might be useful.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sat, 15 May 2021 17:50:05 -0500

For what it's worth,

> But, wholesale, "replace section X with ...."  might be useful.

I'd absolutely run this past the responsible AD. The IESG's view of patch
RFCs versus diff RFCs varies over time, and I discovered late in my third
term that the IESG didn't have a common understanding of what we should do
in this case - and embarrassingly, I was in the rough.

Datatracker references on request, or you can trust me on this one ...

Best,

Spencer