Subject: [pkix] PROPOSAL: SCVP to HISTORIC

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 16 Mar 2012 09:09:13 -0400

Stephen's comments on the alleged confusion between SCVP and OCSP
suggest that the original decision to make SCVP a separate protocol
from OCSP was a blunder and that the delegated certificate path
processing should have been part of OCSP functionality after all.

If every proposal to chance OCSP results in a turf war over which
protocol is to implement the functionality then the original division
was an error.

Therefore I suggest the following course of action:

Extend OCSP to support the SCVP functionality as an option
Move SCVP to HISTORIC

Not only will this avoid future pointless discussions, it will reduce
the size and complexity of the PKIX protocol stack considerably.

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

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 16 Mar 2012 08:27:29 -0700

You earlier asked if anyone used SCVP, and there was the answer:

> A bunch of Govt. Agencies in the U.S. Mostly enterprise deployments. No public CAs use it.

It is irresponsible for a public CA to request a protocol that is known to be deployed to be moved to Historic simply because companies like itself do not use it, even if other entities are known to use it. The PKIX WG makes protocols that are useful to a wide range of entities, not just public CAs.

Having said that, I disagree with Steve Kent's argument that if something is "better" done in SCVP, it cannot be done in OCSP. I agree with Phill that any status of a certificate, including that it was not issues or is expired, is still status and should be able to be represented in a well-deployed protocol such as OCSP.

--Paul Hoffman

---

From: [email-masked]
Date: Fri, 16 Mar 2012 17:03:34 +0100

Paul,

I agrerw ith you that O

De :    Paul Hoffman <[email-masked]>
A :     Phillip Hallam-Baker <[email-masked]>
Cc :    [email-masked]
Date :  16/03/2012 16:27
Objet : Re: [pkix] PROPOSAL: SCVP to HISTORIC
Envoyé par :    [email-masked]

> A bunch of Govt. Agencies in the U.S. Mostly enterprise deployments. No 
public CAs use it.

It is irresponsible for a public CA to request a protocol that is known to 
be deployed to be moved to Historic simply because companies like itself 
do not use it, even if other entities are known to use it. The PKIX WG 
makes protocols that are useful to a wide range of entities, not just 
public CAs.

Having said that, I disagree with Steve Kent's argument that if something 
is "better" done in SCVP, it cannot be done in OCSP. I agree with Phill 
that any status of a certificate, including that it was not issues or is 
expired, is still status and should be able to be represented in a 
well-deployed protocol such as OCSP.

--Paul Hoffman

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 16 Mar 2012 12:20:09 -0400

Paul,

Well I agree with you that this is bad. But the alternative is worse.

Here we have the chair of the PKIX group saying that we can't maintain
or develop OCSP because he wants to keep new functionality for his
favorite protocol that almost nobody is using.

I had no problem in continuing to support SCVP when doing so was
harmless. But that is no longer the case.

If Stephen wants to try to gore my ox then I am going to shoot his,
run it over with an armored vehicle a few times and incinerate the
remains with thermite.

There is clearly a much better case for PKIX to drop SCVP completely
than for public CAs to deploy a new protocol to support a feature that
is far better suited and easily supported in an existing one.

So if Stephen will drop his proposal to tie the functionality I need
to a protocol I do not want, SCVP will no longer be causing harm and
there will be no need to consider moving SCVP to HISTORIC. If he wants
to draw this out into a protracted fight then the cost of continuing
to maintain SCVP rises.

---

From: [email-masked]
Date: Fri, 16 Mar 2012 17:23:55 +0100

Paul,

I agree with you that it is possible to extend OCSP, as long as additional 
status information is related to information 
available by the CA that has issued the certificate. In particular, since 
CRL is a "black list" mechanism, OCSP is able
 to use a "white list" mechanism. This is where "not issued" has a 
meaning.

However, the benefit of using a white list mechanism is only a small 
advantage in case the CA is compromised.
If everything has been compromised in the CA premises, then there is no 
advantage at all.

The only advantage is when the CA compromission is only partial and when 
the forged certificate 
has not been able to be included in the log of issued certificates. 

For example, the HSM has been used directly to create a forged 
certificate.

The danger is that people might think that white list mechanisms are much 
better than black list mechanisms, 
whereas this is not as straight.

Denis

PS. SCVP complexity is about 10 times the complexity of OCSP, hence why it 
is and will not be not widely deployed.

PS 2. the previous message was sent before my message was finished.

--Paul Hoffman

---

From: Michael Myers <[email-masked]>
Date: Fri, 16 Mar 2012 09:43:54 -0700

I lost track.  What was the original need/requirement/observation that  
led to this discussion?

Mike

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 16 Mar 2012 17:59:14 +0100

Mike,

It's provided in the "Possible OCSP Extension" thread.

Basically, if users of OCSP need to extend the functionality of OCSP in a
way where some functionally may come to overlap with functionality
provided by SCVP, then should we allow that overlap or force those with
such need to implement SCVP?

Clearly OCSP is the common dominant protocol for on-line status checking.
Any attempts to force the market to use SCVP will most likely be ignored.

As will any attempts to make material changes to OCSP unless it has a big
use-case for high volume web server certs checking.
If there is a clear and well motivated market need to add extensions to
OCSP, I think we need to satisfy that need regardless of SCVP.

/Stefan

---

From: brennan security <[email-masked]>
Date: Fri, 16 Mar 2012 13:35:49 -0400

(I might have missed some of the conversation)

A CA could produce white lists (certificate good list) in an identical
format to CRLs, then OCSP responders would know both good and bad, and
could respond accordingly?  Ingesting a CGL would be similar to a CRL

The only issue I see with that is the time required for a CA to produce the
CGL, post it, and then have the OCSP consume it.  This could be handled by
Not Before from x509.

Or am I incorrect on this?

-b

On Fri, Mar 16, 2012 at 12:23 PM, <[email-masked]> wrote:

> to use a "white list" mechanism. This is where "not issued" has a meaning.
>
> For example, the HSM has been used directly to create a forged certificate.
>
> ------------------------------
>
>
>
> be deployed to be moved to Historic simply because companies like itself do
> not use it, even if other entities are known to use it. The PKIX WG makes
> protocols that are useful to a wide range of entities, not just public CAs.
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 16 Mar 2012 13:38:58 -0400

Denis,

I agree with the points you raise but:

1) The whole purpose of this proposal is to enable a re-engineering of
CA architecture so that we eliminate 'single break' systems. At the
moment there is only a modest security advantage to separating out the
OCSP HSM from the cert signing HSM, but as your analysis shows having
a strong response for 'does not exist' changes that.

2) SCVP is complicated because the problem it solves is very complex.
The problem of enabling a 'does not exist' certificate status is much
simpler and a direct and logical extension of what OCSP already does.

On Fri, Mar 16, 2012 at 12:23 PM,  <[email-masked]> wrote:
> The only advantage is when the CA compromission is only partial and when the
> forged certificate
> ________________________________
>
>
>
> Having said that, I disagree with Steve Kent's argument that if something is
> "better" done in SCVP, it cannot be done in OCSP. I agree with Phill that
> any status of a certificate, including that it was not issues or is expired,
> is still status and should be able to be represented in a well-deployed
> protocol such as OCSP.
>
> --Paul Hoffman
>

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 16 Mar 2012 14:16:44 -0400

Phil,

The supposed advantages of adding a 'does not exist' response continue 
to elude me.  Back in November I explained in detail why I didn't 
believe that adding this new response would provide much in the way of 
additional security, and if anything might only create a false sense of 
security (see 
http://www.ietf.org/mail-archive/web/pkix/current/msg29983.html).  I 
only received two responses to my message, and both were proposing 
substantial changes to the PKI trust architecture, and neither supported 
the idea that adding a 'does not exist' status response (without making 
other significant changes) would provide a significant advantage.

So, could you respond to my earlier message and explain why simply 
adding a 'does not exist' status does more than provide a false sense of 
added confidence?

Dave

On 03/16/2012 01:38 PM, Phillip Hallam-Baker wrote:
> On Fri, Mar 16, 2012 at 12:23 PM,<[email-masked]>  wrote:
>> Paul,
>>
>> De :        Paul Hoffman<[email-masked]>
>> A :        Phillip Hallam-Baker<[email-masked]>
>> Cc :        [email-masked]
>> Date :        16/03/2012 16:27

---

From: Michael Myers <[email-masked]>
Date: Fri, 16 Mar 2012 11:42:28 -0700

> such need to implement SCVP?

Okay.  Then in that context, as lead author of OCSP and having  
participated in the genesis of SCVP, here's what I would advise the  
WG, were I standing at a microphone in Paris.

If the emergent need fundamentally involves online, dynamic policy  
coherence, it goes to SCVP.  If the need is simply what's the value of  
a given field in a database, it goes to OCSP.  Recall that SCVP is  
designed to incorporate OCSP input, so there's no inherent overlap.   
OCSP could very well be one among several back channels feeding into  
an SCVP service.

For example, I intended the cert status value of 'unknown' to be  
simply that--the queried OCSP responder has no extant data regarding  
the subject certificate.  Maybe it was issued somewhere, somehow, by  
somebody, but that particular certID doesn't show up in that  
particular responder's collection of data regarding certificates for  
which it claims to be authoritative.

However, if someone or some entity sought to delegate a scope of  
authority to a TTP regarding the authoritative issuance or lack  
thereof regarding a particular certificate, well, there's very likely  
a bits-on-the-wire policy component associated with that interaction.   
The crucial aspect of which would likely be that the TTP takes the hit  
if they (it) produces a false response the requester nonetheless  
relies upon before taking a security-relevant action.

I make the distinguishing point about policy and delegation because,  
as some of us may recall, SCVP came about from proposed extensions to  
OCSP regarding Delegated Path Validation and Delegated Path  
Discovery.  Which led to issues regarding policy coherence between  
requester and responder.  Which led to SCVP.

I shall now step away from the virtual microphone.

Mike

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 16 Mar 2012 15:22:31 -0400

The proposal to modify OCSP has nothing to do with "enabling a re-engineering of the CA architecture".  If it is possible to misuse the cert-signing HSM without corrupting the issued-certs database, that mis-use either is or is not facilitated by using the same HSM for OCSP.

Case 1 - common HSM facilitates misuse: re-engineering with separate HSMs will address that vulnerability regardless of whether OCSP is modified.

Case 2 - common HSM does not facilitate misuse: re-engineering with separate HSMs will not reduce the vulnerability regardless of whether OCSP is modified.

Having an OCSP 'does not exist' response changes nothing with regard to the costs and benefits of re-engineering the CA.  The existence of a CA vulnerability motivates the change to OCSP but not vice versa, any more than a rooster crow motivates the sun to rise.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker
Sent: Friday, March 16, 2012 1:39 PM
To: [email-masked]
Cc: [email-masked]; Paul Hoffman
Subject: Re: [pkix] PROPOSAL: SCVP to HISTORIC

Denis,

1) The whole purpose of this proposal is to enable a re-engineering of CA architecture so that we eliminate 'single break' systems. At the moment there is only a modest security advantage to separating out the OCSP HSM from the cert signing HSM, but as your analysis shows having a strong response for 'does not exist' changes that.

2) SCVP is complicated because the problem it solves is very complex.
The problem of enabling a 'does not exist' certificate status is much simpler and a direct and logical extension of what OCSP already does.

On Fri, Mar 16, 2012 at 12:23 PM,  <[email-masked]> wrote:
> Paul,
>
> I agree with you that it is possible to extend OCSP, as long as 
> additional status information is related to information available by 
> the CA that has issued the certificate. In particular, since CRL is a 
> "black list" mechanism, OCSP is able to use a "white list" mechanism. 
> This is where "not issued" has a meaning.
>
> The only advantage is when the CA compromission is only partial and 
> when the forged certificate has not been able to be included in the 
> log of issued certificates.
>
> The danger is that people might think that white list mechanisms are 
> much better than black list mechanisms, whereas this is not as 
> straight.
>
> Denis
>
> PS. SCVP complexity is about 10 times the complexity of OCSP, hence 
> why it is and will not be not widely deployed.
>
> De :        Paul Hoffman <[email-masked]> A :        Phillip 
> Hallam-Baker <[email-masked]> Cc :        [email-masked] Date :        
> 16/03/2012 16:27 Objet :        Re: [pkix] PROPOSAL: SCVP to HISTORIC 
> It is irresponsible for a public CA to request a protocol that is 
> known to be deployed to be moved to Historic simply because companies 
> like itself do not use it, even if other entities are known to use it. 
> The PKIX WG makes protocols that are useful to a wide range of entities, not just public CAs.
>
> Having said that, I disagree with Steve Kent's argument that if 
> something is "better" done in SCVP, it cannot be done in OCSP. I agree 
> with Phill that any status of a certificate, including that it was not 
> issues or is expired, is still status and should be able to be 
> represented in a well-deployed protocol such as OCSP.
>
> --Paul Hoffman
>

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 16 Mar 2012 12:38:42 -0700

Can I turn the question around and ask why adding a 'does not exist' response would be bad?

To answer your question more directly, I think there are scenarios that could most easily be addressed if such a response could be provided.  Just because it doesn't solve all the problems doesn't mean it isn't a useful improvement.

Obviously your concerns should be covered by the security considerations of any description of the extension.

> other significant changes) would provide a significant advantage.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 16 Mar 2012 16:18:04 -0400

+1

This is a lookup in a database and hence an OCSP feature.

On Fri, Mar 16, 2012 at 2:42 PM, Michael Myers <[email-masked]> wrote:
> Okay.  Then in that context, as lead author of OCSP and having participated
> in the genesis of SCVP, here's what I would advise the WG, were I standing
> at a microphone in Paris.
>
> coherence, it goes to SCVP.  If the need is simply what's the value of a
> given field in a database, it goes to OCSP.  Recall that SCVP is designed to
> incorporate OCSP input, so there's no inherent overlap.  OCSP could very
> well be one among several back channels feeding into an SCVP service.
>
> For example, I intended the cert status value of 'unknown' to be simply
> that--the queried OCSP responder has no extant data regarding the subject
> certificate.  Maybe it was issued somewhere, somehow, by somebody, but that
> particular certID doesn't show up in that particular responder's collection
> of data regarding certificates for which it claims to be authoritative.
>
> However, if someone or some entity sought to delegate a scope of authority
> to a TTP regarding the authoritative issuance or lack thereof regarding a
> particular certificate, well, there's very likely a bits-on-the-wire policy
> component associated with that interaction.  The crucial aspect of which
> would likely be that the TTP takes the hit if they (it) produces a false
> response the requester nonetheless relies upon before taking a
> security-relevant action.
>
> I make the distinguishing point about policy and delegation because, as some
> of us may recall, SCVP came about from proposed extensions to OCSP regarding
> Delegated Path Validation and Delegated Path Discovery.  Which led to issues
> regarding policy coherence between requester and responder.  Which led to
> SCVP.
>

---

From: Piyush Jain <[email-masked]>
Date: Fri, 16 Mar 2012 13:32:07 -0700

> From: [email-masked]
> Date: Fri, 16 Mar 2012 12:38:42 -0700
> To: [email-masked]
> CC: [email-masked]
> Subject: Re: [pkix] certificate not issued OCSP status response
> 
It may be useful to describe those scenarios and have a discussion around how 'does not exist' would help.Barring the mention of one case of partial CA compromise, I don't recall that any other use cases that were discussed. 
The fundamental problem here is that if the relying party doubts the signature on a cert signed by a CA, how can it trust the response from a responder delegated by the CA.From an attacker's point of view, If i have compromised the  CA, then I won't stop at issuing the EE cert, I would issue myself a responder cert as well.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 16 Mar 2012 16:40:35 -0400

The advantage is that it allows external parties to determine that a
total compromise has occurred and defenestrate the root.

So in the DigiNotar case there were three separate problems

1) The CA was completely breached and issued false certificates that
the CA had no record of
2) A significant time elapsed before the CA was aware that the breach
had occurred
3) An even longer time elapsed before the breach was independently
discovered and remediation efforts could start.

Now with the proposed scheme the attacker can still issue false
certificates but any attempt to cover their tracks by deleting the log
files will result in the CA issuing the OCSP status 'Does not exist'
and cause the breach to be observable externally. Contrawise if they
do not delete the logs, the CA will have a record of the bogus certs
that were issued.

In the past it was considered axiomatic that a CA will never ever be
breached. Now we have to address that as a possibility and deploy
mechanisms that can detect that eventuality.

On Fri, Mar 16, 2012 at 2:16 PM, David A. Cooper <[email-masked]> wrote:
> Phil,
>
> The supposed advantages of adding a 'does not exist' response continue to
> elude me.  Back in November I explained in detail why I didn't believe that
> adding this new response would provide much in the way of additional
> security, and if anything might only create a false sense of security (see
> http://www.ietf.org/mail-archive/web/pkix/current/msg29983.html).  I only
> received two responses to my message, and both were proposing substantial
> changes to the PKI trust architecture, and neither supported the idea that
> adding a 'does not exist' status response (without making other significant
> changes) would provide a significant advantage.
>
> So, could you respond to my earlier message and explain why simply adding a
> 'does not exist' status does more than provide a false sense of added
> confidence?
>
> Dave
>
>
>>> additional
>>> the
>>> do
>>> is

---

From: Santosh Chokhani <[email-masked]>
Date: Fri, 16 Mar 2012 16:50:27 -0400

PHB never disappoints me in his understanding (or shall I say lack thereof) when it comes to security.

If the CA is compromised, the attacker will issue a delegated OCSP certificate and put that pointer in the certificate that the attacker minted.  It does not even have to do DNS poisoning to point to a rogue responder.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker
Sent: Friday, March 16, 2012 4:41 PM
To: David A. Cooper
Cc: [email-masked]
Subject: Re: [pkix] certificate not issued OCSP status response

The advantage is that it allows external parties to determine that a total compromise has occurred and defenestrate the root.

1) The CA was completely breached and issued false certificates that the CA had no record of
2) A significant time elapsed before the CA was aware that the breach had occurred
3) An even longer time elapsed before the breach was independently discovered and remediation efforts could start.

Now with the proposed scheme the attacker can still issue false certificates but any attempt to cover their tracks by deleting the log files will result in the CA issuing the OCSP status 'Does not exist'
and cause the breach to be observable externally. Contrawise if they do not delete the logs, the CA will have a record of the bogus certs that were issued.

In the past it was considered axiomatic that a CA will never ever be breached. Now we have to address that as a possibility and deploy mechanisms that can detect that eventuality.

On Fri, Mar 16, 2012 at 2:16 PM, David A. Cooper <[email-masked]> wrote:
> additional security, and if anything might only create a false sense 
> of security (see 
> substantial changes to the PKI trust architecture, and neither 
> supported the idea that adding a 'does not exist' status response 
> (without making other significant
> adding a 'does not exist' status does more than provide a false sense 
> of added confidence?
>
> Dave
>
>
>> 1) The whole purpose of this proposal is to enable a re-engineering 
>> of CA architecture so that we eliminate 'single break' systems. At 
>> the moment there is only a modest security advantage to separating 
>> out the OCSP HSM from the cert signing HSM, but as your analysis 
>> shows having a strong response for 'does not exist' changes that.
>>
>>> the CA that has issued the certificate. In particular, since CRL is 
>>> a "black list" mechanism, OCSP is able to use a "white list" 
>>> mechanism. This is where "not issued" has a meaning.
>>>
>>> De :        Paul Hoffman<[email-masked]> A :        Phillip 
>>> Hallam-Baker<[email-masked]> Cc :        [email-masked] Date :        
>>> 16/03/2012 16:27 Objet :        Re: [pkix] PROPOSAL: SCVP to 
>>> HISTORIC Envoyé par :        [email-masked]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 16 Mar 2012 17:06:23 -0400

That might have been a good point if you hadn't started with a personal insult.

The mere fact that a feature is in PKIX does not mean we have to allow
its use. Clearly any observational feedback system (e.g. EFF
Observatory, Convergence) would look for such a certificate and flag
it as unusual.

But given the circumstances you cite, wouldn't the much easier path be
for the attacker to simply issue themselves a cross certificate with
cert signing capability?

In real life an attacker would be rather unlikely to favor that
approach because it would likely trigger secondary controls within the
CA that are there to detect certs with the cert signing bit set. Your
post tells me that I should consider this particular PKIX feature as
another red flag (but my controls tend to describe what is strictly
allowed rather than denied in any case).

---

From: brennan security <[email-masked]>
Date: Fri, 16 Mar 2012 17:18:24 -0400

Other OCSP modes would be resistant to a CA compromise also (direct trust,
CA designated, VA Designated).

Many companies and large enterprises are already doing the CA designated/VA
designated route.

I've also been considering an alternative PKI model as a significant aid -
for example a GPG/PGP signature on Root CAs, sub CAs, and signing Certs.

-b

On Fri, Mar 16, 2012 at 5:06 PM, Phillip Hallam-Baker <[email-masked]>wrote:

> > If the CA is compromised, the attacker will issue a delegated OCSP
> certificate and put that pointer in the certificate that the attacker
> minted.  It does not even have to do DNS poisoning to point to a rogue
> responder.
> >
> > and cause the breach to be observable externally. Contrawise if they do
> not delete the logs, the CA will have a record of the bogus certs that were
> issued.
> >
> >>>>> A bunch of Govt. Agencies in the U.S. Mostly enterprise deployments.
> No
> >>>>> public CAs use it.
> >>>>
> known
> >>>> to
> something

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 16 Mar 2012 17:21:18 -0400

There is a lot of current work in this area and that is input I think
needs to funnel into the trust broker.

On Fri, Mar 16, 2012 at 5:18 PM, brennan security
<[email-masked]> wrote:
>> > certificates but any attempt to cover their tracks by deleting the log files
>> > will result in the CA issuing the OCSP status 'Does not exist'
>> > breached. Now we have to address that as a possibility and deploy mechanisms
>> > that can detect that eventuality.
>> >
>> >
>> >>>> protocols that are useful to a wide range of entities, not just
>> >>>> public
>> >>>> CAs.
>> >>>>

---

From: Liaquat Khan <[email-masked]>
Date: Fri, 16 Mar 2012 21:29:30 +0000

I think of the attack slightly differently, I am not of the opinion that
the attacker removes the certificate from the CA's database to hide
his/her tracks, since this would only highlight the attack specially if
this new "does not exist" status is implemented.  IMO the attacker will
want to leave the fake certificate in the CA's database specifically so
the OCSP responder (assuming it's not been compromised) can be continued
to be fooled that it's a legitimate certificate.  The attacker may delete
other log info which highlights the break-in (e.g. Operator activity log,
system event log etc.), but an OCSP responder doesn't look at generic CA
log tables, it only looks at the cert table to determine certificate
status. 

IMO the attack scenario is that the attacker manages to get access to the
HSM pin, and gets a fake certificate without going through the CA
application.  In this scenario the CA application doesn't know about the
cert and it's not therefore in its cert table. The attacker will now need
to somehow put that fake cert into the CA's DB table to fool the OCSP
responder which can respond with "does not exist" status.

However one could argue that if an attacker can get an HSM pin they can
probably break into the CA also and put a fake cert into the database
there, and also delete other logs that highlight the break-in and pretty
much do what they want.  So detection of the attack will not be so simple
as just making OCSP responder's capable of returning "does not exist"
response. 

Note you state if the fake cert is left in the CA's DB, the CA will have a
record of the bogus cert.  However this doesn't help to detect the problem
it's just a cert like another cert in the CA DB, how would a CA
administrator realise its as bogus cert?

With regards to the OCSP/SCVP discussion, we as a company provide both
types of servers.  I think the certificate "does not exist" check is not
currently part of SCVP either unless I am mistaken, e.g. path building for
such a certificate will still pass, path validation will also succeed
since it was issued by a valid CA private key, and revocation checking
will also succeed (assuming OCSP responder follows current RCC2560 and
doesn't check the CA's DB). So IMO if this check is to be implemented it
makes more sense to implement it in OCSP rather than SCVP. However whether
it will actually solve the original problem of detecting such CA attacks
is questionable, maybe in some limited cases it will.

Regards,

LK

On 16/03/2012 20:40, "Phillip Hallam-Baker" <[email-masked]> wrote:

>>only
>>adding a
>>>>when
>>>>much
>>>>why
>>>> it

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 16 Mar 2012 16:29:17 -0700

On Mar 16, 2012, at 1:32 PM, Piyush Jain wrote:

> It may be useful to describe those scenarios and have a discussion around how 'does not exist' would help.

And I still argue that the question of how it would hurt deserves a response.  How can it be a bad thing to have a way to represent "white-list" as opposed to "black-list" information?

> Barring the mention of one case of partial CA compromise, I don't recall that any other use cases that were discussed. 

Yes, that's probably the main one.

> The fundamental problem here is that if the relying party doubts the signature on a cert signed by a CA, how can it trust the response from a responder delegated by the CA.
> From an attacker's point of view, If i have compromised the  CA, then I won't stop at issuing the EE cert, I would issue myself a responder cert as well.

1) The existence of this extension will tend to eliminate hackers who don't do that, but that doesn't mean there won't be any.

2) The existence of this extension enables other mitigations which would require other work.  I don't want to get into that since I think it's off-topic for such a simple proposal.

---

From: Santosh Chokhani <[email-masked]>
Date: Sat, 17 Mar 2012 11:22:22 -0400

I did not mean to insult you.  May be I am just a harsh critique.

I see several folks posting a lot on this forum without thinking security aspects through. 

Since PKI's main purpose is security, we need to design features that aid or provide security and not false sense of security.

BTW, you may want to examine your prior post on parameter inheritance for EC and cross certified CA carefully and see what was ludicrous about it.  That is your homework assignment.  Now, do not feel insulted.  I am just being tough.  It will help sharpen your security analysis skills.  Consider all this as free tutoring. :-)

-----Original Message-----
From: Phillip Hallam-Baker [mailto:[email-masked]] 
Sent: Friday, March 16, 2012 5:06 PM
To: Santosh Chokhani
Cc: David A. Cooper; [email-masked]
Subject: Re: [pkix] certificate not issued OCSP status response

The mere fact that a feature is in PKIX does not mean we have to allow its use. Clearly any observational feedback system (e.g. EFF Observatory, Convergence) would look for such a certificate and flag it as unusual.

But given the circumstances you cite, wouldn't the much easier path be for the attacker to simply issue themselves a cross certificate with cert signing capability?

In real life an attacker would be rather unlikely to favor that approach because it would likely trigger secondary controls within the CA that are there to detect certs with the cert signing bit set. Your post tells me that I should consider this particular PKIX feature as another red flag (but my controls tend to describe what is strictly allowed rather than denied in any case).

On Fri, Mar 16, 2012 at 4:50 PM, Santosh Chokhani <[email-masked]> wrote:
>> The supposed advantages of adding a 'does not exist' response 
>> continue to elude me.  Back in November I explained in detail why I 
>> didn't believe that adding this new response would provide much in 
>> the way of additional security, and if anything might only create a 
>> false sense of security (see 
>>> The problem of enabling a 'does not exist' certificate status is 
>>> much simpler and a direct and logical extension of what OCSP already does.
>>>
>>>
>>>> additional status information is related to information available 
>>>> by the CA that has issued the certificate. In particular, since CRL 
>>>> is a "black list" mechanism, OCSP is able to use a "white list"
>>>> However, the benefit of using a white list mechanism is only a 
>>>> small advantage in case the CA is compromised.
>>>> The danger is that people might think that white list mechanisms 
>>>> are much better than black list mechanisms, whereas this is not as 
>>>> straight.
>>>>
>>>> Denis
>>>>
>>>> known to be deployed to be moved to Historic simply because 
>>>> companies like itself do not use it, even if other entities are 
>>>> known to use it. The PKIX WG makes protocols that are useful to a 
>>>> wide range of entities, not just public CAs.
>>>>
>>>> something is "better" done in SCVP, it cannot be done in OCSP. I 
>>>> agree with Phill that any status of a certificate, including that 
>>>> it was not issues or is expired, is still status and should be able 
>>>> to be represented in a well-deployed protocol such as OCSP.
>>>>
>>>> --Paul Hoffman
>>>>

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 19 Mar 2012 11:59:07 +0000

> such need to implement SCVP?

Then again, any OCSP service can implement virtually any processing change without modification of the protocol or the clients.  E.g., if an OCSP service has access to the CA history and the queried cert isn't present at all, "UNKNOWN" and "REVOKED" are valid answers.  Why does the client need a new return code (e.g.,  "NEVERISSUED") in this case?

Case in point:  DigiNotar runs their terminal OCSP service this way under the current standard.  Did anyone have a problem with that?

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 19 Mar 2012 12:07:28 +0000

> Can I turn the question around and ask why adding a 'does not exist' response would be bad?

It's a subset of UNKNOWN?

It's incompatible with the installed base?

> To answer your question more directly, I think there are scenarios that could most easily be addressed if such a response could be provided.  

Examples, please?

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 19 Mar 2012 12:10:17 +0000

> do not delete the logs, the CA will have a record of the bogus certs

DigiNotar does this *today* by responding REVOKED in that case, and they didn't modify the protocol.

So this scenario is covered by current practice.  

Try again.

> breached.

That's a hell of a claim.  Prove it.  

-- T

---

From: Tom Ritter <[email-masked]>
Date: Mon, 19 Mar 2012 09:18:59 -0400

This discussion has gone round and round several times.  If a CA takes
the steps to wire their OCSP responder to their cert database so they
can make positive assertions about certificates ("Yes, this
certificate is known and good." vs "This cert is not in my revoked
list.") the response to a query "Is this certificate good?" that is
logically "No, that certificate is not good, I don't remember ever
issuing it!" must be translated to an OCSP status message that causes
a failure on the client.

> So this scenario is covered by current practice.

This is really good.  But unless I'm really missing something, there
is no standard or consensus to do this.  Since it's covered by current
practice - maybe a technical note of some sort could be circulated
referencing this?

However, it would still be very nice to tell the client "Things are
really, *really* weird! You should perhaps do something" which the
client could then alert the user, save diagnostic information, prompt
an error-reporting mechanism that's built into several browsers, save
to a log, or ignore (perhaps with or without an extension - any FF
extension like NoScript, Cert Patrol, etc would be very interested in
this info.)

I think it's really good for CA's to wire the OCSP responder up to the
cert database instead of a CRL, and I think it's really good to convey
the information back to the client that there's this weird thing going
on - although I concede that this is a corner case that would not be
applicable in all CA compromises, and in some would just be another
fraudulent response provided by a CA.

-tom

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 19 Mar 2012 14:03:44 +0000

> issuing it!" must be translated to an OCSP status message that causes

The effect sought is to cause a the client to reject the certificate.  Responding REVOKED does that.  If you respond NOTISSUED, does the client reject the certificate *more* than if you respond REVOKED?  :)

> is no standard or consensus to do this.  

So what?  Why should there be?

> 									Since it's covered by current

I said the last time around (November?) that a Security Note would be appropriate but changing the protocol is kinda pointless.

> extension like NoScript, Cert Patrol, etc would be very interested in

The idea that you'd use NOTISSUED to cause the client to somehow mark the CA as untrusted is flawed because it presumes trust in the responder is separate from trust in the issuer, which is neither guaranteed, appropriate, or even actionable at the client.

If you want to control trust anchors, we have TAMP for that.

-- T

---

From: Stephen Kent <[email-masked]>
Date: Mon, 19 Mar 2012 10:21:55 -0400

Liaquat,

Thanks for providing an example of an attack scenario and its 
implications re various countermeasures.

Here's an "easy to imagine" alternative scenario:

  - attacker gains access to HSM and causes a cert to be issued, with the
same serial number as a extant, legitimate cert.

- no record of cert issuance appears in any CA log.

- an OCSP response for the cert serial number will not yield
a "revoked" or "not issued" because the legitimate cert in question is
valid and not revoked.

until the CA is made aware of the bogus cert, it cannot revoke it,
and at that time a CRL or the current OCSP mechanism will work as well
as any proposed enhancements to OCSP.

Thsi is why a thorough, well-written analysis of the problems to be
solved is needed before we pursue changes of the sort being proposed.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 19 Mar 2012 11:55:17 -0400

Henry,

a "does not exist" reply represents a deviation from the stated scope of
OCSP, and thus if we're going to pursue it we need a thorough explanation of
what problems it solves, and how it interacts with various 
implementation models, e.g., OCSP servers that generate responses 
based only on access to CRLs.

Steve

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 19 Mar 2012 17:39:46 +0100

Steve,

I think I lost you here.

>a "revoked" or "not issued" because the legitimate cert in question is

If the CA has no record of it, why would it not yield a "not issued"
response?

I'm not saying that we should go there. Just couldn't follow your logic.

/Stefan

---

From: Michael Myers <[email-masked]>
Date: Mon, 19 Mar 2012 09:56:59 -0700

> If the CA has no record of it, why would it not yield a "not issued"

Because one cannot prove a negative.  Use 'unknown.'

---

From: brennan security <[email-masked]>
Date: Mon, 19 Mar 2012 13:01:30 -0400

Steve,

Your words, "Th[is] is why a thorough, well-written analysis of the
problems to be solved is needed before we pursue changes of the sort being
proposed" is exactly what I was thinking.

As you suggested, I propose we perform some risk analysis on PKI as it
relates to OCSP:
Assets: CAs, Validation infrastructure, operating system & application
trust stores, transactions, HSMs, etc.
Asset vulnerabilities & weaknesses: intrinsic gaps in asset functionality
or implementations
Threats: exploitations of vulnerabilities and weaknesses
current attack/threat scenarios: , both historical and potential (comodo,
digitotar/PKIoverheid, RapidSSL, Globalsign, others) and potential
remediations for the same.
Countermeasures: protective mechanisms, alterations that address
vulnerabilities & weaknesses.

Then, to conclude, some data on current implementations in industry so any
proposed solutions best considers industry impacts and resourcing.

To that end I volunteer to work on this effort with others, as it coincides
with my present work (high security CA and OCSP infrastructure)

Brennan

On Mon, Mar 19, 2012 at 10:21 AM, Stephen Kent <[email-masked]> wrote:

> Liaquat,
>
> Thanks for providing an example of an attack scenario and its implications
> re various countermeasures.
>
> ______________________________**_________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/pkix<https://www.ietf.org/mailman/listinfo/pkix>
>

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 19 Mar 2012 13:07:32 -0400

In Steve's example, the attacker-generated cert (for which there is no
record) has the same serial number as a legitimately-issued cert.  The
CA's database shows the serial number as existing and not revoked, and
nothing has come to the CA's attention to indicate that two certs with
the same serial number have been signed.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stefan Santesson
Sent: Monday, March 19, 2012 12:40 PM
To: Stephen Kent; Liaquat Khan
Cc: [email-masked]
Subject: Re: [pkix] certificate not issued OCSP status response

Steve,

I think I lost you here.

On 12-03-19 3:21 PM, "Stephen Kent" <[email-masked]> wrote:

>- an OCSP response for the cert serial number will not yield a 
>"revoked" or "not issued" because the legitimate cert in question is 
>valid and not revoked.

/Stefan

---

From: Piyush Jain <[email-masked]>
Date: Mon, 19 Mar 2012 10:10:30 -0700

> Date: Mon, 19 Mar 2012 17:39:46 +0100
> From: [email-masked]
> To: [email-masked]; [email-masked]
> CC: [email-masked]

because a valid certificate with the same serial exists in CA database. Since the responder only gets the serial number in the OCSP request, it cannot differentiate between a fake and a good certificate.

---

From: brennan security <[email-masked]>
Date: Mon, 19 Mar 2012 13:14:47 -0400

Steve,

the text from RFC 2560 reads, "The "good" state indicates a positive
response to the status inquiry.
   At a minimum, this positive response indicates that the certificate
   is not revoked, but does not necessarily mean that the certificate
   was ever issued or that the time at which the response was produced
   is within the certificate's validity interval."

My conclusions from that are:
OCSP as a blacklist, didn't anticipate white-list type of functionality
A good response is within specs for a response to a query about an
unknown and potentially compromised certificate
An unknown might be more appropriate for enterprise type of responder
implementations and should be more strictly defined.
Not issued - as an indicator of a potential CA/RA compromise, should
be treated much differently from good / bad / unknown (more daily type
of items depending on the implementation).

Consequently I concur in the need for a "not issued" response.

-b

---

From: brennan security <[email-masked]>
Date: Mon, 19 Mar 2012 13:18:35 -0400

Piyush,

in looking over the RFCs I was wondering the same exact thing, and was
curious why

 CertID          ::=     SEQUENCE {
       hashAlgorithm       AlgorithmIdentifier,
       issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
       issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
       serialNumber        CertificateSerialNumber }

didn't look more like

 CertID          ::=     SEQUENCE {
       hashAlgorithm       AlgorithmIdentifier,
       issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
       issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
       certNameHash      OCTET STRING, -- Hash of Certificate's DN
       certKeyHash       OCTET STRING, -- Hash of Certificate public key
       serialNumber        CertificateSerialNumber }

(is that sufficient?)

Perhaps someone in the know could respond on that?

-b

On Mon, Mar 19, 2012 at 1:10 PM, Piyush Jain <[email-masked]> wrote:
> because a valid certificate with the same serial exists in CA database.
> Since the responder only gets the serial number in the OCSP request, it
> cannot differentiate between a fake and a good certificate.
>

---

From: Michael Myers <[email-masked]>
Date: Mon, 19 Mar 2012 10:24:32 -0700

On Mar 19, 2012, at 10:14 AM, brennan security wrote:

> Consequently I concur in the need for a "not issued" response

I disagree.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 19 Mar 2012 13:43:57 -0400

People insist on looking at these interactions on the level of
individual client-server interactions which is a mistake.

What was most important in the DigiNotar case was not that the cert
was revoked or not it was that Google had the means to discover
certificates that were not consistent with the issue policy for
google.com.

In this case a NOTISSUED response for an actual cert would sound alarm
bells at the meta-level and an industry level response. Contrawise
responding to a request for a non-existent cert with any other status
would be a cause for concern.

For accountability to work at the CA level, the ability to distinguish
these responses is essential.

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 19 Mar 2012 13:51:13 -0400

Assuming that a NOTISSUED response is universally implemented, why would a rational attacker choose to generate a cert that would sound alarm bells and lead to an industry-level response, as opposed to generating a cert that would pass undetected by piggybacking on a valid cert?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker
Sent: Monday, March 19, 2012 1:44 PM
To: Miller, Timothy J.
Cc: [email-masked]
Subject: Re: [pkix] certificate not issued OCSP status response

People insist on looking at these interactions on the level of individual client-server interactions which is a mistake.

What was most important in the DigiNotar case was not that the cert was revoked or not it was that Google had the means to discover certificates that were not consistent with the issue policy for google.com.

In this case a NOTISSUED response for an actual cert would sound alarm bells at the meta-level and an industry level response. Contrawise responding to a request for a non-existent cert with any other status would be a cause for concern.

For accountability to work at the CA level, the ability to distinguish these responses is essential.

On Mon, Mar 19, 2012 at 10:03 AM, Miller, Timothy J. <[email-masked]> wrote:
>> This discussion has gone round and round several times.  If a CA 
>> takes the steps to wire their OCSP responder to their cert database 
>> so they can make positive assertions about certificates ("Yes, this 
> The effect sought is to cause a the client to reject the certificate.  
> Responding REVOKED does that.  If you respond NOTISSUED, does the 
> client reject the certificate *more* than if you respond REVOKED?  :)
>
>> Since it's covered by current practice - maybe a technical note of 
>> some sort could be circulated referencing this?
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 19 Mar 2012 13:52:13 -0400

I have no problem with the activity of any CA that is no longer in the
root trust store.

If it was a current CA I would want to know if they knew the
difference between a cert they never issued and one that they did so
that I can interdependently audit their acitivities.

---

From: Michael Myers <[email-masked]>
Date: Mon, 19 Mar 2012 10:58:23 -0700

On Mar 19, 2012, at 10:43 AM, Phillip Hallam-Baker wrote:

> bells at the meta-level and an industry level response.

Who did NOT issue the cert?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 19 Mar 2012 13:57:45 -0400

I think that what we need here is to have a standard for revocation where

1) Positive status reports bind to the certificate by means of a
digest and not merely the serial number
2) Negative reports distinguish issued but revoked / expired from not issued

The lack of a cryptographic binding from the OCSP response to the cert
is also a defect in the protocol that should be fixed.

---

From: brennan security <[email-masked]>
Date: Mon, 19 Mar 2012 14:06:42 -0400

David,

one of the problems* with validation status currently, is that an
attacker with a CA/HSM compromise, may issue a certificate with an
identical serial number to an existing certificate.  An OCSP response
is based on certificate serials and has no link to the actual public
key, so a rogue certificate impersonating a good one via a shared
serial, would have a good status.

This wouldn't generate alarm bells unless some specific tools are
being used to perform certificate identification
(observatory/convergence/cert patrol/others)

Not issued is fundamentally not enough to fix the issue, as PHB and
myself have mentioned.  There has to be a relationship to the public
key.

* There are many other issues, some of which are already being addressed.

-b

---

From: Liaquat Khan <[email-masked]>
Date: Mon, 19 Mar 2012 18:06:25 +0000

It's a valid attack scenario Steve, again assuming attacker has got access
to CA's HSM, which is obviously a major problem for CA.

Your scenario shows clearly that the OCSP responder cannot protect against
this even with "not issued" response.

Interestingly this means SCVP is a better protocol for implementing this
check since at least it gets the full cert from the client and can really
determine if that particular cert was every issued or not.  Note this
doesn't mean that I am advocating supporting this in SCVP!

So I think we are still at square one, what is the attack scenario this
feature is trying to prevent or at least detect?  From what I can see its
only for the detection that a fake certificate was issue by an attacker by
accessing the CA's HSM and the attacker chose not to re-use an existing
serial number and also chose not to use a compromised OCSP responder cert
to respond for that cert, and also chose to delete the cert from the CA's
database in case the HSM was accessed through the CA etc. etc.  IMO this
shows its not really worth changing the protocol for such a very narrow
attack scenario. The attacker is not going to be so naïve, especially if
they have the skills to break into the CA.

Regards
LK

---

From: Stephen Kent <[email-masked]>
Date: Mon, 19 Mar 2012 14:20:33 -0400

At 1:01 PM -0400 3/19/12, brennan security wrote:
>problems to be solved is needed before we pursue changes of the sort 
>being proposed" is exactly what I was thinking.
>
>As you suggested, I propose we perform some risk analysis on PKI as 
>it relates to OCSP:
>Assets: CAs, Validation infrastructure, operating system & 
>application trust stores, transactions, HSMs, etc.
>Asset vulnerabilities & weaknesses: intrinsic gaps in asset 
>functionality or implementations
>current attack/threat scenarios: , both historical and potential 
>(comodo, digitotar/PKIoverheid, RapidSSL, Globalsign, others) and 
>potential remediations for the same.
>Then, to conclude, some data on current implementations in industry 
>so any proposed solutions best considers industry impacts and 
>resourcing.
>
>To that end I volunteer to work on this effort with others, as it 
>coincides with my present work (high security CA and OCSP 
>infrastructure)
>
>Brennan

Thanks for volunteering.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 19 Mar 2012 14:26:57 -0400

>doesn't mean that I am advocating supporting this in SCVP!

understood.  and, if the primary problem to be addressed is in the
public CA space, SCVP is not applicable anyway.

>feature is trying to prevent or at least detect?

I want to know that too :-).

I think we need to see what folks generate as a problem statement and
then we can debate what is the best way to solve the problem(s).

Steve

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 19 Mar 2012 15:04:33 -0400

I have been working on a paper, the real question here is scope.

Google proposed some pretty extensive changes to the way the system
worked in their Certificate Transparency proposal. Then there is the
EFF Observatory and the Perspectives/Convergence approach.

I think we will need to look at the name and trust infrastructure
together and from the point of view of 'how do we stop bad things
happening to the end user' rather than looking at fixing things
piecemeal.

One reason for that is that most of the new PKI proposals to date have
been focused only on replacing DV certs which are the lowest grade
cert and not very interesting from a security point of view. The main
point of the SSL CA system for me is to introduce accountability
controls. When people are talking about the objective being to make
sure that DNS names resolve to the owners, this seems to be wrong to
me. I do not want users going to sites that are controlled by the
criminals regardless of whether they have paid their $6 to ICANN for a
domain name or their $whatever to a CA.

The notary scheme proposed in CT may or may not have value, but before
introducing another party into the system, I would like to do what we
can with the existing system.

I also note that one of the reasons for the success of SSL is that the
server admins had a big incentive to deploy crypto and there was an
infrastructure there with call centers etc. to hand hold them through
the process. We never had that for S/MIME or for any of the identity
proposals. And that hurt in two ways, first it meant that users had to
work out how to do crypto by themselves and second there was no
constituency saying 'hey we need simpler crypto admin, the cost of
call center people is eating our margins'.

So the model I am currently looking at is to introduce a client side
broker that would be the proxy for all name and certificate queries,
capable of fast response via a UDP based protocol or longer responses
layered over https.

Such a protocol would be a hybrid of SCVP and DNS recursive resolver
and would provide the same two basic choices, delegated path discovery
or delegated path validation. I would expect it would be a part of an
AV type suite and eventually be hooked into the O/S like AV solutions
are.

Combining both functions in a single service gives the proxy a lot
more information to work with and many more tools. So for example, a
client attempts to connect to a DNS name that was only registered 8
hours ago is suspicious but could have a legitimate explanation, same
for attempting to connect to an IP address in a block allocated to
domestic use or even an IP address associated with possible botnet
activity. But if all three yellow flags are present they add up to a
big red flag and the client really does not want to connect.

So the consumer I am envisioning for this information is not the
endpoint client, that does not have enough context to make useful
decisions. We had the same problem with spam filtering. Put the spam
filter on the email client and all it can do is content analysis which
is a pretty low quality spam filter. Put the filter on the email
server and you can do more because you can apply timing analysis. Put
the filter on an email server servicing millions of messages an hour
and it is much easier to spot the spammy signal in all the noise.

The rule for such a service should be that it can veto name/trust
decisions but not create them. So the browser is only going to show
the DV (padlock) or EV (green bar) chrome if it sees a certificate
that chains to one of the roots it trusts and if it is checking
DNSSEC, it is only going to accept RRs consistent with its chosen
DNSSEC roots. The proxy should not be able to create certs or DNS
names out of thin air but it should be able to block them.

I think we need to have a conversation on this but it is going to be a
rather longer one than we can manage in Paris, or at an IETF meeting
come to that. It is more the sort of thing that we need a two day
workshop or the like for.

On Mon, Mar 19, 2012 at 2:20 PM, Stephen Kent <[email-masked]> wrote:
>> coincides with my present work (high security CA and OCSP infrastructure)
>>
>> Brennan
>
>
> Thanks for volunteering.
>
>
> Steve

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 19 Mar 2012 13:18:10 -0700

> It's a subset of UNKNOWN?

To me UNKNOWN means "my knowledge is incomplete (and therefore not authoritative)" and does not mean "this is clearly bogus".

Looking at 2560, it's actually worse because "never issued" is explicitly a subset of "good" (Section 2.2, paragraph 6).

> It's incompatible with the installed base?

Well, yes.  Less incompatible than switching to SCVP though.

>> To answer your question more directly, I think there are scenarios that could most easily be addressed if such a response could be provided.  

Suppose the trust models are updated so a CA compromise does not compromise the OCSP responder.  We *still* need a way to tell the clients that a cert is bogus.

In a lot of ways I think I prefer your suggestion that we redefine the existing codes to require the responders to provide the needed information.  It should be less incompatible than creating a new extension, I hope.

---

From: Michael Myers <[email-masked]>
Date: Mon, 19 Mar 2012 14:20:19 -0700

On Mar 19, 2012, at 1:18 PM, Henry B. Hotz wrote:

> To me UNKNOWN means "my knowledge is incomplete (and therefore not  
> authoritative)" and does not mean "this is clearly bogus".

It was intended that the responder's knowledge is complete with  
respect to its scope of authority.

---

From: Martin Rex <[email-masked]>
Date: Tue, 20 Mar 2012 00:15:37 +0100 (MET)

> client reject the certificate *more* than if you respond REVOKED?  :)

Maybe you want the client to reject it "less" than if you respond REVOKED,
because it might cause newly issued certs to be rejected for a few days
if those responses are cached.

The value I see in white-listing of certs (and OCSP responses reflecting this)
is not about throughly compromise CAs, but for disaster recovery and damage
control for the CA.  As I previously complained, X.509 was invented with
no apparent plan for disaster recovery.  If there is any suspicion,
the only solution is to immediately and completely nuke the entire PKI,
and re-personalize every PKI credential holder, and not perform any
operations based on the old PKI.

While one should really move to a new PKI after a verified thorough
compromise, that strategy is much less sensible for "suspicious activity".

One of the functions of disaster recovery is the ability to perform an
audit, and then continue operation based on the audited information.
That is only possible if you have a data base (and issuing log) that
can be audited, and which is used for checking certs.

What if you do find malware on one of the machines that the CA software
runs on?  What if it is "just" a remote-root vulnerability that is found
and patch (like that one on March patch-tuesday?).  That you did not hear
the alarm bells ring, does not mean that there was no break-in.

Worst-case scenario is that you loose your HSM hardware through some
hardware defect or natural disaster.  How do you know it was purely
accidental, and not a security-breach trying to cover tracks?

Being able to audit a database&log of issued certs, that may have been
partially restored from backup as part of a disaster recovery procedure,
and offering validation against that audited database, seems like a
good idea and sensible risk management.

You probably do not want to nuke a 1+ Mio PKI purely on the possibility
of a breach.  With the possibility of cert whitelisting (and OCSP responses
reflecting that) you may not only ensure that you do not miss the
well-funded attacker that can exploit vulnerabilities without leaving
easily visible traces through one of the still undiscloses ubiquituous
remote-root vulnerabilities in every COTS software, or can make your HSM die.

And you may use the same facility to audit high-value transactions
performed during a time when the CA had to perform a desaster recovery
for whatever reason.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 20 Mar 2012 00:28:30 +0100 (MET)

> the same serial number have been signed.

Whitelisting of certficates should probably use a cryptographically
strong means of authenticating the certificate for which the status
is requested/inquired, like a certificate hash.  And presence of
a certificate hash in the OCSP request could be used to determine
whether the client will understand a "not_issued" rather than an
unknown or revoked(-for-safety) response.

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 19 Mar 2012 17:54:49 -0700

> happening to the end user' rather than looking at fixing things

This feels like the discussion on the "therightkey" mailing list stopped and, after a few weeks, came over to the PKIX WG. Is that intentional?

If the purpose of moving it over to PKIX is to get a discussion slot in Paris because there is no therightkey BoF, that's fine, but some coordination with the ADs is in order. Hallway conversation about the topics will happen regardless, of course.

--Paul Hoffman

---

From: Piyush Jain <[email-masked]>
Date: Mon, 19 Mar 2012 17:57:50 -0700

> From: [email-masked]
> To: [email-masked]
> Date: Tue, 20 Mar 2012 00:15:37 +0100
> CC: [email-masked]

I think the right solution is to confirm the suspicion, and if CA compromise is confirmed, nuke the whole PKI. 
> agreed.
> Confirm if the CA was compromised. Evaluate the risk and decide to continue with the same key or to mark it as compromised.
Confirm if the CA was compromised. Evaluate the risk and decide to continue with the same key (if you have a bakup) or to mark it as compromised.> 
> good idea and sensible risk management.
And it can be done even today. Issue a revoked/suspended response for any serial number that is not part of the audited database.

> remote-root vulnerabilities in every COTS software, or can make your HSM die.
Only two scenarios are possible here. Either the CA key was compromised or it was not. If the key was not compromised, whitelists and 'not-issued' status do not serve any purpose. If the key was compromised, you cannot be sure of what CA says in the future. Attacker could've backed up the CA key, issued a responder key, issued a whitlist signing key, issued white lists valid for next 20 years, messed with the audit log, messed with the CA database. Not sure if there is a way to recover from such a scenario. 
A CA can very well make a conscious decision to continue operating using the compromised key, after assessing that the cost of replacing the whole PKI is fare more than the damage caused by a few (or quite a few) fraudulent certificates that were issued using the compromised key. However, this is a business cost that should be absorbed by the CA as opposed to making every relying party pay for it in form of upgrade costs, bloated requests and responses, higher bandwidths, storage and computational costs for fetching, storing and processing white lists.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 19 Mar 2012 21:23:26 -0400

No, what happened on my end was that I talked to some folk who had
made proposals during RSA and none was intending to go to Paris, hence
making a bar BOF there maybe not so useful :-(

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 20 Mar 2012 12:24:10 +0000

Steve's scenario tells me Issuer+Serial is an insufficiently unique CertID.  

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 20 Mar 2012 12:28:58 +0000

> would be a cause for concern.

Really?   You think that's a good idea?

I can't *wait* for the ability Verisign down simply by sending false OCSP queries.   Then my Evil Plan can commence!  MWahahhahhahaa!  

Seriously, if you expect a CA operator to take action based on *unauthenticated, untrusted input* it receives at the OCSP interface, you've got another thing coming.  Existence of an OCSP request *does not* imply existence of a fraudulent cert.

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 20 Mar 2012 12:31:09 +0000

> To me UNKNOWN means "my knowledge is incomplete (and therefore not authoritative)" and does not mean "this is clearly bogus".

I can form bogus Issuer/Serial combinations all day long.  What does it mean to the CA operator if I do?

-- T

---

From: Carl Wallace <[email-masked]>
Date: Tue, 20 Mar 2012 08:35:23 -0400

>doesn't mean that I am advocating supporting this in SCVP!

Using the id-swb-ers-pkc-cert wantBack defined in RFC 5276, SCVP can
essentially provide a whitelist feature now.  Of course, few shops use
SCVP and none use SCVP/ERS.  It could be worth a look though if whitelist
notion is explored.  ERS provides a hash tree structure that could
represent issued certs and SCVP/ERS defines a request/response to obtain
the proof for a given certificate.

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 20 Mar 2012 09:34:50 -0400

-----Original Message-----
Piyush Jain
>> can be audited, and which is used for checking certs.

Agreed.

> Confirm if the CA was compromised. Evaluate the risk and decide
> to continue with the same key (if you have a bakup) or to mark it as
compromised.

The premise is that you cannot confirm if the CA was compromised, as the
hardware root of trust has been destroyed.

Which raises the question: assuming the HSM is still operating, do
typical HSMs include tamper-resistant audit features, such as signed
records and a hardware-stored operation counter to detect missing
records?  PKIX is being asked to design multi-party protocol workarounds
to fix poor CA operations.  While layered security is a good idea, it's
incumbent on each element of a system to do its part, and the CA has the
bulk of that responsibility.  HSMs that guarantee a secure audit trail
(as long as the HSM itself has not been compromised) would make this
entire discussion moot.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 20 Mar 2012 10:13:48 -0700

> I can form bogus Issuer/Serial combinations all day long.  What does it mean to the CA operator if I do?

As you ourself pointed out, it means someone's generating bogus queries, maybe to make the CA shut down for an audit.  In the real world it most likely means someone's got a buggy client.

I think the real knowledge of whether a "not issued" response is meaningful is mostly on the client side, which raises questions of how a CA can know whether action is needed or not, and whether the client/user will know what to do with it.

(I don't run a CA.)

---

From: brennan security <[email-masked]>
Date: Tue, 20 Mar 2012 13:21:38 -0400

Henry, this is a good point you are making.

A not issued can be indicative of one of a few things:
CA compromise
HSM compromise
Attempted denial of service
Security testing / Auditing
bad performance testing
buggy client
bad data

-b

On Tue, Mar 20, 2012 at 1:13 PM, Henry B. Hotz <[email-masked]> wrote:

> As you ourself pointed out, it means someone's generating bogus queries,
> maybe to make the CA shut down for an audit.  In the real world it most
> likely means someone's got a buggy client.
>
> I think the real knowledge of whether a "not issued" response is
> meaningful is mostly on the client side, which raises questions of how a CA
> can know whether action is needed or not, and whether the client/user will
> know what to do with it.
>
> (I don't run a CA.)
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 20 Mar 2012 13:27:26 -0400

I do like this approach from an abstract point of view and would
certainly propose something of the sort if we were designing the whole
system de novo.

There are two problems though. The first is that there are 40 odd CAs
in operation and I have no way to know the capabilities of all the
HSMs in use. Unless this is a FIPS-140 requirement it is unlikely to
be ubiquitously supported. Any retrofit that touches the online crypto
services ends up being very expensive due to the need for testing.

A second problem is knowing where to stop. Ideally the HSM would be
capable of performing local enforcement of issue constraints (path and
name constraints for example). This sounds good but requires a more
complex HSM and that is bad. If the constraints are complex, they are
likely to be misconfigured.

So while these are certainly controls I would want to deploy if
possible (and cost effective) at the level of my CAs I don't see them
as a viable industry level proposal unless we are prepared to wait a
long time for introduction. I don't see them as a substitute for
protocol based constraints, nor do I see them as likely to be more
secure in practice.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 20 Mar 2012 13:30:55 -0400

This proposal provides much of the same capability as Google's
Certificate Transparency proposal with considerably less deployment
pain for the CAs.

Thus I see it as being a preferable variation of a proposal that is
already being considered seriously.

---

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

The point of the "requested certificate" request extension is to 
permit the responder to distinguish between the conditions among those 
which indicate that an unrecorded but properly signed certificate is in 
circulation and the ones which don't.  If the certificate has a valid 
signature but is missing from the repository, the CA has some obligation 
to take action.  An attempted DoS or a buggy client does not create any 
such obligation, nor does security testing.
        My own draft of requirements has three entries, and one of them is 
just "To maintain backwards compatibility of both client and responder 
code with RFC 2560-compliant implementations in the complementary role". 
The first substantive requirement is "To permit the client to distinguish 
between those certificate serial numbers which the responder claims to 
belong to valid certificates and those which the responder is simply 
stating have not been revoked, in those cases where the responder chooses 
to implement this feature".  This is only important as a way of making 
decisions if it's considered plausible that a validly signed certificate 
can be created without the CA standing behind it, whether by digest 
collision, key compromise, or an attacker gaining sufficient control of 
the CA to issue certificates and then remove the internal record of them. 
The other is "To permit a client to present a certificate to a responder 
supporting the unknown status (or the not issued status) for determination 
of whether that certificate is known to the responder", which is a way of 
communicating a certificate which is a candidate to be "unrevoked, with a 
valid signature, but never valid".

Tom Gindin

From:   brennan security <[email-masked]>
To:     "Henry B. Hotz" <[email-masked]>, 
Cc:     "[email-masked] PKIX" <[email-masked]>
Date:   03/20/2012 02:21 PM
Subject:        Re: [pkix] certificate not issued OCSP status response
Sent by:        [email-masked]

-b

I think the real knowledge of whether a "not issued" response is 
meaningful is mostly on the client side, which raises questions of how a 
CA can know whether action is needed or not, and whether the client/user 
will know what to do with it.

(I don't run a CA.)