Subject: Re: I-D ACTION:draft-ietf-pkix-new-part1-07.txt

From: "Tom Gindin" <[email-masked]>
Date: Fri, 29 Jun 2001 13:30:44 -0400

Responses on the retrospective text only.

          Tom

Denis Pinkas <[email-masked]> on 06/29/2001 12:27:21 PM

To:   Tom Gindin <[email-masked]>, "Housley, Russ"
      <[email-masked]>
cc:   [email-masked], Tim Polk <[email-masked]>
Subject:  Re: I-D ACTION:draft-ietf-pkix-new-part1-07.txt

Tom and Russ,

>      I don't know if this will be considered helpful or not.

Yes, it is helpful and thank you for your explanations. This allows me to
respond to the second part of the e-mail from Russ as well.

We all agree that the construction of a CRL using a delta CRL in the past
is
only an option and thus the text has to use MAY and not MUST.

Having said that, when the application wants to do such a construction in
the past, we should give some guidance, and this is what you have done
below, using a MAY.

> While
> retrospective verification is certainly not a mandatory feature of RP
> software, there is a method for retrospective validation which is
> compatible with the proposed wording in part1.  (Please note that there's
a
> typo in that paragraph: 'compete' should be 'complete').  In the proposed
> paragraph below, the terms 'current' and 'most current' are given
meanings
> fully compatible with those in the proposed paragraph in part1 - a
> 'current' delta CRL in the sense of that proposal is a 'current' one as
of
> the present time in the sense of this.  I have not included the internal
> CRL possibility for retrospective validation, as it seems pointless in
such
> a case.

> An application that supports delta CRLs MAY be able to construct a
complete
> CRL for a reference time T prior to the current time by combining a
> complete CRL issued no later than T and the most current delta CRL as of
T.
> A delta CRL is considered to be a current one as of a given time T if T
is
> between the times contained in the thisUpdate and nextUpdate fields. If
> more than one current delta CRL for a given scope as of T is encountered,
> the application MUST consider the one with the latest value in thisUpdate
> to be the most current one; while if only one current delta CRL for a
given
> scope as of T is encountered, the application MUST consider it to be the
> most current one.

I have some problems with this text, first with "most current" and then
with
the two last MUST. I propose the following fix:

 An application that supports delta CRLs MAY be able to construct a
complete
 CRL for a reference time T prior to the current time by combining a
 complete CRL issued no later than T and a delta CRL valid as of T.
 A delta CRL is considered to be valid at a given time T if T is
 between the times contained in the thisUpdate and nextUpdate fields.
 If more than one current delta CRL for a given scope as of T is
 encountered, the application SHOULD consider the one with the latest value

 in thisUpdate to be the most current one; while if only one current delta
 CRL for a given scope as of T is encountered, the application SHOULD
 consider it to be the most current one. Note that if two delta CRLs, valid

 at time T, are placed in a repository, unless additional security measures

 are taken, there is no guarantee that both will necessarilly be seen.

[Tom] I'll leave SHOULD vs. MUST for Russ, although I don't understand what
would lead a retrospective verifier to use the second or third most current
delta CRL rather than the most current, if he recognizes them as such.
Your last sentence is helpful, although I don't think that the measures
which guarantee both deltas being seen are security measures.  The most
common reason to only see one would be an LDAP client implementation which
only picked up one value of a multi-valued attribute.

Note that in order to close this issue, we still need to agree on the
set of conditions to use the full CRL or the locally constructed
CRL to be used with the delta CRL.

Russ said: "Denis, I think you missed my point.  And, maybe I am missing
yours too." I think we can both agree on this statement. :-)

So using the text from draft-ietf-pkix-new-part1-07.txt I have tried to
show
which wording could be used:

Making a small fix to section 5.2.4, we could say:

   When a delta CRL is combined with a complete CRL or a locally
   constructed CRL, the resulting locally constructed CRL is equivalent
   to a full CRL which would have a local CRL number equal to the CRL
   number specified in the CRL number extension found in the delta CRL
   used in its construction. In addition, the resulting locally constructed
   CRL has the thisUpdate and nextUpdate times specified in the
   corresponding fields of the delta CRL used in its construction.
   In addition, the locally constructed CRL inherits the issuing
   distribution point from the delta CRL.

This means that we could solve the issue by saying:

A complete CRL or a locally constructed CRL and a delta CRL MAY be combined
if:

      (a)  The complete or locally constructed CRL and delta CRL have the
           same issuer.

      (b)  The complete or locally constructed CRL and delta CRL have the
           same scope.  The two CRLs have the same scope if either of the
           following conditions are met:

         (1)  The issuingDistributionPoint extension is omitted from
              both CRLs.

         (2)  The issuingDistributionPoint extension is present in both
              CRLs, and the values for each of the fields in the
              extensions are the same in both CRLs.

      (c)  The CRL number of the complete CRL is equal to or greater
           than the BaseCRLNumber specified in the delta CRL; or

      (d)  The local CRL number of the locally constructed CRL is equal
           to or greater than the BaseCRLNumber specified in the delta CRL.

One sentence should be moved from 5.2.3 to 5.2.4, since this is specific
with deltas, i.e:

   If a CRL issuer generates delta CRLs in addition to complete CRLs for
   a given scope, the complete CRLs and delta CRLs MUST share one
   numbering sequence.

... while the issue of identical CRL numbers could also be nicely solved
but
not allowing to issue a base CRL and a delta CRL exactly at the very same
second. This is, if I remember correctly, one option with which Tim Polk
could live with. This is implied by option B.

Denis

Annex for Russ only: Hereunder some text that I have been using before
making the above proposal. This shows that we do not need to use a local
CRL
numbering. I also believe that clause (f) is clearer than the current text,
but in order to try to close the discussion, I have as close as possible to
the text from draft 07.

A complete CRL or a locally constructed CRL and a delta CRL MAY be combined
if, first, the following two conditions are satisfied:

      (a)  The complete or locally constructed CRL and delta CRL have the
           same issuer.

      (b)  The complete or locally constructed CRL and delta CRL have the
           same scope.  The two CRLs have the same scope if either of the
           following conditions are met:

         (1)  The issuingDistributionPoint extension is omitted from
              both the complete CRL and the delta CRL.

         (2)  The issuingDistributionPoint extension is present in both
              the complete CRL and the delta CRL, and the values for each
              of the fields in the extensions are the same in both CRLs.

In addition, a complete CRL and a delta CRL MAY be combined if, the
following two other conditions are satisfied:

      (c)  The CRL number of the complete CRL is equal to or greater
      than the BaseCRLNumber specified in the delta CRL.  That is,
      the complete CRL contains (at a minimum) all the revocation
      information held by the referenced base CRL.

      (d)  The CRL number of the complete CRL is less than the CRL
      number of the delta CRL.  That is, the delta CRL follows the
      complete CRL in the numbering sequence.

      [If we now place the new text to say how to pick the right
      delta-CRL, and unless the CA is not conformant with section 5.2.3 !,
      the text under (d) is unnecessary, but I left it for the time being]

In addition, a locally constructed CRL and a delta CRL MAY be combined if,
the locally constructed CRL has been build using a full CRL that has a
cRLNumber either:

      (e)  equal to or greater than the base CRL number referenced
      in the delta CRL; or

      (f) lower than the base CRL number referenced in the delta CRL,
      provided that the delta CRL that has been used to make the
      construction has a CRL number greater than the base CRL number
      referenced in the delta CRL.

===================================================================
(snip)

---

From: "David P. Kemp" <[email-masked]>
Date: Fri, 29 Jun 2001 14:44:53 -0400

> only picked up one value of a multi-valued attribute.

Tom,

Wouldn't a retrospective verifier use a protocol other than LDAP to retrieve
non-current CRLs?  I believe that searching the CDP attributes on an LDAP
server would always return a single CRL for the current wallclock time.
Could there conceivably be an LDAP mechanism to return all CRLs issued
between 10:00 June 3 2001 and 9:30 June 4 2001, or would such a retrieval
requirement be better satisfied using some other protocol (database search,
http query, ftp get by directory/filename, etc.)?

In other words, is there a downside to profiling as single-valued any
directory attributes that hold CRLs?

I agree with Denis that identifying the fact that an unscheduled CRL
is missing is a security consideration.  If the consideration rose to
the level of a security concern (which I doubt), it could be addressed
by sequential numbering or by a new CRL extension holding a backpointer
to the previously-issued CRL.

Dave