Disingenuous seems like an unreasonable stretch. By the logic expressed here, applying CAA enforcement to HTTPS was applying CAA "after the fact" - after all, until CAs were required to enforce CAA, how do we know that domains (... such as google.com or opera.com) meant to restrict server certificate issuance? Couldn't they have been (in this poor stretch of logic) trying to restrict issuance of S/MIME certificates instead?
That's why the argument makes no sense. As to rfc822 names not being mapped onto DNS, that's just definitionally inaccurate. RFC822 names include a domain component. The addr-spec is local-part "@" domain. With domain being the routable definition that we all know and love. You can't just pretend that's not part of the scoping or authority here. On Tue, May 15, 2018 at 12:06 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > It is disingenuous to apply CAA to S/MIME and other certificate purposes > after the fact. > > As a domain holder myself, having implemented CAA in certain domains, I did > intent to restrict issuance of server certificates. I have never intended > this to be a restriction of S/MIME certificate issuance. The name spaces > are different for email addresses versus DNS names. CAA aligns cleanly to > DNS names. It does not align cleanly to rfc822 names. > > Mr. Sleevi's complaints regarding fail-open security are reasonable. > However, they seem misplaced within the scope of CAA, which at the most > basic level is a fail-open mechanism: lack of a CAA record assumes all > issuance allowed. > > Reinterpreting the scope of extant CAA records might well have a chilling > effect on further adoption of CAA. > > When an expressed intent such as CAA has (by definition OR by real-world > effect) a limited scope, many participants will not appreciate that scope > being expanded. > > I believe the "issue" and "issuewild" tags should be regarded as pertaining > only to certificates which either 1) lack any EKU OR 2) include either > anyPurpose EKU or serverAuth EKUs. > > > > On Tue, May 15, 2018 at 10:57 AM, Neil Dunbar via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > > > On 15 May 2018, at 07:59, Matthew Hardeman <mharde...@gmail.com> > wrote: > > > > > > For that matter, can whoever is in charge of gmail.com < > > http://gmail.com/> speak to their intent as to CAA for S/MIME? > > > > > > I've certainly held certificates which include my personal gmail > address > > before. At no point did I need or seek Google's blessing to do so. I > can > > not imagine that was an uncommon case. (At least, not uncommon relative > to > > the universe of issued S/MIME certificates.) > > > > Well, I don’t see a CAA record for gmail.com <http://gmail.com/>, thus > > even if CAA issue tags were reinterpreted, as suggested, to cover S/MIME, > > such issuance would not be prohibited (unlike, say, google.com < > > http://google.com/>, which does have a CAA record). > > > > In other words, those certificates that you were issued hitherto could > not > > have violated CAA policy, since there was no such expression of policy. > > > > Regards, > > > > Neil > > _______________________________________________ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy > > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
