Subject: Re: [pkix] Possible OCSP Extensions

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 22 Mar 2012 13:24:25 +0000

On Mar 21, 2012, at 4:42 PM, Martin Rex wrote:

> Miller, Timothy J. wrote:

>> There is a corner case where the CA history is trusted, the Responder
>> signing key is trusted, but the CA signing key is not.
>> In this case, NOTISSUED can signal a compromise.
>> This is the corner case I think Philip is after.
> 
> I do not think that this is a "corner case"; I believe it will be the
> most probable case that the CA key compromise is a temporary loss of
> control over certificate issuance, and may be accompanied by the loss
> of records what got signed (e.g. physical damage inflicted by the
> attacker).  

I think you missed the point.  The corner is the loss of CA key control while *keeping* CA history integrity.  In both recent cases we have before us, loss of CA key control was temporary, but the CA history couldn't be trusted.  NOTISSUED critically depends on *both*.  

The point of NOTISSUED is to *aid* in detecting compromise so recovery can be attempted.  Once you're *in* recovery, NOTISSUED is irrelevant because you can just as easily respond REVOKED for those certs--as we see from recent cases.

-- T

---

From: Martin Rex <[email-masked]>
Date: Thu, 22 Mar 2012 15:41:52 +0100 (MET)

Miller, Timothy J. wrote:
> Martin Rex wrote:
> I think you missed the point.  The corner is the loss of CA key control
> while *keeping* CA history integrity.  In both recent cases we have
> before us, loss of CA key control was temporary, but the CA history
> couldn't be trusted.  NOTISSUED critically depends on *both*.  

Just the opposite.  In the DigiNotar case, the history integrity
was retained (that is the purpose of any desaster recovery plan).

And the means that they used for their own OCSP server to recognize
misissued certs was to check OCSP requests against their database
of past issued certs and declare all other certs not in that database
as REVOKED.

But unless the OCSP requests include a certificate hash, that check
is not reliable, because depending on how much control the attacker
had over the creation of serial numbers, he could have tried to reuse
serials of correctly issued certs for the misissued certs.
That's why OCSP requests should be updated to include a certificate
hash besides the issuer and serial.

> 
> The point of NOTISSUED is to *aid* in detecting compromise so recovery
> can be attempted.  Once you're *in* recovery, NOTISSUED is irrelevant
> because you can just as easily respond REVOKED for those certs--as we
> see from recent cases.

Just the opposite.  NOTISSUED is only relevant in case of suspicion
and recovery.  Only those that continue claiming that potential
compromise of a CA is a non-event which they do not have to account
for do not care about "NOTISSUED" status.

-Martin

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 22 Mar 2012 10:48:25 -0400

Using OCSP to figure out mis-issued certificates is an incomplete security mechanism.

Attacker can issue itself a delegated OCSP certificate and point to that OCSP in mis-issued certificates.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Thursday, March 22, 2012 10:42 AM
To: Miller Timothy J.
Cc: [email-masked]
Subject: Re: [pkix] Possible OCSP Extensions

Miller, Timothy J. wrote:
> >> There is a corner case where the CA history is trusted, the 
> >> Responder signing key is trusted, but the CA signing key is not.
> > I do not think that this is a "corner case"; I believe it will be 
> > the most probable case that the CA key compromise is a temporary 
> > loss of control over certificate issuance, and may be accompanied by 
> > the loss of records what got signed (e.g. physical damage inflicted 
> > by the attacker).
> 
> I think you missed the point.  The corner is the loss of CA key 
> control while *keeping* CA history integrity.  In both recent cases we 
> have before us, loss of CA key control was temporary, but the CA 
> history couldn't be trusted.  NOTISSUED critically depends on *both*.

Just the opposite.  In the DigiNotar case, the history integrity was retained (that is the purpose of any desaster recovery plan).

And the means that they used for their own OCSP server to recognize misissued certs was to check OCSP requests against their database of past issued certs and declare all other certs not in that database as REVOKED.

But unless the OCSP requests include a certificate hash, that check is not reliable, because depending on how much control the attacker had over the creation of serial numbers, he could have tried to reuse serials of correctly issued certs for the misissued certs.
That's why OCSP requests should be updated to include a certificate hash besides the issuer and serial.

> because you can just as easily respond REVOKED for those certs--as we 

Just the opposite.  NOTISSUED is only relevant in case of suspicion and recovery.  Only those that continue claiming that potential compromise of a CA is a non-event which they do not have to account for do not care about "NOTISSUED" status.

-Martin

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Martin Rex <[email-masked]>
Date: Thu, 22 Mar 2012 17:19:39 +0100 (MET)

> to that OCSP in mis-issued certificates.

Which indicates a design flaw in the scheme to authorize OCSP responders
through attributes in the certificate.  As I said, PKI was not designed
with the concept of desaster recovery from a CA key compromise in mind.

A compromised CA could accept existing PKI credentials to authenticate
requests for new credentials when it knows to ignore that information.

-Martin

---

From: Tom Ritter <[email-masked]>
Date: Thu, 22 Mar 2012 12:20:00 -0400

> Attacker can issue itself a delegated OCSP certificate and point to that OCSP in mis-issued certificates.

Only if the attacker has *complete* control of the CA's signing key.
If the attack actually has access to a signing *function* that
includes logic to look for 'strange things' and block them (like
basicConstraints, delegated OCSP, etc) or a whitelist of attributes to
be allowed through (alternate names) - then the attacker can't do such
a thing.  Exploitation in the real world has to deal with issues like
these: you don't always get a 'complete' SQL injection, sometime
you're not allowed to submit commas.  You don't always get a XSS bug
that lets you include angle brackets, sometime you only get an
attribute-based one.  You don't always get to drop your shellcode on
the stack and execute, sometimes you have to ROP first to bypass DEP.
You don't always get full access to the CA's HSM, sometimes you only
bypass their authorization checks.

I agree that in some cases this security mechanism can be bypassed.
But in some cases so can basicConstraints (as we've seen time and time
again).  It's unknowable for us to say whether this protection
mechanism would or wouldn't *actually* be useful - because it comes
down to nitty-gritty of CA implementation of signing operations, and
they're not going to say anything.

It's likely that it would be a useful security mechanism for some CAs
and would be automatically bypassed by others.  If I were a betting
man, I say it's more likely to be automatically bypassed than useful
*today* - but in the future I hope it eventually would become a useful
mechanism for CAs - it's in their interest to keep the integrity of
their certificate history and to whitelist the parameters specified in
CSR's.

-tom

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 22 Mar 2012 12:26:55 -0400

It is what it is.

Unless that is changed, your suggestion of disaster recovery in light of 5280 and 2560 is a disaster.

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Thursday, March 22, 2012 12:20 PM
To: Santosh Chokhani
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [pkix] Possible OCSP Extensions

> that OCSP in mis-issued certificates.

Which indicates a design flaw in the scheme to authorize OCSP responders through attributes in the certificate.  As I said, PKI was not designed with the concept of desaster recovery from a CA key compromise in mind.

A compromised CA could accept existing PKI credentials to authenticate requests for new credentials when it knows to ignore that information.

-Martin

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 22 Mar 2012 12:29:32 -0400

In three cases I am aware of including Diginotar, the attacker could get the CA to sign any type of certificate it desired.

That would mean creating its own delegated OCSP certificate and putting the OCSP field of its choice in the AIA.

-----Original Message-----
From: Tom Ritter [mailto:[email-masked]] 
Sent: Thursday, March 22, 2012 12:20 PM
To: Santosh Chokhani
Cc: [email-masked]; Miller Timothy J.; [email-masked]
Subject: Re: [pkix] Possible OCSP Extensions

Only if the attacker has *complete* control of the CA's signing key.
If the attack actually has access to a signing *function* that includes logic to look for 'strange things' and block them (like basicConstraints, delegated OCSP, etc) or a whitelist of attributes to be allowed through (alternate names) - then the attacker can't do such a thing.  Exploitation in the real world has to deal with issues like
these: you don't always get a 'complete' SQL injection, sometime you're not allowed to submit commas.  You don't always get a XSS bug that lets you include angle brackets, sometime you only get an attribute-based one.  You don't always get to drop your shellcode on the stack and execute, sometimes you have to ROP first to bypass DEP.
You don't always get full access to the CA's HSM, sometimes you only bypass their authorization checks.

I agree that in some cases this security mechanism can be bypassed.
But in some cases so can basicConstraints (as we've seen time and time again).  It's unknowable for us to say whether this protection mechanism would or wouldn't *actually* be useful - because it comes down to nitty-gritty of CA implementation of signing operations, and they're not going to say anything.

It's likely that it would be a useful security mechanism for some CAs and would be automatically bypassed by others.  If I were a betting man, I say it's more likely to be automatically bypassed than useful
*today* - but in the future I hope it eventually would become a useful mechanism for CAs - it's in their interest to keep the integrity of their certificate history and to whitelist the parameters specified in CSR's.

-tom

---

From: Piyush Jain <[email-masked]>
Date: Thu, 22 Mar 2012 10:31:18 -0700

So, based on what you are saying below the problem boils down to this- CA knows that is has been compromised and fraudulent user certificates have been issued using its keys. There is now way for the CA to know what these certificates because all the traces of this activity has been wiped off from the audit logs.- CA knows that no OCSP or certificate signing certificate has been issued off its keys because it has some fool proof mechanism to detect issuance of such certificates. (May be different,more secure  audit logs or controls that detect this kind of activity)
Here are the solutions that are available to the CA to address the breach.- Continue operation and allow use of fraudulent certificate, until some one reports them and then revoke them. Accept the liability, payoff the victims and classify it as cost of doing business- Revoke the CA. Own up, Reissue all the good certificate off a new key and classify the cost associated with doing this as cost of doing business.- Propose a standard which fundamentally changes how RPs do certificate processing (based on CRLs and OCSP), have them comply with this new standard and pass on all these costs to the RPs. Remember that the costs include not only those associated with major upgrade of their certificate processing software but also those associate with increased bandwidth and storage costs (size of CRLs vs whitelists, bloated OCSP requests and responses). 
Which solution is preferable to you - if you are a CA, if you are a RP?What is you preference if you are a CA whose security practices are so good that you are not among those who get compromised once in 15 years?

> From: [email-masked]
> Date: Thu, 22 Mar 2012 12:20:00 -0400
> To: [email-masked]
> CC: [email-masked]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 22 Mar 2012 19:16:24 -0400

The issue here was what it is going to be.

That is now the issue in another place. Thanks for playing.

-- 
Website: http://hallambaker.com/

---

From: Tom Gindin <[email-masked]>
Date: Thu, 22 Mar 2012 20:43:57 -0400

Santosh:

        That's why one of my suggestions Tuesday was "I am not sure why 
it's a good thing that id-ad-ocsp is recommended to be placed into the 
subject certificate's AIA extension rather than into the issuer's SIA", 
followed by "A migration path to change this would start by recommending 
that an SIA value in the issuer certificate SHOULD take precedence over an 
AIA value in the subject one if both values are present".  Anything with 
revocation information in the subject certificate is potentially 
vulnerable to this, but unsigned OCSP is probably somewhat more so.

Tom Gindin

From:   Santosh Chokhani <[email-masked]>
To:     "[email-masked]" <[email-masked]>, "Miller Timothy J." 
<[email-masked]>, 
Cc:     "[email-masked]" <[email-masked]>
Date:   03/22/2012 10:49 AM
Subject:        Re: [pkix] Possible OCSP Extensions
Sent by:        [email-masked]

Using OCSP to figure out mis-issued certificates is an incomplete security 
mechanism.

Attacker can issue itself a delegated OCSP certificate and point to that 
OCSP in mis-issued certificates.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
Martin Rex
Sent: Thursday, March 22, 2012 10:42 AM
To: Miller Timothy J.
Cc: [email-masked]
Subject: Re: [pkix] Possible OCSP Extensions

> history couldn't be trusted.  NOTISSUED critically depends on *both*.

Just the opposite.  In the DigiNotar case, the history integrity was 
retained (that is the purpose of any desaster recovery plan).

And the means that they used for their own OCSP server to recognize 
misissued certs was to check OCSP requests against their database of past 
issued certs and declare all other certs not in that database as REVOKED.

But unless the OCSP requests include a certificate hash, that check is not 
reliable, because depending on how much control the attacker had over the 
creation of serial numbers, he could have tried to reuse serials of 
correctly issued certs for the misissued certs.
That's why OCSP requests should be updated to include a certificate hash 
besides the issuer and serial.

> because you can just as easily respond REVOKED for those certs--as we 

Just the opposite.  NOTISSUED is only relevant in case of suspicion and 
recovery.  Only those that continue claiming that potential compromise of 
a CA is a non-event which they do not have to account for do not care 
about "NOTISSUED" status.

-Martin

---

From: Santosh Chokhani <[email-masked]>
Date: Fri, 23 Mar 2012 11:07:48 -0400

Tom,

If SIA simply has OCSP pointer in it, it does not fix the problem.  It requires the attacker to poison the DNS for the relying parties so that the OCSP requests come to it.

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Thursday, March 22, 2012 8:44 PM
To: Santosh Chokhani
Cc: [email-masked]; [email-masked]; Miller Timothy J.
Subject: Re: [pkix] Possible OCSP Extensions

        Santosh:

        That's why one of my suggestions Tuesday was "I am not sure why it's a good thing that id-ad-ocsp is recommended to be placed into the subject certificate's AIA extension rather than into the issuer's SIA", followed by "A migration path to change this would start by recommending that an SIA value in the issuer certificate SHOULD take precedence over an AIA value in the subject one if both values are present".  Anything with revocation information in the subject certificate is potentially vulnerable to this, but unsigned OCSP is probably somewhat more so.

Tom Gindin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Thursday, March 22, 2012 10:42 AM
To: Miller Timothy J.
Cc: [email-masked]
Subject: Re: [pkix] Possible OCSP Extensions

-Martin