Subject: RE: Timestamping + Cert revocation + revocation question

From: "Manger, James H" <[email-masked]>
Date: Thu, 5 Sep 2002 10:03:47 +1000

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

This is already supported -- see X.509 (2000) section 8.2.2.5 Private key
usage period extension (or section 4.2.1.4 of RFC 3280].

The private key usage period extension (privateKeyUsagePeriod) indicates the
period of valid use of the private key.

The validity field "is the time interval during which the CA warrants that
it will maintain information about the status of the certificate" [X.509,
section 7].

Revocation info is maintained today for what you call the "2nd Validity
Period", it is just that the first is rarely specified.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 5 Sep 2002 15:05:26 +1200 (NZST)

>usage period extension (or section 4.2.1.4 of RFC 3280].

Isn't that deprecated though (or at least it was in 2459)?  I've never
understood why, it seemed like a marvellously useful extension to me.

Peter.

---

From: "Tom Gindin" <[email-masked]>
Date: Fri, 6 Sep 2002 17:34:13 -0400

Actually, there is no reason to mandate PKU Period in general, just
to recommend it on NR certificates (and probably CA and CRL certificates as
well).  Like Peter, I have never understood why that extension was
deprecated.

            Tom Gindin

Denis Pinkas <[email-masked]>@mail.imc.org on 09/05/2002 09:19:29 AM

Sent by:    [email-masked]

To:    Marc Jadoul <[email-masked]>
cc:    [email-masked]
Subject:    Re: Timestamping + Cert revocation + revocation question

Marc,

(...)

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

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

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

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

(...)

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

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

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

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

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

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

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

> Hope I was readable....
> Best regards,
> Marc

---

From: Peter Williams <[email-masked]>
Date: Mon, 09 Sep 2002 10:08:57 -0700

The various signature laws are written with the assumption
that a seperate record management infrastructure keeps the
assurnace of strong authentication uptodate.

Attmepting to remove the obligation to manage records from 
digital signature frameworks, using technical tricks, is 
really going against the legal framework now in place.

I cant the community that got the legal frameworks established 
reformulating their model.

Its much easier (and this is what counts for the American
market) for users to manage a cheap, trusted message store and
storage medium, then solve a global infrastructure and policy 
problem. Auditors require users to maintain records, anyway.

At ValiCert, we never see any real demand for OCSP features
that provided for historical validation, for example. Folks
do integrate the trusted audit log however, signing the
log files of the validation server as evidence of 
proper authentication. Cheap, easy, natural.

BTW, VISA has a patent on some of this area, based on
work we did in root key handling during the SET committe work
in 1995. SET had specific rules on private and public key 
verification periods, and these rules were important
to the proof-of-possesion (card present) service.

-----Original Message-----
From: Michael Fritscher

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.