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 <[email protected]
<mailto:[email protected]>> 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
[email protected]
https://cabforum.org/mailman/listinfo/public
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
