Subject: RE: OCSP request

From: Ambarish Malpani <[email-masked]>
Date: Tue, 25 Jul 2000 10:14:17 -0700

Hi Simon,
    Yes, we do, violently agree!

I didn't know of the German ISIS interpretation of "unknown". That
is *not* the interpretation that any other group is taking. Do
you know who I can contact to help sort this out? I think it is
very, very wrong!

Given this interpretation, I agree, the
wording could and should have been more explicit.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: Simon Tardell [mailto:[email-masked]]
> Sent: Tuesday, July 25, 2000 8:45 AM
> To: 'Ambarish Malpani'; Simon Tardell; 'Rich Salz'; Joerg Seidel
> Cc: [email-masked]
> Subject: RE: OCSP request
> 
> 
> Ambarish, 
> 
> Let me just start by pointing out that I agree with you 
> (mostly). But not
> everybody agrees with me....
> 
> > Hi Simon,
> >     Here is the text from RFC 2560:
> > 
> > ---------------Start quote from RFC----------------------
> >  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.
> > 
> >    The "revoked" state indicates that the certificate has 
> been revoked
> >    (either permanantly or temporarily (on hold)).
> > 
> >    The "unknown" state indicates that the responder doesn't 
> know about
> >    the certificate being requested.
> > 
> > ---------------End quote from RFC----------------------
> > 
> > 
> > Good means that it is not on the revoked list. If you wish to
> > assert other things, you can do so with extensions.
> > 
> > Revoked means that it is on the revoked list (you can still assert
> > other things with extensions - nothing says you can't do that,
> > although I agree, it would have been better to say so explicitly.
> > 
> > Unknown means you don't know - aren't willing to say either good
> > or bad (again, you can still use extensions to say more things).
> > 
> > I am not sure which part of the language you are objecting 
> > to.
> 
> The problem I have is that a responder may through "good" 
> assert that any
> number properties are true, *without* qualifying with 
> extensions. On the
> other hand "revoked" means a negative assertion to only one of these
> properties.
> 
> Also, in your interpretation (and mine) "unknown" means "I 
> don't know or
> will not say". As a client a perfectly reasonable reaction to 
> that would be
> to come back and check later or go to another OCSP responder 
> (assuming I
> have a list to choose from) and query that responder. However, it is
> possible to interpret the "unknown" definition as an 
> assertion that "I know
> that this certificate is not issued". This is the 
> interpretation taken by
> the German Trust Center Work Group in their ISIS spec. Under those
> semantics, I can't expect any other responder to have better 
> information.
> 
> > Would it have
> > been satisfactory if we had the line starting "Response 
> extensions...
> > validity, etc." in each of the 3 states? Would you have
> > preferred that we not have allowed for any extensions in responses?
> 
> The preferred way would have been to restrict CertStatus to carry
> information only on revocation and force issuance, validity 
> or any other
> property that you want to assert into extensions. Preferrably those
> extensions should have the same structure (assertion true, 
> assertion false,
> i-don't-know). 
> 
> Simon.
> 
> 
> Simon Tardell, Software Architect, iD2 Technologies
> voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319
> [email-masked], http://www.iD2tech.com
> Securing the Internet economy
>

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 26 Jul 2000 09:27:14 +0200

Ambarish,

> you know who I can contact to help sort this out? I think it is

I support your last assertion. As you stated "unknown" means "I
don't know or will not say". This means I also agree with Simon. :-)

Denis

---

From: Juergen Brauckmann <[email-masked]>
Date: Wed, 26 Jul 2000 14:57:55 +0200

Ambarish, Simon,

I'm a member of the group that worked on the ISIS. Comments below... .

>> Subject: RE: OCSP request
[...]
>> have a list to choose from) and query that responder. 

This means that a client *never* can get an authoritive answer that the
certificate is faked (by the way of a CA key compromise) because a client
has no way of knowing whether he talked to all OCSP Responders that may
know something about the certificate.

>> However, it is
>> the German Trust Center Work Group in their ISIS spec. 

RFC2560:
   The "unknown" state indicates that the responder doesn't know about
   the certificate being requested.

ISIS:
   	"Such a reply means that the queried directory service (SigG) cannot 
	provide information about this certificate, since it was not issued 
	by the corresponding certification authority or was not entered into 
	the directory service (SigG)."

Let me try to explain why we want to have "hard" responses from directory
services. The minimum requirements to OCSP in RFC2560 are "weak" in the
sense that there is only one real answer ("revoked") and two answers
("unknown" and "good") which basically mean "Hm, I'm not sure". Minimum
RFC2560-OCSP only provides blacklist functionality.

This is not sufficient for systems that must be robust/tolerant against CA
key compromise or such things. It is also not sufficient for long term
validation of signatures, where you might have, e.g., a signature and a
certificate with an expired crypto algorithm, and a chain of timestamps
with valid algorithms, and where you want to verify the state of the
certificate that made the signature. In this situation you cannot rely on
the certificate itself as an evidence that a CA ever issued it, you must
ask the CA.

In such systems a directory service must be able to give real *positive*
answers about certificates ("Yes, my CA issued this certificate."). This
means we need white lists. This can be done by using OCSP and interpreting
"unknown" as "The certificate was not issued by this CA", and by
interpreting "good" as "The certificate was issued by this CA and not
revoked".

The semantics of "Good" is left rather unspecified in RFC2560, why
shouldn't also "Unknown" be the subject of profile-specific
interpretations? Why should that be "very, very wrong"?

Juergen
-- 
Juergen Brauckmann             Tel.:  +49 (0)40 / 80 80 26-3 11
TC TrustCenter GmbH            Fax.:  +49 (0)40 / 80 80 26-1 26
Sonninstraße 24-28   	    mailto:[email-masked]
D-20097 Hamburg 		    http://www.trustcenter.de

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 27 Jul 2000 11:00:22 +0200

Juergen,

See my comments below.

> >> don't know or will not say". As a client a perfectly 
> >> reasonable reaction to that would be to come back and 
> >> check later or go to another OCSP responder (assuming I

> know something about the certificate.

This is incorrect. You need to query an OCSP server you trust,
either directly (indicated by out-of-bands means), or because it is
indicated within the user certificate.

> >> However, it is possible to interpret the "unknown" 
> >> definition as an assertion that "I know that this 
> >> certificate is not issued". This is the interpretation 
> >> taken by the German Trust Center Work Group in their ISIS spec.

 
> RFC2560-OCSP only provides blacklist functionality.

Nearly. It is not a "minimum" requirement, it is a "maximum"
requirement. Suppress "Minimum". The right sentence is:
"RFC2560-OCSP only provides blacklist functionality". This allows
OCSP responders to base their responses using CRLs only and no other
information.
 
> key compromise or such things. 

Key compromise is an exceptional event (that should not happen, but
might happen) that must be addressed under a disaster recovery plan
(i.e. revoke the CA whose key has been compromised in all the
certificates that has been issued for that CA by other CAs). This
does not mean using means that *permanently* address that case. If
you mandate an OCSP response in the sense you mention, then this
means two things: 

1) you deny the use of CRLs, and 

2) you also deny the local checking of the digital signature 
   from a CA over any certificate (it means that a local checking 
   by a RP is never sufficient since anyway an access to a trusted 
   copy certificate is necessary in a trusted database from the CA 
   which has issued it). So your model is *very* different from the 
   path validation model that is currently described in RFC 2459 
   (or its successor). 

This is pretty different from RF 2459.

> It is also not sufficient for long term

This is wrong. A chain of time stamps protects against key
compromise,
as well as weak algorithms, as long as the timestamps have been
applied
before the key has been compromised or the algorithm has been found
weak. So there is no need to ask the CA.

> interpreting "good" as "The certificate was issued by this CA and not

No. OCSP is not based on the use of white lists. RFC 2459 allows the
use of CRLs and also allows the use of on-line methods of revocation
notification (like OCSP) as another way of providing the same level
of service.

Section 3.3 on revocation of RFC 2459 explicitly states the
following:

" However, this profile does not require CAs to issue CRLs. Message
formats and protocols supporting on-line revocation notification may
be defined in other PKIX specifications.  On-line methods of
revocation notification may be applicable in some environments as an
alternative to the X.509 CRL."

Denis

---

From: Juergen Brauckmann <[email-masked]>
Date: Thu, 27 Jul 2000 14:05:50 +0200

Hi Denis.

>indicated within the user certificate.

So a user must be sure that he configured his client software with all OCSP
responders that a CA may have.

How is he informed if the CA adds another OCSP responder?

>This is pretty different from RF 2459.

The ISIS specification is for use with the German Signature Law. The root
CA operated by the "Regulierungsbehoerde fuer Telekommunikation und Post"
<http://www.regtp.de/en> originally wanted to enforce a chain model, where
a certificate may be valid at time T even if its CA certificate is revoked
at T. They did this by revoking not any longer used CA certificates when
they performed a regular certificate and key rollover. So all certificates
under the old CA certificate were suddenly invalid with RFC2459
verification procedures. 

This means that there is some chance that we(=ISIS) must deal with
non-RFC2459 validity models.

Most involved CAs are, eh, not *really* happy with this situation. The
discussion with the RegTP is going on... .

>This is wrong. A chain of time stamps protects against key

You are right if the timestamp is made over the signature and the
certificate. If the timestamp secures only the signature and a reference to
the certificate (like issuerDN/serialnumber and hash), then the CA must be
asked. OK, that's perhaps not too realistic... .

Juergen

---

From: Richard Levitte <[email-masked]>
Date: Thu, 27 Jul 2000 15:31:12 +0200

> responders that a CA may have.

Hmm, I think "or because it is indicated within the user certificate" might be
a key phrase here...  The other alternative is some kind of global trusted
responder that does the work for others.

> How is he informed if the CA adds another OCSP responder?

I think that a CA has to think carefully before they do that, by making sure
the new responder is reachable through already known names and transports.
This is not really a hard issue, it's just a question of using using other
technologies correctly and optimally, no?  Using DNS, The SRV RR could help a
lot here, for example.  Then again, perhaps I misunderstand what you mean...

In any case, if a CA doesn't make sure the new OCSP responder is reachable
through already known means, they either didn't want it to be reachable for
anything than possibly new certs with info about the new OCSP responder in an
AuthorityInfoAccess, or it has made a fool of itself.  Or some other
alternative I'm not thinking of...

--
Richard Levitte                 !!! New cell phone number !!!
[email-masked]

/* You might enjoy viewing the complete vCard */

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 27 Jul 2000 16:23:57 +0200

Juergen,

> The ISIS specification is for use with the German Signature Law. 

I heard that the German Signature Law was in the process of being
revised.

> The root

To give a name to that "other model", should we call, for the time
being, the "ISIS model" ?

> asked. OK, that's perhaps not too realistic... .

No. Since, as you said, the reference to the certificate includes
the hash of that certificate, this is not necessary to ask anything
to the CA. 

Denis

---

From: Juergen Brauckmann <[email-masked]>
Date: Thu, 27 Jul 2000 16:56:20 +0200

>I heard that the German Signature Law was in the process of being

As far as I know the revision will have no impact on the interpretation of
the validity model by the RegTP.

>being, the "ISIS model" ?

Hm, regtp-model?

>the hash of that certificate, this is not necessary to ask anything

Ups. You are right, sorry... .

Juergen