Subject: Re: OCSP and CSL

From: [email-masked]
Date: Mon, 24 Jan 2000 19:32:14 -0500

Massimiliano Pala <[email-masked]>@toutatis.comune.modena.it on
01/24/2000 12:51:03 PM

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  OCSP and CSL

Hi all,

(first of all I apologize for my english(?), now let's go on ... )

working about an OCSP server to be included in the OpenCA package
I found very strange the lack of some kind of CSL (Certificate
Suspension List). If there is something similar I'm not aware of,
please report it and ignore this mail ...

For CSL I mean a sort of CRL (same structures, formats), but carrying
a list of only suspended certificates: this is obviously useful for
ocsp implementations and considering the fact that in most env you'll
not be requested for certificate status changing very often, issuing
this kind of lists, I think, could be useful.

[Tom Gindin] I believe that a CSL, in this sense, is probably just a CRL
whose issuingDistributionPoint extension contains an onlySomeReasons field
specifying the certificateHold bit and no other bit.  This doesn't require
any change to the standards.  However, it does bring up another point.  Why
is certificateHold included in ReasonFlags but not removeFromCRL?  If a
delta CRL is issued for a CRL partitioned by reason code, it seems to me
from the definition of issuingDistributionPoint that removeFromCRL could
only be included in a delta CRL with the onlySomeReasons field missing,
which goes against the point of having CRL's partitioned on a reason code
basis at all.  If it is assumed that entries with reason removeFromCRL are
permitted in any delta CRL whenever ReasonFlags contains certificateHold,
we should probably amend the IDP extension description to make this clear.

(snip)

---

From: Peter Williams <[email-masked]>
Date: Wed, 26 Jan 2000 12:34:19 -0800

https://www.verisign.com/repository/CPS1.2/CPSCH9.HTM  FYI.

9.8.2 is fun.

-----Original Message-----

From: Philip Hallam-Baker [mailto:[email-masked]]
Sent: Wednesday, January 26, 2000 12:14 PM
To: 'Brian Ford'; Massimiliano Pala
Cc: [email-masked]
Subject: RE: OCSP and CSL

>The CSL which you describe seems to me like a subset of a CRL. 

This is my understanding of the matter too. I really don't like the
profusion
of acronyms for variants of the same structure. I have seen various
varieties
of CRL refered to by customers - ARL (as Authority revocation list and
Attribute
revocation list), XRLs (for cross certification), SRLs (Self signed
root), 
CCRLs (revocation lists for revocation lists), PRLs (Patented
proprietary 
revocation lists, OK I made the last one up but its funny).

I really don't think we should do anything to encourage more acronyms.

The idea of doing anything different with suspended certs is a bit wierd
methinks. If one is going to have a prayer of using suspended certs 
in the manner originally intended then all the junk certs had better be
in the same bag.

The big problem of suspended certs is unsuspension. Unless you are
paying 
for your PKI on a per cert issued basis rather than a per PKI seat basis
there really is not a lot of incentive to suspend rather than
aggressively
revoke and then selectively reissue.

Reversing a certificate suspension would be nice if if was likely to
work
reliably enough. I can imagine a specialist status processing server
(e.g.
OCSP) getting suspension right but the idea of end clients checking the
sigs on reams of CRLs to find out about unsuspension and getting it
right
is surreal.

There are relatively few cases in which authentication data needs to be
suspended (Alice is Alice as Ayn Rand followers would say). It tends to
be authorization data (Alice is allowed to log on) that tends to require
short term modification. Hence my interest in getting a handle on the
distributed authorization issue.

	Phill

---

From: Peter Williams <[email-masked]>
Date: Wed, 26 Jan 2000 16:42:54 -0800

RFC 2459 states, quite simply, the material quoted below. You 
can independently verify this assertion at:

ftp://ftp.isi.edu/in-notes/rfc2459.txt

Other important processing rules and related material may be 
found searching for the term "hold" in the RFC. For example

"(3) the certificate had not been revoked at time T and is not
         currently on hold status that commenced before time T, (this
         may be determined by obtaining the appropriate CRL or status
         information, or by out-of-band mechanisms)"

One can define new hold oids at will. The Open CA community
can invent its own if those of ANSI/PKIX are not suitable.

read the instructions on "id-holdinstruction-reject" in combination
with rule (3) (above) carefully.

Your CSL idea can  be fashioned today from a CRL, which uses the
CRL entry extension as specified in 2459, and which is
quoted below.

OpenCA will need to build its own code. The NSA-related toolkits do
not seem to support this particular element.

Peter.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Wednesday, January 26, 2000 10:36 AM
To: Massimiliano Pala
Cc: [email-masked]
Subject: Re: OCSP and CSL

Finally, I have to agree with Russ. I am not fond of suspension as a 
revocation declaration and since 2459 disparages use of this 
facility, I don't think we should spend lots of time on this issue.

Steve

RFC 2459:

"
5.3.2  Hold Instruction Code

   The hold instruction code is a non-critical CRL entry extension that
   provides a registered instruction identifier which indicates the
   action to be taken after encountering a certificate that has been
   placed on hold.

   id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 }

   holdInstructionCode ::= OBJECT IDENTIFIER

   The following instruction codes have been defined.  Conforming
   applications that process this extension MUST recognize the following
   instruction codes.

   holdInstruction    OBJECT IDENTIFIER ::=
                    { iso(1) member-body(2) us(840) x9-57(10040) 2 }

   id-holdinstruction-none   OBJECT IDENTIFIER ::= {holdInstruction 1}
   id-holdinstruction-callissuer
                             OBJECT IDENTIFIER ::= {holdInstruction 2}
   id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3}

   Conforming applications which encounter an id-holdinstruction-
   callissuer MUST call the certificate issuer or reject the
   certificate.  Conforming applications which encounter an id-

Housley, et. al.            Standards Track                    [Page 50]

RFC 2459        Internet X.509 Public Key Infrastructure    January 1999

   holdinstruction-reject MUST reject the certificate. The hold
   instruction id-holdinstruction-none is semantically equivalent to the
   absence of a holdInstructionCode, and its use is strongly deprecated
   for the Internet PKI."

---

From: Michael Myers <[email-masked]>
Date: Wed, 26 Jan 2000 19:03:27 -0800

Steve, Russ, Massimiliano:

I agree that CRL-based suspension warrants deprecation.  However, we should
not rush to deprecate the notion of certificate suspension in general.

In actual practice, OCSP is being used to achieve certificate suspension
through the use of a state variable in a CA's certificate management
database.  The practice is directly analogous to velocity management of
credit cards, calling cards and the like.

The state variable of a certificate suspected of being unreliable is set to
an equivalent of "revoked", leading to a "revoked" OCSP response.  If it is
ultimately determined that the certificate is reliable (e.g. it is in fact
the subscriber making all those online purchases), the state variable is
reset back to an equivalent of "good".  This achieves the effect of
suspension with no additional complexity.

This further illustrates the fact that OCSP deployments should not depend
upon CRLs.

Mike

> Sent: Wednesday, January 26, 2000 10:36 AM

. . . .

> >I was also thinking about the OCSP service: if I can remember well 
> >the possible states
> >for a given certificate can be Good/Revoked or Unknown only, right 
> >??? What about,
> >if there is not yet, adding a 'Suspended' state ???
> 
> I don't recall what OCSP says re suspended certs as a form of 
> revoked cert.
>

---

From: Ambarish Malpani <[email-masked]>
Date: Wed, 26 Jan 2000 21:18:14 -0800

Hi Massimiliano,
    Yes, you can indicate that a certificate is suspended
in OCSP - you return a status of revoked and in
singleExtensions, include a reasonCode extension, with a
CRLReason of certificateHold.

Hope this clarifies the issue.

Regards,
Ambarish

P.S. This extension is not explicitly mentioned in the draft, but we
do say that we support all CRL Entry Extensions (see section 4.4.5
of RFC 2560).

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043-1833

> From: Massimiliano Pala [mailto:[email-masked]]
> Sent: Tuesday, January 25, 2000 4:39 PM
> To: Russ Housley
> Russ Housley wrote:
> > Massimiliano:
> > I do not think that we should do anything to encourage CAs 
> to suspend
> > certificates.  This feature adds significant complexity to the whole
> > system, and we should discourage it's use.
> > 
> > Russ
> > 
> 
> You are right saying that adding complexity should be 
> discouraged, by the
> way I suggested them because we need something like that (I 
> am from the
> OpenCA project). Let me explain in more details why I think something
> similar could come in handy.
> 
> The CSLs, let's call them CSL to distinguish from CRLs, have 
> sense in env
> where there is a time gap between the 'request for cert 
> revoking' by the
> user and the effective revoking by the CA: this is obvious if 
> you consider
> structures where the main CA computer is disconnected from 
> any network.
> 
> Would you allow a certificate to be used when a user says it 
> could have
> been compromised ? You can not either say it is revoked 
> because it is not
> (CRLs do not report it) and there is no way to verify it till the new
> CRL is issued.
> 
> With some instrument like the proposed CSLs (that is only a 
> proposal, I am
> not saying it is the best or the only solution to the 
> problem, I am obviously
> open to EVERY comment... :-D and hopefully to some better 
> solutions) you can
> say, from the moment the user signals a danger the usage of 
> the certificate
> is compromised and that itself is to be considered in a 
> 'freezed' state.
> 
> Am I completely out of the target ? What do you think about 
> this problem ?
> Thanks for the comments you sent.
> 
> C'you,
> 
> 	Massimiliano Pala ([email-masked])
>

---

From: Simon Tardell <[email-masked]>
Date: Fri, 28 Jan 2000 17:26:19 +0100

> >I cannot find my smartcard... I suppose I left it at my friend's 
> >house, but I am not sure... So I ask for a suspesion of the service.
> >Then I go to my friend's house and I find my smartcard... so the 
> > certificate have never been in danger, I can ask the
> >CA Org not to revoke it and from the suspended state it returns to the
> > lid state.
> 
> 
[...]

> Revoking certificates and reissue sounds like an excellent solution to 
> is problem. The encryption key can be rolled over in the re-issued card,
> miniting new signing keys is never a problem.
> 
> I don't think that the change of the cert status back to 
> valid has much hope of being acurately and reliably tracked.
> Re-certificatrion is a slam dunk.

I don't quite agree. Reissuing a certificate for a smart card will always be
more of hassle than suspending/unsuspending. Not so much for the CA, but for
the user who needs to put his card into a reader capable of updating the
certificate on the smart card (assuming that the certificate is stored
together with the keys). Given that suspension/unsuspensions usually are
requested over phone, I don't think people would be happy with this.

Simon

Simon Tardell, Software Architect, iD2 Technologies
[email-masked], http://www.iD2tech.com/
voice +46 8 7755225, cell +46 70 3198319, fax +46 8 7267912
European IT-prize grand winners 1998 -- http://www.it-prize.org
AU-System Group Swedish IT-company of the year 1999

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 28 Jan 2000 13:22:34 -0500

>Sorry but there are several legislation in place (Italy and
>Germany at least) where it is clearly stated the only
>legally binding way to prove that a cert was not valid at a
>certain date is to provide a CRL (or a CSL!!!) that includes
>it.

This brings up two questions. The first is is there really any legislation
that talks about CSL's?

The second is really a set of them: what if the CA uses a different key to
sign CRL's?  What if the CA designates another entity to sign its CRL's?
What is special about a CRL that makes it the only valid proof? Suppose I
run a service bureau, acting as a CA for many companies. Suppose I partition
the CRL using CRLDP so that each company could only see their own revoked
certificates?  That wouldn't be legal?  If things were contested in a court
of law the CA would have to turn over its entire and complete CRL?

Yech. :)

---

From: Antonio Lioy <[email-masked]>
Date: Fri, 28 Jan 2000 19:20:19 +0100

Mike Young wrote:
> 
> >First of all OCSP is out of question is it is not a trust
> >source but rather a delivery channel for fast trust
> >information. For non-repudiation service, it needs to be
> >backed up by long-term data such as those of a CRL.
> 
> Please elaborate

Done in another mail.

> >Finally, I'd like to give my users the autonomous ability to
> >suspend and then re-activate their certificates. Let's
> >imagine the following scenario:
> >- I don't want to take my smart-card with me and I leave it
> >at the office (or I use a software PSE installed on my PC at
> >work)
> >- as I don't trust the company in charge of cleaning up the
> >office (or may be my co-workers), I'd like to suspend the
> >cert validity during week-ends, vacation, or even during
> >night hours
> >- I'd like to do this by just clicking on a button on a
> >secure Web page (with client authentication) or sending a
> >signed S/MIME message to an automatic responder
> >- the responder (or the Web server) could in turn provide me
> >with a one-time token to re-activate the cert at my will
>
> You can do that with OCSP, xcert has a vacation program.

Great! but for legal use you need to put that in a long term
archive.
 
> So every time a cert is Suspended, you want to add that to the CSL? and I
> assume you want this file issued frequently and signed by the CA? What if
> you have a CA with several million certs, the managment of a CSL will be a
> nightmare.
> The only way to create a scalable PKI that can last 10-15 years is with
> OCSP. CRL/CSLs are so 1980's :^)

May be CRL/CSL are so 80's, but OCSP is at most 90's  :-)
not 2000, in the sense that it is complete deregulation. But
how can I use OCSP to ask if a cert was valid 2 years ago?
in the request there is no way to specify the time for which
the check should be performed, so if I don't continuously
ask to the OCSP server the status of all certs (building my
personal CRL :-) I will never be able to prove revokation
status in the future.
OCSP is very much oriented to on-line short-lived
transactions, while CRL/CSL are more useful in an off-line
legal long-lived environment.

Best regards,

Antonio Lioy

---

From: Ambarish Malpani <[email-masked]>
Date: Sat, 29 Jan 2000 09:22:59 -0800

Hi Antonio,
    In an OCSP response, you can indicate that the status
of the certificate specified is valid as long as the certificate
has not expired before a particular date (check the ArchiveCutoff
extension).

If a server does has information going back 2 years, it can indicate
that in the response.

Hope this helps,
Regards,
Ambarish

> From: Antonio Lioy [mailto:[email-masked]]
> Sent: Friday, January 28, 2000 10:20 AM
> To: Mike Young
> Cc: [email-masked]

---

From: Ambarish Malpani <[email-masked]>
Date: Sat, 29 Jan 2000 09:29:44 -0800

Hi Antonio,
    Another minor nit-pick:

A CRL is not necessarily a "monotonically non-decreasing
list of revoked certificates". Nothing says that the list
needs to be sorted by serial number. There is work going on
in X.509, to define a CRL extension that can indicate that,
but this is not necessarily true about all CRLs.

Regards,
Ambarish

P.S. Whether a particular countries legislation allows you
to use an OCSP response as legal proof or not, would depend on
the legislators of that nation, but I would hope that legislators
would not get into the specifics of technologies used to do
things given the rapid change of technology.

A

> Sent: Friday, January 28, 2000 9:48 AM
> To: [email-masked]
> Brian Tvedt wrote:
> > If I was that concerned about misuse of my private key, I 
> would password protect
> > it.  This seems much superior to relying on a complicated 
> mechanism (CSL) being
> > correctly implemented in every security application out there.
> 
> My private key IS password-protected, and nonetheless I
> could fear its misuse should I forget it around. This fear
> is even greater in Public Administrations with automatic
> signature servers. Since the law explicitly states that such
> servers sign on behalf of a real person, this guy has a real
> fear to be held responsible for signatures emitted during
> non-working hours. And as these servers typically use a
> crypto board, it is not that easy to disable it (could be
> used for SSL support too).
> 
> Revoking and issuing new certs is a real trouble, especially
> when a smart-card (Or crypto board) with one-time on-board
> private-key generation is involved.
> 
> Perhaps I have the wrong understanding of the Hold code in a
> RFC-2459 conformant CRL. I could not find a clear definition
> of how is a certificate "temporarily suspended" and yet
> placed in a CRL. In my understanding, a CRL is a
> monotonically non-decreasing list of revoked certificates.
> There is no way to state that a cert is valid again. Issuing
> another cert for the same key is simply not possible in
> certain environments.
> Either a CRL is augmented in meaning to be a list of invalid
> certs within specific timeframes (i.e. invalidity start -
> invalidity end, the latter being infinite for truly revoked
> certs), or a separate concept has to be created: CSL.
> 
> OCSP can then be the vehicle to convey punctual information
> about a cert status, but given teh current legislation in
> several countries, CRLs (and may be CSLs) have to be
> produced and archived for legal use.
> 
> Antonio Lioy
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 31 Jan 2000 11:22:57 -0500

>L> lid state.

I cannot agree.  The use of suspend adds considerable complexity to both 
the infrastructure and the relying parties, regardless of the revocation 
mechanism used (OCSP, CRLs, whatever).  The provision of non-repudiation is 
also made much more complex.

If a user forgets their smartcard at a friends house, then the PIN/password 
for that smartcard should prevent misuse.  If the user stored her 
PIN/password with the smartcard, then the certificate should be revoke 
permanently.

Russ