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
