Hi! I wanted to check-in with the WG on the next steps for draft-ietf-acme-authority-token. I performed an AD review on it in October-2020 (~7 months) and haven't heard back. Rich and I asked again in January 2021 and April 2021 but got no response. Is this document something the WG still wants to advance?
Regards, Roman > -----Original Message----- > From: Acme <[email protected]> On Behalf Of Roman Danyliw > Sent: Thursday, April 15, 2021 4:01 PM > To: Salz, Rich <[email protected]>; Chris Wendt <[email protected]>; > Mary Barnes <[email protected]>; Peterson, Jon > <[email protected]>; [email protected] > Cc: [email protected] > Subject: Re: [Acme] AD review of draft-ietf-acme-authority-token-05 > > 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 <[email protected]> > > Sent: Wednesday, January 13, 2021 3:16 PM > > To: Roman Danyliw <[email protected]>; Chris Wendt > > <[email protected]>; Mary Barnes <[email protected]>; > > Peterson, Jon <[email protected]>; [email protected] > > Cc: [email protected] > > 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" <[email protected]> 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 > > [email protected] > > 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 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
