[cabfpub] Preballot - Revised Ballot 190

Jeremy Rowley jeremy.rowley at digicert.com
Sat May 20 15:17:50 UTC 2017


Okay – but even if A-C is required, why is pre-validation not allowed under your interpretation?

 

A) A request from, or on behalf of, the Applicant for the issuance of a certificate

- Applicant signs a contract, submits a domain name where they want a cert, but doesn’t give a date when the cert will issue.

B) A certification by, or on behalf of, the Applicant that all of the information contained therein [in the request] is correct

- Applicant certifies that all the information is correct. However, information can be added after, such as the date when the cert will issue.

C) At least one Fully-Qualified Domain Name or IP address to be included in the Certificate's SubjectAltName extension

- Already submitted as part of the request.

 

 

 

 

From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Saturday, May 20, 2017 8:52 AM
To: Jeremy Rowley <jeremy.rowley at digicert.com>
Cc: CA/Browser Forum Public Discussion List <public at cabforum.org>
Subject: Re: [cabfpub] Preballot - Revised Ballot 190

 

 

On Sat, May 20, 2017 at 10:41 AM, Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> > wrote:

 

 

On Fri, May 19, 2017 at 9:47 PM, Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> > wrote:

“The certificate request MAY include all factual information about the Applicant to be included in the Certificate, and such additional information as is necessary for the CA to obtain from the Applicant in order to comply with these Requirements and the CA’s Certificate Policy and/or Certification Practice Statement.”

*	This indicates a certificate request may include partial information.

I appreciate you mentioning this - as I've mentioned it several times - but this doesn't address the concern related to 4.1.2

 

Apologies, that sent too soon.

 

Let's look at 4.1.2 and 4.2.1 combined:

 

>From 4.2.1:

The certificate request MAY include all factual information about the Applicant to be included in the Certificate, and such additional information as is necessary for the CA to obtain from the Applicant in order to comply with these Requirements and the CA’s Certificate Policy and/or Certification Practice Statement. 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. The CA SHALL establish and follow a documented procedure for verifying all data requested for inclusion in the Certificate by the Applicant.

 

Applicant information MUST include, but not be limited to, at least one Fully‐Qualified Domain Name or IP address to be included in the Certificate’s SubjectAltName extension.

 

>From 4.1.2

Prior to the issuance of a Certificate, the CA SHALL obtain the following documentation from the Applicant:

1. A certificate request, which may be electronic; and

2. An executed Subscriber Agreement or Terms of Use, which may be electronic.

 

The CA SHOULD obtain any additional documentation the CA determines necessary to meet these Requirements

 

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. One certificate request MAY suffice for multiple Certificates to be issued to the same Applicant, subject to the aging and updating requirement in Section 3.3.1, provided that each Certificate is supported by a valid, current certificate request signed by the appropriate Applicant Representative on behalf of the Applicant. The certificate request MAY be made, submitted and/or signed electronically. 

 

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. 

 

 

>From these two, it's important to note what constitutes a request:

A) A request from, or on behalf of, the Applicant for the issuance of a certificate

B) A certification by, or on behalf of, the Applicant that all of the information contained therein [in the request] is correct

C) At least one Fully-Qualified Domain Name or IP address to be included in the Certificate's SubjectAltName extension

 

Are we at least in agreement that these three represent the _minimum_ necessary and sufficient conditions to constitute "A Request"?

 

Further, a Request MAY, but not necessarily, "include all factual information about the Applicant to be included in the Certificate". "In cases where the certificate request does not contain all the necessary information about the Applicant", the information requested by the Applicant is not part of the Request, and "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."

 

Hopefully this establishes that CAs MAY include additional information, in addition to the Request.

 

 

Are we in agreement so far, at least with this?

 

This leads to two possible interpretations:

1) A Request is only made when A-C are present. Until such time, a Request has not been made. Because a Request has not been made, an Applicant does not exist. Because an Applicant does not exist, the information cannot be validated pursuant to Section 3.2

2) A Request can be made without any of A-C present, on the basis that it's possible to omit all three of these, because it is a "case where the certificate request does not contain all the necessary information about the Applicant". That is, there is no such requirement for a Request for there to be an Applicant - an Applicant is simply an idea - and the CA can gather information about parties, validate them, and - provided they gather A-C at some point prior to the issuance of a certificate - issue a certificate.

 

Is it at least clear how we can reach these two interpretations?

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170520/3af8645a/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170520/3af8645a/attachment-0001.p7s>


More information about the Public mailing list