3

Is this Public Key Infraestructure possible according with the RFC 6960 Online Certificate Status Protocol - OCSP, Authorized Responders?

OCSP

OCSP response for Cert is signed with a certificate issued by Sub CA 2.

Reading the specification for the signature of an Authorized Responder

  1. Matches a local configuration of OCSP signing authority for the certificate in question, or 2. Is the certificate of the CA that issued the certificate in question, or 3. 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 am not sure if this case is allowed. My own answer will be NO, but also is present

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

Improve this question

1 Answer 1

Reset to default
3

You just answered your question, it is possible (though, strongly discouraged). Even RFC6960-conformant clients should support this scenario.

For example, Microsoft CryptoAPI allows this scenario even when OCSP signing certificate chains up to different root (which must be trusted) by default. Source: What’s New in Certificate Revocation in Windows Vista and Windows Server 2008

Windows Vista SP1 and Windows Server 2008 enable the OCSP signing certificate implemented by the OCSP responder to use a certificate that terminates in a different root CA than the CA whose revocation information is reported in the OCSP responses. This feature enables an organization with a diverse PKI to limit sources of revocation information and the CAs that can issue OCSP signing certificates.

Microsoft do not fully support RFC2560 nor RFC6960, because they rely on their own RFC5019 in reagrds to OCSP.

This means that you should take into consideration deployment environments and their specifics.

Improve this answer
2
  • In fact, I asked this question because Adobe reader was not trusting my PDF signatures until I have signed the ocsp response with the same CA (SubCA1 in the picture). I guess adobe omits that Note intentionally
    – pedrofb
    Jan 9, 2017 at 11:38
  • It is up to specific implementation. Yes, we have standards track in RFC, but it is common when implementations only partially support particular RFC or even violate it due to their vision of the question. In other words, RFC is RFC, reality is a bit different thing.
    – Crypt32
    Jan 9, 2017 at 11:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .