Re: Request for well-known URI: /.well‐known/pki‐validation

Hi Ben,

Overall this looks reasonable, but that's probably too much to put into Related Information. Since it's already in the referenced, that can be safely omitted. If that's OK, I'll register (items below are non-blocking).

One comment and a question:

The use of "directory" is odd in the first sentence. The well-known location specifies a path; clients can retrieve that path, and/or they can add more path components and/or a query string to it to generate other URLs. It's not clear whether you want clients to only use the registered value, or allow any arbitrary path that uses it as a root.

Also, the phrase " contained in the content of a file or on a web page in the form of a meta tag" is ambiguous; does the OR group as:

1. (file) or (web page in the form of a meta tag)
2. (file or web page) in the form of a meta tag

? (two occurrences)

Regards,

> On 26 Aug 2016, at 5:22 AM, Ben Wilson <ben.wilson@digicert.com> wrote:
> 
>  
>    URI suffix:  pki-validation
>  
>    Change controller:  CA/Browser Forum, e-mail address: questions@cabforum.org, homepage:  www.cabforum.org
>  
>    Specification document(s):  Section 3.2.2.4.6 of version 1.3.8 of the CA/Browser Forum’s Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates (“Baseline Requirements”) - specifically here - https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.3.8.pdf  (generally here https://cabforum.org/baseline-requirements-documents/)
>  
>    Related information:    The Baseline Requirements read in pertinent part as follows:
>  
> 3.2.2.4.6 Agreed-Upon Change to Website
> 
> Confirming the Applicant's control over the requested FQDN by confirming 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 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
> 	• 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.
>  
> Communication with the Forum can be accomplished by sending a response to questions@cabforum.org.  
>  
> Sincerely yours,
>  
> Ben Wilson, on behalf of the CA/Browser Forum
> _______________________________________________
> wellknown-uri-review mailing list
> wellknown-uri-review@ietf.org
> https://www.ietf.org/mailman/listinfo/wellknown-uri-review

--
Mark Nottingham   https://www.mnot.net/