Subject: RE: Certificate Hold (was RE: delta CRLs)

From: Santosh Chokhani <[email-masked]>
Date: Tue, 8 May 2001 11:48:08 -0400

Some times people put a certificate on hold because some one is out of
pocket for a while.  In that case, the signatures made during the hold
period should be considered invalid.

-----Original Message-----
From: Hal Lockhart [mailto:[email-masked]]
Sent: Tuesday, May 08, 2001 11:47 AM
To: 'Ambarish Malpani'; 'Housley, Russ '; 'Tom Gindin '
Cc: [email-masked] '
Subject: RE: Certificate Hold (was RE: delta CRLs)

 Ambarish Malpani wrote: 
> Certificate suspension is a useful mechanism to prevent the usage of
> a certificate while you figure out whether it should actually be
> revoked or not. 

Forgive me if this has been discussed in the past, but I am curious. If this
is the (only) purpose of hold, doesn't that simplify the NR issue? If the
cert can be established to be good at a later time, shouldn't the hold be
ignored? If the results of our investigation is that there was actually no
problem after all, why should signatures created during that period be
invalid?

Hal

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 10 May 2001 10:54:16 +0200

Santosh,

> pocket for a while.  

True and this is a good reason to support the hold condition whether CRL or
OCSP is being used. This makes no difference. The support of the hold
condition MUST not be deprecated when supported by CRLs.

> In that case, the signatures made during the hold

The anwser is not as simple as above. During the on-hold period, two cases
have to be addressed: either the verifier cannot wait or it can wait.

1) If it cannot wait, then a safe decision has to be taken: the signature is
invalid. This is the case when the signature is used for real time use:
authentication and /or access control purposes.   

2) If it can wait, then it may postpone the decision at the end of the "on
hold" period. If the certificate number is added to the CRL and marked
definitively revoked, then the signature is invalid. If the certificate
number is removed from the CRL, then the signature is valid. This case
applies for non repudiation purposes.

Denis

---

From: Dr S N Henson <[email-masked]>
Date: Thu, 10 May 2001 14:43:10 +0100

Wrt certficate hold I'm not against its use being deprecated in CRLs.

AFAICS ambiguity arises in the following scenario:

1. A certificate is placed on hold but later removed and the certificate
is declared valid again.
2. Some transactions were made using the certificate while it was on
hold.
3. A verifier needs to determine the validity of the transactions after
the hold period.

There are two separate interpretations depending on the individual
situation.

1. Since the certificate is now valid the transactions are now valid.
2. Because the transactions were made during the hold period they should
be declared invalid.

Its case 2 that causes problems. The verifier really needs to know
whether the certificate was on hold at the time the transaction took
place. This information may not always be available, if all it has is a
current CRL.

Because of this problem I'd say that some clarification is needed as to
the use of certificate hold. 

IMHO we should say that hold MUST NOT be used in this way.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [email-masked] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [email-masked] PGP key: via homepage.

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 10 May 2001 17:54:43 +0200

> the use of certificate hold.

Remember that OCSP has three states:

° Yes
° No,
° Don't know.

The same applies here: there is also a "don't know" condition. Take a look
at my response sent today on that thread.

Regards,

Denis

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 10 May 2001 10:08:29 -0700

Steve, Denis, all:

A few points on this thread as it relates to OCSP, and especially to the
current OCSPv2 work.  First, among Steve Kent's DPV/DPD requirements
assertions coming out of San Diego was the following:

"1.3 A client request to a DPV server can specify the time relative to which
the validation is to be performed. If omitted, the current time is assumed."

In response the OCSPv2 editorial team added a validAt Generalized time field
to DPVOptions in the OCSPv2 I-D:

"DPVOptions  :: = SEQUENCE{
    initialPolicySet  [0]   EXPLICIT PolicyList OPTIONAL,
    trustPoints       [1]   SEQUENCE OF ReqCert OPTIONAL,
    validAt           [2]   GeneralizedTime     OPTIONAL,
    revInfo           [3]   SEQUENCE OF RevocationInfo      OPTIONAL }"

Thus in the presence of the practice of certificate suspension, a
certificate's status may be "valid" at {validAt = N}, "invalid" at {validAt
= N+t}, at again "valid" at {validAt = N+t+x}.  I assume signature
validation would track correspondingly but leave that issue for those
working on signature validation to deal with.

Also, originally established in RFC2560 and maintained in the OCSPv2 I-D is
the Archive Cutoff extension (this reference is from the OCSPv2 I-D but the
essential text is the same in RFC2560):

"8.4	Archive Cutoff

An OCSP responder MAY retain information relevant to a certificate's
validity
beyond a certificate's expiration. The date obtained by subtracting this
retention interval value from the producedAt time in an ORS or DPV response
is
defined as the certificate's "archive cutoff" date.  Applications would use
an
archive cutoff date to contribute to a proof that a digital signature was
(or
was not) reliable on the date it was produced even if the certificate needed
to
validate the signature has long since expired.  OCSP servers SHOULD include
an
archive cutoff date extension in responses where applicable.  If included,
this
value SHALL be provided as an OCSP singleExtensions extension identified by
id-
pkix-ocsp-archive-cutoff and of syntax GeneralizedTime.

   id-pkix-ocsp-archive-cutoff  OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }

   ArchiveCutoff ::= GeneralizedTime

To illustrate, if a server is operated with a 7-year retention interval
policy
and status was produced at time t1 then the value for ArchiveCutoff in the
response would be (t1 - 7 years)."

Thus a relying party is informed by its chosen responding party that beyond
the identified archive cutoff date, no further information is available.
Among other effects, this sets a window on the effective use of the validAt
DPVOptions field.

Mike

Michael Myers
t: +415.819.1362
e: mailto:[email-masked]
w: http://www.traceroutesecurity.com