[cabf_validation] Gerv's ballot

Thu Feb 23 10:54:35 MST 2017

Jeremy,

                The text for the example of a request token has become
mangled by copying and pasting.

It should read..

echo `date -u +%Y%m%d%H%M` `sha256sum <r2.csr` | sed "s/[ -]//g"

Those back-quotes need to be back-quotes.

Robin

From: Validation [mailto:validation-bounces at cabforum.org] On Behalf Of
Jeremy Rowley via Validation
Sent: 23 February 2017 07:22
To: CA/Browser Forum Validation WG List <validation at cabforum.org>; Wayne
Thayer <wthayer at godaddy.com>
Cc: Jeremy Rowley <jeremy.rowley at digicert.com>
Subject: Re: [cabf_validation] Gerv's ballot

Here’s the proposed ballot on this. I’ve added it as ballot 190. Note that
I have not added any of the ballot language around it yet. Just wanted to
get feedback first.

Ballot 190 - Add validation method 1 and 8 along with minor corrections

This ballots adds methods 1 and 8 back into the baseline requirements (as
they are not subject to disclosure statements) and fixes some redundancies
and errors in the previous draft.

Motion Begins

-----

A. Effective immediately, replace Section 3.2.2.4.1 of the Baseline
Requirements with the following:

'''3.2.2.4.1 Validating the Applicant as a Domain Contact.'''

Confirming the Applicant's control over the FQDN by validating the Applicant
is the Domain Contact directly with the Domain Name Registrar. This
method may only be used if:

1. The    CA authenticates the Applicant's identity under BR Section 3.2.2.1
and the authority of the Applicant Representative under BR
Section 3.2.5, OR

2. The CA authenticates the Applicant's identity under EV Guidelines Section
11.2 and the agency of the             Certificate Approver under    EV
Guidelines Section 11.8; OR

3. The CA is also the Domain Name Registrar, or an Affiliate of the
Registrar, of the Base Domain Name.

B. Effective immediately, replace Section 3.2.2.4.8 of the Baseline
Requirements with the following:

'''3.2.2.4.8 IP Address'''

Confirming the Applicant's control over the requested FQDN by confirming
that the Applicant controls an IP address returned from a             DNS
lookup for A or AAAA records for the FQDN in accordance with section
3.2.2.5.

C. Effective immediately, delete the definition of Required Website Content.

D. Effective immediately, amend Section 3.2.2.4.6 as follows:

'''3.2.2.4.6 Agreed‐Upon Change to Website'''

Confirming the Applicant's control over the requested FQDN by confirming
__the presence of Required Website Content contained in the content of a
file or on a web page in the form of a meta tag__ --(one of the following)--
under the "/.well‐known/pki‐validation"               directory, or
another path registered with IANA for the purpose of Domain Validation, on
the Authorization Domain Name that is accessible by the CA via HTTP/HTTPS
over an Authorized Port__. The presence of the Request Token or Random Value
contained in the form of a meta tag where the Request Token or Random Value
MUST NOT appear in the request.__ --(:)--

--(1. The presence of Required Website Content contained in the content of a
file or on a web page in the form of a meta tag. The entire Required Website
Content MUST NOT appear in the request used to retrieve the file or web
page, or)--

--(2. The presence of the Request Token or Request Value contained in the
content of a file or on a webpage in the form of a meta tag where the
Request Token or Random Value MUST NOT appear in the request.)--

If a Random Value is used, the    CA or Delegated Third Party SHALL provide
a Random Value unique to the certificate request and SHALL not use the
Random Value after the longer of (i) 30 days or (ii) if the Applicant
submitted the certificate request, the timeframe          permitted for
reuse of validated information relevant to the certificate (such as in
Section 3.3.1 of these Guidelines or Section     11.14.3 of the EV
Guidelines).

Note:     Examples of Request Tokens include, but are not limited to: (i) a
hash of the public key; (ii) a hash of the Subject Public Key Info [X.509];
and (iii) a hash of a PKCS#10 CSR. A Request Token may also be concatenated
with a timestamp or other data. If a CA               wanted to always use a
hash of a PKCS#10 CSR as a Request Token and did not want to incorporate a
timestamp and did want to allow certificate key re‐use then the
applicant might use the challenge password in the creation of a CSR with
OpenSSL to ensure uniqueness

even if the subject and key are identical between subsequent requests. This
simplistic shell command produces a Request Token which    has a timestamp
and a hash of a CSR. E.g. echo date ‐u +%Y%m%d%H%M sha256sum <r2.csr | sed
"s/[ ‐]//g" The script outputs:

201602251811c9c863405fe7675a3988b97664ea6baf442019e4e52fa335f406f7c5f26cf14f

The CA should define in its CPS (or in a document referenced from the CPS)
the format of Request Tokens it accepts.

E. Effectively immediately, replace the reference to Section 3.3.1 with a
reference to Section 4.2.1 in the third paragraph under Section 3.2.2.4.

-- MOTION ENDS -

From: Validation [mailto:validation-bounces at cabforum.org] On Behalf Of Rick
Andrews via Validation
Sent: Monday, February 13, 2017 6:28 PM
To: Wayne Thayer <wthayer at godaddy.com <mailto:wthayer at godaddy.com> >;
CA/Browser Forum Validation WG List <validation at cabforum.org
<mailto:validation at cabforum.org> >
Cc: Rick Andrews <Rick_Andrews at symantec.com
<mailto:Rick_Andrews at symantec.com> >
Subject: Re: [cabf_validation] Gerv's ballot

Thanks, Wayne. I might volunteer to create that unified ballot, but not
right now. I will be OOO part or all of the next two weeks, and that’s a
bad time to not respond quickly to comments and questions.

-Rick

From: Wayne Thayer [mailto:wthayer at godaddy.com]
Sent: Friday, February 10, 2017 5:58 PM
To: CA/Browser Forum Validation WG List <validation at cabforum.org
<mailto:validation at cabforum.org> >
Cc: Rick Andrews <Rick_Andrews at symantec.com
<mailto:Rick_Andrews at symantec.com> >
Subject: RE: Gerv's ballot

It was a suggestion, not a ballot:
https://cabforum.org/pipermail/public/2017-January/009250.html

Thanks,

Wayne

From: Validation [mailto:validation-bounces at cabforum.org] On Behalf Of Rick
Andrews via Validation
Sent: Friday, February 10, 2017 6:16 PM
To: CA/Browser Forum Validation WG List <validation at cabforum.org
<mailto:validation at cabforum.org> >
Cc: Rick Andrews <Rick_Andrews at symantec.com
<mailto:Rick_Andrews at symantec.com> >
Subject: [cabf_validation] Gerv's ballot

At our VWG this week, we talked about the “errata” ballot I proposed, and
someone suggested it might be good to piggyback it on Gerv’s ballot. Now
that I’m finally caught up on email, I don’t see a ballot from him other
than the CAA ballot, which isn’t appropriate for this. Can someone direct
me to the intended ballot?

-Rick

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20170223/d8d81249/attachment-0001.html>