RE: Comments on CRL issuance after certificate revocation in draft-ietf-ltans-notareqs-02

["Santosh Chokhani" <chokhani@xxxxxxxxxxxx>]

Larry,

Section 4.2 deals with the issue of repudiability when the certificate is
revoked and relying party does not have the current information.

But, that is not the only repudiation.  Practically, the private key holder
might come to know of the compromise after T5 and hence the certificate
might be legitimately revoked after T5.

I think the requirement should be validation of signature at a point in time
as opposed to saying that it is not repudiable.

In addition or alternatively, we could define a policy that if a transaction
is signed at time t1, then we need a CRL with thisUpdate > t1 to verify the
signature and we hold the verification until that CRL is available.  The
transaction may need two time stamps: one for t1 and one for when the
verification is done after the CRL is received.  Then you get in the debate
of is the newer CRL for signer certificate is sufficient or do we need newer
CRL for all certificates in the path.  I would think the CRL for signer
certificate is sufficient. 

If some one needs to repudiate a signature due to revocation coming to the
signer's attention later, we may need additional requirements or say that
the signer's needs to take some proactive action to retract what may have
been signed in his/her name.

-----Original Message-----
From: owner-ietf-ltans@xxxxxxxxxxxx [mailto:owner-ietf-ltans@xxxxxxxxxxxx]
On Behalf Of Larry Masinter
Sent: Tuesday, June 28, 2005 3:10 AM
To: ietf-ltans@xxxxxxx
Subject: Comments on CRL issuance after certificate revocation in
draft-ietf-ltans-notareqs-02



We were sent some comments on the -02 draft, I thought
I should forward the substantive comment for mailing
list discussion:

There was a comment on 
   The problem with CRLs is that they might not be synchronized with
   revocation mechanisms and there is no real information whether a
   signature is valid or not at specific point in time. In theory CRLs
   should be issued immediately after a certificate is revoked.

The comment was:

This is not advisable, because this "on the spot" CRL issuance paves the way
to man in the middle / replay attacks.

An attacker could store a CRL issued before implementing a, say, 
private key compromise attack. After the attack the attacker could 
intercept CRL retrieval requests issued before the CRL nextUpdate  time and
send back the requester the previous CRL, where the revoked 
certificate is not listed. If the nextUpdate time has not yet expired 
the relying parties would trust the CRL they receive, without having 
a means to realise it is the old one. If instead CRLs are issued only 
at nextUpdate time, or just slightly before, RPs would be aware they 
should wait until the so called "grace period" expires. CAs could 
take no responsibility on verifications based on CRLs issued before 
the "grace period". By grace period it is intended the time necessary 
for a revocation request to be processed by the revocation management 
service to make it available to relying parties. If such request is 
submitted to the revocation service too close to the next CRL issuance 
time to be included in it, then the revocation will be published in 
the subsequent CRL. Please see CWA 14171 section 5.3 for details
(http://www.uninfo.polito.it/WS_Esign/doc/cwa14171.pdf or 
ftp://ftp.cenorm.be/PUBLIC/CWAs/e-Europe/eSign/cwa14172-01-2004-Mar.pdf).




(There were a couple of editorial comments, e.g., "When speed is not of
essence" should probably be "When speed is not of the essence"