Authors, Reading Roman's review, it seems that this could be handled just as editorial changes. Please let the WG know if you think there's any semantic changes when you update your draft.
On 10/14/20, 1:03 PM, "Roman Danyliw" <[email protected]> wrote: 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_acme&d=DwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=5wagpGFP9sY4Y3ecs3oagujy8ftyxN2bPkYzJK6cRP4&s=kssp7DJwcTdXjm6B-X3hceqDQAHvp-7Q2NLEwno9-Nk&e= _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
