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

Ryan Sleevi <sleevi@google.com> Tue, 03 January 2017 23:43 UTC

Return-Path: <sleevi@google.com>
X-Original-To: wellknown-uri-review@ietfa.amsl.com
Delivered-To: wellknown-uri-review@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93CA91294BA for <wellknown-uri-review@ietfa.amsl.com>; Tue, 3 Jan 2017 15:43:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.8
X-Spam-Level:
X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VW2FODnS2Fhz for <wellknown-uri-review@ietfa.amsl.com>; Tue, 3 Jan 2017 15:43:18 -0800 (PST)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 238D91294C7 for <wellknown-uri-review@ietf.org>; Tue, 3 Jan 2017 15:43:18 -0800 (PST)
Received: by mail-yw0-x22b.google.com with SMTP id r204so302087944ywb.0 for <wellknown-uri-review@ietf.org>; Tue, 03 Jan 2017 15:43:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+vSlMQCZy9V5wRlo6+g8ny9viVj/SJGAYm2/w0jBxH0=; b=L0uTnsM3BOryB3wy6g0lF7Otudk4dFuNyiXntxSjSBXSJpsb7hF1d++qCHLbqM+CTw DiaeJCTxGDcsUQhbtwyF7dnYJRDf25+a82AMbWhisbN/tc8pwI+QFqf2eK9GJ4l1GJve wrh7MD87a2ZA6tjQOTnhiXM7DYkthpTyMdn9PO8A5CSwAFLW7mhT4Tz17OFhFu3wSYug jULQrRAd8YTimzEmBVOZMwUb7n2Za9gFfK8oNI8sERq81ijb2pMLmvQbH4fP0pDKMn7U k/LFIelTl/Mxe1JpQE6Lpm/BhTXfXYyxq2b5Vl1j6tfVIFr0l5nLCxqmLGTg/BBFDrKQ i37g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+vSlMQCZy9V5wRlo6+g8ny9viVj/SJGAYm2/w0jBxH0=; b=AtOWqA4Ur9jUxWclm6bVGBqAr5InTmukafrPwrXsKP63pzAIt9NY+1CckB7dgMPPyz XXyhB9j+WKAlB35cE+/tOX+JPi0WMO1US3WiefNOVc2MosTa1siTXeLqHJn+X99dAljn a6UvCq1RB7hKTpS+TQr0zn1rnu+LLiGisotsMfzJobYfyEdV7dNa46RFK7wOZw9HS4+v J9bZlBOWXJLAt+KiN5AbkvT39ksyvdVUyJodKgwkwJ+3dkP4lGFnTErAChdRI2a3mNLe ZVAfhMb89tDpw4MnDXIq6rvNRKPwyUhfkRB6Bna7sLeixGns0rRKehr+e9NKCSmEAdeJ i5lA==
X-Gm-Message-State: AIkVDXK0UfvrZLP76oFlAwMHv99iLXi7fSPzvqXG380lamqFdEwlU+Q2cUryR6YPzN2E70rfaBjo0FBttw9qpT8G
X-Received: by 10.129.85.11 with SMTP id j11mr59710984ywb.123.1483486997273; Tue, 03 Jan 2017 15:43:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.214.131 with HTTP; Tue, 3 Jan 2017 15:42:36 -0800 (PST)
In-Reply-To: <1475B745-239F-4685-9DB6-B1C178D6C000@mnot.net>
References: <bc378b56d6254682b2e4d3ab045507f4@EX2.corp.digicert.com> <1475B745-239F-4685-9DB6-B1C178D6C000@mnot.net>
From: Ryan Sleevi <sleevi@google.com>
Date: Tue, 3 Jan 2017 15:42:36 -0800
Message-ID: <CACvaWvZxux=wCvdycuTRmNfj3e3xz4R_VPxDx6JGOsYRAak_kQ@mail.gmail.com>
Subject: =?UTF-8?B?UmU6IFtjYWJmcXVlc3RdIFJlcXVlc3QgZm9yIHdlbGwta25vd24gVVJJOiAvLndlbGw=?= =?UTF-8?B?4oCQa25vd24vcGtp4oCQdmFsaWRhdGlvbg==?=
To: Mark Nottingham <mnot@mnot.net>
Content-Type: multipart/alternative; boundary=001a113f2b8480922c0545393be8
Archived-At: <https://mailarchive.ietf.org/arch/msg/wellknown-uri-review/Sm13ynI3QUuYnW_2KElxHbEbTGU>
Cc: Ben Wilson <ben.wilson@digicert.com>, "wellknown-uri-review@ietf.org" <wellknown-uri-review@ietf.org>, "questions@cabforum.org" <questions@cabforum.org>
X-BeenThere: wellknown-uri-review@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Well-Known URI review list <wellknown-uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wellknown-uri-review>, <mailto:wellknown-uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/wellknown-uri-review/>
List-Post: <mailto:wellknown-uri-review@ietf.org>
List-Help: <mailto:wellknown-uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wellknown-uri-review>, <mailto:wellknown-uri-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Jan 2017 23:43:20 -0000

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 <mnot@mnot.net> 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 <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: 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 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/
>
>
>
>
> _______________________________________________
> Questions mailing list
> Questions@cabforum.org
> https://cabforum.org/mailman/listinfo/questions
>