Dear list,
I have a question about the issuance of the OCSP responder certificates in case
of technically constrained CAs. I apologize for the long introduction, but this
may be an important audit question in the (near) future.
--- BEGIN INTRO ---
I would like to cite five points from the relevant requirements.
1. Section 5.3.1 of Mozilla Policy declares that "We encourage CAs to
technically constrain all intermediate certificates." and in 5.3 we can read:
"Intermediate certificates created after January 1, 2019, with the exception of
cross-certificates that share a private key with a corresponding root
certificate: MUST contain an EKU extension; and, MUST NOT include the
anyExtendedKeyUsage KeyPurposeId; and, * MUST NOT include both the
id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds in the same
certificate."
2. If an issuer CA is technically constrained, the CA certificate will contain
one or more of Extended Key Usage (EKU) extensions as specified in 4.2.1.12 of
RFC 5280. (e.g. id-kp-serverAuth, id-kp-clientAuth, id-kp-emailProtection,
id-kp-OCSPSigning ...) with the corresponding Key Usage (KU) bits (e.g.
digitalSignature, keyCertSign, cRLSign).
3. CAB Forum Baseline requires the support of the OCSP service in 4.9.9 and
4.9.10, moreover ETSI EN 319 411-1 requires it also: "CSS-6.3.10-07 [PTC]: OCSP
shall be supported."
Microsoft Root Program requires in Section 4.A.5. that "All end-entity server
authentication certificates must contain an AIA extension with a valid OCSP
URL."
So, OCSP service is mandatory for the issuers of the publicly trusted
certificates.
4. RFC 6960 details the signature of OCSP responses in 2.2:
"All definitive response messages SHALL be digitally signed. The key
used to sign the response MUST belong to one of the following:
- the CA who issued the certificate in question
- a Trusted Responder whose public key is trusted by the requestor
- a CA Designated Responder (Authorized Responder, defined in
Section 4.2.2.2) who holds a specially marked certificate issued
directly by the CA, indicating that the responder may issue OCSP
responses for that CA".
5. Section 4.2.2.2. of RFC 6960 explains that "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.
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."
--- END INTRO ---
My question is the following: is it allowed to issue an OCSP Responder
certificate with "id-kp-OCSPSigning" EKU from a technically constrained CA if
the "id-kp-OCSPSigning" EKU is not listed in the CA certificate, in other
words, is the inclusion of the "id-kp-OCSPSigning" EKU a possible, mandatory or
forbidden option for such CAs?
As I see in the practice, if a technically constrained CA signs the OCSP
response itself, it can be done without the "id-kp-OCSPSigning" EKU but with
the "digitalSignature" KU bit in the CA certificate.
I followed the relating discussion in the archive (Feb 1, 2013) and found this:
"Inclusion of EKU in CA certificates is generally allowed.
(...)
The use of the EKU extension in intermediate certificates was
discussed at length in the mozilla.dev.security.policy forum. We
considered other options, such as standardizing a set of Policy OIDs or
un-deprecating NetscapeCertType. The discussion included the concern
that one interpretation of RFC 5280 is that this use of EKU is
non-standard, but it was decided that the RFCs are not clear, and
perhaps conflicting, in regards to EKUs in CA certificates. In the
discussion it was pointed out that other major browsers and client
software already support this use of EKU but do not recognize
NetscapeCertType; and we also recognized the difficulties involved in
standardizing a set of Policy OIDs. The conclusion of the discussion was
that EKU is the best tool for technically constraining the types of
certificates that an intermediate certificate may sign."
But this answer is not so clear for me in case of issuer CA certificates if the
CA wants to authorize a CA Designated Responder as its OCSP responder. I am
sorry if I missed something.
I am grateful for any opinion, thank you in advance!
Peter
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
