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
