RE(2): operational protocols

<T.A.Parker@win0199.wins.icl.co.uk> Mon, 07 April 1997 17:04 UTC

Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id KAA19558; Mon, 7 Apr 1997 10:04:23 -0700
Received: from bath.mail.pipex.net by suntan.tandem.com (8.6.12/suntan5.970212) for <ietf-pkix@tandem.com> id KAA19548; Mon, 7 Apr 1997 10:04:16 -0700
From: T.A.Parker@win0199.wins.icl.co.uk
X400-Received: by mta bath.mail.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Mon, 7 Apr 1997 18:03:09 +0100
X400-Received: by mta fel01m2 in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Mon, 7 Apr 1997 17:52:34 +0100
X400-Received: by mta bra01c1 in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Mon, 7 Apr 1997 18:00:49 +0100
X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5-text); Relayed; Mon, 7 Apr 1997 18:02:15 +0100
Date: Mon, 07 Apr 1997 18:02:15 +0100
X400-Originator: T.A.Parker@win0199.wins.icl.co.uk
X400-Recipients: non-disclosure:;
X400-MTS-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;win0199 0000008800012030]
X400-Content-Type: P2-1984 (2)
Content-Identifier: 12030
Alternate-Recipient: Allowed
Message-ID: <"12030*/I=TA/S=Parker/OU=win0199/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS>
To: ietf-pkix@tandem.com
In-Reply-To: <s348aaa6.057@zionsbank.com>
Subject: RE(2): operational protocols

         Late into this thread as usual, but can anyone tell me why
         the CIL works at all? Why couldn't the bad Directory supply the
         caller with an old CIL ("I didn't get the latest CIL either")?
         
         My impression of the (maybe partial) solution to the "I didn't get
         it" problem was that a policy is defined on CRL update releases. 
         One release is defined to be expected every X days. This policy
         can be specified in a V3 certificate. If the CA has nothing to 
         say on a particular CRL issue time point it issues an empty one,
         or a copy of the previous one, depending on whether delta CRLs
         are being used.
         
         Under the policy described above, Validation of a certificate
         demands that all current CRLs, including empty ones have been 
         looked at. If a Directory says "didn't get the last issue", and 
         note that it can't hide the fact that there should be one,
         then the policy says the certificate cannot be treated as valid.
         You can't stop the denial of service threat but you can stop 
         revoked certificates being accepted.
         
         Tom Parker
         ICL, UK
         7.4.97