On 8/19/14, 10:41 AM, Viktor Dukhovni wrote:
On Tue, Aug 19, 2014 at 10:33:16AM -0600, Peter Saint-Andre wrote:
Section 6:
I think it would help implementors to explain a bit more detail -
that if you have multiple names in the cert, one could be the CN and
the others Subject Alt Names.
According to the SIP domain cert RFC the CN should be disregarded and
NOT used if there are any SANs. I don't know the reasoning behind
this. Anyone? Should we do that here too or just forget it?
I'd prefer to leave identity verification rules up to RFC 6125 or the
application-specific equivalent. There's a reason why RFC 6125 ended up at
57 pages...
DANE with SRV (as also DANE with MX) is sufficiently different that
the 6125 rules can and should be revised.
I have ~15 active Internet-Drafts to finish off before I start work on
6125bis. ;-)
* The TLSA base domain is the preferred reference identifier
* While treatment of wildcards, ... is application-specific per
6125, the choice of reference identifier with DANE needs to
recognize the fact that historically SRV lookups were not
DNSSEC protected, and so applications (that cared about
security, rather than merely went through the motions) needed
to verify the input domain not the SRV host.
* Therefore, for backwards-compatibility with UCC certs, ...
Tony correctly recognized the need to allow either the SRV
hostname (which is now secure and is generally the TLSA base
domain) or the legacy input domain. The OPS draft also
recomments the CNAME expanded version of the input domain.
You can probably reference the OPS draft for some of this, and clone
the rest from the SMTP draft.
Noted!
Peter
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
