Subject: [Uta] 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

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 21 May 2021 16:27:16 +0000

Francesca do you have any guidance?  No rush, I have a month to publish another draft :)

From: Spencer IETF <[email-masked]>
Date: Saturday, May 15, 2021 at 6:50 PM
To: Michael Richardson <[email-masked]>
Cc: Rich Salz <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Iotops] BRSKI and IDevID (non-!)issues with draft-ietf-uta-use-san

For what it's worth,

On Fri, May 14, 2021 at 1:52 PM Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

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.

Best,

Spencer

---

From: Francesca Palombini <[email-masked]>
Date: Mon, 24 May 2021 09:23:58 +0000

Hi Rich,

I believe the “obsoleting” path is a better choice here. In general, the “Updates” field can be interpreted in different ways, while “Obsoletes” is straightforward. In addition, 6125 does not have other documents updating it, so that information would not be lost by obsoleting it. Just be mindful of the risk of re-discussing old points not in scope of the current I-D, as Michael says.

Francesca

From: "Salz, Rich" <[email-masked]>
Date: Friday, 21 May 2021 at 18:27
To: Spencer Dawkins at IETF <[email-masked]>, Michael Richardson <[email-masked]>, Francesca Palombini <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Iotops] BRSKI and IDevID (non-!)issues with draft-ietf-uta-use-san

For what it's worth,

Best,

Spencer

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 24 May 2021 11:19:19 +0000

*   I believe the “obsoleting” path is a better choice here. In general, the “Updates” field can be interpreted in different ways, while “Obsoletes” is straightforward. In addition, 6125 does not have other documents updating it, so that information would not be lost by obsoleting it. Just be mindful of the risk of re-discussing old points not in scope of the current I-D, as Michael says.

So a full replacement.  Apply the current draft as a patch and post the result as the new version. :)  Ok.

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 24 May 2021 19:08:30 +0300

Hi Rich,

there are few errata for RFC 6125 with different status (mostly Reported, but at least one - Held for Document Update) -  <https://www.rfc-editor.org/errata_search.php?rfc=6125> RFC Errata Report » RFC Editor (rfc-editor.org)

I also think that authors of original RFC should be contacted and asked whether they want to co-author bis document (and one of errata was reported by them).

Regards,

Valery.

·        I believe the “obsoleting” path is a better choice here. In general, the “Updates” field can be interpreted in different ways, while “Obsoletes” is straightforward. In addition, 6125 does not have other documents updating it, so that information would not be lost by obsoleting it. Just be mindful of the risk of re-discussing old points not in scope of the current I-D, as Michael says.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 24 May 2021 16:17:33 +0000

*   there are few errata for RFC 6125 with different status (mostly Reported, but at least one - Held for Document Update) - RFC Errata Report » RFC Editor (rfc-editor.org)<https://urldefense.com/v3/__https:/www.rfc-editor.org/errata_search.php?rfc=6125__;!!GjvTz_vk!F3Ok1Iiv3Rz5Ezr4oWk8WK_Xguhx5ucVyCAYNnT1PrUoePN0skXdc-_yvMUY$>
  *   I also think that authors of original RFC should be contacted and asked whether they want to co-author bis document (and one of errata was reported by them).

That makes sense, I will do that.

---

From: Keith Moore <[email-masked]>
Date: Sun, 30 May 2021 22:57:03 -0400

On 5/24/21 12:08 PM, Valery Smyslov wrote:

> I also think that authors of original RFC should be contacted and 
> asked whether they want to co-author bis document (and one of errata 
> was reported by them).

IMO it's fine to contact the authors of an original RFC and point out 
that an update is needed.   But it's really presumptuous and rude to 
appoint oneself a co-author of a bis document and suggest that the 
original authors should become co-authors.   IMO that should be a last 
resort option, for the cases where the original authors aren't willing 
to revise their document, not the first suggestion made.

Keith

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 31 May 2021 19:37:46 +0000

*   IMO it's fine to contact the authors of an original RFC and point out that an update is needed.   But it's really presumptuous and rude to appoint oneself a co-author of a bis document and suggest that the original authors should become co-authors.   IMO that should be a last resort option, for the cases where the original authors aren't willing to revise their document, not the first suggestion made.

I am not sure I understand you.  Are you saying that once an RFC is authored, any BIS work must first be offered to the original authors?  If so, what about when the WG has been shut (LAMPS instead of PKIX)? Or this case, where someone wrote a draft and the WG adopted it.  Should the WG then ask the new author to wait until they’ve heard from the original authors? In this case, was I mistaken to submit a draft without first contacting Jeff and Peter before doing anything?

---

From: Keith Moore <[email-masked]>
Date: Mon, 31 May 2021 15:58:45 -0400

On 5/31/21 3:37 PM, Salz, Rich wrote:

>   * IMO it's fine to contact the authors of an original RFC and point
>     out that an update is needed.   But it's really presumptuous and
>     rude to appoint oneself a co-author of a bis document and suggest
>     that the original authors should become co-authors.   IMO that
>     should be a last resort option, for the cases where the original
>     authors aren't willing to revise their document, not the first
>     suggestion made.
>
> I am not sure I understand you.  Are you saying that once an RFC is 
> authored, any BIS work must first be offered to the original authors?  
> If so, what about when the WG has been shut (LAMPS instead of PKIX)? 
> Or this case, where someone wrote a draft and the WG adopted it.  
> Should the WG then ask the new author to wait until they’ve heard from 
> the original authors? In this case, was I mistaken to submit a draft 
> without first contacting Jeff and Peter before doing anything?
>
It's not a legal necessity, as everyone who authors a draft that becomes 
an RFC grants IETF the permission to create derivative works.   But it 
is common courtesy and longstanding practice, and I would claim a useful 
one.

The fact that the original WG has shut down is irrelevant.    The WG did 
not write the document.

It certainly seems inappropriate to claim co-authorship on a document, 
without the blessing of the original authors, if one has made only 
relatively minor contributions to that document.

More generally, a document's authors have a unique role in keeping a 
document coherent.  It's very easy for a new co-author to destroy that 
coherence by making lots of seemingly minor changes that subtly change 
the meaning of the text.   If there's any desire to maintain backward 
compatibility with the old version of the document, or with old 
implementations, updates should be done with extreme care.   The new 
co-author(s) may not understand the reasons behind word choices in the 
old document.

Keith

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 31 May 2021 23:19:05 +0300

Hi Keith,

the 6125-bis draft has not been yet been issued, even the -00 version, so it's a bit early for you 

to make conclusions on selecting its authors. I agree with you that it's best if original

authors take part in authoring -bis document and that's why I suggested Rich to contact

Peter and Jeff for co-authoring before publishing the initial version. 

Regards,

Valery.

From: Uta [mailto:[email-masked]] On Behalf Of Keith Moore
Sent: Monday, May 31, 2021 10:59 PM
To: Salz, Rich; [email-masked]
Subject: Re: [Uta] [Iotops] BRSKI and IDevID (non-!)issues with draft-ietf-uta-use-san

It's not a legal necessity, as everyone who authors a draft that becomes an RFC grants IETF the permission to create derivative works.   But it is common courtesy and longstanding practice, and I would claim a useful one.

The fact that the original WG has shut down is irrelevant.    The WG did not write the document.

It certainly seems inappropriate to claim co-authorship on a document, without the blessing of the original authors, if one has made only relatively minor contributions to that document.

More generally, a document's authors have a unique role in keeping a document coherent.  It's very easy for a new co-author to destroy that coherence by making lots of seemingly minor changes that subtly change the meaning of the text.   If there's any desire to maintain backward compatibility with the old version of the document, or with old implementations, updates should be done with extreme care.   The new co-author(s) may not understand the reasons behind word choices in the old document.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 31 May 2021 16:59:45 -0400

> Peter and Jeff for co-authoring before publishing the initial version.
There may be some context here that I'm not aware of so I'm not 
commenting specifically on this document.

But in general, IMO the first request should generally be to the 
original authors to see if they're willing to update the document 
WITHOUT taking on a co-author.   Appointing another co-author, or having 
a new author appear to appoint him/her-self, can be extremely rude.  
Co-authors need to be able to work together, and there can be 
significant conflicts between co-authors who would otherwise work just 
fine together in the context of say a working group.   Also, because 
co-authors have the ability to update the document in the I-D 
repository, a great deal of trust between co-authors is needed.  This is 
particularly important for security documents because there is a history 
of security proposals being weakened by bad actors.

Keith