On Thu, Jul 20, 2023 at 08:38:23AM -0700, Aaron Gable wrote: > On Wed, Jul 19, 2023 at 11:16 PM Ilari Liusvaara <[email protected]> > 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?
The code does that so that renewal times are uniformly distributed over the window given, even in face of multi-look. Using random time would lead to severe bias in renewal times. And the inputs do include certificate identity, so even if CA sends the same window for multiple certificates, the chosen times will still be independent. > 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. And many OCSP implementations reject anything that is not SHA-1. So the hash algorithm used in OCSP is de-facto SHA-1. > 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. Feeding one recently issued end-entity cert (from Let's Encrypt R3) to dumpasn1: [...] 349 31: SEQUENCE { 351 3: OBJECT IDENTIFIER authorityKeyIdentifier (2 5 29 35) 356 24: OCTET STRING : 30 16 80 14 14 2E B3 17 B7 58 56 CB AE 50 09 40 : E6 1F AF 9D 8B 14 C2 C6 : } [...] ... That does not look like SHA-256... > 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. Actually, it turns out that IssuerNameHash + Serial is sufficient (RFC5280 requires that to be unique)! And those can be generated from the end-entity certificate. -Ilari _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
