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

[Mark Nottingham <[e-mail]>]

Hi Ryan,

Happy New Year. Some responses below.

> On 4 Jan. 2017, at 10:42 am, Ryan Sleevi <[e-mail]> wrote:
> 
> 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 )

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.
> 
> Sorry these questions got dropped.

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

Cheers,


> 
> 
> On Fri, Aug 26, 2016 at 4:39 AM, Mark Nottingham <[e-mail]> 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 <[e-mail]> wrote:
> >
> >
> >    URI suffix:  pki-validation
> >
> >    Change controller:  CA/Browser Forum, e-mail address: [e-mail], 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 [e-mail].
> >
> > Sincerely yours,
> >
> > Ben Wilson, on behalf of the CA/Browser Forum
> > _______________________________________________
> > wellknown-uri-review mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/wellknown-uri-review
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
> 
> 
> 
> _______________________________________________
> Questions mailing list
> [e-mail]
> https://cabforum.org/mailman/listinfo/questions
> 

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