> On 18 Jun 2016, at 13:59, Viktor Dukhovni <[email protected]> wrote: > > On Sat, Jun 18, 2016 at 01:53:20PM +0800, Aaron Zauner wrote: > >> RFC6844 defines a method by which domain owners can limit the CA allowed >> to issue certificates for their domain. > > Critically, this signalling channel is *exclusively* between the > domain and any CA that might consider issuing a certificate for > the domain. It MUST NOT be used by relying parties. > > Unfortunately, the CA/B forum voted to make support for this > optional, so this standard is stillborn.
Thank you for the information. I'm not very familiar with this standard nor it's history, so that's much appreciated. > >> As far as I can tell this isn't widely implemented in DNS Daemons (KnotDNS >> and Bind9 [urgh]) do have support though. Is this something that might >> make sense including in the MTA-STS document? > > See above, CAA does not apply to relying parties, and has no > relevance to STS. Yea, I *was* thinking it could be mentioned in the security considerations section as additional protection - if that makes sense. So for example: various CDNs and DNS providers offer API's - in Certbot we could interface with them to make sure relevant CAA's are set and protected by e.g. DNSSEC. Just an idea. > >> i.e. one could effectively restrict validation to a certain CA (say for >> example Let's Encrypt). > > One could attempt to ask other CAs to not issue certificate for > one's domain. In practice, this is mostly useless. How would that work? You mail each CA not to issue for your domain and expect that they'll honor your request (also intermediates)? I'm not sure where you're going with that. It doesn't seem like anything that would actually work in the real world and the threat model is just insane. Thanks for the feedback! Aaron
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
