Subject: [pkix] Addressing issues in 4.2.2.2 of rfc2560bis-08

From: "Piyush Jain" <[email-masked]>
Date: Sat, 12 Jan 2013 07:49:34 -0800

Hi list,

Here is the proposal to address the issue in section 4.2.2.2 that I brought
up in bullet point 4 of my original review post . You don't need to refer to
that post. Context is provided below.

CURRENT TEXT 

Systems or applications that rely on OCSP responses MUST be capable of
detecting and enforcing 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 fails to meet at least
one of the following criteria:
   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 ExtendedKeyUsage extension
and is issued by the CA that issued the certificate in question as stated
above."

ISSUES
- Creates a paradox If (2) or (3) are used to establish trust in the
response and if the response is marked as revoked because certificate was
"not-issued". If the RP trusts response, it implies that the certificate was
not issued by the CA which implies that the RP should not trust the
response. This can be addressed by changing all references to "issued" to
"signed" in the above text. Please not that this is a problem only for
certificates that exist, not for non-existent certificate. RPs who send
queries for non-existent certificates have no way to establish trust in the
response if the response is signed by a delegated responder.
- If the RP determines that certificate was signed by the CA and if the
response is marked as revoked with extended revoked definition, it implies
that RP has encountered a certificate signed by the CA for which CA has no
record of issuance. Most likely cause for this is RA/CA compromise. Others
have pointed out there may be some 'not so severe' reasons such as loss of
issuance record etc. Unfortunately, there is no way for the responder to
communicate the exact reason to the RP and RPs should assume the worst case
scenario.

PROPOSED TEXT

Systems or applications that rely on OCSP responses MUST be capable of
detecting and enforcing 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 fails to meet at least
one of the following criteria:
   1. Matches a local configuration of OCSP signing authority for the
certificate in question; or
   2. Is the certificate of the CA that signed the certificate in question;
or
   3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage extension
and is signed by the CA that signed the certificate in question as stated
above."

If the response trust is established by using either (1) or (2) and if the
response status is revoked with reason code notIssuedOrIrregularlyIssued
(7), it implies that the CA has no record of issuance of some of the
certificates that were signed using its private key. In this case, it is
recommended that the relying application considers the CA that issued the
certificate in question as compromised for any current or future use. 

COMMENTS:
I'm using Denis's proposal to represent "non-issued" by reason code
notIssuedOrIrregularlyIssued(7). If the consensus is that we extended
revoked extension is a better choice, then we can change the text
accordingly.

---

From: "Piyush Jain" <[email-masked]>
Date: Mon, 14 Jan 2013 16:16:59 -0800

I just realized that even my new proposal does not fix the paradox if the RP
decides to consider the CA as compromised in context of current transaction.
Unfortunately, I don't see any way to resolve this paradox under existing
OCSP trust models.
Here is the revised text where I changed the recommendation to consider CA
compromised for future use instead of current and future uses. It is akin to
saying - Trust me for once when I say "I always lie" :).

NEW PROPOSED TEXT

certificate in question as compromised for any future use. 

> -----Original Message-----
> From: Piyush Jain [mailto:[email-masked]]
> Sent: Saturday, January 12, 2013 7:50 AM
> To: [email-masked]
> Subject: Addressing issues in 4.2.2.2 of rfc2560bis-08
> 
> Hi list,
> 
> Here is the proposal to address the issue in section 4.2.2.2 that I
brought up
> in bullet point 4 of my original review post . You don't need to refer to
that
> post. Context is provided below.
> 
> CURRENT TEXT
> 
one
> of the following criteria:
certificate
> in question; or
>    2. Is the certificate of the CA that issued the certificate in
question; or
> - Creates a paradox If (2) or (3) are used to establish trust in the
response
> and if the response is marked as revoked because certificate was "not-
> issued". If the RP trusts response, it implies that the certificate was
not
> issued by the CA which implies that the RP should not trust the response.
> This can be addressed by changing all references to "issued" to "signed"
in
> the above text. Please not that this is a problem only for certificates
that
> exist, not for non-existent certificate. RPs who send queries for
non-existent
> certificates have no way to establish trust in the response if the
response is
> signed by a delegated responder.
> communicate the exact reason to the RP and RPs should assume the worst
> case scenario.
> 
> PROPOSED TEXT
> 
one
> of the following criteria:
certificate
> in question; or
>    2. Is the certificate of the CA that signed the certificate in
question; or
> (7), it implies that the CA has no record of issuance of some of the
certificates
> that were signed using its private key. In this case, it is recommended
that
> the relying application considers the CA that issued the certificate in
question
> as compromised for any current or future use.
> 
> COMMENTS: