[cabf_validation] Proposed replacement for Method 6

Thu Jul 18 10:30:37 MST 2019

We've been talking about this for a long time, so I'll start the discussion
with this Method 6 replacement proposal.

I've attached a word document in case anyone wants to provide redlined
changes back, or if they want to create a shared Google Doc for commenting
and tracking.

Enjoy!

Doug

****** Current Method 6

3.2.2.4.6 Agreed-Upon Change to Website

Confirming the Applicant's control over the 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. 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 Random Value contained in the
content of a file where the Request Token or Random Value MUST NOT appear in
the request.

If a Random Value is used, the CA 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 4.2.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.

Note: Once the FQDN has been validated using this method, the CA MAY also
issue Certificates for other FQDNs that end with all the labels of the
validated FQDN.  This method is suitable for validating Wildcard Domain
Names.

****** Discussion about the use of Required Website Content

Robbin and I discussed the reasons for including this and we both believe
there is no longer a value "required Website Content"

The current definition of Required Website Content is = ('Random Value' or
'Request Token') AND 'additional information that uniquely identifies the
Subscriber'.

We think that is unnecessarily complex, because the important thing (for us)
is linking the text we put in the webpage with the applicant's request.

Requiring that a subscriber identity is added into the text adds nothing
because it could only be necessary if there is a chance of a duplicate
'Random Value' or a duplicate 'Request Token' and we know that a duplicate
cannot happen.

We think a justification for requiring the subscriber identity be added was
to help validation operatives be clear which 'account' this validation was
for.  

That is just pointless, because (a) both Random Values and Request Tokens
are long enough that they need automated processing rather than manual
inspection; and (b) both Random Values and Request Tokens are unique
already, so no need to add further info.

So, we're proposing that Required Website Content be removed from this
validation method.

****** Proposed Method 6 replacement

3.2.2.4.tbd Agreed-Upon Change to Website

Confirming the Applicant's control over the FQDN by verifying:

1.	that the Request Token or Random Value is contained in the content
of a file, and 
2.	the entire Request Token or Random Value MUST NOT appear in the
request used to retrieve the file, and 
3.	the CA must receive a successful HTTP response (meaning that no 2xx
or 3xx response codes must be accepted).

If a Random Value is used, the CA 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 4.2.1 of these Guidelines or Section 11.14.3
of the EV Guidelines).

The Request Token or Random Number SHALL be: 

a.	Located on an Authorization Domain Name
b.	Located under the "/.well-known/pki-validation" or
".well-known/acme-challenge/" directory
c.	Accessed via HTTP or HTTPS
d.	Accessed over an Authorized Port

The CA may follow only server-side redirects given:

*	A maximum of 1 redirect may be followed, and
*	Redirect must be only to http or https, and
*	May be to a different Authorized Port

<We can keep or remove the Notes - TBD>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190718/1e458a56/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Replacement Method 6.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 17582 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20190718/1e458a56/attachment-0001.docx>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5701 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20190718/1e458a56/attachment-0001.p7s>