[caops-wg] on-hold cert revocation ("suspend") to disappear?

[Mike Helm]

------- Forwarded Message

>From SRS0=c649ea436bb7f94904d7eb80db940951b33abd3e=167=mail.imc.org=owner-ietf-pkix at es.net  Mon Nov 27 12:55:57 2006
Message-ID: <456B47D1.2050405 at cs.tcd.ie>
Date: Mon, 27 Nov 2006 20:17:21 +0000
From: Stephen Farrell <stephen.farrell at cs.tcd.ie>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Russ Housley <housley at vigilsec.com>
CC: ietf-pkix at imc.org
Subject: Re: on-hold certificates in CRLs
References: <a7d7da420611270753s70be3596qebe24ea9f3aff6b at mail.gmail.com> <7.0.0.16.2.20061127140855.07404318 at vigilsec.com>
In-Reply-To: <7.0.0.16.2.20061127140855.07404318 at vigilsec.com>
List-ID: <ietf-pkix.imc.org>


Bit of a late change, but a good one,
S.

Russ Housley wrote:
> 
> I would like to take this opportunity to advocate the deprecation of "on 
> hold" altogether.  No good can come from it, as been discussed so many 
> times on this list.
> 
> I can live with the current text, but I think it would be far better to 
> say that the "on hold" status MUST NOT be used by CAs conforming to 
> 3280bis.
> 
> Russ
> 
> At 10:53 AM 11/27/2006, Carlos González-Cadenas wrote:
>> Hi,
>>
>> Suppose we have the following ordered temporal sequence
>>
>> t1 - a certificate with serial "S1" is issued by a CA
>> t2 - the certificate is put on-hold by the CA (i.e. in order to 
>> investigate a possible compromise)
>> t3 - a full CRL is issued by the CA
>> t4 - the investigation carried by the CA ends up in no compromise, and 
>> the CA makes the certificate valid again
>> t5 - a delta CRL is issued by the CA
>> t6 - a full CRL is issued by the CA
>>
>> Does the CRL logs all the revocation-related events for the 
>> certificate with serial S1?.
>>
>> If we assume that all the events are logged, then the CRLs contents 
>> (for certificate with serial S1) should be:
>>
>> full CRL issued at t3: contains an entry for S1 at t3 with reason code 
>> on-hold
>> delta CRL issued at t5: contains the previous full CRL entry plus an 
>> entry for S1 at t5 with reason code removeFromCRL
>> full CRL issued  at t6: contains both previous entries (so you know 
>> the on-hold period for the certificate) (maybe this is violating 
>> RFC3280 as removeFromCRL is only applicable for deltaCRLs??)
>>
>> If we assume that NOT all events are logged, CRLs issued >=T6 don't 
>> include revocation entries for certificate S1, that is
>>
>> full CRL issued at t3: contains an entry for S1 at t3 with reason code 
>> on-hold
>> delta CRL issued at t5: contains the previous full CRL entry plus an 
>> entry for S1 at t5 with reason code removeFromCRL
>> full CRL issued  at t6: contains NO entry for S1
>>
>> Which is the normative (RFC3280) behaviour for that case?. Is there 
>> any change between RFC3280 and RFC3280bis about these issues?
>>
>> Note that if the second case is the normative behaviour IMHO there's 
>> no way (except storing the CRLs between t2 and the next CRL appeared 
>> after t4) for a relying party (verifying the certificate in or after 
>> t6) to know the certificate status between t2 and t4.
>>
>> Many thanks in advance,
>>
>> Carlos
>>
> 
> 


------- End of Forwarded Message