Re: [Acme] AD review of draft-ietf-acme-authority-token-05

[Roman Danyliw <[e-mail]>]

Hi Jon!

Thanks for the update in -06 and the explanation below.  Please see the responses in line.  I've deleted all of the items that have been resolved.

> -----Original Message-----
> From: Peterson, Jon <[e-mail]>
> Sent: Monday, July 12, 2021 6:57 PM
> To: Roman Danyliw <[e-mail]>; [e-mail]
> Cc: [e-mail]
> Subject: Re: [Acme] AD review of draft-ietf-acme-authority-token-05

[snip]

>     > > >     ** ID-Nits reported the following issues with references being
>     > > > listed but not
>     > > > used:
> 
> We divided references into normative and informative, and nuked ones that
> seemed particularly superfluous (including say acme-telephone).
> 
> For the most part, the new version incorporates your proposed changes to the
> text throughout (and hopefully it's a little better editorially). There are only a
> few cases where this warrants a bit more comment:

Thanks for this clean-up.  Are you use that you need the downref to RFC 8396?  It's use in the document seems to be for illustrative purpose.

If so, we should call this DOWNREF in in the shepherd’s report.

>     > > >
>     > > >     ** 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:
> ...
>     > > > 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).
> 
> We've taken the tack you suggest above of clarifying that this requirements
> need to be satisfied by a combination of authority-token and its tkauth
> subtypes.

Thanks for these updates.  One remaining thing -- this document seems to be defining and registering the “atc” claim (as in this is the base reference for the claim).  However, no guidance is provided on how to compute the fingerprint.  On the other hand, Section 5.4 of draft-ietf-acme-token-tnauthlist covers this topic in depth.  Is there one fingerprint computation method for all instantiations of the atc claim, or does the procedure vary by the selected tktype.  If it’s the former, then the fingerprint computation needs to be here or a normative reference is needed to the tnauthlist.  If the method varies by the tktype, then please explicitly state that.

>     > > >
>     > > >     ** Section 4.  Should the values of tktype be constrained to the
>     > > > IANA "ACME Identifier Types" registry?
> 
> This is another one where I don't have a super strong feeling... it would
> certainly be helpful if it were, but it doesn't seem like it's worth normative
> language to that effect.

I personally do feel that constraining the values of the tktype to some defined set of code points would be helpful and that there would be an identifier-to-atc sub-field mapping.  However, if the WG doesn’t want to do that, then minimally we need some text here saying that the ACME client will somehow know how to populate the atc sub-fields (and which ones) based on local configuration or declare out it knows it as out of scope.
 
>     > > >     ** 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.
> 
> This was a point of misalignment with tnauthlist; we've rectified that by
> deleting this "atc" ACME identifier.

The inter-relationship between the ACME identifier and validation registries still doesn’t appear to be threaded.  Note:

(a) Section 9.7.8 of RFC8555 says the following about the Validations Method registry:

   The
   "Identifier Type" field must be contained in the Label column of the
   "ACME Identifier Types" registry.

(b) The current (-06) text in Section 7 says:

   This document requests that IANA populate a new ACME Validation
   Method (again per [RFC8555]) for the label "tkauth-01", identifier
   type "atc", an ACME value of "Y", and a reference pointing to
   [RFCThis].

The current text noted in (b) is using an identifier type of “atc” but (a) explicitly says that only identifier types in the Identifier registry are permitted there.  Shouldn’t the identifier type read “TNAuthList” (that’s registered in the draft-ietf-acme-authority-token-tnauthlist)?  "atc" isn't a valid ACME identifier type to include in the new order request ("atc" is a tkauth-type).  The end-to-end example in Section 4 draft-ietf-acme-authority-token-tnauthlist suggests that.

Because the new validation method and new identifier each reference each other, but are in separate documents, we have a circular dependency this first time (which isn’t necessarily problem, we can handle that with a “RFC  cluster”).  Subsequent identifiers using this challenge won't have that issue.
 
Editorially, this entire IANA section would be clear if each distinction ask to IANA was a separate section.  I’m sharing this in advance because this has been a consistent COMMENT provided another AD across a few documents in the IESG review process.

Regards,
Roman