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
- Re: operational protocols Housley, Russ
- Re: operational protocols Housley, Russ
- Re: operational protocols Patrick Richard
- Re: operational protocols Reginald Carey
- Re: operational protocols Stef Hoeben
- RE(2): operational protocols T.A.Parker
- Re: operational protocols Mike Smith
- Re: operational protocols Mike Smith
- Re: operational protocols Stef Hoeben
- Re: operational protocols David Boyce
- Re: operational protocols Stef Hoeben