From nobody Wed Jul 26 09:53:07 2023 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8845C137367 for ; Wed, 26 Jul 2023 09:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.105 X-Spam-Level: X-Spam-Status: No, score=-7.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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=as207960.net Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEd_7ASew-FH for ; Wed, 26 Jul 2023 09:53:01 -0700 (PDT) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 73AE4C1526FF for ; Wed, 26 Jul 2023 09:53:00 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-5221f193817so6490288a12.3 for ; Wed, 26 Jul 2023 09:53:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=as207960.net; s=google; t=1690390379; x=1690995179; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=GBq0+w2uInyQOasxsNJbzN8wWZZT8I7k9R9kyJlNFTc=; b=g3P2sBpuwTH6NucIZ8PS93cl0BSa2oyV0bmbWqn9zPpr+890VpFuZSnIcmy6l08bVu r12vxOev0WBQ2bOWoIczDtBGhKqw7G74C7vUIfHKZj8v6TtVXV2T2aw7MxbWJOiZY9CX buvpxxQumXwLLKkCeWzpbMccptQISG3llVSZfZk2ErJHaQF00z2F18U5t0d6waf71CVS Z9n03ueSOpGzHU2XuPBXwKh+esWUkJMu1R2e+ZAZLn3+ohN7+mnbugKss5St2ClRPEA8 3wWO18Q1BJyHoFXzLUmubebO1YYFcUzSLRZox/nfPP0WSEYYU1SHgCJ0j5hMmzDiYVi0 Xvjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690390379; x=1690995179; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=GBq0+w2uInyQOasxsNJbzN8wWZZT8I7k9R9kyJlNFTc=; b=D/iBoxH1JzRLnZrPnTyzbC131AMoZFZGBjZyIA9XoNpUHO0r2TxLznotg/1zKrdC9k 4sXU8eRwWJ07rco8+3g/nalct7JVpua4boBG10//u7ULVXJzhEbkEyJNtMqoVpdxHYZT RlIssnPxPgY4adrQX/Cs4Adl7bFWO55aLZ1O6hnGDYRnONiAONfDJmRVYx6QJv9Ec4A5 PNfXryg2mPYWv5hWAijgbJ9xgcUt3x0omJOOzsmiHUz+m2Ku9Q+/2quurJ7pAkeazZ4o ruozSYrFrZriIPaRW3ZmhgeSFb60Dmd+OTnFKSieRha9XthUwv14iHK+3xOIjYDfR07P Bmtg== X-Gm-Message-State: ABy/qLZJoBwPehGNRAz6EEfpY1IEFP1RkZQHTTBz/CXWclcp8wTTq1PP 4ms6M81pE1DlKmuGDpx3JJ68JkyPcFzV9yzygi2sZw== X-Google-Smtp-Source: APBJJlEVxDwbA4jwbZViaQV3B9Y2xfv0kzzlArOnnlWwooS4v8sOPC9nNVoek30e7jJOLVkX8dGibjfKxOysESyPDrI= X-Received: by 2002:a17:906:32d0:b0:99b:57f0:68b5 with SMTP id k16-20020a17090632d000b0099b57f068b5mr2103921ejk.75.1690390378503; Wed, 26 Jul 2023 09:52:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Q Misell Date: Wed, 26 Jul 2023 09:52:22 -0700 Message-ID: To: Rob Stradling Cc: Aaron Gable , Ilari Liusvaara , "acme@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000af5e2060166aee1" Archived-At: Subject: Re: [Acme] Practical concerns of draft-ietf-acme-ari X-BeenThere: acme@ietf.org 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: Wed, 26 Jul 2023 16:53:06 -0000 --0000000000000af5e2060166aee1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > RFC5280 permits CAs to populate AuthorityKeyIdentifier.{authorityCertIssuer,authorityCertSerialNumber} instead of AuthorityKeyIdentifier.keyIdentifier. Do we instead use a structure containing the full AKI (as encoded in the certificate) and the serial number? This would seem to me to allow unique identification, without having the issuer certificate to hand. ------------------------------ Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under =E2=84=96 12417574 , LEI 875500FXNCJPAPF3PD10. ICO register =E2=84=96: ZA782876 . UK VAT =E2=84=96: GB378323= 867. EU VAT =E2=84=96: EU372013983. Turkish VAT =E2=84=96: 0861333524. South Korean= VAT =E2=84=96: 522-80-03080. AS207960 Ewrop O=C3=9C, having a registered office at L=C3=A4= =C3=A4ne-Viru maakond, Tapa vald, Porkuni k=C3=BCla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under =E2=84=96 16755226. Eston= ian VAT =E2=84=96: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under =E2=84=96 UK00003718474 and =E2=84=96 UK0000371= 8468, respectively. On Wed, 26 Jul 2023 at 08:56, Rob Stradling wrote: > > > For reasons I outlined in > https://mailarchive.ietf.org/arch/msg/acme/aoiW7X3lPYoQ6X8hhRGEvG3HDmo/, > I have a strong preference for sticking with CertID and an equally strong > preference against a 'return to the "url in the Order object" '. > > > > Returning to that message, the main impression I get is that you want > ARI to be implementable outside of an ACME server, so you can implement i= t > in OCSP responder infrastructure. > > Hi Aaron. Yes, that's my goal. > > > This makes sense, but raises two questions in my mind: > > 1) How do you intend to achieve this goal now that ARI includes POST > protocols which by definition must be aware of ACME user accounts? > > The "renewalInfo" resource in each of our ACME server directory objects > will point to our ACME server web frontend, which will handle POST reques= ts > directly (using our ACME server backend, which is part of our CA system) > but will either proxy or HTTP-redirect GET requests to our OCSP > infrastructure. I'm expecting the "heavy-polling nature of ARI" (as you > phrased it) to only affect GET requests, so I think we should be fine wit= h > splitting the traffic in this manner. > > FWIW, our intent is that our OCSP infrastructure will also respond to ARI > GET requests for certificates issued via non-ACME mechanisms. I realise > this is out of scope for draft-ietf-acme-ari and the ACME WG, but I feel > that it makes sense to do it. The GET request part of ARI is not tied to > the ACME protocol, and the goals expressed in > https://www.ietf.org/archive/id/draft-ietf-acme-ari-01.html#section-1 are > not unique to the ACME protocol. > > > 2) This desire doesn't seem tied to the CertID structure itself, just t= o > the idea of independently-constructable ARI request URLs. Would you be ok= ay > with a different structure, as long as it is still externally constructab= le? > > Yes, I'm OK with that in principle. > > I have a strong preference for basing ARI requests on certificate serial > numbers rather than thumbprints: selfishly, our OCSP infrastructure is > already geared up to handle serial number lookups; but also, it's harder > for a client to mangle a serial number than a thumbprint (e.g., consider > non-canonical encodings of the copy of the signature parameters that isn'= t > covered by a certificate's signature). > > To unambiguously identify the issuer, I suppose CABForum BR-compliant CAs > could maybe live with ARI using the certificate's > AuthorityKeyIdentifier.keyIdentifier field (as others have proposed alrea= dy > on this thread), because the BRs forbid CAs from populating the > AuthorityKeyIdentifier.{authorityCertIssuer,authorityCertSerialNumber} > fields. However, we're defining ARI in the context of IETF, not CABForum= ; > and in the IETF context, RFC5280 permits CAs to > populate AuthorityKeyIdentifier.{authorityCertIssuer,authorityCertSerialN= umber} > instead of AuthorityKeyIdentifier.keyIdentifier. ACME has already seen > adoption beyond the initial WebPKI use case, so I think we should expect > ARI to need to support non-WebPKI use cases too. > > Is it required that a CA's Subject DN must be globally unique? No. > > Is it required that a CA's SubjectPublicKeyInfo must be globally unique? > Again, no. > > If two CAs have different Subject DNs but share the same > SubjectPublicKeyInfo, should we consider them to be the same CA or > different CAs? > > OCSP would answer "different CAs", judging by the definition of the CertI= D > structure. FWIW, crt.sh takes the "different CAs" view too...and BTW thi= s > isn't just a theoretical question: crt.sh knows of >160 > SubjectPublicKeyInfos that are each associated with >1 Subject DN (see > [1]). One example: https://crt.sh/?caid=3D65461 and > https://crt.sh/?caid=3D65479. > > Considering all of these edge and corner cases in the context of ARI...I > can't help but wonder if CertID might actually be the least worst tool fo= r > the job. > > Is it really a problem if the ARI protocol requires the ARI client to > possess a copy of the issuer certificate? > Are there realistic scenarios in which an ARI client would not be able to > locate a copy of the issuer certificate? > > > [1] psql -h crt.sh -p 5432 -U guest -d certwatch -c "select count(*), > min(name), max(name) from ca group by public_key having count(*) > 1 and > min(name) !=3D max(name) order by count(*);" > > ------------------------------ > *From:* Acme on behalf of Aaron Gable 40letsencrypt.org@dmarc.ietf.org> > *Sent:* 20 July 2023 16:38 > *To:* Ilari Liusvaara > *Cc:* acme@ietf.org > *Subject:* Re: [Acme] Practical concerns of draft-ietf-acme-ari > > > 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 Wed, Jul 19, 2023 at 11:16=E2=80=AFPM Ilari Liusvaara > wrote: > > E.g., the client might be deterministically generating renewal time > from window (the client I wrote does this). This works nicely if the > renewal window does not shift around. However, it becomes heavily > biased toward beginning of the window if the window shifts around. > > > Why? The draft specifically says that clients should be choosing a time > within the window randomly, not deterministically. What's the motivation > (and method) for doing a deterministic derivation? > > On Wed, Jul 19, 2023 at 11:16=E2=80=AFPM Ilari Liusvaara < > ilariliusvaara@welho.com> wrote: > > The single most annoying part of the process is the hash of the issuer > key. For that, you need the issuer certificate, while everything else > can be pulled from the subject certificate. > > > On Thu, Jul 20, 2023 at 3:31=E2=80=AFAM Deb Cooley wrote: > > Issuer key hash: Is this not in the Authority Key ID extension? Or is > this extension not used? > > If these things are not the same, my recommendation would be to use > Authority Key ID value as a way to ID the issuing CA. > > > On Thu, Jul 20, 2023 at 7:10=E2=80=AFAM Ilari Liusvaara > wrote: > > AFAICT, no. > > RFC5280 merely recommends a construction for AKI, that nevertheless > happens to match value used by issuer key hash in OCSP. > > However: > > 1) One can not rely on this, because some CAs do it differently. > > 2) The value used in ARI is computed using SHA-256, and does not match > the recommended AKI construction. > > > To be clear, the issuer hashes in ARI are *not* computed using SHA-256, > they're computed using any hash algorithm of the client's choice, just li= ke > OCSP. This is what I meant when I said that OCSP's "CertID" structure has > "algorithm agility": it has an algorithm field which must be set to the > algorithm used to hash the Issuer Name and Issuer Key. Let's Encrypt's AR= I > implementation happens to reject any requests which use an algorithm othe= r > than SHA-256, but that's not part of the draft. > > Producing the IssuerNameHash is easy from just the end-entity certificate= , > since the Issuer Name is of course embedded in it. > > Producing the IssuerKeyHash is *almost* easy from just the end-entity > certificate, but in fact impossible to guarantee correct. For example, if= a > CA follow's RFC 5280 Section 4.2.1.2 to construct their Subordinate CA > Certificates' Subject Key Identifier (specifically "The keyIdentifier is > composed of the 160-bit SHA-1 hash of the value of the BIT STRING > subjectPublicKey (excluding the tag, length, and number of unused bits)")= , > then the end-entity cert's IssuerKeyID is exactly the needed IssuerKeyHas= h > with a hash algorithm of SHA-1. Similarly, all of Let's > Encrypt's Subordinate CA Certs use the exact same method ( > https://github.com/letsencrypt/boulder/blob/908421bb98c11c8ffce640029b635= 7446c528cfb/cmd/ceremony/cert.go#L199-L209), > except with SHA-256 instead of SHA-1. So it is *technically* possible for > clients to simply extract the AuthorityKeyId, transfer it to the CertID, > and submit it to Let's Encrypt's ARI endpoint. > > However, there's no way to guarantee that. The AuthorityKeyID field gives > no indication of how it was produced, and there's no way to guarantee tha= t > a CA will continue to use the same method over time. So to guarantee > correctness, a client can't rely on the AKID and has to use the Issuer ce= rt > to re-derive the Issuer Key Hash. > > This is very unfortunate, and is the primary reason that I'm seriously > considering changing the request format. It would be truly nice for the > request to be constructable using *only* the end-entity cert. > > Maybe it would be best to state "Hey, the CA generated its own Issuer Key > IDs, it can be expected to recognize them too", and make the request simp= ly > IssuerKeyID + Serial, in some simple concatenate+base64url format. > > On Thu, Jul 20, 2023 at 4:14=E2=80=AFAM Rob Stradling 40sectigo.com@dmarc.ietf.org> wrote: > > For reasons I outlined in > https://mailarchive.ietf.org/arch/msg/acme/aoiW7X3lPYoQ6X8hhRGEvG3HDmo/, > I have a strong preference for sticking with CertID and an equally strong > preference against a 'return to the "url in the Order object" '. > > > Returning to that message, the main impression I get is that you want ARI > to be implementable outside of an ACME server, so you can implement it in > OCSP responder infrastructure. This makes sense, but raises two questions > in my mind: > 1) How do you intend to achieve this goal now that ARI includes POST > protocols which by definition must be aware of ACME user accounts? > 2) This desire doesn't seem tied to the CertID structure itself, just to > the idea of independently-constructable ARI request URLs. Would you be ok= ay > with a different structure, as long as it is still externally constructab= le? > > Thanks, > Aaron > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --0000000000000af5e2060166aee1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0RFC5280 permits CAs to populate Authorit= yKeyIdentifier.{authorityCertIssuer,authorityCertSerialNumber} instead of A= uthorityKeyIdentifier.keyIdentifier.

Do we instead use= a structure=C2=A0containing the full AKI (as encoded in the certificate) a= nd the serial number? This would=C2=A0seem to me to allow unique identifica= tion, without having the issuer certificate to hand.

Any statements contained in this email are personal to the author and are= not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, = Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company register= ed in Wales under =E2=84=96 12417574, LE= I 875500FXNCJPAPF3PD10. ICO register =E2=84=96: ZA782876. UK VAT =E2=84=96: GB378323867. EU VAT =E2=84=96: EU372013983. Turkish VAT =E2=84=96: 0861333524. South Korean VAT =E2=84=96: 522-80-03080.=20 AS207960 Ewrop O=C3=9C, having a registered office at L=C3=A4=C3=A4ne-Vir= u maakond, Tapa vald, Porkuni k=C3=BCla, Lossi tn 1, 46001, trading as Glau= ca Digital, is a company registered in Estonia under =E2=84=96 16755226. Es= tonian VAT =E2=84=96: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, u= nder =E2=84=96 UK00003718474 and =E2=84=96 UK00003718468, respectively.



On Wed, 26 Jul 2023 at 08:56, Rob Stradling <rob=3D<= a href=3D"mailto:40sectigo.com@dmarc.ietf.org">40sectigo.com@dmarc.ietf.org= > wrote:
> > For reasons I outlined in https:= //mailarchive.ietf.org/arch/msg/acme/aoiW7X3lPYoQ6X8hhRGEvG3HDmo/, I ha= ve a strong preference for sticking with CertID and an equally strong prefe= rence against a 'return to the "url in the Order object" '= ;.
>
>=C2=A0Returning to that message, the main impression I get is tha= t you want ARI to be implementable outside of an ACME server, so you can im= plement it in OCSP responder infrastructure.

Hi Aaron.=C2=A0 Yes, that's my goal.

> This makes sense, but raises two questions in my mind:
>=C2=A01) How do you intend to achieve this goal now that ARI inclu= des POST protocols which by definition must be aware of ACME user accounts?=

The "renewalInfo" resource in each of our ACME server direct= ory objects will point to our ACME server web frontend, which will handle P= OST requests directly (using our ACME server backend, which is part of our = CA system) but will either proxy or HTTP-redirect GET requests to our OCSP infrastructure.=C2= =A0=C2=A0I'm expecting the "heavy-polling nature of ARI"= ; (as you phrased it) to only affect GET requests, so I think we should be = fine with splitting the traffic in this manner.

FWIW, our intent is that our OCSP infrastructure will also respond to = ARI GET requests for certificates issued via non-ACME mechanisms.=C2=A0 I r= ealise this is out of scope for draft-ietf-acme-ari and the ACME WG, but I feel that it makes sense to do it.=C2=A0 The GET request pa= rt of ARI is not tied to the ACME protocol, and the goals expressed in=C2= =A0https://www.ietf.org/archive/id/draft-ietf-acme= -ari-01.html#section-1=C2=A0are not unique to the ACME protocol.

>=C2=A02) This desire doesn't seem tied to the CertID structure itse= lf, just to the idea of independently-constructable ARI request URLs. Would= you be okay with a different structure, as long as it is still externally = constructable?

Yes, I'm OK with that in principle.

I have a strong preference for basing ARI requests on c= ertificate serial numbers rather than thumbprints: selfishly, our OCSP infr= astructure is already geared up to handle serial number lookups; but also, it's harder for a client= to mangle a serial number than a thumbprint (e.g., consider non-canonical = encodings of the copy of the signature parameters that isn't covered by= a certificate's signature).

To unambiguously identify the issuer, I suppose CABForum BR-compliant CAs c= ould maybe live with ARI using the certificate's AuthorityKeyIdentifier= .keyIdentifier field (as others have proposed already on this thread), beca= use the BRs forbid CAs from populating the AuthorityKeyIdentifier.{authorityCertIssuer,authorityCertSerialNumber}= fields.=C2=A0 However, we're defining ARI in the context of IETF, not = CABForum; and in the IETF context, RFC5280 permits CAs to populate=C2=A0Aut= horityKeyIdentifier.{authorityCertIssuer,authorityCertSerialNumber} instead of=C2=A0AuthorityKeyIdentifier.keyIdentifier.=C2=A0 ACME has alrea= dy seen adoption beyond the initial WebPKI use case, so I think we should e= xpect ARI to need to support non-WebPKI use cases too.

Is it required that a CA's Subject DN must be globally unique?=C2=A0 No= .

Is it required that a CA's SubjectPublicKeyInfo must be globally unique= ?=C2=A0 Again, no.

If two CAs have different Subject DNs but share the same SubjectPublicKeyIn= fo, should we consider them to be the same CA or different CAs?

OCSP would answer "different CAs", judging by the definition of t= he CertID structure.=C2=A0 FWIW, crt.sh takes the "different CAs"= view too...and BTW this isn't just a theoretical question: crt.sh know= s of >160 SubjectPublicKeyInfos that are each associated with >1 Subject DN (see [1]).=C2=A0 One example:=C2=A0https://crt.sh/?caid=3D65461=C2=A0= and=C2=A0https:/= /crt.sh/?caid=3D65479.

Considering all of these edge and corner cases in the context of ARI...I can't help but wonder if CertID might actually be the= least worst tool for the job.

Is it really a problem if the ARI protocol requires the= ARI client to possess a copy of the issuer certificate?
Are there realistic scenarios in which an ARI client wo= uld not be able to locate a copy of the issuer certificate?


[1] psql -h crt.sh -p 5432 -U guest -d certwatch -c "select count(*), = min(name), max(name) from ca group by public_key having count(*) > 1 and= min(name) !=3D max(name) order by count(*);"

From: Ac= me <acme-boun= ces@ietf.org> on behalf of Aaron Gable <aaron=3D40letsencrypt.org@dmar= c.ietf.org>
Sent: 20 July 2023 16:38

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.

E.g., the client might be deterministically generating renewal time
from window (the client I wrote does this). This works nicely if the
renewal window does not shift around. However, it becomes heavily
biased toward beginning of the window if the window shifts around.

Why? The draft specifically says that clients should be choosing a tim= e within the window randomly, not deterministically. What's the motivat= ion (and method) for doing a deterministic derivation?

=C2=A0On Wed, Jul 19, 2023 at 11:16=E2=80=AFPM Ilari Liusvaara <ilariliusvaara@w= elho.com> wrote:
The single most annoying part of the process is the hash of the issuer
key. For that, you need the issuer certificate, while everything else
can be pulled from the subject certificate.

=C2=A0On Thu, Jul 20, 2023 at 3:31=E2=80=AFAM Deb Cooley <debcooley1@gmail.com= > wrote:
Issuer key hash:=C2=A0 Is this not in the Authority Key ID extension?= =C2=A0 Or is this extension not used?=C2=A0

If these things are not the same, my recommendation would be to use Au= thority Key ID value as a way to ID the issuing CA.

=C2=A0On Thu, Jul 20, 2023 at 7:10=E2=80=AFAM Ilari Liusvaara <ilariliusvaara@we= lho.com> wrote:
AFAICT, no.

RFC5280 merely recommends a construction for AKI, that nevertheless
happens to match value used by issuer key hash in OCSP.

However:

1) One can not rely on this, because some CAs do it differently.

2) The value used in ARI is computed using SHA-256, and does not match
=C2=A0 =C2=A0the recommended AKI construction.

To be clear, the issuer hashes in ARI are *not* computed using SHA-256= , they're computed using any hash algorithm of the client's choice,= just like OCSP. This is what I meant when I said that OCSP's=C2=A0&quo= t;CertID" structure has "algorithm agility": it has an algorithm field which must be set to the algorithm used to hash the Issuer= Name and Issuer Key. Let's Encrypt's ARI implementation happens to= reject any requests which use an algorithm other than SHA-256, but that= 9;s not part of the draft.

Producing the IssuerNameHash is easy from just the end-entity certific= ate, since the Issuer Name is of course embedded in it.

Producing the IssuerKeyHash is *almost* easy from just the end-entity = certificate, but in fact impossible to guarantee correct. For example, if a= CA follow's RFC 5280 Section 4.2.1.2 to construct their Subordinate CA= Certificates' Subject Key Identifier (specifically "The keyIdentifier is composed of the 160-bit SHA-1 has= h of the value of the BIT STRING subjectPublicKey (excluding the tag, lengt= h, and number of unused bits)"), then the end-entity cert's Issuer= KeyID is exactly the needed IssuerKeyHash with a hash algorithm of SHA-1. Similarly, all of Let's Encrypt's=C2=A0= Subordinate CA Certs use the exact same method (https://github.com/letsencrypt/= boulder/blob/908421bb98c11c8ffce640029b6357446c528cfb/cmd/ceremony/cert.go#= L199-L209), except with SHA-256 instead of SHA-1. So it is *technically* possible for = clients to simply extract the AuthorityKeyId, transfer it to the CertID, an= d submit it to Let's Encrypt's=C2=A0ARI endpoint.

However, there's no way to guarantee that. The AuthorityKeyID fiel= d gives no indication of how it was produced, and there's no way to gua= rantee that a CA will continue to use the same method over time. So to guar= antee correctness, a client can't rely on the AKID and has to use the Issuer cert to re-derive the Issuer Key Hash.<= /div>

This is very unfortunate, and is the primary reason that I'm serio= usly considering changing the request format. It would be truly nice for th= e request to be constructable using *only* the end-entity cert.

Maybe it would be best to state "Hey, the CA generated its own Is= suer Key IDs, it can be expected to recognize them too", and make the = request simply IssuerKeyID=C2=A0+ Serial, in some simple concatenate+base64= url format.

On Thu, Jul 20, 2023 at 4:14=E2=80=AFAM Rob Stradling <= rob=3D40s= ectigo.com@dmarc.ietf.org> wrote:
For reasons I outlined in https://mailarchive.ietf.org/arch/msg/acme/aoiW7X3lPYoQ6X8hhRGEvG3HDmo/= , I have a strong preference for sticking with CertID and an equally strong= preference against a 'return to the "url in the Order object"= ; '.

Returning to that message, the main impression I get is that you want = ARI to be implementable outside of an ACME server, so you can implement it = in OCSP responder infrastructure. This makes sense, but raises two question= s in my mind:
1) How do you intend to achieve this goal now that ARI includes POST p= rotocols which by definition must be aware of ACME user accounts?
2) This desire doesn't seem tied to the CertID structure itself, j= ust to the idea of independently-constructable ARI request URLs. Would you = be okay with a different structure, as long as it is still externally const= ructable?

Thanks,
Aaron=C2=A0
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
--0000000000000af5e2060166aee1--