But it also seems reasonable for organisations making CAA assertions to know the scope of their stipulations before they make them, no?
So, if in the case of Yahoo, they make the assertion “All of our web certificates should come from DigiCert”, are they aware that they are also making the statement “And all of our user mail accounts should only be granted S/MIME certificates from DigiCert too”. Perhaps they are, perhaps not, but I’m willing to bet that a fair number of Yahoo accounts have S/MIME certificates not issued by DigiCert - a shift to CAA-S/MIME enforcement could cause some unwelcome disruption to Yahoo’s customers. Please note: I’m not opposed to CAA stipulations applying to S/MIME. I would just want all participants in the PKI world to know what their statements mean and how far they reach. Since the syntax of CAA is extensible, perhaps ‘issue’ could indeed be restricted to TLS certificates, and a newer tag ‘issueall’ be taken to mean ‘covering all possible forms of certificates’? Just a thought, Neil > On 14 May 2018, at 08:39, Ryan Sleevi via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > 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 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
