> On May 19, 2017, at 5:13 PM, Ryan Sleevi <[email protected]> wrote:
>
>
>
> On Fri, May 19, 2017 at 7:52 PM, Peter Bowen <[email protected]
> <mailto:[email protected]>> 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
> Certificate."
>
> 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 it).
>
>
> 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 establishes:
> - 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 3.2.2.4)
>
> Is that a correct summary of the difference?
There is another way to look at it. Applicant is a defined term that is
basically a pronoun. It is reasonable to replace the capitalized “Applicant”
with a specific natural person or legal entity. So the 3.2 validations can be
performed against a specific legal entity — e.g. Aperture Science, Inc. Given
that completed validations can be reused, it stands that one could validate
that Aperture Science, Inc. controls example.com <http://example.com/>, then
use that later to issue a certificate. I think you are getting hung up on a
concept that the only way to resolve “Applicant” to a specific entity is via
the Applicant submitting a certificate request. I don’t see anything that
forbids a CA from validating that a natural person or legal entity controls a
domain or exists outside of a request then reusing that to satisfy a future
future validation request.
Thanks,
Peter
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
