Yes, but as you correctly point out, this should be taken care of as part of the CAA-bis effort. The original RFC had enough errors with respect to web certificates; I think it would be irresponsible to apply it to e-mail certificates right now without carefully considering the consequences.
With CABF governance reform coming into effect on July 3rd, I'm cautiously optimistic we can start writing requirements for e-mail certificates and phasing out bad practices and phasing in good practices soon. CAA for e-mail certificates is definitely worth considering as part of that process. Slightly higher priority is making sure authenticated encryption modes are used with S/MIME, so people can't play silly games with CBC and harvested ciphertexts. Everything really needs to start transitioning away from CBC ... but I digress. -Tim > -----Original Message----- > From: dev-security-policy [mailto:dev-security-policy- > bounces+tim.hollebeek=digicert....@lists.mozilla.org] On Behalf Of Ryan > Sleevi via dev-security-policy > Sent: Monday, May 14, 2018 11:39 AM > To: Pedro Fuentes <pfuente...@gmail.com> > Cc: mozilla-dev-security-policy > <mozilla-dev-security-pol...@lists.mozilla.org> > Subject: Re: question about DNS CAA and S/MIME certificates > > 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-pol...@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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
