[cabfpub] Preballot - Revised Ballot 190

Ryan Sleevi sleevi at google.com
Fri May 19 23:31:32 UTC 2017

On Fri, May 19, 2017 at 7:12 PM, Ben Wilson <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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170519/9b45fdd8/attachment-0003.html>

More information about the Public mailing list