Subject: Re: [cabfquest] Request for well-known URI: /.well‐known/pki‐validation

From: Ryan Sleevi <[email-masked]>
Date: Tue, 3 Jan 2017 15:42:36 -0800

I never saw these questions go answered, but my attempt is:

1) The intent is/was to allow the construction of a URL that meets the
template of "{Authorized Scheme}://{Authorization Domain Name}:{Optional
Authorized Port}/.well-known/pki-validation/", with the addition of one or
more path components, to be used. Authorized Scheme is HTTP/HTTPS,
Authorization Domain Name is defined in the BRs, as is Authorized Port.

So, put differently, the intent is that "/.well-known/pki-validation/"
represents the base of the path component, followed by one or more
additional paths (or query strings), provided that the remaining URL
components do not contain the entire Required Website Content :)

It is possible that future modifications to the Baseline Requirements may
further restrict the path components (e.g. to specify a specific
construction), and it's possible that future modifications to the Baseline
Requirements may loosen the requirements (e.g. allowing
"/.well-known/pki-validation/anything-else" while also allowing
"/.well-known/acme-challenge/{construction}" in a manner that complies with
https://tools.ietf.org/html/draft-ietf-acme-acme-04 )

2) The grouping is intended as "(file) or (web page in the form of meta
tag)". This means that the latter is, by definition, fully included in the
check of the former - and is thus redundant - but was included to
explicitly note acceptable practice.

Sorry these questions got dropped.

On Fri, Aug 26, 2016 at 4:39 AM, Mark Nottingham <[email-masked]> wrote:

> 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 <[email-masked]> wrote:
> >
> >
> >    URI suffix:  pki-validation
> >
> >    Change controller:  CA/Browser Forum, e-mail address:
> [email-masked], 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: 201602251811c9c863405fe7675a39
> 88b97664ea6baf442019e4e52fa335f406f7c5f26cf14f 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 [email-masked].
> >
> > Sincerely yours,
> >
> > Ben Wilson, on behalf of the CA/Browser Forum
> > _______________________________________________
> > wellknown-uri-review mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/wellknown-uri-review
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>
>
> _______________________________________________
> Questions mailing list
> [email-masked]
> https://cabforum.org/mailman/listinfo/questions
>

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 5 Jan 2017 15:14:12 +1100

Hi Ryan,

Happy New Year. Some responses below.

> On 4 Jan. 2017, at 10:42 am, Ryan Sleevi <[email-masked]> wrote:
> 
> 1) The intent is/was to allow the construction of a URL that meets the template of "{Authorized Scheme}://{Authorization Domain Name}:{Optional Authorized Port}/.well-known/pki-validation/", with the addition of one or more path components, to be used. Authorized Scheme is HTTP/HTTPS, Authorization Domain Name is defined in the BRs, as is Authorized Port.
> 
> So, put differently, the intent is that "/.well-known/pki-validation/" represents the base of the path component, followed by one or more additional paths (or query strings), provided that the remaining URL components do not contain the entire Required Website Content :)
> 
> It is possible that future modifications to the Baseline Requirements may further restrict the path components (e.g. to specify a specific construction), and it's possible that future modifications to the Baseline Requirements may loosen the requirements (e.g. allowing "/.well-known/pki-validation/anything-else" while also allowing "/.well-known/acme-challenge/{construction}" in a manner that complies with https://tools.ietf.org/html/draft-ietf-acme-acme-04 )

Sure. It's just that URLs are defined in terms of paths, path components, etc. -- "directory" implies a filesystem, which may not be the case, depending on the implementation.

> 2) The grouping is intended as "(file) or (web page in the form of meta tag)". This means that the latter is, by definition, fully included in the check of the former - and is thus redundant - but was included to explicitly note acceptable practice.
> 

No problem. If Ben can confirm that it's Ok to elide the Related Information, we can go ahead and register.

Cheers,

> 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).
> 
> 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:
> 
> >    Change controller:  CA/Browser Forum, e-mail address: [email-masked], 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:
> >
> > 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 [email-masked].
> >
> > Sincerely yours,
> >

---

From: Ben Wilson <[email-masked]>
Date: Thu, 12 Jan 2017 17:05:34 +0000

Mark,
Please go ahead and amend the application accordingly.
Thanks,
Ben Wilson, JD, CISA, CISSP
DigiCert VP Compliance
+1 801 701 9678

-----Original Message-----
From: Mark Nottingham [mailto:[email-masked]]
Sent: Wednesday, January 4, 2017 9:14 PM
To: Ryan Sleevi <[email-masked]>
Cc: Ben Wilson <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [cabfquest] Request for well-known URI: /.well‐known/pki‐validation

Hi Ryan,

> It is possible that future modifications to the Baseline Requirements
> may further restrict the path components (e.g. to specify a specific
> construction), and it's possible that future modifications to the
> Baseline Requirements may loosen the requirements (e.g. allowing
> "/.well-known/acme-challenge/{construction}" in a manner that complies
> with https://tools.ietf.org/html/draft-ietf-acme-acme-04 )

Cheers,

> 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,
>
>
>
>
> >    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.pd
> > f  (generally here