Subject: Re: OCSP and CSL

From: "Juan Rodriguez-Torrent" <[email-masked]>
Date: Tue, 1 Feb 2000 00:54:57 -0500

Russ, I cannot agree more. I'm just trying to figure out if these are real
customer requirements or some folks in a glass house tinkering with
possibilities.

JRT
----- Original Message -----
From: Russ Housley <[email-masked]>
To: <[email-masked]>
Sent: Monday, January 31, 2000 11:22 AM
Subject: RE: OCSP and CSL

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

---

From: Antonio Lioy <[email-masked]>
Date: Wed, 02 Feb 2000 09:46:27 +0100

> customer requirements or some folks in a glass house tinkering with

Sorry but I'm quite serious. Although I'm a university
professor, I'm also a practical engineer and I'm not sitting
in a glass house tinkering with possibilities. We are
actively developing a PKI here in Italy and we have
requirements from partners. One of them asked us for
suspending the cert validity associated to a signing engine
that cannot be easily removed from the host, because that
engine should operate only during the physical presence of
the person legally in charge of the signature.
I know that the easiest solution would be to switch off the
machine (and to physically secure it so that nobody can
switch it on) but that cannot be done because the machine
offers other services too. In turn, you could suggest to
duplicate the machine. But I was wondering if there was
nothing simpler like just suspending the certificate. If it
turns out that suspension is a nightmare, fine: I'll suggest
to duplicate the machine, switch it off, and lock it.
But wait a moment: the italian law requires every legally
binding CA:
- to mantain a "signed list of revoked certificates" (they
do use the world CRL and refer to the ISO standard)
- to mantain a "signed list of suspended certificates" (they
do use the world CSL, but they don't define it)
- to permit inquiries over the net to those lists (they
don'use the world OCSP or CRL/CSL distribution over HTTP or
FTP)
so there are lots of CAs here in Italy that are inventing
their own format for CSL.
I just wanted to investigate if teh it was given enough
thoughts to certificate suspension.

I'm mildly unsatisfied of the recent discussion over this
list. It appears that everybody is against certificate
suspension, given its associated cost. I think that, when
speaking technically, we should abide from the associated
costs of operation, because those costs are quite sensitive
to the perceived needs from the users (otherwise we would
never define or adopt strong security measures because they
are surely too expensive :-)
Moreover, some mails suggest to use CRL with the OnHold
reason for suspension, and later remove the certificate if
it is not actually revoked. What??? I have some really bad
feeling about this solution because my understanding is:
1. "revoked" means revoked, i.e. the cert is no more valid
for any use starting from a certain date
2. once a cert is inserted into a CRL, it can *never* be
deleted from it 
If these principles are not true, then please change the
name of CRL to something else, as it doesn't store revoked
certs but temporarly invalid certs. There is nothing more
bad about a standard than using words in a counterintuitive
way.
I ASK FOR A FINAL AUTHORITATIVE WORD HERE: POINT 1 AND 2 ARE
TRUE OR NOT?

Someone advocates more extended usage of OCSP. Apart from
the same terminology issue (the "revoked" status that may be
returned from OCSP doesn't actually mean revoked, hey we are
all joking! if the secondary code is OnHold, check later and
may be it was actually revoked or not) I dislike this
approach because it applies only to on-line transactions: if
I receive a transaction request, then I check the status of
the requesting cert with OCSP and I store the signed answer
as a proof. But there are organizations that want to be
*autonomously* able to perform checks about cert validity at
a certain point in time. Currently, they periodically
request CRLs from their trusted CAs and store them locally.
So even in the case the CA vanishes, they have their own
proof.

Given these considerations, I'm here advocating the
technical need for some kind of "cert history". For example,
we could extend CRLs (to become a CRSL) to allow each entry
to represent a certificate that has been revoked or
suspended at least once (so, no need to insert good
certificates that expire for natural reasons) and to append
a list of suspension periods.
For example:
   CERT #123
   suspended from 14-jan-2000 17:30 GMT+1 to 17-jan-2000
09:00 GMT+1
   suspended from 21-jan-2000 17:30 GMT+1 to 24-jan-2000
09:00 GMT+1
   revoked on 02-feb-2000 09:02 GMT+1
That would allow anybody to locally store data and be able
to always verify (even offline or in the future) the
validity of the certs issued by a certain CA.

Thanks for your attention.

Antonio Lioy

---

From: Camillo Särs <[email-masked]>
Date: Wed, 02 Feb 2000 12:45:36 +0200

Antonio Lioy wrote:
> One of them asked us for suspending the cert validity associated to a 
> signing engine that cannot be easily removed from the host, because that

In that case you are confusing authentication and authorization.  I suggest
considering authorization certificates for this.  They can be very
short-lived and are easy to revoke.  Of course, they are also at least
somewhat controversial at this point.

Suspending the binding between a name and a key is unintuitive, and really
doesn't make sense.  I think you are trying to impose unwanted semantics on
identity certificates!

Regards,
Camillo Särs
-- 
Camillo Särs <[email-masked]>       http://www.iki.fi/ged/
Researcher, Crypto Research                    http://www.F-Secure.com/
F-Secure Corporation   (formerly Data Fellows Corporation)
   F-Secure products: Integrated Solutions for Enterprise Security

---

From: Irene Gassko <[email-masked]>
Date: Wed, 02 Feb 2000 06:26:57 -0500

At 09:46 AM 02/02/2000 +0100, Antonio Lioy wrote:
>[snip]

If we look for a real world analogy here, I would expect that it
would be instructive to see how credit card companies handle it.
Most will close your account forever, but when I called AMEX
and asked them to close my account, they told me that within
a year I could reopen it if I changed my mind. Hence this is at
least debatable.

>2. once a cert is inserted into a CRL, it can *never* be

This is not true. Expired certificates are deleted from CRL.

[snip]
>validity of the certs issued by a certain CA.
This could be useful for archiving purposes.

Irene

>Thanks for your attention.
I
----------------------------------------------------------------------------
-------------------------------------------------------
Irene Gassko			 Bell Laboratories		http://www.lucent.com
Lucent Technologies		Secure Technologies Dept.
1600 Osgood Street			 phone:	(978) 960-5767
Room 30-2-A31			 e-mail: 	[email-masked]
N. Andover, MA 01845		 fax: 	(978) 960-3240

---

From: Antonio Lioy <[email-masked]>
Date: Wed, 02 Feb 2000 12:51:06 +0100

> This is not true. Expired certificates are deleted from CRL.

I disagree. A revoked cert MUST remain in the CRL even after
its expiration date, because I may be willing to check if
the cert was valid at some point in time before its natural
expiration. That's why in a previous mail I said that that
the size of a CRL is "monotonically increasing": you only
add revoked certs to the CRL, and NEVER delete them, not
even after their expiration.
That's one of the major differences between CRL and OCSP:
CRL are the history of all revoked certs by a certain CA,
while OCSP offers information only for the "current" time
slot (unless the OCSP server supports extensions to also
look back at the history of the certs).

> This could be useful for archiving purposes.

That's exactly one of my points.

Cheers,

Antonio Lioy

---

From: Mirko Tedaldi <[email-masked]>
Date: Wed, 02 Feb 2000 12:58:01 +0100

>This is not true. Expired certificates are deleted from CRL.

If I delete expired certificates from CRLs, I could have troubles to verify 
"historical" signatures. Actually, how can I know if a digital signature 
corresponds to a certificate that was valid at the moment of signing and 
now is expired or it corresponds to a revoked certificate?
I think this matter can happen when you verify old signatures.

Is it right?

Mirko Tedaldi.

---

From: Joerg Seidel <[email-masked]>
Date: Wed, 02 Feb 2000 13:39:41 +0100

> I think this matter can happen when you verify old signatures.

Yes, it's a problem. Even if there is a timeAttribute inside of the signature,
you can not trust this time anymore in case of an expired or revoked
certificate. You have to apply a time stamp to the signature after its
generation in order to preserve it's validity after the certificate expiration.
This is the only way to prove that the signature was made prior
revokation/expiration. Btw: This applies to the CRL-signature too.

timeproof has developed a secure hardware based Time Signature System for this
purpose. You are welcome to have a look to our web pages or visit us at CeBIT.

Best regards,
Jörg Seidel
--
timeproof Development                   phone  +49-40-76629-1911
Harburger Schloßstraße 6-12             fax    +49-40-76629-551
D-21079 Hamburg                         mailto:[email-masked]
Germany                                 http://www.timeproof.de

      + + + timeproof CeBIT 2000 Hall 23 Stand A22/14 + + +

---

From: Massimiliano Pala <[email-masked]>
Date: Thu, 03 Feb 2000 13:34:58 +0100

> This is not true. Expired certificates are deleted from CRL.

I am not sure about this. If you delete it from the list how you can
prove it is not valid from the revokation date on ??? The CRLs should
provide an 'history' of all revoked certificates...

C'you,

	Massimiliano Pala ([email-masked])

---

From: Joerg Seidel <[email-masked]>
Date: Thu, 03 Feb 2000 14:12:22 +0100

> provide an 'history' of all revoked certificates...

In order to prove the invalidity of a certain signature you need the CRL of
the point of time the signature was made. Well, more precisely the CRL which
was released next after the signature was made. If you want to be able to
prove the validity of a signature after the expiration date of the
corresponding certificate you need to store this CRL together with the
signature. Well and you need to prove the validity of the
CRL-Signing-Certificate at that time, so you need ... and so on until you are
got a CRL signed with a private key corresponding to a non-expired and
non-revoked certificate.

I just realized: Maybe there is a small security flaw in this system: If a
certificate gets revoked just before certificate expiration, but the next CRL
is released after the expiration time, the revocation might not been stated in
CRLs at all. The state of the signature is unknown.

Jörg Seidel
-- 
timeproof                               phone  +49-40-76629-1911
Development                             fax    +49-40-76629-551
Harburger Schloßstraße 6-12             mailto:[email-masked]
D-21079 Hamburg                         http://www.timeproof.de

---

From: Mirko Tedaldi <[email-masked]>
Date: Thu, 03 Feb 2000 15:25:43 +0100

>CRLs at all. The state of the signature is unknown.

I don't think it is a flaw. A revoked certificate must be always issued in 
CRLs, even if it is expired at the moment of issuing CRL. Actually, RFC 
2459 states that a exipired certificate may be removed just "after 
appearing on one regularly scheduled CRL."

Mirko Tedaldi.

---

From: "Robert Rowland" <[email-masked]>
Date: Thu, 3 Feb 2000 09:03:11 -0800

Is it possible that these problems be divided into two different needs:
1) real time authentication-> vpn technologies,
2) long term authentication->wills, contracts,....

The need for verification of valid certs three years ago sems moot if the
purpose is/was used for corporate remote dial-in,
versus the need to assure that my signature on my will is not used to give
Anna Nicole
Smith any more money.

?????

-----Original Message-----
From: Joerg Seidel [mailto:[email-masked]]
Sent: Thursday, February 03, 2000 5:12 AM
To: Massimiliano Pala
Cc: [email-masked]
Subject: Re: OCSP and CSL

> provide an 'history' of all revoked certificates...

In order to prove the invalidity of a certain signature you need the CRL
of
the point of time the signature was made. Well, more precisely the CRL
which
was released next after the signature was made. If you want to be able
to
prove the validity of a signature after the expiration date of the
corresponding certificate you need to store this CRL together with the
signature. Well and you need to prove the validity of the
CRL-Signing-Certificate at that time, so you need ... and so on until
you are
got a CRL signed with a private key corresponding to a non-expired and
non-revoked certificate.

I just realized: Maybe there is a small security flaw in this system: If
a
certificate gets revoked just before certificate expiration, but the
next CRL
is released after the expiration time, the revocation might not been
stated in
CRLs at all. The state of the signature is unknown.

Jörg Seidel