There's a lot of contradictory statements here, so I'm not sure how best to unpack them.
"I think CAA is and should be HTTPS only" is inconsistent, it seems, with https://groups.google.com/d/msg/mozilla.dev.security.policy/NIc2Nwa9Msg/PZgO5Qe0CQAJ "There isn't much value to CAA if only a few CAs do it" seems inconsistent with "another RFC explaining CAA for email" - rough consensus and running code. I agree that it's useful to determine what the priorities should be. CAs' CP/CPS can document today what they do with CAA in S/MIME. CAA, as written today, absolutely can support email. In an ideal world, CAs would take the maximally restrictive approach to issuance, recognizing that domain operators have primacy over their domains compared to any other entity within their management authority, and that necessarily includes e-mail. I do not think it's at odds with the LAMPS charter for 6844-bis, because I do not think it's at odds with 6844. That said, this is all largely moot, because CAs have strong incentives to not do anything with CAA until they're forced to, and to try to make it someone else's problem as much as possible (passing the buck between CABF, IETF, and root stores for S/MIME), and in the mean time, site operators lose because unless and until CAs do something about it, there's no way they can restrict S/MIME issuance, and thus there's fundamentally questionable value to S/MIME issuance today. To the extent CAs want to cut off their nose to spite their face, I suppose that's their prerogative. The principle at play here, though - that CAA is not an intent to do exactly what it says, which is restrict the issuance of certificates bearing that domain (in all forms), is deeply troubling for any future PKIs, and merely shows the trouble with reliance on third-party CAs in any new PKIs. On Tue, May 15, 2018 at 3:42 PM, Tim Hollebeek <[email protected]> wrote: > I think CAA is and should be HTTPS only until there are clear rules for > how it should work for email, and how to keep web CAA from interfering with > email CAA. E-mail is currently the wild west and that needs to be fixed. > > > > I’m strongly in favor of email CAA, once we get it ‘right’. But there’s > no document out there that specifies what ‘right’ is yet. And there isn’t > much value to CAA if only a few CAs do it. > > > > That’s why I think we need 8644-bis first. Or another RFC explaining CAA > for email. > > > > -Tim > > > > *From:* Ryan Sleevi [mailto:[email protected]] > *Sent:* Tuesday, May 15, 2018 12:44 PM > *To:* Tim Hollebeek <[email protected]> > *Cc:* [email protected]; Pedro Fuentes <[email protected]>; > mozilla-dev-security-policy <[email protected] > > > *Subject:* Re: question about DNS CAA and S/MIME certificates > > > > Tim, > > > > Could you clarify then. Are you disagreeing that CAA is HTTPS only? As > these were your words only 3 hours ago - https://groups.google.com/d/ > msg/mozilla.dev.security.policy/NIc2Nwa9Msg/0quxT0CpCQAJ > > > > On Tue, May 15, 2018 at 12:28 PM, Tim Hollebeek < > [email protected]> wrote: > > Blatantly false. I actually suspect DigiCert might already support CAA > for email. I haven’t double-checked. > > > > -Tim > > > > The only reason that "CAA is HTTPS-only" today is because CAs are not > interested in doing the 'right' thing. > > > > > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
