[cabfpub] Preballot - Revised Ballot 190
Moudrick M. Dadashov
md at ssc.lt
Fri May 19 23:55:44 UTC 2017
The initial process looks like this:
a. A potential customer requests a service;
b. CA authenticates the potential customer, checks its
authorization to represent the Subject (if not Subject);
c. The CA makes a decision whether or not the potential
customer is an Applicant;
d. The CA provides the Applicant with order processing
environment (login/password etc.).
Thanks,
M.D.
On 5/20/2017 2:31 AM, Ryan Sleevi via Public wrote:
>
>
> On Fri, May 19, 2017 at 7:12 PM, Ben Wilson <ben.wilson at digicert.com
> <mailto:ben.wilson at digicert.com>> wrote:
>
> With regard to timing and the sequence of events, I would think
> that it shouldn’t matter too much as long as the steps comply with
> and meet the Baseline Requirements. In other words, a CA should
> take steps to ensure that the applicant has control of the private
> key, that the applicant owns or controls the domain/FQDN, that the
> Applicant has made the request for a certificate, etc. This is
> supported by the fact that the certificate request only has to be
> collected “prior to the issuance of a Certificate”. BR § 4.1.2.
>
>
> I'm trying to highlight a potential problem with your interpretation.
>
> It would appear that you're interpreting the following:
> "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."
>
> As meaning that those two events - the request from or on behalf of,
> and the certification - as separately collectable items. Is that correct?
>
> Whereas I'm arguing for the interpretation that says that a
> certificate request is defined by the provision of those two elements
> - a request from an Applicant for the issuance of a certificate, and a
> certification on behalf of the Applicant that all of the information
> _in the request_ is correct. Absent those two necessary items, a
> Certificate Request has not been made.
>
> Since an Applicant is defined as one who makes a Certificate Request,
> and Section 3.2 applies to the validation of said request, then in the
> absence of such a request, there can be no 'pre' validation.
>
> This is why I asked the earlier questions I asked (regarding what is
> the thing collected in "Step 1.a" and what is the thing collected in
> "Step 3"). If 1.a is the formal request, then what is the thing in 3?
> That is, is it a new request? If the request is not made until the
> data in both 1.a and 3 are together, then step 2 is an example of the
> CA beginning validation before a request - and as such, can be
> reordered in the manner I described.
>
> Finally, if your argument is that under section 4.1.2 an Applicant
> can’t attest to the accuracy of information not yet
> completed/collected, then what about the fact that the CA is given
> discretion to define the forms by which information is
> collected? Another part of section 4.1.2 allows this
> flexibility-- “Prior to the issuance of a Certificate, the CA
> SHALL obtain from the Applicant a certificate request in a form
> prescribed by the CA and that complies with these Requirements.”
> This latter provision could be improved by stating “in a form and
> manner …”.
>
>
> I'm not sure I understand your argument here. The applicant MUST
> attest to what's requested in 4.1.2, but the CA MAY include additional
> information (that the Applicant did NOT request) pursuant with 4.2.1.
>
> It sounds like you're believing that the CA needs to obtain a
> certification "that all of the information contained therein is
> correct" applies to the certificate, whereas I'm reading it as
> applying the request. Is that correct?
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170520/4a190a08/attachment-0003.html>
More information about the Public
mailing list