[cabfpub] Preballot - Revised Ballot 190

Ryan Sleevi sleevi at google.com
Sat May 20 00:13:47 UTC 2017

On Fri, May 19, 2017 at 7:52 PM, Peter Bowen <pzb at amzn.com> wrote:

> There is no reason a CA couldn’t pull public records based on info in CT
> to help expedite things (for example identifying the company registration
> number), but the validation still has to happen. You can’t finalize the
> validation without binding it to a legal entity who will be the
> applicant/subscriber.  It is possible that this validation could use
> records pulled by the CA prior to the request for validation.

And this goes back to the initial question you posed that kicked this all
off, namely:
"I think some have suggested that the BRs don’t allow this alternative
order of operations, but I’m having a little trouble finding the specific
cite.  Do you, Ryan, or does anyone else, think the order of operations
described above is not valid?"

To tie this all back together: Section 4.2.1 only permits the reuse of
information gathered in context with Section 3.2:
"The CA MAY use the documents and data
provided in Section 3.2 to verify certificate information, provided that the
CA obtained the data or document
from a source specified under Section 3.2 no more than thirty‐nine (39)
months prior to issuing the

Section 3.2 is tied to what the Applicant is requesting in the certificate:

So for there to be information to be reused, it needs to be obtained in the
context of an Applicant.

And so the question is whether or not there can be an Applicant prior to a
Certificate Request.

Section 1.6.1 establishes the Applicant as: "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. "

I'm sure we can get into the game of debating whether 'applies for' is
distinct from 'requests' (although I think that's not supported by the text
itself, by virtue of the following sentence, but I'm sure we can misread

You asked if there was a reason to suggest the ordering must be different.
My minimal suggestion was that the order must be:

- A Request, which includes the attestation of correctness (per 4.1.2)
- which establishes an Applicant (per 1.6.1)
- which then permits validation of the Applicant information (per 3.2)
- which can then be reused for subsequent Requests (per 4.2.1)

It would seem that you are advocating for an interpretation that
- An Applicant (by virtue of establishing an Applicant Representative - the
party who has signed the Subscriber Agreement on behalf of the Applicant /
acknowledges the TOU, per 1.6.1)
- which then permits validation of the Applicant information (per 3.2)
- Which then permits one or more Requests (per 4.1.2)
- Which then allows the validated information to be reused (per 4.2.1), or
the reuse of a previously completed validation (per

Is that a correct summary of the difference?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170519/448dd389/attachment-0003.html>

More information about the Public mailing list