Subject: Re: [pkix] New version Notification for draft-pinkas-2560bis-certinfo-00

From: [email-masked]
Date: Fri, 7 Sep 2012 08:16:53 +0200

Santoh,
 
Thank you for your comments.
 
See my replies in line:

>Denis,
> 
>I have couple of suggestions for the security considerations
>section.
> 
>1.     It is worth pointing out aside from RA corruption and database
>corruption that recommendation here do not fix the situation if the
>adversary has attacked the CA and pointed to its own OCSP Responder
>in the OCSP field of the AIA extension.

This attack, as described, would not be succeed. The attacker would also need 
to create an OCSP certificate for the OCSP Responder and for this he needs to 
be able to corrupt the RA which allows the production of OCSP certificates.
 
>2.     It is worth pointing out that the mechanism presented here can
>be used by the relying party to detect collision if the certificate
>signature was made using a weak hash, but the hashAlgorithm in the
>extension is not vulnerable to successful collision attack.

This is not a realistic scenario. If the certificate signature was made 
using a weak hash, the CA will ask to its superior CA to revoke its CA certificate.
This is thus outside the scope of this extension.
 
Denis

---

From: Santosh Chokhani <[email-masked]>
Date: Fri, 7 Sep 2012 07:26:11 -0400

Denis,

On 1, If the CA has been attacked,, you have no assurance that the adversary has not created an OCSP certificate as well.

On 2, just like the CA compromise scenario you cite, the mechanism helps detect collision.  If the CA knew of collision, it would of course change the cipher suite.

Note that 1 still for collision detection trumps 2 since collision creator could have created OCSP certificate and put the rogue OCSP pointer in AIA.

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, September 07, 2012 2:17 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: [pkix] New version Notification for draft-pinkas-2560bis-certinfo-00

Santoh,

Denis

---

From: [email-masked]
Date: Fri, 7 Sep 2012 16:24:28 +0200

Santosh,

> Denis,
> 
> On 1, If the CA has been attacked,, you have no assurance that the 
> adversary has not created an OCSP certificate as well.

Rather than arguing we should concentrate to improve the text. What about:

   When certHashValue is returned and the hashes match, then everything 
   looks fine, but this case does not allow detecting an abnormal 
   situation if the RA software has been corrupted, if the CA itself 
   has been corrupted or if the database to which the OCSP server has 
   access has been maliciously corrupted. 

> On 2, just like the CA compromise scenario you cite, the mechanism 
> helps detect collision.  If the CA knew of collision, it would of 
> course change the cipher suite.

 Maybe, maybe not. A collision may happen without a defect in the cipher 
suite 
(e.g. the HSM has been successfully used directly).

I believe that the current text is sufficient:

   When certHashValue is returned and the hashes do not match, this 
   extension allows detecting an abnormal situation : there exists two 
   certificates with the same serial number: one regularly issued by 
   the CA and another one which has either been forged or obtained 
   irregularly.

If you don't think so, please make a specific proposal.

Denis
 
> Note that 1 still for collision detection trumps 2 since collision 
> creator could have created OCSP certificate and put the rogue OCSP 
> pointer in AIA.
> 

> to create an OCSP certificate for the OCSP Responder and for this 
heneeds to

---

From: Santosh Chokhani <[email-masked]>
Date: Sun, 9 Sep 2012 05:53:39 -0400

Denis,

Thanks.  We are almost there.  I have suggestions in-line below.

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, September 07, 2012 10:24 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: [pkix] New version Notification for draft-pinkas-2560bis-certinfo-00

Santosh,

   When certHashValue is returned and the hashes match, then everything
   looks fine, but this case does not allow detecting an abnormal
   situation if the RA software has been corrupted, if the CA itself
   has been corrupted or if the database to which the OCSP server has
   access has been maliciously corrupted.
[Santosh] This is almost there.  How about the following (added OCSP corruption and cryptographic algorithm)
   When certHashValue is returned and the hashes match, then everything
   looks fine, but this case does not allow detecting an abnormal
   situation if the RA software has been corrupted, if the CA itself
   has been corrupted, OCSP Server has been corrupted, or if the database to which the OCSP server has
   access has been maliciously corrupted. This may also not detect hashing algorithm or signature algorithm compromise.

> course change the cipher suite.

 Maybe, maybe not. A collision may happen without a defect in the cipher suite
(e.g. the HSM has been successfully used directly).

If you don't think so, please make a specific proposal.
[Santosh] I withdraw the second suggestion since it becomes too convoluted.  I have addressed some of it in item 1.

Denis

> to create an OCSP certificate for the OCSP Responder and for this heneeds to

---

From: Piyush Jain <[email-masked]>
Date: Sun, 9 Sep 2012 17:43:28 +0000

Not sure if I get it completely.

In the security section we are saying that it does not detect the 'abnormal' scenario where RA ,CA or responder is compromised.

And the reason for introducing this extension is (from the draft) - "either that the target certificate has indeed not been issued and thus is a forged certificate", which implies that either the CA or RA is compromised.

In summary the extension is used for detecting CA compromise scenarios but cannot detect the 'abnormal' case when CA is compromised.
What am I missing?

-Piyush

From: [email-masked] [mailto:[email-masked]] On Behalf Of Santosh Chokhani
Sent: Sunday, September 09, 2012 2:54 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [pkix] New version Notification for draft-pinkas-2560bis-certinfo-00

Denis,

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Friday, September 07, 2012 10:24 AM
To: Santosh Chokhani
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [pkix] New version Notification for draft-pinkas-2560bis-certinfo-00

Santosh,

Denis

---

From: Santosh Chokhani <[email-masked]>
Date: Sun, 9 Sep 2012 15:03:26 -0400

Piyush,

You are not missing anything.

Thus extension does not cover all the situations.  That is why I am neither a fan of it here nor I think CAB Forum got it right.

That said, speaking from other side of my mouth, if the attacker is not smart enough or the CA configuration makes it hard to mint OCSP certificate, the bogus certificate can be detected.

From: Piyush Jain [mailto:[email-masked]]
Sent: Sunday, September 09, 2012 1:43 PM
To: Santosh Chokhani; [email-masked]
Cc: [email-masked]
Subject: RE: [pkix] New version Notification for draft-pinkas-2560bis-certinfo-00

-Piyush

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Santosh Chokhani
Sent: Sunday, September 09, 2012 2:54 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [pkix] New version Notification for draft-pinkas-2560bis-certinfo-00

Denis,

Santosh,

Denis

---

From: [email-masked]
Date: Mon, 10 Sep 2012 10:04:22 +0200

Santosh,

A small change without changing the intent. Rather than saying:

"This may also not detect hashing algorithm or signature algorithm 
compromise".

I propose:

"This case does not either allow detecting hashing algorithm or signature 
algorithm collisions".

Denis

De :    Santosh Chokhani <[email-masked]>
A :     "[email-masked]" <[email-masked]>
Cc :    "[email-masked]" <[email-masked]>
Date :  09/09/2012 11:53
Objet : RE: [pkix] New version Notification for 
draft-pinkas-2560bis-certinfo-00

Denis,

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, September 07, 2012 10:24 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: [pkix] New version Notification for 
draft-pinkas-2560bis-certinfo-00
 
Santosh, 

   When certHashValue is returned and the hashes match, then everything 
   looks fine, but this case does not allow detecting an abnormal 
   situation if the RA software has been corrupted, if the CA itself 
   has been corrupted or if the database to which the OCSP server has 
   access has been maliciously corrupted. 
[Santosh] This is almost there.  How about the following (added OCSP 
corruption and cryptographic algorithm)
   When certHashValue is returned and the hashes match, then everything 
   looks fine, but this case does not allow detecting an abnormal 
   situation if the RA software has been corrupted, if the CA itself 
   has been corrupted, OCSP Server has been corrupted, or if the database 
to which the OCSP server has 
   access has been maliciously corrupted. This may also not detect hashing 
algorithm or signature algorithm compromise.

If you don't think so, please make a specific proposal. 
[Santosh] I withdraw the second suggestion since it becomes too 
convoluted.  I have addressed some of it in item 1.

Denis 

heneeds to

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 10 Sep 2012 09:55:40 -0400

OK

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, September 10, 2012 4:04 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: [pkix] New version Notification for draft-pinkas-2560bis-certinfo-00

Santosh,

"This may also not detect hashing algorithm or signature algorithm compromise".

I propose:

"This case does not either allow detecting hashing algorithm or signature algorithm collisions".

Denis

De :        Santosh Chokhani <[email-masked]<mailto:[email-masked]>>
A :        "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc :        "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date :        09/09/2012 11:53
Objet :        RE: [pkix] New version Notification for draft-pinkas-2560bis-certinfo-00
________________________________

Denis,

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Friday, September 07, 2012 10:24 AM
To: Santosh Chokhani
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [pkix] New version Notification for draft-pinkas-2560bis-certinfo-00

Santosh,

Denis

---

From: [email-masked]
Date: Mon, 17 Sep 2012 09:16:03 +0200

Piyush,

You said that if the target certificate has indeed not been issued and 
thus is a forged certificate, 
this implies that either the CA or RA is compromised.

This may indeed be the case, but not necessarily. Here are two other cases 
which lead to that situation:

    1) the key has been discovered (e.g. since the algorithm has been 
broken for that key size),
   2) the backup keys of the HSM have been reinstalled on another HSM and 
used directly 
       without using the genuine software.

They are other cases .Nevertheless, you will find hereafter a proposed 
text improvement:

The text was :

   When certHashValue is returned and the hashes match, then everything 
   looks fine, but this case does not allow detecting an abnormal 
   situation if the RA software has been corrupted, if the CA itself 
   has been corrupted, OCSP Server has been corrupted, or if the 
   database to which the OCSP server has access has been maliciously 
   corrupted.  This case does not either allow detecting hashing 
   algorithm or signature algorithm collisions.

The proposed change is the following  : 

   There are different cases when such a situation may happen, in 
   particular:

      1) both the OCSP server and the database to which the OCSP server 
         has access have not been corrupted, but the RA software 
         or the CA software has been partially corrupted.

      2) the backup keys of the HSM (Hardware Security Module) have 
         been reinstalled on another HSM and used directly without 
         using the genuine software.

      3) a collision could be found for the hash and/or the signature 
         algorithm.

      4) the key has been discovered (e.g. since the algorithm has been 
         broken for that key size).

   When certHashValue is returned and the hashes match, then everything 
   looks fine, but this case does not allow detecting abnormal 
   situations such as:

      1) the RA software has been partially or completely corrupted, 

      2) the CA has been partially or completely corrupted, 

      3) the OCSP server has been partially or completely corrupted, or

      4) the database to which the OCSP server has access has been 
         partially or completely maliciously corrupted. 

   This case does not either allow detecting hashing algorithm or 
signature
   algorithm collisions.

Denis
 
> In the security section we are saying that it does not detect the 
> ‘abnormal’ scenario where RA ,CA or responder is compromised.
> 
> And the reason for introducing this extension is (from the draft) - “
> either that the target certificate has indeed not been issued and 
> thus is a forged certificate”, which implies that either the CA or 
> RA is compromised.
> 
> In summary the extension is used for detecting CA compromise 
> scenarios but cannot detect the ‘abnormal’ case when CA is compromised.
> What am I missing?
> 
> -Piyush
> 
> 
>    access has been maliciously corrupted. This may also not detect 
> hashing algorithm or signature algorithm compromise.
> 
>