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
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
