Subject: RE: large crl's

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 20 Sep 2006 06:48:50 -0700

If you want to have an archival capability knowing the revocation status of expired certificates is an essential operational capability.

If the CRL does not have that information it is not an appropriate technology for that application.

In a messaging environment you are very likely to want archival capabilities and in particular the ability to query the status of the certificate on a particular day.

For SSL it does not matter as the only status that matters is current status.

If Ben Franklin had signed the US constitution with a digital signature people would probably want to know if it was still valid after his certificate had expired.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stephen Kent
> Sent: Tuesday, September 19, 2006 8:56 PM
> To: Christine Karman
> Cc: Kemp David P.; [email-masked]
> Subject: RE: large crl's
> 
> 
> At 11:04 AM +0200 9/19/06, Christine Karman wrote:
> >...
> >Another difference between authentication in a browser and 
> email is the 
> >following. A company archives old email. They have to be 
> able to verify 
> >validity of digital signatures on incoming email, even for 
> certificates 
> >that have expired long ago. The DOD will have to have that 20Mb crl 
> >available forever, unless they switch to online verification.
> 
> There is no requirement for a CA to maintain entries on a CRL 
> after the certs in question have expired.  Your model re CRL 
> management is inconsistent with RFC 3280 requirements.
> 
> Steve
> 
> 
>

---

From: "Al Arsenault" <[email-masked]>
Date: Wed, 20 Sep 2006 13:22:34 -0400

Phill,

*       If you want to have an archival capability knowing the revocation
status of expired certificates is an essential operational capability.

Yes, so?  We worked on archival requirements for the DoD PKI more than 10
years ago. This is well understood. One other thing to point out is that in
order for this archive solution to work, you have to have a secure, strong
time-stamping service (which hasn't been mentioned).  Once your signature
key is broken, it was "always" broken - I can create a document, sign it
with your broken key, and back-date it to whenever I want.  The only way for
you to stop that is to have some secure, strong system for telling (with
high probability of accuracy) whether the document actually existed at the
claimed time. 

*       If the CRL does not have that information it is not an appropriate
technology for that application.

If you use CRLs, you have two options.  One is to keep the "current" CRL at
the time the message was signed or first verified, and keep it securely
bound to the message.

The other is to have an archive capability that lets you re-generate the CRL
as it existed at any given time in the past.

Similarly with OCSP.  You have two options: get an OCSP response when the
message was first signed/verified, and securely bind that to the message and
store them; or have an ability to determine certificate status at any given
point in the past and re-create an appropriate OCSP response.

There's no practical difference. Either solution will work, and either
solution is subject to good or bad engineering solutions.

*       In a messaging environment you are very likely to want archival
capabilities and in particular the ability to query the status of the
certificate on a particular day.

Yep.

*       For SSL it does not matter as the only status that matters is
current status.

*       If Ben Franklin had signed the US constitution with a digital
signature people would probably want to know if it was still valid after his
certificate had expired.

I'm not sure why, but okay, no problem - that can be supported.

                  Al Arsenault

---

From: "Liaquat Khan" <[email-masked]>
Date: Wed, 20 Sep 2006 18:45:47 +0100

Yes I agree; our customers definitely see a need for being able to validate
the status of a certificate beyond its expiry date.  As you say this is not
for certificates used for real-time "authentication" purposes but for
digital signatures on long-term documents. We have actually already
implemented this in our validation server (i.e. the archival of each CRL
from a particular CA and then providing facility to check certificate
against historical CRLs).  Of course timestamping also has a big part to
play in this process.  From a business point of view, how long CRLs are
archived should be configurable. 

Regards,
LK

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hallam-Baker, Phillip
Sent: 20 September 2006 14:49
To: Stephen Kent; Christine Karman
Cc: Kemp David P.; [email-masked]
Subject: RE: large crl's

If you want to have an archival capability knowing the revocation status of
expired certificates is an essential operational capability.

If the CRL does not have that information it is not an appropriate
technology for that application.

In a messaging environment you are very likely to want archival capabilities
and in particular the ability to query the status of the certificate on a
particular day.

For SSL it does not matter as the only status that matters is current
status.

If Ben Franklin had signed the US constitution with a digital signature
people would probably want to know if it was still valid after his
certificate had expired.