[Acme] AD review of draft-ietf-acme-authority-token-tnauthlist-06

[Roman Danyliw <[e-mail]>]

Hi!

I performed an AD review of draft-ietf-acme-authority-token-tnauthlist-06.  Below is my feedback.  There might be some negotiation between what text should be here as opposed to draft-ietf-acme-authority-token.

** From idnits (with commentary)

  == Unused Reference: 'ATIS-1000074' is defined on line 565, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC8588' is defined on line 583, but no explicit
     reference was found in the text

  == Outdated reference: A later version (-05) exists of
     draft-ietf-acme-authority-token-04

  == Outdated reference: A later version (-02) exists of
     draft-ietf-stir-cert-delegation-01

  ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231,
     RFC 7232, RFC 7233, RFC 7234, RFC 7235)

I believe RFC7235 is the appropriate replacement

  ** Downref: Normative reference to an Informational RFC: RFC 4949

  ** Downref: Normative reference to an Informational RFC: RFC 7340

I don't believe that RFC7340 needs to be normative.

** Section 3.  Editorial. Please update the various dates in examples to be in 2020 (not 2016) so they more closely reflect the publication date

** Section 4.  Per "a CA MUST use the Authority Token challenge mechanism defined in [I-D.ietf-acme-authority-token]", does this text mean "type = tkauth-01" or "type = tkauth-01; tkauth-type = atc"?

** Section 5.  For clarity, it is likely worth repeating that exp, jti and atc are mandatory.

** Section 5.4.  The example of the TNAuthList AT seems to be missing the full payload/protected /signature structure to show the actual binding provided by the server

** Section 5.5.  What the semantics of the response from the authority server described here are different than what is in draft-ietf-acme-authority-token (Section 5: "... in the success case the Token Authority returns a 200 OK with a body of type "application/json" containing the Authority Token").   What is being returned here is not strictly the authority token format.

** Section 5.5.  Per the last paragraph, no issues with the guidance here.  However, it seems odd that this generic behavior is specified here and not in draft-ietf-acme-authority-token.  Generally, speaking all of this normative text for this protocol between the client and the TA should be specified in the authority-token draft so that future profiles (not tnauthlist) can use it.

** Section 8.  Please add that this document inherits the security properties of draft-ietf-acme-authority-token.

** Section 9.  Editorial.  Explicitly name the registry.

OLD
This document requests the addition of a new identifier object type
   that can be present in the identifier field of the ACME authorization
   object defined in [RFC8555].

NEW
This document requests the addition of a new identifier type to the "ACME Identifier Types" registry defined in Section 9.7.7 of [RFC8555].

Regards,
Roman