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

[Ben Wilson <[e-mail]>]

 

   URI suffix:  pki-validation

 

   Change controller:  CA/Browser Forum, e-mail address: questions@cabforum.
org <mailto:[e-mail]> , homepage:  www.cabforum.org
<http://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:

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.

 

Communication with the Forum can be accomplished by sending a response to
[e-mail] <mailto:[e-mail]> .  

 

Sincerely yours,

 

Ben Wilson, on behalf of the CA/Browser Forum