Subject: on-hold certificates in CRLs

From: "Carlos González-Cadenas" <[email-masked]>
Date: Mon, 27 Nov 2006 16:53:07 +0100

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: Russ Housley <[email-masked]>
Date: Mon, 27 Nov 2006 14:11:32 -0500

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:
>t2 - the certificate is put on-hold by the CA (i.e. in order to 
>investigate a possible compromise)
>t4 - the investigation carried by the CA ends up in no compromise, 
>and the CA makes the certificate valid again
>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
>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: Stephen Farrell <[email-masked]>
Date: Mon, 27 Nov 2006 20:17:21 +0000

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
> 
>> t4 - the investigation carried by the CA ends up in no compromise, and 
>> the CA makes the certificate valid again

---

From: Dr Stephen Henson <[email-masked]>
Date: Mon, 27 Nov 2006 20:10:20 +0000

> say that the "on hold" status MUST NOT be used by CAs conforming to

I have come across two real world examples of it being used in national
ID schemes. In both of these a certificate is automatically placed "on
hold" when the card is manufactured and then made valid when the
recipient has performed some procedure to acknowledge receipt. I suspect
that the two I saw are far from isolated examples.

Personally the use of "on hold" always makes me rather uneasy and I'd
have no objections about it being deprecated.

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.

---

From: Massimiliano Pala <[email-masked]>
Date: Mon, 27 Nov 2006 22:21:19 +0100

Dr Stephen Henson wrote:
[...]
> that the two I saw are far from isolated examples.

I do confirm that some big national CAs (at least in Italy) use the `on Hold'
status when the card is first "initialized" (and the certificate issued)
till the user receives the card.

> have no objections about it being deprecated.

One question, is there any proposal for the replacement of the `on hold'
status ? Some time ago (back in 2000, I guess) there was the proposal
of a separated CSL (Certificate Suspension List) which was rejected in
favor of the "on hold" extension in CRLs... anyway do you think it is
time to address the 'suspended' state once for all ?

We can also agree with the fact that the suspension, as it is now, it is
too difficult to handle and it is error prone, so a viable path would be
to clearly state that there is not a ``suspended'' state, therefore a
certificate is either valid or revoked.

And we stick with simply reissuing the certificates (as, I guess, it is
the most common practice today (?)).

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala                                  [OpenCA Project Manager]

Dartmouth Computer Science Dept                       [email-masked]
PKI/Trust                                        [email-masked]
-----------------------------------------------------------------------o---

---

From: "Turner, Sean P." <[email-masked]>
Date: Mon, 27 Nov 2006 16:33:30 -0500

I agree - on hold shoud be made a MUST NOT.

spt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Farrell
Sent: Monday, November 27, 2006 3:17 PM
To: Russ Housley
Cc: [email-masked]
Subject: Re: on-hold certificates in CRLs

Russ Housley wrote:
>> 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??)
>>
>> 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
>>

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 27 Nov 2006 16:48:39 -0500

The contents of CRL are not affected by the information logged by the CA.

The important thing to note is that a CRL can have at most one entry for 
any given certificate.  So, the delta CRL issued at t5 would contain one 
entry for S1, and that entry would specify a reason code of 
removeFromCRL.  The full CRL issued at t6 would not include an entry for S1.

In some sense, you are correct that you cannot tell from the contents of 
the CRL issued at t6 whether the certificate had been on hold at some 
point in the past.  One of the main problems that we have with 
certificate suspension at the moment is that there are two competing 
interpretations of meaning behind certificate suspension.  In my opinion 
(and I believe that this was the meaning intended by the authors of 
X.509), there is no reason that one would need to know whether a 
certificate was on hold at some point in the past.  In your example, the 
certificate was removed from hold since it was determined that the 
private key had not actually been compromised (if it had been, the 
certificate would have remained revoked, but with the reason code 
changed to keyCompromise).  I would argue that this means that any 
signatures created during the time that the certificate was on hold are 
valid and that a relying party can safely accept those signatures once 
the certificate is removed from hold.  So, there would be no need for 
the relying party to know that the certificate was on hold at the time 
the signature was generated.  If there really was reason to believe that 
the private key had been misused at some time in the past, then the 
certificate should have been permanently revoked.

Other people believe that placing a certificate on hold also places use 
of the private key on hold and so any signatures generated during the 
time that the certificate was on hold are not legitimate.  Thus, these 
people believe that when verifying a signature it is important to know 
whether the certificate was on hold at the time that the signature was 
generated, even if the certificate is later removed from hold.  The 
information included in CRLs issued after the certificate is removed 
from hold do not include any information that would help to determine 
whether the certificate was on hold at some point in the past.

Dave

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 27 Nov 2006 17:33:01 -0500

I know of another case where certificate suspension is used (or at
least the CPS allows for certificate suspension).  In this case, if the
CA receives a request to revoke a certificate but the source of the
request cannot be authenticated, then the certificate is placed on
hold.  If the CA is able to verify that the request came from an
authorized individual (e.g., the certificate subject), then the
certificate is revoked, otherwise it is removed from hold.

Note that in this case, once a certificate is removed from hold, there
is no reason that a relying party would need to know that the
certificate was on hold at some point in the past.  The certificate was
removed from hold since it was determined that there was never a
problem with the certificate in the first place.  Once the certificate
has been removed from hold, there is no reason to consider any use of
private key during the time that the certificate was on hold to be
invalid, so there is no need for relying parties to know that the
certificate was on hold at some point in the past.

While I don't think that the above use of certificate suspension is
unreasonable (if it is necessary to take action before verifying the
revocation request), I do agree that it is generally a good idea to try
to avoid using certificate suspension.

Dave

Dr Stephen Henson wrote:

Russ Housley wrote:

Steve.

---

From: "Peter Lipp" <[email-masked]>
Date: Mon, 27 Nov 2006 23:32:58 +0100

> to say that the "on hold" status MUST NOT be used by CAs 
YES PLEASE. Thanks. :-)

Peter Lipp

---

From: Russ Housley <[email-masked]>
Date: Mon, 27 Nov 2006 18:51:14 -0500

>till the user receives the card.

If people are really using it, then we should not pull the rug out 
from under them.  I do not think this is a great mechanism for the 
situation that is described, but there are far worse uses that have 
been discussed.

Russ

---

From: "Michael Myers" <[email-masked]>
Date: Mon, 27 Nov 2006 16:03:05 -0800

I concur that it should be deprecated.

Mike

-----Original Message-----
From: Dr Stephen Henson
Sent: Monday, November 27, 2006 12:10 PM

. . .

Steve

---

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 28 Nov 2006 01:31:33 +0000

> whether the certificate was on hold at some point in the past.

That's the case I'm uneasy about which I suspect is the case the two
examples I've seen are intended to cover.

It should be noted that this assumes that there is a way to reliably
determine when the signature was made.

This is not always possible and often one can only say it was made *on
or before* a certain time (for example the time in a trusted timestamp).

That doesn't help because the signature might be made during the hold
period and the timestamp added some time afterwards.

Steve.

---

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 28 Nov 2006 01:28:07 +0000

Steve.

---

From: Róbert Kisteleki <[email-masked]>
Date: Tue, 28 Nov 2006 10:59:16 +0100

Russ Housley wrote:
> If people are really using it, then we should not pull the rug out from 
> under them.  I do not think this is a great mechanism for the situation 
> that is described, but there are far worse uses that have been discussed.
> 
> Russ

I have to agree with Massimiliano, in some countries the legislation (!) 
enables/forces the national CAs to use the on hold status. Besides this, 
whole business processes have been built upon this feature.

I'm not saying that on hold is a good/bad feature, merely that it is being 
used, and even if you deprecate it, it will take years to root it out from 
practice.

Robert

---

From: "Peter Rybar" <[email-masked]>
Date: Tue, 28 Nov 2006 11:31:29 +0100

Signed mail is in attachment.

Subject: RE: on-hold certificates in CRLs
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Date: Tue, 28 Nov 2006 11:21:10 +0100

The status of certificateHold or removeFromCRL is useful only for strictly 
online system, where is no reason to check a history about revocation 
status information.

If certificate is several times in status on hold and removed from hold 
then the verification of qualified electronic signature with trusted 
timestamp is almost impossible. 

That is the reason why the Slovak Act no. 215/2002 Coll. on Electronic 
Signature (qualified certificate and qualified el. signature) does not 
allow removing the certificate from hold. 

Certificate in the CRL (OCSP) can not be found in revocation reason 
certificateHold or removeFromCRL, thus its validity can not be stopped for 
certain period.

IMHO useful recommendation in this RFC: 
"The certificateHold or removeFromCRL status MUST NOT be used by CA except 
CA for strictly On-Line system".

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On 
Behalf Of Dr Stephen Henson
Sent: Tuesday, November 28, 2006 2:32 AM
To: pkix
Subject: Re: on-hold certificates in CRLs

Steve.

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 28 Nov 2006 10:42:18 +0000

2 things.

1) Some examples of using on-hold seems a bit shaky. For example putting a certificate on-hold until card is delivered does not stop me from signing with the card and use that signature after its status has been restored. I concur that once status has been restored, there is no need to know if it has been on hold.

I'm personally not a big fan of "on hold", but we have a responsibility to not break users of this profile, so deprecating a feature puts great responsibilities on us to determine that we don't break legitimate implementations.

2) RFC3280bis will never be perfect. We will never stop finding things that we may want to change or update. It's time to draw the line and let this document proceed. Let's focus on fixing errors if we find them but avoid "improvements" as much as possible. It's time to ship an update of RFC 3280.

In time there will be an rfc3280bisbis

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Russ Housley
> Sent: den 28 november 2006 00:51
> To: [email-masked]

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Tue, 28 Nov 2006 19:18:06 +0800

> period and the timestamp added some time afterwards.
In the area of "Advanced Electronic Signatures" (or so-called long term
electronic signatures by the S/MIME WG), this is called "time-stamp delay".

In section B.8.4 of RFC 3125, it informatively describe requirement of
signature policy related to "time-stamp delay" as follows:

   There will be some delay between the time that a signature is created
   and the time the signer's digital signature is time-stamped.
   However, the longer this elapsed period the greater the risk of the
   signature being invalidated due to compromise or deliberate
   revocation of its private signing key by the signer.  Thus the
   signature policy should specify a maximum acceptable delay between
   the signing time as claimed by the signer and the time included
   within the time-stamp.

And in section 3.8 of RFC 3125, the signatureTimestampDelay field is
defined as follows to allow a signature policy Issuer to specify  the
acceptable "time-stamp delay":
  The signatureTimestampDelay field specifies a maximum acceptable time
   between the signing time and the time at which the signature time-
   stamp, as used to form the ES Time-Stamped, is created for the
   verifier.  If the signature time-stamp is later that the time in the
   signing-time attribute by more than the value given in
   signatureTimestampDelay, the signature must be considered invalid.

The implication is that with the help of a trusted time-stamp close enough
to the signing-time (in the signed attribute) claimed by the signer, the verifier
can assume, in the regard of the agreed signature policy, the message
was really signed at that time.

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".
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.

I am one of the people who believe that placing a certificate on hold also
places use of the private key on hold and so any signature generated
during the time that the certificate was on hold are not legitimate. I also
agree the following Santosh's opinion:
   "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."

I am aware a case where the signatures generated during the time that the
certificate was on hold are not legitimate. The case is the government issues
X.509 certificates to companies and  by regulation if a company's license
is placed on hold (for example, due to illegal tax evasion) then the company's
X.509 will also be simultaneously placed on hold and the company's digital
signatures will be considered illegitimate until its company license is resumed
(and of course its X.509 certificate will be simultaneously resumed too).

To validate an archived signed data (with long-term signature and timestamps),
we will need a mechanism to validate the signing certificate relative to past
time or period. Currently, the SCVP draft intend to support validate a certificate
relative to past time. (Personally, I think SCVP should also support validate
a certificate relative to past "period".) However, it is unfortunately that the
certificate validation algorithm of RFC 3280 and RFC 3280bis only support
validate a certificate at the "current time". We still lack a standard algorithm to
validate a certificate relative to past time or period.

Wen-Cheng Wang

---

From: "Peter Lipp" <[email-masked]>
Date: Tue, 28 Nov 2006 12:39:15 +0100

> If people are really using it, then we should not pull the 
> rug out from under them.  I do not think this is a great 
> mechanism for the situation that is described, but there are 
> far worse uses that have been discussed.

That's an understandable position. But probably it would be or have been
worthwhile to differentiate between the different uses; currently the number
of interpretations what to use that mechanism for is simply to
heterogeneous, some of them are problematic. We have seen mentioned now:

- on hold for the time of transport of the id card
- on hold for suspected compromise where the info came from unauthenticated
sources
I have heared from ideas to use on hold for a time where e.g. I am not in my
office and cant use the certificate on my office machine (like vacation or
even the weekend). (Don't know if this idea has been implemented though.
Hope not.)
There may be other ideas/uses of that concept. 

Santosh mentioned that "on hold is not overly complex". I agree, the basic
idea isn't. But the different interpretations existing make it maybe not
complex but incompatible or meaningless. What does the "on hold" for
transport buy me? As soon as it is no longer on hold and the firt CRL
without that information issued, this fact is forgotten. What if I now had a
signature created during that time... (If I assume I will never find such a
signature, why place the cert on hold?) 

If this stays in, the usage should be restricted to the working scenarious
only and any legislation prescribing other uses should be fixed.

Peter

---

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 28 Nov 2006 12:05:19 +0000

> consider add a "content time-stamp" in addition to the "signature

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 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.

---

From: "Carlos González-Cadenas" <[email-masked]>
Date: Tue, 28 Nov 2006 15:34:38 +0100

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

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).

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

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

---

From: Massimiliano Pala <[email-masked]>
Date: Tue, 28 Nov 2006 16:13:38 +0100

Stefan Santesson wrote:
> 2) RFC3280bis will never be perfect. We will never stop finding things that we may want
> to change or update. It's time to draw the line and let this document proceed. Let's
> focus on fixing errors if we find them but avoid "improvements" as much as possible.
> It's time to ship an update of RFC 3280.
> 

I agree with this vision. Unfortunately it seems that the rfc3280 is probably one
of those documents which requires periodic updates, and this does not map well into
IETF RFCs.

I personally think, anyway, that a specific text should be added in this case to
the RFC, in particular we should at least make it clear that:

<< The `on hold' status does not affect later verification of legitimacy of
certificate usage in case the certificate is later removed from CRLs. Therefore
the `on hold' status does not provide a reliable way of suspending the usage of
a certificate in a specific period of time. >>

Providing also an explicit reference to the card/token suspension example as being
a bad interpretation/practice that should be avoided could also help (and as it is
quite a common practice, it is useful to explicitly state that it should be avoided
because it *does not* prevent the certificate to be used!).

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]            [email-masked]
                                                  [email-masked]

Dartmouth Computer Science Dept
PKI/Trust
--o------------------------------------------------------------------------

---

From: Stephen Kent <[email-masked]>
Date: Tue, 28 Nov 2006 14:19:40 -0500

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: "Wen-Cheng Wang" <[email-masked]>
Date: Wed, 29 Nov 2006 20:12:54 +0800

Re: on-hold certificates in CRLs
  ----- Original Message ----- 
  From: Stephen Kent 
  To: "Carlos González-Cadenas" 
  Cc: Dr Stephen Henson ; pkix 
  Sent: Wednesday, November 29, 2006 3:19 AM
  Subject: Re: on-hold certificates in CRLs

  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.

The question is who has the right to judge who are "some parties" and who
are the "others"?

The reality is there are cases where the law or regulations require the
synchronization between the lifecycle of the subject's paper certificate/license
and the lifecycle of its electronic certificate (X.509 certificate). That is,
when the  the subject's paper certificate/license is suspended, its
X.509 certificate is required to be suspended simultaneously. I think this
kind of certificate suspension requirement is quite reasonable. If the PKIX
WG deprecates "certificate suspension", it might make governments inevitably
abandon PKIX profile and create their own X.509 certificate profiles. This
is not good for the interoperability.

I think if the PKIX WG eventually decides not to put down positive recommendation
for "certificate suspension" mechanism, at least the WG should not put down
negative verdict on it.

Wen-Cheng Wang

---

From: Massimiliano Pala <[email-masked]>
Date: Thu, 30 Nov 2006 01:10:23 +0100

Wen-Cheng Wang wrote:
[...]
> The question is who has the right to judge who are "some parties" and who

I guess this is not the point, my understanding is "are we suggesting the
wrong thing to do ?", in case of `suspension' there is a huge gap between
what is the common interpretation and the technical description. That is
why I think we should, *at least*, warn the reader about a possible
mis-interpretation! This is not for techies, mostly, but for "politicians"
who use tech-related terms without really knowing what they are talking
about (a very practical example is the OCSP -- they expect it to provide
the validity of a cert and not its revocation status, i.e. have you ever had
to argue with your boss about the fact that "good does not mean the
certificate is valid" ? :-/ )

> is not good for the interoperability.

Sorry, but I think it differently. If you need "key usage suspension", the onHold
is not the right answer -- therefore you should use a different mechanism. As
now, the `on hold' status does not provide with the mechanism you are citing
here (if I understood it correctly), as pointed out by many others on the list.

> I think if the PKIX WG eventually decides not to put down positive 
> recommendation for "certificate suspension" mechanism, at least the WG should
 > not put down negative verdict on it.

Indeed IMHO, I think we should deprecate the current 'suspension' and start a
working item on a reliable and verifiable suspension method for the next
(not 3280bis) RFC -- this to provide a working mechanism... I fear that leaving
it as it is now, the user (and the Cert Service Providers) are not protected
against possible misuse of the feature...

-- 

Best Regards,

	Massimiliano Pala

Dartmouth Computer Science Dept               Home Phone: +1 (603) 397-3883
PKI/Trust
--o------------------------------------------------------------------------

---

From: Stephen Kent <[email-masked]>
Date: Wed, 29 Nov 2006 12:35:25 -0500

At 8:12 PM +0800 11/29/06, Wen-Cheng Wang wrote:
>From: <mailto:[email-masked]>Stephen Kent
>To: <mailto:[email-masked]>"Carlos González-Cadenas"
>Cc: <mailto:[email-masked]>Dr 
>Stephen Henson ; <mailto:[email-masked]>pkix
>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.
>
>
>and the lifecycle of its electronic certificate (X.509 certificate).

The IETF has consistently chosen to NOT to pay 
heed to legislative demands imposed by  countries 
in the crypto area, for many years. See the RFCs 
for S/MINE and TLS as examples. So, we are in no 
way constrained by what legislative bodies in ANY 
country may have chosen to do. (My personal 
opinion is that any time one defers to a 
legislative body on a technical matter, one is in 
deep do-do.)

>That is,

Suspension is a wimpy approach to revocation. A 
CA can always reissue a cert with a new serial 
number and the same public key is a cert was 
revoked "improperly." Suspension is just a way 
for a CA to avoid legal liability.

Steve

---

From: "Peter Lipp" <[email-masked]>
Date: Thu, 30 Nov 2006 11:48:00 +0100

> If the PKIXWG deprecates "certificate suspension", ....
>...this is not good for the interoperability.
Since the different interpretations of suspension are not interoperable
anyway, this can't get worse IMHO

Peter

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Thu, 30 Nov 2006 20:28:00 +0800

Stephen Kent wrote:

  The IETF has consistently chosen to NOT to pay heed to legislative demands imposed by  countries in the crypto area, for many years. See the RFCs for S/MINE and TLS as examples. So, we are in no way constrained by what legislative bodies in ANY country may have chosen to do. (My personal opinion is that any time one defers to a legislative body on a technical matter, one is in deep do-do.)
Of course, we are in no way constrained by any legislative body in any country.
 But, my point is that we should not deviate from the reality.
I am a technical person too. Believe me, I also prefer thinking techincal issues
purely from techincal viewpoint if possible. Unfortunately, the reality is there, the
real world is complex. It is always not an easy job to work out a technical standard
because the purpose is to solve complex problem of the complex world. Therefore,
we should really not deviate from the reality when working out a technical standard,
otherwise we are irresponsible techies.

The reality is a great percentage of X.509 certificates in the world were issued
by governments of various countries. Why? Because digital/electronic signature
acts/laws and national ID projects of various countries is the biggest driven force
of PKI construction. Think about millions of X.509 certificates issued by verious
government PKI's.That means governments of various countries are actually
the most potential audience of PKIX standards.  Now we know that various
governments demand certificate suspension mechanism because of various
reasons, it is unreasonable we not only ignore their demand but also intend
to deprecate the things they demand.

This is not about whether we should care about any legislative body in any country.
This is about we should care about the demand of the real world.

  Suspension is a wimpy approach to revocation. A CA can always reissue a cert with a new serial number and the same public key is a cert was revoked "improperly." Suspension is just a way for a CA to avoid legal liability.

Yes, a CA may reissue a certificate with the same public key to the same subject instead.
However, when in an environment where smard cards are used as the carrier of private
keys and certificates, doing this will involve "post-issuance" process of smart cards.
Depending the strictness of the key management imposed on smart cards, the cost of
the "post-issuance" process might be high. In the reality, the cost does matter. Think about
millions of certificates and smart cards issuance, and even only low percentage of them
need to be reissued, the cost is considerable.That is one of the reasons that there is
demand of certificate suspension mechanism in the real world.

I do not think suspension is just a way for a CA to avoid legal liability. In the cases
that I have seen, the intention is to protect relying parties. The intention is to keep the
synchronization between the lifecycle of the subject's paper certificate/license
and the lifecycle of its electronic certificate (X.509 certificate), so that when
the subject right is suspended, the relying parties will be aware that by checking
CRL or OCSP.

Wen-Cheng Wang

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Thu, 30 Nov 2006 20:51:49 +0800

> anyway, this can't get worse IMHO
Then should'nt we work out a interoperable interpretation of suspension
rather than just deprecate it.

Wen-Cheng Wang

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Thu, 30 Nov 2006 20:49:17 +0800

> certificate is valid" ? :-/ )

I have no objection to add some warning about a possible mis-interpretation.
But to deprecate the suspension mechanism? That is another thing.

> here (if I understood it correctly), as pointed out by many others on the list.

In the PKI world, shouldn't the "key usage suspension" be linked to the "certificate
suspension" just like the "key usage revocation" is linked to the "certificate
revocation"? Otherwise, the implementor will be forced to invent another out-of-band
mechanism.

> against possible misuse of the feature...
Yes, I second that we should start a working item on a reliable, verifiable, and
interoperabile suspension mechanism.

Wen-Cheng Wang

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 30 Nov 2006 13:12:41 +0000

> interoperabile suspension mechanism.

Count me as a -1 for that. I don't believe we do want a suspension
mechanism really.

Stephen.