> On 19 May 2017, at 3:43 pm, Ryan Sleevi <[email protected]> wrote: > > How does that fit with the quoted Section 4.1.2? > > "The certificate request MUST contain a request from, or on behalf of, > the Applicant for the issuance of a Certificate, and a certification by, or > on behalf of, the Applicant that all of the information contained therein is > correct.”
4.1.2 starts with “Prior to the issuance of a Certificate”. So, at some point before the certificate issues, 4.1.2 needs to be satisfied. There’s no ordering between that and the validation requirements in the BRs. > 1) If there is no certificate request, is there an Applicant at the time the > CA begins validating information? A validation is only relevant to the BRs if it leads to a certificate issuance. A certificate issuance must only occur after a certificate request which implies the existence of an Applicant to get the certificate request from. So, yes, there must have been an Applicant. The CA may not have known who. > 2) If there is no certificate request, and/or there is no Applicant, how is > the information the CA validated conforming with Section 3.2, which Section > 4.2.1 references? There is always an Applicant and there must be a certificate request, see above. > Those are two reasons why I do not believe the scenario is permitted. Those weren’t reasons, they were questions… > On Fri, May 19, 2017 at 6:37 PM, Geoff Keating <[email protected] > <mailto:[email protected]>> wrote: > Hi Ryan, > > I don’t think there’s anything in the BRs that says that particular > validation steps must happen before other steps, so long as the appropriate > time limits are honored. Your example where a CA finds an existing > certificate for a prospective customer, validates everything in that > certificate (for example checking domain name against organization name using > whois), and then contacts the prospective customer (for example, via postal > address in company registration, matched against whois) and asks if they’d > like a replacement certificate and if all the details are correct, seems > permitted to me. > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
