On Fri, May 19, 2017 at 7:48 PM, Geoff Keating <[email protected]> wrote:
> > 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. > Section 1.6.1 Applicant: The natural person or Legal Entity that applies for (or seeks renewal of) a Certificate. Once the Certificate issues, the Applicant is referred to as the Subscriber. For Certificates issued to devices, the Applicant is the entity that controls or operates the device named in the Certificate, even if the device is sending the actual certificate request. Applicant Representative: A natural person or human sponsor who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant: (i) who signs and submits, or approves a certificate request on behalf of the Applicant, and/or (ii) who signs and submits a Subscriber Agreement on behalf of the Applicant, and/or (iii) who acknowledges the Terms of Use on behalf of the Applicant when the Applicant is an Affiliate of the CA or is the CA. Certificate Data: Certificate requests and data related thereto (whether obtained from the Applicant or otherwise) in the CA’s possession or control or to which the CA has access. Within the context of domain validation, Section 3.2.2.4, all of the means of validating are stated in the context of the request. Except for 3.2.2.4.11 (... of course). Within the context of IV, Section 3.2.3 is gated on a request. Within the context of OV, Section 3.2.5 is gated on a request. Further, within that quoted section, as I replied to Ben, while I agree that the totality of information gathered in 4.1.2 can happen asynchronously, I am suggesting that the definition in 4.1.2 constitutes the minimum information necessary for a request - namely, the information to be added and an attestation that said information is correct. The CA is permitted to add additional information (c.f. Section 4.2.1), but there's some initial aspect that constitutes "a request", and represents an immutable set due to the conjunctive requirements. > 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. > I don't think there's been any disagreement about that - but rather, whether or not 'pregathering' of unknown data is permitted. > 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. > But at the time the CA is validating the information, there is no Applicant or Request, as per the original message.
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
