Subject: [pkix] Possible OCSP Extensions

From: Tom Gindin <[email-masked]>
Date: Sat, 10 Mar 2012 12:50:20 -0500

Why isn't there an OCSP response extension containing "never 
issued" or "outside validity period" which a responder may use if they 
have the CA's certificate repository available?  Getting a request that 
produces such an error would not be anything which the responder would be 
expected to report.  A client who had received a response with such an 
extension could then demonstrate that an actual compromise had occurred by 
resending the request with a request extension containing the actual 
certificate, or perhaps the chain, which had provoked that response 
extension above.  Receiving such a certificate would allow the OCSP server 
to verify that the CA had actually been cracked and then react.
        I think that such a feature would be useful to responders operated 
by a CA with many subordinate CA's, and possibly to others as well.

Tom Gindin
P.S. - The above suggestion is mine, and not necessarily that of my 
employer.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 11 Mar 2012 12:17:53 -0400

I think it would be good to have a way to state precisely what the
server knows about the certificate. This can lead to problems though
if the OCSP server is on a batch update from the certificate service.

If we are going to make this scale it has to be possible to pre-sign
the proofs of non-existence as an option. That means adopting the
NSEC-type approach of signing the gaps between the existing records.

So what I think is needed is actually two pieces of response data:

1) This service has no knowledge of any certificate between serial # X and Y
2) This assertion was generated from data current at time X

The signing time is arguably a proxy for the second - or could be made such.

What I totally reject is the notion that we should constrain the spec
according to the architecture of certain third party OCSP responders
as has been proposed in the past. The CAs have this data and the
relying apps have a purpose that requires it.

There may well be a role for fourth parties (not a CA, subject or RP)
to add value to PKIX certificates as I have proposed on the Right Key
list. I just don't think OCSP is the right protocol for doing that.
Nor is DNS.

On Sat, Mar 10, 2012 at 12:50 PM, Tom Gindin <[email-masked]> wrote:
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

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

---

From: Piyush Jain <[email-masked]>
Date: Sun, 11 Mar 2012 10:17:38 -0700

Is this trying to address the case where CA continues to operate after it
has been compromised?
I'm assuming that in this case EE certificates have been signed using the CA
key and somehow deleted from the CA's issued certificates repository.
What happens if the attacker issued an OCSP signing certificate (with
OCSP-no-check) as opposed to an EE certificate?

Many of us would believe that only way to address this breach is to revoke
the CA.

There could be limited use of this extension for the CA to determine if it
has been compromised.

-Piyush

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Tom Gindin
> Sent: Saturday, March 10, 2012 9:50 AM
> To: pkix
> Subject: [pkix] Possible OCSP Extensions
> 
issued" or
> "outside validity period" which a responder may use if they have the CA's
> certificate repository available?  Getting a request that produces such an
> error would not be anything which the responder would be expected to
> report.  A client who had received a response with such an extension could
> then demonstrate that an actual compromise had occurred by resending the
> request with a request extension containing the actual certificate, or
perhaps
> the chain, which had provoked that response extension above.  Receiving
> such a certificate would allow the OCSP server to verify that the CA had
> actually been cracked and then react.
by a
> CA with many subordinate CA's, and possibly to others as well.
> 
> Tom Gindin
employer.

---

From: Tom Gindin <[email-masked]>
Date: Sun, 11 Mar 2012 23:50:41 -0400

Piyush:

        One purpose of this is to identify cases where the issuer has 
apparently been compromised, and the major purpose of the request 
extension (call it "requested certificate body" or "requested certificate 
chain") is to allow such a case to be substantiated.  Once the request is 
substantiated, I would expect the issuer key to be treated as compromised 
unless the submitted certificate is a digest duplicate against an actual 
issued certificate.  That would be an algorithmic issue rather than a key 
compromise.
        I'd like to adapt part of Phill's suggestion, and redefine the 
proposed "never issued" status as "Not issued before" and a time.  The 
presigned variant, which might be called "no serial number within range", 
seems right for issuers with increasing serial numbers but makes less 
sense for issuers who assign serial numbers which don't monotonically 
increase with time.  Phill, is that supposed to be the closed interval 
(with the two endpoint serial numbers not issued) or the open one (with 
the two endpoint serial numbers issued)?  Also, is there an option in 
which the upper bound is not specified which means "no serial number above 
L had been issued as of time T"?

Tom Gindin

From:   Piyush Jain <[email-masked]>
To:     Tom Gindin/Watson/IBM@IBMUS, "'pkix'" <[email-masked]>, 
Date:   03/11/2012 01:17 PM
Subject:        RE: [pkix] Possible OCSP Extensions

I'm assuming that in this case EE certificates have been signed using the 
CA

-Piyush

issued" or
perhaps
by a
employer.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 12 Mar 2012 08:57:21 -0400

And many of us think that we should fix the damn spec to do what it
was originally intended to do until a bunch of people with a business
model and a startup ruined it.

There are many reasons why this functionality would be required. There
are tens of thousands of certs revoked for cause every year. less than
1% of those so revoked last year were due to mis-issue.

Why do we have so many people obsessing about what has been the rarest
use case for OCSP and not the fact that the browsers don't actually
hard fail on OSCP?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 12 Mar 2012 09:29:36 -0400

Actually, the idea for the serial numbers was not that they would
necessarily be monotonic, rather the idea is just to sign the gaps. If
the CA signs non-monotonic serial numbers then they would have to sort
them into order first.

So the way a CA would work is that every OCSP signing increment, say 1
hour, they would create OCSP responses for

1) Every known cert issued
2) The gaps between the serial numbers.

So with 100 certs issued, this would be 200 OCSP responses.

If a cert is issued within that time interval, the CA creates three
additional OCSP responses, one for the new cert and two for the new
serial number intervals that have just been created.

This approach allows CAs to avoid creating additional timing errors
but is still robust if they are introduced by others.

---

From: Rob Stradling <[email-masked]>
Date: Mon, 12 Mar 2012 13:45:12 +0000

> but is still robust if they are introduced by others.

The CA may have issued three additional OCSP Responses, but how do you 
force clients to use them instead of cached copies of the previous 
Responses?

Would the Responder have to set the various HTTP "no cache" headers when 
it sends a "gaps between the serial numbers" Response?

Or would we just have to accept that newly issued certs may cause 
spurious OCSP errors within the first 1 hour of their lifetime?

> On Sun, Mar 11, 2012 at 11:50 PM, Tom Gindin<[email-masked]>  wrote:
>>         Piyush:
>>
>> From:   Piyush Jain<[email-masked]>
>> To:     Tom Gindin/Watson/IBM@IBMUS, "'pkix'"<[email-masked]>,

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

---

From: [email-masked]
Date: Mon, 12 Mar 2012 14:45:49 +0100

Tom,

Your email is not crystal clear (at least to me) and seems to address at 
the same time two different topics:

   - an OCSP response extension containing "never issued" and
  - an OCSP response extension containing "outside validity period". 

I can understand "never issued", but I don't know what you mean, in the 
context of OCSP, with "outside validity period"

Your proposal seems allowing an OCSP server "to verify that a CA had 
actually been cracked and then react".
The problem is that we cannot do this, until we first specify a way to 
return a status like "never issued".

Simply adding an additional status report like "never issued" would not be 
sufficient as explained below.

The problem is that OSCP was originally designed to work either :

 - with CRLs only, or 
 - with a revocation status data base for revoked certificates only, or
 - with a revocation status data base for all issued certificates managed 
directly by the CA which issued that certificate.

We currently have no way to indicate either in the request or in the 
response 
which of the three modes is/was requested or used.

An OCSP server might only indicate "never issued", if  it also indicates 
that it got this information using 
a revocation status data base for all issued certificates managed directly 
by the CA which has issued that certificate.

This means that this extension may only be present if the OCSP responder 
is using  a revocation status data base 
for all issued certificates managed directly by the CA which has issued 
that certificate.
 
This extension would then contain a boolean to say whether of not the 
certificate was issued.

I remember that we discuss this topic on the PKIX  list but I don't 
remember any concrete proposal.

Once we have such a mechanism (or a similar one), then we can build on it 
and discuss (and understand better) your proposal.

Denis

De :    Tom Gindin <[email-masked]>
A :     pkix <[email-masked]>
Date :  10/03/2012 18:51
Objet : [pkix] Possible OCSP Extensions
Envoyé par :    [email-masked]

Tom Gindin

---

From: Tom Gindin <[email-masked]>
Date: Mon, 12 Mar 2012 10:20:32 -0400

Denis:

        "Outside validity period" means, in most cases, that the serial 
number requested was indeed issued by the CA but is now expired.  It could 
also mean that the "NotBefore" time is still in the future, but that would 
be much rarer.  It would be feasible to distinguish Expired from Not Yet 
Valid in the response extension, of course.
        Naturally, an OCSP responder must have access to a repository 
containing those certificates which are currently valid for a given issuer 
to determine any of these statuses.  That's your third case, but you can't 
distinguish never issued from outside validity period if expired 
certificates are purged from the repository.  Neither the "revocation 
database" case nor the "CRL only" case give the responder any basis to say 
whether a given serial number belongs to a currently valid certificate, an 
expired certificate which was never revoked, or neither.  A full database 
of certificates which have ever been issued with a given issuer name 
should allow the responder to classify any given certificate serial number 
for that issuer as "revoked" (including suspended), "valid", "expired", 
"not yet", or "unknown".
        If you feel it's desirable for the responder to include which 
repository mode it's using in an extension, I personally see no reason to 
object to such a proposal.  Including the repository mode is not necessary 
for the use of these extensions, because two of the modes are inconsistent 
with using them.

Tom Gindin

From:   [email-masked]
To:     Tom Gindin/Watson/IBM@IBMUS, 
Cc:     [email-masked]
Date:   03/12/2012 09:46 AM
Subject:        RE: [pkix] Possible OCSP Extensions

Tom, 

 - with CRLs only, or 

 

Denis 

Tom Gindin

---

From: Piyush Jain <[email-masked]>
Date: Mon, 12 Mar 2012 15:51:31 -0700

> Date: Mon, 12 Mar 2012 08:57:21 -0400
> Subject: Re: [pkix] Possible OCSP Extensions
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]; [email-masked]
> 

So what was the original intention of the spec?Here is the excerpt from first section of RFC 2560
" This document specifies a protocol useful in determining the current   status of a digital certificate without requiring CRLs."
and the existing specs seem to be adequate to satisfy this intention.
> 1% of those so revoked last year were due to mis-issue.
A few examples would really be helpful in understanding how this functionality will address the needs that simple signature checking cannot address.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 12 Mar 2012 18:53:04 -0700

Seems to me that it ought to be possible for OCSP to provide complete information about the possibly-knowable status of a certificate.  If the OCSP server has complete current and historical information about what certs a CA has issued, then it should be possible say if the cert is good, bad, or doesn't (shouldn't) exist.

While I've no objection to supporting optimizations in how OCSP responses can be pre-generated or cached, that seems mostly like implementation and deployment rather than protocol.

> model and a startup ruined it.

;-)

> server knows about the certificate.

Are you asking that a client be able to tell if "never issued" wasn't returned because the COSP responder doesn't support that extension (as opposed to because the cert really had been issued)?  Seems like a useful complementary capability.
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 12 Mar 2012 19:00:08 -0700

On Mar 12, 2012, at 5:57 AM, Phillip Hallam-Baker wrote:

> And many of us think that we should fix the <deleted> spec to do what it

;-)

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 12 Mar 2012 22:27:35 -0400

If the Issuer is compromised, unless there is a trust established in the Responder independent of the Issuer, the attacker can manufacture proof it wishes to.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tom Gindin
Sent: Sunday, March 11, 2012 11:51 PM
To: Piyush Jain; Phillip Hallam-Baker
Cc: 'pkix'
Subject: Re: [pkix] Possible OCSP Extensions

        Piyush:

        One purpose of this is to identify cases where the issuer has apparently been compromised, and the major purpose of the request extension (call it "requested certificate body" or "requested certificate
chain") is to allow such a case to be substantiated.  Once the request is substantiated, I would expect the issuer key to be treated as compromised unless the submitted certificate is a digest duplicate against an actual issued certificate.  That would be an algorithmic issue rather than a key compromise.
        I'd like to adapt part of Phill's suggestion, and redefine the proposed "never issued" status as "Not issued before" and a time.  The presigned variant, which might be called "no serial number within range", seems right for issuers with increasing serial numbers but makes less sense for issuers who assign serial numbers which don't monotonically increase with time.  Phill, is that supposed to be the closed interval (with the two endpoint serial numbers not issued) or the open one (with the two endpoint serial numbers issued)?  Also, is there an option in which the upper bound is not specified which means "no serial number above L had been issued as of time T"?

Tom Gindin

Is this trying to address the case where CA continues to operate after it has been compromised?
I'm assuming that in this case EE certificates have been signed using the CA key and somehow deleted from the CA's issued certificates repository.
What happens if the attacker issued an OCSP signing certificate (with
OCSP-no-check) as opposed to an EE certificate?

Many of us would believe that only way to address this breach is to revoke the CA.

There could be limited use of this extension for the CA to determine if it has been compromised.

-Piyush

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Tom Gindin
issued" or
> certificate repository available?  Getting a request that produces 
> such
an
> then demonstrate that an actual compromise had occurred by resending 
> the request with a request extension containing the actual 
> certificate, or
perhaps
> the chain, which had provoked that response extension above.  
> Receiving such a certificate would allow the OCSP server to verify 
> that the CA had actually been cracked and then react.
by a
employer.

---

From: [email-masked]
Date: Tue, 13 Mar 2012 08:49:11 +0100

Tom,

One of your arguments is to say that the proposal "can't distinguish never 
issued from outside validity period 
if expired certificates are purged from the repository". The question is 
whether this is really necessary. 
The answer is that it is not necessary, as explained below.

A key point is that OSCP has only been designed to provide the revocation 
status of a certificate at the current time.

It should be the responsibility of the OCSP client, before making the OCSP 
request, to test that the current time 
is within the validity period of the certificate. Thus if a certificate 
serial number refers to a certificate that has expired, 
the OCSP response is not meaningful.

However, if the proposal is included, explanations should clearly indicate 
that the additional status is only meaningful 
if the client has locally tested that the the current time is within the 
validity period of the certificate. 

Denis

De :    Tom Gindin <[email-masked]>
A :     [email-masked]
Cc :    [email-masked]
Date :  12/03/2012 15:21
Objet : RE: [pkix] Possible OCSP Extensions

        Denis:

with using them.

Tom Gindin

Tom, 

 - with CRLs only, or 

 

Denis 

Tom Gindin

---

From: Tomas Gustavsson <[email-masked]>
Date: Tue, 13 Mar 2012 09:11:52 +0100

> So with 100 certs issued, this would be 200 OCSP responses.

This is not clear to me? If we, for example, use random 64 bit serial
numbers (which is good for several reasons). After 100 issued
certificates I would not for any practical reasons be able to calculate
any "gaps".

"Gaps" for certificate serial number seems to me to be a non existing thing.

Cheers,
Tomas

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 13 Mar 2012 09:13:58 -0400

RFC 2560, Section 4.4.4, Archive Cutoff

    An OCSP responder MAY choose to retain revocation information beyond
    a certificate's expiration. The date obtained by subtracting this
    retention interval value from the producedAt time in a response is
    defined as the certificate's "archive cutoff" date.

    OCSP-enabled applications would use an OCSP archive cutoff date to
    contribute to a proof that a digital signature was (or was not)
    reliable on the date it was produced even if the certificate needed
    to validate the signature has long since expired.

    OCSP servers that provide support for such historical reference
    SHOULD include an archive cutoff date extension in responses.  If
    included, this value SHALL be provided as an OCSP singleExtensions
    extension identified by id-pkix-ocsp-archive-cutoff and of syntax
    GeneralizedTime.

    id-pkix-ocsp-archive-cutoff  OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }

    ArchiveCutoff ::= GeneralizedTime

    To illustrate, if a server is operated with a 7-year retention
    interval policy and status was produced at time t1 then the value for
    ArchiveCutoff in the response would be (t1 - 7 years).

On 3/13/12 3:49 AM, [email-masked] wrote:
> Tom,
>
> One of your arguments is to say that the proposal "can't distinguish 
> never issued from outside validity period
> if expired certificates are purged from the repository". The question 
> is whether this is really necessary.
> A key point is that OSCP has only been designed to provide the 
> revocation status of a certificate at the current time.
>
> It should be the responsibility of the OCSP client, before making the 
> OCSP request, to test that the current time
> is within the validity period of the certificate. Thus if a 
> certificate serial number refers to a certificate that has expired,
> However, if the proposal is included, explanations should clearly 
> indicate that the additional status is only meaningful
> if the client has locally tested that the the current time is within 
> the validity period of the certificate.
>
> Denis
>
>
>
>
> ------------------------------------------------------------------------
>
>
>
>         Denis:
>

---

From: [email-masked]
Date: Tue, 13 Mar 2012 15:46:23 +0100

David,

You have provided a copy of section 4.4.4 but without providing any text 
modification proposal.

My text proposal was only a strawman proposal and was making the 
assumption that the 
id-pkix-ocsp-archive-cutoff extension was not included in the response.

Taking into account section 4.4.4, a sentence from my previous email 
should be expanded as follows:

Thus if a certificate serial number refers to a certificate that has 
expired, 
the OCSP response is not meaningful when the id-pkix-ocsp-archive-cutoff 
extension is not present, but it is when the id-pkix-ocsp-archive-cutoff 
extension is present. 

It should be noticed that when the  id-pkix-ocsp-archive-cutoff extension 
is present, the status is not 
the revocation status at the current time, but the revocation status at 
the end of the validity period of the certificate. 

It would be worthwhile to mention it in section 4.4.4 in the next draft (
draft-ietf-pkix-rfc2560bis-05). 

Since you are a co-editor ...

Denis

De :    "David A. Cooper" <[email-masked]>
A :     "[email-masked]" <[email-masked]>
Date :  13/03/2012 14:14
Objet : Re: [pkix] Possible OCSP Extensions
Envoyé par :    [email-masked]

Denis 

        Denis:

with using them.

Tom Gindin

Tom, 

- with CRLs only, or 

Denis 

Tom Gindin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 13 Mar 2012 21:15:36 -0400

Yes, but my point was that once the point you make is understood it
becomes obvious that half the alternative proposals are completely
unworkable as well.

The problems you cite with hardfail will be true of DNSSEC for a very
long time to come. So the DANE folk are wasting their time. As for
'Sovereign Keys', that is not simply a hardfail proposal it is a
'permanent perpetual fail' proposal. So good luck with that as well.

The problem with OCSP has been that the proportion of dangerous certs
in the population from all causes has always been low enough for
ignoring revocation to be an acceptable risk/performance tradeoff for
many users. I would not say it was 99.99% but at least 99.5%.

Now that some of the bad guys are putting effort into getting bad
certs, the percentage is likely to change and the risk probably ceases
to be acceptable.

On Mon, Mar 12, 2012 at 8:15 PM, Peter Gutmann
<[email-masked]> wrote:
> Phillip Hallam-Baker <[email-masked]> writes:
>
>>Why do we have so many people obsessing about what has been the rarest use
>>case for OCSP and not the fact that the browsers don't actually hard fail on
>>OSCP?
>
> Because failing hard would be a massive self-inflicted DoS on every browser
> user on the planet.  The problem isn't "browsers don't fail hard", it's
> "99.99% of all OCSP failures [*] are benign, how do we deal with that".
>
> Peter.
>
> [*] Figure freely pulled out of thin air, although Google and Firefox's public
>    observations on the matter indicate that it's very high.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 13 Mar 2012 21:24:12 -0400

The original intention was to provide a scalable solution to
revocation that was not encumbered by the Entrust distribution point
partitioning patent that I had just discovered and to support
authenticode and to enable the selling of per transaction insurance.

The original spec that I wrote with Mike Meyers was hijacked by
Valicert who rewrote our proposal in ASN.1. I still think that was a
better spec to be honest.

Certainly I got a bit peeved when the people who changed our OCSP spec
to make it 'extensible' then decided that extending OCSP to support
SCVP type functionality was not the way to go.

Next time people in charge let someone pull a stunt like that they
need to remember that I will still be bringing it up ten and twenty
years from now whenever the opportunity should arise.

On Mon, Mar 12, 2012 at 6:51 PM, Piyush Jain <[email-masked]> wrote:
> So what was the original intention of the spec?
> Here is the excerpt from first section of RFC 2560
>
> " This document specifies a protocol useful in determining the current
> status of a digital certificate without requiring CRLs."
>
> A few examples would really be helpful in understanding how this
> functionality will address the needs that simple signature checking cannot
> address.
>
>>

---

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

No, that is untrue, OCSP was originally designed to report archival
status at a specific point in time.

People can pull out the good stuff out of the specs if they like but
they don't get to say that it was never the intention to do it.

On Tue, Mar 13, 2012 at 3:49 AM,  <[email-masked]> wrote:
> ________________________________
>
>
>
>         Denis:
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 13 Mar 2012 21:36:19 -0400

So to work out the gaps:

Take the set of issued certs C_set
Sort by serial number to produce a list C_list [0..99]

Create OCSP status responses for
   C[0].serial
   C[1].serial
   ...
   C[99].serial

Create OCSP non-existence responses for
    C[0].serial+1 -> C[1].serial-1
    C[1].serial+1 -> C[2].serial-1
    ...
    C[98].serial+1 -> C[99].serial-1
    C[99].serial+1 -> C[0].serial-1

Does that answer the question?

---

From: Michael Myers <[email-masked]>
Date: Tue, 13 Mar 2012 18:59:13 -0700

> status at a specific point in time.

PHB,

A nit.

:s/archival status/best known revocation status/w/q

Mike

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 13 Mar 2012 22:31:32 -0400

Good point, yep.

Though quite what archival status would be in that case... But
certainly one of the use cases motivating the work was being able to
get a status on a signed document (e.g. a mortgage or a bill of
lading) twenty years later.

---

From: Piyush Jain <[email-masked]>
Date: Tue, 13 Mar 2012 23:18:37 -0700

I like idea of returning the status for a range of serial numbers.
It can be used to return "other" certificate statuses as well. Not that I like the idea of bulk revocations, but it is quite prevalent in some big enterprise PKI deployments in the US. The information in a 20 MB  CRL, which is a result of a few rounds of bulk revocation can be captured in a very few OCSP responses. Also, as Philip suggested earlier, it'll make it possible to pre-sign responses for CAs who generate certificates with non sequential serial numbers.

Going back to the possible status values
- revoked (present in CRL - issued by all kind of responders)
- not present in CRL (issued by responder which does not have access to CA database)
- good (issued by responder which has access to to CA database)
- unknown (CRL not available - issued by responder which does not have access to CA database)
- not issued (issued by responder which has access to to CA database)
- expired (issued by responder which has access to to CA database)

What confuses me is why the last two values are needed at all. If the client can parse the cert and verify signatures, it can figure out if the cert was issued and if it is expired. If the client is a dumb client, it is better off using SCVP. 

> Date: Tue, 13 Mar 2012 21:36:19 -0400
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]

---

From: Tomas Gustavsson <[email-masked]>
Date: Wed, 14 Mar 2012 09:37:38 +0100

>      C[0].serial+1 ->  C[1].serial-1

Since it says "responses". The gap "C[0].serial+1 ->  C[1].serial-1" 
might very well be 10 billion serials, making that completely infeasible 
with modern hardware.

 From a scalability point of view the use case with 100 issued 
certificates is not very interesting. The solutions should work with 100 
million certificates, and an issuance frequency of 100 certificates per 
second, or something like that.

Or are you targeting a corner case with a relatively static CA that does 
not do much?

Cheers,
Tomas

On 03/14/2012 02:36 AM, Phillip Hallam-Baker wrote:
> On Tue, Mar 13, 2012 at 4:11 AM, Tomas Gustavsson<[email-masked]>  wrote:
>>
>>

---

From: Erwann Abalea <[email-masked]>
Date: Wed, 14 Mar 2012 14:05:11 +0100

Bonjour,

2012/3/14 Tomas Gustavsson <[email-masked]>

> Since it says "responses". The gap "C[0].serial+1 ->  C[1].serial-1" might
> very well be 10 billion serials, making that completely infeasible with
> modern hardware.
>

I think noone asked for an OCSP response for all possible serial numbers.
Just an OCSP response with the 2 integers for the range bounds.
These integers must be optional, to be able to semantically represent -Inf
and +Inf.

-- 
Erwann.

---

From: Erwann Abalea <[email-masked]>
Date: Wed, 14 Mar 2012 14:20:26 +0100

Bonjour,

2012/3/14 Phillip Hallam-Baker <[email-masked]>

>    C[99].serial+1 -> C[0].serial-1

That last "link" has no sense. You need to create an OCSP response from
-Inf to C[0].serial-1, and another one from C[99].serial+1 to +Inf.

Precisely, for n certificates, you need 2n+1 OCSP responses. Short-lived
ones, preferably (1 day, maybe?).

Now expand the example to larger numbers. Imagine a deployed PKI for 300
million certificates, renewed every few years (this is not a purely
hypothetical example).
CRL based validation is not an option (well, it may work for signatures,
but not authentication). OCSP is a good tool, as an OCSP response need only
be produced when asked.

Using the proposed scheme would require the CA to sign 600 million OCSP
tokens every day. That's 7000 signatures per second, 7000 OCSP responses
produced and stored somewhere per second, every single second, even if the
OCSP response is not used. OCSP becomes now a non option.

-- 
Erwann.

---

From: [email-masked]
Date: Wed, 14 Mar 2012 14:37:24 +0100

Phil,

You claim that OCSP was originally designed to report archival status at a 
specific point in time.
The fact is that OCSP is currently unable to report archival status at a 
specific point in time.

OCSP reports the revocation status :

a) if the certificate is not expired, at the current time (or close to the 
current time when cached responses are supported),
b) if both the certificate is expired and the archive cutoff extension is 
supported, as it was at the end of the certificate's validity period. 

Denis 

De :    Phillip Hallam-Baker <[email-masked]>
A :     [email-masked]
Cc :    Tom Gindin <[email-masked]>, [email-masked]
Date :  14/03/2012 02:30
Objet : Re: [pkix] Possible OCSP Extensions

> One of your arguments is to say that the proposal "can't distinguish 
never
> A key point is that OSCP has only been designed to provide the 
revocation
> It should be the responsibility of the OCSP client, before making the 
OCSP
> However, if the proposal is included, explanations should clearly 
indicate

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 14 Mar 2012 10:08:02 -0400

No, it is one OCSP response that would sign a statement 'no cert
exists for serial number X through Y inclusive', not ten billion
signed responses.

On Wed, Mar 14, 2012 at 4:37 AM, Tomas Gustavsson <[email-masked]> wrote:
> From a scalability point of view the use case with 100 issued certificates
> is not very interesting. The solutions should work with 100 million
> certificates, and an issuance frequency of 100 certificates per second, or
> something like that.
>
> Or are you targeting a corner case with a relatively static CA that does not
> do much?
>
> Cheers,
> Tomas
>
>
>>>>>> Of
>>>>>> "outside validity period" which a responder may use if they have the
>>>>>
>>>>> CA's
>>>>>>
>>>>>> report.  A client who had received a response with such an extension
>>>>>
>>>>> could
>>>>>>
>>>>>> the
>>>>>>  Receiving
>>>>>>         I think that such a feature would be useful to responders
>>>>>
>>>>> operated
>>>>> by a
>>>>>>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 14 Mar 2012 10:24:17 -0400

On Wed, Mar 14, 2012 at 9:20 AM, Erwann Abalea <[email-masked]> wrote:
> That last "link" has no sense. You need to create an OCSP response from -Inf
> to C[0].serial-1, and another one from C[99].serial+1 to +Inf.

As I said in a previous message, this is following the DNS NSEC
practice of having the last interval wrap and if the start of the
interval is greater than the end it is equivalent to the two intervals
you give.

I am not wedded to that approach, its just that sticking to the DNSSEC
approach gives maximum anti-troll protection on the patent front.

> CRL based validation is not an option (well, it may work for signatures, but
> not authentication). OCSP is a good tool, as an OCSP response need only be
> produced when asked.

True, and this can be a configuration option. The pre-signed approach
definitely makes sense for SSL where the number of certs is low
compared to the number of lookups and you very much want to airgap the
OCSP signature capability from the Internet which is not possible if
there is an on-demand signature creation capability.

It would not make sense for S/MIME where the number of lookups per
cert is very low, probably less than one a day.

The pre-signed issue is not that it be a requirement for operations,
people can operate their OCSP any way they like. But OCSP is already
deployed in a pre-signed configuration at many CAs and any new
proposal has to support that approach.

> OCSP response is not used. OCSP becomes now a non option.

If I could sell 300 million SSL certs I am sure that Melih would be
only too delighted to write a check for the necessary signing units.

The crypto hardware used in CA infrastructure is capable of cloning
keys into other devices under strictly controlled circumstances. So
increasing the OCSP signature capability would mean simply buying and
racking more units.

Adding in the gaps only doubles the number of signatures required and
hardware improves much faster than anyone's sales numbers climb.

Signing the gaps was a big issue in DNSSEC because adding DNSSEC was
an unfunded mandate. Signing every DNS name in .com was a huge deal
and would have had a massive operational impact. If people had taken
seriously the statements I made in 2001 then DNSSEC would have been
deployed for ten years already.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 14 Mar 2012 10:25:38 -0400

When I see a broken protocol I try to fix it. What do you do?

---

From: Stephen Kent <[email-masked]>
Date: Wed, 14 Mar 2012 10:48:35 -0400

At 6:53 PM -0700 3/12/12, Henry B. Hotz wrote:
>Seems to me that it ought to be possible for OCSP to provide 
>complete information about the possibly-knowable status of a 
>certificate.  If the OCSP server has complete current and historical 
>information about what certs a CA has issued, then it should be 
>possible say if the cert is good, bad, or doesn't (shouldn't) exist.

Henry,

yes, but that has not been the model underlying OCSP response generation
in many contexts.

Although I was not an author of OCSP, I have always viewed it as a 
alternative to CRLs, and I think this model is accurate. CRLs convey 
info on whether a cert has been revoked, not whether it is expired, 
not issued, etc. Consistent with this model, an OCSP server can 
generate responses using only a CRL for the CA in question.

In that light, adding additional info about cert status is not 
consistent with basic OCSP functionality. PKIX developed SCVP to 
provide more comprehensive cert status info (within a validation 
context). The WG rejected (narrowly) the idea of making changes to 
extend OCSP to convey this additional info.

So, any proposals for extending OCSP functionality need to be 
justified relative to the model that has underpinned OCSP, the 
existence of SCVP, and any changes in the environment that might 
motivate new OCSP functionality.

I agree with PHB's observation that the public CA (TTP) landscape has changed
dramatically in the recent past. If there is a credible rationale for 
extending OCSP because of this change, then fine. However, proposals 
to extend OCSP to
provide additional status info, more like what SCVP offers, are not 
likely to be viable. OCSP is a "brand" but that does not make it a 
good choice to solve additional problems that will entail 
substantiative protocol changes.

Steve

---

From: Michael Myers <[email-masked]>
Date: Wed, 14 Mar 2012 08:20:06 -0700

On Mar 14, 2012, at 7:48 AM, Stephen Kent wrote:

> an OCSP server can generate responses using only a CRL for the CA in  
> question.

Steve,

For the record, what I had in mind back then was authoritative access  
to the data necessary to the production of a CRL.  With CRLs being  
periodic, the freshest data remained unaccessible.  But lacking such  
access, *then* the CRL.  That's where Ambarish and I got into it.  And  
Carlisle too, as I recall.

Mike

---

From: Stephen Kent <[email-masked]>
Date: Wed, 14 Mar 2012 11:39:34 -0400

At 8:20 AM -0700 3/14/12, Michael Myers wrote:
>>an OCSP server can generate responses using only a CRL for the CA 
>>in question.
>
>Steve,
>
>For the record, what I had in mind back then was authoritative 
>access to the data necessary to the production of a CRL.  With CRLs 
>being periodic, the freshest data remained unaccessible.  But 
>lacking such access, *then* the CRL.  That's where Ambarish and I 
>got into it.  And Carlisle too, as I recall.
>
>Mike

Mike,

Thanks for the historical background. I'd suggest that the data 
needed to produce a CRL is not much different from the CRL itself, in 
this context, except wrt timeliness.

I also observe that RFC 2560 begins with the statement:

"This document specifies a protocol useful in determining the current
status of a digital certificate without requiring CRLs."

That statement suggests that OCSP responses are to be viewed as an alternative
to CRLs (although the term "status" is overly broad here).

The protocol overview in Section 2 refines this notion by stating:

"In lieu of or as a supplement to checking against a periodic CRL, it
    may be necessary to obtain timely information regarding the
    revocation status of a certificate."

This text suggests that OCSP response processing can be either a 
substitute for CRL checking, or that these responses offer a more up 
to date source of revocation status data. The latter interpretation 
is consistent with the
notion of issuing OCPS responses based on the data used to generate 
CRLs, perhaps before the next CRL is issued.

None of this text suggests that OCSP is a way to determine if a cert 
has been issued, one of the features being discussed now.

Steve

---

From: Erwann Abalea <[email-masked]>
Date: Wed, 14 Mar 2012 17:02:26 +0100

> [...]
> -Inf

I get it, now.

[...]

> increasing the OCSP signature capability would mean simply buying and

The example I had in mind is not an hypothetical one. And adding crypto
hardware every year is not an option.

But I read the thread again and noticed that your proposal doesn't need to
impose pre-signing OCSP responses. A "negative gap" OCSP response can be
generated and returned when asked for a non existent serial number.

Sorry, going back to my cave ;)

-- 
Erwann.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 14 Mar 2012 14:13:21 -0400

Does anyone use SCVP?

If there is going to be a choice between maintaining OCSP and
maintaining SCVP then OCSP is going to be the one that I choose.

Could we have a discussion on this at the next meeting? As I see it,
it PKIX is not going to maintain OCSP then it is time to fork the spec
and maintain it elsewhere.

I do not think that anyone can claim that SCVP is sufficiently
deployed to abandon OCSP in its favor.

On Wed, Mar 14, 2012 at 10:48 AM, Stephen Kent <[email-masked]> wrote:
>> Seems to me that it ought to be possible for OCSP to provide complete
>> information about the possibly-knowable status of a certificate.  If the
>> OCSP server has complete current and historical information about what certs
>> a CA has issued, then it should be possible say if the cert is good, bad, or
>> doesn't (shouldn't) exist.
>
>
> Henry,
>
> alternative to CRLs, and I think this model is accurate. CRLs convey info on
> whether a cert has been revoked, not whether it is expired, not issued, etc.
> Consistent with this model, an OCSP server can generate responses using only
> a CRL for the CA in question.
>
> In that light, adding additional info about cert status is not consistent
> with basic OCSP functionality. PKIX developed SCVP to provide more
> comprehensive cert status info (within a validation context). The WG
> rejected (narrowly) the idea of making changes to extend OCSP to convey this
> additional info.
>
> So, any proposals for extending OCSP functionality need to be justified
> relative to the model that has underpinned OCSP, the existence of SCVP, and
> any changes in the environment that might motivate new OCSP functionality.
>
> extending OCSP because of this change, then fine. However, proposals to
> extend OCSP to
> provide additional status info, more like what SCVP offers, are not likely
> to be viable. OCSP is a "brand" but that does not make it a good choice to
> solve additional problems that will entail substantiative protocol changes.
>
> Steve
>

---

From: Piyush Jain <[email-masked]>
Date: Wed, 14 Mar 2012 13:35:45 -0700

> Date: Wed, 14 Mar 2012 14:13:21 -0400
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]
A bunch of Govt. Agencies in the U.S. Mostly enterprise deployments. No public CAs use it.

> maintaining SCVP then OCSP is going to be the one that I choose.
Does not have to be a choice. Use OCSP for revocation status check, use SCVP to completely offload certificate processing.

> deployed to abandon OCSP in its favor.
No need to abandon OCSP. Both can co-exist peacefully :). However, comparing number of deployments seems unfair given that SCVP became an RFC almost 10 years after OCSP.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 14 Mar 2012 16:47:15 -0400

>Does anyone use SCVP?

I'll let others, who know better than I, respond to this question.

>maintaining SCVP then OCSP is going to be the one that I choose.

If the proposal is to keep the name OCSP and add a lot of functionality
that overlaps SCVP, that is not a reasonable course of action.

>and maintain it elsewhere.

"Maintan?" When you and Stefan generated RFC 6277 to try to address 
the alg agility problem for OCSP, that was maintenance. Changing OCSP 
to provide an indication of whether a cert was issued, for example, 
does not seem like maintenance.

>deployed to abandon OCSP in its favor.

I didn't suggest abandoning OCSP in favor of SCVP. OCSP provides an 
alternative (to CRLs) for checking the revocation status of a cert. 
If we have good reasons
to improve on that function, then doing so using OCSP makes sense.

If we're looking to address security problems related to cert revocation, and
which have become more serious due to browser trust model problems and due
to attacks on public CAs, that also may be appropriate for OCSP.

But, as I noted above and in my previous message, if the goal is to
keep the OCSP name because it is widely known, and to add new functions
that extend OCSP functionality and that overlap with SCVP functions, then
we have a problem.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 14 Mar 2012 16:55:19 -0400

>A bunch of Govt. Agencies in the U.S. Mostly enterprise deployments. 

Thanks for the reply.

The services provided by SCVP are such that public CAs were not 
viewed as good candidates to offer SCVP services. So it doesn't make 
much sense to focus on SCVP use in that context

Steve

---

From: Martin Rex <[email-masked]>
Date: Thu, 15 Mar 2012 04:20:18 +0100 (MET)

Stephen Kent wrote:
> 
> Phillip Hallam-Baker wrote:
> > 

I agree with PHB.

> that overlaps SCVP, that is not a reasonable course of action.

Just the opposite.

If someone is currently running an OCSP server, and wants new functionality,
upgrading to an OCSPv2 Server rather than having to setup a second server
looks pretty reasonable to me.

> to improve on that function, then doing so using OCSP makes sense.

Steve, I don't understand why you are so obsessed with keeping OCSP
locked up in a matchbox.  Limiting the initial scope&functionality to that
of rfc2560 in order to get an initial version of the protocol finished,
shipped and deployed in a reasonable timeframe is a good idea.

But insisting that a protocol never grows beyond the original scope
of version 1.0 does not seem reasonable to me at all.

Had the DNS folks exhibited such an attitude, then we would have to
use a different Transport&Protocol to convey authentication and security
for DNS records...

Or look at the incremental enhancements to the HTTP protocol.

> that extend OCSP functionality and that overlap with SCVP functions, then

That name confusion issue can be sufficiently addressed by tagging
a version to the end of OCSP, e.g. OCSPv2.

Since the extensibility in OCSP uses ASN.1 OID tags rather than
IETF assigned code points, extensions can easily be developed outside
of the IETF and PKIX and later published as informational, in case
that Steve intends to roadblock progress all by himself rather
than letting the WG decide.

-Martin

---

From: Tomas Gustavsson <[email-masked]>
Date: Thu, 15 Mar 2012 10:26:39 +0100

Makes much more sense to me now as well.

Cheers,
Tomas

On 03/14/2012 05:02 PM, Erwann Abalea wrote:
>
> 2012/3/14 Phillip Hallam-Baker <[email-masked] <mailto:[email-masked]>>
>
>     On Wed, Mar 14, 2012 at 9:20 AM, Erwann Abalea <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      >
>      > 2012/3/14 Phillip Hallam-Baker <[email-masked]
>     <mailto:[email-masked]>>
>     [...]
> But I read the thread again and noticed that your proposal doesn't need
> to impose pre-signing OCSP responses. A "negative gap" OCSP response can
> be generated and returned when asked for a non existent serial number.
>

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 15 Mar 2012 16:21:03 +0000

>certs, the percentage is likely to change and the risk probably ceases

What I think Peter is getting at is this is akin to a base rate bias
problem.  The probability of a fraudulent cert is significantly lower than
the probability of failure to validate from all other causes.  As a
result, adding "fraudulent" as a response code doesn't change the ability
of the relying party to distinguish signal from noise.

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 15 Mar 2012 16:29:31 +0000

However, it should be obvious that only CA-signed OCSP responses can even
pretend to offer a view into whether a cert exists, because only the CA
has the data available.  CA-designated and Trusted Responder would be a
real problem for any deployment, and there are nevertheless real risks
associated with the CA-signed model in practice.

Further, at high data rates I don't think this is going to be feasible
anyway; once the DB query response time climbs beyond a threshold the
whole system is going to quickly thrash to a halt.

Not that this matters in theory.  :)

-- T

---

From: Stephen Kent <[email-masked]>
Date: Thu, 15 Mar 2012 18:15:35 -0400

>looks pretty reasonable to me.

That's not at all clear. A new server can be a virtual instance on the same
machine, so there is no significant, implied hardware cost. Depending 
on the complexity of dealing with new options, changes to the state 
machines in the sever and in clients to KNOW when the other end 
supports the new options (in a secure fashion) as well as processing 
them, etc. One cannot reliably say whether the software cost is 
greater or less for use of a different protocol.

>shipped and deployed in a reasonable timeframe is a good idea.

Actually, the result was a bit messy, as our efforts to deal with alg 
agility have made clear.

>of version 1.0 does not seem reasonable to me at all.

Your statement is a vast over simplification of the issue. We have 
expanded the scope of OCSP since it's initial version.  The initial 
version did not
anticipate OCSP responders with pre-signed replies. That new 
capability was added, but the result, again, was not ideal.

I'd not like to see another attempt to expand OCSP functionality that 
yields a messy result, as a side effect of sticking with the base 
protocol. However, if we have a well-substantiated need, and a clean 
way to enhance OCSP that does not engender some of the problems we 
have seen in the past, and that does not overlap with SCVP, we can 
pursue it.  (Note that SCVP was not intended to support public CA 
services, so, depending on the stated scope of the problem we might 
address, the SCVP overlap may not be an issue.)

>use a different Transport&Protocol to convey authentication and security

First your analogy is seriously flawed. Second, we generally need to 
use TCP for DNSSEC record transport. Until DNSSEC, UDP was used 
almost exclusively for DNS record transport, so not such a good 
example :-).

>a version to the end of OCSP, e.g. OCSPv2.

I fear you missed my point here. In the discussion that led to SCVP, 
one of the arguments put forth in favor of extending OCSP was to 
capitalize on the name,
i.e., folks would think an extension of OCSP was intrinsically 
simpler than any new protocol. The WG rejected that approach. Using 
the name OCSPv2 is an example
of this sort of problem.

>than letting the WG decide.

Three observations:

	- the OIDs for OCSP are issued under an IETF/PKIX-controlled arc.

	- docs developed outside of the IETF and which are viewed as
	  attempts to circumvent the IETF process may be blocked from
           publication as RFCs, even via the independent submission track.

	- my reading of the list so far does not suggest that there is
	  widespread support for (an an yet undefined) set of OCSP extensions,
           which I am unilaterally blocking.

Steve

---

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

> that overlaps SCVP, that is not a reasonable course of action.

What course of action do you think will most quickly give us an off-the-shelf web browser that can most usefully verify it's connecting to the intended destination?  Someone complained the real problem was that browsers don't "fail hard" even when OCSP is turned on.  I see it as a chicken-and-egg problem where a browser shouldn't fail hard unless OCSP actually tells the browser what it needs to know.

I won't argue OCSP+ vs SCVP because I don't actually care.  I'm very surprised that the idea of adding a never-issued response to OCSP is so controversial however.  It appears to me that some people are reading more into it than was originally intended.

> "Maintan?" When you and Stefan generated RFC 6277 to try to address the alg agility problem for OCSP, that was maintenance. Changing OCSP to provide an indication of whether a cert was issued, for example, does not seem like maintenance.
> 
> I didn't suggest abandoning OCSP in favor of SCVP. OCSP provides an alternative (to CRLs) for checking the revocation status of a cert. If we have good reasons

I thought that was the original idea, yes.

> that extend OCSP functionality and that overlap with SCVP functions, then

I'll grant you that adding never-issued to OCSP starts a slippery slope in that direction, but see above.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 16 Mar 2012 08:55:39 -0400

> that overlaps SCVP, that is not a reasonable course of action.

OCSP is the Online Certificate Status Protocol. This is Certificate
Status. So if we accept your argument that there is overlap with SCVP,
the fault is with SCVP.

This is a minor incremental development of the protocol to address a
functionality that was originally intended.

> alternative (to CRLs) for checking the revocation status of a cert. If we
> have good reasons

You suggested that the existence of SCVP means we cannot add new
features to OCSP.

I said that I don't accept that as virtually nobody uses SCVP. So if
you want to push that idea I think it is time to move SCVP to HISTORIC
and slim down the stack a little.

> that extend OCSP functionality and that overlap with SCVP functions, then

The functionality is certificate status and SCVP is totally
irrelevant. SCVP does not address this subject area and no public CA
uses it.

OCSP has an extension mechanism. It should have been used to implement
SCVP in the first place.

---

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

Oh I agree that the issue Peter raised is a serious problem. It is the
type of free rider problem that plagues public immunization programs.
I don't need to have the vaccine myself provided that 99% of other
people have it.

The reason that revocation is in such a bad state is that mis-issued
certificates have not been a serious concern in the first decade and a
half of public CA operation.

I don't expect that application clients will be the early consumers of
this information. That is going to be mechanisms such as CertSentry
which Comodo is currently beta-testing.

---

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

It is clear that two servers means two queries for the same response.

This is a silly argument and I can't take your position as serious.Why
oh why do you imagine that SCVP has any place in this when you admit
that public CAs do not operate SCVP services?

On Thu, Mar 15, 2012 at 6:15 PM, Stephen Kent <[email-masked]> wrote:
>>>  >
>>>  > If there is going to be a choice between maintaining OCSP and
>>>  > maintaining SCVP then OCSP is going to be the one that I choose.
>>
>>
>> I agree with PHB.
>>
>>>
> machine, so there is no significant, implied hardware cost. Depending on the
> complexity of dealing with new options, changes to the state machines in the
> sever and in clients to KNOW when the other end supports the new options (in
> a secure fashion) as well as processing them, etc. One cannot reliably say
> whether the software cost is greater or less for use of a different
> protocol.
>
>> ...
>>
>>
>>
> Your statement is a vast over simplification of the issue. We have expanded
> the scope of OCSP since it's initial version.  The initial version did not
> anticipate OCSP responders with pre-signed replies. That new capability was
> added, but the result, again, was not ideal.
>
> I'd not like to see another attempt to expand OCSP functionality that yields
> a messy result, as a side effect of sticking with the base protocol.
> However, if we have a well-substantiated need, and a clean way to enhance
> OCSP that does not engender some of the problems we have seen in the past,
> and that does not overlap with SCVP, we can pursue it.  (Note that SCVP was
> not intended to support public CA services, so, depending on the stated
> scope of the problem we might address, the SCVP overlap may not be an
> issue.)
>
>
> First your analogy is seriously flawed. Second, we generally need to use TCP
> for DNSSEC record transport. Until DNSSEC, UDP was used almost exclusively
> for DNS record transport, so not such a good example :-).
>
>
>
>>  > If we're looking to address security problems related to cert
>> revocation, and
>>  > which have become more serious due to browser trust model problems and
>> due
>>  > to attacks on public CAs, that also may be appropriate for OCSP.
>>>
>>>
> I fear you missed my point here. In the discussion that led to SCVP, one of
> the arguments put forth in favor of extending OCSP was to capitalize on the
> name,
> i.e., folks would think an extension of OCSP was intrinsically simpler than
> any new protocol. The WG rejected that approach. Using the name OCSPv2 is an
> example
> of this sort of problem.
>
>

---

From: Carl Wallace <[email-masked]>
Date: Fri, 16 Mar 2012 09:11:32 -0400

On 3/16/12 8:55 AM, "Phillip Hallam-Baker" <[email-masked]> wrote:
><snip>

Part of the reason SCVP has not been adopted is lack of client side
support.  Changing the OCSP spec is not going to improve the integration
options for providing more than revocation status on the client side.

---

From: Piyush Jain <[email-masked]>
Date: Fri, 16 Mar 2012 08:58:17 -0700

> Date: Fri, 16 Mar 2012 09:11:32 -0400
> From: [email-masked]
> To: [email-masked]; [email-masked]
> CC: [email-masked]
Completely agree with this observation. BTW, it took good 5-8 years for the major browser vendors to add OCSP client support in their products after OCSP became an RFC. SCVP has just started gaining momentum and the adoption is likely to increase in next few years.

---

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

Again, a reason to drop SCVP and concentrate on a single protocol.

Lets do this systematically:

1) Is the proposal related to certificate status or to cert path validation?

A: The feature is directly related to certificate status, stating that
the certificate serial number was never issued.

Since OCSP is the certificate status protocol, OCSP is the right
protocol for implementation

2) Would the service be implemented by a CA or a third party?

A: This feature can only be implemented by a CA.

Since SCVP is not implemented by CAs and intended to serve as a
protocol to support delegated processing of relying party path math it
makes no sense to attempt to use SCVP. Only OCSP is suitable.

3) Which protocol is most widely used?

A. OCSP by a very long way

4) Which protocol are the proposers of the feature interested in using?

A. OCSP

Deployment of SCVP is not my problem. If people think that there is a
market for that capability then fine. But as things stand we have a
group that is very vocal in telling us that they don't want the
feature but they are nevertheless determined that it be part of the
protocol nobody who is interested in the feature wants to use.

I really cannot understand the strategy here unless the objective is
to make me really upset in the hope that I will say something that
will then be used as a pretext for ignoring my proposal.

---

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

Suppose we accept both your arguments below, and Stephen Kent's arguments that SCVP is the right solution for the real problem faced by ordinary users.

I can imagine a solution being that the browser venders make cert validation an extra-cost service they provide to random consumers.  Enterprise deployments might configure their browsers to use use the enterprise SCVP.

If someone can convince me that this approach will "take", I'd be all for it.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 16 Mar 2012 15:43:53 -0400

Oh is that what he is worrying about?

There is definitely a case for some form of delegated trust processing
from the client. But that does nothing to change the need for giving
the CA the ability to transmit the right info.

Lets look at this in a four corner model:

Relying Party     ---------------------------------   Server
          |                                                                |
          |                                                                |
Trust Broker      ---------------------------------   Certificate Authority

SSL/PKIX is a mess because the design of OCSP means that the Relying
Party has to 'cross the center' and get certificate status from the CA
direct.

The way the protocol should run is that the communications should run
round the edges. The OCSP token should be stapled into SSL just like
the certificate is.

But one of the reasons I started looking at this issue is that if you
take the view that the RP should be channeling their trust decisions
through a broker, that pretty clearly means that the CA needs the
ability to communicate all the necessary info to the trust broker -
including non existence.

I see SCVP as one option for a trust broker protocol. I don't think it
is a good option but that is where it sits. The non existence proposal
is to allow the CA to publish information. OCSP is a CA protocol.

Now we can have a separate conversation as to what features should be
supported in a trust broker protocol and if SCVP or XKMS or something
completely new would be the best choice. Any new development in that
area is going to have to support DANE, Convergence and CT type
approaches and probably DNSSEC as well.

If the real concern here is to get people to use a trust broker
protocol, then we are all in agreement as to objectives. If people
want to insist on it being SCVP then I think they need to ask
themselves if this is something that really matters to them or
something that they prefer or imagine will make deployment easier.

---

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

> Oh is that what he is worrying about?

Well, it's what *I*'m worried about.  Stephen can speak for himself.  I don't think the practical validation problem is unique to web/TLS though.

---

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

Me too, I just can't see how recent events are going to get engineers
excited about implementing a 10 year old protocol that is pretty
tightly bound to PKIX and a rather specific view of PKIX at that.

If we are going to get a trust broker protocol deployed we are going
to have to meet the Google criteria that it improve, not harm response
time. So the only deployable approach I can see is to combine the
trust resolution request with the name resolution request.

Knowing more about the validity of the certificate seems rather
superfluous to me when I have no authoritative or reliable means of
knowing if the connection should use SSL (other than cached previous
interactions).

---

From: Carl Wallace <[email-masked]>
Date: Fri, 16 Mar 2012 18:57:14 -0400

You have been suggesting that a delegated path processing protocol be
tossed aside, have been pointing out that OCSP should have been used for
delegated path processing in the first place and have been implying that
the broad support for OCSP for one purpose means it is well suited for
another purpose.  This has been in service of some proposal about how to
deal with certificates that pass basic validation but were not issued
intentionally by a CA, presumably due to compromise.  Which protocol is
more widely used, who implements the proposal, whether the proposal is
related to the 's' word or not and what the proposers want to do is all
irrelevant to my point, which was that current OCSP clients are used in a
way that make them poor integration points for a delegated path validation
client.  My comment was not part of some strategy to make you upset in
hope you will say something that will then be used as a pretext for
ignoring your proposal.

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 17 Mar 2012 00:31:39 +0100

Phil,

Giving this some thought my problem is that this proposal feels like a
good thing.
This is a piece of information known to most OCSP responders, but no way
to express it, why not add that feature?

But the deeper you go into examining what the real benefits actually would
be, it gets harder and harder to see those benefits.

We seem to have build the foundation of PKI on the assumption that
everything that is signed by a CA, is a valid statement of that CA. And if
the key of the CA, or the CA itself, is compromised, then all bets are off.

This proposal seems to propose that all bets are not off. That there are
ways to prevent a successful exploit of a compromised CA if we add a
"never issued" response.

I'm in doubt.

/Stefan 

On 12-03-16 9:28 PM, "Phillip Hallam-Baker" <[email-masked]> wrote:

>> Well, it's what *I*'m worried about.  Stephen can speak for himself.  I
>>don't think the practical validation problem is unique to web/TLS though.

---

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

> ways to prevent a successful exploit of a compromised CA if we add a

You have data points (DigiNotar & Comodo).  Phil does not.  :)

Just sayin'.

-- T

---

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

At 12:44 AM -0700 3/16/12, Henry B. Hotz wrote:
>What course of action do you think will most quickly give us an 
>off-the-shelf web browser that can most usefully verify it's 
>connecting to the intended destination?  Someone complained the real 
>problem was that browsers don't "fail hard" even when OCSP is turned 
>on.  I see it as a chicken-and-egg problem where a browser shouldn't 
>fail hard unless OCSP actually tells the browser what it needs to 
>know.

Henry,

Your statement focuses on a broad topic, one that seems to be beyond what PHB
suggested when he started this thread. For that broad topic, look at what the
DANE WG is doing.

>I won't argue OCSP+ vs SCVP because I don't actually care.  I'm very 
>surprised that the idea of adding a never-issued response to OCSP is 
>so controversial however.  It appears to me that some people are 
>reading more into it than was originally intended.

A change to OCSP to solve a problem needs to be justified by a 
well-written statement of the problem to be solved, and an argument 
about why the proposed solution is the nest way to solve the problem. 
Both of those are missing here.

>I thought that was the original idea, yes.

Several (other) folks have argued that the suggested change does not do a great
job of addressing this bigger problem, relative to the costs it imposes, and
others have noted that we lack a clear description of the problem.

>slope in that direction, but see above.

Well, at least we agree on this point :-).

Steve

---

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

At 12:01 PM -0700 3/16/12, Henry B. Hotz wrote:
>Suppose we accept both your arguments below, and Stephen Kent's 
>arguments that SCVP is the right solution for the real problem faced 
>by ordinary users.

Steve Kent didn't say that. He said that PKIX decided to develop SCVP 
instead of extending OCSP, when we lasted visited this sort of topic. 
In  later messages I noted that folks did not except public CAs to 
operate SCVP servers; SCVP is best suited for enterprise environments.

Steve

---

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

On Mar 19, 2012, at 8:42 AM, Stephen Kent wrote:

> Steve Kent didn't say that.

OK, OK.  I admit I'm stretching a point to try to find common ground.

I'm kind of disappointed by how acrimonious the discussions of this feature (and on this list in general) have been.  I'm guessing that is why we haven't heard from Tom Gundin, the guy who started this thread, in a while.

> He said that PKIX decided to develop SCVP instead of extending OCSP, when we lasted visited this sort of topic. In  later messages I noted that folks did not except public CAs to operate SCVP servers; SCVP is best suited for enterprise environments.
> 
> Steve

---

From: Tom Gindin <[email-masked]>
Date: Tue, 20 Mar 2012 08:24:42 -0400

Actually, my lack of participation was more physical exhaustion 
than a result of the emotional temperature of the discussions.  There are 
probably others who are more bothered than me by that level, and if I 
typically sent out my initial draft responses I would probably contribute 
to the problem.  Given my limited practical experience with OCSP, I'm 
going to make some naive comments below, after starting with a statement 
of what I at least think needs to be resolved.
        One outstanding problem is that a client often cannot distinguish 
"good" from merely "unrevoked", or even be aware that the responder is not 
making such a distinction.  The other is for a client to provide evidence 
that a certificate is in circulation which is not expected to be by the 
responder.  My other suggestion below about using the issuer's SIA for 
id-ad-ocsp is unrelated to these, and is intended to reduce the chances of 
an attacker diverting the revocation check to a server under his own 
controls. 
        I do wonder what the point is to having OCSP support an "unknown" 
status code if it's appropriate for a responder to return "good" on a 
serial number that was never issued.  The natural meaning of the words 
would suggest to me that a CRL-only OCSP responder should call its two 
status values "revoked" and "unknown" rather than "revoked" and "good". 
One could probably argue that never using "good" is consistent with the 
literal wording of RFC 2560 section 2.2, but it certainly isn't the common 
practice.  Thus I consider that the current "good" status would mean more 
to high-reliance RP's if it were accompanied by an extension telling the 
client whether "good" includes "unknown" or not.  That's not exactly 
Denis' position, but it's close to it.
        Next, I am surprised that the reporting extension in which a 
client can provide evidence of a certificate's actual existence has drawn 
little comment.  I would think that, in conjunction with either "unknown" 
or "neverIssued", that extension allows a client to report a possible 
issuer breach inside the protocol.  In particular, I think that it answers 
Dave Cooper's objection of Friday, because a major point to this set of 
proposed changes is to permit a client to test his suspicion of a 
compromise.  It's perfectly true that a client who's inside a DNS 
masquerade environment will gain little from unsigned OCSP responses of 
any type.  While using an OCSP URL with an IP address would avoid the DNS 
masquerade, no attacker's subject certificate will create such a value 
(although RA compromises would probably not change the AIA extension in 
most CA's).
        Last, 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.  I realize that this provides greater 
flexibility for an issuer to change its practices over time, but letting 
an attacker redirect OCSP URL's is a bad thing (and Santosh is right that 
it's far too easy, although not about Phill's analytic skills).  CRLDP 
partitioning is a reason for that revocation mechanism to be in the 
subject certificate rather than the issuer one, but why should that 
precedent govern OCSP?  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.

Tom Gindin

From:   "Henry B. Hotz" <[email-masked]>
To:     Stephen Kent <[email-masked]>, 
Cc:     pkix <[email-masked]>
Date:   03/19/2012 04:26 PM
Subject:        Re: [pkix] Possible OCSP Extensions
Sent by:        [email-masked]

>> Suppose we accept both your arguments below, and Stephen Kent's 
arguments that SCVP is the right solution for the real problem faced by 
ordinary users.

I'm kind of disappointed by how acrimonious the discussions of this 
feature (and on this list in general) have been.  I'm guessing that is why 
we haven't heard from Tom Gundin, the guy who started this thread, in a 
while.

> He said that PKIX decided to develop SCVP instead of extending OCSP, 
when we lasted visited this sort of topic. In  later messages I noted that 
folks did not except public CAs to operate SCVP servers; SCVP is best 
suited for enterprise environments.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 20 Mar 2012 13:39:33 +0000

So would this be a fair summary of the range of possible responses?

1) A Responder with no access to the CA history has only two possible responses:

	REVOKED - Certificate identified by the Request is on a CRL.
	UNKNOWN - All other queries.

2) A Responder with access to the CA history, if and only if certificate evidence is provided in the Request, may also respond:

	GOOD - An exact match for the certificate in the Request is found in the CA history, and that certificate is not on a CRL.

3) A Responder with access to the CA history, if and only if certificate *and chain* evidence is provided in the Request, may also respond:

	NOTISSUED - The certificate in the Request chains to the cognizant CA but no exact match for the certificate is found in the CA history.

"Certificate evidence" must be a sufficiently unique CertID.  I'd want a cert thumbprint at the least; a copy of the cert itself at most.  If the Responder is operating as a Trusted Responder, the relying party won't be able to detect name collisions if only Issuer/Serial is used.  CA-signed and CA-Designated can detect name collisions because the queried cert won't chain to the same trust anchor as the OCSP Response signature, but they have to be specifically directed to make this check.

"Certificate and chain evidence" will probably have to be the certificate itself, though if anyone has alternative ideas I'm all ears.  IMHO this is required for NOTISSUED because it's the only way to prevent a malicious querent from messing up your day with falsified certificate evidence.  A query that doesn't match anything in the CA history is *not* enough evidence of compromise unless it can be shown to be a cert that actually chains to the cognizant CA.

I think the above is close to full coverage, but it's also a complete overhaul of OCSP.  I'd call it a new protocol, though I don't know enough about SCVP to say whether or not this functions can be replicated with that protocol.

-- T

---

From: brennan security <[email-masked]>
Date: Tue, 20 Mar 2012 10:58:28 -0400

Tim,

There is some ambiguity in the flow-down results of what we are discussing.

Current CRLs content is serial based, rather than actual certificate or digest.

If we are going to fix OCSP, it may mean a requirement to update CRLs
also, as CRLs are often used as an information source for OCSP
production.

-b

---

From: Piyush Jain <[email-masked]>
Date: Tue, 20 Mar 2012 08:01:17 -0700

> From: [email-masked]
> To: [email-masked]
> Date: Tue, 20 Mar 2012 13:39:33 +0000
> CC: [email-masked]
> Thanks for the comprehensive coverage Tim. i don't think that you missed anything Here are additional implications of blessing this concept in any protocol- CRLs and signature checking won't be enough to accept a certificate. RFC 5280 would need to be changed- CAs would be required to publish a white list (for RPs who do not do OCSP or this new protocol) and  CRLs would become useless.  This probably requires change in X.509.- Since the primary reason for deploying OCSP is the pain associated with downloading and processing big CRLs, adoption of OCSP (or the new protocol) would increase even more because now we would have even bigger white lists.- While we are at it, we can also recommend getting rid of signatures from x.509 certificates because they won't be needed anymore. RPs just send the certificate without signature(or its hash) to the CA, or look up the white list and figure out if it was really blessed by the CA.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 20 Mar 2012 15:47:04 +0000

Brennan's reply got me thinking, and I think this is a better way of attacking the issue from the ground up:

We assume:

-- The Responder MUST have a copy of the certificate.
-- The Responder MUST have access to the CA history.

There are three binary states of interest:

-- Cert was signed (or not) by the cognizant CA (S, or notS)
-- Cert was recorded (or not) by the cognizant CA (H, or notH) (H for history)
-- Cert was revoked (or not) by the cognizant CA (R, or notR)

This yields 8 distinct cases (2^3).  I can reduce this to four response cases like so:

-- Any case of (notS) is always a response of UNKNOWN.  
-- Any case of (S && notH) is NOTISSUED.  
-- (S && H && R) is REVOKED.
-- (S && H && notR) is GOOD. 

Thus, UNKNOWN means "not signed by the cognizant CA," NOTISSUED means "signed but not recorded by the cognizant CA, may be fraudulent," and GOOD means "signed, recorded and not revoked by the cognizant CA."  REVOKED means what it always meant, but is now stronger because name collisions are eliminated.  

Implementations should be guided to treat both REVOKED and NOTISSUED as a hard failure, and to seek additional sources for UNKNOWNs.

Working backward from the above definition to the current OCSP:

If the Responder does not have access to the CA history, then GOOD and NOTISSUED cannot be sent as a response to a query.  Therefore the meaning of UNKNOWN changes to mean "not issued or not recorded by the cognizant CA".  The Responder MUST signal this state to the client, and the client implementation MUST be cautioned not to treat this response as a hard failure.

If the Responder does not have access to the query certificate, then the Responder MUST assume that the S is true, but this means that UNKNOWN now means "not revoked by the cognizant CA".  The Responder MUST signal this state to the client, and implementations MUST be cautioned not to treat this response as a hard failure.

-- T

On Mar 20, 2012, at 10:01 AM, Piyush Jain wrote:

> Thanks for the comprehensive coverage Tim. i don't think that you missed anything
>  
> Here are additional implications of blessing this concept in any protocol
> - CRLs and signature checking won't be enough to accept a certificate. RFC 5280 would need to be changed
> - CAs would be required to publish a white list (for RPs who do not do OCSP or this new protocol) and  CRLs would become useless.  This probably requires change in X.509.
> - Since the primary reason for deploying OCSP is the pain associated with downloading and processing big CRLs, adoption of OCSP (or the new protocol) would increase even more because now we would have even bigger white lists.
> - While we are at it, we can also recommend getting rid of signatures from x.509 certificates because they won't be needed anymore. RPs just send the certificate without signature(or its hash) to the CA, or look up the white list and figure out if it was really blessed by the CA.
>

---

From: brennan security <[email-masked]>
Date: Tue, 20 Mar 2012 12:10:32 -0400

Some questions

Actual certificates on the responder, or just an information source
(certificate, digest, other) ?

CA history, or just an information source for good & bad  (certificate,
digest, other) ?

Have you considered how resilient this is in the advent of CA/HSM
compromise?

How would this work in Direct Trust, CA designated and VA delegated trust
relationships?

Are you saying that NOTISSUED would trigger a security alarm?

-b

On Tue, Mar 20, 2012 at 11:47 AM, Miller, Timothy J. <[email-masked]>
wrote:
> Thus, UNKNOWN means "not signed by the cognizant CA," NOTISSUED means
"signed but not recorded by the cognizant CA, may be fraudulent," and GOOD
means "signed, recorded and not revoked by the cognizant CA."  REVOKED
means what it always meant, but is now stronger because name collisions are
eliminated.
>
> Implementations should be guided to treat both REVOKED and NOTISSUED as a
hard failure, and to seek additional sources for UNKNOWNs.
> If the Responder does not have access to the CA history, then GOOD and
NOTISSUED cannot be sent as a response to a query.  Therefore the meaning
of UNKNOWN changes to mean "not issued or not recorded by the cognizant
CA".  The Responder MUST signal this state to the client, and the client
implementation MUST be cautioned not to treat this response as a hard
failure.
>
> If the Responder does not have access to the query certificate, then the
Responder MUST assume that the S is true, but this means that UNKNOWN now
means "not revoked by the cognizant CA".  The Responder MUST signal this
state to the client, and implementations MUST be cautioned not to treat
this response as a hard failure.
>> > 2) A Responder with access to the CA history, if and only if
certificate evidence is provided in the Request, may also respond:
>> >
>> > GOOD - An exact match for the certificate in the Request is found in
the CA history, and that certificate is not on a CRL.
>> >
>> > 3) A Responder with access to the CA history, if and only if
certificate *and chain* evidence is provided in the Request, may also
respond:
>> >
>> > NOTISSUED - The certificate in the Request chains to the cognizant CA
but no exact match for the certificate is found in the CA history.
>> >
>> > "Certificate evidence" must be a sufficiently unique CertID. I'd want
a cert thumbprint at the least; a copy of the cert itself at most. If the
Responder is operating as a Trusted Responder, the relying party won't be
able to detect name collisions if only Issuer/Serial is used. CA-signed and
CA-Designated can detect name collisions because the queried cert won't
chain to the same trust anchor as the OCSP Response signature, but they
have to be specifically directed to make this check.
>> >
>> > "Certificate and chain evidence" will probably have to be the
certificate itself, though if anyone has alternative ideas I'm all ears.
IMHO this is required for NOTISSUED because it's the only way to prevent a
malicious querent from messing up your day with falsified certificate
evidence. A query that doesn't match anything in the CA history is *not*
enough evidence of compromise unless it can be shown to be a cert that
actually chains to the cognizant CA.
>> - CAs would be required to publish a white list (for RPs who do not do
OCSP or this new protocol) and  CRLs would become useless.  This probably
requires change in X.509.
>> - Since the primary reason for deploying OCSP is the pain associated
with downloading and processing big CRLs, adoption of OCSP (or the new
protocol) would increase even more because now we would have even bigger
white lists.
>> - While we are at it, we can also recommend getting rid of signatures
from x.509 certificates because they won't be needed anymore. RPs just send
the certificate without signature(or its hash) to the CA, or look up the
white list and figure out if it was really blessed by the CA.
>>
>> > I think the above is close to full coverage, but it's also a complete
overhaul of OCSP. I'd call it a new protocol, though I don't know enough
about SCVP to say whether or not this functions can be replicated with that
protocol.
>> > > arguments that SCVP is the right solution for the real problem faced
by

---

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

On Mar 20, 2012, at 11:10 AM, brennan security wrote:

> Actual certificates on the responder, or just an information source (certificate, digest, other) ?

I think it needs to be actual certificates in the request to work in the complete case.  Less than the full cert means the Responder can't eliminate namespace collisions, or can't guarantee the cert belongs to the cognizant CA.  E.g., if client is asking the Responder for CA A about a cert from CA B; given only the hash, the Responder can't tell the cert was issued by B.  NOTISSUED would not be a proper response because the Responder can't actually make the decision; only UNKNOWN is appropriate here.
  
The reduced cases with changed response code semantics cover the case where the client doesn't provide the cert.

> CA history, or just an information source for good & bad  (certificate, digest, other) ?

Irrelevant.  If a CA Designated Responder has direct access to the CA database or simply a query mechanism doesn't matter to the client.  "CA" in this case should be taken to mean the complete trusted infrastructure that composes the CA and it's constituent services and personnel, not the just the box that creates signatures.  :)

> Have you considered how resilient this is in the advent of CA/HSM compromise?

I'm working on the fly here, so don't take my work so far as a fully worked proposal.   But given what Philip has been asking for this is the only way I see to deliver even a portion of what he wants.  

That said, if the CA is compromised such that the *history* is invalid, NOTISSUED loses all meaning.  Similarly, compromise of the CA signing key means GOOD and REVOKED lose all meaning.   Compromise of the Responder signing key means *all* responses lose their meaning, but you'd never know it.  :)

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.

> How would this work in Direct Trust, CA designated and VA delegated trust relationships?

I think OCSP trust model is orthogonal to the concept I give, if my assumptions are preserved.  

> Are you saying that NOTISSUED would trigger a security alarm?

In the corner case above, yes.

I'm personally not convinced this would happen in practice.

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 20 Mar 2012 16:44:50 +0000

> Actual certificates on the responder, or just an information source (certificate, digest, other) ?

To reflection, the current 2560 CertID is not enough to determine whether the cert was recorded or not.  Recall:

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

In the case where a fraudulent certificate is issued under an valid certificate serial number, this CertID would result in an incorrect match, and GOOD would be sent as the response.   In contrast, if we have the subject key--or a more specific subject key identifier--then the cert would *not* match, and NOTISSUED would result.

Adding

		subjectKeyHash OCTET STRING, -- Hash of Subject public key

to CertID would probably suffice.  

So I'll retract the "I want to see the whole cert" part.  Chalk it up to excessive paranoia.  My gut feels better if the OCSP service actually validates the certificate signature, but if we assume a halfway competent client this is redundant (and if the client is less than halfway competent, the OCSP response probably doesn't matter anyway :).

-- T

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 20 Mar 2012 12:51:40 -0400

If you are talking about certificates, it is always better to have a certificate hash as opposed to public key hash.

This comment should not be construed to mean my support for any of this.  I continue to be skeptical of the need for not issued in general and of ranges when serial numbers are random or pseudo random.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Miller, Timothy J.
Sent: Tuesday, March 20, 2012 12:45 PM
To: brennan security
Cc: <[email-masked]>
Subject: Re: [pkix] Possible OCSP Extensions

	CertID          ::=     SEQUENCE {

Adding

-- T

---

From: brennan security <[email-masked]>
Date: Tue, 20 Mar 2012 12:56:32 -0400

Tim,

I'm not sure I concur on the actual certificate and I think it is a good
subject for more analysis.  For example
http://tools.ietf.org/html/rfc5914might be a candidate and I am sure
our team can come up with a
comprehensive list of alternatives with respective pros and cons.  For
mobile RPs, this may be significant.

CA delegated modes of VA are compromised with a CA compromised; CA
Designated, VA delegated and direct trust are resistant to CA compromises,
namely, they can revoke CA trust. (Preventing a CA from being a single
point of failure, but adding complexity).

-b

On Tue, Mar 20, 2012 at 12:31 PM, Miller, Timothy J. <[email-masked]>wrote:

> I think it needs to be actual certificates in the request to work in the
> complete case.  Less than the full cert means the Responder can't eliminate
> namespace collisions, or can't guarantee the cert belongs to the cognizant
> CA.  E.g., if client is asking the Responder for CA A about a cert from CA
> B; given only the hash, the Responder can't tell the cert was issued by B.
>  NOTISSUED would not be a proper response because the Responder can't
> actually make the decision; only UNKNOWN is appropriate here.
>
> The reduced cases with changed response code semantics cover the case
> where the client doesn't provide the cert.
>
> Irrelevant.  If a CA Designated Responder has direct access to the CA
> database or simply a query mechanism doesn't matter to the client.  "CA" in
> this case should be taken to mean the complete trusted infrastructure that
> composes the CA and it's constituent services and personnel, not the just
> the box that creates signatures.  :)
>
> I'm working on the fly here, so don't take my work so far as a fully
> worked proposal.   But given what Philip has been asking for this is the
> only way I see to deliver even a portion of what he wants.
>
> That said, if the CA is compromised such that the *history* is invalid,
> NOTISSUED loses all meaning.  Similarly, compromise of the CA signing key
> means GOOD and REVOKED lose all meaning.   Compromise of the Responder
> signing key means *all* responses lose their meaning, but you'd never know
> it.  :)
>
> 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.
>

---

From: Piyush Jain <[email-masked]>
Date: Tue, 20 Mar 2012 10:00:46 -0700

> From: [email-masked]
> To: [email-masked]; [email-masked]
> Date: Tue, 20 Mar 2012 12:51:40 -0400
> CC: [email-masked]
> If you are talking about certificates, it is always better to have a certificate hash as opposed to public key hash.> > This comment should not be construed to mean my support for any of this.  I continue to be skeptical of the need for not issued in general and of ranges when serial numbers are random or pseudo random.
I'm in  agreement with your stand on not issued.However, I would appreciate your opinions on the options available to a  responder for presigning for CAs that use random or pseudo random serials, and your thoughts on why ranges won't solve this problem.

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 20 Mar 2012 13:04:55 -0400

Piyush,

You never responded to my e-mail addressing this issue and asking some questions yesterday.

That e-mail is attached assuming list serve does not strip it off.  If it is stripped off, go back to your or PKIX archives to look at it.

From: Piyush Jain [mailto:[email-masked]]
Sent: Tuesday, March 20, 2012 1:01 PM
To: Santosh Chokhani; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [pkix] Possible OCSP Extensions

> From: [email-masked]<mailto:[email-masked]>
> To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> CC: [email-masked]<mailto:[email-masked]>

I'm in  agreement with your stand on not issued.
However, I would appreciate your opinions on the options available to a  responder for presigning for CAs that use random or pseudo random serials, and your thoughts on why ranges won't solve this problem.

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Miller, Timothy J.
> Cc: <[email-masked]<mailto:[email-masked]>>
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

Subject: Re: [pkix] Range responses in OCSP
From: Santosh Chokhani <[email-masked]>
To: Piyush Jain <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 19 Mar 2012 11:06:17 -0400
List-Id: PKIX Working Group <pkix.ietf.org>

Piyush,

If the serial numbers truly random, how would you do this without declaring unissued certificates as valid?

I suspect you are saying that if the CA is compromised, all of this does not matter and if the CA is not compromised, declaring unissued as legitimate hurts nothing.

Is this what you are saying.  If so, this is yet another reason not to include never issued.

BTW, the most folks deal with pre-signing today by having multiple responses in a pre-signed bundle.  The bundle is generally configurable and I have seen bundle size as high as 20, reducing the signing workload by a factor of 20.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Piyush Jain
Sent: Monday, March 19, 2012 10:53 AM
To: [email-masked]; [email-masked]
Subject: Re: [pkix] Range responses in OCSP

On the contrary, it'll address the objections to move to non sequential numbers.

There are installations today that are using the unadvertised feature in Microsoft CA to generate sequential serial numbers, just because the current OCSP spec makes pre-signing for certificates with random serial numbers impossible.

-Piyush
________________________________
Date: Mon, 19 Mar 2012 11:35:14 +0100
Subject: Re: [pkix] Range responses in OCSP
From: [email-masked]<mailto:[email-masked]>
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
My fear is that this will glue CAs to sequential serial numbers and prevent them from moving to non sequential serial numbers when needed.

/Stefan

From: Piyush Jain <[email-masked]<mailto:[email-masked]>>
Date: Sun, 18 Mar 2012 20:57:26 -0700
To: Stefan Santesson <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Subject: Re: [pkix] Range responses in OCSP

I think the proposal to have OCSP support range responses should be discussed separately from the proposal to add "does not exist" response.

Range response is just an optimal way of packing a large number of single responses in one OCSP response.

This is how pre-signing of OCSP is done today.
One (or more) more keyed responders create a list of OCSP responses which is then mirrored to multiple keyless responders. Relying parties use these keyless responders to check the status of certificates. One OCSP response is usually packed with status of muliple certificates to minimize the number of signings. However, the trade off is that the OCSP response gets bloated.

Problem:
1) The current representation of OCSP response is inefficient. Let's say that the range of issued certificates by a CA is 'M' and the number of revoked certificates in the CRL is 'N'. We know that typically M is much bigger than N. Using the current OCSP response representation , you need to create M  responses to account for every serial number that the CA issued. Using ranges you could
achieve the same thing using at most 2*N + 1 responses ( Think of it as an efficient representation of a sparse array).

2)For CAs that issue certificates using random serial numbers, M is so big that it becomes computationally  impossible to pre-sign responses for those CAs unless the responder has access to the CA database.

Range response will facilitate pre-signing of OCSP responses for CAs that issue certificates with non sequential serial numbers and reduce the computation and bandwidth requirements even for CAs who issue certificates with sequential serial numbers.

-Piyush

> Date: Sun, 18 Mar 2012 23:48:52 +0100
> From: [email-masked]<mailto:[email-masked]>
> To: [email-masked]<mailto:[email-masked]>
> Subject: Re: [pkix] Range responses in OCSP
>
> Trying to return to the actual question I would like to take up in
> Santosh's question.
>
> What problem is this trying to solve?
>
> Why would it not be enough to just craft one standard response saying "I
> have no record of the certificate you are asking for"?
> Yes, it would not be a signed proof that this is not a replay sent by Eve
> in order to fool you to reject a perfectly valid cert.
>
> But it would be an indication that something is fishy here and should be
> investigated.
>
> Either you have a MitM swapping the OCSP responses, or you have a bad OCSP
> responder, or you have a compromised CA.
> Time to push the alarm and figure out what's wrong.
>
> What more would you get from prefabricating all these OCSP range responses?
>
> /Stefan
>
>
> [email-masked]<mailto:[email-masked]>
_______________________________________________ pkix mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/pkix

---

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

> This comment should not be construed to mean my support for any of this.  I continue to be skeptical of the need for not issued in general and of ranges when serial numbers are random or pseudo ran…

I'm also skeptical about whether the extension is worth it, I'm just trying to figure out the cases and requirements necessary to make it work at all.  Based on what I've laid out, I've only reinforced my opinion that NOTISSUED is meaningful only in narrow circumstances that won't occur in the wild.  

I've also come to think that GOOD should be struck from the list of possible responses unless qualified by an extension (mandatory for GOOD responses) that tells the client that the CA history was checked for a match.  As currently written, allowing GOOD without qualifier leads to incorrect interpretation of the protocol.  I.e., for most OCSP Responders only REVOKED or UNKNOWN should be sent.  

Response ranges is a separate thread, I thought.  

-- T

---

From: Carl Wallace <[email-masked]>
Date: Tue, 20 Mar 2012 15:18:18 -0400

On 3/20/12 2:58 PM, "Miller, Timothy J." <[email-masked]> wrote:

>> This comment should not be construed to mean my support for any of
>>this.  I continue to be skeptical of the need for not issued in general
>>and of ranges when serial numbers are random or pseudo random.
>
>I'm also skeptical about whether the extension is worth it, I'm just
>trying to figure out the cases and requirements necessary to make it work
>at all.  Based on what I've laid out, I've only reinforced my opinion
>that NOTISSUED is meaningful only in narrow circumstances that won't
>occur in the wild.
>
>I've also come to think that GOOD should be struck from the list of
>possible responses unless qualified by an extension (mandatory for GOOD
>responses) that tells the client that the CA history was checked for a
>match.  As currently written, allowing GOOD without qualifier leads to
>incorrect interpretation of the protocol.  I.e., for most OCSP Responders
>only REVOKED or UNKNOWN should be sent.

As currently written where?  RFC2560 states the following:

   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. Response extensions
   may be used to convey additional information on assertions made by
   the responder regarding the status of the certificate such as
   positive statement about issuance, validity, etc.

Adding an extension to return proof of existence would be easy enough and
would not break backwards compatibility.  Adding additional status values
or changing the meaning of existing status values would.  Clients that
want to fail without the extra proof could do so.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 20 Mar 2012 19:59:48 +0000

On Mar 20, 2012, at 2:18 PM, Carl Wallace wrote:

> As currently written where?  

The response code says it's "good" and *everyone* knows what that means, right? 

The sarcasm should be obvious.  

The clarifying text even calls out the problem with this response code!  

Here's a rule of thumb:  Any specification that includes the phrase "…does not necessarily mean…" should immediately be rewritten.  :)

> want to fail without the extra proof could do so.

IMHO, OCSP only needs two response codes:  REVOKED and OTHER, where OTHER means the cert does *not* match records on the CRL.  This doesn't mean the cert is good, bad, or someone else's, it just means the revocation status could not be determined.  REVOKED should induce a hard failure, and OTHER should not.  Three codes *in the base case* introduced ambiguity because the only additional information the third code (GOOD) tells you is "the cert *appears to be* one of mine," and "appears to be" isn't actually conveying any actual information. [1]

-- T
[1] If you want more than this, OTHER could be qualified by extensions; e.g., NOTMINE (certificate wasn't issued by the cognizant CA), BOGUS (certificate appears to belong to the cognizant CA but doesn't match the cognizant CA's list of things that should exist), or EXCELLENT (certificate does match the cognizant CA's list of things that should exist).

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 20 Mar 2012 16:09:14 -0400

Why not just go with the terms CRL and not on CRL since CRL is the primary source.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Miller, Timothy J.
Sent: Tuesday, March 20, 2012 4:00 PM
To: Carl Wallace
Cc: <[email-masked]>
Subject: Re: [pkix] Possible OCSP Extensions

Here's a rule of thumb:  Any specification that includes the phrase "...does not necessarily mean..." should immediately be rewritten.  :)

> Adding an extension to return proof of existence would be easy enough 
> and would not break backwards compatibility.  Adding additional status 
> values or changing the meaning of existing status values would.  
> Clients that want to fail without the extra proof could do so.

-- T

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 20 Mar 2012 16:33:04 -0400

The word GOOD directly contradicts the RFC 2560 paragraph describing it.
A certificate that was never issued or is outside its validity period
cannot, under any reasonable English language interpretation, be
considered "good".   Whereas UNKNOWN is a reasonable word to use for a
certificate that may or may not exist, but is definitely not revoked.
Modifying OCSP responders to never send a deprecated GOOD response does
not change the meaning of that response.  And unless the default client
behavior is to fail on UNKNOWN, changing responders to use it for all
non-revoked certificates does not affect client behavior.

Excellent point regarding proof of existence.  There is no need to
change the OCSP request in any way.  The extension can be sent at the
discretion of the responder, the client can validate the proof since it
already has a copy of the certificate being checked, and the client can
follow its own policy for handling responses without the extension or
responses with proofs that don't match the certificate.  That is
backwards compatibility at its best, and although I'm skeptical of using
OCSP to address PHB's NOT-ISSUED requirement, the proof-of-issuance
extension seems quite straightforward.

Dave

-----Original Message-----
From: Carl Wallace

On 3/20/12 2:58 PM, "Miller, Timothy J." <[email-masked]> wrote:
> As currently written, allowing GOOD without qualifier leads to 
> incorrect interpretation of the protocol.  I.e., for most OCSP 
> Responders only REVOKED or UNKNOWN should be sent.

Adding an extension to return proof of existence would be easy enough
and would not break backwards compatibility.  Adding additional status
values or changing the meaning of existing status values would.  Clients
that want to fail without the extra proof could do so.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 20 Mar 2012 16:54:20 -0400

Wrong.

I suggest that if you are going to attack other people's competence in
this field you take the time to learn about it first.

OCSP was not intended to be limited to responding from a CRL. The CRL
is not the authoritative source even today. A CA can meet the PKIX
requirement to issue a CRL at much longer intervals than the OCSP
response updates.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 20 Mar 2012 17:04:23 -0400

We have a hard constraint that it be possible to pre-sign all signed
OCSP responses. That is an operational necessity.

If the OCSP responder is going to be required to always return a
signed response we need to have the ability to do range responses.
This will be a new requirement but essential for transparency.

Since a range response is only going to make sense for not-issued it
is going to be interpreted as such anyway.

I really fail to see why this proposal results in the responses it
does. Particularly given the number of boondoggles and curlicues that
the DoD faction has required of the spec: Policy constraints,
attribute certs, SCVP.

All I am looking to do here is to make the public CA system work
effectively. If the DoD faction can't live with that then I'll take
the proposal elsewhere and if it gets deployed we will end up in the
spec being spread across three standards orgs instead of the two it is
split across at present.

---

From: Carl Wallace <[email-masked]>
Date: Tue, 20 Mar 2012 18:24:09 -0400

>OCSP responses. That is an operational necessity.

A proof of existence extension would not break the ability to pre-sign
responses.  As with any extension, it would make responses larger though.

>is going to be interpreted as such anyway.

A range response extension could be a form of proof of (non-)existence (at
least at the time the pre-signing was done).  The extension could also
include a pointer for where to send the offending certificate so
corrective actions can be taken if necessary.  However, there are still
unanswered questions on the list regarding how to square range signing
with on-going certificate issuance with random serial numbers.

>does. 

Perhaps because it needs more work.  For example, it requires CAs to
maintain a complete log.  This seems like an odd requirement in a proposal
that is addressing a problem in which the CA lost control of their log.
It also leaves some important things unaddressed.  For example, is there
any operational necessity for backwards compatibility?  It seems odd to
want to use an existing protocol but break backwards compatibility.

If you are collecting requirements for transparency work, you should add
publication of all CA certificates.

A proof of existence-based approach might be a good thing for
transparency.  It would ensure the CA is not up to no good if a bad
certificate is found since the check that determines the certificate is no
good is performed on the client side.

Of course, to mention another unaddressed point from the list, any extra
check is moot depending on the nature of the compromise and whether bad
certificates can be distinguished from good ones.

>Particularly given the number of boondoggles and curlicues that
>effectively. 

OK.

>If the DoD faction can't live with that then I'll take

---

From: Tom Gindin <[email-masked]>
Date: Tue, 20 Mar 2012 20:04:13 -0400

I wish OCSP v1 had looked like #1 for CRL-only responders, but I 
think it's unrealistic to go there from RFC 2560.  That change is so far 
from backwards compatibility that it demands a new protocol, and a large 
class of clients are really just looking for "revoked" vs. "not known to 
be revoked" and would have no reason to migrate from v1 to this model. 
Thus, I propose an extension (obviously optional and non-critical) to be 
used with GOOD giving the operating model.
        I agree with #2 except for the statement about certificate 
evidence.  It's perfectly legitimate to choose "unknown", "good", or 
"revoked" based solely on the serial number in v1, and I see little reason 
to change that feature of the protocol.
        For #3, although I'm the one who started the discussion over 
NOTISSUED, NOTISSUED will work perfectly well as an extension to "unknown" 
(as will "expired").  I'm trying to extend the protocol rather than to 
break it.  This is especially true since "unknown", "within validity 
period", and "old enough to have been published" implies NOTISSUED.
        For anyone who wants to see a strawman, the extension I mentioned 
in #1 might have the following syntax, as a singleExtension used only with 
GOOD:
ResponseBasis   ::= SEQUENCE    {
        certIdentified  BOOLEAN DEFAULT FALSE   -- TRUE if it's in a full 
repository
}
        This is an extension partly to avoid changing the current 
definition of CertStatus' good element as IMPLICIT NULL, and making it 
contain IMPLICIT BOOLEAN DEFAULT FALSE instead would break existing 
clients.  As a responseExtension, the boolean's name changes to 
"fullRepository" but its basic meaning stays the same.  An alternative 
form for the response extension would be a three-valued enum called 
operatingModel { CRL, fullRepository, revokedRepository }.  Since I think 
that there's little difference which matters to the client between the 
"revoked certificate status DB" and a "CRL-fed" model which has just 
gotten a CRL, I prefer the boolean form.

Tom Gindin

From:   "Miller, Timothy J." <[email-masked]>
To:     Tom Gindin/Watson/IBM@IBMUS, 
Cc:     "Henry B. Hotz" <[email-masked]>, pkix <[email-masked]>
Date:   03/20/2012 09:42 AM
Subject:        Re: [pkix] Possible OCSP Extensions

1) A Responder with no access to the CA history has only two possible 
responses:

                 REVOKED - Certificate identified by the Request is on a 
CRL.
                 UNKNOWN - All other queries.

2) A Responder with access to the CA history, if and only if certificate 
evidence is provided in the Request, may also respond:

                 GOOD - An exact match for the certificate in the Request 
is found in the CA history, and that certificate is not on a CRL.

3) A Responder with access to the CA history, if and only if certificate 
*and chain* evidence is provided in the Request, may also respond:

                 NOTISSUED - The certificate in the Request chains to the 
cognizant CA but no exact match for the certificate is found in the CA 
history.

"Certificate evidence" must be a sufficiently unique CertID.  I'd want a 
cert thumbprint at the least; a copy of the cert itself at most.  If the 
Responder is operating as a Trusted Responder, the relying party won't be 
able to detect name collisions if only Issuer/Serial is used.  CA-signed 
and CA-Designated can detect name collisions because the queried cert 
won't chain to the same trust anchor as the OCSP Response signature, but 
they have to be specifically directed to make this check.

"Certificate and chain evidence" will probably have to be the certificate 
itself, though if anyone has alternative ideas I'm all ears.  IMHO this is 
required for NOTISSUED because it's the only way to prevent a malicious 
querent from messing up your day with falsified certificate evidence.  A 
query that doesn't match anything in the CA history is *not* enough 
evidence of compromise unless it can be shown to be a cert that actually 
chains to the cognizant CA.

I think the above is close to full coverage, but it's also a complete 
overhaul of OCSP.  I'd call it a new protocol, though I don't know enough 
about SCVP to say whether or not this functions can be replicated with 
that protocol.

-- T

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 21 Mar 2012 09:49:43 -0400

PHB,

All a pre-signer can do is say revoked/on CRL or not revoked/not on CRL.

-----Original Message-----
From: Phillip Hallam-Baker [mailto:[email-masked]] 
Sent: Tuesday, March 20, 2012 4:54 PM
To: Santosh Chokhani
Cc: Miller, Timothy J.; Carl Wallace; <[email-masked]>
Subject: Re: [pkix] Possible OCSP Extensions

Wrong.

I suggest that if you are going to attack other people's competence in this field you take the time to learn about it first.

OCSP was not intended to be limited to responding from a CRL. The CRL is not the authoritative source even today. A CA can meet the PKIX requirement to issue a CRL at much longer intervals than the OCSP response updates.

On Tue, Mar 20, 2012 at 4:09 PM, Santosh Chokhani <[email-masked]> wrote:
> Here's a rule of thumb:  Any specification that includes the phrase 
> "...does not necessarily mean..." should immediately be rewritten.  :)
>
>> and would not break backwards compatibility.  Adding additional 
>> status values or changing the meaning of existing status values would.
> IMHO, OCSP only needs two response codes:  REVOKED and OTHER, where 
> OTHER means the cert does *not* match records on the CRL.  This 
> doesn't mean the cert is good, bad, or someone else's, it just means 
> the revocation status could not be determined.  REVOKED should induce 
> a hard failure, and OTHER should not.  Three codes *in the base case* 
> introduced ambiguity because the only additional information the third 
> code (GOOD) tells you is "the cert *appears to be* one of mine," and 
> "appears to be" isn't actually conveying any actual information. [1]
>
> -- T

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 21 Mar 2012 09:54:12 -0400

PHB,

As Steve said, let us identify the requirements first, then see how valid they are and then we can debate the solutions.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker
Sent: Tuesday, March 20, 2012 5:04 PM
To: Kemp, David P.
Cc: [email-masked]
Subject: Re: [pkix] Possible OCSP Extensions

We have a hard constraint that it be possible to pre-sign all signed OCSP responses. That is an operational necessity.

If the OCSP responder is going to be required to always return a signed response we need to have the ability to do range responses.
This will be a new requirement but essential for transparency.

Since a range response is only going to make sense for not-issued it is going to be interpreted as such anyway.

I really fail to see why this proposal results in the responses it does. Particularly given the number of boondoggles and curlicues that the DoD faction has required of the spec: Policy constraints, attribute certs, SCVP.

All I am looking to do here is to make the public CA system work effectively. If the DoD faction can't live with that then I'll take the proposal elsewhere and if it gets deployed we will end up in the spec being spread across three standards orgs instead of the two it is split across at present.

On Tue, Mar 20, 2012 at 4:33 PM, Kemp, David P. <[email-masked]> wrote:
> Modifying OCSP responders to never send a deprecated GOOD response 
> does not change the meaning of that response.  And unless the default 
> client behavior is to fail on UNKNOWN, changing responders to use it 
> for all non-revoked certificates does not affect client behavior.
>
> discretion of the responder, the client can validate the proof since 
> it already has a copy of the certificate being checked, and the client 
> can follow its own policy for handling responses without the extension 
> or responses with proofs that don't match the certificate.  That is 
> backwards compatibility at its best, and although I'm skeptical of 
> using OCSP to address PHB's NOT-ISSUED requirement, the 
> proof-of-issuance extension seems quite straightforward.
>
> Dave
>
>

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 21 Mar 2012 14:00:32 +0000

> This will be a new requirement but essential for transparency.

While response ranges would help with pre signing, I don't see how to do this and retain backward compatibility.  Still thinking about that one.

That said, CRL-fed pre-signers for PKIs with sequential serials currently cope with the gap between highest-revoked and highest-issued.  I know one implementation takes the highest-revoked serial, adds a skew, and signs a "good" response for everything in between.  This is probably less than ideal, but as long as proof sets are generated at least as often as CRLs it doesn't create a problem.

If not-issued is added to the specification, this approach doesn't have to change.  Alternatively, a Responder with only pre-signed proofs can refer any request for status for a cert in the "gap" to another Responder with the necessary information where a live response can be generated.  The DoD currently does this for requests for certs that aren't in the pre-signed set. 

Again, less than ideal, but as long as proof sets follow CRLs closely enough it's a problem that can be managed operationally.

> is going to be interpreted as such anyway.

Actually, I see utility for response ranges regardless of disposition of not-issued as a concept.  The PKI I support would definitely benefit if only because the generation workload and resulting proof set size could be dramatically reduced.

> I really fail to see why this proposal results in the responses it

I'll speak only for myself, but for me it's because you're worrying about a corner case with a vanishingly small probability of actually occurring in the field.  Specifically, not-issued conveys actionable information only when the OCSP Responder key is provably secure, the CA history has provable integrity, but the CA signing key has been compromised.  Yes, that's one possible set of circumstances, but it's just not worth bothering about; a position I feel is bolstered by the most recent commercial CA compromises that show that CA signing key security and CA history integrity go hand-in-glove.  

Throw in the fact that the scheme is only implementable by Responders with access to the CA history, which anecdotally appears to be a minority of deployed Responders anyway, and the scheme's utility is even further reduced.

I'm far more interested in response ranges because of potential performance gains for deployed systems, and in improving OCSP overall by addressing the ambiguity of the current set of responses.

-- T

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 21 Mar 2012 10:07:47 -0400

I like the ideas Carl has with respect to once we have agreed on the requirements, problem to solve, looking at extensions at response and single response levels to see how extensions can solve the problem before we try to bust the protocol.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Carl Wallace
Sent: Tuesday, March 20, 2012 6:24 PM
To: Phillip Hallam-Baker
Cc: [email-masked]
Subject: Re: [pkix] Possible OCSP Extensions

>OCSP responses. That is an operational necessity.

A proof of existence extension would not break the ability to pre-sign responses.  As with any extension, it would make responses larger though.

>
>If the OCSP responder is going to be required to always return a signed 
>response we need to have the ability to do range responses.

A range response extension could be a form of proof of (non-)existence (at least at the time the pre-signing was done).  The extension could also include a pointer for where to send the offending certificate so corrective actions can be taken if necessary.  However, there are still unanswered questions on the list regarding how to square range signing with on-going certificate issuance with random serial numbers.

>I really fail to see why this proposal results in the responses it 

Perhaps because it needs more work.  For example, it requires CAs to maintain a complete log.  This seems like an odd requirement in a proposal that is addressing a problem in which the CA lost control of their log.
It also leaves some important things unaddressed.  For example, is there any operational necessity for backwards compatibility?  It seems odd to want to use an existing protocol but break backwards compatibility.

If you are collecting requirements for transparency work, you should add publication of all CA certificates.

A proof of existence-based approach might be a good thing for transparency.  It would ensure the CA is not up to no good if a bad certificate is found since the check that determines the certificate is no good is performed on the client side.

Of course, to mention another unaddressed point from the list, any extra check is moot depending on the nature of the compromise and whether bad certificates can be distinguished from good ones.

>Particularly given the number of boondoggles and curlicues that the DoD 
>faction has required of the spec: Policy constraints, attribute certs, 
>SCVP.
>

OK.

>If the DoD faction can't live with that then I'll take the proposal 
>elsewhere and if it gets deployed we will end up in the spec being 
>spread across three standards orgs instead of the two it is split 
>across at present.
>
>
>> it already has a copy of the certificate being checked, and the 
>> client can follow its own policy for handling responses without the 
>> extension or responses with proofs that don't match the certificate.  
>> That is backwards compatibility at its best, and although I'm 
>> skeptical of using OCSP to address PHB's NOT-ISSUED requirement, the 
>> status values or changing the meaning of existing status values 
>> would.  Clients that want to fail without the extra proof could do so.
>>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 21 Mar 2012 13:59:22 -0400

> All a pre-signer can do is say revoked/on CRL or not revoked/not on CRL.

Not true, there is an extensions field.

> As Steve said, let us identify the requirements first, then see how valid they are and then we can debate the solutions.

I have raised requirements here but you don't seem interested in them.

As for the IETF being the judge of the 'validity' of my requirements,
never. I have requirements and I will deploy whatever technology I
require to meet those requirements. If nobody else agrees with my
requirements they are unlikely to need my technology and there is no
requirement for a standard.

There seems to be a demand for greater transparency in the operation
of public CAs. There is a clear advantage to both the CAs and our
customers in meeting that demand. So I expect that the industry will
take whatever measures are necessary to achieve that.

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 21 Mar 2012 14:09:06 -0400

So, what would pre-signer figure out about unissued certificates and put in extensions field.

Pre-signer can only speak for issued certificates.

-----Original Message-----
From: Phillip Hallam-Baker [mailto:[email-masked]] 
Sent: Wednesday, March 21, 2012 1:59 PM
To: Santosh Chokhani
Cc: Kemp, David P.; [email-masked]
Subject: Re: [pkix] Possible OCSP Extensions

As for the IETF being the judge of the 'validity' of my requirements, never. I have requirements and I will deploy whatever technology I require to meet those requirements. If nobody else agrees with my requirements they are unlikely to need my technology and there is no requirement for a standard.

There seems to be a demand for greater transparency in the operation of public CAs. There is a clear advantage to both the CAs and our customers in meeting that demand. So I expect that the industry will take whatever measures are necessary to achieve that.

> Of Phillip Hallam-Baker
>> considered "good".   Whereas UNKNOWN is a reasonable word to use for 
>> a certificate that may or may not exist, but is definitely not revoked.