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

Carl Wallace <> Tue, 27 February 2024 10:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D3FFCC14F683 for <>; Tue, 27 Feb 2024 02:50:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5Aw4c98Q-Npb for <>; Tue, 27 Feb 2024 02:50:03 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 96CFFC14F60D for <>; Tue, 27 Feb 2024 02:50:03 -0800 (PST)
Received: by with SMTP id d75a77b69052e-42e86f37a0eso12778431cf.0 for <>; Tue, 27 Feb 2024 02:50:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1709031002; x=1709635802;; h=mime-version:in-reply-to:references:thread-topic:message-id:cc:to :from:subject:date:user-agent:from:to:cc:subject:date:message-id :reply-to; bh=Gm8SvmWjrWTQhwy3TcXVZDyxbQ66gW9oIbqSOi9T4/U=; b=CN3pH9GC4DGOjG/wEclPFjJOy1Lf/71eHHC8VMQQDh3cSIPMWyYfzJb/PpGS6vCqwN PRC9i2IYEGCvwqWAPpdT6obuaUBqLVQEgnstHJz2fix1sd4MeYsI2b2URq34F9jvcHcj cMs0/USATI2Hy0QcIlmADft9Jec74rw4t87hg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1709031002; x=1709635802; h=mime-version:in-reply-to:references:thread-topic:message-id:cc:to :from:subject:date:user-agent:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=Gm8SvmWjrWTQhwy3TcXVZDyxbQ66gW9oIbqSOi9T4/U=; b=RMipktmtCyS1Wry2gUL0U792uG/RjlLB/tOBNah5zy3eMoWXpMNmW/IkutXvaQj8q2 Yg6cITCYANwZSHRglBJa7phC3ETLNvZqGQKGMIu2ZxBbituVsVmgLECT0FI+AihBpdXf r7b994Exk5wWkAFU6L4POpD5uc3c1UHsAEk3wXiqTpswABDJq2J+NHxBYBNzDVbJHrAs xRFZPz59OCdbXiGf0TcgEdhgh8FP93SzNPPn93SrnxZLgFOpdx7aL93I2iAc1rEli3Ay XRaA3GTsdLxVWi33qEEodtgs63DVoCBOIssduqkuDgDPBACFDUKcnBw3HpSFpo7Mbeui WYxg==
X-Gm-Message-State: AOJu0Yw4xhmNLStNnFUr4j9bCs4bDKgK5P01/LRwJfDpFFOTaRT0fBUi oYrUZPh6Bs4aDhtDsIhXb/KKXbabthyBAKQpaiTtznvdrVqNKr3IS9lzugIXBgsuaj1Br4YUTUr t
X-Google-Smtp-Source: AGHT+IH0GAPzpvbHGtPdubNtjawoka2B0i4AW84ZLYMOCqE6YyGs6nK/XoW8hRWdlgraNZR7p5PQEQ==
X-Received: by 2002:a05:622a:1482:b0:42e:5f2b:7e45 with SMTP id t2-20020a05622a148200b0042e5f2b7e45mr12337464qtx.49.1709031001952; Tue, 27 Feb 2024 02:50:01 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id x9-20020ac85389000000b0042e1950d591sm3444172qtp.70.2024. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Feb 2024 02:50:01 -0800 (PST)
User-Agent: Microsoft-MacOutlook/16.82.24021813
Date: Tue, 27 Feb 2024 05:50:00 -0500
From: Carl Wallace <>
To: Aaron Gable <>
Message-ID: <>
Thread-Topic: [Acme] I-D Action: draft-ietf-acme-ari-03.txt
References: <> <> <>
In-Reply-To: <>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3791857801_3673119329"
Archived-At: <>
Subject: Re: [Acme] I-D Action: draft-ietf-acme-ari-03.txt
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Automated Certificate Management Environment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Feb 2024 10:50:07 -0000



From: Aaron Gable <>
Date: Tuesday, February 27, 2024 at 12:23 AM
To: Carl Wallace <>
Cc: <>
Subject: Re: [Acme] I-D Action: draft-ietf-acme-ari-03.txt


On Mon, Feb 26, 2024 at 4:36 AM Carl Wallace <> 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 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 "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,