Subject: OCSP request

From: "Karl Scheibelhofer" <[email-masked]>
Date: Wed, 26 Jul 2000 09:08:23 +0200

if a certificate can only have the simple histories (issue)-valid-expired
and (issue)-valid-revoked, there is no problem. generalized: when a
certificate becomes invalid (revoked or expired) it remains invalid forever.
but, if a certificate can be suspended (= invalid for some time), i cannot
use OCSP as is to find that out later on when the certificate is no longer
suspended.

what i would like to have:
from the client's point of view, i want to ask the OCSP server: was this
certificate valid during the whole time interval [t1,t2]?
in case of successful processing of request the server should respone:

- certificate was valid during whole time interval [t1,t2]
- certificate was invalid during whole time interval [t1,t2], because of
(revocation,suspension,...)
- status of certificate changed during time interval [t1,t2], type of change
was (valid-suspended, valid-revoked, suspended-valid, ...)

in case of unsuccessful processing the server should tell the reason
(certificate unknown, , unsupported certificate format, internal error,...)

this approach would support any life-cycle of certificates.
by now, it seems to me that a lot of protocols assume implicitly that
certificates can become invalid just once, and once they are invalid they
can never become valid once again. i agree that this is mostly the case.

does this idea also make sense to others?

best regards,

  Karl Scheibelhofer

--

Karl Scheibelhofer, <mailto:[email-masked]>
Institute for Applied Information Processing and Communications (IAIK)
at Technical University of Graz, Austria, http://www.iaik.at
Phone: (+43) (316) 873-5540

---

From: Simon Tardell <[email-masked]>
Date: Wed, 26 Jul 2000 16:16:10 +0200

Jürgen,

The black-list AND white-list approach taken by German signature legislation
is good by me. It addresses the potential "big-bang" of CA key compromise in
ways that are reasonable. However, I don't think you need to change OCSP
semantics to do this. I see the German ISIS OCSP variety as a change rather
than a profile, because an OCSP client has to behave differently when
talking to an ISIS OCSP responder than when talking to a world OCSP
responder.
 
> 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"?

One problem with altering the definition of "unknown" from "I don't know" to
the assertion "I know this certificate has not been issued" is that you may
have several OCSP responders to choose from (for availability reasons) and
if one of them is unable to answer one or more of the requests in an OCSP
request, it should be possible to go down the list, or come back later. If
you don't distinguish between the "no" and "???" answer, you don't have that
possibility. Even if an ISIS compliant PKI may not use this, the end-user
may be part of other PKIs that do, and it'd be convenient to be able to use
the same clients.

Basically there are two independent assertions: revoked - yes/no/don't-know
and issued - yes/no/don't-know. My suggestion is to treat them on equal
footing. Restrict CertStatus to represent the first assertion
(yes/no/don't-know on revocation) and introduce an extension for the second
assertion ("being inserted into the directory (SigG)") with the same
structure (yes/no/don't-know). Let this extension be critical if the value
is "no" or "don't-know". In this way, non-ISIS compliant clients will work
together with ISIS PKIs and vice versa, without losses. Of course, some
combinations are unreasonable (you hardly revoke a certificate that was
never issued) or may be disallowed by policy (maybe the "don't-know" answers
are not possible due to policy).

Orthogonality between assertions means that further assertions ("was valid
at time X" was suggested) can be introduced in the same manner, without
breaking unaware clients. That is probably the biggest advantage.

One more comment:

> >> 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. 
> 
> 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.

Sure he can. It's a matter of policy. Since you can't trust the list of
responders in the AIA extension (because you fear CA key compromise) you
have to have a hard-coded list. This is true whether you allow for one or
several responders.

Regards,

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: Frank Balluffi <[email-masked]>
Date: Wed, 26 Jul 2000 07:20:34 -0700

Juergen,

If by an "expired crypto algorithm" you mean an algorithm that is known to
be insecure, then it may also not be possible to rely upon signed OCSP
responses. This sounds like a red herring to me.

Frank

> -----Original Message-----
> From: Juergen Brauckmann [mailto:[email-masked]]
> Sent: Wednesday, July 26, 2000 8:58 AM
> To: Ambarish Malpani; 'Simon Tardell'; 'Rich Salz'
> Cc: [email-masked]
> Subject: RE: OCSP request
> 
> 
> Ambarish, Simon,
> 
> I'm a member of the group that worked on the ISIS. Comments below... .
> 
> >> -----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
> >>
> [...]
> >> 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
> >> 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:
>    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".
> 
> 
> 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: Frank Balluffi <[email-masked]>
Date: Wed, 26 Jul 2000 07:47:35 -0700

Juergen,

Thank you for the clarification. I assumed that you meant an OCSP response
from around the same time that the certificate was issued. In this case, the
use of red herring inappropriate.

In the case you described, why would the timestamper know to use a "chain of
timestamps with valid algorithms", but not the CA (i.e., use a valid
algorithm)? Just curious.

Frank

> Sent: Wednesday, July 26, 2000 10:40 AM
> To: Frank Balluffi
> Cc: [email-masked]
> At 07:20 26.07.00 -0700, Frank Balluffi wrote:
> >Juergen,
> >
> Simple example: Certificate from 1990 with 512-bit RSA 
> signature by the CA,
> OCSP Response with an up-to-date certificate with 1024 or 
> 2048 bit RSA key. 
> 
> You cannot necessarily rely on the 512-bit signature, but you 
> could rely
> upon the OCSP response signature.
> 
> Juergen
> --

---

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 26 Jul 2000 17:20:00 -0600

I don't mean to pick on Simon twice in one day, but his assertions regarding the benefit of timestamping don't make legal sense.

>Now, if a key gets compromised, you cannot trust *any* signatures by that
>key (before or after compromise), because you cannot trust the signer's
>assertion of what time it was. A practical system has to protect itself from
>that somehow. Enters time stamping. A time stamping service would probably
>check the revocation status of the signatory cert and store that together
>with the time stamp. 

If the certificate is revoked for cause, e.g, a change of name, change of status, etc., then (generally speaking) whoever did in fact sign the document is legally liable for the consequences, regardless of the revocation status.  (Note that I said whoever in fact signed the document, NOT necessarily the apparent subscriber.) All that the revocation does is to change the reasonableness of the presumption that the transaction was valid -- it doesn't change the _fact_ of who signed it -- they are still personally liable.

The other case is where a key compromise is suspected.  Depending on the circumstances, that compromise might or might not be known.  If a smart card is lost, the time could probably be pinned down to a day or so, but if someone's password for a software-encrypted key were compromised, no one is likely to know IF that occurred, much less when.

In the second case, therefore, it may be completely immaterial as to when a given document was signed, and all of the timestamps in the world won't help, if in fact the key was compromised a year earlier, covertly.

The real issue is not a technical one, but two legal ones.  The first is, in the event of a challenged signature (attempted repudiation), which party bears the burden of proof.

Depending upon the specific statutes, the revocation of a certificate MAY serve to transfer the burden of proof to the relying party, to show that the reliance on the transaction was commercially reasonable.  Some of the original digital signature statutes, such as the much maligned Utah Act, attempted to answer that question with a rebuttable presumption, assuming that the certificate was issued by a licensed CA.

The second issue is, regardless of who has the burden of proof, who bears the risk of loss in the event that the subscriber did not in fact sign the transaction.  is the subscriber strictly liable, or is the relying party required to show both commercial reasonableness and perhaps to bear some or all of the risk of loss?

Those aren't technical questions, they are legal ones, and OCSP can't help very much.

Bob

---

From: Simon Tardell <[email-masked]>
Date: Thu, 27 Jul 2000 10:58:17 +0200

Ambarish,

> b. The reason why the change ISIS has proposed is "wrong" is:
> In an OCSP request, you identify a cert by the hash of the CA's
> public key [and the hash of the CA's name] and the certificate
> serial number. If somebody had compromised the CA's public key,
> all they would need to do, is create a new certificate with a
> serial number that corresponds to a legitimate serial number, but
> a different subject public key and there goes the ability of the
> OCSP responder to tell you anything useful.

ISIS defines an extension holding the hash of the certificate for this
purpose.

Simon.

---

From: Juergen Brauckmann <[email-masked]>
Date: Thu, 27 Jul 2000 11:37:04 +0200

>algorithm)? Just curious.

Well, if you received an important signature from someone, you can get
timestamps from TSAs as often as you like (each time with a fresh
algorithm). But it may be difficult/impossible for you to get a new
certificate from the person that gave you the signature.

Juergen

---

From: Simon Tardell <[email-masked]>
Date: Thu, 27 Jul 2000 13:57:42 +0200

Bob,

> I don't mean to pick on Simon twice in one day, but his 
> assertions regarding the benefit of timestamping don't make 
> legal sense.

That is a very categorical statement. And I don't see where you contradict
what I say. There may be legal systems, and business practices, as well as
technical circumstances that makes timestamping of no benefit. OTOH the
reverse is also true. In fact, the rest of your reasoning about who stands
the risk if there is a dispute only serves to underline that. 

Paying with bank cards in Sweden and in the US is an analogue world example
of such differences in business practices (more that than law). In Sweden
the merchant forces you to show photo ID, because the bank will make him
stand the risk if he doesn't. And he has to (sort of) prove that he did (by
writing the ID card number on the slip, and signing). It seems perfectly
reasonable to me that a translation to our world would be the bank forcing
the merchant to check your certificate and time stamp that together with the
transaction. Or the time stamping service doing that step for him. 

Note, even though the imposter that tries to use my bank card is responsible
for doing so, that does not relieve the merchant of the obligation to check
ID. Liability doesn't have to be connected to business risk (the imposter
may never show up to pay the money he owes).

So, yes, laws and business practices do make a difference, I agree. And
technology does to, to support laws and business practices.

Simon.

---

From: [email-masked]
Date: Thu, 27 Jul 2000 13:07:18 -0400

One slight clarification about TS chains below :-)

(snip)
> 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
> 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.

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.

[Tom Gindin] If I remember your presentation at IETF 46 correctly, the
actual claim is that a chain of time stamps protects against both key
compromise (of a time stamp) and weak algorithms as long as there was no
time T at which the most recently applied stamp (as of time T) had been
rendered questionable - whether by key compromise or by weak algorithm.
Key compromise or algorithm break only bring a chain into question if they
are claimed to have occurred before the next time stamp in the chain.

---

From: Ambarish Malpani <[email-masked]>
Date: Thu, 27 Jul 2000 07:44:26 -0700

Hi Juergen,
    Originally, OCSP had the following states (I do this from
memory, so I might be a little off):

- good
- revoked
- expired
- notIssued
- unknown (maybe)

The problem with having this set of return states, is you then
need to ask: does "revoked" also mean not-expired, but issued?
What does "issued" say about the revocation status? Does "good" imply
that is was issued? What if the responder doesn't know about that?

This topic was discussed in gory detail, and I had suggested one
of two approaches:
1. The current way of doing things
2. Have 3 orthogonal statuses in the response, referring to
the revocation, expiration and issuance status of the cert.

While proposing the second question, I had also asked why it was
important to figure out the expiration/issuance status in OCSP -
couldn't the client figure this out on their own. Pretty much all
the people agreed that they could and that is why we went with
solution #1.

Yes, as far as I can see, your certHash mechanism will work.
However, I still don't see exactly what problem you are solving
with it. Are you trying to take care of the issue of CA key
compromise/misuse? That was not the problem we were trying to
solve with OCSP. If the CA key is compromised, I could also issue
a OCSP-signing certificate to a fake OCSP responder controlled by
me and then issue incorrect responses to my heart's content.
Couldn't I?

It is really important that you specify very, very clearly what
problem you are trying to solve and the kind of scenario you
are operating in (direct trust of the responder, CA delegated trust,
...). Then, a better analysis of your proposed solution is
possible.

Hope this helps,
Regards,
Ambarish

P.S. What is the status of the ISIS solution? Is it already a
"rule/law"? Is it open to review/comments/suggestions?

A

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

> Sent: Thursday, July 27, 2000 2:34 AM
> To: Ambarish Malpani
> Cc: [email-masked]
> Hello Ambarish.
> At 07:10 26.07.00 -0700, Ambarish Malpani wrote:
> >1. OCSP responses are not meant to be weak at all. The meaning of
> >good is "not revoked" or "still good" (as long as the certificate
> >was correctly issued and hadn't expired before the ArchiveCutoff
> >date).
> 
> From RFC 2560:
>    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
> 
> By saying that OCSP responses are "weak" I had the last 
> sentence in mind.
> An OCSP responder can give me a "good" even if the CA did not 
> issue the
> certificate. Minimum-RFC2560-OCSP-responses with "Good" don't tell me
> whether the certificate ever existed.
> 
> "Weak" is probably a bad word for it. 
> 
> >The problem you might run into,
> >is say, somebody builds an ISIS OCSP server and somebody else
> >tries to use it with say a Netscape Communicator OCSP client. The
> >two products will claim to talk OCSP, but will actually be saying
> >different things in their requests and responses and nobody else
> >will ever know.
> 
> Yes, I see. 
> 
> One question (mainly an attempt to try to understand rfc 
> 2560): Why didn't
> you include specifications for the issuance questions into rfc 2560?
> Obviously you were aware of the problem because the 
> description of "good"
> says that such information may be delivered by extensions. 
> And why isn't
> there a fourth state "noSuchCert" besides good,revoked,unknown? I
> understand that it was the intention to be able to build 
> CRL-based OCSP
> Responders, but I don't see why it should have been 
> impossible to combine
> the two things.
> 
> Yes. Therefore the OCSP Response should contain a hash of the 
> certificate
> in an extension, see my mail
> from yesterday "good in OCSP Responses. Was: Re: OCSP 
> request". This is the
> ISIS certHash extensions Simon is refering to in his mail 
> from 10:28 today.
> 
> >Part of why it is valuable to at least pose desires to change the
> >interpretations of RFCs on this kind of a list, is you might
> >actually get some useful input from others, who might think about
> >a problem in different ways.
> >
> >Does that make sense?
> 
> Well one problem is that it's difficult to see what the 
> interpretation of
> RFC2560 is that the authors had in mind... .
> 
> >P.S. Again, if you do pose the problems you want to solve, there
> >might be other reasonable ways of extending OCSP [within the
> >framework of the protocol], that might better fit in with the RFC
> >itself.
> 
> We try that, see the certHash extension... .
> 
> Regards,
>   Juergen
> --