Re: [Acme] I-D Action: draft-ietf-acme-ari-03.txt

[Rob Stradling <[e-mail]>]

Carl wrote:
> 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.

I think this is a reasonable request.

Aaron wrote:
> RFC 5280 requires both that the AKID extension be present and that the keyIdentifier field be present within it

I think it's worth pointing this out too.

> Do other members of this list think that using some form of the Issuer Name bytes would be better than using the keyIdentifier?

Only if "some form of the Issuer Name bytes" turns out to be the CertID structure used by OCSP and earlier ARI drafts!  Reusing an appropriate existing mechanism can have benefits, but if we're now talking about defining a new mechanism then I'll point out that Name matching can be a bit of a footgun...

From https://datatracker.ietf.org/doc/html/rfc5280#section-8:
   Inconsistent application of name comparison rules can result in
   acceptance of invalid X.509 certification paths or rejection of valid
   ones.  The X.500 series of specifications defines rules for comparing
   distinguished names that require comparison of strings without regard
   to case, character set, multi-character white space substring, or
   leading and trailing white space.  This specification relaxes these
   requirements, requiring support for binary comparison at a minimum.

   CAs MUST encode the distinguished name in the subject field of a CA
   certificate identically to the distinguished name in the issuer field
   in certificates issued by that CA.  If CAs use different encodings,
   implementations might fail to recognize name chains for paths that
   include this certificate.  As a consequence, valid paths could be
   rejected.

________________________________
From: Acme <[e-mail]> on behalf of Aaron Gable <aaron=[e-mail]>
Sent: 27 February 2024 05:23
To: Carl Wallace <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [Acme] I-D Action: draft-ietf-acme-ari-03.txt

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

On Mon, Feb 26, 2024 at 4:36 AM Carl Wallace <[e-mail]<mailto:[e-mail]>> 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?

- 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<https://datatracker.ietf.org/doc/html/rfc5280#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?

Thanks again,
Aaron