Subject: [Uta] Adoption of draft-rsalz-use-san

From: "Valery Smyslov" <[email-masked]>
Date: Sun, 14 Mar 2021 17:47:47 +0300

Hi,

this message starts 2 weeks formal adoption call for draft-rsalz-use-san.

The call will end on Sunday 28 March.

The draft has already received some support for adoption, of course it'll be counted.

Regards,

Valery (for the chairs).

---

From: Loganaden Velvindron <[email-masked]>
Date: Sun, 14 Mar 2021 19:02:19 +0400

> The call will end on Sunday 28 March.

I support adoption of the draft and will provide feedback.

> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 14 Mar 2021 15:46:30 +0000

Hi,

> On 14 Mar 2021, at 14:47, Valery Smyslov <[email-masked]> wrote:
> 
> 
> Hi,
>  

I support adoption of this document.

Best Regards,
Alexey

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sun, 14 Mar 2021 18:38:49 +0100

> On 14 Mar 2021, at 16:46, Alexey Melnikov <[email-masked]> wrote:
> 
> Hi,
> 
I support adoption of this document

/O
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/uta <https://www.ietf.org/mailman/listinfo/uta>

---

From: Brian Smith <[email-masked]>
Date: Sun, 14 Mar 2021 14:37:41 -0700

I have read the draft and I support most of the ideas. However, is
publishing this as a separate RFC that updates RFC 6125 by patching it the
best way forward? I think it would be much better to rewrite RFC 6125 with
all the patches applied, and then have that new document obsolete
RFC 6125 instead of updating it.

Cheers,
Brian

-- 
https://briansmith.org/

---

From: Eliot Lear <[email-masked]>
Date: Mon, 15 Mar 2021 10:58:56 +0100

Architecturally, Rich is nailing it.  We should be encouraging the use of SANs.  However, use of SANs beyond the scope of the web may not be entirely ubiquitous, and so we should  either be a bit more targeted, or slow roll the other uses with some backward compatibility language.  Personally I like the latter approach.  We shouldn’t hold up deprecation across the web due to the other uses, but we should encourage those other uses to move off of subject.

If Rich and others are ok with that, I’m all for adoption.

By way of example, IEEE 802.1AR allows for the use of the subject, and some of those certs are extremely long lived.  One thing we should do is liaise this draft to the 802.1 committee so that they can prepare their base, and get their feedback about how to roll out this change.

For libraries like OpenSSL I wouldn’t mind throwing in a new flag, for instance, that would be required to validate a cert based on the subject.  That would help these other uses get over the hump over time; perhaps even with a warning of some form emitted.

Eliot

> On 14 Mar 2021, at 15:47, Valery Smyslov <[email-masked]> wrote:
> 
> Hi,
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 15 Mar 2021 08:31:39 -0200

> On Mar 15, 2021, at 7:58 AM, Eliot Lear <lear=[email-masked]> wrote:
> 

Certificates are barely checked in SMTP at all (opportunistic
and at that), but to the extent that they are, I am not aware
of anyone who's got meaningful certificates that only have a
matching CN and no matching SAN.

It is fine to deprecate the requirement to support CNs in the
absence of a DNS-ID SAN also for SMTP (not just Web).  Long
overdue.

-- 
	Viktor.

---

From: Henning Krause <[email-masked]>
Date: Mon, 15 Mar 2021 10:38:04 +0000

Hi,

As a developer for an email security gateway, I'm all in favor of validating the SAN instead of the CN on the SMTP level.

And though SMTP mostly uses opportunistic TLS, mandatory use of TLS is increasing with more people adopting MTA-STS.

Now, the proposed RFC is specifically scoped to TLS certificates. I think pushing the same thing for SMIME certificates would also be useful.

Kind regards,
Henning

> -----Original Message-----
> From: Uta [mailto:[email-masked]] On Behalf Of Viktor Dukhovni
> Sent: Montag, 15. März 2021 11:32
> To: [email-masked]
> Subject: Re: [Uta] Adoption of draft-rsalz-use-san
> 
> > Architecturally, Rich is nailing it.  We should be encouraging the use of
> SANs.  However, use of SANs beyond the scope of the web may not be
> entirely ubiquitous, and so we should  either be a bit more targeted, or slow
> roll the other uses with some backward compatibility language.  Personally I
> like the latter approach.  We shouldn’t hold up deprecation across the web
> due to the other uses, but we should encourage those other uses to move
> off of subject.
> >
> Certificates are barely checked in SMTP at all (opportunistic and at that), but
> to the extent that they are, I am not aware of anyone who's got meaningful
> certificates that only have a matching CN and no matching SAN.
> 
> It is fine to deprecate the requirement to support CNs in the absence of a
> DNS-ID SAN also for SMTP (not just Web).  Long overdue.
> 
> --
> 	Viktor.
>

---

From: Eliot Lear <[email-masked]>
Date: Mon, 15 Mar 2021 13:33:04 +0100

Hi Victor,

> absence of a DNS-ID SAN also for SMTP (not just Web).  Long

I have no problem with this sort of thing either.  In fact, perhaps now is the precise time to add this requirement for SMTP-based servers.  My issue is more around certificates used to identify hardware (iDevIDs).  In this case, if a SAN is included then implementations are requested to use HardwareModuleName from RFC 4108.

I’m quite certain this is NOT what Rich had in mind when he was writing the document, and thus my suggestions.

Eliot

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 15 Mar 2021 16:11:37 +0300

Hi Henning,

> certificates would also be useful.

I don't think S/MIME is in scope of UTA charter...

Regards,
Valery.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 15 Mar 2021 14:56:57 +0000

> I think it would be much better to rewrite RFC 6125 with all the patches applied, and then have that new document obsolete RFC 6125 instead of updating it.

I took another look at 6125 and I am happy to put up a draft if the WG prefers that approach.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 15 Mar 2021 15:14:07 +0000

>    I’m quite certain this is NOT what Rich had in mind when he was writing the document, and thus my suggestions.

There are more things in heaven and earth, Horatio, than are covered by your draft :)

Happy to add some wording if anyone has suggestions.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 15 Mar 2021 18:23:44 +0100

Thanks, Rich.  My recommendation is to state the architectural principle, much as you already you, but then to split up the recommendations, perhaps along the following lines:

Applications that make use of domain names and maybe ip addresses in certificates
Others

I *think* that is the right split (Victor got me thinking along these lines).  For the former, we don’t have to be too polite about those not using SANs: it’s well past time.  For the latter, I would couch the language just a bit, because there are likely to be non-IETF use cases tracking your work.

So something like: those producing certificates that do not contain domain names MUST use a SAN.  Those validating certificates not using domain names MAY reject certificates that do not contain a SAN, based on intended use case, length of certificates in play, and other specific application knowledge.

That probably needs a WHOLE lot of word smithing, but it gives fair warning to the industry that unstructured subjects are naughty.

I would still liaise this stuff to the IEEE.

Eliot

> On 15 Mar 2021, at 16:14, Salz, Rich <rsalz=[email-masked] <mailto:rsalz=[email-masked]>> wrote:
>

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 15 Mar 2021 17:29:45 +0000

Your suggestions seem okay to me, and we can work on it once adopted.  Thanks!

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 15 Mar 2021 17:34:02 +0000

BTW, recorded here: https://github.com/richsalz/draft-rsalz-use-san/issues/1

From: Rich Salz <[email-masked]>
Date: Monday, March 15, 2021 at 1:29 PM
To: Eliot Lear <lear=[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Uta] Adoption of draft-rsalz-use-san

---

From: Leif Johansson <[email-masked]>
Date: Tue, 16 Mar 2021 00:22:09 +0100

On 2021-03-15 15:56, Salz, Rich wrote:
> *>* I think it would be much better to rewrite RFC 6125 with all the patches applied, and then have that new document obsolete RFC 6125 instead of updating it.
> 
>  
> 

That is still a possible outcome of a WG draft - nothing forces us to publish as a separate doc.

	Cheers Leif

---

From: Watson Ladd <[email-masked]>
Date: Tue, 16 Mar 2021 22:57:22 -0700

> Architecturally, Rich is nailing it.  We should be encouraging the use of SANs.  However, use of SANs beyond the scope of the web may not be entirely ubiquitous, and so we should  either be a bit m…

Every discussion of depreciation I've been in in the IETF seems to go
the same way: no matter how gentle the prohibition we get complaints,
and meanwhile people don't notice what's disfavored, in part because
of the earlier requests to not forbid things making the indications of
future disfavor too soft.

The IETF needs a way to depreciate, and the way to do that is to
signal clearly that something has problems, which nothing short of
MUST NOT seems to get across. Otherwise nothing happens, and this has
been a major thorn in the work of this working group ever since it
started, arguably the reason this working group was started.

This depreciation will happen in Go 1.17 according to
https://golang.org/doc/go1.16#crypto/x509. We should be leading here,
not following.

> By way of example, IEEE 802.1AR allows for the use of the subject, and some of those certs are extremely long lived.  One thing we should do is liaise this draft to the 802.1 committee so that they…

There is no protocol police. The ending of CN validation will not
happen instantly, no matter what we say. If your PKI cannot reissue
the end-entity certs at issue, you have a very broken PKI: what
happens when certificates are compromised?  IEEE 802.1AR can roll out
after we say "You MUST use the SAN" just as they rolled out TLS 1.2
after it was created.

Sincerely,
Watson Ladd

---

From: Eliot Lear <[email-masked]>
Date: Wed, 17 Mar 2021 07:53:25 +0100

Watson,

> On 17 Mar 2021, at 06:57, Watson Ladd <[email-masked]> wrote:
> 

The alternative view is that we shouldn’t break stuff or write edicts we know will be ignored.  AR certs are burned into products.  They’re NEVER going to change, and some code in some contexts need to expect them.  That includes, by the way, in all likelihood, the smart meter providing your house electricity.  Not everything is apache or a browser that you can take an auto-update and simply get away from bad code.   The world is a complex place.

> signal clearly that something has problems,

Yes.

> which nothing short of
> MUST NOT seems to get across.

Why would you think that in this case?  The IEEE has been remarkably good at tracking our work, as have a  great many other organizations, but for uses you’ve never considered.  That’s why code like OpenSSL is deployed in places you’ve never heard of.  And while you’re right, we’re not the protocol police, it’s bad when we give developers advice they simply cannot follow because they live in the real world.

Eliot

---

From: Nico Williams <[email-masked]>
Date: Wed, 17 Mar 2021 11:08:07 -0500

On Mon, Mar 15, 2021 at 10:58:56AM +0100, Eliot Lear wrote:
> By way of example, IEEE 802.1AR allows for the use of the subject, and
> some of those certs are extremely long lived.  One thing we should do
> is liaise this draft to the 802.1 committee so that they can prepare
> their base, and get their feedback about how to roll out this change.
> 
> For libraries like OpenSSL I wouldn’t mind throwing in a new flag, for
> instance, that would be required to validate a cert based on the
> subject.  That would help these other uses get over the hump over
> time; perhaps even with a warning of some form emitted.

Easy fix IF we really need it:

 - relying parties MUST reject old-style certificates issued after some
   appropriate future date TBD

 - relying parties MAY continue to accept old-style certificates issued
   before some appropriate future date TBD

 - after some appropriate future date TBD, relying parties MAY reject
   old-style certificates issued before that date

 - after some later appropriate future date TBD, relying parties SHOULD
   reject old-style certificates issued before that date

As Watson noted, one should be able to get old-style certificates
re-issued with dNSName SANs and empty DNs.

Some long-lived certificates can't be replaced easily (e.g., EKcerts),
but generally those can't have any kind of hostname name because such
names cannot possibly be known at issuance time or because it's not
appropriate for the issuer to assert them.

Conversely, devices not using such hard-to-roll certs must be possible
to fix, so we can have a drop-dead date even for certificates issued
before that date.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 17 Mar 2021 12:53:59 -0400

> On Mar 15, 2021, at 5:58 AM, Eliot Lear <lear=[email-masked]> wrote:
> 

See X509_check_host(3).  It's behaviour is customisable via the
below flags:

    X509_CHECK_FLAG_ALWAYS_CHECK_SUBJECT,
    X509_CHECK_FLAG_NEVER_CHECK_SUBJECT,
    X509_CHECK_FLAG_NO_WILDCARDS,
    X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS,
    X509_CHECK_FLAG_MULTI_LABEL_WILDCARDS.
    X509_CHECK_FLAG_SINGLE_LABEL_SUBDOMAINS.

So what Rich is proposing amounts to changing the default flag
setting from zero to X509_CHECK_FLAG_NEVER_CHECK_SUBJECT, and
then applications that want the legacy behaviour can just clear
that flag bit if they so desire.

-- 
	Viktor.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 17 Mar 2021 18:00:04 +0100

> On 17 Mar 2021, at 17:53, Viktor Dukhovni <[email-masked]> wrote:
> 
> 

Ok, that makes a whole lot of sense.

Eliot

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 17 Mar 2021 13:13:30 -0400

> On Mar 17, 2021, at 1:00 PM, Eliot Lear <lear=[email-masked]> wrote:
> 

For the record, there's also X509_VERIFY_PARAM_set_hostflags(3),
which in combination with X509_VERIFY_PARAM_set1_host(3) and
X509_VERIFY_PARAM_add1_host(3) performs the hostname checks
automatically as part of the overall certificate chain verification
process.  For TLS applications, there are also:

     int SSL_set1_host(SSL *s, const char *hostname);
     int SSL_add1_host(SSL *s, const char *hostname);
     void SSL_set_hostflags(SSL *s, unsigned int flags);

which provide a simpler interface than having to dig down to the
underlying X509_STORE and its verification parameter structure.

-- 
	Viktor.

---

From: Brian Smith <[email-masked]>
Date: Wed, 17 Mar 2021 10:57:33 -0700

Leif Johansson <[email-masked]> wrote:

> Salz, Rich wrote:
> > *>* I think it would be much better to rewrite RFC 6125 with all the
> patches applied, and then have that new document obsolete RFC 6125 instead
> of updating it.
> >

Then I think the working group should adopt this and I'll help review it.

It actually looks pretty good to me. The only thing I disagree with is "Severs
either MUST NOT issue a CN-ID, or MUST use a form for the Common Name RDN
that cannot be mistaken for an identifier" and similar language. It would
be better to let people put whatever they want in the CN field of the
subject whether or not it looks like a domain name. As long as conformant
clients stop using the CN as a dNSName/iPAddress SAN alternative, then it
doesn't matter what's in the CN. Probably some users will need to duplicate
what's in the SAN in the subject CN for backward compatibility with
nonconformant verifiers.

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

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 17 Mar 2021 19:38:26 +0000

*   It actually looks pretty good to me. The only thing I disagree with is "Severs either MUST NOT issue a CN-ID, or MUST use a form for the Common Name RDN that cannot be mistaken for an identifier" and similar language. It would be better to let people put whatever they want in the CN field of the subject whether or not it looks like a domain name. As long as conformant clients stop using the CN as a dNSName/iPAddress SAN alternative, then it doesn't matter what's in the CN. Probably some users will need to duplicate what's in the SAN in the subject CN for backward compatibility with nonconformant verifiers.

That’s a good point.  If the doc focuses purely on client behavior then that makes it easier for legacy, such as Elliot’s vehicle issue, and also makes it more clear about the wildcards.

---

From: Hubert Kario <[email-masked]>
Date: Fri, 19 Mar 2021 12:06:30 +0100

On Monday, 15 March 2021 11:38:04 CET, Henning Krause wrote:
> Hi,
>
> As a developer for an email security gateway, I'm all in favor 
> of validating the SAN instead of the CN on the SMTP level.
>
> And though SMTP mostly uses opportunistic TLS, mandatory use of 
> TLS is increasing with more people adopting MTA-STS.
>
> Now, the proposed RFC is specifically scoped to TLS 
> certificates. I think pushing the same thing for SMIME 
> certificates would also be useful.

Were people putting email addresses into the CN field, where there has been
an email field since "forever"?

I don't think we shoud worry (and thus include that information in the RFC)
about them.

-- 
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: Hubert Kario <[email-masked]>
Date: Fri, 19 Mar 2021 12:20:23 +0100

On Wednesday, 17 March 2021 07:53:25 CET, Eliot Lear wrote:
>>> Architecturally, Rich is nailing it.  We should be 
>>> encouraging the use of SANs.  However, use of SANs beyond the 
>>> scope of the web may not be entirely ubiquitous, and so we 
>>> should  either be a bit more targeted, or slow roll the other 
>>> uses with some backward compatibility language.  Personally I 
>>> like the latter approach.  We shouldn’t hold up deprecation 
>>> across the web due to the other uses, but we should encourage 
>>> those other uses to move off of subject.
>> 
> The alternative view is that we shouldn’t break stuff or write 
> edicts we know will be ignored.  AR certs are burned into 
> products.  They’re NEVER going to change, and some code in some 
> contexts need to expect them.  That includes, by the way, in all 
> likelihood, the smart meter providing your house electricity.  
> Not everything is apache or a browser that you can take an 
> auto-update and simply get away from bad code.   The world is a 
> complex place.

it's also a place that needs to keep on moving forward as new attacks and
more powerful computers come into light every year

> Why would you think that in this case?  The IEEE has been 
> remarkably good at tracking our work, as have a  great many 
> other organizations, but for uses you’ve never considered.  
> That’s why code like OpenSSL is deployed in places you’ve never 
> heard of.  And while you’re right, we’re not the protocol 
> police, it’s bad when we give developers advice they simply 
> cannot follow because they live in the real world.

they also need to accept the reality that their use-case is a niche use
case for the whole ecosystem, so not all things will align nicely and not
all advice will be applicable to them

so maybe, we should give them a little bit of credit and assume that they 
are
able to differentiate stuff that makes sense in their context from stuff
that's applicable to the web in general
-- 
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: "Eliot Lear (elear)" <[email-masked]>
Date: Fri, 19 Mar 2021 14:12:25 +0000

> On 19 Mar 2021, at 12:20, Hubert Kario <[email-masked]> wrote:
> 

Sure.  That’s why I support the draft.

> all advice will be applicable to them

Is it?  There are hundreds of millions of devices that cover this use case, and that number is accelerating.

> 
> so maybe, we should give them a little bit of credit and assume that they are

And herein lies the problem: either this document is intended for the “web” or it is intended to be general.  The two are not the same.  I like scoping this document broadly, though, to mark what is currently a best practice.  And THEN you can give those people credit for doing the right thing, because they largely have in the past.

To be clear: this is a bit of a juggernaut.  The idea that a device identity survives through the entire lifetime of a device very much depends on what that lifetime is.  Toys and IT equipment have 3-5 year lifetimes.  Some sensors have six week lifetimes.  Some stuff in the ground has 40-50 year lifetimes, and some mechanical tools like presses have 120 year lifetimes.

So sure.  802.1AR is going to need to evolve around these concepts.  But let’s please just recognize the reality we face, that the currently deployed systems are going to be around for quite a while, they will continue to verify as they do, and their certs won’t change, at least for onboarding purposes.

Eliot

---

From: Hubert Kario <[email-masked]>
Date: Fri, 19 Mar 2021 17:01:54 +0100

On Friday, 19 March 2021 15:12:25 CET, Eliot Lear (elear) wrote:
>>> That’s why code like OpenSSL is deployed in places you’ve 
>>> never heard of.  And while you’re right, we’re not the 
>>> protocol police, it’s bad when we give developers advice they 
>>> simply cannot follow because they live in the real world.
>> 
> Is it?  There are hundreds of millions of devices that cover 
> this use case, and that number is accelerating.

and how it's a good thing that the number of devices that can't have their
software updated is accelerating?

> And herein lies the problem: either this document is intended 
> for the “web” or it is intended to be general.  The two are not 
> the same.  I like scoping this document broadly, though, to mark 
> what is currently a best practice.  And THEN you can give those 
> people credit for doing the right thing, because they largely 
> have in the past.
>
> To be clear: this is a bit of a juggernaut.  The idea that a 
> device identity survives through the entire lifetime of a device 
> very much depends on what that lifetime is.  Toys and IT 
> equipment have 3-5 year lifetimes.  Some sensors have six week 
> lifetimes.  Some stuff in the ground has 40-50 year lifetimes, 
> and some mechanical tools like presses have 120 year lifetimes.
>
> So sure.  802.1AR is going to need to evolve around these 
> concepts.  But let’s please just recognize the reality we face, 
> that the currently deployed systems are going to be around for 
> quite a while, they will continue to verify as they do, and 
> their certs won’t change, at least for onboarding purposes.

the whole point of it is to say: this is how you this TLS stuff,
if you don't do it like this, you really should have a good excuse

but it's not IETF job to find those excuses, and it's not IETF job to
ensure that you're able to use IETF protocols, unchanged, for 50
years

now, just because you have an excuse, doesn't mean you don't have a
liability, just like the people that run lathes or presses using
Windows 95 PCs
-- 
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: Eliot Lear <[email-masked]>
Date: Fri, 19 Mar 2021 17:19:17 +0100

Hubert,

This is it for me.  Apparently you are not going to be convinced that the world is bigger than the web.  This is not about excuses, but the real world.  It is not about lawyering- few of us here, if any are lawyers.  Probably a good thing.  Again, I am happy for this document to extend beyond the scope of the web, because as I wrote, Rich is giving good architectural advice, but then let’s recognize evolution takes place at different paces in different places, and interoperability remains important.  The lights have too tay on.

One correction:

> On 19 Mar 2021, at 17:01, Hubert Kario <[email-masked]> wrote:
> 

No, that’s not what is happening on the whole.  It is one component of the device that cannot be updated: its hardware identity.  It relates to anti-counterfeiting and support aspects of complex systems. It may not be as hard in the medium term when TEEs are everywhere, but even then that’s a debatable point.

And this is just one use case out of many outside the context of the web.

Eliot

---

From: Nico Williams <[email-masked]>
Date: Fri, 19 Mar 2021 11:34:29 -0500

On Wed, Mar 17, 2021 at 07:53:25AM +0100, Eliot Lear wrote:
> The alternative view is that we shouldn’t break stuff or write edicts
> we know will be ignored.  AR certs are burned into products.  They’re
> NEVER going to change, and some code in some contexts need to expect
> them.  That includes, by the way, in all likelihood, the smart meter
> providing your house electricity.  Not everything is apache or a
> browser that you can take an auto-update and simply get away from bad
> code.   The world is a complex place.

A better alternative view is that certs issued before a certain date can
continue to be validated with the old rules, and certs issued after can
be required by RPs to have SANs.  A much better approach to not breaking
existing things while still making progress.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 19 Mar 2021 11:41:34 -0500

On Fri, Mar 19, 2021 at 05:19:17PM +0100, Eliot Lear wrote:
> This is it for me.  Apparently you are not going to be convinced that
> the world is bigger than the web.  This is not about excuses, but the
> real world.  It is not about lawyering- few of us here, [...]

I think you've convinced yourself that there isn't a better alternative
to the one you've suggested, and so you feel justified in writing such
an aggressive reply to Hubert (which reads to me as "apparently you are
not going to be convinced that you're so very very wrong, have a nice
day").

My take is that RPs should be prepared to validate certs issued before a
certain date using the old DN rules but require SANs in certs issued
after.  This covers the extant very-long-lived certs use cases while
still making progress.

Now, there might be other extant issues, like old RPs that can't be
upgraded.  There's still room for argument.

Nico
--

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 29 Mar 2021 15:58:15 +0300

Hi,

the call for adoption is over. We received a very strong support

for adoption of the draft and some good comments regarding its content.

The draft is adopted. Rich, can you please re-issue the draft with draft-ietf-uta-* name.

Regards,

Valery (for the chairs).

Hi,

Regards,

Valery (for the chairs).