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

From: [email-masked]
Date: Thu, 03 May 2001 20:15:50 +0000

Here again is an instance where the protocol structure 
starts to invade the domain of the use model. 

As the hold-over CRL's anyone that wants to use a CRL 
should be prepared to query the CRL server and to find 
out when the last update was made. That's just common 
sense -- 

Also this should be left up to the App developer since 
it may change in any number of situations.

--
Regards,
Todd
> Russ and Denis,
> 
> I was somewhat confused about your positions on the "hold" feature.
> Having read the email below, I am now REALLY confused.
> 
> Based on context, I interpreted Denis' comment:
> "So I am not advocating the addition of on hold now."
> to mean
> "I have not recently switched my position on 'hold'."
> 
> Denis, is that correct?
> 
> Russ, it appears from your comment:
> "Fair reply.  And, unless there is a ground swell of
> support, I will drop it."
> that you have interpreted Denis as meaning
> "I have withdrawn my support for 'hold'."
> 
> Russ, is that correct?
> 
> And Russ, I am further confused by "... I will drop it."
> 
> Did you mean that you will add text to prohibit compliant
> CA's from issuing delta CRL's that include "hold" and
> "removeFromCRL" reason codes or text that will prohibit
> this for full CRL's as well as delta-CRLs, or did you
> mean something else entirely?
> 
> Regards,
> 
> Carlin
> 
> ____________________________
> 
> -  Carlin Covey
>    Cylink Corporation
> 
> -----Original Message-----
> From: Housley, Russ [mailto:[email-masked]]
> Sent: Thursday, May 03, 2001 10:17 AM
> To: Denis Pinkas
> Cc: [email-masked]
> Subject: Re: delta CRLs
> 
> 
> Denis:
> 
> > > >5.2.4  Delta CRL Indicator
> > > >
> > > >    The delta CRL indicator is a critical CRL extension that identifies
> > > >    a CRL as being a delta CRL. A delta-CRL is a CRL that only provides
> > > >    information about certificates who statuses have changed since the
> > > >    issuance of a specific, previously issued CRL. The use of delta
> > >
> > > I do not like the second sentence any better than the original.  How
> about:
> > >
> > >     A delta CRL provides an updates a previously issued complete CRL.
> > >     A delta CRL only includes entries for certificates that have changed
> > >     status since the complete CRL was issued.
> >
> >This sentence was nearly a copy and paste from a sentence written by David
> >Cooper in his paper. I would have no problem to have two short sentences
> >instead of a long one. I would however like to make an observation. I have
> >been using the term "base CRL" when it is a CRL that is advertised to
> >support delta CRLs. I have ben using the term "complete" CRL for a CRL that
> >does NOT support delta CRLs. According to this convention, I would change
> >"complete" into "base". This would lead to:
> >
> >    A delta CRL provides an updates a previously issued base CRL.
> >    A delta CRL only includes entries for certificates that have changed
> >    status since the base CRL was issued.
> 
> Fine.
> 
> > > >    CRLs can significantly reduce network load and processing time in
> > > >    some environments.  Delta CRLs are generally much smaller than the
> > > >    CRLs they update, so applications that obtain delta CRLs consume
> > > >    less network bandwidth than applications that obtain the
> > > >    corresponding complete CRLs.
> 
> Did you want to rephrase this to get rid of complete here too?
> 
> > > >    The delta CRL indicator extension contains a single value of type
> > > >    BaseCRLNumber.  This value identifies the CRL number of the base
> CRL
> > > >    that was used as the foundation in the generation of this delta
> CRL.
> > > >    The referenced base CRL is a CRL that was explicitly issued as a
> CRL
> > > >    that is complete for a given scope (e.g., a set of revocation
> reasons
> > > >    or a particular distribution point.) The CRL containing the delta
> CRL
> > > >    indicator extension contains all updates to the certificate
> > > >    revocation status for that same scope.
> > > >
> > > >    When a delta CRL is issued, it MUST cover the same set of reasons
> > > >    and same set of certificates that were covered by the base CRL it
> > > >    references.
> > > >
> > > >    When a conforming CA issues a delta CRL, the delta CRL MUST include
> > > >    a critical delta CRL indicator extension.
> > > >
> > > >    An application can construct a CRL that is the most current for
> > > >    a given scope, for a specific date, by retrieving the appropriate
> > > >    base CRL for that scope, and combining it with a delta-CRL which
> > > >    contains a Delta CRL Indicator equal to the cRLNumber of the base
> > > >    CRL and where the date for which the construction is being made is
> > > >    between thisUpdate and nextUpdate as indicated the delta CRL.
> >
> > > Can we focus on the most common case?  How about:
> >
> > >     An application can construct an updated CRL by retrieving the
> > >     appropriate base CRL for that scope, and combining it with a delta
> > >     CRL which contains a delta CRL indicator extension with the same
> > >     CRL number as the base CRL.
> >
> >This does not work, since the sentence does not speak anymore about the
> time
> >and thus there is no guaranty that what you get is the "freshest". Remember
> >that the extension for advertising delta is (mis-)named freshestCRL !
> >I would have no problem to have two short sentences instead of a long one.
> >How about:
> >
> >    An application can construct an updated CRL, for a specific time T,
> >    by retrieving the appropriate base CRL for that scope, and combining
> >    it with a delta CRL which contains a delta CRL indicator extension
> >    with the same CRL number as the base CRL. Time T MUST fall between
> >    thisUpdate and nextUpdate for both the base CRL and the delta CRL.
> 
> Okay, however, we should say: Applications that support delta CRLs MUST
> ensure that time T falls between thisUpdate and nextUpdate for both the
> base CRL and the delta CRL.
> 
> > > >    Conforming implementations of this specification are not required
> > > >    to implement the above algorithm, but MUST provide functionality
> > > >    equivalent to the external behavior resulting from this procedure.
> >
> > > No.  We do not presently require CRL implementation.  The paragraph
> would
> > > seem to change that situation, and require CRL and delta CRL
> > > implelmentation.  I suggest that the previous paragraph be omitted.
> >
> >I understand what you mean, but this was not the intent. How about:
> >
> >    Conforming implementations supporting delta-CRLs are not required
> >    to implement the above algorithm, but MUST provide functionality
> >    equivalent to the external behavior resulting from this procedure.
> 
> Reading the previous paragraph, I do not think that we need to have this
> paragraph at all.  The previous paragraph does not actually include an
> algorithm.
> 
> > > >    CAs must ensure that application of a delta CRL to the referenced
> > >
> > > Change "CAs must" to "Conforming CAs that support CRLs and delta CRLs
> > MUST".
> >
> >Fine.
> >
> > > >    base revocation information accurately reflects the current status
> of
> > > >    revocation.  If a CA supports the certificateHold revocation reason
> > > >    the following rules must be applied when generating delta CRLs:
> >
> > > I argued against the inclusion of support for certificate hold in RFC
> > > 2459.  Your text demonstrates the complexity of supporting this feature.
> I
> > > am quite concerned that this topic is being raised so late in the
> > > process.  We are in WG Last Call ...  [Denis, you will recall that you
> made
> > > a similar response to a comment that I made regarding TSP.]
> >
> >The text was there, it has not been added now. I have only corrected the
> >text. So I am not advocating the addition of on hold now. I could reverse
> >the argument saying that I am surprised that in WG last call, *you* now
> >would like certificate hold to be removed everywhere in the document.
> 
> Fair reply.  And, unless there is a ground swell of support, I will drop it.
> 
> >Coming back to the technical arguments only, when "on hold" was introduced
> >(many years ago) I originally believed that there could be some problems
> >when being used in the context of a non repudiation service. I have not
> >been able to find a single case where there would be a problem.
> 
> When trying to determine if a certificate was valid at a particular time T
> (in the significant past), an application must recreate the history of
> on-hold/off-hold events near time T.
> 
> > > I am still concerned about the significant complexity that certificate
> hold
> > > adds.  It makes non-repudiation even more difficult.  Further, I am not
> > > convinced that there is really a constituency for this feature.
> > >
> > > I would be very happy if we changed the profile to say that conforming
> CAs
> > > MUST NOT use certificateHold.  I would be happy  if we changed the
> profile
> > > to say that conforming CAs SHOULD NOT use certificateHold. I would be
> quite
> > > upset if we require clients to support certificateHold in any manner
> other
> > > than simply revoked.  (Note that section 5.3.2 provides the conformant
> > > application the alternative of simply rejecting the certificate.)
> >
> >This is clearly a much wider topic, that is not solely directed to
> >delta-CRLs. So I would request that people interresting to debate along
> this
> >topic change the title of the thread to someting like: "certificate hold".
> >
> >As far as I am concerned, until I will see an argument where the use of
> hold
> >creates more problems than its non-use, I see no reason why we should make
> a
> >change to the document.
> 
> Fair request.
> 
> Russ
>

---

From: "Tom Gindin" <[email-masked]>
Date: Fri, 4 May 2001 18:50:08 -0400

I don't know why this particular feature is so unpopular.  I can
understand why handling "removeFromCRL" in deltas could be an extra load on
clients, but wouldn't the maximum remedy for that be to say that CA's which
issue delta CRL's SHOULD NOT use hold, while RP's MAY process
removeFromCRL?  What extra complexity does hold add to an RP for a CA which
doesn't issue deltas but issues full CRL's (perhaps full distribution point
CRL's) instead?

          Tom Gindin

Stephen Kent <[email-masked]> on 05/04/2001 02:42:33 PM

To:   "Housley, Russ" <[email-masked]>
cc:   [email-masked]
Subject:  RE: Certificate Hold  (was RE: delta CRLs)

At 1:30 PM -0400 5/4/01, Housley, Russ wrote:
>Carlin:
>I have NEVER liked the on-hold feature.  I still do not like the
>on-hold feature.
>
>I will not delay the Last Call process on son-of-rfc 2459 to debate
>the issue unless I see that there are others that support my view.

I feel the same as Russ, i.e., have never liked it and still think
it's a bad idea. Since we deprecated the hold instruction (vis our
comments on the hold instruction code entry extension) last time, is
there are basis for change this time around?

Steve

---

From: Santosh Chokhani <[email-masked]>
Date: Sat, 5 May 2001 07:58:09 -0400

Tom:

I also am not a fan of "hold: feature.  But, I fail to see why
"removeFromHold" is in delta CRL is unduly complex.  I would say either not
have the "hold" feature or require "hold' and "release" irrespective of
delta.

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]]
Sent: Friday, May 04, 2001 6:50 PM
To: Stephen Kent
Cc: Housley, Russ; [email-masked]
Subject: RE: Certificate Hold (was RE: delta CRLs)

          Tom Gindin

Steve

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 07 May 2001 08:36:04 -0400

Tom:

It is not that simple.

In my view, non-repudiation is significantly complicated by the processing 
necessary to determine whether a certificate was suspended (a.k.a., on 
hold).  This is a topic that you do not discuss in your Internet Draft on 
non-repudiation.

Russ

---

From: "Tom Gindin" <[email-masked]>
Date: Mon, 7 May 2001 11:32:49 -0400

I don't actually think that "removeFromCRL" is unduly complex, nor did
I say so.  What I wanted to point out was that when delta CRL's are not in
use the "certificateHold" reason adds no extra complexity to standard CRL
processing at all (exclusive of NR, which is not a simple case), and
therefore I can't understand why anyone would want to deprecate that
reason.

          Tom Gindin

Santosh Chokhani <[email-masked]> on 05/05/2001 07:58:09 AM

To:   Tom Gindin/Watson/IBM@IBMUS, Stephen Kent <[email-masked]>
cc:   "Housley, Russ" <[email-masked]>, [email-masked]
Subject:  RE: Certificate Hold (was RE: delta CRLs)

Tom:

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]]
Sent: Friday, May 04, 2001 6:50 PM
To: Stephen Kent
Cc: Housley, Russ; [email-masked]
Subject: RE: Certificate Hold (was RE: delta CRLs)

CRL's) instead?

          Tom Gindin

Steve

---

From: Peter Williams <[email-masked]>
Date: Mon, 07 May 2001 11:17:46 -0700

The impact of suspending of the operational period (aka
the subscribers sining authority) of a certificate by suspension
is discussed at length in the ABA's legal infrastructure for
certification and e-commerce. Suspending a certificate
suspends the operational period, and directly impacts
the outcome of the process of verification of a digital 
signature. Clearly, an unverifiable impacts ISO NR.

When a notarial service confirms a signature upon countersigning
data, it is responsible for establishing that the
signing authority is effective. This means technically,
that it must 'determine' whether the certificate is currently
operational by reference to the official repository
that maintains the records controlling certificate status,
where status is "issued, {valid*, operational*, revoked}, expired}

If any CRL or signed CertificateList reflects the official
repository records accurately, then that object can
signal operational period.

Repositories will suspend certificate, whether or
not CRLs signal that state. NR is a function
of the repository records and other factors, not the 
CRL which may not even serve as an adequate record. 
In X.509, a CRL is but one bit format for communicating
revocation notices. Whether the notices have
force upon the NR conditions is controlled by repository
records management processes.

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
Sent: Monday, May 07, 2001 5:36 AM
To: Tom Gindin
Cc: [email-masked]
Subject: RE: Certificate Hold (was RE: delta CRLs)

Tom:

It is not that simple.

Russ

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 09 May 2001 09:12:39 -0400

Hal:

The reality is that people are binding authorization information into 
certificates, and the hold is really being placed on the authorization, not 
the binding of the public key and the identity.  This is one of the major 
reasons that I advocate the placement of authorization information 
elsewhere, like attribute certificates.

Russ

At 11:47 AM 5/8/2001 -0400, Hal Lockhart wrote:
>  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