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.
* 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.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
