[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on CRL issuance after certificate revocation in draft-ietf-ltans-notareqs-02
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.
From: owner-ietf-ltans@xxxxxxxxxxxx [mailto:owner-ietf-ltans@xxxxxxxxxxxx]
On Behalf Of Larry Masinter
Sent: Tuesday, June 28, 2005 3:10 AM
Subject: Comments on CRL issuance after certificate revocation in
We were sent some comments on the -02 draft, I thought
I should forward the substantive comment for mailing
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
(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"