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

From: "Salz, Rich" <[email-masked]>
Date: Mon, 19 Apr 2021 16:33:55 +0000

I don’t know of a good way to address the concern raised by Eliot [1]. I don't want to make the requirements weaker. I would really like to hear from others. 

[1] https://mailarchive.ietf.org/arch/msg/uta/ayfVzc_j0kK7wY0_cW8OR9r81LE/

---

From: Eliot Lear <[email-masked]>
Date: Mon, 19 Apr 2021 19:48:20 +0200

Hi Rich,

A few of us just had this discussion in another context.  Try this:

CAs MUST populate a SAN.
Verifiers MUST use a SAN if present.
Verifiers MUST reject certificates without a SAN by default.
Verifiers MAY be configured to accept certificates without SANs when very long lived certificates are expected to be encountered.

Eliot

> On 19 Apr 2021, at 18:33, Salz, Rich <rsalz=[email-masked]> wrote:
> 
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta

---

From: Brian Smith <[email-masked]>
Date: Mon, 19 Apr 2021 12:33:44 -0700

Eliot Lear <lear=[email-masked]> wrote:

>
>    - CAs MUST populate a SAN.
>    - Verifiers MUST use a SAN if present.
>    - Verifiers MUST reject certificates without a SAN by default.
>    - Verifiers MAY be configured to accept certificates without SANs when
>    very long lived certificates are expected to be encountered.
>
> Some certificates identify a subject where a GeneralName is the accepted
way of naming the subject. For example, end-user smart card certificates
used for client authentication. For such certificates, even V1 certificates
without any extensions, and in particular without any subjectAltName
extension, are reasonable.

I would very much like to stick to the original idea I proposed back before
the initial draft: Let's just rewrite RFC 6125 to remove the concept of
CN-ID, and call it a day. Don't put any requirements on producers of
certificates. They can put whatever they want into the Common Name field
and it will be ignored by conformant (to the new spec) validators.

Cheers,
Brian

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 19 Apr 2021 20:17:43 +0000

*   I would very much like to stick to the original idea I proposed back before the initial draft: Let's just rewrite RFC 6125 to remove the concept of CN-ID, and call it a day. Don't put any requirements on producers of certificates. They can put whatever they want into the Common Name field and it will be ignored by conformant (to the new spec) validators.

I also think we should have the wildcard limitations that are in the draft-use-san.

The more I think about it, the more I am in favor of this. As I said back then, I’m willing to do it.

Anyone else have a preference between this and Eliot’s?

---

From: "Jim Fenton" <[email-masked]>
Date: Mon, 19 Apr 2021 13:55:13 -0700

I’m probably joining in the middle of this conversation, but please be 
patient with me:

> Verifiers MUST reject certificates without a SAN by default.

I don’t understand what “by default” means here; it seems to 
conflict with the MUST. Of course using CN to indicate the subject of 
the certificate hasn’t been good practice for 10 years or so, but this 
requirement seems to run counter to the principle of being liberal in 
what you accept (with the obvious exception of things that create a 
security problem, but I don’t think that is the case here). What is 
the problem that this requirement is solving, other than eliminating a 
few lines in certificate verification code?

> Verifiers MAY be configured to accept certificates without SANs when 

This must be the exception to the previous bullet. But I would expect 
the requirement to be based on the issue date of the certificate, not 
its lifetime. How does a verifier know in advance what to expect?

Are CAs issuing certificates with freeform text in their CN fields, is 
that the problem?

-Jim

---

From: Eliot Lear <[email-masked]>
Date: Tue, 20 Apr 2021 07:42:22 +0200

Hi Jim,

802.1AR has some very long lived certificates out there (no expiration date) because they’re burned into the device.  Now, not everything needs to deal with AR certs, and they’re not meant for normal web usage.  This group is focused on web usage, but rather than scope Rich’s draft to that, my suggestion is that we simply take the reality into account, and note that there are going to be places where such certs exist for quite a while, and that some implementations will have to deal with them.  To do otherwise ignores reality.

Conveniently, AR cert usage in the wild is generally constrained, and people shift over to deployment certificates.  That’s what draft-ietf-bootstrapping-keyinfra and RFC 8366 are for.  There are surely other uses of AR that we’re not aware of, and there are surely other uses of long lived certificates that we are also not aware of.  The verifiers in these cases are likely to know when they need to interact with such systems.  So either we give that sort of advice or they’ll simply ignore us, because otherwise their systems will simply break.

Eliot

> On 19 Apr 2021, at 22:55, Jim Fenton <[email-masked]> wrote:
> 
> I’m probably joining in the middle of this conversation, but please be patient with me:
> 
> I don’t understand what “by default” means here; it seems to conflict with the MUST. Of course using CN to indicate the subject of the certificate hasn’t been good practice for 10 years or so, but this requirement seems to run counter to the principle of being liberal in what you accept (with the obvious exception of things that create a security problem, but I don’t think that is the case here). What is the problem that this requirement is solving, other than eliminating a few lines in certificate verification code?

> This must be the exception to the previous bullet. But I would expect the requirement to be based on the issue date of the certificate, not its lifetime. How does a verifier know in advance what to expect?
> 
> Are CAs issuing certificates with freeform text in their CN fields, is that the problem?
> 
> -Jim
>

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 20 Apr 2021 13:22:20 +0000

I am of mixed-mind about Eliot’s suggestions.  The phrase that keeps  coming back is “we’re not the protocol police.”

If an application wants to stay on its own specifications, and not follow the use-san document, it almost seems like it should just do that, and not clutter up use-san with escape hatches.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 20 Apr 2021 16:03:45 +0200

Rich,

> On 20 Apr 2021, at 15:22, Salz, Rich <[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.

Eliot

---

From: Brian Smith <[email-masked]>
Date: Tue, 20 Apr 2021 15:22:36 -0700

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.

Cheers,
Brian

---

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

> 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: Hubert Kario <[email-masked]>
Date: Wed, 21 Apr 2021 19:05:47 +0200

On Wednesday, 21 April 2021 18:50:56 CEST, Eliot Lear wrote:
> Brian,
>
> If this is scoped to dnsNames then I’m fine with it going 
> forward as is.  Other names would be problematic.

why? iPAddress is actually used in SANs
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 21 Apr 2021 13:06:21 -0400

> is.  Other names would be problematic.

It was my expectation/understanding all along that we're talking about
is deprecation of CN-ID fallback when the reference identifier is a
DNS-ID.

Ideally, I'd like to see certificates that have only DNS-ID SANs
published with an empty subject name.  This is already the case when the
DNS-ID exceeds the 64 character limit on CommonName, and it would be
simply more consistent to just drop the subject name entirely, it
serves no purpose in certificates that only carry DNS names.

-- 
    Viktor.

---

From: Tony Finch <[email-masked]>
Date: Wed, 21 Apr 2021 18:34:03 +0100

> is deprecation of CN-ID fallback when the reference identifier is a

Yes, I was wondering how those very old certificates embedded in hardware
waiting on shelves would work when deployed, i.e. what's the DNS setup?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  https://dotat.at/
Shannon: East or southeast 4 to 6, occasionally 7 later. Moderate or
rough. Fair. Good.

---

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