[Servercert-wg] Possible conflict between BR and RFC 6960?

Fri May 29 01:05:51 MST 2020

Dear Servercert-wg community,

NOTE: This message was originally posted to the Questions CA/B Forum Mailing List. Both Ryan and Dimitris thought severcert-wg would be a better place for discussing this topic, hence the repost.

I recently started working at a Dutch CA and am currently learning the PKI ropes, so to speak. I am doing this by reading RFC's, keeping up with ballots, and reading recent bug posts. All to get to know the current state of affairs in the wonderful world of PKI!

During my research I stumbled upon Apple's bug post (https://bugzilla.mozilla.org/show_bug.cgi?id=1588001) on OCSP responses being signed by the incorrect issuer. Reading the bug report itself makes everything look clear cut. However, when looking at RFC 6960 it looks less so. My colleagues have been unable to ease my mind on this one, so I thought it would be better to take this higher up in the food chain to try and get a clear answer. Let me elaborate.

RFC 6960 (OCSP) paragraph "2.2 Response" states:
"[..] 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
[...]
This specification defines the following definitive response indicators for use in the certificate status value:

*        Good

*        Revoked

*        Unknown
[...]
The "unknown" state indicates that the responder doesn't know about the certificate being requested, usually because the request indicates an unrecognized issuer that is not served by this responder.
[...]"

When reading CA/B Baseline Requirements paragraph "4.9.9 On-line Revocation/Status Checking Availability" it states:
"OCSP responses MUST conform to RFC6960 and/or RFC5019. OCSP responses MUST either:

1.      Be signed by the CA that issued the Certificates whose revocation status is being checked, or

2.      Be signed by an OCSP Responder whose Certificate is signed by the CA that issued the Certificate whose revocation status is being checked.
[...]"

Conflicting requirements
When comparing these two I can deduce the BR is stricter in who can sign a response: "a Trusted Responder whose public key is trusted by the requestor" is no longer allowed. This sounds reasonable. However, when looking at the three definitive responses in RFC 6960, it is only possible to adhere to the BR when answering with either "good" of "revoked". It is inherently impossible to do this for "unknown" because the issuer is unrecognized (not served by the responder).

Work-around in bug post
The approach used in the bug post is to not issue an "unknown" definitive response but an "unauthorized" error response. The fix in the incident report in the bug post reads: "Disabling the default OCSP responder ensures that the responder will reply 'unauthorized' (as per RFC 6960) for all unknown issuers." The way I interpret this is not as per RFC 6960, as it should reply with an "unknown" definitive response, and not with error message "unauthorized". See paragraph "2.3. Exception Cases" in RFC 6960:

"In case of errors, the OCSP responder may return an error message. These messages are not signed. Errors can be of the following types:

-        malformedRequest

-        internalError

-        tryLater

-        sigRequired

-        unauthorized
[...]
The response "unauthorized" is returned in cases where the client is not authorized to make this query to this server or the server is not capable of responding authoritatively (cf. [RFC5019], Section 2.2.3)."

I think everybody agrees on the first part of the definition of "unauthorized" in that the client itself is not authorized to make a query. This was not relevant in the case of the bug post. I assume people thought this was about "the server is not capable of responding authoritatively". However, "not capable of responding authoritatively" and "not an authorized responder" are two different things. The meaning of "not capable of responding authoritatively" is in fact (using a quite prosaic example) "Yes, I am in theory capable of giving an answer because I *do* know the issuer, but am just not *allowed* to because I cannot do this authoritatively; in the distributed environment I operate in the responder next to me has more up-to-date information on the requested certificate and therefore is the authoritative one". At least, that is the only way I can interpret RFC 6960 and the example they refer to in it in RFC 5019.

The way I see it right now is using the work-around in the bug post does fix the issue of not signing with the right issuer certificate in accordance to the BR, but introduces a new issue of being not compliant with RFC 6960.

Does this all make sense to you, or am I overlooking or misinterpreting anything?

How would I fix this?
If my ramblings do indeed make sense, the best way to solve this issue would be to do a small re-write of CA/B Baseline Requirements paragraph "4.9.9 On-line Revocation/Status Checking Availability", including mentioning the different ways of handling definitive and error responses (this now also has room for different interpretations!). For example:

"OCSP responses MUST conform to RFC6960 and/or RFC5019. OCSP definitive responses Good and Revoked MUST either:

1.      Be signed by the CA that issued the Certificates whose revocation status is being checked, or

2.      Be signed by an OCSP Responder whose Certificate is signed by the CA that issued the Certificate whose revocation status is being checked.
OCSP definitive response Unknown MUST be signed with a Trusted Responder whose public key is trusted by the requestor.
OCSP error responses MUST [in the RFC this is a MAY!] either:

1.      Be signed by the CA that issued the Certificates whose revocation status is being checked, or

2.      Be signed by an OCSP Responder whose Certificate is signed by the CA that issued the Certificate whose revocation status is being checked, or

3.      Be signed by a Trusted Responder whose public key is trusted by the requestor.
[...]"

Any thoughts on this?

Best regards,

Patrick van den Berg

Architect PKIoverheid
........................................................................
Logius
S&R/S&S/CvS, DigiN & PKIo
Ministerie van Binnenlandse Zaken en Koninkrijksrelaties
Wilhelmina van Pruisenweg 52 | 2595 AN | Den Haag
Postbus 96810 | 2509 JE | Den Haag
........................................................................
M 06-51 92 81 08
patrick.berg at logius.nl<mailto:patrick.berg at logius.nl>
http://www.logius.nl<http://www.logius.nl/>
........................................................................
Dienst digitale overheid

Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200529/7bc83379/attachment-0001.html>