Subject: [pkix] OCSP extension

From: Stephen Kent <[email-masked]>
Date: Wed, 9 Nov 2011 13:32:06 -0500

Folks,

While the discussion of a whitelist per se is not new, the question 
of whether OCSP should be extended to provide status info other than 
revocation status.

Discussion of this topic triggered the development of SCVP, as an 
alternative to revising and extending OCSP to provide status info 
other that revocation status.

An OSCP response of the form "good" clearly moves back into this 
territory.  Issued and not revoked is skating close :-).

The recent observation that "good" is a misleading OCSP response 
alludes to this issue. (Maybe if we named the protocol OCRSP ("R" = 
"revocation") we might have avoided this problem, but ...

I am worried that we are again heading down the path of asking OCSP to
convey cert validity, vs. cert revocation status.

I'd much rather see this question explored in the context of the SCVP 
validation (vs. path discovery) function, even though I realize that 
there are some subtle differences  between the "issued and not 
revoked" response and cert validity.

Steve

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 9 Nov 2011 19:34:03 +0000

>convey cert validity, vs. cert revocation status.

That's a fair point.  I'll cop to blurring this line in the discussion,
but I am aware of the distinction between the response and a statement of
validity.

>revoked" response and cert validity.

You stole my thunder; that's where I was going to go next responding to
Martin & Tom.

-- T

---

From: [email-masked]
Date: Thu, 10 Nov 2011 14:02:41 +0100

Steve,,

This topic has nothing to do with SCVP, since "good and really issued" is 
very different from "this certification path is valid".
So this discussion should stay with OCSP and should not be redirected to 
SCVP.

For a RP point of view, the proposed extension  is able to provide a 
better confidence . 

Some validation policies could (in the future) mandate the presence of 
this new extension, 
so that only OCSP responses containing this new extension will be 
accepted.

My first proposal for a certificate that was not isued was:

a) OCSP responder using CRLs

certStatus = good

b) OCSP responder using  white lists of certificates

certStatus= revoked

singleExtension "cert. status checked using white lists" present.

This proposal is insufficient since it does not allow a RP to know that 
the certificate was not issued and hence is not able 
to help the CA to discover a security breach.

In order to make the difference between "issued" and "not issued", the CA 
SHALL add a hash of the certificate
 when the certificate was issued.

Then, in case a RP observes that it got a certificate that was correctly 
signed but at the same time the OCSP responder 
indicates that it was not issued, the RP should contact the CA so that the 
CA can take immediate actions to investigate 
immediately the origin of the problem and take corrective measures if 
possible. 

Denis

Folks,

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

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 10 Nov 2011 15:37:03 +0100

On 11/10/2011 02:02 PM, [email-masked] wrote:
> Steve,,
>
> This topic has nothing to do with SCVP, since "good and really issued" 
> is very different from "this certification path is valid".
> So this discussion should stay with OCSP and should not be redirected 
> to SCVP.
I wondered how long it would take to come to this comparison. Indeed,
he discussion started with OCSP. The reason is not that OCSP is best suited,
but there is already much more deployment and software.

> For a RP point of view, the proposed extension  is able to provide a 
This is an incomplete interpretation.
> singleExtension"cert. status checked using white lists" present.
>
> This proposal is insufficient since it does not allow a RP to know 
> that the certificate was not issued and hence is not able
But the responder knows the problem and is probably better placed than 
the RP.
>
> In order to make the difference between "issued" and "not issued", the 
> CA SHALL add a hash of the certificate

- a client that is interested to obtain more information about a cert, 
adds an
   extension that let's say as a layman: send the certificate in question.

- The server is able to say "revoked" if the cert is not on its "whitelist".
     But, in case of 'good', the client doesn't know whether whether the
     server operates with a white list.
     making the extension critical, doesn't seem a good choice for me.
    ==>
- A server can respond with another extension indication: "good, and I 
have a whitelist"
     well, it may be that the client doesn't want to show the cert.
     ==>
- The client is supposed to have the cert, so the client can send the hash,
     and the server responds with a corresponding cert if it has a 
matching one.

- When receiving "revoked" without a cert, the client doesn't know 
whether the
   cert exists,  but the server does, and can take actions. The server 
may respond
   with a non-critical extension indicating 'revoked because I have no 
record'.

>
> Then, in case a RP observes that it got a certificate that was 
> correctly signed but at the same time the OCSP responder
> indicates that it was not issued, the RP should contact the CA so that 
> the CA can take immediate actions to investigate
I don't care.
> of whether OCSP should be extended to provide status info other than
For the purpose of revocation status delivery, OCSP is
a "Eier legende Wollmilchsau.", there are several layers
of protocols, it seems to be meant to be as "yet another
session/dialog/presentation/...  extensible  protocol.
Too much anyway, but it exists.
> revoked" response and cert validity.
Steve, if you want to have SCVP doing this, then I think
one should define a very limited profile, i.e.

  client send cert hash with some appropriate wantback,
  and server sends the cert. Just this, all other features
  of SCVP may be rejected by the server.

Discussion about whether it is better to use SCVP or OCSP
IMO not very helpful at that stage.

BTW: I remind that another protocol says:

    When verifying a public key certificate, the DVCS verifies that the
    certificate included in the request is a valid certificate and
    determines its revocation status at a specified time.

    As a replacement for certificates, certification identifiers
    (ESSCertId, CertId)  MAY be used in requests and responses, if this
    is sufficient to perform the service, e.g., when the corresponding
    certificates are provided elsewhere in a request or response (as part
    of the SignedData type).

regards
/P

---

From: Stephen Kent <[email-masked]>
Date: Thu, 10 Nov 2011 11:03:25 -0500

At 2:02 PM +0100 11/10/11, [email-masked] wrote:
>Steve,,
>
>This topic has nothing to do with SCVP, since "good and really 
>issued" is very different from "this certification path is valid".
>So this discussion should stay with OCSP and should not be redirected to SCVP.

I understand your objection, but one could, I believe, use SCVP here 
for the intended application.  OCSP is revocation status protocol, so 
the question "was this cert issued" is not really in scope for it 
either. The question "was it issued and not revoked" is pretty close 
to the scope, and arguably closer than the "is it valid relative to a 
specified point in a cert path.

>For a RP point of view, the proposed extension  is able to provide a 

agreed.

>Some validation policies could (in the future) mandate the presence 
>of this new extension,
>so that only OCSP responses containing this new extension will be accepted.

yes, maybe.

>singleExtension "cert. status checked using white lists" present.

"revoked" is not really accurate. It is force fitting the status into 
the current set of responses, for backward compatability, right?

>to help the CA to discover a security breach.

I do not recall that a goal of this was to have RPs help a CA 
discover a breech,
but it may have been cited on one of the many messages.

>In order to make the difference between "issued" and "not issued", 
>the CA SHALL add a hash of the certificate

that makes this an even less desirable design, as it increases CRL 
size by an even greater factor!

>indicates that it was not issued, the RP should contact the CA so 
>that the CA can take immediate actions to investigate
>immediately the origin of the problem and take corrective measures 
>if possible.

Yes, one could do that, but I think it may make more sense to suggest 
that the OCSP server contacts the CA, in many contexts. In the 
context we've been discussing, i.e., browser clients validating web 
site certs in the public Internet, I have little confidence in that 
set of RPs contacting a CA.  Also, we should note that an OCSP server 
operated by a CA provides an obvious, immediate path to the CA in 
question.

Steve