Subject: RE: delta-CRLs and NR

From: Santosh Chokhani <[email-masked]>
Date: Tue, 24 Apr 2001 15:11:09 -0400

Mike:

You do NOT need to accumulate all the relevant deltas.  You only need the
referenced base or later and the delta in "your hand" to create a full
revocation picture.

-----Original Message-----
From: Michael Myers [mailto:[email-masked]]
Sent: Tuesday, April 24, 2001 2:32 PM
To: Tom Gindin
Cc: David P. Kemp; [email-masked]
Subject: RE: delta-CRLs and NR

Tom,

Perhaps I should have used the term "dispute resolution process" instead of
"non-repudiation".  I was thinking more in terms of that process and the
general notion that one can never have too much documentation proving one's
point--i.e. in this case the indisputably "full" CRL-- whereas in day to day
activities the efficiencies gained by deltas cover what undoubtedly will be
the vastly larger number of undisputed transactions.

So I was thinking that it would be unwise for us to needlessly burden 99%(?)
of the solution space to address issues associated with the remaining 1%,
hence break out fulls from deltas.  Now, I'm not a lawyer, but that all
said, I think the assured presence of a full CRL in the case of a "dispute
resolution event" would very useful to that 1%.  One is otherwise faced with
proving that one had fully accumulated all relevant deltas.  Thus mandate
fulls as an assured baseline regardless of the PKI context, but with perhaps
a longer production period that nonetheless contributes evidence to a
possible discovery process.  Again, I'm not a lawyer, but I have played with
them on the street.

Ultimately, I'm still convinced that the only effective resolution is a
dynamically produced, digitally signed assertion (i.e. OCSPv2 with its DPV
extension).  But that's an entirely different buffalo hunt.

Mike

> -----Original Message-----
> From: Tom Gindin [mailto:[email-masked]]
> Sent: Tuesday, April 24, 2001 10:43 AM
> To: Michael Myers
> Cc: David P. Kemp; [email-masked]
> Subject: RE: delta-CRLs and NR
>
>
>
>      When non-repudiation is an actual practice, doesn't the revocation
> status need to be checked as of a time no earlier than the actual
> signature
> of the non-repudiable message or document?  And won't a full CRL (or a
> delta, for that matter) rarely have been published with such an effective
> time at the time an RP initially receives such a message or document?
>      It is perfectly true that it is much easier to check a
> single full CRL
> than a CRL with deltas.  However, I don't see why the problem is more
> severe for NR except that an NR system is even less tolerant of false
> negatives on revocation than authentication is.
>
>           Tom Gindin
>

---

From: "Michael Myers" <[email-masked]>
Date: Tue, 24 Apr 2001 12:25:48 -0700

I understand.  But the trajectory of the dialog seemed to be suggesting
elimination the full CRL context, hence in that forward scenario one would
have no choice but to face the accumulation task.  Also, the proposal to
enable a different period of production between a full CRL and its
associated deltas (thus enabling periods of delta-only activity between full
CRL production) does suggest that there might exists cases where more than
one delta is necessary to span the gap between fulls.

Mike

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Tuesday, April 24, 2001 12:11 PM
To: Michael Myers; Tom Gindin
Cc: David P. Kemp; [email-masked]
Subject: RE: delta-CRLs and NR

Mike:

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 24 Apr 2001 15:43:45 -0400

This is a misunderstanding of the way that delta-CRLs work. A delta-CRL specifies a base CRL and  provides a list of all certificates whose status has changed since the base CRL was issued. When using the deltaCRLIndicator, the referenced base CRL must have been issued as a full CRL (i.e., not a delta). Thus, one can always obtain complete revocation information by applying a single delta-CRL to the base CRL that it references.

If delta-CRLs are issued more frequently than full CRLs, this will just mean that multiple delta-CRLs will reference the same full CRL as their base.

With the current PKIX standard, one can always get complete revocation information by just obtaining a full CRL. If the rules were relaxed, one would be required to obtain one full CRL and one delta-CRL.

Dave

---

From: "Carlin Covey" <[email-masked]>
Date: Tue, 24 Apr 2001 13:35:50 -0700

David,

You are correct for delta-CRLs defined with the deltaCRLIndicator, but
it is also possible to define delta-CRLs using the CRL scope extension.

X.509 Ed. 4 v6 says the following in section 8.5.2.5 'CRL scope extension':

"In the crlScope case, the information in the baseRevocationInfo
component, indicates the point in time from which the CRL containing
this extension provides updates. Although this is done by referencing
a CRL, the referenced CRL may or may not be one that is complete for
the applicable scope, whereas the deltaCRLIdentifier extension references
an issued CRL that is complete for the applicable scope."

In an earlier email I made the following observation and asked a question:

"I don't see anywhere in draft-ietf-pkix-new-part1-05 where it says
that a delta CRL must be identified by a deltaCRLIndicator extension.
It does say that "The delta CRL indicator is a critical CRL extension
that identifies a CRL as being a delta CRL."  This appears to be a
sufficient
condition, but not a necessary condition, for the CRL to be interpreted as a
delta CRL.  So a PKIX-profile-compliant CRL-issuer could use the crlScope
extension rather than the deltaCRLIndicator extension to identify delta
CRLs?

      -  Russ, is that right?"

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation

-----Original Message-----
From: David A. Cooper [mailto:[email-masked]]
Sent: Tuesday, April 24, 2001 12:44 PM
To: [email-masked]
Subject: RE: delta-CRLs and NR

This is a misunderstanding of the way that delta-CRLs work. A delta-CRL
specifies a base CRL and  provides a list of all certificates whose status
has changed since the base CRL was issued. When using the deltaCRLIndicator,
the referenced base CRL must have been issued as a full CRL (i.e., not a
delta). Thus, one can always obtain complete revocation information by
applying a single delta-CRL to the base CRL that it references.

If delta-CRLs are issued more frequently than full CRLs, this will just mean
that multiple delta-CRLs will reference the same full CRL as their base.

With the current PKIX standard, one can always get complete revocation
information by just obtaining a full CRL. If the rules were relaxed, one
would be required to obtain one full CRL and one delta-CRL.

Dave

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 24 Apr 2001 17:05:59 -0400

Carlin,

The quote that you included about the cRLScope extension is correct, but the end result is (nearly) the same whether delta-CRLs are identified using the cRLScope extension or the deltaCRLIndicator extension. In addition to the text that you quoted, X.509 (Ed. 4 v7 is the latest) section 8.5.2.5 states the following about the cRLScope extension:

         the cRLNumber referenced in the BaseRevocationInfo field of a dCRL shall be less than or equal
         to the cRLNumber of the most recently issued CRL that is complete for the applicable scope.

So, while the base CRL referenced by the delta-CRL may not have been issued as a full CRL, there will be at least one CRL, issued as a full CRL, against which the delta-CRL may be applied to obtain complete certificate status information. The full CRL may have been issued after the referenced base CRL, but one can still apply the delta-CRL to that full CRL.

As to your second question, the PKIX certificate and CRL profile does not include the cRLScope extension. So, while X.509 provides two ways to identify a CRL as being a delta-CRL, PKIX only provides the deltaCRLIndicator. Would a CRL issuer that used the cRLScope extension be non-PKIX-compliant? I'll leave that to others to decide.

Dave

---

From: "Carlin Covey" <[email-masked]>
Date: Tue, 24 Apr 2001 15:41:03 -0700

David,

Thank you for pointing out the "..less than or equal.."
phrase.  I had missed the significance.

My preference is that delta-CRL's be identified only by
the deltaCRLIndicator extension, rather than the
cRLScope extension.

I propose that the following "sufficient condition" in the
PKIX profile

"The delta CRL indicator is a critical CRL extension
that identifies a CRL as being a delta CRL."

be reworded as a "necessary condition" along the lines of

"A delta CRL MUST be identified via the delta CRL indicator
extension, which MUST be marked as a critical CRL extension."

Regards,

Carlin

-  Carlin Covey
   Cylink Corporation

-----Original Message-----
From: David A. Cooper [mailto:[email-masked]]
Sent: Tuesday, April 24, 2001 2:06 PM
To: [email-masked]
Subject: RE: delta-CRLs and NR

Carlin,

The quote that you included about the cRLScope extension is correct, but the
end result is (nearly) the same whether delta-CRLs are identified using the
cRLScope extension or the deltaCRLIndicator extension. In addition to the
text that you quoted, X.509 (Ed. 4 v7 is the latest) section 8.5.2.5 states
the following about the cRLScope extension:

         the cRLNumber referenced in the BaseRevocationInfo field of a dCRL
shall be less than or equal
         to the cRLNumber of the most recently issued CRL that is complete
for the applicable scope.

So, while the base CRL referenced by the delta-CRL may not have been issued
as a full CRL, there will be at least one CRL, issued as a full CRL, against
which the delta-CRL may be applied to obtain complete certificate status
information. The full CRL may have been issued after the referenced base
CRL, but one can still apply the delta-CRL to that full CRL.

As to your second question, the PKIX certificate and CRL profile does not
include the cRLScope extension. So, while X.509 provides two ways to
identify a CRL as being a delta-CRL, PKIX only provides the
deltaCRLIndicator. Would a CRL issuer that used the cRLScope extension be
non-PKIX-compliant? I'll leave that to others to decide.

Dave

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 25 Apr 2001 15:50:54 -0400

Carlin:

As David Cooper has already pointed out, only the deltaCRLIndicator is part 
of the profile.  The profile allows the use of other extensions.  However, 
other extensions SHOULD not be critical (since they reduce interoperability).

Russ

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 26 Apr 2001 14:42:38 -0400

Carlin:

I would prefer to leave the first sentence alone.  I think that it is 
explanation of delta CRLs.  However, I like your point, and suggest the 
addition of the following paragraph:

    When a conforming CA issues a delta CRL, the delta CRL MUST include a
    critical delta CRL indicator extension.

Russ

---

From: "Carlin Covey" <[email-masked]>
Date: Fri, 27 Apr 2001 08:43:26 -0700

Russ,

I'm perfectly comfortable with your wording (and it seems better than mine).

- Carlin

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
Sent: Thursday, April 26, 2001 11:43 AM
To: Carlin Covey
Cc: [email-masked]
Subject: RE: delta-CRLs and NR

Carlin:

Russ

At 03:41 PM 4/24/2001 -0700, Carlin Covey wrote:
> >condition, but not a necessary condition, for the CRL to be interpreted
as
>a