On Wed, Jul 31, 2019 at 05:08:42AM -0400, Viktor Dukhovni wrote: > On Tue, Jul 30, 2019 at 11:16:25PM -0700, Jim Fenton wrote: > > > The RFC 7672 definition of Reference Identifier includes the CN-ID, so it > > would be more consistent to include it when referencing 6125 as well. > > For the record, RFC7672 has aged a bit since ~2014 when most of it > was written, so at some point support for CN-ID could be reconsidered.
Sure. It doesn't really have to be this document, though -- thanks to Jim for pointing out the RFC 7672 precedent. > In that light, I took a look at the certificates currently live on > MX hosts found by the DANE survey, and of 854 certificates on MX > hosts that use DANE-TA records (for which name checks are in scope) > 22 have CN-ID and no SAN. That may be too high a rate to pull the > plug just yet. :-( That seems likely; I don't feel a particular need to introduce skew between reality and the text of the specification. I guess, if the WG wants, we could recommend SRV-ID but still allow CN-ID (but this really is up to the WG and it is not part of a Discuss point given the 7672 precedent). -Ben > One notable example is the state of Bavaria: > > bayern.de. IN MX 10 mail.bayern.de. ; NoError AD=1 > _25._tcp.mail.bayern.de. IN TLSA 2 0 1 > 32a2bc1d515cdbc412b62b47a1cccf2bb1b8e3ef309f982458d3a7c61797422a ; NoError > AD=1 > cert sha256 [matched] <- 2 0 1 > 32a2bc1d515cdbc412b62b47a1cccf2bb1b8e3ef309f982458d3a7c61797422a > cert sha256 [matched] <- 2 0 1 > 32a2bc1d515cdbc412b62b47a1cccf2bb1b8e3ef309f982458d3a7c61797422a > > which sports a V1 cert (no extensions, hence no SANs). The issuer > looks like a private CA: > > C = DE > ST = Bayern > O = Freistaat Bayern > CN = Bayerische DANE-CA > > -- > Viktor. > _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
