On Mon, Mar 15, 2021, 2:59 AM Eliot Lear <lear=40cisco....@dmarc.ietf.org> 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.
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. > > 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. 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 _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
