Subject: Re: [Secdispatch] Requesting agenda time for draft-rsalz-use-san

From: "Martin Thomson" <[email-masked]>
Date: Wed, 03 Mar 2021 15:56:25 +1100

What Rich is doing here is good.  SAN is dead and we should ensure that our documentation reflects that.  (Even at the time of 6125 it was a holdover from a previous era.)

Is now the time that we get to talk about other updates to RFC 6125?  Because there is no IP-ID reference identity in RFC 6125 and HTTP had to define one just to document what happens in practice: https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#https.ip-id

I don't want to get in the way of making actual progress here, but knowing the difficulties with getting 6125 done, it might be safer to do this work in a working group.  I have no opinion regarding whether it is a new one or UTA.

On Fri, Feb 5, 2021, at 02:43, Salz, Rich wrote:
> I would like to present https://datatracker.ietf.org/doc/draft-rsalz-use-san/
> 
> This updates RFC 6125 to remove commonName as a way to identify the 
> server; just use subjectAltName.  It also limits where the "*" can go 
> in wildcard certificates. This is a simplification of widely 
> implemented existing practice. It may even be de facto what's mostly 
> done. Perhaps the wildcard limitation is controversial and I'd be 
> willing to remove it.
> 
> 6125 was AD-sponsored. I think this could also be, or perhaps it could 
> go to UTA. I would not present any slides, and think 10-15 minutes 
> would be enough time.
>  
> 
> _______________________________________________
> Secdispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch
>

---

From: Carrick Bartle <[email-masked]>
Date: Tue, 2 Mar 2021 21:28:58 -0800

> SAN is dead 

Wait, what? Do you mean CN?

> On Mar 2, 2021, at 8:56 PM, Martin Thomson <[email-masked]> wrote:
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 2 Mar 2021 21:55:00 -0800

On Wed, Mar 03, 2021 at 03:56:25PM +1100, Martin Thomson wrote:
> What Rich is doing here is good.  ~~SAN~~CN is dead and we should ensure that our documentation reflects that.  (Even at the time of 6125 it was a holdover from a previous era.)
> 

I do have a longstanding item in my list of things to do for updating 6125
in this manner.  (Note that
https://tools.ietf.org/html/draft-ietf-dtn-tcpclv4-25#section-4.4.1 has
also had to define an IPADDR-ID.)

I *also* have a longstanding item in my list for doing something analogous
to 6125 but for client authentication.  That, however, is a much more
open-ended question that should be a separate effort.

> I don't want to get in the way of making actual progress here, but knowing the difficulties with getting 6125 done, it might be safer to do this work in a working group.  I have no opinion regardin…

I am hopeful that the UTA chairs can provide some thoughts here.

-Ben

---

From: John Mattsson <[email-masked]>
Date: Wed, 3 Mar 2021 13:32:21 +0000

+1 for draft-rsalz-use-san
+1 for Ben's list of things to do for updating 6125

RFC 6125 is important. I think draft-rsalz-use-san and Ben's list of things to do for updating 6125 should be part of RFC6125bis done in a WG.

John

-----Original Message-----
From: Secdispatch <[email-masked]> on behalf of Benjamin Kaduk <[email-masked]>
Date: Wednesday, 3 March 2021 at 06:55
To: Martin Thomson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Secdispatch] Requesting agenda time for draft-rsalz-use-san

On Wed, Mar 03, 2021 at 03:56:25PM +1100, Martin Thomson wrote:
> Is now the time that we get to talk about other updates to RFC 6125?  Because there is no IP-ID reference identity in RFC 6125 and HTTP had to define one just to document what happens in practice: https://protect2.fireeye.com/v1/url?k=6c98cf38-3303f613-6c988fa3-866038973a15-d092f6bd04e72169&q=1&e=aa803440-e857-4dee-a5fe-3c4ab8ff3e81&u=https%3A%2F%2Fhttpwg.org%2Fhttp-core%2Fdraft-ietf-httpbis-semantics-latest.html%23https.ip-id

-Ben

---

From: Michael Richardson <[email-masked]>
Date: Wed, 03 Mar 2021 11:09:34 -0500

Martin Thomson <[email-masked]> wrote:
    > What Rich is doing here is good.  SAN is dead and we should ensure that
    > our documentation reflects that.  (Even at the time of 6125 it was a
    > holdover from a previous era.)

I agree.
The question is: how do we hold the funeral and memorial service?
That is, how long is the tail?

https://datatracker.ietf.org/doc/draft-rsalz-use-san/ is short and sweet, and
we could easily publish it pretty much as is, and we'd get somewhere.

It seems that clients must take the first step here.
The major browsers all auto-update, and so if this isn't out there already,
could be out there within six months.
Libcurl is in ubiquitous use out there operating m2m transfers of many kinds.

**It is unclear to me if there is any work to do**

Pretty much all these things already look at SAN, so the lack of CN shouldn't
be an issue, except for some communications out there where there is a SAN missing.
I suspect that this is mostly in the roll-your-own situation.

I'd like the document to give an Implementation or Deployment overview.
This would be particularly useful to re-assure managers about removing CN
from their certificates.

Let me say that it's really frustrated for embedded system builders to wind
up in a situation where they can't get a security patch installed because
moving to the next version has a disconnect like this.
They may require that they update a long-installed system, and they can't get the
server side updated with SAN, because that system is also on a long lifespan
update cycle.

I've watched this both from within a team and outside.
Within the team, I've lost the battle of, "we need to be control our destiny"
argument, i.e. that is "we need to build it all from source so we can
backport patches".   {That team still has Ubuntu Hardy devices in the
field which have no updates in a decade.  Fortunately, the hardware is dying,
and some of the customers have replaced 1000 devices at a time with a
competing solution}

    > Is now the time that we get to talk about other updates to RFC 6125?
    > Because there is no IP-ID reference identity in RFC 6125 and HTTP had
    > to define one just to document what happens in practice:
    > https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#https.ip-id

    > I don't want to get in the way of making actual progress here, but
    > knowing the difficulties with getting 6125 done, it might be safer to
    > do this work in a working group.  I have no opinion regarding whether
    > it is a new one or UTA.

Yeah, "better is the enemy of good enough"
I suggest that we publish https://datatracker.ietf.org/doc/draft-rsalz-use-san/ as is.
I think that it's short enough that AD sponsor is enough.

I suggest that RFC6125 deserves to advance to Internet Standard, and it might
require a revision to get there.  I feel the same way about RFC5280.
LAMPS seems like the right place to do this, but maybe there are other
opinions.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Nico Williams <[email-masked]>
Date: Wed, 3 Mar 2021 10:21:14 -0600

> Wait, what? Do you mean CN?

Question seconded.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 3 Mar 2021 13:11:22 -0500

I did a quick look at what CABForum has on this. They are in the same state.

Given that CABForum has the ability to actually enforce a profile and given
that this has been in place since we EOLed RSA1024, it is highly unlikely
that there are any browsers currently in use that rely on the CN field.

These are the EV guidelines but I doubt anyone does different for DV.

This change should be synchronized with CABForum if people want this
properly dead.

https://cabforum.org/wp-content/uploads/CA-Browser-Forum-EV-Guidelines-v1.7.0.pdf

Contents: If present, this field MUST contain a single Domain Name(s) owned
or controlled by the Subject and to be associated with the Subject’s
server. Such server MAY be owned and operated by the Subject or another
entity (e.g., a hosting service). Wildcard certificates are not allowed for
EV Certificates except as permitted under Appendix F.

On Thu, Feb 4, 2021 at 10:44 AM Salz, Rich <rsalz=
[email-masked]> wrote:

> I would like to present
> https://datatracker.ietf.org/doc/draft-rsalz-use-san/
>
> server; just use subjectAltName.  It also limits where the "*" can go in
> wildcard certificates. This is a simplification of widely implemented
> existing practice. It may even be de facto what's mostly done. Perhaps the
> wildcard limitation is controversial and I'd be willing to remove it.
>
> 6125 was AD-sponsored. I think this could also be, or perhaps it could go
> to UTA. I would not present any slides, and think 10-15 minutes would be
> enough time.
>
>

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 04 Mar 2021 09:38:17 +1100

> Wait, what? Do you mean CN?

Wow, nice proofreading failure.  Yeah. CN is dead.  Long live SAN.

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 04 Mar 2021 09:41:40 +1100

> This change should be synchronized with CABForum if people want this 

I propose we just do this and then tell them.  I can talk to our representative, and we can encourage others to do.  But the BRs are already pretty good on this point.  A motion to expunge the backward-compatibility clause is all they really need to do, but I don't see them as being obligated to do that.  It's OK if they don't.