Hi Roman, With my characteristic alacrity, here are some update notes inline on the authority-token draft:
On 7/27/21, 10:00 PM, "Roman Danyliw" <[email protected]> wrote: 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. [JFP] True, we don't need this to be normative - moved to informative. > 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. [JFP] I believe the draft is explicit that it varies by tktype - see section 4, "the specification of how the binding is generated is left to the identifier type profile for the Authority Token." > > > > > > > > ** 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. [JFP] Okay, not a problem - added, and when the tnauthlist draft goes forward, then "TNAuthList" will appear in that registry, and it probably makes sense that any future things would as well. But this brings us to the tough one... > > > > ** 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. [JFP] Um, correct, the threading here still wasn't right. That is fixed. I also fixed a little corresponding text up at the end of Section 3 that I hope clarifies a bit. 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. [JFP] Yes, historically because of the way the draft evolved, we've ended up with circular dependencies between these documents that requires them to progress together. The text I added makes that a bit clearer, I hope - again, I'm kind of patching some problems that arose because of how we separated the drafts. 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. [JFP] That is implemented in the new version. Thanks for the notes again Roman! Jon Peterson Neustar, Inc. Regards, Roman _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
