[cabf_validation] Gerv's ballot
Robin Alden
robin at comodo.com
Thu Mar 9 09:37:29 MST 2017
Jeremy,
As well as my ‘backquote’ issue (below), I see another item that I think needs attention. I don’t think it is contentious.
The sentence is this one:
“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.”
It’s either got a word or two missing or it’s a hybrid of two other wording attempts.
I think it should probably read
“The Request Token or Random Value MUST NOT appear in the request for the file or web-page.”
I will endorse.
Regards
Robin
From: Rick Andrews [mailto:Rick_Andrews at symantec.com]
Sent: 24 February 2017 14:30
To: CA/Browser Forum Validation WG List <validation at cabforum.org>
Cc: Wayne Thayer <wthayer at godaddy.com>; Robin Alden <robin at comodo.com>
Subject: Re: [cabf_validation] Gerv's ballot
Wayne, I don't need to be the proposer (I had nothing to do with the idea to add back unencumbered methods) but whatever works.
-Rick
On Feb 23, 2017, at 12:55 PM, Robin Alden via Validation <validation at cabforum.org <mailto:validation at cabforum.org> > wrote:
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 <mailto:validation at cabforum.org> >; Wayne Thayer <wthayer at godaddy.com <mailto:wthayer at godaddy.com> >
Cc: Jeremy Rowley <jeremy.rowley at digicert.com <mailto: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
_______________________________________________
Validation mailing list
Validation at cabforum.org <mailto:Validation at cabforum.org>
https://clicktime.symantec.com/a/1/0VkjHJwzMbzByG-vng4C8QQY6KraYOpOd9aggObyGQ8=?d=o5S-oN4t2oeOJsWtGRWbX0G6ilKH8lQjTiDrc7bILdE82J9aiS3iKHyb5jh93b5dcjWCa-ULcL10QAqg3ERhhtFk9utjv5yykM03vJfaxMvzeoURpwLieRDLfRXiN-4XiMut9c_CfZR5DEACkmpKkc7HwdBF5DwVi7Wo_T8jgenWHwuTf77TR1Y1Hi9oxT5k6_huv_ch6WdJZ4qDPv3hVkGPBTXciWPjS6X1UM1zF-pigHv6AFABxeT3UT0L0eaTacG0LVeneMutXz5XB33XIbcnwxwYDZ8miyNeEhlv5Nn5psLwBuFGowdzonsKNlXgUPJTnnuR4nHjYdwAf92LO4w1e9xjveyCnf9ZLSRAZtvzR3TGbZ5IAm5dpgl5d0ev&u=https%3A%2F%2Fcabforum.org%2Fmailman%2Flistinfo%2Fvalidation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20170309/a803d055/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5152 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20170309/a803d055/attachment-0001.bin>
More information about the Validation
mailing list