Subject: RE: on-hold certificates in CRLs

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 27 Nov 2006 13:23:40 -0800

Russ,

I do not agree with the conclusion that on hold is overly complex.  We should have a profile that does not require the use of "Hold Instruction".  In that case, on hold and remove from hold is a nice feature.

As to determination of the certificate status, archiving all CRL (and deltas if deltas are produced) give the accurate picture of revocation status modulo CRL issuance frequency.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Monday, November 27, 2006 2:12 PM
To: Carlos GonzÃ¡lez-Cadenas; [email-masked]
Subject: Re: on-hold certificates in CRLs

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
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 28 Nov 2006 13:45:52 -0800

I sorta agree with Steve here. 
 
I don't think that there is much prospect of using the suspension, on-hold or any other cert status other than 'good' or 'bad'. Once you advertise the status of the certificate as being suspect you might as well issue a fresh cert than money about trying to retract the suspension status. 
 
And before you ask, no I would not use the features that would create the desire to do this either.

If you are only going to operate in an OCSP world there might be a point to quasi-revocation. But if you decide to only live in that world you might as well get rid of the certs altogether and go back to Diffie's original idea of a directory for keys as XKMS does.

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Kent
	Sent: Tuesday, November 28, 2006 2:20 PM
	To: "Carlos González-Cadenas"
	Cc: Dr Stephen Henson; pkix
	Subject: Re: on-hold certificates in CRLs

	At 3:34 PM +0100 11/28/06, Carlos González-Cadenas wrote:

		...
		The problem now is that
		
		1) we don't have a common view about what "on-hold" means (in this mail thread some people argue that the key should not be used during the on-hold period and other people argue that the key may be used).

	right, and that means that CAs who have decided to use this "feature" of X.509 are imposing a burden on all RPs because of this ambiguity.

		2) it's not clear how to bring certificate suspension into the practice

	how about not at all!

	I am not a fan of "hold" as a cert status, for example:

	        - absent a common understanding of what hold means by itself, one needs to use the hold instruction code, which is itself a mess for automated processing, e.g., 3280 says "Conforming applications which encounter an id-holdinstruction-callissuer MUST call the certificate issuer or reject the certificate." Give me a break! Call the issuer OR reject the cert.  This is hardly useful guidance for software.

	        - and 3280 notes deprecates use of the silly "none" instruction. Frankly, this is a perfect example of a committee-designed extension that needed adult supervision!

	
	Presumably the best example provided so far is the use of hold to state that an issued and valid cert is NOT yet "in play" and thus for NR purposes, signatures that are created while the cert is on hold are not reliable.  But, the same effect could have been achieved by distributing a smart card with a key pair and a cert template, and have the cert really issued as a side effect of the user executing some POP protocol.  It sounds like some CAs decided that use of hold was an easy way to address a valid concern in a way that makes life easy for them, but harder for all RPs. 

	I will disagree with Russ and Stefan on this one.  While we ought not create standards that disenfranchise legitimate uses of the technology, we also have no obligation to condone practices that externalize costs, i.e., create undue burdens on some parties to make life easier for others.

	Steve

---

From: "Denis Pinkas" <[email-masked]>
Date: Wed, 29 Nov 2006 10:08:18 +0100

Carlos,

I concur with you when you say " I always felt that some text that clarified how to deal with suspension was missing".
The text from X.509 is not much better either. :-(

You mention three supported cases, but you only deal with cases a) and b).  :-)
In fact, there are many cases to consider:

a) whether the certificate is a leaf certificate, or a CA certificate

b) when it is a leaf certificate, whether the certificate is used for :

        -  authentication purposes (which means real-time verification), or 
        -  non-repudiation purposes (which means verification in the past).

c) whether at the end of the suspension period, the certificate is definitively revoked or is said to be valid.  

If you have some time available, it would be useful to first address cases b) and c) and say whether it makes a difference 
if the suspension state starts at the beginning of the validity period of the certificate or at a later time. 

Denis

In my opinion the on-hold status makes sense in many concrete cases all of you have been discussing before. Many CAs (I speak for what I've seen here in Spain) also support certificate suspension, and that's included in their CPSs. 

It is technically possible to determine with a precision near to zero when a signature was created (as you said in some emails there's plenty of published material about that matter), so it's necessary to know the status of the certificate in a point of time. 

The problem now is that 

Regarding 2) I see that a common practice about how to  do certificate suspension described in 3280bis would be very helpful. In my opinion there should be three supported cases 

a) a certificate suspended (on-hold) that is finally revoked, that means that the CA first revoke the certificate in instant t1 with the on-hold cause, and after doing some investigations or whatever finally revokes the certificate in instant t2 with another cause different from on-hold ( i.e. key compromise, ...) (note that it will be very useful to include an invalidity date extension pointing to t1 or to the time it's known the certificate should be considered as invalid). 

Relying parties validating the certificate between t1 and t2 will see the certificate on-hold (I see here that using the hold instruction code can make happy people with different interpretations for what means on-hold, that is, the CA can inform with the hold instruction that the certificate is to be rejected, possibly solving the problems found in 1) ) 
Relying parties validating the certificate after t2 will see the certificate revoked (everything should work as usual)

b) a certificate suspended (on-hold) that is finally determined valid, that means that the CA first revoke the certificate in instant t3 with the on-hold cause, and after doing some investigations or whatever finally determines that the certificate should keep valid, therefore including a removeFromCRL in t4 (if the CA is issuing deltas) and eliminating all the information regarding this certificate in the full CRL issued in t5 

Relying parties validating the certificate between t3 and t4 will see the certificate on-hold (I see here that using the hold instruction code can make happy people with different interpretations for what means on-hold, that is, the CA can inform with the hold instruction that the certificate is to be rejected, possibly solving the problems found in 1))
Relying parties validating the certificate after t4 should determine that the certificate is valid (and in this case the information that the certificate was on hold it's not longer needed as you said). 

I don't know if I'm missing something important, but as an implementer I always felt that some text that clarified how to deal with suspension was missing: I guessed and interpreted how to do it. I think we have a gold opportunity now to fix this issue in 3280bis (possibly 3280bisbis will take many years). 

I offer myself to help in what you consider is the best solution (producing text for 3280bis, creating informative material, ....).

Opinions?

Best regards,

Carlos

On 11/28/06, Dr Stephen Henson <[email-masked]> wrote:

Wen-Cheng Wang wrote:
>
>
> You may argue that no matter how close between the time in the time-stamp
> and the signing time claimed by the signer, risk still exists. If so,
> you should
> consider add a "content time-stamp" in addition to the "signature
> time-stamp".

Yes I'd argue that. In some cases (S/MIME signing time attribute for
example) an attacker could generate a message with an arbitrary signing 
time. In this case they could claim some time in the future after the
hold status is expected to be lifted.

> The signing sequence will be as the following:
>    Step 1. Get a trusted time-stamp of the message content 
>    Step 2. Sign the message
>    Step 3. Get a trusted time-stamp of the signature
> Since the message must be signed between the time of the content time-stamp
> was generated and the time of the signature time-stamp was generated, the 
> verifier can certainly be aware of the period in which the message is
> signed.
>
> Therefore, it is actually possible to reliably determine the time (in
> the regard of
> the agreed signature policy) or the "period" the signature was made. 
>

Yes that would work assuming that "message" in Step 2, is the message
content with time stamp. Signing the content time stamp would have the
same result.

IMHO if we are not going to deprecate the on-hold status we at least 
need some text to indicate the issues involved.

Steve.
--
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.