Subject: Timestamping + Cert revocation + revocation question

From: "Marc Jadoul" <[email-masked]>
Date: Tue, 3 Sep 2002 12:55:48 +0200

Hi,

I probably misunderstood something and I have a small question about how to 'invalidate' a certificate that has already expired.
Here is a simple scenario:
User A get controle on a certificate certifying User B. It create a signature in the name of user B. It then timestamp this signature.
Now User B do not know this. The certificate expire and it is not possible to revoke it anymore (right?).
The time-stamped signature is thus valid and I do not know any mean to communicate that the certificate was wrong from the begining. Any relying party will continue to accept the time-stamped signature, even if User B and the CA now know the there was a problem with the certificate at the time of the signature.
Does it exist some way to communicate that a certificate was invalid from a specific date, even if it is known only after expiration of the certificate?

How to invalidate a timestamped signature? In the real world you would destroy it but here, it can perfectly be duplicated.

Marc Jadoul

---

From: "Marc Jadoul" <[email-masked]>
Date: Tue, 3 Sep 2002 15:23:45 +0200

Sorry to annoy everybody. The original subject was wrong, and I suppose that I need to correct it if I want a response :-/
Marc
  ----- Original Message ----- 
  From: Marc Jadoul 
  To: [email-masked] 
  Sent: Tuesday, September 03, 2002 12:55 PM
  Subject: Timestamping + Cert revocation + revocation question

  Hi,

  Marc Jadoul

---

From: "Marc Jadoul" <[email-masked]>
Date: Wed, 4 Sep 2002 14:39:45 +0200

Hi,

Yes I agree with you, User B can apply to the court. He might win, and the
court might decide that any signature made with this key/cert after a
defined date is invalid.
But what seems wrong to me is that there is no technical way (like CRL for
expired certs) to communicate to any third party this fact and any one will
continue to accept signature made with this key/cert because the (expired)
cert can not be revoked anymore.

Marc Jadoul
----- Original Message -----
From: "Esposito Alfredo" <[email-masked]>
To: "Marc Jadoul" <[email-masked]>
Sent: Wednesday, September 04, 2002 11:22 AM
Subject: Re: Timestamping + Cert revocation + revocation question

> Hi
> that is something weird in your scenario. In order to sign a document
> user A should control the private key of user B. The certificate alone
> is not enough to sign anything. In the legal system of  the countries
> introducing digital signature, the revocation status applies after the
> publication of a CRL. Before this publication user B can not repudiate
> his signature. Of course, User B can apply to the court. Depending on
> the kind of storing the private key (smart card, floppy, hard disk...)
> and all the other factors, the court will decide about the legal
> effects of the claimed forged signature.
>
> Alfredo Esposito
> InfoCamere SCpA
> Digital Signature
> Via Morgagni 30H
> 00161 Roma
> Italy
>
>
> Marc Jadoul wrote:
>
> > Hi,
> >
> >
> >
> > I probably misunderstood something and I have a small question about
> > how to 'invalidate' a certificate that has already expired.
> >
> > User A get controle on a certificate certifying User B. It create a
> > signature in the name of user B. It then timestamp this signature.
> >
> > The time-stamped signature is thus valid and I do not know any mean to
> > communicate that the certificate was wrong from the begining. Any
> > relying party will continue to accept the time-stamped signature, even
> > if User B and the CA now know the there was a problem with the
> > certificate at the time of the signature.
> >
> > Does it exist some way to communicate that a certificate was invalid
> > from a specific date, even if it is known only after expiration of the
> > certificate?
> >
> >
> >
> > How to invalidate a timestamped signature? In the real world you would
> > destroy it but here, it can perfectly be duplicated.
> >
> >
> >
> > Marc Jadoul
> >
>
>
>

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 04 Sep 2002 14:46:39 +0200

Marc,

[Next time, please use text editing, instead of HTML editing]

> Hi, I probably misunderstood something and I have a small question about

Quite a strange formulation.

> User A get controle on a certificate certifying User B. It
> create a signature in the name of user B. It then timestamp this
> signature.Now User B do not know this. The certificate expire and it is
> not possible to revoke it anymore (right?).

RFC 3280 states:

   An entry MUST NOT be removed from the CRL until it appears on one 
   regularly scheduled CRL issued beyond the revoked certificate's 
   validity period.

This is a minimum condition. 

RFC 3125 states:

B.8.3  Timing Constraints - Caution Period

   Before an electronic signature may really be valid, the verifier has
   to be sure that the holder of the private key was really the only one
   in possession of key at the time of signing.  However, there is an
   inevitable delay between a compromise or loss of key being noted, and
   a report of revocation being distributed.  To allow greater
   confidence in the validity of a signature, a "cautionary period" may
   be identified before a signature may be said to be valid with high
   confidence.  A verifier may revalidate a signature after this
   cautionary signature, or wait for this period before validating a
   signature. The validation policy may specify such a cautionary period.

This would mean that the CA should continue, at least, to make available
the revocation status information until the end of the cautionnary period.
However, there are two problems:

  1) the CA is ignorant about the duration of the various cautionary
     periods from the various signature/validation policies.  
  
  2) unless using the CPS, the CA has no way to indicate how long after 
     the end of the certificate validity period, it will maintain the 
     revocation status information ... and the CPS is not directly machine 
     processable.

> The time-stamped signature is
> thus valid and I do not know any mean to communicate that the certificate
> was wrong from the begining. Any relying party will continue to accept the
> time-stamped signature, even if User B and the CA now know the there was a
> problem with the certificate at the time of the signature.

Whether or not the certificate has expired, a user who does not know that
his private key has been compromised may be issuing "valid" signatures
without knowing it.

In a CRL, it is possible to include an invalidity date that provides the
date on which it is known or suspected that the private key was compromised.
This date may be earlier than the revocation date in the CRL entry.
 
However, any CRL fetched soon after the cautionary period is sufficient to
prove that the signature was valid. So a fresher CRL would not
help to declare the signature invalid if it is issued after the end of the
cautionary period. The only advantage would be that the CA would have an
information about a user declaration of an invalidity date, maybe sooner
than the time included in the time-stamp token.

> Does it exist
> some way to communicate that a certificate was invalid from a specific
> date, even if it is known only after expiration of the certificate? How to
> invalidate a timestamped signature? 

You seem to be looking for a user declaration of an invalidity date and
since the CA will not care about an expired certificate, you wonder where
and how this declaration could be done.

There are two possible answers to your question:

1) Extend the time period during which the revocation information is
   both handled and maintained and indicate the end of that period using 
   a new (non-critical) CRL extension. That time should be superior to the 
   cautionary period from the signature policy or the validation policy. 
   This would cover the cautionary period.

2) Beyond the end of the cautionary period, since anyway this declaration 
   will not be "visible" in the CRL used to validate the signature 
   (and picked during the cautionary period), it does not matter where that 
   declaration will be made. Today someone having his car robbed will make 
   a declaration of robbery to the police. The same happens with door keys. 
   Maybe, in the future, some people will make a declaration of loss for 
   a private key to the police.

Regards,

Denis

> In the real world you would destroy it but here, it can perfectly be duplicated.

---

From: "Marc Jadoul" <[email-masked]>
Date: Wed, 4 Sep 2002 17:50:28 +0200

Thanks Denis.
It is interresting.
I effectivelly think that for qualified cert and signature with a legal
value, CRL should be maintain during the same period than the validity
period of signatures. Thus archiving CRL for 20-30 years it not really
enought, we should also maintain them during this period: we should be able
to 'revoke' certs after expiration.
By adding Timestamping to PKI that was originaly foreseen for realtime
authentication, we add additional complexity and the original PKI design
show their limits. The Validity Period in a certificate means originally
that the certificate could be accepted in realtime during this Validity
Period. Thus it was logical to maintain CRLs only during this period. But
know that a certificate could be accepted long after his expiration,
revocation information should be maintain during the whole life of the
certificate. And the Validity Period of the certificate only concern the
time where the action is done, not anymore the time where the action is
verified.
May be we should have 2 Validity Period in the certificate: one for when the
cert can be used to sign and the other when the cert can be used for
verifying. Revocation Info should be maintain during the 2nd Validity Period
and not the first as today.
Best Regards,
Marc

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 05 Sep 2002 09:31:06 +0200

Marc,

> period of signatures. 

This sentence may be quite confusing. CRLs shall be kept by a verifier
during the same period than the validity period of the signature. However,
the CA is not concerned with any archiving of CRLs during such a time frame.

> Thus archiving CRL for 20-30 years it not really enought, we should also 
> maintain them during this period: we should be able to 'revoke' certs 
> after expiration.

At most, during a reasonable cautionary period, e.g. one month.

> certificate. 

No. See above.

> And the Validity Period of the certificate only concern the

No.

> verifying. 

We have this in X.509, but not in RFC 3280. This is the private key usage
period extension.

Using it, would mean that the period of use of the private key would be, let
us say, one month shorter than the period of use of the public key. So the
digital signature would then need to be time-stamped before the end of the
private key period. In this way revocation will still be handled one month
after.

Whatever way we are looking to this problem, revocation needs to be handled
a few weeks after the use of the private key. Since it is impossible to know
exactly when the private key has been used, an upper limit is used instead
by using the date included in a time-stamp token over the digital signature.

> Revocation Info should be maintain during the 2nd Validity Period and not the first as today.

This is one possibility, as explained in details above.

In order to solve nicely this issue, there is a need to add extra
information "somewhere".

1) One possibilty is to use the private key usage period extension 
   in a public key certificate.

2) Another possibility would be to use the Archive Cutoff extension defined 
   in RFC 2560 (OCSP) in section 4.4.4. The only problem is that we do not 
   have the equivalent for CRLs.

Since the later solution would not increase the size of the certificate, 
this would have my preference.

In RFC 2560, Archive Cutoff is introduced as follows:
 
   An OCSP responder MAY choose to retain revocation information beyond
   a certificate's expiration. 

For CRLs, it would be introduced as follows:

   A CRL Issuer MAY choose to retain revocation information beyond
   a certificate's expiration. 

Regards,

Denis

---

From: "Marc Jadoul" <[email-masked]>
Date: Thu, 5 Sep 2002 11:48:53 +0200

Thanks to you all for your responses.
I put all my comment in this email instead of responding to Peter Gutmann,
James Manger and you in 3 emails.

----- Original Message -----
From: "Denis Pinkas" <[email-masked]>
To: "Marc Jadoul" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, September 05, 2002 9:31 AM
Subject: Re: Timestamping + Cert revocation + revocation question

> the CA is not concerned with any archiving of CRLs during such a time
frame.

I am not a legal guy and yes I am probably mixing several issues. But, I
know that ETSI TS 101 456 v1.2.1 require the CA to archive a lot of
information. See point 7.4.11 e) saying that "Recording concerning qualified
certificates shall be held for a period of time as appropriate for providing
necessary legal evidence in support of electronic signature."
I thought that this would imply that CRLs need to be archived for a very
long time.

> At most, during a reasonable cautionary period, e.g. one month.

Humm...

> > revocation information should be maintain during the whole life of the

... cut ...

>    a certificate's expiration.

I removed the rest of the discussion.
I agree with you and James Manger that the "private key usage period
extension" is a response to my concern.
I agree with Peter Gutmann that I do not understand why it is recommanded to
not use it (yet or anymore?) in PKIX.
I disagree with your second proposition, as I prefer an extension in the
certificate than in the OCPS response or CRL. If you look at traffic, OCSP
and CRLs are downloaded from a few points in the network while certificate
eventually follow the signature. CRLs and OCSP traffic can become really
large if you talk about CAs of more than 10000000 users.
If you take into account the fact that you might need to archive CRLs for 20
years, you will prefer to have them small, right? So this extension could be
OK for OCSP but please do not add too much to CRLs which might need to be
reissued every 6 hours and archived for 20 years!
Additionnally, as a CA we would propose OCSP but still issue CRLs. Thus
again duplication of the info!
One more argument: the private key usage period extension is really a
property of the key/certificate, not of the revocation. You want to
implement in client application the logic for not using the key anymore
after it expire, you won't use OCSP to check that.
One last argument: it exist already, we just could make it a PKIX standard.

Hope I was readable....

Best regards,

Marc

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 05 Sep 2002 15:19:29 +0200

Marc,

(...)

 

> I thought that this would imply that CRLs need to be archived for a very

 ... but they will not be accessible to the public.

(...) 

> > 2) Another possibility would be to use the Archive Cutoff extension
> >    defined in RFC 2560 (OCSP) in section 4.4.4. The only problem 
> >    is that we do not have the equivalent for CRLs.

 

> large if you talk about CAs of more than 10000000 users.

This is not an argument since CRLs or OCSP responses are needed anyway. 

> years, you will prefer to have them small, right? 

Compared to the size of the CRL, the addition will not be noticeable.

> So this extension could be

> One last argument: it exist already, we just could make it a PKIX standard.

The solution would be technically correct, but it would mandate the presence
of the private key usage period extension. 

:-(

Also it would not mimic current situations with credit cards, where a new
credit card is received one month before the expiration of the current one,
but during that month any of them can be used.

There is anyway a solution to this problem which does not require any
extension. Under a given CP, a CA may say that its CRL Issuers continue to
handle revocation one month after the end of the certificate validity
period. This does not scale worldwide, but it works as soon as the CPs to be
accepted are known by verifiers, which is mostly the case.

An extension in the CRL would make it scalable. Now, if in practice every 
CA is fixing the time after which revocation continues to be handled to 
6 weeks, is that extension in a CRL really needed ? 

Finally, if a CA is only using OCSP responders, the solution already exists.

Regards,

Denis

---

From: "Marc Jadoul" <[email-masked]>
Date: Thu, 5 Sep 2002 17:09:47 +0200

Hello Denis,

I do not know if the problem of the credit card is the same as the one of
legally valid signature and qualified certificates I was tinking about.

(...)

>  ... but they (archived CRLs)  will not be accessible to the public.

We are still talking about TByte of CRL's data to archive and Gbit/s of
bandwidth for relying party to download the last CRL. In fact, do you intent
to add the extension as a CRL entry extension or a global CRL extension? For
me the private key validity period depend of the lenght of the private key
of the user and thus is probably a CRL entry extension. That mean that you
might have an CRL entry which is 50% bigger. Instead of having 1TB you would
need 1.5TB of storage and same caculation can be done for needed bandwidth.

(...)

> This is not an argument since CRLs or OCSP responses are needed anyway.

See above. I would like to minimize the bandwidth/storage needed for a CA,
thus price/certificate.

(...)

> Compared to the size of the CRL, the addition will not be noticeable.

See above: depend if you talk about a CRL Entry Extension or a CRL
Extension.

(...)

> but during that month any of them can be used.

I do not completly understand this. Couldn't you have the new private key
valid 1 month before the old private key expire?
Obviously, you are talking of maintaining the CRL for 1 additional month
after expiration of a private key himself usable for (5 years + 1 month)
(credit card model) while I think in term of qualified certificates with a
private key usable during (5 years + 1 month) and maintaining revocation
info for 20 years for instance.

> Finally, if a CA is only using OCSP responders, the solution already
exists.

May be like nice technical solutions too much.

Kind regards,

Marc

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 05 Sep 2002 17:42:02 +0200

Marc,

> to add the extension as a CRL entry extension or a global CRL extension? 

A global CRL extension. Look at the definition archive cutoff in RFC 2560.

> For me the private key validity period depend of the lenght of the private 
> key of the user and thus is probably a CRL entry extension. That mean that 
> you might have an CRL entry which is 50% bigger. Instead of having 1TB you 
> would need 1.5TB of storage and same caculation can be done for needed 
> bandwidth.

We are not talking of a private key validity period, and we are not
discussing key length strengths for a period of one month.
 
> > credit card is received one month before the expiration of the current
> > one, but during that month any of them can be used.
> 

Yes, but during this period the signer could use any of them.

> (credit card model) 

Yes.

> while I think in term of qualified certificates with a

Revocation information needs to be captured close to the time the signature
is issued to make sure that the signature is valid. The intent is NOT to ask
the CRL issuer to keep that information for 20 years.
 
> > period. This does not scale worldwide, but it works as soon as the CPs to
> > be accepted are known by verifiers, which is mostly the case.
> >

Let us wait for the opinion of others.

Regards,

Denis

---

From: David Hopwood <[email-masked]>
Date: Thu, 05 Sep 2002 20:09:19 +0000

-----BEGIN PGP SIGNED MESSAGE-----

Denis Pinkas wrote:
> > Thus archiving CRL for 20-30 years it not really enough, we should also

How long revocation needs to be possible for depends on the meaning of the
certification. For example, in the case of code signing, a certificate carries
the implication that (someone says that) the principal should be trusted to
sign only secure code - that is, code that cannot be exploited, as well as not
being itself malicious. The fact that a principal has been signing flawed code
(intentionally or not) can discovered at *any* time. The certificate should
therefore be able to be revoked at *any* point in its lifetime, independent of
the use of timestamping.

Some people might argue that the revocation mechanism was never intended
to be able to handle anything other than the compromise of private keys.
Regardless, revocation is assumed in many protocols to be a way of
"taking back" a certification for any reason at all.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 09 Sep 2002 15:42:57 +0200

David,

> therefore be able to be revoked at *any* point in its lifetime, independent of

Revocation is independant from timestamping.
 
Any certificate is revokabled at *any* point in its lifetime.

When time-stamping is used, signatures done prior to the revocation time
continue to be valid, if the time-stamp token was applied before the
revocation time.

When time-stamping is *not* used, signatures done prior to the revocation
have to be considered as invalid, unless ther timeliness can be demonstrated 
using other means.

Regards,

Denis

> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3i
> Charset: noconv
> 
> iQEVAwUBPXe5uTkCAxeYt5gVAQEWGgf/VteAjKGLOFc0o9TlR+NGjU7FC6JPuUKs
> Co3lm3OtzsHGdQIdNFtDAGZE0VfmpVvjXgKTxbLoDBYOtn80nMfLR7qnNL6jHRyb
> YiCJYE3sCQViP4K+rgAhDMnwoV1yA7dc7RrkQ8i5shlD5721rWnmL+D80TY/M9X6
> 4dUskeyjWfB+7jv8pqeFGNXJIOSBMvStAESDjm4MgMcwdkvLAUqSdrc0pUXLqe+1
> YfhJHsNlmi/shu0ezLFJ2iHQ5fJ9zUMDgjXcgviqSD5Yej5wJy/6DoX3236iSYfC
> wnvst5rYOJlXo3AludfjuuCIJwungn5U4Q8a5mIB76FqRyNqL6whsw==
> =T2ae
> -----END PGP SIGNATURE-----

---

From: Michael Fritscher <[email-masked]>
Date: Mon, 09 Sep 2002 15:59:53 +0200

I am working on a thesis on signatures that can be validated over a
long period (similar to the 20 to 30 years mentioned here before).

I now went through the whole thread and got the impression that the
point behind the problems discussed in this thread is that you want to
have different validity periods for the use of the private key and the
use of the public key (correct me if I got that wrong).

IMHO there is no "technical" reason for having different validity
periods. If you can afford to extend the validity period for the
public key (in order to be able to verify a signature/certificate
after the certificate has expired), I see no reason why you could not
extend the validity period of the private key as well.

As I have seen it till now, the only way to be able to verify a
signature is to have some valid (at the time of verification)
certificate for the private key that was used to sign a time-stamp on
another timestamp (or signature combined with a timestamp) valid at
the time of timestamping and so on... This way you get a chain of
trust over time and keep the signatures verifyable.

Michael Fritscher
Any way, at least one valid signature over the rest is necessary.

I am aware of the fact that a chain of trust over time does not
address the problem of handling the verification of signatures whose
private key has been revoked after the signing time.