Subject: Re: [Iotops] [Uta] How should we change draft-ietf-use-san?

From: Eliot Lear <[email-masked]>
Date: Wed, 21 Apr 2021 09:30:42 +0200

[+iotops]

Brian,

> On 21 Apr 2021, at 00:22, Brian Smith <[email-masked]> wrote:
> 
> Eliot Lear <lear=[email-masked] <mailto:[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.
> 
> 
> What you're trying to prevent is the entire purpose of this, as I had originally proposed it. The goal is to have library developers feel comfortable removing the CN-ID support completely from their libraries.

Thanks for being crisp in stating your intent.

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?

I would claim that there are three unacceptable outcomes:

Causing the app developers to write their own X.509 validation code – they’ll get it wrong.
Freezing app developers on old versions of the libraries – we want app developers to update.
Library developers ignoring the IETF.  Let’s not give advice they simply cannot follow.

By the way, one reason many of these devices have long lived certs is that they might sit in inventory for long periods of time before they are ever taken out of the box.  There are other reasons, as well.  Burned in certs can be there as a base level anti-counterfeiting measure, for instance.  And yes, there are lots of issues with burned in anything, but there are engineering tradeoffs to be made.

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.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Wed, 21 Apr 2021 09:34:18 +0200

One correction:

> What harm comes to any use case for there to be a non-default library flag, as Victor mentioned there is with OpenSSL?

The flag is there.  I don’t know the default state.

Eliot

---

From: Brian Smith <[email-masked]>
Date: Wed, 21 Apr 2021 08:54:28 -0700

Eliot Lear <[email-masked]> wrote:

> 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.
>>
>>
> What you're trying to prevent is the entire purpose of this, as I had
> originally proposed it. The goal is to have library developers feel
> comfortable removing the CN-ID support completely from their libraries.
>
>
> 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?
>

I suspect OpenSSL would continue to do what it does because it does all
kinds of stuff to support legacy implementations.

My interest is in developing software for the Web PKI (what browsers do,
roughly) and similar new systems where CN-ID isn't useful. Note that RFC
6125 and a rewrite of it wouldn't be relevant to the legacy systems that
were designed before RFC 6125, or that were designed after RFC 6125 but
chose to ignore the advice in RFC 6125 and so became legacy systems before
they even shipped.

I would claim that there are three unacceptable outcomes:
>
>    - Causing the app developers to write their own X.509 validation code
>    – they’ll get it wrong.
>    - Freezing app developers on old versions of the libraries – we want
>    app developers to update.
>    - Library developers ignoring the IETF.  Let’s not give advice they
>    simply cannot follow.
>
> Most developers will be able to take the advice to avoid CN-IDs. It is
becoming common for libraries to ignore CN-IDs by default (e.g. Golang's
library [1]) or to not support them at all (in the case of webpki [2]).

> By the way, one reason many of these devices have long lived certs is that
> they might sit in inventory for long periods of time before they are ever
> taken out of the box.  There are other reasons, as well.  Burned in certs
> can be there as a base level anti-counterfeiting measure, for instance.
> And yes, there are lots of issues with burned in anything, but there are
> engineering tradeoffs to be made.
>
> 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.
>

Are those certificates using the Subject Common Name field to identify a
DNS name or an IP address, without having the subjectAltName populated? If
not, then this proposal wouldn't affect them. This isn't saying "You must
have a subjectAltName no matter what;" it's saying "You must have a
subjectAltName using dNSName (iPAddress) to identify a subject by DNS name
(IP address)."

To your point that we should have a 10 year deprecation period: RFC 6125
was published just over 10 years ago, and already discouraged using the
subject common name for DNS names and IP addresses. So I think we've
already lived through the 10 year deprecation period.

[1] https://golang.org/doc/go1.15#commonname
[2] https://github.com/briansmith/webpki

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Eliot Lear <[email-masked]>
Date: Wed, 21 Apr 2021 18:50:56 +0200

Brian,

If this is scoped to dnsNames then I’m fine with it going forward as is.  Other names would be problematic.

Eliot

---

From: Brian Smith <[email-masked]>
Date: Wed, 21 Apr 2021 11:25:45 -0700

> Other names would be problematic.

Could you be more specific as to what other names would be problematic and
list them explicitly? Here are the choices in a GeneralName:

        otherName                       [0]     OtherName,
        rfc822Name                      [1]     IA5String,
        dNSName                         [2]     IA5String,
        x400Address                     [3]     ORAddress,
        directoryName                   [4]     Name,
        ediPartyName                    [5]     EDIPartyName,
        uniformResourceIdentifier       [6]     IA5String,
        iPAddress                       [7]     OCTET STRING,
        registeredID

Thanks,
Brian

---

From: Eliot Lear <[email-masked]>
Date: Wed, 21 Apr 2021 20:48:31 +0200

> On 21 Apr 2021, at 20:25, Brian Smith <[email-masked]> wrote:
> 
> Eliot Lear <[email-masked] <mailto:[email-masked]>> wrote:
> Could you be more specific as to what other names would be problematic and list them explicitly? Here are the choices in a GeneralName:
> 
>         otherName                       [0]     OtherName,

The principle here is long-lived names.  I can’t imagine [2] and [7] being at issue. [1] and [4] are definitely in use in long-lived environment.  I don’t know about the rest.

---

From: Brian Smith <[email-masked]>
Date: Wed, 21 Apr 2021 13:31:13 -0700

Eliot Lear <[email-masked]> wrote:

> The principle here is long-lived names.  I can’t imagine [2] and [7] being
> at issue. [1] and [4] are definitely in use in long-lived environment.  I
> don’t know about the rest.
>

OK, [2] is dNSName, and [7] is iPAddress. Those are the primary two types
of identifiers that I'm targeting: I want the spec to say that certificate
verifiers must not look for IP addresses or DNS names in the Common Name
sub-field of the Subject field of a certificate.

Regarding [4] directoryName, I don't think anybody is encoding an entire
directoryName into the Common Name field of the subject field, so that's a
non-issue.

Regarding [1] rfc822Name, are you saying that you are worried about
certificates with a subject like : CN="[email-masked]" without an
accompanying subjectAltName rfc822Name="[email-masked]"? If so, is your
concern about using these certificates in email applications? I would love
for us to get to the point where we say email applications also must use
only email addresses (rfc822Names) in the subjectAltName extension and not
look in the CN of the subject field. For non-email applications, aren't
they just using the subject field as a directoryName that's somewhat
incomplete? Regardless, non-email address uses of CN=[email-masked] would
be (or could be made) out of scope of the revised spec.

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Eliot Lear <[email-masked]>
Date: Thu, 22 Apr 2021 16:25:50 +0200

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.

Here’s the text:
The DevID subject field shall uniquely identify the device associated with the particular DevID credential within the issuer’s domain of significance. The formatting of this field shall contain a unique X.500 Distinguished Name (DN). This may include the unique device serial number assigned by the manufacturer or any other suitable unique DN value that the issuer prefers. In the case of a third-party CA or a standards certification agency, this can contain the manufacturer’s identity information.

That’s a pretty broad range.

I don’t claim that this is the only use of subjects, but it is one such use.

Email

---

From: Brian Smith <[email-masked]>
Date: Thu, 22 Apr 2021 09:58:05 -0700

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

OK, great. I don't think what Rich or what I'm proposing is in conflict
with that at all.

The idea here is to tell certificate verifiers (relying parties):
* If you're looking for a DNS name in a certificate, only look in the
subjectAltName, Don't look in the Subject Common Name.
* If you're looking for an IP address in a certificate, only look in the
subjectAltName,  Don't look in the Subject Common Name.

That's it.

In the case of  802.1AR-2009, the verifier is to look for a distinguished
name (either the Subject or a directoryName subjectAltName), not a DNS name
or an IP address, so the proposed guidance wouldn't apply.

Note that RFC 6125 punted in IP addresses because they weren't commonly
used in certificates in the working groups' judgement at the time, but now
I think it is clear that an update to RFC 6125 should address IP addresses
too.

Cheers,
Brian

---

From: Eliot Lear <[email-masked]>
Date: Thu, 22 Apr 2021 19:03:24 +0200

Thanks, Brian.  I appreciate your patience.  The below totally works for me.

Eliot

> On 22 Apr 2021, at 18:58, Brian Smith <[email-masked]> wrote:
> 
> OK, great. I don't think what Rich or what I'm proposing is in conflict with that at all.
> 
> * If you're looking for a DNS name in a certificate, only look in the subjectAltName, Don't look in the Subject Common Name.
> * If you're looking for an IP address in a certificate, only look in the subjectAltName,  Don't look in the Subject Common Name.
> 
> That's it.
> 
> In the case of  802.1AR-2009, the verifier is to look for a distinguished name (either the Subject or a directoryName subjectAltName), not a DNS name or an IP address, so the proposed guidance wouldn't apply.
> 
> Note that RFC 6125 punted in IP addresses because they weren't commonly used in certificates in the working groups' judgement at the time, but now I think it is clear that an update to RFC 6125 should address IP addresses too.
> 
> Cheers,
> Brian

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 22 Apr 2021 17:48:42 +0000

I am beginning to think that doing a complete re-issue of 6125 will be better, because trying to fit the “patch” described below seems awkward.  On the other hand, if anyone has suggestions on how to do that, please post or email or make a PR at https://github.com/richsalz/draft-rsalz-use-san

From: Eliot Lear <[email-masked]>
Date: Thursday, April 22, 2021 at 1:03 PM
To: Brian Smith <[email-masked]>
Cc: Rich Salz <[email-masked]>, Jim Fenton <[email-masked]>, "[email-masked]" <[email-masked]>, <[email-masked]>
Subject: Re: [Uta] How should we change draft-ietf-use-san?

Eliot

On 22 Apr 2021, at 18:58, Brian Smith <[email-masked]<mailto:[email-masked]>> wrote:

Eliot Lear <[email-masked]<mailto:[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.

That's it.

Cheers,
Brian