Inline…
From: Aaron Gable <[email protected]> Date: Tuesday, February 27, 2024 at 12:23 AM To: Carl Wallace <[email protected]> Cc: <[email protected]> Subject: Re: [Acme] I-D Action: draft-ietf-acme-ari-03.txt On Mon, Feb 26, 2024 at 4:36 AM Carl Wallace <[email protected]> wrote: Two comments on the third paragraph of section 4.1: - The addition of section identifiers for the references makes the sentences harder to read. Maybe wrapping the section identifiers and reference in parentheses. Thanks, this feedback is appreciated. I've gone back and forth a lot on how best to do these references, and tried a bunch of different things, and this was my favorite phrasing so far. Unfortunately putting them in parentheses causes the resulting sentence to not read in plain English, unless I'm misunderstanding your suggestion? [CW] I meant something like this (which also corrects a typo in the third word): “The unique identifier is constructed by concatenating the base64url-encoding (see Section 5 of [RFC4648]) of the bytes of the keyIdentifier field of certificate's Authority Key Identifier (AKI) extension (see Section 4.2.1.1 of [RFC5280]), a literal period, and the base64url-encoding of the bytes of the DER encoding of the certificate's Serial Number (without the tag and length bytes).” - The preparation of the URI uses the keyIdentifier field of AuthorityKeyIdentifier. That field is optional. What should occur if it is absent (or if AKID is absent)? Given 5280 requires uniqueness for issuer name and serial and the issuer field is not optional, would the issuer field make for a better target than AKID? If this mechanism only applies to certs that conform to a profile that requires presence of key identifier in the AKID extension, state that up front. This is a very interesting point. RFC 5280 requires both that the AKID extension be present and that the keyIdentifier field be present within it (Section 4.2.1.1: "The keyIdentifier field of the authorityKeyIdentifier extension MUST be included in all certificates generated by conforming CAs to facilitate certification path construction."). So it's not obvious to me that the issuer name + serial uniqueness is any more required than the existence of the keyIdentifier field. Do other members of this list think that using some form of the Issuer Name bytes would be better than using the keyIdentifier? [CW] I am not advocating for use of issuer and serial, but I do think that the spec should say something about the potential for the field to be absent. RFC5280 is a good profile to reference. Maybe in the intro say something like: “This specification is intended for use with certificates that conform to the profile defined in RFC 5280. Specifically, it is for use with certificates that feature Authority Key Identifier extensions containing the keyIdentifier field.” I see the appeal of key identifier vs. issuer name for this mechanism (but name would work too and is arguably a firmer target). Thanks again, Aaron
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
