Re: [Acme] AD review of draft-ietf-acme-authority-token-05
Roman Danyliw <rdd@cert.org> Thu, 15 April 2021 20:00 UTC
Return-Path: <rdd@cert.org>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4274B3A2CC6 for <acme@ietfa.amsl.com>; Thu, 15 Apr 2021 13:00:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
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 OnCaX8s9pxh8 for <acme@ietfa.amsl.com>; Thu, 15 Apr 2021 13:00:52 -0700 (PDT)
Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 361F93A2CC4 for <acme@ietf.org>; Thu, 15 Apr 2021 13:00:52 -0700 (PDT)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 13FK0kXM002154; Thu, 15 Apr 2021 16:00:47 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 13FK0kXM002154
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1618516847; bh=gra+1Mz6ZscI3nJSkaVkmL0NbWjlbidVwY7e8s7S7bM=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=lpYWmglLgUn1rKIo3f27xHI02St4nreY2h1xzisltlYYvsfLdc4fqgZQEb9cRf/YR E2wi56kqg+ORX7ho5THafwJv5PWILakp6Jq9cYeUN72zU6g6GuONnj2pEV2eUmGhH5 NXzLaxw7pD90kGlTmT7R4QJeBT4nFYXt8B6RxloY=
Received: from MURIEL.ad.sei.cmu.edu (muriel.ad.sei.cmu.edu [147.72.252.47]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 13FK0iEr005980; Thu, 15 Apr 2021 16:00:44 -0400
Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 15 Apr 2021 16:00:44 -0400
Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%21]) with mapi id 15.01.2106.013; Thu, 15 Apr 2021 16:00:44 -0400
From: Roman Danyliw <rdd@cert.org>
To: "Salz, Rich" <rsalz@akamai.com>, Chris Wendt <chris-ietf@chriswendt.net>, Mary Barnes <mary.ietf.barnes@gmail.com>, "Peterson, Jon" <jon.peterson@team.neustar>, "davidhancock.ietf@gmail.com" <davidhancock.ietf@gmail.com>
CC: "acme@ietf.org" <acme@ietf.org>
Thread-Topic: [Acme] AD review of draft-ietf-acme-authority-token-05
Thread-Index: AQHW6ejlOEYeQcveQkikId7N6kJ3Waq2j80A
Date: Thu, 15 Apr 2021 20:00:43 +0000
Message-ID: <5bcc3911ebce4a78a26a98df1575210d@cert.org>
References: <9FF54993-6265-49F5-9663-63A99DB7762B@akamai.com>
In-Reply-To: <9FF54993-6265-49F5-9663-63A99DB7762B@akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.203.41]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/YgKHOq-UjJeutKcDJyc2KMKioLc>
Subject: Re: [Acme] AD review of draft-ietf-acme-authority-token-05
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Apr 2021 20:00:57 -0000
Hi! I'm checking in on status of this document. I'd like to batch it with draft-ietf-acme-authority-token-tnauthlist when they go to the IESG. Thanks, Roman > -----Original Message----- > From: Salz, Rich <rsalz@akamai.com> > Sent: Wednesday, January 13, 2021 3:16 PM > To: Roman Danyliw <rdd@cert.org>; Chris Wendt <chris-ietf@chriswendt.net>; > Mary Barnes <mary.ietf.barnes@gmail.com>; Peterson, Jon > <jon.peterson@team.neustar>; davidhancock.ietf@gmail.com > Cc: acme@ietf.org > Subject: Re: [Acme] AD review of draft-ietf-acme-authority-token-05 > > Authors, > > Have these been addressed? Soon? > > On 10/14/20, 1:00 PM, "Roman Danyliw" <rdd@cert.org> wrote: > > Hi! > > I performed an AD review of draft-ietf-acme-authority-token. Thanks for > writing this document in an extensible way (for additional token types). Below > is my detailed feedback. > > ** What is the intended status of this document? The document says > Informational; the datatracker and the shepherd's report says Proposed > Standard. TnAuthlist is PS. These four places need to be consistent. > > ** Are there implementations of this document? The rough history in ACME > seems to have been PS should have implementation experience. Is the link to > STIR decisive here (to make it PS)? > > ** ID-Nits reported the following issues with references being listed but not > used: > == Unused Reference: 'I-D.ietf-acme-service-provider' is defined on line > 455, but no explicit reference was found in the text > > == Unused Reference: 'I-D.ietf-acme-star' is defined on line 460, but no > explicit reference was found in the text > > == Unused Reference: 'RFC7340' is defined on line 477, but no explicit > reference was found in the text > > == Unused Reference: 'RFC8224' is defined on line 494, but no explicit > reference was found in the text > > == Unused Reference: 'RFC8225' is defined on line 500, but no explicit > reference was found in the text > > ** Additionally, on the topic of references, why are [I-D.ietf-acme-authority- > token-tnauthlist] , [RFC7340] and [RFC8226] normative? > > -- Section 1. [I-D.ietf-acme-telephone] is an expired draft that doesn't appear > to be actively advanced. Given that it primarily to show an example use case, it > should likely be an informative, not normative, reference. > > ** In the introductory materials (abstract and/or Section 1), I would have > benefited from an upfront statement that this document is describing an > architecture for Authority Tokens, a particular token format, a new protocol for > retrieving the token, and integration of this token into an ACME challenge. In > particular the existence of the new protocol (between the TA and the client) > was not clear. > > ** The tkauth-type="atc" type doesn't seem to describe all of the required > information described by Section 3.1 - 3.3 and Section 9 (Security > Considerations) as being needed for a token format. Specifically: > > (a) Section 3.1. Per "Definitions of a tkauth-type MUST specify how they > manage the freshness of authority assignments", how is freshness of authority > assignment handled in tkauth-type="atc"? > > (b) Section 3.2 suggests that tokens need to convey scope. This scope seems > to be identifier specific conveyed through the tkvalue. However, the values of > tkvalue is out of scope of this document. > > (c) Section 3.3. suggests "To mitigate this, Authority Tokens contain a binding > signed by an Authority". Section 9 says "... all Authority Tokens MUST contain a > field that identifies to the CA which ACME client requested the token from the > authority; here that is the fingerprint specified in Section 4)." However, Section > 4 says, "For the purposes of the "atc" tkauth-type, the binding "fingerprint" is > assumed to be a fingerprint of the ACME credential for the account used to > request the certificate, but the specification of how the binding is generated is > left to the identifier type profile for the Authority Token." This seems to > suggest that defining the binding computation is out scope of this document. > > For the binding, I'm curious on how is it computed (on what input? How are > algorithms/keys selected) and when does this need to occur? > > Minimally, it seems that properties (b) and (c) can only be satisfied with the > combination of this document and a particular "identifier profile". Perhaps this > section is spelling out requirements for both of those collectively? If so, this > should be explicitly stated (perhaps in the intro to Section 3, reminded in > Sections 4 and 9). > > ** Editorially, decide on where the text will use AT and TA; Authority Token > and Token Authority; or token and authority. It would be clear if it was the > fewest possible version of this key terms. > > ** Section 3. Editorial. The title "Challenges for an Authority Token" might > be clearer if reworded given that ACME has "challenges" - perhaps s/Challenges > for an Authority Token/ACME Authority Token Challenge/ > > ** Section 3. The text notes that authority tokens can be used for ACME > challenges, but this document doesn't add a new challenge type to the "ACME > Validation Methods" registry. Section 6 provides an example using token- > tnauthlist which seems to suggest a type="tkauth-01", but that isn't specified in > draft-ietf-acme-token-tnauthlist or this document. > > I also found it jarring to jump into the discussion of tkauth-type and token > authority without a bit more context. I recommend replacing the last > paragraph as follows: > > OLD > ACME challenges that support Authority Tokens ... > > NEW > > The ACME Authority Token Challenge, "tkauth-01", supports different token > types. The token type is determined by a new ACME challenge field, tkauth- > type. An IANA registry is used to manage the values of tkauth-type, see Section > 8.*. Additionally, this challenge also has a new "token-authority" field to > designate a location where a token can be acquired. > > ** Section 3.1. Per "The IANA will maintain a registry of tkauth-types under a > policy of Specification Required", move this text about registry policy to the > IANA section > > ** Section 3.1. Per "... future specifications must indicate how a token > conveys to the CA the name(s) ...", is there a reason this isn't a normative > MUST? > > ** Section 3.1. Per "The protocols used to request an Authority Token MUST > convey to the Token Authority the identifier type and value from the ACME > challenge ...", the language of "from the ACEM challenge" suggests only a > workflow where the token is requested after engagement with the ACME > server. However, Section 3.2 suggests that a client might get the token before > engaging the ACME server. Maybe s/from the ACME challenge/from or what > will be used in the ACME challenge/ > > ** Section 3.2. Editorial. Somewhere earlier in the text state "Authority > Token (AT)", as no text currently establishes this acronym. > > ** Section 3.2. Editorial. Consistently use "Authority Token", s/to a client a > Token/to a client an Authority Token/ > > ** Section 3.2. Per "an Authority Token could attest to all of the resources > that the client is eligible to receive certificates for", couldn't this leaks > information to a CA, if that single CA is not responsible for all of the scopes? > > ** Section 3.2. Editorial. Consistently use "Token Authority" instead of > "Authority" to make it clear were aren't saying "Certificate Authority" > > ** Section 3.3. Editorial. I found it confusing to use "binding" and both a > noun and a verb: > -- "To mitigate this, Authority Tokens contain a binding signed by an > Authority ..." > -- "Binding an Authority Token to a particular ACME account ..." > > ** Section 4. Editorial. > > OLD > This draft registers a tkauth-type of "atc", for the Authority Token > Challenge. Here the "atc" tkauth-type signifies a standard JWT token > [RFC7519] using a JWS-defined signature string [RFC7515]. This may > be used for any number of different identifier types given in ACME > challenges. The "atc" element (defined below) lists the identifier > type used by tokens based on ATC . The use of "atc" is restricted to > JWTs, if non-JWT tokens were desired for ACME challenges, a different > tkauth-type should be defined for them. > > NEW > This draft specifies a tkauth-type of "atc" which is a standard JWT token > [RFC7519] using a JWS-defined signature string [RFC7115]. The "atc" tkauth- > type MAY be used for any number of different ACME identifier types in the > ACME challenge. A new JWT claim, "atc", is defined below and lists the > identifier type used in this Authority Token. The "atc" tkauth-type is restricted > to the JWTs; if a non-JWT token format is desired for the ACME Authority > Token Challenge, a different tkauth-type should be specified and registered in > the "xxx" registry defined in Section 8.* > > ** Section 4. Editorial. ATC is used but never explicitly defined as being > "Authority Token Challenge (ATC)". > > ** Section 4. What would be the circumstance where the x5u/iss would not > equal the token-authority? > > ** Section 4. Why is "The JWT payload must also contain a ...", not a > normative MUST? > > ** Section 4. Should the values of tktype be constrained to the IANA "ACME > Identifier Types" registry? > > ** Section 4. This text should explicitly say that "tkvalue" semantics are > outside the scope of this document. > > ** Section 4. s/"atc" element/"atc" claim/ > > ** Section 4. The example in this section is missing the full > payload/protected /signature structure to show the actual binding provided by > the server > > ** Section 5. This token acquisition protocol seems underspecified: > -- How does the client authenticate/do authorization with the HTTPS server? > > -- Is there any semantics to the resource locator to make for an > interoperable/discoverable URI? > > -- Does the client get to request a scope? > > ** Section 5. Editorial. s/a Authority Token/an Authority Token/ > > ** Section 5.1. It might be useful to show a full server response example > given a particular client request > > ** Section 5.1 > After an HTTPS-level challenge to verify the identity of the client > and subsequently making an authorization decision , in the success > case the Token Authority returns a 200 OK with a body of type > "application/json" containing the Authority Token. > > -- What is an "HTTPS-level challenge"? > > -- It seems like a few words are missing describing the server's behavior to > describe what happens between client sending the JSON "atc" blob and > returning an authority token? Should there be text about signing? The server > validating the scope in a some identifier specific way? > > -- How is error handling managed with the HTTP error code? The TnAuthlist > draft actually specifies this behavior more that this base document. > > -- Section 5. Shouldn't a successful response from a Token Authority return a > body of type "application/jwt" if an "authority token" is being returned per > Section 4? > > ** Section 6. This section seems underspecified with only the use of an > example. It provides no normative text on using the authority token in the > ACME challenge. For example, what type should be used (tkauth-01)? What is > the cardinality of tk-auth-type, token-authority, token? > > ** Section 8. This text registers "atc" as an ACME identifier. When and how > is that used? I thought that identifier profiles specified an identifier and that > the atc what the challenge/verification type. > > ** Section 8. Is there a reason that the "atc" claim from Section 4 not being > registered in the "JSON Web Token Claims" registry? > > ** Section 8. Per the registry of "token types", there don't seem to be > enough details here: > -- Is the intent for the registry to be called (in lower case) "token types". > Shouldn't it be something like "ACME Authority Token Challenge Types"? > > -- What columns are in that registry? Please be explicit, if it is Label and > Reference. > > Regards, > Roman > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.ietf.org_mailman_listinfo_acme&d=DwICAg&c=96ZbZZcaMF4w0F4j > pN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=KKMUAt5wm8Vy2_- > YnBnWkWr_4yD6G9lTMhYZiFQ2J_s&s=K5vl0NrG5LqkL6Qzy- > 8cyQCG1RMqIQwrvCf0jPOBA7w&e=
- [Acme] AD review of draft-ietf-acme-authority-tok… Roman Danyliw
- Re: [Acme] AD review of draft-ietf-acme-authority… Salz, Rich
- Re: [Acme] AD review of draft-ietf-acme-authority… Roman Danyliw
- Re: [Acme] AD review of draft-ietf-acme-authority… Roman Danyliw
- Re: [Acme] AD review of draft-ietf-acme-authority… Roman Danyliw
- Re: [Acme] AD review of draft-ietf-acme-authority… Peterson, Jon
- Re: [Acme] AD review of draft-ietf-acme-authority… Roman Danyliw
- Re: [Acme] AD review of draft-ietf-acme-authority… Peterson, Jon
- Re: [Acme] AD review of draft-ietf-acme-authority… Roman Danyliw