In September 2025 the current R3 is going to expire. For that time a new intermediate must already be issued. Will the key of this new intermediate certificate the same as the current R3, or will it have different key?
If the keys are different, I have a second question.
At this moment the same key is signing the leaf certificates as the OCSP signing certificate's key.
Will the OCSP signing key stay as its certificate signing key for each leaf certificate during the transition period of the intermediate certificate?
Or, will the OCSP signing key suddenly change for the new key even if it is not matching the leaf certificate's signing key?
It affects the OCSP verification configuration scripting for BigIP F5. It is a design decision to be made today. I already assumed that the OCSP signing key always matches the certificate signing key. Even during the intermediate transition period when there are valid certificates overlapping in time, some signed with the old and some signed with the new signing key. I just want to be sure on my design.
In the transition from Let's Encrypt Authority X1 to Let's Encrypt Authority X3 the same keypair was re-used. However the transition from Let's Encrypt Authority X3 to R3 used a new keypair.
If I recall correctly, the X1 transition from X1 to X3 was made early (after less than 1 year) due to an extension issue (X509v3 Name Constraints) causing issues.
Therefore it is likely that a normal, planned transition will involve a new key. That also makes sense from a cryptographic hygiene point of view.
I don't really understand what the question is here, so I'm going to clarify a few things that may be of help.
RFC 6960 states:
The key that signs a certificate's status information need not be the
same key that signed the certificate. It is necessary, however, to
ensure that the entity signing this information is authorized to do
so. Therefore, a certificate's issuer MUST do one of the following:
sign the OCSP responses itself, or
explicitly designate this authority to another entity
OCSP signing delegation SHALL be designated by the inclusion of
id-kp-OCSPSigning in an extended key usage certificate extension
included in the OCSP response signer's certificate. This certificate
MUST be issued directly by the CA that is identified in the request.
Let's Encrypt has never used a delegated responder certificate for intermediate certificates (they used to have one for the root though).
Therefore OCSP responses for leaf certificates will always be signed by the issuing certificate's key.
In simple words:
If you have a certificate signed by Let's Encrypt Authority X3:
All OCSP responses are signed by X3, over the entire certificate's lifetime
If you have a certificate signed by R3:
All OCSP responses are signed by R3, over the entire certificate's lifetime
If you have a certificate signed by a future certificate ("R5"):
All OCSP responses are signed by "R5", over the entire certificate's lifetime
The more relevant bits I got from the spec (thanks, @Nummer378) are in the next paragraphs.
My reading is that your client MUST handle the following, in a situation where there is a migration from R3 to R4:
The OCSP is signed by the same certificate (R4) that issued the Leaf Certificate
The OCSP is signed by a Delegated Certificate (R4-OSCP), said Delegated Certificate having been signed by the same certificate (R4) that signed the Leaf Certificate
The OCSP could also be signed by a Delegated Certificate (R5-OSCP), said Delegated Certificate NOT having been signed by the same certificate that signed the Leaf Certificate - but your client is not required to accept that by the spec, so the practice is explicitly discouraged.
There is a lot of time to prepare for these 3 scenarios, but IMHO it would be great if ISRG could commit to reducing this down to 1 or 2.
Edited to add: I understand the value and importance of being specs and being RFC compliant, the reality is that implementations are often broken -- especially with ACME stuff as we have recently learned when many (most?) clients hard-coded intermediates. Planning for the simplest migration path to minimize issues - at least for a period of time after the initial changeover - would be in the best interests of the internet as a whole.
The CA SHOULD use the same issuing key to issue a delegation
certificate as that used to sign the certificate being checked for
revocation. Systems relying on OCSP responses MUST recognize a
delegation certificate as being issued by the CA that issued the
certificate in question only if the delegation certificate and the
certificate being checked for revocation were signed by the same key.
Note: For backwards compatibility with RFC 2560 [RFC2560], it is not
prohibited to issue a certificate for an Authorized Responder
using a different issuing key than the key used to issue the
certificate being checked for revocation. However, such a
practice is strongly discouraged, since clients are not
required to recognize a responder with such a certificate as an
Authorized Responder.
Systems or applications that rely on OCSP responses MUST be capable
of detecting and enforcing the use of the id-kp-OCSPSigning value as
described above. They MAY provide a means of locally configuring one
or more OCSP signing authorities and specifying the set of CAs for
which each signing authority is trusted. They MUST reject the
response if the certificate required to validate the signature on the
response does not meet at least one of the following criteria:
Matches a local configuration of OCSP signing authority for the
certificate in question, or
Is the certificate of the CA that issued the certificate in
question, or
Includes a value of id-kp-OCSPSigning in an extended key usage
extension and is issued by the CA that issued the certificate in
question as stated above.
I can say we're unlikely to start using delegated OCSP signers (they increase the size of OCSP responses), but of course I can't guarantee it - if we do choose to do so, it would be the responsibility of Relying Party software to handle it.
@bruncsak can you tell us more about the context of your request? You mention BigIP F5's. If this is for general-purpose OCSP validation, of course you'd need to handle delegated OCSP signing. If it's for an ACME client - ideally that ACME client could be configured to use a range of different providers, now that there are so many ACME CAs. So there may be other providers that use delegated OCSP signing.
BigIP F5 itself handles the OCSP validation internaly, with the condition that the "trusted certificate" is configured correctly for the OCSP object. As the above discussion clearly indicates that always the same key signs the certificate and the OCSP reply (even during the rollover to the new intermediate), I can safely use the certificate's intermediate signing certificate in the role of the "trusted certificate" for the BigIP F5 OCSP objects.
The OCSP validation configured for the certificates is the enabler for the option of OCSP stapling on the virtual hosts. Enabling that option is my goal.
It's entirely possible that BigIP F5 already handles this correctly for the delegated signer case. An OCSP response that uses a delegated signer has to include that signer in the response. So if the F5 API takes a root or intermediate, along with an OCSP response, it should be capable of saying "oh, this OCSP response is signed by a different certificate than the issuer of the end entity certificate I'm validating. Is it the embedded certificate in the response? If so, is that embedded certificate signed by the issuer of the end-entity certificate?"
Hopefully the BigIP docs would indicate this but unfortunately PKI-related docs are often kinda thin.
Buypass (really sorry to summon a competitor here) is using the method of delegated certificate for OCSP signing. This delegated certificate is signed with the intermediate of course.
We're just half way the intermediates lifetime.