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

[Michael Richardson <[e-mail]>]

Martin Thomson <[e-mail]> 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 <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide