On Fri, Jan 19, 2018 at 11:06 AM, Peter Bowen via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > For a certificate capable of being used for SSL-enabled servers, the CA > must ensure that the applicant has registered the domain(s) referenced in > the certificate or has been authorized by the domain registrant to act on > their behalf. This must be done using one or more of the 10 methods > documented in section 3.2.2.4 of version 1.4.1 (and not any other version) > of the CA/Browser Forum Baseline Requirements. The CA's CP/CPS must clearly > specify the procedure(s) that the CA employs, and each documented procedure > should state which subsection of 3.2.2.4 it is complying with. Even if the > current version of the BRs contains a method 3.2.2.4.11, CAs are not > permitted to use this method.” > > While this clearly does call out that the methods are acceptable, it isn’t > a results oriented statement. The BRs also do not have clear results > requirements for validation methods. > > What does Mozilla expect to be verified? We know the 10 methods allow > issuance where "the applicant has registered the domain(s) referenced in > the certificate or has been authorized by the domain registrant to act on > their behalf” is not true. > > I also think it may make sense for the root program policy to illuminate specifically the nature and parameters of a successful outcome.
Maybe it's something like: The validation is properly achieved when it 1) aligns to one of the permitted BR validation mechanisms AND 2) successfully achieves the various other goals that the program has. Things like "provides reasonable assurance that the issuance will be granted only to a party demonstrating ownership or effective control of the related domain". It's not clear today, absent further guidance, that the Mozilla root program policy would call on a CA to preemptively stop utilizing a compromised mechanism which is BR compliant prior to change of the BR. If the program were changed such that one of the outcomes to be considered at the time of the validation is that the CA, via technical means, has strong assurance that the issuance is to a party owning or controlling the domain in question, then a publication of a vulnerability over a certain validation method would certainly strike the CA's confidence in that assertion and so guide that the validation can not be considered proper for reliance for issuance. Incorporating intended outcomes of the policies related to validation and issuance pursuant to validations may be helpful in providing a default, "automatic" guidance on how to handle an emerging vulnerability of a previously acceptable method. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
