It seems perfectly reasonable and desirable to require that CAs, regardless of the type of certificate they are issuing, respect CAA.
If an email provider wishes to restrict some types of certificates (e.g. HTTPS) while allow others (e.g. S/MIME), this could be accomplished through additional expressions within the CAA syntax. However, it would be a long-lasting, and tragic mistake if CAA was presumed to 'only' apply to HTTPS - because it would make the same mistake of nameConstraints - namely, everything that is not expressly listed as permitted/restricted is implicitly permitted - rather than doing what security practitioners have long known is the safe and secure base - forbid unless expressly permitted (default-deny). In terms of order of concerns and constituents, the domain holders needs and security goals outweigh those of the notion of users 'owning' an email address. On Mon, May 14, 2018 at 3:45 AM, Pedro Fuentes via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Just to say that looking at this from Europe, I don't see this feasible. > > Citizens getting their personal eIDAS-compliant certificate go through > face-to-face validation and will give virtually any valid e-mail address to > appear in their certificate. > > El sábado, 12 de mayo de 2018, 2:30:58 (UTC+2), Wayne Thayer escribió: > > I created a new issue suggesting that we add this requirement to Mozilla > > policy: https://github.com/mozilla/pkipolicy/issues/135 > > > > On Wed, May 9, 2018 at 4:59 PM Ryan Sleevi via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > > > On Wed, May 9, 2018 at 11:47 AM, Adrian R. via dev-security-policy < > > > dev-security-policy@lists.mozilla.org> wrote: > > > > > > > Hello, > > > > this question is somewhat outside the current Baseline Requirements, > > > but... > > > > > > > > wouldn't it be normal for the same CAA rules for server certificates > to > > > > also apply to client certificates when the email address is for a > domain > > > > that already has a valid CAA policy published in DNS? > > > > > > > > > > > > RFC 6844 doesn't seem to make any distinction between server and > S/MIME > > > > client certificates, it combines them together by referring to > > > certificates > > > > "for that domain" as a whole. > > > > > > > > > > > > i tested this last night - i obtained an email certificate from one > of > > > the > > > > CAs participating here (not for this exact address though) and it was > > > > happily issued even if CAA records authenticated by DNSSEC do not > allow > > > > their CA to issue for this domain. > > > > > > > > Now, this is technically not a mis-issuance because it was a proper > > > > email-validated address and their CPS says that CAA is only checked > for > > > > server-type certificates. It doesn't say anything about CAA > validation > > > for > > > > such client certificates. > > > > > > > > I got in touch with them and they seemed equally surprised by such > > > > intended use case for CAA, so my second question is: is anyone > actually > > > > checking CAA records for client certificates where an email address > is > > > > included in the certificate subject info and the EKU includes Secure > > > Email? > > > > > > > > > > > > Or is CAA usually checked only for server-type certificates, even if > RFC > > > > 6844 refers to certificates "for that domain" as a whole? > > > > > > > > > > CAs are generally only checking CAA when they're required to in order > to be > > > trusted. > > > > > > Right now, CAs are only required to check CAA for server-type > certificates > > > (by virtue of the Baseline Requirements Section 3.2.2.8). > > > CAs are not presently being required to check CAA for e-mail. They > can, but > > > they are required to do it, so they are unlikely to do it. > > > _______________________________________________ > > > 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
