> 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 № 12417574 <https://find-and-update.company-information.service.gov.uk/company/12417574>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively. On Wed, 26 Jul 2023 at 08:56, Rob Stradling <rob= 40sectigo....@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. > > 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 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. 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 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. 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 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 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 already > 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,authorityCertSerialNumber} > 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 CertID > structure. FWIW, crt.sh takes the "different CAs" view too...and BTW this > 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=65461 and > https://crt.sh/?caid=65479. > > 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 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) != max(name) order by count(*);" > > ------------------------------ > *From:* Acme <acme-boun...@ietf.org> on behalf of Aaron Gable <aaron= > 40letsencrypt....@dmarc.ietf.org> > *Sent:* 20 July 2023 16:38 > *To:* Ilari Liusvaara <ilariliusva...@welho.com> > *Cc:* acme@ietf.org <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 PM Ilari Liusvaara <ilariliusva...@welho.com> > 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 PM Ilari Liusvaara < > ilariliusva...@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 AM Deb Cooley <debcool...@gmail.com> 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 AM Ilari Liusvaara <ilariliusva...@welho.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 > 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 like > 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 ARI > implementation happens to reject any requests which use an algorithm other > 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 IssuerKeyHash > 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/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, > 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 that > 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 cert > 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 simply > IssuerKeyID + Serial, in some simple concatenate+base64url format. > > On Thu, Jul 20, 2023 at 4:14 AM Rob Stradling <rob= > 40sectigo....@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 okay > with a different structure, as long as it is still externally constructable? > > Thanks, > Aaron > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
