[cabfpub] Preballot - Revised Ballot 190

Ryan Sleevi sleevi at google.com
Fri May 19 22:25:43 UTC 2017


I think the question is not whether it's "common", it's whether and where
it's even permitted :)

I mentioned the sections that define what constitutes what an Applicant
must suggest as part of a certificate request, and a certificate request is
what makes them an applicant. It sounds like the suggestion being made here
is that 'part' of a certificate request can be submitted, and then, later,
and some other point, the 'full' certificate request can be made, thus
meeting the obligations.

My point, particularly in the context of Section 4.1.2, is what constitutes
the absolute minimum for a request. 4.1.2 spells out a certain minimum,
namely:
"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."

Do you believe that your Step 1.a meets this obligation, thus making the
list of domains a Certificate Request?
If so, what do you call the thing they submit in Step 3?
If not, what do you believe permits Step 2 from starting, if a valid
Certificate Request is not required?

This is how you get into the situation I provided, which I think is an
important question to answer, since it logically emerges as permitted, if
the "Certificate Request" is not done until Step 3, but you can begin
validating in Step 2. There's nothing, for example, to prohibit you from
starting Step 4 before Step 3 - and, indeed, Section 4.2.1 explicitly
permits the CA to obtain that information independent of the customer's CSR
- specifically:

"In cases where the certificate request does not contain all the necessary
information about the Applicant, the CA SHALL obtain the remaining
information from the Applicant or, having obtained it from a reliable,
independent, third‐party data source, confirm it with the Applicant."

Or, put differently, based on what you described as "common practice", if
we accept that it's also "permitted" practice, then it's fully permitted to
reorder the sequence you describe as:

4 – CA completes any remaining validation steps and verifies that process
has not exceeded any applicable timeframes

1 –         a. Customer signs a contract with domains listed therein, or

b. signs up for an account, obtains a username/password and submits domain
names.

2 – CA starts the domain validation process
3 – Customer submits CSR
5 – CA issues certificate

Is it clear how I arrive at that conclusion?

On Fri, May 19, 2017 at 6:15 PM, Ben Wilson <ben.wilson at digicert.com> wrote:

> Pre-validation is a common practice.  Here is scenario:
>
>
>
> 1 –         a. Customer signs a contract with domains listed therein, or
>
> b. signs up for an account, obtains a username/password and submits domain
> names.
>
> 2 – CA starts the domain validation process
>
> 3 – Customer submits CSR
>
> 4 – CA completes any remaining validation steps and verifies that process
> has not exceeded any applicable timeframes
>
> 5 – CA issues certificate
>
>
>
> *Ben Wilson, JD, CISA, CISSP*
>
> VP Compliance
>
> +1 801 701 9678 <(801)%20701-9678>
>
>
>
> *From:* Public [mailto:public-bounces at cabforum.org] *On Behalf Of *Ryan
> Sleevi via Public
> *Sent:* Friday, May 19, 2017 4:08 PM
> *To:* Peter Bowen <pzb at amzn.com>
> *Cc:* Ryan Sleevi <sleevi at google.com>; CA/Browser Forum Public Discussion
> List <public at cabforum.org>
> *Subject:* Re: [cabfpub] Preballot - Revised Ballot 190
>
>
>
>
>
>
>
> On Fri, May 19, 2017 at 6:00 PM, Peter Bowen <pzb at amzn.com> wrote:
>
> Yes, it does.  We know that CAs can generate keys on behalf of the
> subscriber, so it is clear that a public key is not required.  This means
> that a CA could take the request for “issue a certificate to example.com”,
> do validation and key generation, throw away the private key, issue the
> cert, and end up with a “pre-validated” domain.  This is compliant.  The
> generated cert could have some flag in it, similar to a pre-cert, that
> makes it unusable for any real world purpose, and it would still be fine.
> But this is silly.  We don’t want to have hoop jumping for no discernible
> value.
>
> Can you suggest a change that you feel would make it clear that CAs may
> validate identities (organizations, domains, etc) independent of issuing
> certificates and use the documents and data gathered during such validation
> for future issuance, subject to the aging requirement of 4.2.1?  I would
> suggest a change myself, but I’m not quite clear which part of the BRs you
> feel prevents this today.
>
>
>
> The BRs are gated on the concept of an Applicant - all of the validation
> is done in concert and connection with an Applicant.
>
>
>
> I'm not sure how it makes sense for CAs to have, say, a prevalidated set
> of organizations, any of which can apply and thus reuse the information.
>
>
>
> Put differently: Do you think it would be BR conformant if a CA looked
> through CT, determined which organizations had OV/EV certs, worked through
> QIIS/QGIS's to 'prevalidate' the organizational information related to it,
> and then approached all customers with the remark "We can give you a
> certificate in 30 seconds?"
>
>
>
> It may be that the answer is yes - that the extent of the CAs obligations
> (to validate the documents and domain, in absentia of an Applicant) are met.
>
> It may be that the answer is no - that a CA cannot begin doing some form
> of validation until contacted by an Applicant.
>
>
>
> But I think understanding the specific answer to this scenario can help
> inform whether or not an "Applicant" is required to make a certificate
> request before being, well, an "Applicant".
>
>
>
> If they are required to make a request, then naturally, it follows that
> your so-called hoop-jumping is necessary, since there is a minimum
> definition of what constitutes a certificate request.
>
> If they are not required to make a request, then naturally, the scenario I
> described is the logical extreme, in which the CA can validate 'everything
> but the application'. To further add to the extreme, it might be possible
> for the CA to pre-generate the public key, and just call up the subscriber
> and say "Do you want a cert" - with that assent being sufficient to
> constitute an "Application"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170519/ce6fe93e/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 6118 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170519/ce6fe93e/attachment-0003.jpg>


More information about the Public mailing list