[cabfpub] Preballot - Revised Ballot 190

[Ryan Sleevi]

On Fri, May 19, 2017 at 7:48 PM, Geoff Keating <geoffk at apple.com> wrote:

>
> On 19 May 2017, at 3:43 pm, Ryan Sleevi <sleevi at google.com> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170519/097a6cb4/attachment-0001.html>