> 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.
Issuer Key ID plus serial makes a lot of sense to me, and I think should be the request format. ------------------------------ 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 Thu, 20 Jul 2023 at 17:38, Aaron Gable <aaron= 40letsencrypt....@dmarc.ietf.org> wrote: > 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
