Subscriber-imposed certificate expiry

[davidben]

Certificates currently all expire as the batch expires, which come from a technical requirement of the mechanism. However, when requesting a certificate, the subscriber may have even tighter opinions on expiry, based on its own key management goals. Probably not likely with MTC certificate lifetimes, but we do mean for BikeshedCertificate to be extensible and ACME does allow the subscriber to request a notAfter date.

If the subscriber requests a tighter notAfter date than the corresponding batch, the ACME server would need to choose between not issuing a Merkle tree certificate, or extending the subscriber's vulnerability to it key longer than requested. We could avoid that by adding an extra expiration time inside the certificate. The semantics would be that you check both that expiration time and the batch-level one. (Equivalently, require they be consistent. But checking both may be more straightforward since we need the RP to check anyway.)

Not sure whether this should go in Assertion + AbridgedAssertion, or MerkleTreeProofSHA256 + HashAssertionInput. I'm envisioning the Assertion being something that the subscriber puts together, that plugs into CSRs and any other proof-of-possession checks. Saying that the subscriber's Assertion is byte-for-byte identical to the one in the certificate gives a lot of nice properties, but in other proof types, a CA may wish to express a tighter lifetime than what the subscriber requested. That would suggest the CA-imposed expiry, in general, needs to be outside the assertion. (CA-imposed expiry is implicit in MTCs, but may not be in other constructions.) But then we might want PoPs to express a subscriber-imposed expiry, which would mean this "check both CA- and subscriber-imposed expiry separately" model needs to become universal.

Put another way, it's the difference between:

• The statement "the key 1234 is good for example.com" is true until 2024-01-31
• The statement "the key 1234 is good for example.com until 2024-01-20" is true until 2024-01-31

[davidben]

Hmm, I may be overthinking this. Proof-of-possession schemes can still have expiry by just putting it outside the assertion. Having assertions themselves be timeless makes it a lot easier to say things like "I'm looking for sha256(assertion)", without having the identity of the assertion change over time.

Leaning towards doing it outside the assertion.

[bwesterb]

Makes sense. We should keep this in mind when designing revocation (#41): if we want revocation that's not aligned with the issue time of batches, then we could perhaps do this by issuing and immediately revoking at the intended expiry.

[davidben]

I think those are separate. Any kind of revocation scheme like that will necessarily be fuzzy (e.g. only work with RPs that have gotten a fresh push) because of all the usual reasons X.509-style revocation does not work.

This is about whether there should be a way to note, in the certificate, that the subscriber, at issuance time, did not want the key to last beyond Thursday.

[davidben]

Also really the only thing to design in "revocation" is some way to uniquely identify the certificate... which I suppose does have some connection to the question of where the expiration time goes, hmm...

[davidben]

Will do this as part of rebasing on trust anchor IDs. This avoids needing to define a CertificatePropertyList to pass in the expiration time out-of-band.

To avoid the expiration time and proof-induced time constraint getting out of sync, the expectation will be that all proof verification algorithms will reject any certificate whose expiration time is inconsistent with the proof. That is, for MTCs, the explicit expiration time must be at or before the batch expiration.

(The analogy in X.509 land would be saying that if cert1 is the issuer of cert2, we must have cert1.notBefore <= cert2.notBefore <= cert2.notAfter <= cert1.notAfter. Issuing a certificate that lasts longer than you is not an implicit clamping but an error.)