Re: draft-ietf-pkix-ac509prof -> RFC?

[Hideyuki Odahara <[e-mail]>]

Sir

Thank you for an instant reply. 
Although not soon set easily to RFC, saying soon,
it is waiting to be set to RFC with expectation after this.
Moreover, since a question will be asked if there are some
questions, please let me know then. 

Thanks

----------
  Hideyuki Odahara $B!'(B [e-mail]


> Hi,
> 
> I'm not entirely clear exactly what question is being asked, 
> however, I *think* the answer is that I've got to make a few
> very minor changes and then that draft will be sent to the RFC 
> editor. In other words, the work on this specification is done, 
> it will be an RFC quite soon now, without any substantive 
> changes being made.
> 
> The minor changes to be made include adding a section saying 
> that there are no IANA consideration; updating to reflect a 
> couple of minor changes to the base X.509 document and a change 
> to allow some s/mime specifications to reference this document
> more easily.
> 
> I hope that answers your question,
> Regards,
> Stephen.
> 
> Hideyuki Odahara wrote:
> > 
> > Mr. Stephen Farrell
> > 
> > Thank you for your reply the example of use of an attribute the other
> > day.
> > I would like you to teach about RFC-izing of draft-ietf-pkix-ac509prof
> > today, and mail was given. While it is said that ac509prof has near
> > RFC-izing, it is not RFC-ized easily. Now, would you the argument is
> > progressing how much and teach [ when to RFC-be due to beized and ] this
> > draft?
> > Although humiliated a busy place, I ask of you well.
> > 
> > thanks





Received: by above.proper.com (8.9.3/8.9.3) id VAA15692 for ietf-pkix-bks; Thu, 31 May 2001 21:17:45 -0700 (PDT)
Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA15686; Thu, 31 May 2001 21:17:39 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f514Hfl20633; Thu, 31 May 2001 21:17:41 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Paul Hoffman / IMC" <[e-mail]>, <[e-mail]>
Subject: RE: Minor OID mistakes in OCSPv2 and the official OID list
Date: Thu, 31 May 2001 21:17:07 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <p05100330b73c94b28f54@[165.227.249.18]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Paul,

This is actually what I had in mind in the long run, an IANA level doc.  I
for one think we're close enough to get the machinery moving but I'm
deferring to you and Russ and whomever else to come back and say whether
that's a feasible thing to do or not right now.

Mike

> -----Original Message-----
> From: Paul Hoffman / IMC
>
> . . .
>
> - Make it an IANA registry
>
> . . .
>
> [etc. re: IANA]
>
> . . .
>
> Do we think we are ready enough for that yet?



Received: by above.proper.com (8.9.3/8.9.3) id SAA10338 for ietf-pkix-bks; Thu, 31 May 2001 18:30:36 -0700 (PDT)
Received: from tama3.tas.ntt.co.jp (tama3.tas.ntt.co.jp [192.68.248.40]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA10334 for <[e-mail]>; Thu, 31 May 2001 18:30:30 -0700 (PDT)
Received: from nttmail.ecl.ntt.co.jp (nttmail.tas.ntt.co.jp [192.68.248.11]) by tama3.tas.ntt.co.jp (8.9.3+3.2W/3.7W/01/21/00) with ESMTP id KAA14097; Fri, 1 Jun 2001 10:30:14 +0900 (JST) (envelope-from [e-mail])
Received: from dsa.isl.ntt.co.jp by nttmail.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/03/21/01) with ESMTP id KAA14253; Fri, 1 Jun 2001 10:30:12 +0900 (JST) (envelope-from [e-mail])
Received: from cats by dsa.isl.ntt.co.jp (8.9.3/isl-2.0) id KAA26471; Fri, 1 Jun 2001 10:30:10 +0900 (JST)
Date: Fri, 01 Jun 2001 10:30:46 +0900
From: Hideyuki Odahara <[e-mail]>
To: [e-mail]
Subject: Re: draft-ietf-pkix-ac509prof -> RFC?
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.00.03
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Sir

Thank you for an instant reply. 
Although not soon set easily to RFC, saying soon,
it is waiting to be set to RFC with expectation after this.
Moreover, since a question will be asked if there are some
questions, please let me know then. 

Thanks

----------
  Hideyuki Odahara $B!'(B [e-mail]


> Hi,
> 
> I'm not entirely clear exactly what question is being asked, 
> however, I *think* the answer is that I've got to make a few
> very minor changes and then that draft will be sent to the RFC 
> editor. In other words, the work on this specification is done, 
> it will be an RFC quite soon now, without any substantive 
> changes being made.
> 
> The minor changes to be made include adding a section saying 
> that there are no IANA consideration; updating to reflect a 
> couple of minor changes to the base X.509 document and a change 
> to allow some s/mime specifications to reference this document
> more easily.
> 
> I hope that answers your question,
> Regards,
> Stephen.
> 
> Hideyuki Odahara wrote:
> > 
> > Mr. Stephen Farrell
> > 
> > Thank you for your reply the example of use of an attribute the other
> > day.
> > I would like you to teach about RFC-izing of draft-ietf-pkix-ac509prof
> > today, and mail was given. While it is said that ac509prof has near
> > RFC-izing, it is not RFC-ized easily. Now, would you the argument is
> > progressing how much and teach [ when to RFC-be due to beized and ] this
> > draft?
> > Although humiliated a busy place, I ask of you well.
> > 
> > thanks




Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id RAA07558 for ietf-pkix-bks; Thu, 31 May 2001 17:51:01 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA07551 for <[e-mail]>; Thu, 31 May 2001 17:50:56 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Thu, 31 May 2001 17:51:17 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Thu, 31 May 2001 17:51:16 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <HR26TYCR>; Thu, 31 May 2001 17:48:21 -0700
Content-return: allowed
Date: Thu, 31 May 2001 17:48:21 -0700
From: Peter Williams <[e-mail]>
Subject: RE: cA flag and CRL issuers
To: Tony Bartoletti <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I think this was very good news.

Let me put Steve's apparent statements in simpler, declarative form
in which each numbered assertion is a self-contained truth devoid
of context, other than perhaps assuming the truth of an earlier 
numbered assertion:

1. OCSP can be used in side-effect modes.

2. It is legitimate to use OCSP responder working in a
side effect mode to achieve the goals T&B cite

3. You can "rely" on an OCSP responder/response.

4. You can combine an OCSP side effect mode with reliance
on an OCSP responder/respose.

5. A relying party can rely upon an OCSP responder working
in side effect mode "V" as "a local means of asserting per-certificate
validity
judgements that might override those of the CA who issued a cert."

6. To use and rely on an OCSP responder operating in side effect
mode "V" is to be operating in a manner compatible with the PKIX
overall model.

7. The same general theory holds for a DPV server.


Do you agree that some or all of my numbered assertions are consistent
with Steve's message, as you intepreted it?

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Wednesday, May 30, 2001 7:24 PM
To: Tony Bartoletti
Cc: [e-mail]
Subject: Re: cA flag and CRL issuers


Tony & Bob,

This discussion re revocation seems to be colored by excessive use of
the term "trust."  It's common to use that term in discussing PKIs,
and the public CA approach to PKI, exemplified by VeriSIgn,
encourages that notion, because such CA are viable only if "trusted."

However, that is not the only way to think about roles in a PKI.  If
CAs are aligned with physical world entities that are authoritative
for the data contained in certs, e.g., companies issuing certs for
employees, then these CAs are not "trusted" in the same way that one
trusts a public CA.  Moreover, CAs of this sort are authoritative for
revocation, just as they are authoritative for cert issuance. Tony
seems to agree with this observation, but Bob feels that this is a
naive model re NR.  I will remind Bob that NR is not the only focus
of PKI, that this WG has expended way to much time arguing about NR
matters that seem to never be fully resolved in the technical domain,
and that the lack of uniform agreement re NR requirements suggests
that no single view of technical support for NR can be considered
authoritative.

What you tow are suggesting is a local means of asserting
per-certificate validity judgements that might override those of the
CA who issued a cert. While I can appreciate the motivations that you
cite for this, they are simply not consistent with the overall X.509
or PKIX models. We cannot tailor the specs to compensate for
questionable PKI implementation designs in apps such as browsers.

OCSP does allow for local configuration of a local source for
revocation information, and that would allow one to achieve the goals
you cite, if one relied on OCSP for revocation status.  DPV will
allow a similar configuration capability. So, I suggest that you be
content with the ability to achieve the stated effects via these
other protocols, which will provide the capability as a side effect
of their other design goals.

Steve


Received: by above.proper.com (8.9.3/8.9.3) id RAA07491 for ietf-pkix-bks; Thu, 31 May 2001 17:49:24 -0700 (PDT)
Received: from [165.227.249.18] (ip18.proper.com [165.227.249.18]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA07486 for <[e-mail]>; Thu, 31 May 2001 17:49:19 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100330b73c94b28f54@[165.227.249.18]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 31 May 2001 17:48:23 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: Minor OID mistakes in OCSPv2 and the official OID list
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

At 2:44 PM -0700 5/31/01, Michael Myers wrote:
>I (and I hope others too) deeply appreciate what Paul's doing for us but in
>the longer run I'm little bit concerned of direct linkage to a potentially
>ephemeral Web site.  I recall my aggravation years ago at having to hunt
>down authoritative references to OIW OIDs.

So, you got a few choices:

- Let { Paul | Tim | Steve | Russ | Peter :-) | someone } keep it on 
a web site that is hopefully well-known

- Put it in an Internet Draft that has to be updated at least every 
six months and is hopefully well-known

- Put it into an RFC that will be well-known but won't change

- Make it an IANA registry

The last one is preferable, if and only if we can come up with a 
clear and sensible mechanism for IANA to follow. That is the 
difficult part. This thread shows exactly how hard it is. The IANA 
folks are good record keepers, and they don't know diddly about ASN.1 
or PKIX, nor do they want to learn about it.

Probably the best way to let IANA run it is to have them not do the 
management, but to have an "OID reviewer" run a mailing list and that 
person is the only one who can tell IANA how the registry should 
change. This is essentially what we are doing now, except that the 
registry is on a web server somewhere, not at IANA. At the point we 
think the registry is well-cooked, someone must write an Internet 
Draft with the IANA rules, have it cycle here in the WG for a while, 
and eventually become an RFC. At that point, the registry goes to 
IANA.

Do we think we are ready enough for that yet?

--Paul Hoffman, Director
--Internet Mail Consortium


Received: by above.proper.com (8.9.3/8.9.3) id PAA00858 for ietf-pkix-bks; Thu, 31 May 2001 15:58:55 -0700 (PDT)
Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA00853 for <[e-mail]>; Thu, 31 May 2001 15:58:50 -0700 (PDT)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MA0R2DCD; Thu, 31 May 2001 15:52:07 -0700
From: "Carlin Covey" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Minor OID mistakes in OCSPv2 and the official OID list
Date: Thu, 31 May 2001 15:56:03 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Perhaps when (someday) PKIX concludes, the OIDs can be documented in
a non-ephemeral RFC.

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Peter Gutmann
Sent: Friday, June 01, 2001 10:14 AM
To: [e-mail]; [e-mail];
[e-mail]
Cc: [e-mail]
Subject: RE: Minor OID mistakes in OCSPv2 and the official OID list


"Michael Myers" <[e-mail]> writes:

>I (and I hope others too) deeply appreciate what Paul's doing for us but in
>the longer run I'm little bit concerned of direct linkage to a potentially
>ephemeral Web site.

As opposed to a non-ephemeral IETF draft?

Peter :-).




Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id PAA29270 for ietf-pkix-bks; Thu, 31 May 2001 15:29:58 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA29249 for <[e-mail]>; Thu, 31 May 2001 15:29:51 -0700 (PDT)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id SAA24203 for <[e-mail]>; Thu, 31 May 2001 18:29:53 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 31 May 2001 18:29:47 -0400
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: draft delta crl text
In-Reply-To: <[e-mail]. com>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====================_180332535==_"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--=====================_180332535==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

Folks,

Russ Housley, David Cooper, and I have tried to draft what we hope *will 
become* consensus text for the delta CRL and CRL number text.  We believe 
that the attached text clarifies (1) the requirements for "conforming 
applications that support CRLs", (2) the CRL issuer's responsibilities when 
including the delta CRL indicator and CRL number extensions, (3) the 
algorithm followed by a CRL issuer when determining what certificates 
should be listed on a delta CRL, and (4) the algorithm followed by an 
application when determining whether a complete CRL and a delta CRL may be 
combined.

To do this we have introduced a number of changes, beginning in section 
3.  In section 3, we introduce the "CRL issuer" in an enhanced version of 
the ASCII art model of a pKI (figure 1.)  In section 5, we define several 
more terms including CRL scope, base CRL, delta CRL and complete CRL.  All 
this was necessary to set the stage for the CRL number extension and delta 
CRL indicator extension text.

Please read these excerpts carefully.  We believe that the text is flexible 
enough to support reasonable implementations of delta CRLs, does not unduly 
burden clients that wish to support deltas, and is consistent with 
X.509.  When you read this please ask yourself if you can *live* with it.

The attachment contains the following excerpts:  Figure 1 from section 3, 
section 5 (the intro to CRLs), section 5.2.3 (CRL number extension) and 
5.2.4 (delta CRL indicator extension).  Please ignore the blank spaces; I 
was trying to remove anything irrelevant to this discussion.

Thanks,

Tim Polk
--=====================_180332535==_
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment; filename="deltacrl.txt"



INTERNET DRAFT                                                  May 2001


       +---+
       | C |                       +------------+
       | e | <-------------------->| End entity |
       | r |       Operational     +------------+
       | t |       transactions          ^
       | i |      and management         |  Management
       | f |       transactions          |  transactions
       | i |                             |                    PKI users
       | c |                             v
       | a | =======================  +--+------------+  ==============
       | t |                          ^               ^
       | e |                          |               |  PKI management
       |   |                          v               |      entities
       | & |                       +------+           |
       |   | <---------------------|  RA  |<----+     |
       | C |  Publish certificate  +------+     |     |
       | R |                                    |     |
       | L |                                    |     |
       |   |                                    v     v
       | R |                                +------------+
       | e | <------------------------------|     CA     |
       | p |   Publish certificate          +------------+
       | o |   Publish CRL                     ^      ^
       | s |                                   |      |  Management
       | i |                +------------+     |      |  transactions
       | t | <--------------| CRL Issuer |<----+      |
       | o |   Publish CRL  +------------+            v
       | r |                                      +------+
       | y |                                      |  CA  |
       +---+                                      +------+

                          Figure 1 - PKI Entities

   The components in this model are:

   end entity:  user of PKI certificates and/or end user system that
                is the subject of a certificate;
   CA:          certification authority;
   RA:          registration authority, i.e., an optional system to
                which a CA delegates certain management functions;
   CRL issuer:  an optional system to which a CA delegates the
                publication of certificate revocation lists;
   repository:  a system or collection of distributed systems that
                store certificates and CRLs and serves as a means of
                distributing these certificates and CRLs to end
                entities.





Housley, Ford, Polk, & Solo                                     [Page 9]

INTERNET DRAFT                                                  May 2001


   
   










   


   
   

  

   

   
   

   



   

5  CRL and CRL Extensions Profile

   As described above, one goal of this X.509 v2 CRL profile is to
   foster the creation of an interoperable and reusable Internet PKI.
   To achieve this goal, guidelines for the use of extensions are
   specified, and some assumptions are made about the nature of
   information included in the CRL.

   CRLs may be used in a wide range of applications and environments
   covering a broad spectrum of interoperability goals and an even
   broader spectrum of operational and assurance requirements.  This
   profile establishes a common baseline for generic applications
   requiring broad interoperability.  The profile defines a set of
   information that can be expected in every CRL.  Also, the profile
   defines common locations within the CRL for frequently used
   attributes as well as common representations for these attributes.

   The entity that issues the CRL is referred to as the CRL issuer.  In



Housley, Ford, Polk, & Solo                                    [Page 47]

INTERNET DRAFT                                                  May 2001


   general, CAs publish CRLs to provide status information on the
   certificates they generated.  However, a CA MAY delegate this
   responsibility to another trusted authority.  Whenever the CRL issuer
   is not the CA that issued the certificates, the CRL is referred to as
   an indirect CRL.

   Each CRL has a particular scope.  The CRL scope is the set of
   certificates that could appear on a given CRL.  For example, the
   scope could be "all certificates issued by CA X", "all CA
   certificates issued by CA X", "all certificates issued by CA X that
   have been revoked for reasons of key compromise and CA compromise",
   or could be a set of certificates based on arbitrary local
   information, such as "all certificates issued to the NIST employees
   located in Boulder".

   A complete CRL lists all un-expired certificates, within its scope,
   that have been revoked for one of the revocation reasons covered by
   the CRL scope.  The CRL issuer MAY also generate delta CRLs.  A delta
   CRL only lists those un-expired certificates, within its scope, whose
   revocation status has changed since the issuance of a referenced
   complete CRL. The referenced complete CRL is referred to as a base
   CRL.  The scope of a delta CRL MUST be the same as the base CRL that
   it references.

   This profile does not define any private Internet CRL extensions or
   CRL entry extensions.

   Environments with additional or special purpose requirements may
   build on this profile or may replace it.

   Conforming CAs are not required to issue CRLs if other revocation or
   certificate status mechanisms are provided.  Conforming CAs that
   issue CRLs MUST issue version 2 CRLs, include the date by which the
   next CRL will be issued in the nextUpdate field (see sec. 5.1.2.5),
   include the CRL number extension (see sec. 5.2.3), and include the
   authority key identifier extension (see sec. 5.2.1).  Conforming
   applications that support CRLs are required to process both version 1
   and 2 CRLs that are complete for a given scope.  Conforming
   applications are not required to support processing of delta CRLs or
   indirect CRLs.



   

   <<stuff deleted>>





Housley, Ford, Polk, & Solo                                    [Page 48]

INTERNET DRAFT                                                  May 2001


5.2.3  CRL Number

   The CRL number is a non-critical CRL extension which conveys a
   monotonically increasing sequence number for a given CRL scope and
   CRL issuer.  This extension allows users to easily determine when a
   particular CRL supersedes another CRL.  CRL issuers conforming to
   this profile MUST include this extension in all CRLs.

   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.  If a delta CRL and a complete CRL that cover the
   same scope are issued at the same time, they MUST have the same CRL
   number.  This indicates that the combination of the delta CRL and an
   acceptable complete CRL provide the same revocation information as
   the simultaneously issued complete CRL.

   If a CRL issuer generates a delta CRL and a complete CRL at different
   times, the delta and complete CRL MUST NOT have the same CRL number.
   That is, if the this update field (see sec. 5.1.2.4.)  in the delta
   and complete CRL are not identical, the CRL numbers are required to
   be different.

   id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }

   cRLNumber ::= INTEGER (0..MAX)

5.2.4  Delta CRL Indicator

   The delta CRL indicator is a critical CRL extension that identifies a
   CRL as being a delta CRL.  Delta CRLs contain updates to revocation
   information previously distributed, rather than all the information
   that would appear in a complete CRL.  The use of delta CRLs can
   significantly reduce network load and processing time in some
   environments.  Delta CRLs are generally smaller than the CRLs they
   update, so applications that obtain delta CRLs consume less network
   bandwidth than applications that obtain the corresponding complete
   CRLs.  Applications which store revocation information in a format
   other than the CRL structure can add new revocation information to
   the local database without reprocessing information.

   The delta CRL indicator extension contains the 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.  The CRL containing the delta CRL
   indicator extension contains all updates to the certificate
   revocation status for that same scope.  The combination of a CRL
   containing the delta CRL indicator extension plus the CRL referenced



Housley, Ford, Polk, & Solo                                    [Page 54]

INTERNET DRAFT                                                  May 2001


   in the BaseCRLNumber component of this extension is equivalent to a
   complete CRL, for the applicable scope, at the time of publication of
   the delta CRL.

   When a conforming CRL issuer generates a delta CRL, the delta CRL
   MUST include a critical delta CRL indicator extension.

   When a delta CRL is issued, it MUST cover the same set of reasons and
   the same set of certificates that were covered by the base CRL it
   references.  That is, the scope of the delta CRL MUST be the same as
   the scope of the complete CRL referenced as the base.

   An application that supports delta CRLs can construct a CRL that is
   complete for a given scope, at the current time, in either of the
   following ways:

      (a)  by retrieving the current delta CRL for that scope, and
      combining it with an issued CRL that is complete for that scope
      and that has a cRLNumber greater than or equal to the base CRL
      number referenced in the current delta CRL; or

      (b)  by retrieving the current delta CRL for that scope and
      combining it with a locally constructed CRL whose cRLNumber is
      greater than or equal to the base CRL number referenced in the
      current delta CRL.

   When a delta CRL is combined with a complete CRL or a locally
   constructed CRL, the resulting locally constructed CRL has the CRL
   number specified in the CRL number extension found in the delta CRL
   used in its construction.

   A complete CRL and a delta CRL MUST NOT be combined unless both of
   the following conditions are satisfied:

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

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

   CRL issuers MUST ensure that the combination of a delta CRL and any
   appropriate complete CRL accurately reflects the current status of
   revocation.  For each certificate whose status has changed since the
   generation of the referenced base CRL:




Housley, Ford, Polk, & Solo                                    [Page 55]

INTERNET DRAFT                                                  May 2001


      (a)  If the certificate is revoked for a reason included in the
      scope of the CRL, list the certificate as revoked.

      (b)  If not (a), list the certificate with the reason code
      removeFromCRL.

   It is appropriate to list a certificate with reason code
   removeFromCRL on a delta CRL even if the certificate was not on hold
   on the referenced base CRL.  If the certificate was placed on hold on
   any CRL issued after the base but before this delta CRL and then
   released from hold, it MUST be listed on the delta CRL with
   revocation reason removeFromCRL.

   Applications that support delta CRLs are not required to support
   local construction of CRLs.  Since the delta CRLs are required to
   reference a base CRL that was explicitly issued as a complete CRL,
   the information required to process delta CRLs is always available in
   a complete CRL.

   id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }

   baseCRLNumber ::= CRLNumber



   
   
   


   









   
   









Housley, Ford, Polk, & Solo                                    [Page 56]

--=====================_180332535==_--



Received: by above.proper.com (8.9.3/8.9.3) id PAA28152 for ietf-pkix-bks; Thu, 31 May 2001 15:14:21 -0700 (PDT)
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA28148 for <[e-mail]>; Thu, 31 May 2001 15:14:15 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id KAA23795; Fri, 1 Jun 2001 10:14:16 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <99134725610945>; Fri, 1 Jun 2001 10:14:16 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: Minor OID mistakes in OCSPv2 and the official OID list
Cc: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Fri, 1 Jun 2001 10:14:16 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

"Michael Myers" <[e-mail]> writes:

>I (and I hope others too) deeply appreciate what Paul's doing for us but in
>the longer run I'm little bit concerned of direct linkage to a potentially
>ephemeral Web site.

As opposed to a non-ephemeral IETF draft?

Peter :-).




Received: by above.proper.com (8.9.3/8.9.3) id OAA27506 for ietf-pkix-bks; Thu, 31 May 2001 14:45:16 -0700 (PDT)
Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA27492 for <[e-mail]>; Thu, 31 May 2001 14:45:10 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f4VLj8x01401; Thu, 31 May 2001 14:45:08 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Housley, Russ" <[e-mail]>, "Michael Myers" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Minor OID mistakes in OCSPv2 and the official OID list
Date: Thu, 31 May 2001 14:44:32 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Russ,

I (and I hope others too) deeply appreciate what Paul's doing for us but in
the longer run I'm little bit concerned of direct linkage to a potentially
ephemeral Web site.  I recall my aggravation years ago at having to hunt
down authoritative references to OIW OIDs.

Mike



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

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Housley, Russ
> Sent: Thursday, May 31, 2001 12:06 PM
> To: Michael Myers
> Cc: [e-mail]
> Subject: RE: Minor OID mistakes in OCSPv2 and the official OID list
>
>
> I can certainly publish the OID list periodically in an I-D.  Say
> every six
> months. In the I-D, I can say that the files on the IMC web site are
> updated more frequently.  Are there document editors that do not
> know this
> already?
>
> Russ
>
> At 03:38 PM 5/29/2001 -0700, Michael Myers wrote:
> >I think so Russ.  At a minimum we need to leave behind a highly
> visible and
> >definitive OID structure.  In my opinion PKIX isn't done until
> we document
> >all that we've defined.
> >
> >Mike
> >
> >
> >
> >Michael Myers
> >t: +415.819.1362
> >e: mailto:[e-mail]
> >w: http://www.traceroutesecurity.com
> >
> > > -----Original Message-----
> > > From: Housley, Russ [mailto:[e-mail]]
> > > Sent: Tuesday, May 29, 2001 2:32 PM
> > > To: Michael Myers
> > > Cc: Russ Housley; [e-mail]
> > > Subject: RE: Minor OID mistakes in OCSPv2 and the official OID list
> > >
> > >
> > > Mike:
> > >
> > > This seems like a reasonable thing to do as the PKIX WG is winding
> > > down.  Is there really any point in a document that documents the
> > > current snapshot?
> > >
> > > Russ
> > >
> > > At 02:13 PM 5/29/2001 -0700, Michael Myers wrote:
> > > >Russ,
> > > >
> > > >Good to hear of this.  Thanks.  Any chance for an Informational
> > > >I-D laying out the OID structure?  I'm willing to help.
> > > >
> > > >Mi
>



Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA22384 for ietf-pkix-bks; Thu, 31 May 2001 13:49:50 -0700 (PDT)
Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA22375 for <[e-mail]>; Thu, 31 May 2001 13:49:44 -0700 (PDT)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <L7GNSQ0Z>; Thu, 31 May 2001 16:49:15 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: CMP and CRMF (again)...
Date: Thu, 31 May 2001 16:49:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0EA13.27402F90"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0EA13.27402F90
Content-Type: text/plain

Hi all,

I have submitted "draft-ietf-pkix-rfc2510bis-04.txt" and
"draft-ietf-pkix-rfc2511bis-02.txt" to the internet-drafts address; they
should show up soon at the usual repositories.

As you may know, calls for a clean-up of the ASN.1 modules in CMP and CRMF
have necessitated yet another revision of the specs.  One of those "callers"
has been kind enough to look over the revised ASN.1 modules.  Although
they're still not ideal (88 syntax importing 93 or 97 syntax, mixing
EXPLICIT and IMPLICIT in the process), the fixable syntax errors (adding a
semicolon to the end of the IMPORT section, etc.) have been fixed and he can
live with these improved versions.

As well, I've taken this opportunity to make a small number of other minor
changes to take into account feedback from Peter Gutmann, YongChul Kwon,
Jeff Brinskelle, and Magnus Nystrom; see pages 23 ("senderKID" text), 28
("For simplicity" text), 36 ("rand" text), 46 ("Supported Languages"
section; see also p.87), and 76 (1st and 3rd paragraph, and 1st bullet).

Call me starry-eyed, but I persist in my belief that these specs are now
ready to go to IESG for consideration for advancement to Draft Standard
status.  Interoperability testing has been on-going, and increasingly
successful, over the past couple of years and the necessary clarifications
have been reflected in the drafts since RFCs 2510 and 2511.

Bob:  could you please ensure that some document reflecting the successful
interoperability testing of all the MUSTs and SHOULDs is sent to Tim and
Steve as soon as possible?

Tim, Steve:  once you receive this document from Bob, could you please begin
the process of moving these onto the IESG agenda?

Thanks again to everyone for all the feedback over the years on these specs!

Carlisle.


------_=_NextPart_001_01C0EA13.27402F90
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>CMP and CRMF (again)...</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
all,</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">I have =
submitted</FONT> <FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&quot;draft-ietf-pkix-rfc251</FONT><FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Times New Roman">0</FONT><FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Times New Roman">bis-0</FONT><FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Times New Roman">4</FONT><FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Times New Roman">.txt&quot;</FONT><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman"> and =
&quot;draft-ietf-pkix-rfc2511bis-02.txt&quot; to the internet-drafts =
address; they should show up soon at the usual repositories.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">As you may =
know, calls for a clean-up of the ASN.1 modules in CMP and CRMF have =
necessitated yet another revision of the specs.&nbsp; One of those =
&quot;callers&quot; has been kind enough to look over the revised ASN.1 =
modules.&nbsp; Although they're still not ideal (88 syntax importing 93 =
or 97 syntax, mixing EXPLICIT and IMPLICIT in the process), the fixable =
syntax errors (adding a semicolon to the end of the IMPORT section, =
etc.) have been fixed and he can live with these improved =
versions.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">As well, =
I've taken this opportunity to make a small number of other minor =
changes to take into account feedback from Peter Gutmann, YongChul =
Kwon, Jeff Brinskelle, and Magnus Nystrom; see pages 23 =
(&quot;senderKID&quot; text), 28 (&quot;For simplicity&quot; text), 36 =
(&quot;rand&quot; text), 46 (&quot;Supported Languages&quot; section; =
see also p.87), and 76 (1st and 3rd paragraph, and 1st =
bullet).</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Call me =
starry-eyed, but I persist in my belief that these specs are now ready =
to go to IESG for consideration for advancement to Draft Standard =
status.&nbsp; Interoperability testing has been on-going, and =
increasingly successful, over the past couple of years and the =
necessary clarifications have been reflected in the drafts since RFCs =
2510 and 2511.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Bob:&nbsp; =
could you please ensure that some document reflecting the successful =
interoperability testing of all the MUSTs and SHOULDs is sent to Tim =
and Steve as soon as possible?</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Tim, =
Steve:&nbsp; once you receive this document from Bob, could you please =
begin the process of moving these onto the IESG agenda?</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Thanks =
again to everyone for all the feedback over the years on these =
specs!</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0EA13.27402F90--


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA21435 for ietf-pkix-bks; Thu, 31 May 2001 13:36:28 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA21428 for <[e-mail]>; Thu, 31 May 2001 13:36:21 -0700 (PDT)
Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 31 May 2001 14:35:44 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Thu, 31 May 2001 14:36:16 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: cA flag and CRL issuers
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id NAA21429
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Russ, 

The more that I think about it, the more I believe that what Tony and I (and Peter Williams) are getting at is the difference between a rather blind syntactic validation of a certificate chain, including the binding between the certificate contents and the public key by the issuer's signature, vs. the somewhat more amorphous notion of "trust" -- not of the certificate, but of the designated entity.

As Steve correctly points out, although "trust" is a rather slippery concept, it is unavoidable, at least with respect to the CA.  Whatever it means, and that is really and finally in the eye of the beholder, i.e., the relying party, if you don't "trust" the CA, you certainly shouldn't include their root in your browser's list of trusted roots. 

But why should this be so?  After all, whether they would admit it or not, Microsoft and Netscape serve very well as de facto global CAs by including a collection of CA roots in their browsers.  And I believe that code is signed, as well.  So presumably there isn't any question as to whether those roots are syntactically valid or not, and their CPS is effectively embedded in their click-wrapped contract which you have to accept before installing the product.

Well, one possible reason for rejecting some CA's certificate is that you don't like, trust, or agree with the due diligence that CA has decided to provide, or maybe you don't feel comfortable with the digital signature statutes of Afghanistan or Zambia, or the state-run CA of Iraq, or the Mafia.  So despite the fact that there is no disagreement that the name of the CA has been accurately conveyed with appropriate due diligence, or that the public key (and hence the private key, indirectly) has been properly bound to that name and not compromised or revoked, nonetheless we don't choose to accept that CA's certificate.

But isn't this inconsistent with the "identity is all that matters" PKI philosophy some would espouse?

If you agree that there are circumstances where you as the relying party might choose not to trust a CA, despite the fact that all of the circumstances of the signature chain are in order, then why shouldn't the same logic apply to an end user, someone who is much more likely to cause me some harm than the CA is?  It really shouldn't matter why I choose not to trust that individual -- maybe he is gay, or a Boy Scout, or a red-head, or an Iraqi terrorist; or all of the above -- I simply choose to trust him, or to accept his credentials. (And to disagree with Steve on one point, this has nothing to do with nonrepudiation.)  

But t answer your question, just because I choose not to trust some entity, or their certificate, or the horse they rode in on, doesn't mean that their certificate is suddenly invalid from a global perspective, or that someone else might quite legitimately continue to trust the entity.  And so I have very little cause to even ask the CA to revoke the certificate, and certainly no way to compel the CA to do so.  And it wouldn't be right.

That view is consistent with not accepting a CA's certificate in a browser, and it is also consistent with the local policy control mechanism which has already been accepted in RFC in the case of OCSP.  So it is really the CRL path validation mechanism that we are treating inconsistently.

Now, I will certainly grant that there would be other ways to control the acceptance of a certificate, other than the CRL mechanism.  I could certainly add that certificate to a directory of blackballed certificates.  But the question is, who would use such a mechanism?  As a single end-user enterprise, I certainly can't afford to go off and rewrite all of the browsers, SSL, and S/MIME code I have lying around, not to mention  Adobe Acrobat, a number of forms processors, B2B transaction processors, etc.  It is simply too huge a job.  And even if I could somehow cajole one vendor into doing it, that doesn't solve the problem -- I need EVERYONE to do it with one uniform mechanism, or the system is still broken.

Maybe I'm missing a technical nuance or "gotcha" somewhere, but I continue to believe that a local CRL chain that is tied back to a trusted root in the browser, i.e., my own Enterprise's certificate, solves these problems almost automatically, and with little if any changes required to existing code.

If that simply can't be made to work without upsetting the apple cart, then I suppose we (or the RP) could jettison support for CRLs entirely and just use OCSP, but that seems both inconsistent from a standards perspective and undesirable from a performance standpoint in some cases.

Regards,

Bob


>>> "Housley, Russ" <[e-mail]> 05/31/01 08:47AM >>>
Tony:

If YourOrg decides that a particular UserNameN and UserKeyN that was 
certified by WhoeverCA, they can do so.  PKIX does not (and I think should 
not) have a standard mechanism to do so.  If YourOrg feels that one 
certificate issued by WhoeverCA should be revoked, and WhoeverCA has 
not/will not revoke it, then why would YourOrg continue to trust WhoeverCA 
for any certificates?  It seems to me that the WhoeverCA certificate should 
be revoked or removed from the certificate trust list.

Russ

At 11:43 AM 5/30/2001 -0700, Tony Bartoletti wrote:
>At 10:10 AM 5/30/01 -0400, you wrote:
>>3) An authority stands up on its own with no CA blessing, and overtly claims
>>that it will not reflect the CA's revocation status, but instead will reflect
>>some local policy such as an employee's right to access company assets.
>>
>>By dictionary and common sense, #3 is not a "Certificate Revocation List",
>>it is an "Access Control List".  You and Tony argue that it is a good idea
>>to mix authentication and access control because such mixing is expedient --
>>products support revocation of authentication credentials but do not widely
>>support access control.  You further argue that the PKIX path validation
>>algorithm should be modified to officially sanction the merging of
>>authentication and access control.
>>
>>I argue that such merging (done unofficially) is a bad idea from a security
>>point of view, and it would be an even worse idea to modify X.509 and
>>PKIX to officially support non-CA-authorized CRL signers.
>
>Dave,
>
>I agree that mixing (identity) authentication and authorization is bad 
>(however expedient.)
>
>My issue, perhaps academic, was not one of authorization.  I intend that 
>the RP (or RP organization) unilaterally declares that binding of identity 
>(DN) to key is voided.  The net result might not be the same regarding 
>authorization.  If an "identity" binding fails, there may be myriad 
>separate authorizations the need to be revoked, but only the one name-key 
>binding.
>
>I argue the RP has a right to declare the CA-issued certificate to be 
>"null and void", and to be able to promote this declaration throughout the 
>organization.
>
>Perhaps this "should" be accomplished by having the RP-organization-as-CA 
>issue its own certification for every public key of possible interest, in 
>which case it could revoke according to the present mechanisms, and 
>everything "works".  To ensure that third-party certifications are (by 
>default) untrusted, it would need to purge the vendor-installed default 
>root certificates from its systems.
>
>___tony___
>
>
>
>
>___tony___
>
>
>
>Tony Bartoletti 925-422-3881 <[e-mail]>
>Information Operations, Warfare and Assurance Center
>Lawrence Livermore National Laboratory
>Livermore, CA 94551-9900
>
>


Received: by above.proper.com (8.9.3/8.9.3) id MAA16687 for ietf-pkix-bks; Thu, 31 May 2001 12:19:10 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id MAA16677 for <[e-mail]>; Thu, 31 May 2001 12:19:01 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 31 May 2001 19:18:19 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA20841 for <[e-mail]>; Thu, 31 May 2001 15:19:02 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <LR8TCB8X>; Thu, 31 May 2001 15:19:01 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.67]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TCB8N; Thu, 31 May 2001 15:18:54 -0400
From: "Housley, Russ" <[e-mail]>
To: Michael Myers <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 31 May 2001 15:05:36 -0400
Subject: RE: Minor OID mistakes in OCSPv2 and the official OID list
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I can certainly publish the OID list periodically in an I-D.  Say every six 
months. In the I-D, I can say that the files on the IMC web site are 
updated more frequently.  Are there document editors that do not know this 
already?

Russ

At 03:38 PM 5/29/2001 -0700, Michael Myers wrote:
>I think so Russ.  At a minimum we need to leave behind a highly visible and
>definitive OID structure.  In my opinion PKIX isn't done until we document
>all that we've defined.
>
>Mike
>
>
>
>Michael Myers
>t: +415.819.1362
>e: mailto:[e-mail]
>w: http://www.traceroutesecurity.com
>
> > -----Original Message-----
> > From: Housley, Russ [mailto:[e-mail]]
> > Sent: Tuesday, May 29, 2001 2:32 PM
> > To: Michael Myers
> > Cc: Russ Housley; [e-mail]
> > Subject: RE: Minor OID mistakes in OCSPv2 and the official OID list
> >
> >
> > Mike:
> >
> > This seems like a reasonable thing to do as the PKIX WG is winding
> > down.  Is there really any point in a document that documents the
> > current snapshot?
> >
> > Russ
> >
> > At 02:13 PM 5/29/2001 -0700, Michael Myers wrote:
> > >Russ,
> > >
> > >Good to hear of this.  Thanks.  Any chance for an Informational
> > >I-D laying out the OID structure?  I'm willing to help.
> > >
> > >Mi


Received: by above.proper.com (8.9.3/8.9.3) id KAA12974 for ietf-pkix-bks; Thu, 31 May 2001 10:30:52 -0700 (PDT)
Received: from mail.funk.com (mail.funk.com [198.186.160.22]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA12969 for <[e-mail]>; Thu, 31 May 2001 10:30:46 -0700 (PDT)
Received: by mail.funk.com with Internet Mail Service (5.5.2653.19) id <LLY0FBKD>; Thu, 31 May 2001 13:33:01 -0400
Message-ID: <[e-mail]>
From: Aslam <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: CRLs doubts...
Date: Thu, 31 May 2001 13:33:01 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Hi,

I have some doubts:

1. Like we have a "cert serial no and issuer name" to uniquely identify a
certificate, do we have such thing for CRL also.

2. If the CRL Distribution Point extension has two URIs in it, do they refer
to same CRLs or they point to different CRLs with different scope.

3. In order to make a CRL cache thing work, what can be the primary key to
get a CRL blob from the cache just by having the certificate, for which the
revocation info has to be obtained.

Thanks

Aslam 


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA02357 for ietf-pkix-bks; Thu, 31 May 2001 08:23:37 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id IAA02349 for <[e-mail]>; Thu, 31 May 2001 08:23:27 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 31 May 2001 15:22:45 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA29540; Thu, 31 May 2001 11:23:28 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <LR8TB8QW>; Thu, 31 May 2001 11:23:27 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.126]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TB8QS; Thu, 31 May 2001 11:23:24 -0400
From: "Housley, Russ" <[e-mail]>
To: Tony Bartoletti <[e-mail]>
Cc: [e-mail], "David P. Kemp" <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 31 May 2001 10:47:49 -0400
Subject: Re: cA flag and CRL issuers
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Tony:

If YourOrg decides that a particular UserNameN and UserKeyN that was 
certified by WhoeverCA, they can do so.  PKIX does not (and I think should 
not) have a standard mechanism to do so.  If YourOrg feels that one 
certificate issued by WhoeverCA should be revoked, and WhoeverCA has 
not/will not revoke it, then why would YourOrg continue to trust WhoeverCA 
for any certificates?  It seems to me that the WhoeverCA certificate should 
be revoked or removed from the certificate trust list.

Russ

At 11:43 AM 5/30/2001 -0700, Tony Bartoletti wrote:
>At 10:10 AM 5/30/01 -0400, you wrote:
>>3) An authority stands up on its own with no CA blessing, and overtly claims
>>that it will not reflect the CA's revocation status, but instead will reflect
>>some local policy such as an employee's right to access company assets.
>>
>>By dictionary and common sense, #3 is not a "Certificate Revocation List",
>>it is an "Access Control List".  You and Tony argue that it is a good idea
>>to mix authentication and access control because such mixing is expedient --
>>products support revocation of authentication credentials but do not widely
>>support access control.  You further argue that the PKIX path validation
>>algorithm should be modified to officially sanction the merging of
>>authentication and access control.
>>
>>I argue that such merging (done unofficially) is a bad idea from a security
>>point of view, and it would be an even worse idea to modify X.509 and
>>PKIX to officially support non-CA-authorized CRL signers.
>
>Dave,
>
>I agree that mixing (identity) authentication and authorization is bad 
>(however expedient.)
>
>My issue, perhaps academic, was not one of authorization.  I intend that 
>the RP (or RP organization) unilaterally declares that binding of identity 
>(DN) to key is voided.  The net result might not be the same regarding 
>authorization.  If an "identity" binding fails, there may be myriad 
>separate authorizations the need to be revoked, but only the one name-key 
>binding.
>
>I argue the RP has a right to declare the CA-issued certificate to be 
>"null and void", and to be able to promote this declaration throughout the 
>organization.
>
>Perhaps this "should" be accomplished by having the RP-organization-as-CA 
>issue its own certification for every public key of possible interest, in 
>which case it could revoke according to the present mechanisms, and 
>everything "works".  To ensure that third-party certifications are (by 
>default) untrusted, it would need to purge the vendor-installed default 
>root certificates from its systems.
>
>___tony___
>
>
>
>
>___tony___
>
>
>
>Tony Bartoletti 925-422-3881 <[e-mail]>
>Information Operations, Warfare and Assurance Center
>Lawrence Livermore National Laboratory
>Livermore, CA 94551-9900
>
>


Received: by above.proper.com (8.9.3/8.9.3) id HAA26733 for ietf-pkix-bks; Thu, 31 May 2001 07:15:37 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id HAA26724 for <[e-mail]>; Thu, 31 May 2001 07:15:31 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 31 May 2001 14:14:44 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA21834; Thu, 31 May 2001 10:15:24 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <LR8TB67Z>; Thu, 31 May 2001 10:15:23 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.44]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TB674; Thu, 31 May 2001 10:15:17 -0400
From: "Housley, Russ" <[e-mail]>
To: Richard Lampard <[e-mail]>
Cc: [e-mail], Andrew Watson <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 31 May 2001 10:15:13 -0400
Subject: Re: Algorithms in PKIX and S/MIME - query
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Richard:

PKIX has not selected any algorithms as mandatory to implement.  PKIX has 
left such decisions to the protocols that make use of certificates.

S/MIME documents are being updated to reflect:
         signature generation:   RSA or DSA or both
         signature validation:   RSA and DSA
         hash:                   SHA-1
         encrypt:                Triple-DES CBC
         key management: RSA (PKCS#1 v1.5)

Russ


At 10:38 AM 5/30/2001 +0100, Richard Lampard wrote:
>We recently completed an interoperability trial looking at PKI and S/MIME 
>v3 interoperability. If you're interested, the final report is available at:
>
>www.cesg.gov.uk/cloudcover/PKIdemonstrator.htm
>
>We are about to embark on a second phase, this time looking at S/MIME v3 
>encryption. We are keen to mirror current thinking on S/MIME algorithms, 
>which I
>believe is:
>
>Signature generation: DSA or RSA may be implemented
>Signature processing: DSA and RSA must both be supported
>Key transport: RSA
>
>However, I also believe that PKIX thinking at the moment is that DSA is 
>still the mandatory to implement algorithm for certificate and CRL signing.
>
>This leads to the awkward situation where an implementation, for example, 
>only signs S/MIME messages using RSA, but has to sign its RSA transport 
>keys using
>DSA. I can imagine other mismatches whereby the keys for one algorithm are 
>signed by a different algorithm.
>
>This seems to stem from the fact that thinking on algorithms between PKIX 
>and  S/MIME is not yet aligned. I'd be very grateful for some advice on 
>how we should
>play our second phase, and what we should be asking vendors to bring to 
>the trial. Is it realistic to expect vendors to support both DSA and RSA, 
>especially in
>their CAs?
>
>Many thanks
>
>Richard
>
>Richard Lampard
>CESG
>PO Box 144
>Cheltenham
>Gloucestershire GL52 5UE
>Tel: [phone] x4086
>Fax: [phone]
>**********************************************************************
>This email and any files transmitted with it is intended solely for
>the use of the individual or entity to whom they are addressed. If
>you have received this email in error please notify
>[e-mail].
>**********************************************************************


Received: by above.proper.com (8.9.3/8.9.3) id DAA11703 for ietf-pkix-bks; Thu, 31 May 2001 03:26:28 -0700 (PDT)
Received: from hip.baltimore.ie ([193.41.17.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA11691 for <[e-mail]>; Thu, 31 May 2001 03:26:17 -0700 (PDT)
Received: from Baltimore-FW1 ([172.19.1.1]) by hip.baltimore.ie (8.9.3/8.9.3) with SMTP id LAA20224 for <[e-mail]>; Thu, 31 May 2001 11:18:01 +0100
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.1) with SMTP id <[e-mail]> for <[e-mail]>; Thu, 31 May 2001 10:42:09 +0100
Received: from baltimore.ie (ip226-24.ie.baltimore.com [10.153.24.226]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id KAA30029; Thu, 31 May 2001 10:45:48 +0100
Message-ID: <[e-mail]>
Date: Thu, 31 May 2001 10:38:52 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Hideyuki Odahara <[e-mail]>
CC: [e-mail]
Subject: Re: draft-ietf-pkix-ac509prof -> RFC?
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Hi,

I'm not entirely clear exactly what question is being asked, 
however, I *think* the answer is that I've got to make a few
very minor changes and then that draft will be sent to the RFC 
editor. In other words, the work on this specification is done, 
it will be an RFC quite soon now, without any substantive 
changes being made.

The minor changes to be made include adding a section saying 
that there are no IANA consideration; updating to reflect a 
couple of minor changes to the base X.509 document and a change 
to allow some s/mime specifications to reference this document
more easily.

I hope that answers your question,
Regards,
Stephen.

Hideyuki Odahara wrote:
> 
> Mr. Stephen Farrell
> 
> Thank you for your reply the example of use of an attribute the other
> day.
> I would like you to teach about RFC-izing of draft-ietf-pkix-ac509prof
> today, and mail was given. While it is said that ac509prof has near
> RFC-izing, it is not RFC-ized easily. Now, would you the argument is
> progressing how much and teach [ when to RFC-be due to beized and ] this
> draft?
> Although humiliated a busy place, I ask of you well.
> 
> thanks
> 

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: by above.proper.com (8.9.3/8.9.3) id AAA20592 for ietf-pkix-bks; Thu, 31 May 2001 00:07:44 -0700 (PDT)
Received: from server.ica.cz (server.ica.cz [195.47.13.11]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA20562 for <[e-mail]>; Thu, 31 May 2001 00:07:36 -0700 (PDT)
Received: from SZOTKOWSKI (com.ica.cz [195.47.13.10]) by server.ica.cz (8.9.2/8.8.7) with SMTP id JAA30402 for <[e-mail]>; Thu, 31 May 2001 09:07:21 +0200 (CEST)
Message-ID: <06cf01c0e9a0$569023e0$[e-mail]>
From: "Martin Szotkowski" <[e-mail]>
To: <[e-mail]>
Subject: LDAP and certificates
Date: Thu, 31 May 2001 09:07:21 +0200
Organization: PVT, a.s.
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Hi,
I started study LDAP and I like know how add user certificate into LDAP DB.
How create entry for one user?
>From DN? (what is right order of RDN in DN)
>From some other information?
How browsers connect LDAP server to obtain certificates or CRL?

please send me some RFC or drafts, where it is described.

thanks Martin






Received: by above.proper.com (8.9.3/8.9.3) id TAA29145 for ietf-pkix-bks; Wed, 30 May 2001 19:54:03 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA29141 for <[e-mail]>; Wed, 30 May 2001 19:53:57 -0700 (PDT)
Received: from [128.33.238.84] (TC030.BBN.COM [128.33.238.30]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id WAA00006; Wed, 30 May 2001 22:53:56 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010408b73b5701a36c@[128.33.238.84]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Wed, 30 May 2001 22:23:45 -0400
To: Tony Bartoletti <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: cA flag and CRL issuers
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Tony & Bob,

This discussion re revocation seems to be colored by excessive use of 
the term "trust."  It's common to use that term in discussing PKIs, 
and the public CA approach to PKI, exemplified by VeriSIgn, 
encourages that notion, because such CA are viable only if "trusted."

However, that is not the only way to think about roles in a PKI.  If 
CAs are aligned with physical world entities that are authoritative 
for the data contained in certs, e.g., companies issuing certs for 
employees, then these CAs are not "trusted" in the same way that one 
trusts a public CA.  Moreover, CAs of this sort are authoritative for 
revocation, just as they are authoritative for cert issuance. Tony 
seems to agree with this observation, but Bob feels that this is a 
naive model re NR.  I will remind Bob that NR is not the only focus 
of PKI, that this WG has expended way to much time arguing about NR 
matters that seem to never be fully resolved in the technical domain, 
and that the lack of uniform agreement re NR requirements suggests 
that no single view of technical support for NR can be considered 
authoritative.

What you tow are suggesting is a local means of asserting 
per-certificate validity judgements that might override those of the 
CA who issued a cert. While I can appreciate the motivations that you 
cite for this, they are simply not consistent with the overall X.509 
or PKIX models. We cannot tailor the specs to compensate for 
questionable PKI implementation designs in apps such as browsers.

OCSP does allow for local configuration of a local source for 
revocation information, and that would allow one to achieve the goals 
you cite, if one relied on OCSP for revocation status.  DPV will 
allow a similar configuration capability. So, I suggest that you be 
content with the ability to achieve the stated effects via these 
other protocols, which will provide the capability as a side effect 
of their other design goals.

Steve


Received: by above.proper.com (8.9.3/8.9.3) id SAA24818 for ietf-pkix-bks; Wed, 30 May 2001 18:55:27 -0700 (PDT)
Received: from [165.227.249.18] (ip18.proper.com [165.227.249.18]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA24811; Wed, 30 May 2001 18:55:20 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100317b73b527edc1a@[165.227.249.18]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Wed, 30 May 2001 18:54:24 -0700
To: "Tom Gindin" <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Patent disclosure
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

At 2:40 PM -0400 5/30/01, Tom Gindin wrote:
>IBM is unable to provide more specific
>information regarding the application, until such time as the application
>is published or the patent is issued.

IBM often does The Right Thing with respect to patents used in IETF 
protocols, so I am not eager to kick them around. However, the above 
statement is simply not true. IBM is quite able to provide more 
specific information: it is choosing not to. And by choosing not to, 
the PKIX WG cannot move forwards with either document with any 
understanding about what doing so means.

It would be great if IBM would reconsider its choice to be almost 
silent as soon as possible.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: by above.proper.com (8.9.3/8.9.3) id RAA18225 for ietf-pkix-bks; Wed, 30 May 2001 17:11:24 -0700 (PDT)
Received: from smtp-2.llnl.gov (smtp-2.llnl.gov [128.115.250.82]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA18213 for <[e-mail]>; Wed, 30 May 2001 17:11:18 -0700 (PDT)
Received: from poptop.llnl.gov (localhost [127.0.0.1]) by smtp-2.llnl.gov (8.9.3/8.9.3/LLNL-gateway-1.0) with ESMTP id RAA19872; Wed, 30 May 2001 17:10:45 -0700 (PDT)
Received: from catalyst.llnl.gov (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id RAA15930; Wed, 30 May 2001 17:10:45 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 30 May 2001 17:17:50 -0700
To: "Bob Jueneman" <[e-mail]>, <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: cA flag and CRL issuers
Cc: <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

At 04:44 PM 5/30/01 -0600, Bob Jueneman wrote:
> >
> >Perhaps this "should" be accomplished by having the RP-organization-as-CA
> >issue its own certification for every public key of possible interest, in
> >which case it could revoke according to the present mechanisms, and
> >everything "works".

>Fortunately, revocation of particular certificates can be done on an 
>exception basis, without having to (re-)issue all of the certificates 
>directly, and that is my point.
>
>Bob

:)  That is mostly why "should" and "works" are in quotes.  The scheme is 
hardly workable except in a very limited arrangement.

My concerns also joined with that of CA root-key compromise.  I suppose a 
CA that issues a CRL listing its own signing key as revoked *can* be 
trusted (if it too signed the CRL) since either the CA intended to revoke, 
or the key is in fact compromised.  Ala SPKI "loop-of-trust", wherein 
authority begins (and ends) with the Relying Party, I sought to allow any 
party of authority to act as a "CA over the CAs" by "certifying" their root 
keys, and thus to be able to revoke them if desired, to address the root 
compromise problem for a "Relying Community".  That community would (once) 
install this super-CA root in its user's software.  Thereafter, if a CA 
needed to issue a new root upon compromise, the "authority" of each 
community could seek out that CA and certify that new key via the 
"community root".  This would allow the end user software a path to 
"accept" a new CA root electronically, since it would verify with the 
installed community key.

This mechanism reduces manual intervention in the N systems to only those 
operations that concern a community's trust in it own authority.

___tony___


Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900






Received: by above.proper.com (8.9.3/8.9.3) id PAA12220 for ietf-pkix-bks; Wed, 30 May 2001 15:45:05 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA12207 for <[e-mail]>; Wed, 30 May 2001 15:44:57 -0700 (PDT)
Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 30 May 2001 16:44:22 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Wed, 30 May 2001 16:44:50 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: cA flag and CRL issuers
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id PAA12208
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

>I argue the RP has a right to declare the CA-issued certificate to be "null 
>and void", and to be able to promote this declaration throughout the 
>organization.
>
>Perhaps this "should" be accomplished by having the RP-organization-as-CA 
>issue its own certification for every public key of possible interest, in 
>which case it could revoke according to the present mechanisms, and 
>everything "works".  To ensure that third-party certifications are (by 
>default) untrusted, it would need to purge the vendor-installed default 
>root certificates from its systems.
>
Tony, I completely agree with you, but I would point out that although having the RP organization issue its own certification for all public keys of interest might be technically do-able, it certainly wouldn't scale beyond the boundaries of that organization. Once you start trying to manage the public keys of all of the employees of your extranet partners, you are out of the frying pan and into the fire from a management and control aspect.

Fortunately, revocation of particular certificates can be done on an exception basis, without having to (re-)issue all of the certificates directly, and that is my point.

Bob



Received: by above.proper.com (8.9.3/8.9.3) id LAA28931 for ietf-pkix-bks; Wed, 30 May 2001 11:41:35 -0700 (PDT)
Received: from e1.ny.us.ibm.com ([32.97.182.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA28921 for <[e-mail]>; Wed, 30 May 2001 11:41:29 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA125574; Wed, 30 May 2001 14:38:33 -0400
Received: from d02ml237.somers.hqregion.ibm.com (d02ml237.sby.ibm.com [9.45.4.171]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id OAA111224; Wed, 30 May 2001 14:34:40 -0400
Importance: Normal
Subject: Patent disclosure
To: [e-mail]
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Wed, 30 May 2001 14:40:01 -0400
X-MIMETrack: Serialize by Router on D02ML237/02/M/IBM(Release 5.0.7 |March 21, 2001) at 05/30/2001 02:40:09 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

IBM has submitted patent applications in a technology area that  may be
employed by the PKIX working group in developing its final specifications.
The technology area  relates to the use of certificateHold for
Non-Repudiation.  This may prove relevant to some parts of the
draft-ietf-pkix-ocspv2-02.txt and to some parts of
draft-ietf-pkix-new-part1-06.txt.  IBM is unable to provide more specific
information regarding the application, until such time as the application
is published or the patent is issued.

IBM, in support of IETF intellectual property rights procedures, is willing
to offer non-exclusive licenses to issued patents, upon written request,
under reasonable and non-discriminatory  terms and conditions, in
accordance with IBM's usual licensing practices, when there is a necessary
dependence upon these IBM patents to implement  PKIX specifications.

          Tom Gindin




Received: by above.proper.com (8.9.3/8.9.3) id LAA28691 for ietf-pkix-bks; Wed, 30 May 2001 11:37:24 -0700 (PDT)
Received: from smtp-2.llnl.gov (smtp-2.llnl.gov [128.115.250.82]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA28683 for <[e-mail]>; Wed, 30 May 2001 11:37:18 -0700 (PDT)
Received: from poptop.llnl.gov (localhost [127.0.0.1]) by smtp-2.llnl.gov (8.9.3/8.9.3/LLNL-gateway-1.0) with ESMTP id LAA22824; Wed, 30 May 2001 11:36:44 -0700 (PDT)
Received: from catalyst.llnl.gov (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id LAA21182; Wed, 30 May 2001 11:36:44 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 30 May 2001 11:43:49 -0700
To: [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: cA flag and CRL issuers
Cc: "David P. Kemp" <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

At 10:10 AM 5/30/01 -0400, you wrote:
>3) An authority stands up on its own with no CA blessing, and overtly claims
>that it will not reflect the CA's revocation status, but instead will reflect
>some local policy such as an employee's right to access company assets.
>
>By dictionary and common sense, #3 is not a "Certificate Revocation List",
>it is an "Access Control List".  You and Tony argue that it is a good idea
>to mix authentication and access control because such mixing is expedient --
>products support revocation of authentication credentials but do not widely
>support access control.  You further argue that the PKIX path validation
>algorithm should be modified to officially sanction the merging of
>authentication and access control.
>
>I argue that such merging (done unofficially) is a bad idea from a security
>point of view, and it would be an even worse idea to modify X.509 and
>PKIX to officially support non-CA-authorized CRL signers.

Dave,

I agree that mixing (identity) authentication and authorization is bad 
(however expedient.)

My issue, perhaps academic, was not one of authorization.  I intend that 
the RP (or RP organization) unilaterally declares that binding of identity 
(DN) to key is voided.  The net result might not be the same regarding 
authorization.  If an "identity" binding fails, there may be myriad 
separate authorizations the need to be revoked, but only the one name-key 
binding.

I argue the RP has a right to declare the CA-issued certificate to be "null 
and void", and to be able to promote this declaration throughout the 
organization.

Perhaps this "should" be accomplished by having the RP-organization-as-CA 
issue its own certification for every public key of possible interest, in 
which case it could revoke according to the present mechanisms, and 
everything "works".  To ensure that third-party certifications are (by 
default) untrusted, it would need to purge the vendor-installed default 
root certificates from its systems.

___tony___




___tony___



Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900






Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id KAA24712 for ietf-pkix-bks; Wed, 30 May 2001 10:36:12 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA24704 for <[e-mail]>; Wed, 30 May 2001 10:36:05 -0700 (PDT)
Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 30 May 2001 11:35:27 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Wed, 30 May 2001 11:35:55 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: cA flag and CRL issuers
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id KAA24705
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Dave, thanks for the clarification.  For a while there I was afraid I was going to have to appeal to Charleton Heston!

I agree that semantically, only the issuer can revoke the issuer's binding of a key to whatever else may be contained in the certificate, normally the identity of the holder of that key, and state, as you say, that in the eyes of the issuer, that binding is no long in effect.

But you then jumped from notion of certificate revocation, or what might more accurately be called certificate trust revocation, to the notion of access control and PMI.  I don't equate the two, although of course there is some overlap.  So I don't agree that your case #3 isn't a CRL, but rather access control, or PMI.

Instead, I want to use some form of certificate revocation or whatever we call it to revoke encryption certificates for various recipients, and to revoke digital signature certificates for people I no longer trust to sign documents or transactions.

I suppose you could argue that if X.509 PKI is exclusively about identity, then there is some justification for claiming that the CA is reasonably authoritative for identity and thus only the CA should be able to revoke the trust relationship inherent in the certificate -- the end-entity presumably hasn't been transmogrified into someone else, and even if they were, they are presumably still responsible for their actions.

But we all know by now, I hope, that the initial naive "nonrepudiation" conceit of the technologists (and I include myself there) that if we could just be sure who someone really was, that the world would be a much better place, simply hasn't materialized.  We handed the car dealer our driver's license and drove off in the Ferrari on a test drive, and never returned.  Even if the driver's license wasn't falsified, what are you going to do next -- send the sheriff into cyberspace to arrest some e-mail name? In fact, putting aside religious arguments about ASN.1 vs. "simpler" mechanisms, the SPKI crowd probably had it closer to right than the PKI crowd, because the essence of a workable PKI isn't just identity, but authority and credibility, i.e., trust.  Remember, the original use of X.509 was to authenticate an individual to a directory, where such decisions could be made. but we effectively threw away the directory, and proposed making decision based on the certificate itself, with no other information.

That's why there have been virtually no Residential Person certificates issued to speak of  -- only Organizational Person certs -- because rightly or wrongly, the implicit affiliation of the individual with an organization carries a lot of weight, to the point that the name almost doesn't matter an most cases. (I said almost. :-)  and hence there is little or not acceptance of a Residential person certificate, except perhaps for casual e-mail encryption.

I note that the current specification allows an independent OCSP responder to comment on the status of a certificate, and indirectly on the trust associated with the end-user.  You deprecate that usage, but there it is.  So why does the certificate validation concept depend on the choice of protocols?  We should be arguing philosophy, not protocols and whether or not the certificate is checked in real time.

You argue that "such merging (done unofficially) is a bad idea from a security point of view, and it would be an even worse idea to modify X.509 and PKIX to officially support non-CA-authorized CRL signers."

Particularly if the "merging" is local to a single relying party's organization, I would like to better understand your reasoning as to why you think that is a bad idea, for that certainly isn't obvious to me.  Instead, I believe that continuing the rely on the CA's potentially out of date world view, when that CA has no obligation to continuing monitor the trust relationship associated with that user, is in fact the Bad Idea, if relied on exclusively.  The CA is only obligated to revoke a certificate upon the request of the end-user, who may have every interest in the world to continue to use that certificate.  That simply isn't good enough for all situations.

Likewise, I disagree with the assertion that it would be an even worse idea to modify X.509 and PKIX to officially support non-CA-authorized CRL signers.  Local RP organizational control is one such case that makes eminently good sense to me, as does the notion of some overarching authority such as a State or Federal CA licensing authority, for example.  And if we get into Attribute Certificates, or attributes within a certificate that reflect a credential such as whether or not someone is a medical doctor (that's an attribute, not a privilege, although the RP may decide to confer a privilege based on that attribute), then I think having a non-CA such as the state medical association be able to revoke such credentials is even more important.

The issue of whether products do, or should support PMI is a separate issue.  They don't, and they should, but in my view, at least, that still doesn't solve the trust problem.  And we are ten years and counting.

Regards,

Bob

>>> "David P. Kemp" <[e-mail]> 05/30/01 08:10AM >>>
Bob Jueneman wrote:

> >
> > [dpk] ** No one but the issuer can revoke that issuer's certification. **
> 
> Well, that is precisely the disagreement, isn't it?  Or let me clarify that
> just a bit.  What I care about is revoking the certificate itself.
> Revoking the issuer's certification of that certificate is a slight,
> but perhaps a significant nuance of difference.


My statement was a bit terse, and I certainly see how it could be interpreted,
not as intended, but as a stone-tablet pronouncement.

The issuer has signed a statement binding name to key, and only the issuer,
from the standpoint of Noah Webster (as opposed to the standpoint of Moses)
is able to state that in the eyes of the issuer that binding is no longer
in effect.

There are three cases to consider:

1) The CA can revoke certificates using its own signing key directly, or
indirectly by signing a cRLSign certificate, an Authorized OCSP responder
certificate, or an EE cert with a CRLDP referring to an ICRLA.

2) A revocation authority could stand up on its own, with no blessing from
a CA, but claim that it will faithfully reflect the CA's revocation status
to the best of its ability.  This is the Trusted OCSP responder model.

3) An authority stands up on its own with no CA blessing, and overtly claims
that it will not reflect the CA's revocation status, but instead will reflect
some local policy such as an employee's right to access company assets.

By dictionary and common sense, #3 is not a "Certificate Revocation List",
it is an "Access Control List".  You and Tony argue that it is a good idea
to mix authentication and access control because such mixing is expedient --
products support revocation of authentication credentials but do not widely
support access control.  You further argue that the PKIX path validation
algorithm should be modified to officially sanction the merging of
authentication and access control.

I argue that such merging (done unofficially) is a bad idea from a security
point of view, and it would be an even worse idea to modify X.509 and
PKIX to officially support non-CA-authorized CRL signers.


> I'm always willing to consider other, alternative means of achieving
> any particular objective, so long as they are reasonably well standardized
> and widely implemented on commercial software packages.  But if I were the
> RP's organization, I would certainly NOT like to have to throw out all of
> my browsers, my S/MIME software, etc., just to achieve this objective --
> that's a non-starter.

I can think of three off the bat:

1) Request that the CA issue an "authorized revocation authority" (OCSP or
ICRLA)
   certificate to your local status authority.  This is expedient (in the
   pejorative sense) and the CA might refuse to do it, but it requires no
   undesirable changes to the text of X.509 or to products.

2) Stand up a CA which explicitly issues certificates according to local
   policies such as employment status, and then revokes those certificates
   according to the same criteria under which they were issued.  This does
   no violence to the intent of X.509, and requires no changes to products.

3) Use a "trusted OCSP" responder and forget about CRLs.  I think this
   option should be deprecated, but it is documented today in RFC 2560.

4) A fourth option, which of course requires better products, is to
   use a proper PMI.  The PMI standards are there; it's up to product
   developers to determine if there is a market.

I'm not persuaded by "well, products haven't seen fit to support authorization
yet, so let's muck with the authentication standard to support coarse-grained
(yes/no) bastardized privilege management."

Regards,
Dave


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA07044 for ietf-pkix-bks; Wed, 30 May 2001 07:13:42 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA07035 for <[e-mail]>; Wed, 30 May 2001 07:13:36 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA15318 for <[e-mail]>; Wed, 30 May 2001 10:13:32 -0400 (EDT)
Received: from reject.missi.ncsc.mil (reject.missi.ncsc.mil [144.51.60.17]) by stingray.missi.ncsc.mil with SMTP id KAA15314 for <[e-mail]>; Wed, 30 May 2001 10:13:32 -0400 (EDT)
Received: from 144.51.60.215 by reject.missi.ncsc.mil (InterScan E-Mail VirusWall NT); Wed, 30 May 2001 10:15:49 -0400 (Eastern Daylight Time)
Received: from missi.ncsc.mil (ara.missi.ncsc.mil [144.51.55.128]) by amx.missi.ncsc.mil with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LQK7KMM6; Wed, 30 May 2001 10:16:50 -0400
Message-ID: <[e-mail]>
Date: Wed, 30 May 2001 10:10:03 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: cA flag and CRL issuers
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Bob Jueneman wrote:

> >
> > [dpk] ** No one but the issuer can revoke that issuer's certification. **
> 
> Well, that is precisely the disagreement, isn't it?  Or let me clarify that
> just a bit.  What I care about is revoking the certificate itself.
> Revoking the issuer's certification of that certificate is a slight,
> but perhaps a significant nuance of difference.


My statement was a bit terse, and I certainly see how it could be interpreted,
not as intended, but as a stone-tablet pronouncement.

The issuer has signed a statement binding name to key, and only the issuer,
from the standpoint of Noah Webster (as opposed to the standpoint of Moses)
is able to state that in the eyes of the issuer that binding is no longer
in effect.

There are three cases to consider:

1) The CA can revoke certificates using its own signing key directly, or
indirectly by signing a cRLSign certificate, an Authorized OCSP responder
certificate, or an EE cert with a CRLDP referring to an ICRLA.

2) A revocation authority could stand up on its own, with no blessing from
a CA, but claim that it will faithfully reflect the CA's revocation status
to the best of its ability.  This is the Trusted OCSP responder model.

3) An authority stands up on its own with no CA blessing, and overtly claims
that it will not reflect the CA's revocation status, but instead will reflect
some local policy such as an employee's right to access company assets.

By dictionary and common sense, #3 is not a "Certificate Revocation List",
it is an "Access Control List".  You and Tony argue that it is a good idea
to mix authentication and access control because such mixing is expedient --
products support revocation of authentication credentials but do not widely
support access control.  You further argue that the PKIX path validation
algorithm should be modified to officially sanction the merging of
authentication and access control.

I argue that such merging (done unofficially) is a bad idea from a security
point of view, and it would be an even worse idea to modify X.509 and
PKIX to officially support non-CA-authorized CRL signers.


> I'm always willing to consider other, alternative means of achieving
> any particular objective, so long as they are reasonably well standardized
> and widely implemented on commercial software packages.  But if I were the
> RP's organization, I would certainly NOT like to have to throw out all of
> my browsers, my S/MIME software, etc., just to achieve this objective --
> that's a non-starter.

I can think of three off the bat:

1) Request that the CA issue an "authorized revocation authority" (OCSP or
ICRLA)
   certificate to your local status authority.  This is expedient (in the
   pejorative sense) and the CA might refuse to do it, but it requires no
   undesirable changes to the text of X.509 or to products.

2) Stand up a CA which explicitly issues certificates according to local
   policies such as employment status, and then revokes those certificates
   according to the same criteria under which they were issued.  This does
   no violence to the intent of X.509, and requires no changes to products.

3) Use a "trusted OCSP" responder and forget about CRLs.  I think this
   option should be deprecated, but it is documented today in RFC 2560.

4) A fourth option, which of course requires better products, is to
   use a proper PMI.  The PMI standards are there; it's up to product
   developers to determine if there is a market.

I'm not persuaded by "well, products haven't seen fit to support authorization
yet, so let's muck with the authentication standard to support coarse-grained
(yes/no) bastardized privilege management."

Regards,
Dave


Received: by above.proper.com (8.9.3/8.9.3) id CAA15200 for ietf-pkix-bks; Wed, 30 May 2001 02:38:23 -0700 (PDT)
Received: from mail1.gsi.gov.uk (mail.gsi.gov.uk [194.6.79.172]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA15195 for <[e-mail]>; Wed, 30 May 2001 02:38:17 -0700 (PDT)
Received: from eliminator.cesg.gsi.gov.uk (mail2.cesg.gsi.gov.uk [51.64.33.243]) by mail1.gsi.gov.uk (BLOBBY/BLOBBY) with ESMTP id f4U9egQ16010 for <[e-mail]>; Wed, 30 May 2001 10:40:42 +0100 (BST)
Received: by eliminator.cesg.gsi.gov.uk (CHOCCY/GINGER) id LAA20465; Wed, 30 May 2001 11:04:39 +0100 (GMT/BST)
X-Received: suppressed
X-Received: suppressed (id line)
X-Received: suppressed
X-Received: suppressed (id line)
X-Received: suppressed (id line)
X-Received: suppressed
X-Received: suppressed
X-Received: suppressed (id line)
X-Received: suppressed
X-Received: suppressed (id line)
X-Received: suppressed
X-Received: suppressed (id line)
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.4
Date: Wed, 30 May 2001 10:38:41 +0100
From: "Richard Lampard" <[e-mail]>
To: <[e-mail]>
Cc: "Andrew Watson" <[e-mail]>
Subject: Algorithms in PKIX and S/MIME - query
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

We recently completed an interoperability trial looking at PKI and S/MIME v3 interoperability. If you're interested, the final report is available at:

www.cesg.gov.uk/cloudcover/PKIdemonstrator.htm 

We are about to embark on a second phase, this time looking at S/MIME v3 encryption. We are keen to mirror current thinking on S/MIME algorithms, which I
believe is:

Signature generation: DSA or RSA may be implemented
Signature processing: DSA and RSA must both be supported
Key transport: RSA

However, I also believe that PKIX thinking at the moment is that DSA is still the mandatory to implement algorithm for certificate and CRL signing.

This leads to the awkward situation where an implementation, for example, only signs S/MIME messages using RSA, but has to sign its RSA transport keys using
DSA. I can imagine other mismatches whereby the keys for one algorithm are signed by a different algorithm.

This seems to stem from the fact that thinking on algorithms between PKIX and  S/MIME is not yet aligned. I'd be very grateful for some advice on how we should
play our second phase, and what we should be asking vendors to bring to the trial. Is it realistic to expect vendors to support both DSA and RSA, especially in
their CAs?

Many thanks

Richard

Richard Lampard
CESG
PO Box 144
Cheltenham
Gloucestershire GL52 5UE
Tel: [phone] x4086
Fax: [phone]
**********************************************************************
This email and any files transmitted with it is intended solely for 
the use of the individual or entity to whom they are addressed. If 
you have received this email in error please notify 
[e-mail].
**********************************************************************


Received: by above.proper.com (8.9.3/8.9.3) id SAA01807 for ietf-pkix-bks; Tue, 29 May 2001 18:50:14 -0700 (PDT)
Received: from tama3.tas.ntt.co.jp (tama3.tas.ntt.co.jp [192.68.248.40]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA01798 for <[e-mail]>; Tue, 29 May 2001 18:50:04 -0700 (PDT)
Received: from nttmail.ecl.ntt.co.jp (nttmail.tas.ntt.co.jp [192.68.248.11]) by tama3.tas.ntt.co.jp (8.9.3+3.2W/3.7W/01/21/00) with ESMTP id KAA23320; Wed, 30 May 2001 10:49:45 +0900 (JST) (envelope-from [e-mail])
Received: from dsa.isl.ntt.co.jp by nttmail.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/03/21/01) with ESMTP id KAA27923; Wed, 30 May 2001 10:49:39 +0900 (JST) (envelope-from [e-mail])
Received: from cats by dsa.isl.ntt.co.jp (8.9.3/isl-2.0) id KAA12569; Wed, 30 May 2001 10:49:21 +0900 (JST)
Date: Wed, 30 May 2001 10:52:10 +0900
From: Hideyuki Odahara <[e-mail]>
To: [e-mail]
Subject: draft-ietf-pkix-ac509prof -> RFC?
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.00.03
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Mr. Stephen Farrell

Thank you for your reply the example of use of an attribute the other
day.
I would like you to teach about RFC-izing of draft-ietf-pkix-ac509prof
today, and mail was given. While it is said that ac509prof has near
RFC-izing, it is not RFC-ized easily. Now, would you the argument is
progressing how much and teach [ when to RFC-be due to beized and ] this
draft?
Although humiliated a busy place, I ask of you well.

thanks


> 
> Slightly late response, but here it is...
> 
> Syntactically, the access identity attribute can't have the authInfo 
> field present. This basically means that you should use the access
> identity field if the relying party is willing to believe a straight
> assertion from the AA about the holder's identity. In theory that 
> should be enough, but it turns out that there are many applications
> which still require a username & password to identify/authenticate
> a user, so the service auth info attribute allows support for such
> applications.
> 
> As an example of where this might apply, say you inegrate the AC
> relying party code into a web server, with a set of web applications
> being called from the web server. Now some of those applications
> will simply accept a user identity passed from the web server, using
> say the ssl client or holder field for identity, others will have their 
> own concept of usernames (so you can use the access identity for those),
> but still others will have their own username/password handling (so 
> you can use service auth info and not bother the user with entry of
> additional passwords).
> 
> Hope this makes it clearer,
> Stephen.
> 
> Hideyuki Odahara wrote:
> > 
> > Please teach me the difference of the use of
> > "Service Authentication Infomation" and "Access Identity"
> > in Attribute Certificate, and how to use the "Access Identity"
> > attribute if you have any concrete example.
> > 
> > It is described that "this is a different use to that intended
> > for the svceAuthInfo attribute discribed in 4.4.1 above." at the
> > page 19 in the internet-draft(draft-ietf-pkix-ac509prof).
> > But there is no example what situation does it suit.
> > 
> > thanks

----------
  Hideyuki Odahara $B!'(B [e-mail]



Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id RAA27036 for ietf-pkix-bks; Tue, 29 May 2001 17:22:34 -0700 (PDT)
Received: from smtp-2.llnl.gov (smtp-2.llnl.gov [128.115.250.82]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA27027 for <[e-mail]>; Tue, 29 May 2001 17:22:28 -0700 (PDT)
Received: from poptop.llnl.gov (localhost [127.0.0.1]) by smtp-2.llnl.gov (8.9.3/8.9.3/LLNL-gateway-1.0) with ESMTP id RAA28770; Tue, 29 May 2001 17:22:01 -0700 (PDT)
Received: from catalyst.llnl.gov (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id RAA12899; Tue, 29 May 2001 17:22:00 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 29 May 2001 17:29:07 -0700
To: "David P. Kemp" <[e-mail]>, [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: cA flag and CRL issuers (Addendum)
Cc: "Bob Jueneman" <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Dave,

(Some clarification added at the end.)

I agree, "No one but the issuer can revoke that issuer's certification."

But the organization that is my employer should be able to revoke my 
ability to use or trust that certificate.  Moreover, they should be able to 
do so in a manner that is "global" to their body of employees, as easily as 
the CA itself might perform such a revocation.  It should NOT be required 
that each of 5000 employees "do something" via browser settings to effect 
the company's dictate for each such revocation (it could never happen in a 
timely or reliable manner.)

Why, exactly, the PKIX validation algorithm becomes off-limits to this 
endeavor, I am not sure.

I do not intend my comments to hold up PKIX acceptance.  My comments 
address the general concern over the assumptions and direction of future work.

Perhaps my concerns are misplaced, but a "very few" OS/browser vendors 
command the market, and having one's "root" certificate sitting warm and 
cozy in that environment is an enviable situation.  I imagine that 99% of 
casual users are blissfully unaware of how any of this works, and those 
vendors that benefit from the existing arrangement have little motivation 
to really put users in the driver's seat, on the chance they may drive off 
in another trust direction.  The user bought an OS, a browser, and have 
been quietly "opted-in" to a mysterious constellation of trust points, and 
indirectly trusted entities.

An organization (corporate, government) must be the final authority of 
trust for its employees (and, I would argue, individual citizens be their 
own final authority unless they choose to delegate these trust decisions.) 
Software should make it easy for an organization to install their own 
self-signed root certificate, use their "Org-CA-Key" to "certify" the other 
CA root certificates as they choose, and indicate any revocation mechanism 
they see fit.  This need "physically" impact the organization's N-thousand 
user systems only rarely, and thereafter the "standard PKI components" do 
their job as if nothing has changed.  Only the "root" has shifted.

Is there something inherently wrong with this vision? (Honest Question!)

CLARIFICATION:

I do understand why it "won't work" given the current profile 
dictates.  Current mechanics aside, is there something "philosophically" 
wrong with this vision?  The argument that "the user bought the OS, thus 
trust it, thus trust every (mostly hidden) thing it trusts in turn" 
disturbs me.  I suppose an organization could supplant the root of trust, 
but it seems they must climb over a mountain range of trees and rocks to do 
it.  (And given UCITA, it might even be illegal!)

___tony___


At 04:08 PM 5/29/01 -0400, David P. Kemp wrote:
>A Relying Party has the ability to control which CAs it trusts to issue
>certificates, and it also has the option of trusting public keys for which
>no CA has issued a certificate.  It likewise, as you say, has the option of
>accepting a certification which has expired or been revoked by its issuer,
>or refusing to accept, on a case-by-case basis, a certification which has
>not expired or been revoked.
>
>But despite the fact that the Relying Party is always in control of what
>that RP chooses to accept from others, RP applications need a specification
>(the PKIX profile) that tells how to reliably determine what the issuer of
>a certificate thinks about that certificate's current status.
>
>** No one but the issuer can revoke that issuer's certification. **
>
>You may wish to use the X.509 CertificateList data structure to contain
>some other authority's opinion of a certificate, or of the subject of
>that certificate.  That's fine, but you can't call it a CRL or process
>it using the PKIX path validation algorithm.
>
>Dave
>
>
>
>Tony Bartoletti wrote:
> >
> > Bob,
> >
> > I echo your sentiments.
> >
> > A certificate is fundamentally a statement by something called a CA, that
> > says, "We stand behind the associations embodied in this certificate until
> > we say otherwise (or it expires naturally.)"
> >
> > The fact that they made such an assertion, one way or another, is just one
> > piece of data in a relying party's particular trust model.  The RP may
> > either desire to "revoke trust" in that certificate, despite a CA's lack of
> > revocation, or may have reason to wish to continue relying upon a
> > certificate even though the issuing CA has revoked it.
> >
> > It is the Relying Party that Relies.  All others are simply factors in the
> > RP's trust calculation.
> >
> > And a rational PKI profile would recognize this fact and provide
> > corresponding guidance so that end-user products support user ease and
> > flexibility in local trust management.
> >
> > ___tony___

Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900






Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id RAA26187 for ietf-pkix-bks; Tue, 29 May 2001 17:02:33 -0700 (PDT)
Received: from smtp-2.llnl.gov (smtp-2.llnl.gov [128.115.250.82]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA26172 for <[e-mail]>; Tue, 29 May 2001 17:02:27 -0700 (PDT)
Received: from poptop.llnl.gov (localhost [127.0.0.1]) by smtp-2.llnl.gov (8.9.3/8.9.3/LLNL-gateway-1.0) with ESMTP id RAA26599; Tue, 29 May 2001 17:01:59 -0700 (PDT)
Received: from catalyst.llnl.gov (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id RAA05391; Tue, 29 May 2001 17:01:59 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 29 May 2001 17:09:05 -0700
To: "David P. Kemp" <[e-mail]>, [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: cA flag and CRL issuers
Cc: "Bob Jueneman" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Dave,

I agree, "No one but the issuer can revoke that issuer's certification."

But the organization that is my employer should be able to revoke my 
ability to use or trust that certificate.  Moreover, they should be able to 
do so in a manner that is "global" to their body of employees, as easily as 
the CA itself might perform such a revocation.  It should NOT be required 
that each of 5000 employees "do something" via browser settings to effect 
the company's dictate for each such revocation (it could never happen in a 
timely or reliable manner.)

Why, exactly, the PKIX validation algorithm becomes off-limits to this 
endeavor, I am not sure.

I do not intend my comments to hold up PKIX acceptance.  My comments 
address the general concern over the assumptions and direction of future work.

Perhaps my concerns are misplaced, but a "very few" OS/browser vendors 
command the market, and having one's "root" certificate sitting warm and 
cozy in that environment is an enviable situation.  I imagine that 99% of 
casual users are blissfully unaware of how any of this works, and those 
vendors that benefit from the existing arrangement have little motivation 
to really put users in the driver's seat, on the chance they may drive off 
in another trust direction.  The user bought an OS, a browser, and have 
been quietly "opted-in" to a mysterious constellation of trust points, and 
indirectly trusted entities.

An organization (corporate, government) must be the final authority of 
trust for its employees (and, I would argue, individual citizens be their 
own final authority unless they choose to delegate these trust decisions.) 
Software should make it easy for an organization to install their own 
self-signed root certificate, use their "Org-CA-Key" to "certify" the other 
CA root certificates as they choose, and indicate any revocation mechanism 
they see fit.  This need "physically" impact the organization's N-thousand 
user systems only rarely, and thereafter the "standard PKI components" do 
their job as if nothing has changed.  Only the "root" has shifted.

Is there something inherently wrong with this vision? (Honest Question!)

___tony___


At 04:08 PM 5/29/01 -0400, David P. Kemp wrote:
>A Relying Party has the ability to control which CAs it trusts to issue
>certificates, and it also has the option of trusting public keys for which
>no CA has issued a certificate.  It likewise, as you say, has the option of
>accepting a certification which has expired or been revoked by its issuer,
>or refusing to accept, on a case-by-case basis, a certification which has
>not expired or been revoked.
>
>But despite the fact that the Relying Party is always in control of what
>that RP chooses to accept from others, RP applications need a specification
>(the PKIX profile) that tells how to reliably determine what the issuer of
>a certificate thinks about that certificate's current status.
>
>** No one but the issuer can revoke that issuer's certification. **
>
>You may wish to use the X.509 CertificateList data structure to contain
>some other authority's opinion of a certificate, or of the subject of
>that certificate.  That's fine, but you can't call it a CRL or process
>it using the PKIX path validation algorithm.
>
>Dave
>
>
>
>Tony Bartoletti wrote:
> >
> > Bob,
> >
> > I echo your sentiments.
> >
> > A certificate is fundamentally a statement by something called a CA, that
> > says, "We stand behind the associations embodied in this certificate until
> > we say otherwise (or it expires naturally.)"
> >
> > The fact that they made such an assertion, one way or another, is just one
> > piece of data in a relying party's particular trust model.  The RP may
> > either desire to "revoke trust" in that certificate, despite a CA's lack of
> > revocation, or may have reason to wish to continue relying upon a
> > certificate even though the issuing CA has revoked it.
> >
> > It is the Relying Party that Relies.  All others are simply factors in the
> > RP's trust calculation.
> >
> > And a rational PKI profile would recognize this fact and provide
> > corresponding guidance so that end-user products support user ease and
> > flexibility in local trust management.
> >
> > ___tony___

Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900






Received: by above.proper.com (8.9.3/8.9.3) id PAA21032 for ietf-pkix-bks; Tue, 29 May 2001 15:39:05 -0700 (PDT)
Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA21023 for <[e-mail]>; Tue, 29 May 2001 15:38:59 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f4TMctu26288; Tue, 29 May 2001 15:38:55 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Housley, Russ" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Minor OID mistakes in OCSPv2 and the official OID list
Date: Tue, 29 May 2001 15:38:20 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-reply-to: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I think so Russ.  At a minimum we need to leave behind a highly visible and
definitive OID structure.  In my opinion PKIX isn't done until we document
all that we've defined.

Mike



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

> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
> Sent: Tuesday, May 29, 2001 2:32 PM
> To: Michael Myers
> Cc: Russ Housley; [e-mail]
> Subject: RE: Minor OID mistakes in OCSPv2 and the official OID list
>
>
> Mike:
>
> This seems like a reasonable thing to do as the PKIX WG is winding
> down.  Is there really any point in a document that documents the
> current snapshot?
>
> Russ
>
> At 02:13 PM 5/29/2001 -0700, Michael Myers wrote:
> >Russ,
> >
> >Good to hear of this.  Thanks.  Any chance for an Informational
> >I-D laying out the OID structure?  I'm willing to help.
> >
> >Mi



Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA16303 for ietf-pkix-bks; Tue, 29 May 2001 14:33:46 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id OAA16288; Tue, 29 May 2001 14:33:39 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 29 May 2001 21:33:00 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id RAA11822; Tue, 29 May 2001 17:33:41 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <LR8TB1XF>; Tue, 29 May 2001 17:33:41 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.100.22.73]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TB1XC; Tue, 29 May 2001 17:33:36 -0400
From: "Housley, Russ" <[e-mail]>
To: Michael Myers <[e-mail]>
Cc: Russ Housley <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 29 May 2001 17:32:03 -0400
Subject: RE: Minor OID mistakes in OCSPv2 and the official OID list
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Mike:

This seems like a reasonable thing to do as the PKIX WG is winding 
down.  Is there really any point in a document that documents the current 
snapshot?

Russ

At 02:13 PM 5/29/2001 -0700, Michael Myers wrote:
>Russ,
>
>Good to hear of this.  Thanks.  Any chance for an Informational I-D laying
>out the OID structure?  I'm willing to help.
>
>Mike
>
>
>
>Michael Myers
>t: +415.819.1362
>e: mailto:[e-mail]
>w: http://www.traceroutesecurity.com
>
> > -----Original Message-----
> > From: Russ Housley [mailto:[e-mail]]
> > Sent: Tuesday, May 29, 2001 1:05 PM
> > To: [e-mail]; [e-mail]
> > Cc: [e-mail]
> > Subject: RE: Minor OID mistakes in OCSPv2 and the official OID list
> >
> >
> > Mike:
> >
> > Temporal Data Authority (TDA) has disappeared from the TSP
> > document. So, no
> > OID is needed for it, and it can be re-assigned. We got luckly this time,
> > so I did the reassignment.
> >
> >       id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }
> >
> > Please help avoid future collisions!  In the future, any PKIX document
> > editor that needs an OID, please send mail to
> > [e-mail] to
> > request it.  Do not make a guess at the value that might be assigned!
> >
> > Regards,
> >    Russ
> >
> >  > >From: "Michael Myers" <[e-mail]>
> >  > >To: <[e-mail]>, <[e-mail]>,
> >  > >         <[e-mail]>, <[e-mail]>
> >  > >Subject: RE: Minor OID mistakes in OCSPv2 and the official OID list
> >  > >Date: Fri, 18 May 2001 13:01:16 -0700
> >  > >X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
> >  > >Importance: Normal
> >  > >Sender: [e-mail]
> >  > >List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
> >  > >List-ID: <ietf-pkix.imc.org>
> >  > >List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
> >  > >List-ID: <ietf-pkix.imc.org>
> >  > >
> >  > >
> >  > >On Saturday, May 19, 2001, at the inspiring hour of 3:30 AM,
> > Peter Gutman
> >  > >advised:
> >  > >
> >  > > > Given that there are already certs (and lots of software)
> >  > > > out there which use the current OID, wouldn't it be better
> >  > > > to relocate temporalDataAuthority (what is that anyway?
> >  > > > Does anyone use it? It looks like an oddly-named TSA OID).
> >  > > >
> >  > > > (Given that the OCSP OID is already in active use, I suspect
> >  > > > {id-kp 9} will remain "the OCSP OID" even if it's officially
> >  > > >  reassigned, this my comment that it's going to be easier for
> >  > > > Mohammed to go to the mountain).
> >  > > >
> >  > > > Peter.
> >  > >
> >  > >Peter,
> >  > >
> >  > >Certainly a more pragmatic approach.  As a consequence I've
> > spent some time
> >  > >today searching across the various current and historical IETF work
> > products
> >  > >to do kind of an environmental impact assessment of simply
> > re-labelling
> >  > >{id-kp 9} from "id-kp-temporalDataAuthority" to "id-kp-OCSPSigning".
> >  > >
> >  > >As it turns out, the notion of a Temporal Data Authority (TDA) and a
> >  > >corresponding {id-kp 9} definition was introduced at least by
> >  >
> > >http://www.ietf.org/proceedings/99jul/I-D/draft-ietf-pkix-time-stamp-02.
> > txt.
> >  > >However, by the -14 edition the concept went away:
> >  > >http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-14.txt.
> >  > >
> >  > >So the path seems clear to redefine {id-kp 9} as
> > id-kp-OCSPSigning with no
> >  > >impact to timestamping implementors.  Doing so would benefit
> > standing OCSP
> >  > >implementations but does not excuse the OCSP authors, myself
> > included, from
> >  > >a swift kick in the butt for failing to coordinate across the
> > WG on this
> >  > >point.
> >  > >
> >  > >Incidentally, it might be useful to produce the relevant OID
> > list into a
> >  > >PKIX work product so that once PKIX wraps clues are left
> > behind how the
> >  > >pieces are supposed to bolt together.
> >  > >
> >  > >Mike
> >  > >
> >  > >
> >  > >Michael Myers
> >  > >t: +415.819.1362
> >  > >e: mailto:[e-mail]
> >  > >w: http://www.traceroutesecurity.com
> >


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA16150 for ietf-pkix-bks; Tue, 29 May 2001 14:31:38 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA16126 for <[e-mail]>; Tue, 29 May 2001 14:31:31 -0700 (PDT)
Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 29 May 2001 15:30:57 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Tue, 29 May 2001 15:31:12 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: cA flag and CRL issuers
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id OAA16128
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

David,

Please see my comments in-line.
>
>>>> "David P. Kemp" <[e-mail]> 05/29/01 02:08PM >>>
>A Relying Party has the ability to control which CAs it trusts to issue
>certificates, and it also has the option of trusting public keys for which
>no CA has issued a certificate.  It likewise, as you say, has the option of
>accepting a certification which has expired or been revoked by its issuer,
>or refusing to accept, on a case-by-case basis, a certification which has
>not expired or been revoked.

OK, so we are at least agreed in principle regarding the question of managing trust from the RP's perspective.
>
>But despite the fact that the Relying Party is always in control of what
>that RP chooses to accept from others, RP applications need a specification
>(the PKIX profile) that tells how to reliably determine what the issuer of
>a certificate thinks about that certificate's current status.

I would certainly agree that what the issuer thinks is at least relevant.  And if the issuer says that it is revoked for cause (as opposed to merely expired, or perhaps a trivial address update), then if I were the RP or the determining organization, I would certainly think long an hard before continuing to trust it.

However, the CA should not have an equal vote in the matter if the CA knows of no reason why the certificate should not be trusted but the RP does, (or for that matter even some other credible party, such as a state registration agency or licensing authority, as provided for under a number of state and foreign country's laws.)
>
>** No one but the issuer can revoke that issuer's certification. **

Well, that is precisely the disagreement, isn't it?  Or let me clarify that just a bit.  What I care about is revoking the certificate itself.  Revoking the issuer's certification of that certificate is a slight, but perhaps a significant nuance of difference.
>
>You may wish to use the X.509 CertificateList data structure to contain
>some other authority's opinion of a certificate, or of the subject of
>that certificate.  That's fine, but you can't call it a CRL or process
>it using the PKIX path validation algorithm.

And just why not?  Did I miss that particular tablet of stone somewhere?  I thought that was what we were debating.

I'm always willing to consider other, alternative means of achieving any particular objective, so long as they are reasonably well standardized and widely implemented on commercial software packages.  But if I were the RP's organization, I would certainly NOT like to have to throw out all of my browsers, my S/MIME software, etc., just to achieve this objective -- that's a non-starter.

As someone else said, I don't care whether we call this a CRL, or an RPCRL, or a french fry, so long as it works.  But saying ipso facto that this mechanism cannot be processed using the {PKIX path validation algorithm would seem to be jumping to a conclusion, since that was the question at hand.

In particular, merely putting a certificate in some kind of a blackballed data structure, as I think you are proposing (I'm putting words in your mouth, so correct me if I am wrong), would probably NOT be sufficient, and especially from a nonrepudiation standpoint, because as I understand it those certificate structures would not be cryptographically bound to a reliable source.  And even though it would be the RP's organization that would presumably post this particular french fry, it still seems worth providing a nonrepudiable binding mechanism.

So from the standpoint of minimizing development cost and maximizing interoperability, processing a local revocation of a certificate via the PKIX path validation algorithm is PRECISELY what I would like to do.  

Bob





Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA14809 for ietf-pkix-bks; Tue, 29 May 2001 14:14:39 -0700 (PDT)
Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA14756; Tue, 29 May 2001 14:14:16 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f4TLEIu20428; Tue, 29 May 2001 14:14:18 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Russ Housley" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Minor OID mistakes in OCSPv2 and the official OID list
Date: Tue, 29 May 2001 14:13:42 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-reply-to: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Russ,

Good to hear of this.  Thanks.  Any chance for an Informational I-D laying
out the OID structure?  I'm willing to help.

Mike



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

> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Tuesday, May 29, 2001 1:05 PM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: RE: Minor OID mistakes in OCSPv2 and the official OID list
>
>
> Mike:
>
> Temporal Data Authority (TDA) has disappeared from the TSP
> document. So, no
> OID is needed for it, and it can be re-assigned. We got luckly this time,
> so I did the reassignment.
>
>       id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }
>
> Please help avoid future collisions!  In the future, any PKIX document
> editor that needs an OID, please send mail to
> [e-mail] to
> request it.  Do not make a guess at the value that might be assigned!
>
> Regards,
>    Russ
>
>  > >From: "Michael Myers" <[e-mail]>
>  > >To: <[e-mail]>, <[e-mail]>,
>  > >         <[e-mail]>, <[e-mail]>
>  > >Subject: RE: Minor OID mistakes in OCSPv2 and the official OID list
>  > >Date: Fri, 18 May 2001 13:01:16 -0700
>  > >X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
>  > >Importance: Normal
>  > >Sender: [e-mail]
>  > >List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
>  > >List-ID: <ietf-pkix.imc.org>
>  > >List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
>  > >List-ID: <ietf-pkix.imc.org>
>  > >
>  > >
>  > >On Saturday, May 19, 2001, at the inspiring hour of 3:30 AM,
> Peter Gutman
>  > >advised:
>  > >
>  > > > Given that there are already certs (and lots of software)
>  > > > out there which use the current OID, wouldn't it be better
>  > > > to relocate temporalDataAuthority (what is that anyway?
>  > > > Does anyone use it? It looks like an oddly-named TSA OID).
>  > > >
>  > > > (Given that the OCSP OID is already in active use, I suspect
>  > > > {id-kp 9} will remain "the OCSP OID" even if it's officially
>  > > >  reassigned, this my comment that it's going to be easier for
>  > > > Mohammed to go to the mountain).
>  > > >
>  > > > Peter.
>  > >
>  > >Peter,
>  > >
>  > >Certainly a more pragmatic approach.  As a consequence I've
> spent some time
>  > >today searching across the various current and historical IETF work
> products
>  > >to do kind of an environmental impact assessment of simply
> re-labelling
>  > >{id-kp 9} from "id-kp-temporalDataAuthority" to "id-kp-OCSPSigning".
>  > >
>  > >As it turns out, the notion of a Temporal Data Authority (TDA) and a
>  > >corresponding {id-kp 9} definition was introduced at least by
>  >
> >http://www.ietf.org/proceedings/99jul/I-D/draft-ietf-pkix-time-stamp-02.
> txt.
>  > >However, by the -14 edition the concept went away:
>  > >http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-14.txt.
>  > >
>  > >So the path seems clear to redefine {id-kp 9} as
> id-kp-OCSPSigning with no
>  > >impact to timestamping implementors.  Doing so would benefit
> standing OCSP
>  > >implementations but does not excuse the OCSP authors, myself
> included, from
>  > >a swift kick in the butt for failing to coordinate across the
> WG on this
>  > >point.
>  > >
>  > >Incidentally, it might be useful to produce the relevant OID
> list into a
>  > >PKIX work product so that once PKIX wraps clues are left
> behind how the
>  > >pieces are supposed to bolt together.
>  > >
>  > >Mike
>  > >
>  > >
>  > >Michael Myers
>  > >t: +415.819.1362
>  > >e: mailto:[e-mail]
>  > >w: http://www.traceroutesecurity.com
>



Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA10892 for ietf-pkix-bks; Tue, 29 May 2001 13:31:23 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA10877 for <[e-mail]>; Tue, 29 May 2001 13:31:15 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Tue, 29 May 2001 13:31:35 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Tue, 29 May 2001 13:31:34 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <HR26T3B4>; Tue, 29 May 2001 13:28:44 -0700
Content-return: allowed
Date: Tue, 29 May 2001 13:28:40 -0700
From: Peter Williams <[e-mail]>
Subject: RE: cA flag and CRL issuers
To: "'Tony Bartoletti'" <[e-mail]>, Bob Jueneman <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"
Importance: low
X-Priority: 5
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Tony and Bob:

Based on elements of my doctoral investigations in
1992/3, in 1997 I penned chapter 12 "secure electronic commerce"
of a book I co-authored with others: "Digital Certificates".
That chapter expounds a doctrine of relying-party trust; my aim
was to make readers think about the design options when profiling; 
PKIX provided little rationalization for its design decisions, and
has always lacked sensitivity to commercial credentialing practices. You
can read about similar issues in Tom Austin's book on PKI, in
my view. These profiling themes contrast markedly with the scholarly
doctrine reflected in the books of Housley, Adams, etc., which
would have you believe that Internet PKI was (a) a single camp of thought
reflected in PKIX docs, and (b) you, the Internet end-consumer, are, 
quite properly, just a robotic subscriber.

The main reason I left (1997-style) verisign for valicert was because the
latter's business model (1998) focussed on a (modernised) method for
bridging 
the competing goals of mandatory and discretionary security policy 
enforcement. given hindsight I'd now write the afore-mentioned chapter quite

differently, for a 2002 audience given actual infrastructure deployment 
events since 1998. The current issues of CA bit (like the NR bit) are the 
manifestation of the quite principled but very different security policy 
philosophies present within our user and design communities, in my view.

Despite my reservations, I do think we need to finish 2459+ Final Call, and 
respect the hard work that the tightly-nit PKIX author and advisor group
have 
put in. Im not  sure its the standard that reflects the WG, or the needs of
the Internet 
enviroment. But, it does act as the snapshot lynchpin, that makes the 
document set reasonably consistent and coherent, for this point in time. 
We should ensure we consolidate this fine technical achievement, even
if security policy matters will need further standardization at another
time, or in another forum that cares less about trusted keys and more
about trusted interworking.

Postcript:

It will be interesting to see what the authors in
http://www.amazon.com/exec/obidos/ASIN/0850926602/qid=991167837/sr=1-3/ref=s
c_b_3/107-6570836-8267712
have to say on infrastructure thenes, as reflection of a large (US) 
govt's position when delivering services via the Internet.

-----Original Message-----
From: Tony Bartoletti [mailto:[e-mail]]
Sent: Tuesday, May 29, 2001 12:14 PM
To: Bob Jueneman; [e-mail]
Cc: [e-mail]
Subject: RE: cA flag and CRL issuers


Bob,

I echo your sentiments.

A certificate is fundamentally a statement by something called a CA, that 
says, "We stand behind the associations embodied in this certificate until 
we say otherwise (or it expires naturally.)"

The fact that they made such an assertion, one way or another, is just one 
piece of data in a relying party's particular trust model.  The RP may 
either desire to "revoke trust" in that certificate, despite a CA's lack of 
revocation, or may have reason to wish to continue relying upon a 
certificate even though the issuing CA has revoked it.

It is the Relying Party that Relies.  All others are simply factors in the 
RP's trust calculation.

And a rational PKI profile would recognize this fact and provide 
corresponding guidance so that end-user products support user ease and 
flexibility in local trust management.

___tony___


At 11:28 AM 5/29/01 -0600, Bob Jueneman wrote:
>Michael,
>
>I commented on this earlier, but no one picked up on it.  Maybe it got 
>lost in the noise.
>
>Generally, I would agree with you.  However, the entire purpose of PKI is 
>to serve the needs of the relying party, first and foremost.  And since 
>the most cases the relying party is a member of an organization that may 
>wish to impose some collective rules for processing certificates, I 
>believe that necessitates the ability to have the option for LOCAL control 
>over CRLs and OCSP responses.
>
>Since in the general the subscriber or issuing CA may not even know who 
>the relying parties may be, this means in particular that it is NOT always 
>possible, nor desirable to require that the source of a CRL must 
>necessarily be named in advance, for example in a CRLDistributionPoint, or 
>signed or otherwise anointed by the CA, for that would turn the relying 
>party trust model on its head.
>
>So I would rephrase your requirement to state that the provenance of a 
>certificate, including its current validity and trust status or lack 
>thereof, must link back in a technical fashion to a trust root installed 
>in the relying party's software.  Assuming that the CA's, AA's, etc., root 
>is installed the RP software, your requirement is a proper subset of what 
>I am proposing.
>
>"Is there anyone else thinking same way, or am I unique in this
perspective?"
>
>Bob
>
>Robert R. Jueneman
>Security Architect
>
>Novell, Inc -- the leading provider of Net services software
>
>
>
> >>> "Michael Myers" <[e-mail]> 05/29/01 11:07AM >>>
>All,
>
>Regarding this thread, it seems to me that whether setting the cA bit for
PK
>certs, establishing algorithmic logic regarding naming or authorizations,
>maybe in the long run inventing a cA bit equivalent for ACs or whatever
>other technical mechanism we may devise, there exists a meta-requirement
>that the provenance of a digital credential MUST link back in a technical
>fashion to the source of its original issuance.  Is anyone else thinking
the
>same way or am I unique in this perspective?
>
>Mike
>
>
>Michael Myers
>t: +415.819.1362
>e: mailto:[e-mail]
>w: http://www.traceroutesecurity.com

Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900





Received: by above.proper.com (8.9.3/8.9.3) id NAA09389 for ietf-pkix-bks; Tue, 29 May 2001 13:11:56 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA09381 for <[e-mail]>; Tue, 29 May 2001 13:11:50 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id QAA29075 for <[e-mail]>; Tue, 29 May 2001 16:11:46 -0400 (EDT)
Received: from reject.missi.ncsc.mil (reject.missi.ncsc.mil [144.51.60.17]) by stingray.missi.ncsc.mil with SMTP id QAA29071 for <[e-mail]>; Tue, 29 May 2001 16:11:46 -0400 (EDT)
Received: from 144.51.60.215 by reject.missi.ncsc.mil (InterScan E-Mail VirusWall NT); Tue, 29 May 2001 16:14:06 -0400 (Eastern Daylight Time)
Received: from missi.ncsc.mil (ara.missi.ncsc.mil [144.51.55.128]) by amx.missi.ncsc.mil with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LQK7KKMF; Tue, 29 May 2001 16:15:04 -0400
Message-ID: <[e-mail]>
Date: Tue, 29 May 2001 16:08:21 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: cA flag and CRL issuers
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

A Relying Party has the ability to control which CAs it trusts to issue
certificates, and it also has the option of trusting public keys for which
no CA has issued a certificate.  It likewise, as you say, has the option of
accepting a certification which has expired or been revoked by its issuer,
or refusing to accept, on a case-by-case basis, a certification which has
not expired or been revoked.

But despite the fact that the Relying Party is always in control of what
that RP chooses to accept from others, RP applications need a specification
(the PKIX profile) that tells how to reliably determine what the issuer of
a certificate thinks about that certificate's current status.

** No one but the issuer can revoke that issuer's certification. **

You may wish to use the X.509 CertificateList data structure to contain
some other authority's opinion of a certificate, or of the subject of
that certificate.  That's fine, but you can't call it a CRL or process
it using the PKIX path validation algorithm.

Dave



Tony Bartoletti wrote:
> 
> Bob,
> 
> I echo your sentiments.
> 
> A certificate is fundamentally a statement by something called a CA, that
> says, "We stand behind the associations embodied in this certificate until
> we say otherwise (or it expires naturally.)"
> 
> The fact that they made such an assertion, one way or another, is just one
> piece of data in a relying party's particular trust model.  The RP may
> either desire to "revoke trust" in that certificate, despite a CA's lack of
> revocation, or may have reason to wish to continue relying upon a
> certificate even though the issuing CA has revoked it.
> 
> It is the Relying Party that Relies.  All others are simply factors in the
> RP's trust calculation.
> 
> And a rational PKI profile would recognize this fact and provide
> corresponding guidance so that end-user products support user ease and
> flexibility in local trust management.
> 
> ___tony___


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA06032 for ietf-pkix-bks; Tue, 29 May 2001 12:07:30 -0700 (PDT)
Received: from smtp-1.llnl.gov (smtp-1.llnl.gov [128.115.250.81]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA06027 for <[e-mail]>; Tue, 29 May 2001 12:07:24 -0700 (PDT)
Received: from poptop.llnl.gov (localhost [127.0.0.1]) by smtp-1.llnl.gov (8.9.3/8.9.3/LLNL-gateway-1.0) with ESMTP id MAA08720; Tue, 29 May 2001 12:06:55 -0700 (PDT)
Received: from catalyst.llnl.gov (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id MAA19475; Tue, 29 May 2001 12:06:56 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 29 May 2001 12:14:03 -0700
To: "Bob Jueneman" <[e-mail]>, <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: RE: cA flag and CRL issuers
Cc: <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Bob,

I echo your sentiments.

A certificate is fundamentally a statement by something called a CA, that 
says, "We stand behind the associations embodied in this certificate until 
we say otherwise (or it expires naturally.)"

The fact that they made such an assertion, one way or another, is just one 
piece of data in a relying party's particular trust model.  The RP may 
either desire to "revoke trust" in that certificate, despite a CA's lack of 
revocation, or may have reason to wish to continue relying upon a 
certificate even though the issuing CA has revoked it.

It is the Relying Party that Relies.  All others are simply factors in the 
RP's trust calculation.

And a rational PKI profile would recognize this fact and provide 
corresponding guidance so that end-user products support user ease and 
flexibility in local trust management.

___tony___


At 11:28 AM 5/29/01 -0600, Bob Jueneman wrote:
>Michael,
>
>I commented on this earlier, but no one picked up on it.  Maybe it got 
>lost in the noise.
>
>Generally, I would agree with you.  However, the entire purpose of PKI is 
>to serve the needs of the relying party, first and foremost.  And since 
>the most cases the relying party is a member of an organization that may 
>wish to impose some collective rules for processing certificates, I 
>believe that necessitates the ability to have the option for LOCAL control 
>over CRLs and OCSP responses.
>
>Since in the general the subscriber or issuing CA may not even know who 
>the relying parties may be, this means in particular that it is NOT always 
>possible, nor desirable to require that the source of a CRL must 
>necessarily be named in advance, for example in a CRLDistributionPoint, or 
>signed or otherwise anointed by the CA, for that would turn the relying 
>party trust model on its head.
>
>So I would rephrase your requirement to state that the provenance of a 
>certificate, including its current validity and trust status or lack 
>thereof, must link back in a technical fashion to a trust root installed 
>in the relying party's software.  Assuming that the CA's, AA's, etc., root 
>is installed the RP software, your requirement is a proper subset of what 
>I am proposing.
>
>"Is there anyone else thinking same way, or am I unique in this perspective?"
>
>Bob
>
>Robert R. Jueneman
>Security Architect
>
>Novell, Inc -- the leading provider of Net services software
>
>
>
> >>> "Michael Myers" <[e-mail]> 05/29/01 11:07AM >>>
>All,
>
>Regarding this thread, it seems to me that whether setting the cA bit for PK
>certs, establishing algorithmic logic regarding naming or authorizations,
>maybe in the long run inventing a cA bit equivalent for ACs or whatever
>other technical mechanism we may devise, there exists a meta-requirement
>that the provenance of a digital credential MUST link back in a technical
>fashion to the source of its original issuance.  Is anyone else thinking the
>same way or am I unique in this perspective?
>
>Mike
>
>
>Michael Myers
>t: +415.819.1362
>e: mailto:[e-mail]
>w: http://www.traceroutesecurity.com

Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900






Received: by above.proper.com (8.9.3/8.9.3) id KAA02018 for ietf-pkix-bks; Tue, 29 May 2001 10:29:26 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA02010 for <[e-mail]>; Tue, 29 May 2001 10:29:20 -0700 (PDT)
Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 29 May 2001 11:28:41 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Tue, 29 May 2001 11:28:59 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: cA flag and CRL issuers
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id KAA02012
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Michael,

I commented on this earlier, but no one picked up on it.  Maybe it got lost in the noise.

Generally, I would agree with you.  However, the entire purpose of PKI is to serve the needs of the relying party, first and foremost.  And since the most cases the relying party is a member of an organization that may wish to impose some collective rules for processing certificates, I believe that necessitates the ability to have the option for LOCAL control over CRLs and OCSP responses.

Since in the general the subscriber or issuing CA may not even know who the relying parties may be, this means in particular that it is NOT always possible, nor desirable to require that the source of a CRL must necessarily be named in advance, for example in a CRLDistributionPoint, or signed or otherwise anointed by the CA, for that would turn the relying party trust model on its head.

So I would rephrase your requirement to state that the provenance of a certificate, including its current validity and trust status or lack thereof, must link back in a technical fashion to a trust root installed in the relying party's software.  Assuming that the CA's, AA's, etc., root is installed the RP software, your requirement is a proper subset of what I am proposing.

"Is there anyone else thinking same way, or am I unique in this perspective?"

Bob

Robert R. Jueneman
Security Architect

Novell, Inc -- the leading provider of Net services software



>>> "Michael Myers" <[e-mail]> 05/29/01 11:07AM >>>
All,

Regarding this thread, it seems to me that whether setting the cA bit for PK
certs, establishing algorithmic logic regarding naming or authorizations,
maybe in the long run inventing a cA bit equivalent for ACs or whatever
other technical mechanism we may devise, there exists a meta-requirement
that the provenance of a digital credential MUST link back in a technical
fashion to the source of its original issuance.  Is anyone else thinking the
same way or am I unique in this perspective?

Mike


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




Received: by above.proper.com (8.9.3/8.9.3) id KAA00804 for ietf-pkix-bks; Tue, 29 May 2001 10:08:46 -0700 (PDT)
Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA00792 for <[e-mail]>; Tue, 29 May 2001 10:08:41 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f4TH8Hu03962; Tue, 29 May 2001 10:08:17 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, "David P. Kemp" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: cA flag and CRL issuers
Date: Tue, 29 May 2001 10:07:44 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-reply-to: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

All,

Regarding this thread, it seems to me that whether setting the cA bit for PK
certs, establishing algorithmic logic regarding naming or authorizations,
maybe in the long run inventing a cA bit equivalent for ACs or whatever
other technical mechanism we may devise, there exists a meta-requirement
that the provenance of a digital credential MUST link back in a technical
fashion to the source of its original issuance.  Is anyone else thinking the
same way or am I unique in this perspective?

Mike


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



Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id EAA03697 for ietf-pkix-bks; Tue, 29 May 2001 04:02:41 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA03686 for <[e-mail]>; Tue, 29 May 2001 04:02:35 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28295; Tue, 29 May 2001 07:02:17 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-time-stamp-15.txt
Date: Tue, 29 May 2001 07:02:16 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Time Stamp 
                          Protocols (TSP)
	Author(s)	: C. Adams, P. Cain, D. Pinkas, R. Zuccherato
	Filename	: draft-ietf-pkix-time-stamp-15.txt
	Pages		: 26
	Date		: 25-May-01
	
A time stamping service supports assertions of proof that a datum 
existed before a particular time. This document describes the format 
of a request sent to a Time Stamping Authority (TSA) and of the 
response that is returned. It also establishes several security-
relevant requirements for TSA operation, with regards to processing 
requests to generate responses. A TSA may be operated as a Trusted 
Third Party (TTP) service, though other operational models may be 
appropriate, e.g. an organization might require a TSA for internal 
time stamping purposes. 

Non-repudiation services [ISONR] require the ability to establish the 
existence of data before specified times. This protocol may be used as 
a building block to support such services. An example of how to prove 
that a digital signature was generated during the validity period of 
a public key certificate is given in an annex.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-15.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-time-stamp-15.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-time-stamp-15.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-time-stamp-15.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-time-stamp-15.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id GAA01267 for ietf-pkix-bks; Fri, 25 May 2001 06:28:41 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA01256 for <[e-mail]>; Fri, 25 May 2001 06:28:35 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <LT4XFD89>; Fri, 25 May 2001 09:28:05 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: "David P. Kemp" <[e-mail]>
Cc: [e-mail]
Subject: RE: cA flag and CRL issuers
Date: Fri, 25 May 2001 09:18:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0E51D.30B1E0F0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0E51D.30B1E0F0
Content-Type: text/plain;
	charset="iso-8859-1"

Dave:

My last response to Steve was a la yours, do not require generators to
assert the basicConstraints either.

-----Original Message-----
From: David P. Kemp [mailto:[e-mail]]
Sent: Friday, May 25, 2001 9:09 AM
Cc: [e-mail]
Subject: Re: cA flag and CRL issuers


Carlin Covey wrote:
> Some postings in this thread have attached significance to the fact that
> X.509 does not discuss whether the CA bit should be set when cRLSign is
true
> but keyCertSign is false.  I agree with you, Russ, that the discussion
> should center on the level of flexibility and complexity that the PKIX
> community want to embrace in its certificate and CRL profile, rather than
> the nuances of text omissions in X.509.

Yes.


> I also agree that Sharon does a fine job in representing X.509's view.  I
> understand that she is on vacation at the moment.

Yes!  It is exceedingly rare to find in one person her level of technical
understanding, fairness, and equanimity.  Thank you, Sharon. 


> All that said, let me now second Santosh's proposal: "I vote for not
> requiring the cA flag for CRL check and making appropriate changes to
X.509
> and to PKIX to make it clear and consistent."  - Santosh Chokhani, 24 May
> 2001

Yes.  However, for consistency you need a generation non-requirement
in addition to Santosh's recipient non-requirement:  I vote for not
requiring the cA flag for CRL generation or checking and for making
appropriate changes to X.509 and to PKIX to make them clear and consistent.


> To streamline the algorithm a little further, I suggest that we ask X.509
to
> allow the keyCertSign bit to be asserted in Attribute Authority
> certificates, as well as CA certificates.  As far as I can see, that would
> make the CRL validation algorithm identical for AA-issued and CA-issued
> CRL's.

No.  I support reserving the keyCertSign bit exclusively for use in
certificates of issuers of (public-) key certificates.


Regards,

Dave

------_=_NextPart_001_01C0E51D.30B1E0F0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: cA flag and CRL issuers</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Dave:</FONT>
</P>

<P><FONT SIZE=2>My last response to Steve was a la yours, do not require generators to assert the basicConstraints either.</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: David P. Kemp [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>Sent: Friday, May 25, 2001 9:09 AM</FONT>
<BR><FONT SIZE=2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=2>Subject: Re: cA flag and CRL issuers</FONT>
</P>
<BR>

<P><FONT SIZE=2>Carlin Covey wrote:</FONT>
<BR><FONT SIZE=2>&gt; Some postings in this thread have attached significance to the fact that</FONT>
<BR><FONT SIZE=2>&gt; X.509 does not discuss whether the CA bit should be set when cRLSign is true</FONT>
<BR><FONT SIZE=2>&gt; but keyCertSign is false.&nbsp; I agree with you, Russ, that the discussion</FONT>
<BR><FONT SIZE=2>&gt; should center on the level of flexibility and complexity that the PKIX</FONT>
<BR><FONT SIZE=2>&gt; community want to embrace in its certificate and CRL profile, rather than</FONT>
<BR><FONT SIZE=2>&gt; the nuances of text omissions in X.509.</FONT>
</P>

<P><FONT SIZE=2>Yes.</FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt; I also agree that Sharon does a fine job in representing X.509's view.&nbsp; I</FONT>
<BR><FONT SIZE=2>&gt; understand that she is on vacation at the moment.</FONT>
</P>

<P><FONT SIZE=2>Yes!&nbsp; It is exceedingly rare to find in one person her level of technical</FONT>
<BR><FONT SIZE=2>understanding, fairness, and equanimity.&nbsp; Thank you, Sharon. </FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt; All that said, let me now second Santosh's proposal: &quot;I vote for not</FONT>
<BR><FONT SIZE=2>&gt; requiring the cA flag for CRL check and making appropriate changes to X.509</FONT>
<BR><FONT SIZE=2>&gt; and to PKIX to make it clear and consistent.&quot;&nbsp; - Santosh Chokhani, 24 May</FONT>
<BR><FONT SIZE=2>&gt; 2001</FONT>
</P>

<P><FONT SIZE=2>Yes.&nbsp; However, for consistency you need a generation non-requirement</FONT>
<BR><FONT SIZE=2>in addition to Santosh's recipient non-requirement:&nbsp; I vote for not</FONT>
<BR><FONT SIZE=2>requiring the cA flag for CRL generation or checking and for making</FONT>
<BR><FONT SIZE=2>appropriate changes to X.509 and to PKIX to make them clear and consistent.</FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt; To streamline the algorithm a little further, I suggest that we ask X.509 to</FONT>
<BR><FONT SIZE=2>&gt; allow the keyCertSign bit to be asserted in Attribute Authority</FONT>
<BR><FONT SIZE=2>&gt; certificates, as well as CA certificates.&nbsp; As far as I can see, that would</FONT>
<BR><FONT SIZE=2>&gt; make the CRL validation algorithm identical for AA-issued and CA-issued</FONT>
<BR><FONT SIZE=2>&gt; CRL's.</FONT>
</P>

<P><FONT SIZE=2>No.&nbsp; I support reserving the keyCertSign bit exclusively for use in</FONT>
<BR><FONT SIZE=2>certificates of issuers of (public-) key certificates.</FONT>
</P>
<BR>

<P><FONT SIZE=2>Regards,</FONT>
</P>

<P><FONT SIZE=2>Dave</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0E51D.30B1E0F0--


Received: by above.proper.com (8.9.3/8.9.3) id GAA00119 for ietf-pkix-bks; Fri, 25 May 2001 06:13:38 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA00113 for <[e-mail]>; Fri, 25 May 2001 06:13:32 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id JAA08583 for <[e-mail]>; Fri, 25 May 2001 09:13:20 -0400 (EDT)
Received: from reject.missi.ncsc.mil (reject.missi.ncsc.mil [144.51.60.17]) by stingray.missi.ncsc.mil with SMTP id JAA08579 for <[e-mail]>; Fri, 25 May 2001 09:13:20 -0400 (EDT)
Received: from 144.51.60.215 by reject.missi.ncsc.mil (InterScan E-Mail VirusWall NT); Fri, 25 May 2001 09:15:56 -0400 (Eastern Daylight Time)
Received: from missi.ncsc.mil (ara.missi.ncsc.mil [144.51.55.128]) by amx.missi.ncsc.mil with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LQK7K1AF; Fri, 25 May 2001 09:16:40 -0400
Message-ID: <[e-mail]>
Date: Fri, 25 May 2001 09:09:15 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: cA flag and CRL issuers
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Carlin Covey wrote:
> Some postings in this thread have attached significance to the fact that
> X.509 does not discuss whether the CA bit should be set when cRLSign is true
> but keyCertSign is false.  I agree with you, Russ, that the discussion
> should center on the level of flexibility and complexity that the PKIX
> community want to embrace in its certificate and CRL profile, rather than
> the nuances of text omissions in X.509.

Yes.


> I also agree that Sharon does a fine job in representing X.509's view.  I
> understand that she is on vacation at the moment.

Yes!  It is exceedingly rare to find in one person her level of technical
understanding, fairness, and equanimity.  Thank you, Sharon. 


> All that said, let me now second Santosh's proposal: "I vote for not
> requiring the cA flag for CRL check and making appropriate changes to X.509
> and to PKIX to make it clear and consistent."  - Santosh Chokhani, 24 May
> 2001

Yes.  However, for consistency you need a generation non-requirement
in addition to Santosh's recipient non-requirement:  I vote for not
requiring the cA flag for CRL generation or checking and for making
appropriate changes to X.509 and to PKIX to make them clear and consistent.


> To streamline the algorithm a little further, I suggest that we ask X.509 to
> allow the keyCertSign bit to be asserted in Attribute Authority
> certificates, as well as CA certificates.  As far as I can see, that would
> make the CRL validation algorithm identical for AA-issued and CA-issued
> CRL's.

No.  I support reserving the keyCertSign bit exclusively for use in
certificates of issuers of (public-) key certificates.


Regards,

Dave


Received: by above.proper.com (8.9.3/8.9.3) id EAA20045 for ietf-pkix-bks; Fri, 25 May 2001 04:00:05 -0700 (PDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA20024 for <[e-mail]>; Fri, 25 May 2001 03:59:58 -0700 (PDT)
Received: from ireserver.Ireland.Sun.COM ([129.156.220.7]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA22612; Fri, 25 May 2001 04:59:55 -0600 (MDT)
Received: from sun.com (boston [129.156.220.153]) by ireserver.Ireland.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with ESMTP id LAA24950; Fri, 25 May 2001 11:59:55 +0100 (BST)
Message-ID: <[e-mail]>
Date: Fri, 25 May 2001 11:59:55 +0100
From: Sean Mullan <[e-mail]>
Organization: Sun Microsystems
X-Mailer: Mozilla 4.76C-CCK-MCD Netscape [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail], [e-mail]
Subject: Java CertPath API now available in J2SE 1.4 beta
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I would like to bring to your attention for a moment the
just-released J2SE (Java 2 Standard Edition) 1.4 Beta release:

  http://java.sun.com/j2se/1.4/index.html

This includes the current version of the CertPath API and
Reference Implementation. This is a proposed standard 
Java API for building and validating certification paths 
that is being developed using the Java Community Process. See 
http://java.sun.com/jcp/jsr/jsr_055_certp.html for the latest
status.

The CertPath API (developed as an extension of the 
java.security.cert package) includes classes for 
representing, building and validating certification paths. 
The API is very extensible. It allows you to plug in 
implementations of standard certification path algorithms,
types and certificate repositories using the Java Cryptography 
Architecture. It also allows you to extend the PKIX validation 
algorithm by implementing callback classes to handle private
extensions or an alternate revocation checking mechanism, for
example. 

The reference implementation of the APIs included in the beta
release includes an implementation of the PKIX certification path 
validation algorithm and also includes support for retrieving 
certificates and CRLs using LDAP (using the schema defined in RFC 
2587) or a simpler Collection.

Please see the beta release notes for a couple of known problems
that will be addressed in the next update. Also, see the
Programmer's Guide 
(http://java.sun.com/j2se/1.4/docs/guide/security/certpath/CertPathProgGuide.html)
for an overview and examples of using the API. We hope you find 
these APIs to be well designed and flexible. Please submit any feedback
to the "[e-mail]" or "[e-mail]"
aliases.

Thanks,
Sean


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id SAA18401 for ietf-pkix-bks; Thu, 24 May 2001 18:13:08 -0700 (PDT)
Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA18395 for <[e-mail]>; Thu, 24 May 2001 18:13:02 -0700 (PDT)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LQQYJXAA; Thu, 24 May 2001 18:06:40 -0700
From: "Carlin Covey" <[e-mail]>
To: "Housley, Russ" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: cA flag and CRL issuers
Date: Thu, 24 May 2001 18:12:42 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Thanks for answering my questions, Russ.  Socrates must have been better at
the method than I am.  ;>)  Let me try a more straightforward approach.

Some postings in this thread have stated that only CA's can issue CRL's.
'Tain't true.  As Russ says, Attribute Authorities can also issue CRL's.

Some postings in this thread have attached significance to the fact that
X.509 does not discuss whether the CA bit should be set when cRLSign is true
but keyCertSign is false.  I agree with you, Russ, that the discussion
should center on the level of flexibility and complexity that the PKIX
community want to embrace in its certificate and CRL profile, rather than
the nuances of text omissions in X.509.

I also agree that Sharon does a fine job in representing X.509's view.  I
understand that she is on vacation at the moment.

All that said, let me now second Santosh's proposal: "I vote for not
requiring the cA flag for CRL check and making appropriate changes to X.509
and to PKIX to make it clear and consistent."  - Santosh Chokhani, 24 May
2001

My rationale is this:  Attribute Authorities can issue CRL's.  Attribute
Authority certificates will not have the CA bit set.  So if we don't adopt
Santosh's proposal, the validation algorithm for CRL's will check for the CA
bit in the CRL issuer's certificate if the CRL issuer is a CA, but will not
check for the CA bit if the issuer is an Attribute Authority.  This doesn't
appear to add anything to the security, since having the CA bit set doesn't
mean that the CA is authoritative for status of the certificates on the CRL.
In both the CRL-issuer-is-CA case and the CRL-issuer-is-AA case the
validation algorithm must ensure that the CRL issuer is either the issuer of
the certificates on the CRL, or is a delegate of the issuer of the
certificates on the CRL.  So why bother checking the CA bit?

To streamline the algorithm a little further, I suggest that we ask X.509 to
allow the keyCertSign bit to be asserted in Attribute Authority
certificates, as well as CA certificates.  As far as I can see, that would
make the CRL validation algorithm identical for AA-issued and CA-issued
CRL's.

       "The bit keyCertSign is for use in CA-certificates only."
        - X.509 Ed. 4 v8, section 8.2.2.3 "Key usage extension"

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation




-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Housley, Russ
Sent: Thursday, May 24, 2001 1:04 PM
To: Carlin Covey
Cc: [e-mail]
Subject: RE: cA flag and CRL issuers


Carlin:

>1)  If only a CA can issue CRLs, and an Attribute Authority is not
>a CA, then who is going to revoke an AA's Attribute Certificates?

CAs issue public key certificates and they may issue CRLs associated with
those public key certificates.

AAs issue attribute certificates and they may issue CRLs associated with
those attribute certificates.

>2)  Perhaps there is no great significance to the fact that X.509
>does not mention the CA bit in connection with verifying signatures
>over CRLs.  It may simply reflect the earlier historical reality.
>Once upon a time only the certificate issuer's certificate could
>be used to verify the signature over the corresponding CRL.

With X.509v3 certificates, we get increased flexibility and complexity.  I
hope this thread is about the level of flexibility and complexity that we
want to embrace in the Internet profile of X.509v3.  In many cases, we have
reduced flexibility in order to achieve greater interoperability and
simplicity.

>3)  Why don't we just ask the good folks in the X.509 working group
>what the current text in X.509 section 8.4.2.1 "Basic constraints
extension"
>is intended to mean with respect to CA bit and CRL signing?

I think that Sharon has done a fine job in patiently representing the views
as the editor of X.509.  Editors often represent and write the view of the
overall group, even when they personally disagree with a particular
detail.  I applaud her efforts.

Russ



Received: by above.proper.com (8.9.3/8.9.3) id PAA06786 for ietf-pkix-bks; Thu, 24 May 2001 15:01:35 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA06782 for <[e-mail]>; Thu, 24 May 2001 15:01:30 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Thu, 24 May 2001 15:01:49 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Thu, 24 May 2001 15:01:48 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <HR26TD44>; Thu, 24 May 2001 14:59:11 -0700
Content-return: allowed
Date: Thu, 24 May 2001 14:59:02 -0700
From: Peter Williams <[e-mail]>
Subject: RE: cA flag and CRL issuers
To: "'Tony Bartoletti'" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

 
"And does an AA have ability to enforce this delegation (via key usage 
flags, etc) in parallel to the mechanisms afforded a PKC-CA?"



PMI AAs have a properly designed set of delegation techniques
to accomplish this and other uses of delegation that control
privileges; this set contrasts markedly with the proposed
kludges for PKI entities. 

The functions of AA-based delegation are properly modelled as 
privileges,  specified for us to use, and our implementable. They
do not rely upon misuing (or even require the
existance of) of PKI extension fields to enforce
the Housley "authority policy" [X.509], say, between an issuing
authority and a CRL issuer. 

X.509 certainly does not require that a CRL Issuer be issued a 
PKI cert by the CA with whom it cooperates in the matter of
communicating revocation notices, or require that the
authority that does issue indirect CRLs be in the
same certification/policy domain as the cert issuing authority.

Indeed, I dont know how anyone can read X.509 and claim
that it mandates or even describes a delegation
model between  CAs and CRL Issuers. It specifically
states that "authority policy" [X.509] deals with these
kind of matters, particularly when there are multiple
CRL Issuers for a given CA.  The PKI work in X.509 simply does not 
require nor does it describe the use of delegation as 
an enforcement technique, and it does not mandate/hint/intend
any particular authority policy.

If PKIX authors want to mandate an authority policy (why? I 
understand why MISSI users would want a uniform policy, but why 
so constrain the Internet PKI?) then they should do it properly using the 
techniques provided. Use PMI delegation privileges, using the delegation 
model in 15.5, constraining the certificate policy oids in the CRL 
Issuers EE cert so relying parties can use conventional cert path processing

to enforce the CAs authority policy over the CRL Issuers. 

This way (15.5.2.3), bridge models, hierarhical
models and cross-certification models all still work; hierarchical
PKIs can still use CRL issuers in bridge models, etc, by using
policy mapping, path processing enforcement, etc.

Peter.



Received: by above.proper.com (8.9.3/8.9.3) id OAA05172 for ietf-pkix-bks; Thu, 24 May 2001 14:20:22 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id OAA05168 for <[e-mail]>; Thu, 24 May 2001 14:20:16 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 24 May 2001 21:19:43 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id RAA07884 for <[e-mail]>; Thu, 24 May 2001 17:20:18 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <LR8TAA4C>; Thu, 24 May 2001 17:20:18 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.65]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TAAT0; Thu, 24 May 2001 17:20:15 -0400
From: "Housley, Russ" <[e-mail]>
To: Carlin Covey <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 24 May 2001 16:03:50 -0400
Subject: RE: cA flag and CRL issuers
In-Reply-To: <[e-mail]>
References: <002e01c0e261$d5c5f7c0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Carlin:

>1)  If only a CA can issue CRLs, and an Attribute Authority is not
>a CA, then who is going to revoke an AA's Attribute Certificates?

CAs issue public key certificates and they may issue CRLs associated with 
those public key certificates.

AAs issue attribute certificates and they may issue CRLs associated with 
those attribute certificates.

>2)  Perhaps there is no great significance to the fact that X.509
>does not mention the CA bit in connection with verifying signatures
>over CRLs.  It may simply reflect the earlier historical reality.
>Once upon a time only the certificate issuer's certificate could
>be used to verify the signature over the corresponding CRL.

With X.509v3 certificates, we get increased flexibility and complexity.  I 
hope this thread is about the level of flexibility and complexity that we 
want to embrace in the Internet profile of X.509v3.  In many cases, we have 
reduced flexibility in order to achieve greater interoperability and 
simplicity.

>3)  Why don't we just ask the good folks in the X.509 working group
>what the current text in X.509 section 8.4.2.1 "Basic constraints extension"
>is intended to mean with respect to CA bit and CRL signing?

I think that Sharon has done a fine job in patiently representing the views 
as the editor of X.509.  Editors often represent and write the view of the 
overall group, even when they personally disagree with a particular 
detail.  I applaud her efforts.

Russ


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA04485 for ietf-pkix-bks; Thu, 24 May 2001 14:11:22 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA04458 for <[e-mail]>; Thu, 24 May 2001 14:11:11 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <LRSZVKDM>; Thu, 24 May 2001 17:10:43 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Stephen Kent <[e-mail]>
Cc: [e-mail]
Subject: RE: cA Flag -- cRLSign
Date: Thu, 24 May 2001 17:01:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0E494.A80E5C20"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0E494.A80E5C20
Content-Type: text/plain;
	charset="iso-8859-1"

Steve:
 
I vote for not requiring the cA flag for CRL check and making appropriate
changes to X.509 and to PKIX to make it clear and consistent
 
-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Tuesday, May 22, 2001 8:13 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: Re: cA Flag -- cRLSign


At 2:55 PM -0400 5/18/01, Santosh Chokhani wrote:

Steve:


I have a compromise proposal in this area.  As Russ Housley says: In the
interest of interoperability, the generator should be strict and processor
should be forgiving (assuming no security) is compromised.


I would say let us do the following:


1.  A PKIX compliant CA must assert basicConstraints with cA set to TRUE if
cRLSign bit is set, and


2.  A PKIX compliant relying party client must check cRLSign flag in the
keyUsage extension, if keyUsage extension is present, when using the public
key of the subject to verify a signature on the CRL.  However, if the
keyUsage extension is absent, basicConstraints must be present with cA =
TRUE


I think it confusing for a standard to encourage asymmetric behavior for CAs
vs. clients. It also removes a big part of the motivation for CAs to set the
flag according to the standard.

As I said earlier, if there is consensus to remove the need for cA to be
asserted in certs associated with CRL validation, then we can make that
explicit in the standard, but we just have to "buy in" to making the other
changes to clarify this, and to name a role for entities who sign CRLs but
who are not CAs.

Steve

------_=_NextPart_001_01C0E494.A80E5C20
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>Re: cA Flag -- cRLSign</TITLE>

<STYLE type=text/css>BLOCKQUOTE {
	MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px
}
DL {
	MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px
}
UL {
	MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px
}
OL {
	MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px
}
LI {
	MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px
}
</STYLE>

<META content="MSHTML 5.00.2014.210" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=732390921-24052001>Steve:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=732390921-24052001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=732390921-24052001>I vote 
for not requiring the cA flag for CRL check and making appropriate changes to 
X.509 and to PKIX to make it clear and consistent</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV class=OutlookMessageHeader><FONT face="Times New Roman" 
size=2>-----Original Message-----<BR><B>From:</B> Stephen Kent 
[mailto:[e-mail]]<BR><B>Sent:</B> Tuesday, May 22, 2001 8:13 
AM<BR><B>To:</B> Santosh Chokhani<BR><B>Cc:</B> 
[e-mail]<BR><B>Subject:</B> Re: cA Flag -- cRLSign<BR><BR></FONT></DIV>
<DIV>At 2:55 PM -0400 5/18/01, Santosh Chokhani wrote:</DIV>
<BLOCKQUOTE cite type="cite"><FONT face=Arial 
size=-1>Steve:</FONT><BR></BLOCKQUOTE>
<BLOCKQUOTE cite type="cite"><FONT face=Arial size=-1>I have a compromise 
  proposal in this area.&nbsp; As Russ Housley says: In the interest of 
  interoperability, the generator should be strict and processor should be 
  forgiving (assuming no security) is compromised.</FONT><BR></BLOCKQUOTE>
<BLOCKQUOTE cite type="cite"><FONT face=Arial size=-1>I would say let us do 
  the following:</FONT><BR></BLOCKQUOTE>
<BLOCKQUOTE cite type="cite"><FONT face=Arial size=-1>1.&nbsp; A PKIX 
  compliant CA must assert basicConstraints with cA set to TRUE if cRLSign bit 
  is set, and</FONT><BR></BLOCKQUOTE>
<BLOCKQUOTE cite type="cite"><FONT face=Arial size=-1>2.&nbsp; A PKIX 
  compliant relying party client must check cRLSign flag in the keyUsage 
  extension, if keyUsage extension is present, when using the public key of the 
  subject to verify a signature on the CRL.&nbsp; However, if the keyUsage 
  extension is absent, basicConstraints must be present with cA = 
TRUE</FONT></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>I think it confusing for a standard to encourage asymmetric behavior for 
CAs vs. clients. It also removes a big part of the motivation for CAs to set the 
flag according to the standard.</DIV>
<DIV><BR></DIV>
<DIV>As I said earlier, if there is consensus to remove the need for cA to be 
asserted in certs associated with CRL validation, then we can make that explicit 
in the standard, but we just have to "buy in" to making the other changes to 
clarify this, and to name a role for entities who sign CRLs but who are not 
CAs.</DIV>
<DIV><BR></DIV>
<DIV>Steve</DIV></BODY></HTML>

------_=_NextPart_001_01C0E494.A80E5C20--


Received: by above.proper.com (8.9.3/8.9.3) id NAA01618 for ietf-pkix-bks; Thu, 24 May 2001 13:39:02 -0700 (PDT)
Received: from smtp-1.llnl.gov (smtp-1.llnl.gov [128.115.250.81]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA01610 for <[e-mail]>; Thu, 24 May 2001 13:38:57 -0700 (PDT)
Received: from poptop.llnl.gov (localhost [127.0.0.1]) by smtp-1.llnl.gov (8.9.3/8.9.3/LLNL-gateway-1.0) with ESMTP id NAA05306 for <[e-mail]>; Thu, 24 May 2001 13:38:29 -0700 (PDT)
Received: from catalyst.llnl.gov (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id NAA19422 for <[e-mail]>; Thu, 24 May 2001 13:38:29 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 24 May 2001 13:44:33 -0700
To: [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: RE: cA flag and CRL issuers
In-Reply-To: <[e-mail]. com>
References: <899128A30EEDD1118FC900A0C9C74A34BA97F0@BIGBIRD>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

At 03:53 PM 5/24/01 -0400, Housley, Russ wrote:
>It has never been my intent to add any new entities to the Internet PKI 
>model.  The CA is responsible for maintaining revocation status 
>information about the certificates that it issues.  The indirect CRL 
>mechanism allows the CA to delegate the issuing of CRLs that cover all or 
>some portion of those certificates to another CA.  We still call it a CA 
>even if it never issues any certificates, only CRLs.
>
>Russ

Since the designation "CA" is specifically a PKC-CA (correct me otherwise,) 
your statement does not address AAs.

In parallel logic, would it be correct to say when an Attribute Authority 
delegates the issue of "Attribute CRLs" to another party, that other party 
is thus to be called an AA, even though it may not issue attribute 
certificates?

And does an AA have ability to enforce this delegation (via key usage 
flags, etc) in parallel to the mechanisms afforded a PKC-CA?

___tony___


Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900






Received: by above.proper.com (8.9.3/8.9.3) id MAA28849 for ietf-pkix-bks; Thu, 24 May 2001 12:54:51 -0700 (PDT)
Received: from gonzo.aus.rsa.com (mail.rsasecurity.com.au [203.46.112.10]) by above.proper.com (8.9.3/8.9.3) with SMTP id MAA28837 for <[e-mail]>; Thu, 24 May 2001 12:54:43 -0700 (PDT)
Received: from checkpoint.local.aus.rsa.com by gonzo.aus.rsa.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 24 May 2001 19:51:12 UT
Received: (private information removed)
Received: (private information removed)
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.109]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8S00C3; Thu, 24 May 2001 15:54:01 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 24 May 2001 15:53:57 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: RE: cA flag and CRL issuers
In-Reply-To: <899128A30EEDD1118FC900A0C9C74A34BA97F0@BIGBIRD>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

It has never been my intent to add any new entities to the Internet PKI 
model.  The CA is responsible for maintaining revocation status information 
about the certificates that it issues.  The indirect CRL mechanism allows 
the CA to delegate the issuing of CRLs that cover all or some portion of 
those certificates to another CA.  We still call it a CA even if it never 
issues any certificates, only CRLs.

Russ


Received: by above.proper.com (8.9.3/8.9.3) id KAA24444 for ietf-pkix-bks; Thu, 24 May 2001 10:51:40 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA24426 for <[e-mail]>; Thu, 24 May 2001 10:51:27 -0700 (PDT)
Received: from [128.33.4.247] (bbnt-dhcp004-247.bbn.com [128.33.4.247]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA23238; Thu, 24 May 2001 13:51:23 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <p05010401b73008647c40@[128.33.4.247]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>		 <[e-mail]>		 <[e-mail]>		 <[e-mail]>		 <000801c0c6a7$60e9d870$[e-mail]>		 <[e-mail]>		 <[e-mail]> <[e-mail]>		 <[e-mail]>		 <[e-mail]>		 <[e-mail]>		 <[e-mail]>	 <p05010406b72760acb0bf@[128.33.238.68]>	 <[e-mail]> <p05010403b7288eeda3d6@[128.33.238.22]> <[e-mail]>
Date: Tue, 22 May 2001 08:25:36 -0400
To: "David P. Kemp" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: cA flag and CRL issuers (was Re: Last Call:     draft-ietf-pkix-new-part1-06.txt comments)
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Dave,

>Hi Steve,
>
>I certainly agree that the intent of X.509, from v1 to the present, was
>that a CA entity is the ultimate and sole authority for revoking the
>certificates that it issues.
>
>However, Tim has proposed changing the text of PKIX to require the cA
>flag to be set in every certificate whose subject is a CA entity.
>Such a change is unnecessary.
>
>The question is:
>
>  * When a CA entity uses one public key to sign certificates
>  * and a different public key to sign CRLs, must the cA flag be set
>  * in the certificate containing the public key used to sign CRLs?
>
>I say no.  David Cooper, Santosh, Sharon, Denis, Tom, and others
>can answer this question explicitly for themselves; I will refrain
>from interpreting their words.
>

This is a big part of the question at hand, but not the whole 
question. If we do agree that the cA flag need not be set in a cert 
used by a CA who signs a CRL, then what about a non-CA entity that 
signs a CRL? What do we call it?  Also, it might be clear that the 
entity signing the CRL was a CA (w/o the cA flag set), because the 
entity has the same name as the CA who signed the certs in question, 
i.e., we're dealing with a self-issued cert. But, what if the name is 
different? In that latter case, we need to make an explicit statement 
about the role of the entity in question, starting with naming that 
role.

I agree that a very broad interpretation of the requirement to set 
the cA flag runs into problems, but so do the key usage bits in some 
contexts. For example, if a CA signs a cert request message in CMP, 
requesting a cross-cert from another CA, isn't this use of the CA 
private key for POP a contradiction of the key usage bits in the 
self-signed cert issued by the CA to itself?

Steve


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id KAA24441 for ietf-pkix-bks; Thu, 24 May 2001 10:51:37 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA24429 for <[e-mail]>; Thu, 24 May 2001 10:51:30 -0700 (PDT)
Received: from [128.33.4.247] (bbnt-dhcp004-247.bbn.com [128.33.4.247]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA23233; Thu, 24 May 2001 13:51:22 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <p05010400b7300788484d@[128.33.4.247]>
In-Reply-To:  <[e-mail]>
References: <[e-mail]>
Date: Tue, 22 May 2001 08:12:54 -0400
To: Santosh Chokhani <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: cA Flag -- cRLSign
Cc: [e-mail]
Content-Type: multipart/alternative; boundary="============_-1221395796==_ma============"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--============_-1221395796==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 2:55 PM -0400 5/18/01, Santosh Chokhani wrote:
>Steve:
>
>I have a compromise proposal in this area.  As Russ Housley says: In 
>the interest of interoperability, the generator should be strict and 
>processor should be forgiving (assuming no security) is compromised.
>
>I would say let us do the following:
>
>1.  A PKIX compliant CA must assert basicConstraints with cA set to 
>TRUE if cRLSign bit is set, and
>
>2.  A PKIX compliant relying party client must check cRLSign flag in 
>the keyUsage extension, if keyUsage extension is present, when using 
>the public key of the subject to verify a signature on the CRL. 
>However, if the keyUsage extension is absent, basicConstraints must 
>be present with cA = TRUE

I think it confusing for a standard to encourage asymmetric behavior 
for CAs vs. clients. It also removes a big part of the motivation for 
CAs to set the flag according to the standard.

As I said earlier, if there is consensus to remove the need for cA to 
be asserted in certs associated with CRL validation, then we can make 
that explicit in the standard, but we just have to "buy in" to making 
the other changes to clarify this, and to name a role for entities 
who sign CRLs but who are not CAs.

Steve
--============_-1221395796==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { margin-top: 0 ; margin-bottom: 0 }
 --></style><title>Re: cA Flag -- cRLSign</title></head><body>
<div>At 2:55 PM -0400 5/18/01, Santosh Chokhani wrote:</div>
<blockquote type="cite" cite><font face="Arial"
size="-1">Steve:</font><br>
</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">I have a
compromise proposal in this area.&nbsp; As Russ Housley says: In the
interest of interoperability, the generator should be strict and
processor should be forgiving (assuming no security) is
compromised.</font><br>
</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">I would say
let us do the following:</font><br>
</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">1.&nbsp; A
PKIX compliant CA must assert basicConstraints with cA set to TRUE if
cRLSign bit is set, and</font><br>
</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">2.&nbsp; A
PKIX compliant relying party client must check cRLSign flag in the
keyUsage extension, if keyUsage extension is present, when using the
public key of the subject to verify a signature on the CRL.&nbsp;
However, if the keyUsage extension is absent, basicConstraints must be
present with cA = TRUE</font></blockquote>
<div><br></div>
<div>I think it confusing for a standard to encourage asymmetric
behavior for CAs vs. clients. It also removes a big part of the
motivation for CAs to set the flag according to the standard.</div>
<div><br></div>
<div>As I said earlier, if there is consensus to remove the need for
cA to be asserted in certs associated with CRL validation, then we can
make that explicit in the standard, but we just have to &quot;buy in&quot;
to making the other changes to clarify this, and to name a role for
entities who sign CRLs but who are not CAs.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1221395796==_ma============--


Received: by above.proper.com (8.9.3/8.9.3) id EAA24223 for ietf-pkix-bks; Thu, 24 May 2001 04:02:10 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA24216 for <[e-mail]>; Thu, 24 May 2001 04:02:05 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10400; Thu, 24 May 2001 07:01:48 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-cmp-transport-protocols-04.txt
Date: Thu, 24 May 2001 07:01:48 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Transport Protocols for CMP
	Author(s)	: A. Kapoor, R. Tschalar
	Filename	: draft-ietf-pkix-cmp-transport-protocols-04.txt
	Pages		: 
	Date		: 23-May-01
	
This document describes how to layer Certificate Management
Protocols [CMP] over various transport protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmp-transport-protocols-04.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-cmp-transport-protocols-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-cmp-transport-protocols-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-cmp-transport-protocols-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-cmp-transport-protocols-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.9.3/8.9.3) id LAA09790 for ietf-pkix-bks; Wed, 23 May 2001 11:47:37 -0700 (PDT)
Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA09785 for <[e-mail]>; Wed, 23 May 2001 11:47:31 -0700 (PDT)
Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.8.8/8.8.8) with ESMTP id OAA18853; Wed, 23 May 2001 14:47:31 -0400 (EDT)
Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38888) id <[e-mail]>; Wed, 23 May 2001 14:44:21 -0400 (EDT)
Received: from emss03i00.ems.lmco.com ([141.240.31.211]) by lmco.com (PMDF V5.2-32 #38888) with ESMTP id <[e-mail]>; Wed, 23 May 2001 14:44:17 -0400 (EDT)
Received: by emss03i00.orl.lmco.com with Internet Mail Service (5.5.2653.19)	id <L1PFLMRQ>; Wed, 23 May 2001 14:44:22 -0400
Content-return: allowed
Date: Wed, 23 May 2001 14:44:19 -0400
From: "Slone, Skip" <[e-mail]>
Subject: RE: X.509 Certificate schema in LDAPv3
To: "'Kurt D. Zeilenga'" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
Content-transfer-encoding: 7BIT
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Kurt,

Could you please clarify what you mean by "As much of this schema is broken
... " and "... the X.509 certificate schema is known to be broken in LDAPv3
... ?"

In my capacity as the US Defect Editor for X.500, no one has EVER brought
any broken schema elements in the 3rd edition to my attention.

  -- Skip Slone

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[e-mail]] 
Sent: Wednesday, May 23, 2001 9:07 AM
To: [e-mail]
Subject: X.509 Certificate schema in LDAPv3


LDAPbis is currently revising the LDAPv3 for publication
as a Draft Standard.  One of the significant issues in
which we are addressing is LDAP's relationship to X.500.
The consensus of the WG has determined it best that LDAPv3
only reference the one edition of X.500 and not both the
2nd and 3rd editions as the Proposed Standard did.  The consensus of the
LDAPbis WG is to only reference the 2nd edition as this is what the protocol
itself depends on, and to drop the few schema elements from the "core"
document which are dependent on the 3rd edition.  As much of this schema is
broken anyways, this seems like the most reasonable solution.

The most significant impact of this change is that the
X.509 certificate schema would be dropped from the "core" documents and,
hopefully, picked up in a separate document. I note that the X.509
certificate schema is known to be broken in LDAPv3, in particular the
attributes are missing key matching rules.

I understand that PKIX is working on an PKI profile for
LDAPv3 which includes additional X.509 certificate schema.
I would suggest that this work be expanded to include
new specification of the RFC 2252/2256 certificate schema elements.

-- Kurt


Received: by above.proper.com (8.9.3/8.9.3) id JAA05279 for ietf-pkix-bks; Wed, 23 May 2001 09:58:25 -0700 (PDT)
Received: from mta01-svc.ntlworld.com (mta01-svc.ntlworld.com [62.253.162.41]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA05260 for <[e-mail]>; Wed, 23 May 2001 09:58:18 -0700 (PDT)
Received: from salford.ac.uk ([62.252.104.40]) by mta01-svc.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with ESMTP id <[e-mail]>; Wed, 23 May 2001 17:58:19 +0100
Message-ID: <[e-mail]>
Date: Wed, 23 May 2001 18:03:49 +0100
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Kurt D. Zeilenga" <[e-mail]>
CC: [e-mail]
Subject: Re: X.509 Certificate schema in LDAPv3
References: <5.1.0.14.0.20010523075142.00ad21f0@127.0.0.1>
Content-Type: multipart/mixed; boundary="------------B613F78E952BCF903C22DD10"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This is a multi-part message in MIME format.
--------------B613F78E952BCF903C22DD10
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Kurt

I am happy to include the schema definitions in the PKIX LDAP Schema
document.

David

"Kurt D. Zeilenga" wrote:
> 
> LDAPbis is currently revising the LDAPv3 for publication
> as a Draft Standard.  One of the significant issues in
> which we are addressing is LDAP's relationship to X.500.
> The consensus of the WG has determined it best that LDAPv3
> only reference the one edition of X.500 and not both the
> 2nd and 3rd editions as the Proposed Standard did.  The
> consensus of the LDAPbis WG is to only reference the 2nd
> edition as this is what the protocol itself depends on,
> and to drop the few schema elements from the "core" document
> which are dependent on the 3rd edition.  As much of this
> schema is broken anyways, this seems like the most reasonable
> solution.
> 
> The most significant impact of this change is that the
> X.509 certificate schema would be dropped from the "core"
> documents and, hopefully, picked up in a separate document.
> I note that the X.509 certificate schema is known to be
> broken in LDAPv3, in particular the attributes are missing
> key matching rules.
> 
> I understand that PKIX is working on an PKI profile for
> LDAPv3 which includes additional X.509 certificate schema.
> I would suggest that this work be expanded to include
> new specification of the RFC 2252/2256 certificate schema
> elements.
> 
> -- Kurt

-- 
*****************************************************************

David Chadwick, BSc PhD
Post: IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
*NEW* Mobile: [phone] *NEW*
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------B613F78E952BCF903C22DD10
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:[e-mail]
x-mozilla-cpt:;11160
fn:David Chadwick
end:vcard

--------------B613F78E952BCF903C22DD10--



Received: by above.proper.com (8.9.3/8.9.3) id GAA17691 for ietf-pkix-bks; Wed, 23 May 2001 06:10:14 -0700 (PDT)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA17674 for <[e-mail]>; Wed, 23 May 2001 06:10:02 -0700 (PDT)
Received: from gypsy.OpenLDAP.org ([e-mail] [198.144.206.49]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id f4ND7Sp58338 for <[e-mail]>; Wed, 23 May 2001 13:07:28 GMT (envelope-from [e-mail])
Message-Id: <5.1.0.14.0.20010523075142.00ad21f0@127.0.0.1>
X-Sender: guru@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 23 May 2001 08:06:54 -0500
To: [e-mail]
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: X.509 Certificate schema in LDAPv3
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

LDAPbis is currently revising the LDAPv3 for publication
as a Draft Standard.  One of the significant issues in
which we are addressing is LDAP's relationship to X.500.
The consensus of the WG has determined it best that LDAPv3
only reference the one edition of X.500 and not both the
2nd and 3rd editions as the Proposed Standard did.  The
consensus of the LDAPbis WG is to only reference the 2nd
edition as this is what the protocol itself depends on,
and to drop the few schema elements from the "core" document
which are dependent on the 3rd edition.  As much of this
schema is broken anyways, this seems like the most reasonable
solution.

The most significant impact of this change is that the
X.509 certificate schema would be dropped from the "core"
documents and, hopefully, picked up in a separate document.
I note that the X.509 certificate schema is known to be
broken in LDAPv3, in particular the attributes are missing
key matching rules.

I understand that PKIX is working on an PKI profile for
LDAPv3 which includes additional X.509 certificate schema.
I would suggest that this work be expanded to include
new specification of the RFC 2252/2256 certificate schema
elements.

-- Kurt



Received: by above.proper.com (8.9.3/8.9.3) id FAA16729 for ietf-pkix-bks; Wed, 23 May 2001 05:54:59 -0700 (PDT)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA16724 for <[e-mail]>; Wed, 23 May 2001 05:54:53 -0700 (PDT)
Received: from gypsy.OpenLDAP.org ([e-mail] [198.144.206.49]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id f4NCqDp58268 for <[e-mail]>; Wed, 23 May 2001 12:52:14 GMT (envelope-from [e-mail])
Message-Id: <5.1.0.14.0.20010523075135.00adf6f0@127.0.0.1>
X-Sender: guru@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 23 May 2001 07:51:40 -0500
To: [e-mail]
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: LDAP DN format and short names
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

There are numerous differences between the LDAPv2 and LDAPv3
DN specification.  I discuss some of these differences in the
draft-zeilenga-ldapbis-vd-00.txt.  Anyways, these differences
are quite moot as LDAPv2 should soon be moved to historical
status (once LDAPv3 progresses to Draft Standard status).

RFC 2253 was fairly clear as how to generate a string
representation of an X.500(93) distinguished name.   The most
glaring problem was rather unclear as to which table of short
names it was referring to in Section 2.3.  The RFC 2253 editor
stated that the 2.3 table is the table and not an example of
table.  This makes sense given the objectives of the I-D to
produce an unambiguous string representation.  However, as
many implementations used other tables, LDAPbis determined
it was inappropriate to mandate use of this table and arrived,
after extended discussion but strong consensus, at the text
you now find in draft-ietf-ldapbis-dn-05.txt.

I note that this I-D has just completed an LDAPbis WG Last Call.
We have a couple of clarifying comments to make and an
implementation report to complete, but it's basically ready to
be progressed.  If you have issues which have not been addressed
(see archives), you are encouraged to raise them now on the
LDAPbis mailing list.

Kurt



Received: by above.proper.com (8.9.3/8.9.3) id DAA06395 for ietf-pkix-bks; Wed, 23 May 2001 03:49:49 -0700 (PDT)
Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by above.proper.com (8.9.3/8.9.3) with SMTP id DAA06378 for <[e-mail]>; Wed, 23 May 2001 03:49:42 -0700 (PDT)
Received: (qmail 3124 invoked from network); 23 May 2001 10:49:36 -0000
Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by 172.16.1.1 with SMTP; 23 May 2001 10:49:36 -0000
Received: (qmail 14054 invoked from network); 23 May 2001 10:49:35 -0000
Received: from unknown (HELO localhost.localdomain) (172.16.13.115) by spirit.dynas.se with SMTP; 23 May 2001 10:49:35 -0000
To: [e-mail]
Subject: pkix operational protocols: dns
From: Simon Josefsson <[e-mail]>
Date: 23 May 2001 12:49:31 +0200
Message-ID: <[e-mail]>
Lines: 20
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.0.102
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Folks,

I'd like to point your attention to

http://www.ietf.org/internet-drafts/draft-josefsson-pkix-dns-00.txt

for a suggestion on how DNS could be used within PKIX to locate,
retrieve and publish certificates.  As always, feedback appreciated.

/Simon

Abstract

    The protocol conventions described in this document satisfy some of
    the operational requirements of the Internet Public Key
    Infrastructure (PKI).  This document specifies the conventions for
    using the Domain Name System (DNS) to obtain certificates and
    certificate revocation lists (CRLs) from PKI repositories.
    Additional mechanisms addressing PKIX operational requirements are
    specified in separate documents.



Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA07146 for ietf-pkix-bks; Tue, 22 May 2001 14:30:26 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA07122 for <[e-mail]>; Tue, 22 May 2001 14:30:17 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id RAA00921 for <[e-mail]>; Tue, 22 May 2001 17:30:03 -0400 (EDT)
Received: from reject.missi.ncsc.mil (reject.missi.ncsc.mil [144.51.60.17]) by stingray.missi.ncsc.mil with SMTP id RAA00917 for <[e-mail]>; Tue, 22 May 2001 17:30:03 -0400 (EDT)
Received: from 144.51.60.215 by reject.missi.ncsc.mil (InterScan E-Mail VirusWall NT); Tue, 22 May 2001 17:32:49 -0400 (Eastern Daylight Time)
Received: from missi.ncsc.mil (ara.missi.ncsc.mil [144.51.55.128]) by amx.missi.ncsc.mil with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JSFMCMAM; Tue, 22 May 2001 17:33:19 -0400
Message-ID: <[e-mail]>
Date: Tue, 22 May 2001 17:26:53 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: cA flag and CRL issuers (was Re: Last Call:    draft-ietf-pkix-new-part1-06.txt comments)
References: <[e-mail]> <002e01c0e261$d5c5f7c0$[e-mail]> <[e-mail]> <007701c0e2e6$d782c180$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

> AWA:  Let's accept your premise - that not only CA's can sign CRLs.  I can
> actually live with this, if it reflects the wishes of this group.  However,
> if that's the consensus, then offspring-of-2459 is going to require heavy
> editing.  I took a quick 10-minute scan through
> <draft-ietf-pkix-new-part1-06.txt>, and identified the following areas which
> must be changed, at a minimum:  ...


Al,

Like David Cooper, I don't particularly care what you call entities that
can sign CRLs - it could be "CA or AA", "Authority", or "Revocation
Authority".  Cleaning up the text is a good idea, but it's not what
I'm focused on.

The MUST requirements for generating and receiving applications are what
I care about.  Those requirements should be as minimal as possible
without adversely affecting security.  In particular, a new requirement
that links the cA flag in basic constraints with the type of certificate
contained in the CRL is simultaneously baroque and incomplete.



> My personal bottom line is this:  the document says explicitly in numerous
> places that only CA's issue CRLs.  Now, if we're going to change that, we're
> going to change the entire document so that it consistently covers those
> entities that can sign CRLs.  I really do not want to be a party to some
> semantic game (it took me 10 tries to find a phrase as inoffensive as
> "semantic game" to use here :-) where we leave all the ancillary text the
> way it is, and then say but no, really, non-CAs can sign CRLs, too.
> 
> And I would object also to a game where we declared a "CA" to be anybody who
> had a cert with keyUsage = cRLSign, regardless of the value of
> basicConstraints. (i.e., just because it doesn't have the CA bit set doesn't
> mean it's not a CA.) That just strikes me as a lazy way of getting around a
> problem, not a fix to the problem.

Fine.  Your problem is getting the document to define "what do we call
the entities that sign CRLs", and I agree that there is a painful way
and a lazy way to fix it. I agree that the lazy way won't work, because
an AA must be able to revoke ACs without being called a "CA".  I don't
particularly object to leaving the ancilliary text the way it is, and then
say once "The authority to revoke any certificate rests with the issuer
of that certificate. CRLs can be signed by CAs, AAs, or their authorized
agents."

My problem is an application has a certificate X.  X could be anything;
it could belong to an EE, a CA, or an AA, and it could be a public key
certificate or an attribute certificate.  The application also has a CRL
signed by public key Y, and a certificate for public key Y with cRLSign
asserted. The application needs to decide if the CRL is valid and applies
to certificate X.

My position is that the application does not need to even look at the basic
constraints extension in the certificate for Y to determine whether the
CRL applies to certificate X.   


> > The answer is (c):  Only the issuer of a certificate (CA or AA) is
> responsible
> > for signing the CRLs that apply to that certificate.  That responsibility
> > can be exercised directly by using the same public key to sign the cert
> > and CRL, or indirectly by issuing a cRLSign certificate for the public
> > key used to sign the CRL.
> 
> AWA:  And how exactly do you identify that separate certificate which is
> authorized to sign CRLs?
> 
> > The cA bit tells you nothing about who is entitled to revoke a
> > certificate: VeriSign can't revoke Cybertrust certificates
> > even though it is a CA.
> 
> AWA:  True, but irrelevant.

It is relevant because it demonstrates that the cA flag in basic
constraints is not sufficient to determine whether a CRL Z applies to
certificate X.

I don't need to specify the exact algorithm for identifying the CRL Z
(signed by Y) which applies to certificate X, or for identifying the
certificate for public key Y.  All I need to do is demonstrate that
the cA flag in the certificate for public key Y is irrelevant to that
algorithm.  The entity that signed the certificate for public key Y
has set the cRLSign bit.  There is no reason to either require or
prohibit it from also setting the cA flag in that certificate, and
there is no reason for an application to look at the cA flag in that
certificate when applying the CRL.


> >Using the cA bit in the rules for
> > CRL processing adds no value, it adds only needless confusion.
> 
> AWA:  Leaving the document the way it is does not solve the problem, 
> it only causes needless confusion!!!!

These two statements are both true, but they refer to different
problems.  They are somewhat synergistic in that if you don't try
to differentiate and name all the kinds of entities that can sign
CRLs, then you don't need to assign meanings to those names.

IMO, "Revocation Authority", defined as the subject of a certificate
which has cRLSign asserted, is the only name we need to clean up the
document.

Dave


Received: by above.proper.com (8.9.3/8.9.3) id MAA28574 for ietf-pkix-bks; Tue, 22 May 2001 12:12:56 -0700 (PDT)
Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA28566 for <[e-mail]>; Tue, 22 May 2001 12:12:50 -0700 (PDT)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KVA709SH; Tue, 22 May 2001 12:06:34 -0700
From: "Carlin Covey" <[e-mail]>
To: <[e-mail]>
Subject: RE: cA flag and CRL issuers (was Re: Last Call:  draft-ietf-pkix-new-part1-06.txt comments)
Date: Tue, 22 May 2001 12:12:59 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <002e01c0e261$d5c5f7c0$[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I've been following this thread with some interest, and I thought
I'd interject a few observations:

1)  If only a CA can issue CRLs, and an Attribute Authority is not
a CA, then who is going to revoke an AA's Attribute Certificates?

2)  Perhaps there is no great significance to the fact that X.509
does not mention the CA bit in connection with verifying signatures
over CRLs.  It may simply reflect the earlier historical reality.
Once upon a time only the certificate issuer's certificate could
be used to verify the signature over the corresponding CRL.

3)  Why don't we just ask the good folks in the X.509 working group
what the current text in X.509 section 8.4.2.1 "Basic constraints extension"
is intended to mean with respect to CA bit and CRL signing?

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation



Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id KAA25582 for ietf-pkix-bks; Tue, 22 May 2001 10:41:17 -0700 (PDT)
Received: from femail14.sdc1.sfba.home.com (femail14.sdc1.sfba.home.com [24.0.95.141]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA25574 for <[e-mail]>; Tue, 22 May 2001 10:41:11 -0700 (PDT)
Received: from cc787228a ([24.180.131.6]) by femail14.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010522174113.EBXF12893.femail14.sdc1.sfba.home.com@cc787228a>; Tue, 22 May 2001 10:41:13 -0700
Message-ID: <007701c0e2e6$d782c180$[e-mail]>
From: "Al Arsenault" <[e-mail]>
To: "David P. Kemp" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <002e01c0e261$d5c5f7c0$[e-mail]> <[e-mail]>
Subject: Re: cA flag and CRL issuers (was Re: Last Call:   draft-ietf-pkix-new-part1-06.txt comments)
Date: Tue, 22 May 2001 13:44:24 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Dave,


----- Original Message -----
From: "David P. Kemp" <[e-mail]>
To: <[e-mail]>
Sent: Tuesday, May 22, 2001 9:35 AM
Subject: Re: cA flag and CRL issuers (was Re: Last Call:
draft-ietf-pkix-new-part1-06.txt comments)


> Al,
>
> The problem with (a) is that *not* only CAs can sign CRLs.  The discussion
> has lasted so long because of a proposal to expand the description of
> the keyUsage extension from one sentence to six.
> Tim proposed a rule whereby cRLSign could be used to verify CRLs
containing
> PK certificates ONLY if cA is true, and cRLSign could be used to verify
> CRLs containing Attribute Certificates ONLY if cA is false.
>

AWA:  Let's accept your premise - that not only CA's can sign CRLs.  I can
actually live with this, if it reflects the wishes of this group.  However,
if that's the consensus, then offspring-of-2459 is going to require heavy
editing.  I took a quick 10-minute scan through
<draft-ietf-pkix-new-part1-06.txt>, and identified the following areas which
must be changed, at a minimum:

    - Section 3.3 - revocation - which says CA's issue CRLs.  It will have
to describe other entities that can sign CRLs.

       Section 4.2.1.3, p. 30:  Obviously, the section on the keyUsage
extension will have to be cleaned up.

       Basically, all of Section 5 will have to be rewritten.  It currently
imposes requirements only on CA's who issue CRLs.  There are no requirements
imposed on other, non-CA entities who sign CRLs.  For example, the intro to
Section 5; the second paragraph of Section 5.1.1.3., etc.

My personal bottom line is this:  the document says explicitly in numerous
places that only CA's issue CRLs.  Now, if we're going to change that, we're
going to change the entire document so that it consistently covers those
entities that can sign CRLs.  I really do not want to be a party to some
semantic game (it took me 10 tries to find a phrase as inoffensive as
"semantic game" to use here :-) where we leave all the ancillary text the
way it is, and then say but no, really, non-CAs can sign CRLs, too.

And I would object also to a game where we declared a "CA" to be anybody who
had a cert with keyUsage = cRLSign, regardless of the value of
basicConstraints. (i.e., just because it doesn't have the CA bit set doesn't
mean it's not a CA.) That just strikes me as a lazy way of getting around a
problem, not a fix to the problem.

> There are two problems with this - 1) it is unnecessarily complex:
keyUsage
> and issuer name or CRLDP are sufficient to link the issuer of a
certificate
> with the CRL which can revoke it, and 2) it needlessly prohibits a CA from
> issuing attribute certificates.  (The AC profile currently does prohibit
> CAs from being AAs, but if we want that prohibition, it should be an
> explicit statement in the AC profile, not a side effect of processing
> rules for the keyUsage and basicConstraints extensions.)
>
> The answer is (c):  Only the issuer of a certificate (CA or AA) is
responsible
> for signing the CRLs that apply to that certificate.  That responsibility
> can be exercised directly by using the same public key to sign the cert
> and CRL, or indirectly by issuing a cRLSign certificate for the public
> key used to sign the CRL.
>

AWA:  And how exactly do you identify that separate certificate which is
authorized to sign CRLs?

> The cA bit tells you nothing about who is entitled to revoke a
> certificate: VeriSign can't revoke Cybertrust certificates
> even though it is a CA.

AWA:  True, but irrelevant.

>Using the cA bit in the rules for
> CRL processing adds no value, it adds only needless confusion.
>

AWA:  Leaving the document the way it is does not solve the problem, it only
causes needless confusion!!!!

            Al Arsenault
            Chief Security Architect
            Diversinet Corp.






Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id KAA23433 for ietf-pkix-bks; Tue, 22 May 2001 10:03:17 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA23425 for <[e-mail]>; Tue, 22 May 2001 10:03:11 -0700 (PDT)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id NAA01093 for <[e-mail]>; Tue, 22 May 2001 13:03:02 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Tue, 22 May 2001 13:01:53 -0400
To: [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: Re: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <002e01c0e261$d5c5f7c0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I really don't think the issue of whether a non-CA can issue a CRL is important. We all agree that it is permissible for an entity that does not issue certificates to issue CRLs . I personally don't care if such an entity is called a certification authority, a revocation authority, or a french fry.

However, if we do decide that only CAs can issue CRLs, then the definition of CA should be changed, since X.509 currently defines a CA as an entity that issues public key certificates. (X.509 similarly defines an authority as an entity that issues either public key or attribute certificates). If we decide that non-CAs can issue certificates, then it appears that some of the text needs to be cleaned up to make that clear.

What I consider to be far more important than the name we assign to a CRL issuing entity are the certificate generation and processing rules. Here I believe the standard is quite clear. X.509 states that:

         The cA component [of basicConstraints] indicates if the certified public key may be
         used to verify certificate signatures.

There is nothing in the description of the cA component that even suggests that this field indicates whether the certificate subject is a CA. Certainly, the subject must be a CA if cA is set to TRUE, since by definition an entity that signs public key certificates is a CA. However, it is possible for a CA to be the subject of a certificate in which the subject public key is not intended to be used to verify signatures on certificates. It could be that the subject public key is only to be used to verify signatures on S/MIME messages or CRLs. In such a case, the subject of the certificate would be a CA, but cA would be set to FALSE.

It may be useful to agree on a term for entities that issue CRLs but not certificates, if this would help to make the overview material in the standards more clear. However, there is no reason that the outcome of such a decision should have any effect on either the certificate generation or certificate processing rules. The value of the cA bit in basicConstraints is determined by keyUsage, not by the type of entity that the certificate subject is. As has already been stated several times, there are no security issues here. It is simply a matter of ensuring that the certificate generation and processing rules are clear and consistent.

Dave

At 09:35 AM 5/22/01 -0400, David P. Kemp wrote:
>Al,
>
>The problem with (a) is that *not* only CAs can sign CRLs.  The discussion
>has lasted so long because of a proposal to expand the description of
>the keyUsage extension from one sentence to six.
>Tim proposed a rule whereby cRLSign could be used to verify CRLs containing
>PK certificates ONLY if cA is true, and cRLSign could be used to verify
>CRLs containing Attribute Certificates ONLY if cA is false.
>
>There are two problems with this - 1) it is unnecessarily complex: keyUsage
>and issuer name or CRLDP are sufficient to link the issuer of a certificate
>with the CRL which can revoke it, and 2) it needlessly prohibits a CA from
>issuing attribute certificates.  (The AC profile currently does prohibit
>CAs from being AAs, but if we want that prohibition, it should be an
>explicit statement in the AC profile, not a side effect of processing
>rules for the keyUsage and basicConstraints extensions.)
>
>The answer is (c):  Only the issuer of a certificate (CA or AA) is responsible
>for signing the CRLs that apply to that certificate.  That responsibility
>can be exercised directly by using the same public key to sign the cert
>and CRL, or indirectly by issuing a cRLSign certificate for the public
>key used to sign the CRL.
>
>The cA bit tells you nothing about who is entitled to revoke a
>certificate: VeriSign can't revoke Cybertrust certificates
>even though it is a CA.  Using the cA bit in the rules for
>CRL processing adds no value, it adds only needless confusion.
>
>Dave
>
>
>
>
>Al Arsenault wrote:
> > 
> > Okay, I think that we've reached consensus that the text in the current
> > documents (X.509 and offspring-of-2459) is wrong.  It's inconsistent, as
> > cited by Dave Cooper below.
> > 
> > Now, what's the best way to fix it?
> > 
> > Do we:
> > 
> >     (a) decide that only CA's can sign CRLs; that CA's are determined by the
> > value of the basicConstraints extension; that CA's who sign CRLs but not
> > certificates need not have the keyCertSign bit set in KU, and that that
> > section 8.4.2.1 in X.509 and corresponding text in offspring-of-2459 needs
> > to be fixed?
> > 
> >     (b) decide that non-CA's of some stripe can sign CRLs, and fix all of
> > the text in X.509 and offspring-of-2459 that needs to be fixed?
> > 
> >     (c) something else?
> > 
> > Clearly, leaving the text in the documents as it stands now is unacceptable;
> > I think we all agree that it's wrong.
> > 
> > So, what will it be?
> > 
> > Personally, if we were voting, I'd vote for (a) above, but that's just my
> > preference and there's probably some hanging chads around here...
> > 
> >             Al Arsenault
> >             Chief Security Architect
> >             Diversinet Corp.




Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA11109 for ietf-pkix-bks; Tue, 22 May 2001 07:37:00 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA11093 for <[e-mail]>; Tue, 22 May 2001 07:36:54 -0700 (PDT)
Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 22 May 2001 08:36:19 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Tue, 22 May 2001 08:36:29 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: cA flag and CRL issuers (was Re: Last Call:  draft-ietf-pkix-new-part1-06.txt comments)
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=_53096F73.95F4040D"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_53096F73.95F4040D
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Al,

I've only been skimming the arguments on this topic, but I believe there =
is significant merit in allowing local control over CRLs, e.g., by the =
relying party's organization, who may be in a better position to know =
whether or not to TRUST a certificate, for all that implies, than the CA =
that originally issued it.  This local control option should not necessaril=
y force the CRL issuer to be a CA, and even if they were one, they would =
not necessarily have issued the certificate in question.

Obviously, allowing some organization other than the issuing CA to publish =
CRLs could raise some havoc if the trust relationships were not properly =
managed.  But I believe that that can be accomplished by proper management =
of the trusted root of that CRL issuer within the relying party software.

The same philosophy, of allowing local control of trust on behalf of the =
relying party's organization, would also apply to OCSP, of course.

So I would vote for option B.

Bob


Robert R. Jueneman
Security Architect

Novell, Inc -- the leading provider of Net services software



>>> "Al Arsenault" <[e-mail]> 05/21/01 07:52PM >>>
Okay, I think that we've reached consensus that the text in the current
documents (X.509 and offspring-of-2459) is wrong.  It's inconsistent, as
cited by Dave Cooper below.

Now, what's the best way to fix it?

Do we:

    (a) decide that only CA's can sign CRLs; that CA's are determined by =
the
value of the basicConstraints extension; that CA's who sign CRLs but not
certificates need not have the keyCertSign bit set in KU, and that that
section 8.4.2.1 in X.509 and corresponding text in offspring-of-2459 needs
to be fixed?

    (b) decide that non-CA's of some stripe can sign CRLs, and fix all of
the text in X.509 and offspring-of-2459 that needs to be fixed?

    (c) something else?

Clearly, leaving the text in the documents as it stands now is unacceptable=
;
I think we all agree that it's wrong.

So, what will it be?

Personally, if we were voting, I'd vote for (a) above, but that's just my
preference and there's probably some hanging chads around here...

            Al Arsenault
            Chief Security Architect
            Diversinet Corp.


----- Original Message -----
From: "David A. Cooper" <[e-mail]>
To: "Hal Lockhart" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, May 21, 2001 6:25 PM
Subject: RE: cA flag and CRL issuers (was Re: Last Call:
draft-ietf-pkix-new-part1-06.txt comments)


> Hal,
>
> I believe the debate really stems from different ways of determining the
meaning of the cA field in basicConstraints. I believe the meaning of the
field should be taken from section of the document that describes the
basicConstraints extension (section 8.4.2.1 in X.509 4th edition). This
section states:
>
>          The cA component indicates if the certified public key may be
used to verify certificate signatures
>
> This text clearly supports the position of David Kemp and I (and =
others).
>
> I do not know the basis for argument that the cA field should be set to
TRUE if the subject public key may only be used to sign CRLs, but my best
guess is that the argument is as follows:
>
>          1) The introductory (and other) material in the document states
that only CAs can issue CRLs
>
>          3) Since there is a requirement that only CAs can issue CRLs,
there must be some way for
>              relying parties to verify that the signer of a CRL is a CA.
>
>          2) In the basicConstraints extension, there is a field of type
boolean named cA. Based on the
>              name of this field, this bit must be an indicator of =
whether
the subject of the certificate is
>              is CA. (As I stated above, this is only my guess at the
reasoning. Given that in order to
>              conclude that this is the proper interpretation of the bit
one must ignore the text that explicitly
>              describes the meaning of the bit, it is possible that I am
misinterpreting the argument.)
>
>          4) Since the cA field indicates whether the subject is a CA and
the signer of a CRL must be a
>              CA, the cA field must be set to TRUE if the subject public
key is to be used to sign CRLs.
>
>
>
> I think we are all willing to accept the notion that only CAs can issue
CRLs. However, that simply means that
>
>          1) A certificate may only contain a keyUsage extension with the
cRLSign bit set, if the subject of
>              the certificate is a CA.
>
>          2) If a certificate contains a cRLDistributionPoints extension
and the cRLIssuer field is present,
>              the entity named in the cRLIssuer field must be a CA.
>
> However, the cA field in basicConstraints should only be set if the
subject public key may be used to verify signatures on certificates. The
text in the standard clearly states that this is a meaning of the bit.
Perhaps naming the field "cA" has led to some confusion, with some people
assigning semantics to the field based on the name. But the semantics of =
the
cA field in basic constraints must be based on the stated description of =
the
field ("The cA component indicates if the certified public key may be used
to verify certificate signatures"), not on the field's name.
>
> Dave
>
> At 12:52 PM 5/21/01 -0400, Hal Lockhart wrote:
> >David P. Kemp wrote:
> > > I certainly agree that the intent of X.509, from v1 to the
> > > present, was
> > > that a CA entity is the ultimate and sole authority for revoking the
> > > certificates that it issues.
> >
> >I think that at least part of this debate stems from different views of
> >exactly what constitutes an "entity". I believe the following are =
implied
in
> >messages from different people:
> >
> >1. a key
> >2. a DN
> >3. a legally constituted organization
> >
> >Hal
>
>


--=_53096F73.95F4040D
Content-Type: text/plain
Content-Disposition: attachment; filename="Bob Jueneman.vcf"

BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:Bob Jueneman
TEL;WORK:01-801/861-7387
ORG:Novell Inc. -- the leading provider of Net services software;DS eBusiness Solutions
TEL;PREF;FAX:[phone]
EMAIL;WORK;PREF;NGW:[e-mail]
N:Jueneman;Bob
TITLE:Consultant Engineer
ADR;INTL;WORK;PARCEL;POSTAL:;;Novell, Inc.\n1800 South Novell Place\n;Provo;Utah;84606;USA
LABEL;INTL;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Bob Jueneman=0A=
Novell, Inc.=0A=
1800 South Novell Place=0A=
=0A=
Provo, Utah  84606=0A=
USA
LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Bob Jueneman=0A=
Novell, Inc.=0A=
1800 South Novell Place=0A=
=0A=
Provo, Utah  84606
END:VCARD

BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:Robert R. Jueneman
TEL;WORK:01-801/861-7387
ORG:Novell, Inc.;DS eBusiness Solutions
TEL;PREF;FAX:[phone]
EMAIL;WORK;PREF;NGW:[e-mail]
N:Jueneman;Bob
TITLE:Consultant Engineer
ADR;INTL;WORK;PARCEL;POSTAL:;PRV-F331;122 E. 1700 South;Provo;Utah;84606;USA
LABEL;INTL;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Robert R. Jueneman=0A=
PRV-F331=0A=
122 E. 1700 South=0A=
Provo, Utah  84606=0A=
USA
LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Robert R. Jueneman=0A=
PRV-F331=0A=
122 E. 1700 South=0A=
Provo, Utah  84606
TEL;HOME:1-801-765-4378
TEL;CELL:1-801-361-1410
TEL;PREF:1-801-861-7387, 1-800-453-1267
END:VCARD


--=_53096F73.95F4040D--


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id GAA06784 for ietf-pkix-bks; Tue, 22 May 2001 06:38:37 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA06780 for <[e-mail]>; Tue, 22 May 2001 06:38:31 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id JAA14597 for <[e-mail]>; Tue, 22 May 2001 09:38:15 -0400 (EDT)
Received: from reject.missi.ncsc.mil (reject.missi.ncsc.mil [144.51.60.17]) by stingray.missi.ncsc.mil with SMTP id JAA14593 for <[e-mail]>; Tue, 22 May 2001 09:38:15 -0400 (EDT)
Received: from 144.51.60.215 by reject.missi.ncsc.mil (InterScan E-Mail VirusWall NT); Tue, 22 May 2001 09:41:02 -0400 (Eastern Daylight Time)
Received: from missi.ncsc.mil (ara.missi.ncsc.mil [144.51.55.128]) by amx.missi.ncsc.mil with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JSFMCJ8L; Tue, 22 May 2001 09:41:35 -0400
Message-ID: <[e-mail]>
Date: Tue, 22 May 2001 09:35:13 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: cA flag and CRL issuers (was Re: Last Call:   draft-ietf-pkix-new-part1-06.txt comments)
References: <[e-mail]> <002e01c0e261$d5c5f7c0$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Al,

The problem with (a) is that *not* only CAs can sign CRLs.  The discussion
has lasted so long because of a proposal to expand the description of
the keyUsage extension from one sentence to six.
Tim proposed a rule whereby cRLSign could be used to verify CRLs containing
PK certificates ONLY if cA is true, and cRLSign could be used to verify
CRLs containing Attribute Certificates ONLY if cA is false.

There are two problems with this - 1) it is unnecessarily complex: keyUsage
and issuer name or CRLDP are sufficient to link the issuer of a certificate
with the CRL which can revoke it, and 2) it needlessly prohibits a CA from
issuing attribute certificates.  (The AC profile currently does prohibit
CAs from being AAs, but if we want that prohibition, it should be an
explicit statement in the AC profile, not a side effect of processing
rules for the keyUsage and basicConstraints extensions.)

The answer is (c):  Only the issuer of a certificate (CA or AA) is responsible
for signing the CRLs that apply to that certificate.  That responsibility
can be exercised directly by using the same public key to sign the cert
and CRL, or indirectly by issuing a cRLSign certificate for the public
key used to sign the CRL.

The cA bit tells you nothing about who is entitled to revoke a
certificate: VeriSign can't revoke Cybertrust certificates
even though it is a CA.  Using the cA bit in the rules for
CRL processing adds no value, it adds only needless confusion.

Dave




Al Arsenault wrote:
> 
> Okay, I think that we've reached consensus that the text in the current
> documents (X.509 and offspring-of-2459) is wrong.  It's inconsistent, as
> cited by Dave Cooper below.
> 
> Now, what's the best way to fix it?
> 
> Do we:
> 
>     (a) decide that only CA's can sign CRLs; that CA's are determined by the
> value of the basicConstraints extension; that CA's who sign CRLs but not
> certificates need not have the keyCertSign bit set in KU, and that that
> section 8.4.2.1 in X.509 and corresponding text in offspring-of-2459 needs
> to be fixed?
> 
>     (b) decide that non-CA's of some stripe can sign CRLs, and fix all of
> the text in X.509 and offspring-of-2459 that needs to be fixed?
> 
>     (c) something else?
> 
> Clearly, leaving the text in the documents as it stands now is unacceptable;
> I think we all agree that it's wrong.
> 
> So, what will it be?
> 
> Personally, if we were voting, I'd vote for (a) above, but that's just my
> preference and there's probably some hanging chads around here...
> 
>             Al Arsenault
>             Chief Security Architect
>             Diversinet Corp.


Received: by above.proper.com (8.9.3/8.9.3) id UAA11545 for ietf-pkix-bks; Mon, 21 May 2001 20:07:22 -0700 (PDT)
Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by above.proper.com (8.9.3/8.9.3) with ESMTP id UAA11536 for <[e-mail]>; Mon, 21 May 2001 20:07:16 -0700 (PDT)
Received: by aspams52.ca.com with Internet Mail Service (5.5.2650.21) id <LKWHNTPP>; Tue, 22 May 2001 13:06:45 +1000
Message-ID: <[e-mail]>
From: "Ramsay, Ron" <[e-mail]>
To: [e-mail]
Subject: RE: C=country; just a convention?
Date: Tue, 22 May 2001 13:06:51 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

X.500 uses object identifiers, not strings. Therefore, there is no
'normative' definition of the attribute names. LDAP generally uses string
names for attributes. The names reflect those used in the X500 documents.
Many definitions are given in RFC 2256.

Ron

-----Original Message-----
From: Vivian Cancio [mailto:[e-mail]]
Sent: Tuesday, 22 May 2001 8:18
To: '[e-mail]'; 'Frank Balluffi'
Cc: [e-mail]
Subject: RE: C=country; just a convention?


Terry Hayes wrote:

> RFC 2252 itself references X.520, so it may 
> be intended that attribute type strings from that document 
> should apply.

In the X.500, X.509, X.520 and others, I couldn't find a 'normative' section
specifying the use of these short names, they are only used in examples.


Frank Balluffi wrote:

> RFC 2253 is the most up-to-date standard for the string 
> representation of a distinguished name, which defines
> ST for stateOrProvinceName and STREET for streetAddress.
> <snip>
> I would go with RFC 2253.

Hmm ... it's really not 'defined' ...
RFC 2253 reads (and exactly quote below) ... 
"As an example, strings for a few of the attribute
   types frequently seen in RDNs include:

                    String  X.500 AttributeType
                    ------------------------------
                    CN      commonName
                    L       localityName
                    ST      stateOrProvinceName
                    <snip>

This is not normative, and are included as examples, and although it
references X500, they are also used in examples in those series of
documents.

Thanks. I appreciate all the feedback!
We need to be careful about making any assumptions with these short names as
there seems to be no normative text defining them. Is there a need to
recommend a standard way of using these short names (where discrepancy
exist)?

Vivian

Vivian


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id SAA08239 for ietf-pkix-bks; Mon, 21 May 2001 18:49:15 -0700 (PDT)
Received: from femail14.sdc1.sfba.home.com (femail14.sdc1.sfba.home.com [24.0.95.141]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA08235 for <[e-mail]>; Mon, 21 May 2001 18:49:09 -0700 (PDT)
Received: from cc787228a ([24.180.131.6]) by femail14.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010522014907.HKID12893.femail14.sdc1.sfba.home.com@cc787228a>; Mon, 21 May 2001 18:49:07 -0700
Message-ID: <002e01c0e261$d5c5f7c0$[e-mail]>
From: "Al Arsenault" <[e-mail]>
To: "Hal Lockhart" <[e-mail]>, "David A. Cooper" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: cA flag and CRL issuers (was Re: Last Call:  draft-ietf-pkix-new-part1-06.txt comments)
Date: Mon, 21 May 2001 21:52:18 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Okay, I think that we've reached consensus that the text in the current
documents (X.509 and offspring-of-2459) is wrong.  It's inconsistent, as
cited by Dave Cooper below.

Now, what's the best way to fix it?

Do we:

    (a) decide that only CA's can sign CRLs; that CA's are determined by the
value of the basicConstraints extension; that CA's who sign CRLs but not
certificates need not have the keyCertSign bit set in KU, and that that
section 8.4.2.1 in X.509 and corresponding text in offspring-of-2459 needs
to be fixed?

    (b) decide that non-CA's of some stripe can sign CRLs, and fix all of
the text in X.509 and offspring-of-2459 that needs to be fixed?

    (c) something else?

Clearly, leaving the text in the documents as it stands now is unacceptable;
I think we all agree that it's wrong.

So, what will it be?

Personally, if we were voting, I'd vote for (a) above, but that's just my
preference and there's probably some hanging chads around here...

            Al Arsenault
            Chief Security Architect
            Diversinet Corp.


----- Original Message -----
From: "David A. Cooper" <[e-mail]>
To: "Hal Lockhart" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, May 21, 2001 6:25 PM
Subject: RE: cA flag and CRL issuers (was Re: Last Call:
draft-ietf-pkix-new-part1-06.txt comments)


> Hal,
>
> I believe the debate really stems from different ways of determining the
meaning of the cA field in basicConstraints. I believe the meaning of the
field should be taken from section of the document that describes the
basicConstraints extension (section 8.4.2.1 in X.509 4th edition). This
section states:
>
>          The cA component indicates if the certified public key may be
used to verify certificate signatures
>
> This text clearly supports the position of David Kemp and I (and others).
>
> I do not know the basis for argument that the cA field should be set to
TRUE if the subject public key may only be used to sign CRLs, but my best
guess is that the argument is as follows:
>
>          1) The introductory (and other) material in the document states
that only CAs can issue CRLs
>
>          3) Since there is a requirement that only CAs can issue CRLs,
there must be some way for
>              relying parties to verify that the signer of a CRL is a CA.
>
>          2) In the basicConstraints extension, there is a field of type
boolean named cA. Based on the
>              name of this field, this bit must be an indicator of whether
the subject of the certificate is
>              is CA. (As I stated above, this is only my guess at the
reasoning. Given that in order to
>              conclude that this is the proper interpretation of the bit
one must ignore the text that explicitly
>              describes the meaning of the bit, it is possible that I am
misinterpreting the argument.)
>
>          4) Since the cA field indicates whether the subject is a CA and
the signer of a CRL must be a
>              CA, the cA field must be set to TRUE if the subject public
key is to be used to sign CRLs.
>
>
>
> I think we are all willing to accept the notion that only CAs can issue
CRLs. However, that simply means that
>
>          1) A certificate may only contain a keyUsage extension with the
cRLSign bit set, if the subject of
>              the certificate is a CA.
>
>          2) If a certificate contains a cRLDistributionPoints extension
and the cRLIssuer field is present,
>              the entity named in the cRLIssuer field must be a CA.
>
> However, the cA field in basicConstraints should only be set if the
subject public key may be used to verify signatures on certificates. The
text in the standard clearly states that this is a meaning of the bit.
Perhaps naming the field "cA" has led to some confusion, with some people
assigning semantics to the field based on the name. But the semantics of the
cA field in basic constraints must be based on the stated description of the
field ("The cA component indicates if the certified public key may be used
to verify certificate signatures"), not on the field's name.
>
> Dave
>
> At 12:52 PM 5/21/01 -0400, Hal Lockhart wrote:
> >David P. Kemp wrote:
> > > I certainly agree that the intent of X.509, from v1 to the
> > > present, was
> > > that a CA entity is the ultimate and sole authority for revoking the
> > > certificates that it issues.
> >
> >I think that at least part of this debate stems from different views of
> >exactly what constitutes an "entity". I believe the following are implied
in
> >messages from different people:
> >
> >1. a key
> >2. a DN
> >3. a legally constituted organization
> >
> >Hal
>
>



Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id PAA28692 for ietf-pkix-bks; Mon, 21 May 2001 15:27:44 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA28687 for <[e-mail]>; Mon, 21 May 2001 15:27:37 -0700 (PDT)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id SAA00316; Mon, 21 May 2001 18:27:38 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Mon, 21 May 2001 18:25:42 -0400
To: Hal Lockhart <[e-mail]>
From: "David A. Cooper" <[e-mail]>
Subject: RE: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments)
Cc: [e-mail]
In-Reply-To: <899128A30EEDD1118FC900A0C9C74A34BA97FD@BIGBIRD>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Hal,

I believe the debate really stems from different ways of determining the meaning of the cA field in basicConstraints. I believe the meaning of the field should be taken from section of the document that describes the basicConstraints extension (section 8.4.2.1 in X.509 4th edition). This section states:

         The cA component indicates if the certified public key may be used to verify certificate signatures

This text clearly supports the position of David Kemp and I (and others).

I do not know the basis for argument that the cA field should be set to TRUE if the subject public key may only be used to sign CRLs, but my best guess is that the argument is as follows:

         1) The introductory (and other) material in the document states that only CAs can issue CRLs

         3) Since there is a requirement that only CAs can issue CRLs, there must be some way for
             relying parties to verify that the signer of a CRL is a CA.

         2) In the basicConstraints extension, there is a field of type boolean named cA. Based on the
             name of this field, this bit must be an indicator of whether the subject of the certificate is
             is CA. (As I stated above, this is only my guess at the reasoning. Given that in order to
             conclude that this is the proper interpretation of the bit one must ignore the text that explicitly
             describes the meaning of the bit, it is possible that I am misinterpreting the argument.)

         4) Since the cA field indicates whether the subject is a CA and the signer of a CRL must be a
             CA, the cA field must be set to TRUE if the subject public key is to be used to sign CRLs.



I think we are all willing to accept the notion that only CAs can issue CRLs. However, that simply means that

         1) A certificate may only contain a keyUsage extension with the cRLSign bit set, if the subject of
             the certificate is a CA.

         2) If a certificate contains a cRLDistributionPoints extension and the cRLIssuer field is present,
             the entity named in the cRLIssuer field must be a CA.

However, the cA field in basicConstraints should only be set if the subject public key may be used to verify signatures on certificates. The text in the standard clearly states that this is a meaning of the bit. Perhaps naming the field "cA" has led to some confusion, with some people assigning semantics to the field based on the name. But the semantics of the cA field in basic constraints must be based on the stated description of the field ("The cA component indicates if the certified public key may be used to verify certificate signatures"), not on the field's name.

Dave

At 12:52 PM 5/21/01 -0400, Hal Lockhart wrote:
>David P. Kemp wrote:
> > I certainly agree that the intent of X.509, from v1 to the 
> > present, was
> > that a CA entity is the ultimate and sole authority for revoking the
> > certificates that it issues.
>
>I think that at least part of this debate stems from different views of
>exactly what constitutes an "entity". I believe the following are implied in
>messages from different people:
>
>1. a key
>2. a DN
>3. a legally constituted organization
>
>Hal




Received: by above.proper.com (8.9.3/8.9.3) id PAA27249 for ietf-pkix-bks; Mon, 21 May 2001 15:18:24 -0700 (PDT)
Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA27229 for <[e-mail]>; Mon, 21 May 2001 15:18:18 -0700 (PDT)
Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19) id <JHZ8B952>; Mon, 21 May 2001 15:18:18 -0700
Message-ID: <[e-mail]>
From: Vivian Cancio <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'Frank Balluffi'" <[e-mail]>
Cc: [e-mail]
Subject: RE: C=country; just a convention?
Date: Mon, 21 May 2001 15:18:17 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Terry Hayes wrote:

> RFC 2252 itself references X.520, so it may 
> be intended that attribute type strings from that document 
> should apply.

In the X.500, X.509, X.520 and others, I couldn't find a 'normative' section
specifying the use of these short names, they are only used in examples.


Frank Balluffi wrote:

> RFC 2253 is the most up-to-date standard for the string 
> representation of a distinguished name, which defines
> ST for stateOrProvinceName and STREET for streetAddress.
> <snip>
> I would go with RFC 2253.

Hmm ... it's really not 'defined' ...
RFC 2253 reads (and exactly quote below) ... 
"As an example, strings for a few of the attribute
   types frequently seen in RDNs include:

                    String  X.500 AttributeType
                    ------------------------------
                    CN      commonName
                    L       localityName
                    ST      stateOrProvinceName
                    <snip>

This is not normative, and are included as examples, and although it
references X500, they are also used in examples in those series of
documents.

Thanks. I appreciate all the feedback!
We need to be careful about making any assumptions with these short names as
there seems to be no normative text defining them. Is there a need to
recommend a standard way of using these short names (where discrepancy
exist)?

Vivian

Vivian


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA26057 for ietf-pkix-bks; Mon, 21 May 2001 14:57:08 -0700 (PDT)
Received: from e1.ny.us.ibm.com ([32.97.182.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA26052 for <[e-mail]>; Mon, 21 May 2001 14:57:01 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA322376; Mon, 21 May 2001 17:54:25 -0400
Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id RAA96040; Mon, 21 May 2001 17:50:40 -0400
To: Peter Williams <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: C=country; just a convention?
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
From: "Timothy Hahn" <[e-mail]>
Message-ID: <[e-mail]>
Date: Mon, 21 May 2001 17:56:00 -0400
X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Release 5.0.7  SPR #MIAS4UTJ8H &S/390 SPR #JHEG4V8UT5|April 5, 2001) at 05/21/2001 05:56:01 PM, Serialize complete at 05/21/2001 05:56:01 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 00783D7E85256A53_="
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This is a multipart message in MIME format.
--=_alternative 00783D7E85256A53_=
Content-Type: text/plain; charset="us-ascii"

Peter,

The Internet Draft is written with those words to ensure that string forms 
are consistently interpreted.  For attributes that do not appear in "the 
table", it is possible that the non-OID form of the attribute type name 
could be different between different servers.

The Internet Draft also makes the usage of the "short attribute names" 
more explicit than the prior RFC.

Kurt Zeilenga is the author of the Internet Draft and can provide more 
details regarding the intent.

Regards,
Tim Hahn

Internet: [e-mail]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: [phone]     tie-line: 8/852.6388
fax: [phone]





Peter Williams <[e-mail]>
05/21/2001 05:36 PM

 
        To:     "'Timothy Hahn'" <[e-mail]>, [e-mail]
        cc: 
        Subject:        RE: C=country; just a convention?

 

The way your bis reference text on AttributeType encoding is phrased
suggests 
that it is INCORRECT to use country=GB; one MUST use c=GB.

The specification also suggests, strongly, that using the name of the
ASN.1 type for the string-name of the AttributeType is WRONG. Unless
the type is one of those listed in the table of 2.3; one MUST use the 
dotted-decimal form.

PKIX may want to provide specification advice, on all this.

 -----Original Message-----
From: Timothy Hahn [mailto:[e-mail]]
Sent: Monday, May 21, 2001 1:23 PM
To: [e-mail]
Subject: Re: C=country; just a convention?



Hi all, 

FWIW, the most up-to-date information regarding string forms of
distinguished names, as prescribed by LDAP-related documents can be found
in: 

"Lightweight Directory Access Protocol (v3): UTF-8 String Representation 
of
Distinguished Names", Kurt Zeilenga, 04/30/2001. (19892 bytes) 
(http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-dn-05.txt) 
     The X.500 Directory uses distinguished names as the primary keys to
entries in the directory. Distinguished Names are encoded in ASN.1 in the
X.500 
     Directory protocols. In the Lightweight Directory Access Protocol, a
string representation of distinguished names is transferred. This
specification defines the 
     string format for representing names, which is designed to give a 
clean
representation of commonly used distinguished names, while being able to 
     represent any distinguished name. 

Regards,
Tim Hahn

Internet: [e-mail]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: [phone]     tie-line: 8/852.6388
fax: [phone]



[e-mail] (Terry Hayes) 
Sent by: [e-mail] 
05/21/2001 02:47 PM 
 
        To:        Vivian Cancio <[e-mail]> 
        cc:        "'Frank Balluffi'" <[e-mail]>,
[e-mail] 
        Subject:        Re: C=country; just a convention? 

 


I believe the string representation of a Distinguished Name (DN) that we 
are discussing is defined by the LDAP RFCs, not by X.500 or PKIX .  As 
such we should expect that the LDAP RFC would give some indication as to 
the proper form of the attribute type. Looking in RFC 2253, we find the 
following statement:

 "If the AttributeType is in a published table of attribute types 
associated with LDAP [4], then the type name string from that table is 
used, otherwise it is encoded as the dotted-decimal encoding of the 
AttributeType's OBJECT IDENTIFIER."

The reference "LDAP [4]" is for RFC 2252.  However I don't see a table 
of values in that document.  RFC 2252 itself references X.520, so it may 
be intended that attribute type strings from that document should apply.

Terry Hayes

Vivian Cancio wrote:

>Frank Balluffi said:
>
>>As I recall LDAP does transmit the string representation of a 
>>Name (e.g., "CN=Steve Kille,O=Isode Limited,C=GB") over the 
>>wire in anOCTET STRING (or LDAPString).
>>
>
>It may not work if "stateOrProvinceName" is ever one of the fields
>transmitted between vendors. See the discrepancies from the feedback. I
have
>concluded that there's no specification defining a formal standard for
these
>short names. Any expected interoperability over the wire must rely on the
>OID (which was the intention in the first place?).
>
>I guess the users reading displayed certificates using this terminology
must
>be clever and deduct based on the information on the right of the "=", or
>vendors should provide "legends" defining their use.
>
>Here is one example of discrepancy:
>In X.520:
>s                 stateOrProvinceName
>
>In Peter's list:
>sp                 stateOrProvinceName
>st                 streetAddress
>s                 surname
>
>In RFC 2253
>st                 stateOrProvinceName
>
>
>Vivian
>
>
>>-----Original Message-----
>>From: Frank Balluffi [mailto:[e-mail]]
>>Sent: Friday, May 18, 2001 6:42 PM
>>To: Vivian Cancio
>>Cc: [e-mail]
>>Subject: RE: C=country; just a convention?
>>
>>
>>Vivian Cancio said:
>>
>>>I'm assuming that since it doesn't go "on the wire" it is somewhat
>>>irrelevant?
>>>
>>As I recall LDAP does transmit the string representation of a 
>>Name (e.g.,
>>"CN=Steve Kille,O=Isode Limited,C=GB") over the wire in an 
>>OCTET STRING (or
>>LDAPString). You can even roll your own AttributeTypeAndValues using
>>period-delimited attribute types and hexadecimal attribute values. For
>>example
>>
>>1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB [From RFC 2253.]
>>
>>Frank
>>



--=_alternative 00783D7E85256A53_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Peter,</font>
<br>
<br><font size=2 face="sans-serif">The Internet Draft is written with those words to ensure that string forms are consistently interpreted. &nbsp;For attributes that do not appear in &quot;the table&quot;, it is possible that the non-OID form of the attribute type name could be different between different servers.</font>
<br>
<br><font size=2 face="sans-serif">The Internet Draft also makes the usage of the &quot;short attribute names&quot; more explicit than the prior RFC.</font>
<br>
<br><font size=2 face="sans-serif">Kurt Zeilenga is the author of the Internet Draft and can provide more details regarding the intent.<br>
</font>
<br><font size=2 face="sans-serif">Regards,<br>
Tim Hahn<br>
<br>
Internet: [e-mail]<br>
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)<br>
phone: [phone] &nbsp; &nbsp; tie-line: 8/852.6388<br>
fax: [phone]<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>Peter Williams &lt;[e-mail]&gt;</b></font>
<p><font size=1 face="sans-serif">05/21/2001 05:36 PM</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;&quot;'Timothy Hahn'&quot; &lt;[e-mail]&gt;, [e-mail]</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;RE: C=country; just a convention?</font>
<br>
<br><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp;</font></table>
<br>
<br><font size=2 face="Courier New">The way your bis reference text on AttributeType encoding is phrased<br>
suggests <br>
that it is INCORRECT to use country=GB; one MUST use c=GB.<br>
<br>
The specification also suggests, strongly, that using the name of the<br>
ASN.1 type for the string-name of the AttributeType is WRONG. Unless<br>
the type is one of those listed in the table of 2.3; one MUST use the <br>
dotted-decimal form.<br>
<br>
PKIX may want to provide specification advice, on all this.<br>
<br>
 -----Original Message-----<br>
From: Timothy Hahn [mailto:[e-mail]]<br>
Sent: Monday, May 21, 2001 1:23 PM<br>
To: [e-mail]<br>
Subject: Re: C=country; just a convention?<br>
<br>
<br>
<br>
Hi all, <br>
<br>
FWIW, the most up-to-date information regarding string forms of<br>
distinguished names, as prescribed by LDAP-related documents can be found<br>
in: <br>
<br>
&quot;Lightweight Directory Access Protocol (v3): UTF-8 String Representation of<br>
Distinguished Names&quot;, Kurt Zeilenga, 04/30/2001. (19892 bytes) <br>
(http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-dn-05.txt) <br>
 &nbsp; &nbsp; The X.500 Directory uses distinguished names as the primary keys to<br>
entries in the directory. Distinguished Names are encoded in ASN.1 in the<br>
X.500 <br>
 &nbsp; &nbsp; Directory protocols. In the Lightweight Directory Access Protocol, a<br>
string representation of distinguished names is transferred. This<br>
specification defines the <br>
 &nbsp; &nbsp; string format for representing names, which is designed to give a clean<br>
representation of commonly used distinguished names, while being able to <br>
 &nbsp; &nbsp; represent any distinguished name. <br>
<br>
Regards,<br>
Tim Hahn<br>
<br>
Internet: [e-mail]<br>
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)<br>
phone: [phone] &nbsp; &nbsp; tie-line: 8/852.6388<br>
fax: [phone]<br>
<br>
<br>
<br>
[e-mail] (Terry Hayes) <br>
Sent by: [e-mail] <br>
05/21/2001 02:47 PM <br>
 &nbsp; &nbsp; &nbsp; &nbsp;<br>
 &nbsp; &nbsp; &nbsp; &nbsp;To: &nbsp; &nbsp; &nbsp; &nbsp;Vivian Cancio &lt;[e-mail]&gt; <br>
 &nbsp; &nbsp; &nbsp; &nbsp;cc: &nbsp; &nbsp; &nbsp; &nbsp;&quot;'Frank Balluffi'&quot; &lt;[e-mail]&gt;,<br>
[e-mail] <br>
 &nbsp; &nbsp; &nbsp; &nbsp;Subject: &nbsp; &nbsp; &nbsp; &nbsp;Re: C=country; just a convention? <br>
<br>
 &nbsp; &nbsp; &nbsp; <br>
<br>
<br>
I believe the string representation of a Distinguished Name (DN) that we <br>
are discussing is defined by the LDAP RFCs, not by X.500 or PKIX . &nbsp;As <br>
such we should expect that the LDAP RFC would give some indication as to <br>
the proper form of the attribute type. Looking in RFC 2253, we find the <br>
following statement:<br>
<br>
 &quot;If the AttributeType is in a published table of attribute types <br>
associated with LDAP [4], then the type name string from that table is <br>
used, otherwise it is encoded as the dotted-decimal encoding of the <br>
AttributeType's OBJECT IDENTIFIER.&quot;<br>
<br>
The reference &quot;LDAP [4]&quot; is for RFC 2252. &nbsp;However I don't see a table <br>
of values in that document. &nbsp;RFC 2252 itself references X.520, so it may <br>
be intended that attribute type strings from that document should apply.<br>
</font>
<br><font size=2 face="Courier New">Terry Hayes<br>
<br>
Vivian Cancio wrote:<br>
<br>
&gt;Frank Balluffi said:<br>
&gt;<br>
&gt;&gt;As I recall LDAP does transmit the string representation of a <br>
&gt;&gt;Name (e.g., &quot;CN=Steve Kille,O=Isode Limited,C=GB&quot;) over the <br>
&gt;&gt;wire in anOCTET STRING (or LDAPString).<br>
&gt;&gt;<br>
&gt;<br>
&gt;It may not work if &quot;stateOrProvinceName&quot; is ever one of the fields<br>
&gt;transmitted between vendors. See the discrepancies from the feedback. I<br>
have<br>
&gt;concluded that there's no specification defining a formal standard for<br>
these<br>
&gt;short names. Any expected interoperability over the wire must rely on the<br>
&gt;OID (which was the intention in the first place?).<br>
&gt;<br>
&gt;I guess the users reading displayed certificates using this terminology<br>
must<br>
&gt;be clever and deduct based on the information on the right of the &quot;=&quot;, or<br>
&gt;vendors should provide &quot;legends&quot; defining their use.<br>
&gt;<br>
&gt;Here is one example of discrepancy:<br>
&gt;In X.520:<br>
&gt;s &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; stateOrProvinceName<br>
&gt;<br>
&gt;In Peter's list:<br>
&gt;sp &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; stateOrProvinceName<br>
&gt;st &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; streetAddress<br>
&gt;s &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; surname<br>
&gt;<br>
&gt;In RFC 2253<br>
&gt;st &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; stateOrProvinceName<br>
&gt;<br>
&gt;<br>
&gt;Vivian<br>
&gt;<br>
&gt;<br>
&gt;&gt;-----Original Message-----<br>
&gt;&gt;From: Frank Balluffi [mailto:[e-mail]]<br>
&gt;&gt;Sent: Friday, May 18, 2001 6:42 PM<br>
&gt;&gt;To: Vivian Cancio<br>
&gt;&gt;Cc: [e-mail]<br>
&gt;&gt;Subject: RE: C=country; just a convention?<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;Vivian Cancio said:<br>
&gt;&gt;<br>
&gt;&gt;&gt;I'm assuming that since it doesn't go &quot;on the wire&quot; it is somewhat<br>
&gt;&gt;&gt;irrelevant?<br>
&gt;&gt;&gt;<br>
&gt;&gt;As I recall LDAP does transmit the string representation of a <br>
&gt;&gt;Name (e.g.,<br>
&gt;&gt;&quot;CN=Steve Kille,O=Isode Limited,C=GB&quot;) over the wire in an <br>
&gt;&gt;OCTET STRING (or<br>
&gt;&gt;LDAPString). You can even roll your own AttributeTypeAndValues using<br>
&gt;&gt;period-delimited attribute types and hexadecimal attribute values. For<br>
&gt;&gt;example<br>
&gt;&gt;<br>
&gt;&gt;1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB [From RFC 2253.]<br>
&gt;&gt;<br>
&gt;&gt;Frank<br>
&gt;&gt;<br>
</font>
<br>
<br>
--=_alternative 00783D7E85256A53_=--


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA25532 for ietf-pkix-bks; Mon, 21 May 2001 14:38:31 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA25523 for <[e-mail]>; Mon, 21 May 2001 14:38:24 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Mon, 21 May 2001 14:38:42 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Mon, 21 May 2001 14:38:41 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <HR26SW7M>; Mon, 21 May 2001 14:36:12 -0700
Content-return: allowed
Date: Mon, 21 May 2001 14:36:02 -0700
From: Peter Williams <[e-mail]>
Subject: RE: C=country; just a convention?
To: "'Timothy Hahn'" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

The way your bis reference text on AttributeType encoding is phrased
suggests 
that it is INCORRECT to use country=GB; one MUST use c=GB.

The specification also suggests, strongly, that using the name of the
ASN.1 type for the string-name of the AttributeType is WRONG. Unless
the type is one of those listed in the table of 2.3; one MUST use the 
dotted-decimal form.

PKIX may want to provide specification advice, on all this.

 -----Original Message-----
From: Timothy Hahn [mailto:[e-mail]]
Sent: Monday, May 21, 2001 1:23 PM
To: [e-mail]
Subject: Re: C=country; just a convention?



Hi all, 

FWIW, the most up-to-date information regarding string forms of
distinguished names, as prescribed by LDAP-related documents can be found
in: 

"Lightweight Directory Access Protocol (v3): UTF-8 String Representation of
Distinguished Names", Kurt Zeilenga, 04/30/2001. (19892 bytes) 
(http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-dn-05.txt) 
     The X.500 Directory uses distinguished names as the primary keys to
entries in the directory. Distinguished Names are encoded in ASN.1 in the
X.500 
     Directory protocols. In the Lightweight Directory Access Protocol, a
string representation of distinguished names is transferred. This
specification defines the 
     string format for representing names, which is designed to give a clean
representation of commonly used distinguished names, while being able to 
     represent any distinguished name. 

Regards,
Tim Hahn

Internet: [e-mail]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: [phone]     tie-line: 8/852.6388
fax: [phone]



[e-mail] (Terry Hayes) 
Sent by: [e-mail] 
05/21/2001 02:47 PM 
        
        To:        Vivian Cancio <[e-mail]> 
        cc:        "'Frank Balluffi'" <[e-mail]>,
[e-mail] 
        Subject:        Re: C=country; just a convention? 

       


I believe the string representation of a Distinguished Name (DN) that we 
are discussing is defined by the LDAP RFCs, not by X.500 or PKIX .  As 
such we should expect that the LDAP RFC would give some indication as to 
the proper form of the attribute type. Looking in RFC 2253, we find the 
following statement:

 "If the AttributeType is in a published table of attribute types 
associated with LDAP [4], then the type name string from that table is 
used, otherwise it is encoded as the dotted-decimal encoding of the 
AttributeType's OBJECT IDENTIFIER."

The reference "LDAP [4]" is for RFC 2252.  However I don't see a table 
of values in that document.  RFC 2252 itself references X.520, so it may 
be intended that attribute type strings from that document should apply.

Terry Hayes

Vivian Cancio wrote:

>Frank Balluffi said:
>
>>As I recall LDAP does transmit the string representation of a 
>>Name (e.g., "CN=Steve Kille,O=Isode Limited,C=GB") over the 
>>wire in anOCTET STRING (or LDAPString).
>>
>
>It may not work if "stateOrProvinceName" is ever one of the fields
>transmitted between vendors. See the discrepancies from the feedback. I
have
>concluded that there's no specification defining a formal standard for
these
>short names. Any expected interoperability over the wire must rely on the
>OID (which was the intention in the first place?).
>
>I guess the users reading displayed certificates using this terminology
must
>be clever and deduct based on the information on the right of the "=", or
>vendors should provide "legends" defining their use.
>
>Here is one example of discrepancy:
>In X.520:
>s                 stateOrProvinceName
>
>In Peter's list:
>sp                 stateOrProvinceName
>st                 streetAddress
>s                 surname
>
>In RFC 2253
>st                 stateOrProvinceName
>
>
>Vivian
>
>
>>-----Original Message-----
>>From: Frank Balluffi [mailto:[e-mail]]
>>Sent: Friday, May 18, 2001 6:42 PM
>>To: Vivian Cancio
>>Cc: [e-mail]
>>Subject: RE: C=country; just a convention?
>>
>>
>>Vivian Cancio said:
>>
>>>I'm assuming that since it doesn't go "on the wire" it is somewhat
>>>irrelevant?
>>>
>>As I recall LDAP does transmit the string representation of a 
>>Name (e.g.,
>>"CN=Steve Kille,O=Isode Limited,C=GB") over the wire in an 
>>OCTET STRING (or
>>LDAPString). You can even roll your own AttributeTypeAndValues using
>>period-delimited attribute types and hexadecimal attribute values. For
>>example
>>
>>1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB [From RFC 2253.]
>>
>>Frank
>>


Received: by above.proper.com (8.9.3/8.9.3) id NAA20207 for ietf-pkix-bks; Mon, 21 May 2001 13:26:56 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA20194 for <[e-mail]>; Mon, 21 May 2001 13:26:49 -0700 (PDT)
Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 21 May 2001 14:26:15 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Mon, 21 May 2001 14:25:51 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: C=country; just a convention?
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id NAA20196
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

My very vague recollection is that these "business card abbreviations" were originally defined in X.400??

Bob

>>> Peter Gutmann <[e-mail]> 05/22/01 08:08AM >>>
"Housley, Russ" <[e-mail]> writes:

>The table in RFC 2253 has a few discrepancies with your table.

Yes I know, I took the ones which are in common use.  RFC 2253 has its
definitions for things like street addresses and state or province, but other
places define them differently, and it appears that people are using the
definitions given in other places.

                    "But it izz written!" bellowed Beelzebub.
                    "But it might be written differently somewhere else" said
                        Crowley.  "Where you can't read it".
                    "In bigger letters" said Aziraphale.
                    "Underlined" Crowley added.
                    "Twice" suggested Aziraphale.
                        -- Neil Gaiman and Terry Pratchett, "Good Omens"

Peter.




Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA20095 for ietf-pkix-bks; Mon, 21 May 2001 13:23:33 -0700 (PDT)
Received: from e1.ny.us.ibm.com ([32.97.182.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA20091 for <[e-mail]>; Mon, 21 May 2001 13:23:26 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA549514 for <[e-mail]>; Mon, 21 May 2001 16:21:12 -0400
Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id QAA19352 for <[e-mail]>; Mon, 21 May 2001 16:17:26 -0400
To: [e-mail]
Subject: Re: C=country; just a convention?
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
From: "Timothy Hahn" <[e-mail]>
Message-ID: <[e-mail]>
Date: Mon, 21 May 2001 16:22:44 -0400
X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Release 5.0.7  SPR #MIAS4UTJ8H &S/390 SPR #JHEG4V8UT5|April 5, 2001) at 05/21/2001 04:22:48 PM, Serialize complete at 05/21/2001 04:22:48 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 006F59B985256A53_="
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This is a multipart message in MIME format.
--=_alternative 006F59B985256A53_=
Content-Type: text/plain; charset="us-ascii"

Hi all,

FWIW, the most up-to-date information regarding string forms of 
distinguished names, as prescribed by LDAP-related documents can be found 
in:

"Lightweight Directory Access Protocol (v3): UTF-8 String Representation 
of Distinguished Names", Kurt Zeilenga, 04/30/2001. (19892 bytes)
(http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-dn-05.txt)
     The X.500 Directory uses distinguished names as the primary keys to 
entries in the directory. Distinguished Names are encoded in ASN.1 in the 
X.500
     Directory protocols. In the Lightweight Directory Access Protocol, a 
string representation of distinguished names is transferred. This 
specification defines the
     string format for representing names, which is designed to give a 
clean representation of commonly used distinguished names, while being 
able to
     represent any distinguished name. 

Regards,
Tim Hahn

Internet: [e-mail]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: [phone]     tie-line: 8/852.6388
fax: [phone]





[e-mail] (Terry Hayes)
Sent by: [e-mail]
05/21/2001 02:47 PM

 
        To:     Vivian Cancio <[e-mail]>
        cc:     "'Frank Balluffi'" <[e-mail]>, [e-mail]
        Subject:        Re: C=country; just a convention?

 

I believe the string representation of a Distinguished Name (DN) that we 
are discussing is defined by the LDAP RFCs, not by X.500 or PKIX .  As 
such we should expect that the LDAP RFC would give some indication as to 
the proper form of the attribute type. Looking in RFC 2253, we find the 
following statement:

  "If the AttributeType is in a published table of attribute types 
associated with LDAP [4], then the type name string from that table is 
used, otherwise it is encoded as the dotted-decimal encoding of the 
AttributeType's OBJECT IDENTIFIER."

The reference "LDAP [4]" is for RFC 2252.  However I don't see a table 
of values in that document.  RFC 2252 itself references X.520, so it may 
be intended that attribute type strings from that document should apply.

Terry Hayes

Vivian Cancio wrote:

>Frank Balluffi said:
>
>>As I recall LDAP does transmit the string representation of a 
>>Name (e.g., "CN=Steve Kille,O=Isode Limited,C=GB") over the 
>>wire in anOCTET STRING (or LDAPString).
>>
>
>It may not work if "stateOrProvinceName" is ever one of the fields
>transmitted between vendors. See the discrepancies from the feedback. I 
have
>concluded that there's no specification defining a formal standard for 
these
>short names. Any expected interoperability over the wire must rely on the
>OID (which was the intention in the first place?).
>
>I guess the users reading displayed certificates using this terminology 
must
>be clever and deduct based on the information on the right of the "=", or
>vendors should provide "legends" defining their use.
>
>Here is one example of discrepancy:
>In X.520:
>s               stateOrProvinceName
>
>In Peter's list:
>sp              stateOrProvinceName
>st              streetAddress
>s               surname
>
>In RFC 2253
>st              stateOrProvinceName
>
>
>Vivian
>
>
>>-----Original Message-----
>>From: Frank Balluffi [mailto:[e-mail]]
>>Sent: Friday, May 18, 2001 6:42 PM
>>To: Vivian Cancio
>>Cc: [e-mail]
>>Subject: RE: C=country; just a convention?
>>
>>
>>Vivian Cancio said:
>>
>>>I'm assuming that since it doesn't go "on the wire" it is somewhat
>>>irrelevant?
>>>
>>As I recall LDAP does transmit the string representation of a 
>>Name (e.g.,
>>"CN=Steve Kille,O=Isode Limited,C=GB") over the wire in an 
>>OCTET STRING (or
>>LDAPString). You can even roll your own AttributeTypeAndValues using
>>period-delimited attribute types and hexadecimal attribute values. For
>>example
>>
>>1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB [From RFC 2253.]
>>
>>Frank
>>






--=_alternative 006F59B985256A53_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Hi all,</font>
<br>
<br><font size=2 face="sans-serif">FWIW, the most up-to-date information regarding string forms of distinguished names, as prescribed by LDAP-related documents can be found in:</font>
<br>
<br><font size=2 face="sans-serif">&quot;Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names&quot;, Kurt Zeilenga, 04/30/2001. (19892 bytes)</font>
<br><font size=2 face="sans-serif">(http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-dn-05.txt)</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp;The X.500 Directory uses distinguished names as the primary keys to entries in the directory. Distinguished Names are encoded in ASN.1 in the X.500</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp;Directory protocols. In the Lightweight Directory Access Protocol, a string representation of distinguished names is transferred. This specification defines the</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp;string format for representing names, which is designed to give a clean representation of commonly used distinguished names, while being able to</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp;represent any distinguished name. <br>
</font>
<br><font size=2 face="sans-serif">Regards,<br>
Tim Hahn<br>
<br>
Internet: [e-mail]<br>
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)<br>
phone: [phone] &nbsp; &nbsp; tie-line: 8/852.6388<br>
fax: [phone]<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>[e-mail] (Terry Hayes)</b></font>
<br><font size=1 face="sans-serif">Sent by: [e-mail]</font>
<p><font size=1 face="sans-serif">05/21/2001 02:47 PM</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;Vivian Cancio &lt;[e-mail]&gt;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;&quot;'Frank Balluffi'&quot; &lt;[e-mail]&gt;, [e-mail]</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;Re: C=country; just a convention?</font>
<br>
<br><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp;</font></table>
<br>
<br><font size=2 face="Courier New">I believe the string representation of a Distinguished Name (DN) that we <br>
are discussing is defined by the LDAP RFCs, not by X.500 or PKIX . &nbsp;As <br>
such we should expect that the LDAP RFC would give some indication as to <br>
the proper form of the attribute type. Looking in RFC 2253, we find the <br>
following statement:<br>
<br>
 &nbsp;&quot;If the AttributeType is in a published table of attribute types <br>
associated with LDAP [4], then the type name string from that table is <br>
used, otherwise it is encoded as the dotted-decimal encoding of the <br>
AttributeType's OBJECT IDENTIFIER.&quot;<br>
<br>
The reference &quot;LDAP [4]&quot; is for RFC 2252. &nbsp;However I don't see a table <br>
of values in that document. &nbsp;RFC 2252 itself references X.520, so it may <br>
be intended that attribute type strings from that document should apply.<br>
<br>
Terry Hayes<br>
<br>
Vivian Cancio wrote:<br>
<br>
&gt;Frank Balluffi said:<br>
&gt;<br>
&gt;&gt;As I recall LDAP does transmit the string representation of a <br>
&gt;&gt;Name (e.g., &quot;CN=Steve Kille,O=Isode Limited,C=GB&quot;) over the <br>
&gt;&gt;wire in anOCTET STRING (or LDAPString).<br>
&gt;&gt;<br>
&gt;<br>
&gt;It may not work if &quot;stateOrProvinceName&quot; is ever one of the fields<br>
&gt;transmitted between vendors. See the discrepancies from the feedback. I have<br>
&gt;concluded that there's no specification defining a formal standard for these<br>
&gt;short names. Any expected interoperability over the wire must rely on the<br>
&gt;OID (which was the intention in the first place?).<br>
&gt;<br>
&gt;I guess the users reading displayed certificates using this terminology must<br>
&gt;be clever and deduct based on the information on the right of the &quot;=&quot;, or<br>
&gt;vendors should provide &quot;legends&quot; defining their use.<br>
&gt;<br>
&gt;Here is one example of discrepancy:<br>
&gt;In X.520:<br>
&gt;s &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; stateOrProvinceName<br>
&gt;<br>
&gt;In Peter's list:<br>
&gt;sp &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; stateOrProvinceName<br>
&gt;st &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; streetAddress<br>
&gt;s &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; surname<br>
&gt;<br>
&gt;In RFC 2253<br>
&gt;st &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; stateOrProvinceName<br>
&gt;<br>
&gt;<br>
&gt;Vivian<br>
&gt;<br>
&gt;<br>
&gt;&gt;-----Original Message-----<br>
&gt;&gt;From: Frank Balluffi [mailto:[e-mail]]<br>
&gt;&gt;Sent: Friday, May 18, 2001 6:42 PM<br>
&gt;&gt;To: Vivian Cancio<br>
&gt;&gt;Cc: [e-mail]<br>
&gt;&gt;Subject: RE: C=country; just a convention?<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;Vivian Cancio said:<br>
&gt;&gt;<br>
&gt;&gt;&gt;I'm assuming that since it doesn't go &quot;on the wire&quot; it is somewhat<br>
&gt;&gt;&gt;irrelevant?<br>
&gt;&gt;&gt;<br>
&gt;&gt;As I recall LDAP does transmit the string representation of a <br>
&gt;&gt;Name (e.g.,<br>
&gt;&gt;&quot;CN=Steve Kille,O=Isode Limited,C=GB&quot;) over the wire in an <br>
&gt;&gt;OCTET STRING (or<br>
&gt;&gt;LDAPString). You can even roll your own AttributeTypeAndValues using<br>
&gt;&gt;period-delimited attribute types and hexadecimal attribute values. For<br>
&gt;&gt;example<br>
&gt;&gt;<br>
&gt;&gt;1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB [From RFC 2253.]<br>
&gt;&gt;<br>
&gt;&gt;Frank<br>
&gt;&gt;<br>
<br>
<br>
<br>
</font>
<br>
<br>
--=_alternative 006F59B985256A53_=--


Received: by above.proper.com (8.9.3/8.9.3) id NAA19122 for ietf-pkix-bks; Mon, 21 May 2001 13:08:54 -0700 (PDT)
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA19109 for <[e-mail]>; Mon, 21 May 2001 13:08:48 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id IAA24449; Tue, 22 May 2001 08:08:47 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <99047572709647>; Tue, 22 May 2001 08:08:47 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: C=country; just a convention?
Cc: [e-mail], [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Tue, 22 May 2001 08:08:47 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

"Housley, Russ" <[e-mail]> writes:

>The table in RFC 2253 has a few discrepancies with your table.

Yes I know, I took the ones which are in common use.  RFC 2253 has its
definitions for things like street addresses and state or province, but other
places define them differently, and it appears that people are using the
definitions given in other places.

                    "But it izz written!" bellowed Beelzebub.
                    "But it might be written differently somewhere else" said
                        Crowley.  "Where you can't read it".
                    "In bigger letters" said Aziraphale.
                    "Underlined" Crowley added.
                    "Twice" suggested Aziraphale.
                        -- Neil Gaiman and Terry Pratchett, "Good Omens"

Peter.



Received: by above.proper.com (8.9.3/8.9.3) id LAA15650 for ietf-pkix-bks; Mon, 21 May 2001 11:47:40 -0700 (PDT)
Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA15646 for <[e-mail]>; Mon, 21 May 2001 11:47:34 -0700 (PDT)
Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id f4LIl4n00619 for <[e-mail]>; Mon, 21 May 2001 11:47:05 -0700 (PDT)
Received: from netscape.com ([192.18.121.215]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GDP86H00.LA4; Mon, 21 May 2001 11:47:05 -0700 
Message-ID: <[e-mail]>
Date: Mon, 21 May 2001 11:47:03 -0700
From: [e-mail] (Terry Hayes)
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9+) Gecko/20010326
X-Accept-Language: en
MIME-Version: 1.0
To: Vivian Cancio <[e-mail]>
CC: "'Frank Balluffi'" <[e-mail]>, [e-mail]
Subject: Re: C=country; just a convention?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I believe the string representation of a Distinguished Name (DN) that we 
are discussing is defined by the LDAP RFCs, not by X.500 or PKIX .  As 
such we should expect that the LDAP RFC would give some indication as to 
the proper form of the attribute type. Looking in RFC 2253, we find the 
following statement:

  "If the AttributeType is in a published table of attribute types 
associated with LDAP [4], then the type name string from that table is 
used, otherwise it is encoded as the dotted-decimal encoding of the 
AttributeType's OBJECT IDENTIFIER."

The reference "LDAP [4]" is for RFC 2252.  However I don't see a table 
of values in that document.  RFC 2252 itself references X.520, so it may 
be intended that attribute type strings from that document should apply.

Terry Hayes

Vivian Cancio wrote:

>Frank Balluffi said:
>
>>As I recall LDAP does transmit the string representation of a 
>>Name (e.g., "CN=Steve Kille,O=Isode Limited,C=GB") over the 
>>wire in anOCTET STRING (or LDAPString).
>>
>
>It may not work if "stateOrProvinceName" is ever one of the fields
>transmitted between vendors. See the discrepancies from the feedback. I have
>concluded that there's no specification defining a formal standard for these
>short names. Any expected interoperability over the wire must rely on the
>OID (which was the intention in the first place?).
>
>I guess the users reading displayed certificates using this terminology must
>be clever and deduct based on the information on the right of the "=", or
>vendors should provide "legends" defining their use.
>
>Here is one example of discrepancy:
>In X.520:
>s	stateOrProvinceName
>
>In Peter's list:
>sp	stateOrProvinceName
>st	streetAddress
>s	surname
>
>In RFC 2253
>st	stateOrProvinceName
>
>
>Vivian
>
>
>>-----Original Message-----
>>From: Frank Balluffi [mailto:[e-mail]]
>>Sent: Friday, May 18, 2001 6:42 PM
>>To: Vivian Cancio
>>Cc: [e-mail]
>>Subject: RE: C=country; just a convention?
>>
>>
>>Vivian Cancio said:
>>
>>>I'm assuming that since it doesn't go "on the wire" it is somewhat
>>>irrelevant?
>>>
>>As I recall LDAP does transmit the string representation of a 
>>Name (e.g.,
>>"CN=Steve Kille,O=Isode Limited,C=GB") over the wire in an 
>>OCTET STRING (or
>>LDAPString). You can even roll your own AttributeTypeAndValues using
>>period-delimited attribute types and hexadecimal attribute values. For
>>example
>>
>>1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB [From RFC 2253.]
>>
>>Frank
>>





Received: by above.proper.com (8.9.3/8.9.3) id LAA14715 for ietf-pkix-bks; Mon, 21 May 2001 11:08:30 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA14709 for <[e-mail]>; Mon, 21 May 2001 11:08:25 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Mon, 21 May 2001 11:08:37 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Mon, 21 May 2001 11:08:37 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <HR26SV55>; Mon, 21 May 2001 11:06:08 -0700
Content-return: allowed
Date: Mon, 21 May 2001 11:06:01 -0700
From: Frank Balluffi <[e-mail]>
Subject: RE: C=country; just a convention?
To: "'Vivian Cancio'" <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Vivian,

RFC 2253 is the most up-to-date standard for the string representation of a
distinguished name, which defines ST for stateOrProvinceName and STREET for
streetAddress.

X.520 does not define string representations -- it defines attributes in
ASN.1.

Peter's list is Peter's list :-).

I would go with RFC 2253.

Frank

> -----Original Message-----
> From: Vivian Cancio [mailto:[e-mail]]
> Sent: Monday, May 21, 2001 1:55 PM
> To: 'Frank Balluffi'
> Cc: [e-mail]
> Subject: RE: C=country; just a convention?
> 
> 
> Frank Balluffi said:
> 
> > As I recall LDAP does transmit the string representation of a 
> > Name (e.g., "CN=Steve Kille,O=Isode Limited,C=GB") over the 
> > wire in anOCTET STRING (or LDAPString).
> 
> It may not work if "stateOrProvinceName" is ever one of the fields
> transmitted between vendors. See the discrepancies from the 
> feedback. I have
> concluded that there's no specification defining a formal 
> standard for these
> short names. Any expected interoperability over the wire must 
> rely on the
> OID (which was the intention in the first place?).
> 
> I guess the users reading displayed certificates using this 
> terminology must
> be clever and deduct based on the information on the right of 
> the "=", or
> vendors should provide "legends" defining their use.
> 
> Here is one example of discrepancy:
> In X.520:
> s	stateOrProvinceName
> 
> In Peter's list:
> sp	stateOrProvinceName
> st	streetAddress
> s	surname
> 
> In RFC 2253
> st	stateOrProvinceName
> 
> 
> Vivian
> 
> 
> > -----Original Message-----
> > From: Frank Balluffi [mailto:[e-mail]]
> > Sent: Friday, May 18, 2001 6:42 PM
> > To: Vivian Cancio
> > Cc: [e-mail]
> > Subject: RE: C=country; just a convention?
> > 
> > 
> > Vivian Cancio said:
> > 
> > > I'm assuming that since it doesn't go "on the wire" it is somewhat
> > > irrelevant?
> > 
> > As I recall LDAP does transmit the string representation of a 
> > Name (e.g.,
> > "CN=Steve Kille,O=Isode Limited,C=GB") over the wire in an 
> > OCTET STRING (or
> > LDAPString). You can even roll your own AttributeTypeAndValues using
> > period-delimited attribute types and hexadecimal attribute 
> values. For
> > example
> > 
> > 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB [From RFC 2253.]
> > 
> > Frank
> > 
> 


Received: by above.proper.com (8.9.3/8.9.3) id KAA14072 for ietf-pkix-bks; Mon, 21 May 2001 10:55:24 -0700 (PDT)
Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA14064 for <[e-mail]>; Mon, 21 May 2001 10:55:17 -0700 (PDT)
Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19) id <JHZ8B91N>; Mon, 21 May 2001 10:55:16 -0700
Message-ID: <[e-mail]>
From: Vivian Cancio <[e-mail]>
To: "'Frank Balluffi'" <[e-mail]>
Cc: [e-mail]
Subject: RE: C=country; just a convention?
Date: Mon, 21 May 2001 10:55:15 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Frank Balluffi said:

> As I recall LDAP does transmit the string representation of a 
> Name (e.g., "CN=Steve Kille,O=Isode Limited,C=GB") over the 
> wire in anOCTET STRING (or LDAPString).

It may not work if "stateOrProvinceName" is ever one of the fields
transmitted between vendors. See the discrepancies from the feedback. I have
concluded that there's no specification defining a formal standard for these
short names. Any expected interoperability over the wire must rely on the
OID (which was the intention in the first place?).

I guess the users reading displayed certificates using this terminology must
be clever and deduct based on the information on the right of the "=", or
vendors should provide "legends" defining their use.

Here is one example of discrepancy:
In X.520:
s	stateOrProvinceName

In Peter's list:
sp	stateOrProvinceName
st	streetAddress
s	surname

In RFC 2253
st	stateOrProvinceName


Vivian


> -----Original Message-----
> From: Frank Balluffi [mailto:[e-mail]]
> Sent: Friday, May 18, 2001 6:42 PM
> To: Vivian Cancio
> Cc: [e-mail]
> Subject: RE: C=country; just a convention?
> 
> 
> Vivian Cancio said:
> 
> > I'm assuming that since it doesn't go "on the wire" it is somewhat
> > irrelevant?
> 
> As I recall LDAP does transmit the string representation of a 
> Name (e.g.,
> "CN=Steve Kille,O=Isode Limited,C=GB") over the wire in an 
> OCTET STRING (or
> LDAPString). You can even roll your own AttributeTypeAndValues using
> period-delimited attribute types and hexadecimal attribute values. For
> example
> 
> 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB [From RFC 2253.]
> 
> Frank
> 


Received: by above.proper.com (8.9.3/8.9.3) id JAA10446 for ietf-pkix-bks; Mon, 21 May 2001 09:47:33 -0700 (PDT)
Received: from indy.gradient.com ([e-mail] [192.92.110.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA10435 for <[e-mail]>; Mon, 21 May 2001 09:47:25 -0700 (PDT)
Received: from bigbird.gradient.com (bigbird.gradient.com [192.92.110.50]) by indy.gradient.com (8.9.1a/8.9.1) with ESMTP id MAA19092; Mon, 21 May 2001 12:47:22 -0400 (EDT)
Received: by BIGBIRD with Internet Mail Service (5.5.2650.10) id <LBJCTJBT>; Mon, 21 May 2001 12:52:17 -0400
Message-ID: <899128A30EEDD1118FC900A0C9C74A34BA97FD@BIGBIRD>
From: Hal Lockhart <[e-mail]>
To: "'David P. Kemp'" <[e-mail]>, Stephen Kent <[e-mail]>
Cc: [e-mail]
Subject: RE: cA flag and CRL issuers (was Re: Last Call:    draft-ietf-pki x-new-part1-06.txt comments)
Date: Mon, 21 May 2001 12:52:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

David P. Kemp wrote:
> I certainly agree that the intent of X.509, from v1 to the 
> present, was
> that a CA entity is the ultimate and sole authority for revoking the
> certificates that it issues.

I think that at least part of this debate stems from different views of
exactly what constitutes an "entity". I believe the following are implied in
messages from different people:

1. a key
2. a DN
3. a legally constituted organization

Hal


Received: by above.proper.com (8.9.3/8.9.3) id IAA07243 for ietf-pkix-bks; Mon, 21 May 2001 08:52:55 -0700 (PDT)
Received: from x007.klerer.net (ns.klerer.net [63.146.136.63]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA07235 for <[e-mail]>; Mon, 21 May 2001 08:52:48 -0700 (PDT)
Received: from BOBT21 ([10.10.10.6]) by x007.klerer.net with Microsoft SMTPSVC(5.0.2195.1600); Mon, 21 May 2001 11:51:20 -0400
From: "Robert Klerer" <[e-mail]>
To: <[e-mail]>
Subject: RE: C=country; just a convention?
Date: Mon, 21 May 2001 11:52:49 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <[e-mail]>
X-OriginalArrivalTime: 21 May 2001 15:51:20.0480 (UTC) FILETIME=[E110CA00:01C0E20D]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

And also remember that the ASN.1 in the subjectDN is written so that any
prefix is a valid entry in the directory (from x.501) -- which translates
into

c=us, o=My Company ,cn=me

While LDAP traditionally presents the cn first in the textual
representations and is generally considered the authoritative (since x.500
is silent on this issue) for the textual representation of DNs so the same
name would be:

cn=me,o=My Company,c=us

:)

Now which name will the api Certificate.SubjectDN().getName() return depends
upon how carefully that particular implementation's authors read the
standards that must be inferred.  Also note that getName() returns a String
representation and if anyone were to suggest that the ASN.1 is authoritative
please respond with a "How come getName does not return the ASN.1 DER
encoded in a byte[]?"

----


Peter:

The table in RFC 2253 has a few discrepancies with your table.

                     String  X.500 AttributeType
                     ------------------------------
                     CN      commonName
                     L       localityName
                     ST      stateOrProvinceName
                     O       organizationName
                     OU      organizationalUnitName
                     C       countryName
                     STREET  streetAddress
                     DC      domainComponent
                     UID     userid

Russ

At 12:33 PM 5/19/2001 +0000, Peter Gutmann wrote:
>Vivian Cancio <[e-mail]> writes:
>
> >I noticed that RFC 1485 is not included in the RFC 2459 references and
the
> >table (in RFC 1485) is rather limited.
>
>The short forms of DN components is another one of these "hunt the thimble"
>affairs which is even more fun than looking for OIDs.  Here are the ones
I've
>found either in common use or at least defined in only one place (ie
>they're at
>least definitely (in)accurate):
>
>Label   Component
>bc              businessCategory
>c               countryName
>cn              commonName
>d               description
>dc              domainComponent
>email   emailAddress (PKCS #9)
>g               givenName
>i               initials
>isdn    internationalISDNNumber
>l               locality
>o               organisationName
>ou              organisationalUnitName
>s               surname
>sn              serialNumber
>sp              stateOrProvinceName
>st              streetAddress
>t               title
>
>Peter.



Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA04130 for ietf-pkix-bks; Mon, 21 May 2001 07:57:50 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA04110 for <[e-mail]>; Mon, 21 May 2001 07:57:42 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA14878; Mon, 21 May 2001 10:57:25 -0400 (EDT)
Received: from reject.missi.ncsc.mil (reject.missi.ncsc.mil [144.51.60.17]) by stingray.missi.ncsc.mil with SMTP id KAA14872; Mon, 21 May 2001 10:57:23 -0400 (EDT)
Received: from 144.51.60.215 by reject.missi.ncsc.mil (InterScan E-Mail VirusWall NT); Mon, 21 May 2001 11:00:13 -0400 (Eastern Daylight Time)
Received: from missi.ncsc.mil (ara.missi.ncsc.mil [144.51.55.128]) by amx.missi.ncsc.mil with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JSFMCGBG; Mon, 21 May 2001 11:00:43 -0400
Message-ID: <[e-mail]>
Date: Mon, 21 May 2001 10:54:06 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: cA flag and CRL issuers (was Re: Last Call:    draft-ietf-pkix-new-part1-06.txt comments)
References: <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <000801c0c6a7$60e9d870$[e-mail]>	 <[e-mail]>	 <[e-mail]> <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]> <p05010406b72760acb0bf@[128.33.238.68]> <[e-mail]> <p05010403b7288eeda3d6@[128.33.238.22]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Hi Steve,

I certainly agree that the intent of X.509, from v1 to the present, was
that a CA entity is the ultimate and sole authority for revoking the
certificates that it issues.

However, Tim has proposed changing the text of PKIX to require the cA
flag to be set in every certificate whose subject is a CA entity.
Such a change is unnecessary.

The question is:

 * When a CA entity uses one public key to sign certificates
 * and a different public key to sign CRLs, must the cA flag be set
 * in the certificate containing the public key used to sign CRLs?

I say no.  David Cooper, Santosh, Sharon, Denis, Tom, and others
can answer this question explicitly for themselves; I will refrain
from interpreting their words.

----

A related discussion concerns the ability of a non-CA authority
(an AA) to sign CRLs for the non-PKCs (ACs) that it issues.
Since non-public-key X.509 certificates did not exist before v3, there
is no historical author's intent concerning the issuance and revocation
of such certificates.  But it is no stretch of the imagination to
believe that had the question been asked, the original authors would
have said that the issuer of a non-PKC is the ultimate and sole
authority for revoking that non-PKC.  In both the PKC and non-PKC
cases, the issuer of a certificate can designate or delegate a public
key to be used for revoking that certificate by setting the cRLSign bit.
The issuer's authority and ability to revoke does not depend on,
or benefit from, the existence or state of the cA flag in the
basic constraints extension.

This related discussion of historical intent is interesting, but
I am *not* calling for a straw poll to interpret historical intent,
or to write new text to clarify historical intent.

I posit that there is no need to change the text to require
the cA bit to be set in certificates used to validate CRLs containing
PKCs.  The current text does not require the cA bit to be set, and
there is no need to add such a requirement.

Dave



Stephen Kent wrote:
> 
> Dave,
> 
> We have a fundamental disagreement here. You have posited that there
> is no need to change the text to make it clear that a non-CA entity
> can sign CRLs. We have heard from Sharon, who clearly stated that the
> intent of the authors of X.509 was to impose such a requirement, and
> I think Tim said the same. Russ, I think may have concurred, even
> though he now agrees with your reasoning about what is a reasonable
> interpretation going forward.
> 
> What we have here is analogous to a lawyer proposing an
> interpretation of a law, but not being willing to examine the
> legislative history. That's simply mot acceptable. I won't argue
> whether it is appropriate to CHANGE to a scheme in which there is no
> need to check the CA flag when validating the signature on a CRL. if
> we have arrived at a consensus that this is OK, then fine. But, it is
> clearly a change relative to the expressed intent of the authors of
> previous versions of the standards and thus it merits an explicit
> change to the text of the next rev of the standards.
> 
> As per the message text cites you forwarded, I don't interpret any of
> the quotes as supportive of your contention that there is no need to
> change the text of these standards when if we drop the CA flag bit
> requirement.  Most of these messages are supportive of the change
> (some are taken out of context and so it's hard to tell even if that
> is the case).  None of these addresses the issue you raise.
> 
> So, no, I will not call for a poll on the question you pose because
> it ignores the stated intent of the authors and flies in the face of
> a reasonable interpretation of all preceding text by an intelligent
> reader.  One cannot vote to change history, and I will not conduct a
> poll to determine if people want to change history.
> 
> The only question o the table is whether we want to remove the
> implied restriction that used to exist, and thus accept the editing
> changes that it implies.
> 
> Steve


Received: by above.proper.com (8.9.3/8.9.3) id GAA27998 for ietf-pkix-bks; Mon, 21 May 2001 06:18:13 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id GAA27989 for <[e-mail]>; Mon, 21 May 2001 06:18:06 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 21 May 2001 13:17:35 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA07405; Mon, 21 May 2001 09:18:06 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <JY8NZ0PQ>; Mon, 21 May 2001 09:18:05 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.118]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JY8NZ0PM; Mon, 21 May 2001 09:18:02 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 21 May 2001 08:46:34 -0400
Subject: RE: C=country; just a convention?
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Peter:

The table in RFC 2253 has a few discrepancies with your table.

                     String  X.500 AttributeType
                     ------------------------------
                     CN      commonName
                     L       localityName
                     ST      stateOrProvinceName
                     O       organizationName
                     OU      organizationalUnitName
                     C       countryName
                     STREET  streetAddress
                     DC      domainComponent
                     UID     userid

Russ

At 12:33 PM 5/19/2001 +0000, Peter Gutmann wrote:
>Vivian Cancio <[e-mail]> writes:
>
> >I noticed that RFC 1485 is not included in the RFC 2459 references and the
> >table (in RFC 1485) is rather limited.
>
>The short forms of DN components is another one of these "hunt the thimble"
>affairs which is even more fun than looking for OIDs.  Here are the ones I've
>found either in common use or at least defined in only one place (ie 
>they're at
>least definitely (in)accurate):
>
>Label   Component
>bc              businessCategory
>c               countryName
>cn              commonName
>d               description
>dc              domainComponent
>email   emailAddress (PKCS #9)
>g               givenName
>i               initials
>isdn    internationalISDNNumber
>l               locality
>o               organisationName
>ou              organisationalUnitName
>s               surname
>sn              serialNumber
>sp              stateOrProvinceName
>st              streetAddress
>t               title
>
>Peter.


Received: by above.proper.com (8.9.3/8.9.3) id SAA21676 for ietf-pkix-bks; Fri, 18 May 2001 18:44:00 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA21672 for <[e-mail]>; Fri, 18 May 2001 18:43:55 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 18 May 2001 18:44:09 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Fri, 18 May 2001 18:44:09 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <HR26SS14>; Fri, 18 May 2001 18:41:47 -0700
Content-return: allowed
Date: Fri, 18 May 2001 18:41:46 -0700
From: Frank Balluffi <[e-mail]>
Subject: RE: C=country; just a convention?
To: Vivian Cancio <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Vivian Cancio said:

> I'm assuming that since it doesn't go "on the wire" it is somewhat
> irrelevant?

As I recall LDAP does transmit the string representation of a Name (e.g.,
"CN=Steve Kille,O=Isode Limited,C=GB") over the wire in an OCTET STRING (or
LDAPString). You can even roll your own AttributeTypeAndValues using
period-delimited attribute types and hexadecimal attribute values. For
example

1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB [From RFC 2253.]

Frank


Received: by above.proper.com (8.9.3/8.9.3) id RAA19345 for ietf-pkix-bks; Fri, 18 May 2001 17:49:08 -0700 (PDT)
Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA19324 for <[e-mail]>; Fri, 18 May 2001 17:49:01 -0700 (PDT)
Received: from postal-gw1.verisign.com (verisign.com [63.104.27.101]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id RAA28286; Fri, 18 May 2001 17:42:47 -0700 (PDT)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2653.19) id <KZSK9MDX>; Fri, 18 May 2001 17:49:01 -0700
Message-ID: <[e-mail]>
From: Alex Deacon <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: RE: C=country; just a convention?
Date: Fri, 18 May 2001 17:48:59 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

It may be also interesting to have a look at RFC 1778.  In addition you
should note that RFC 1485 and RFC 1779 have been obsoleted by RFC  2253.

Alex


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Saturday, May 19, 2001 5:34 AM
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: C=country; just a convention?
> 
> 
> Vivian Cancio <[e-mail]> writes:
> 
> >I noticed that RFC 1485 is not included in the RFC 2459 
> references and the
> >table (in RFC 1485) is rather limited.
> 
> The short forms of DN components is another one of these 
> "hunt the thimble"
> affairs which is even more fun than looking for OIDs.  Here 
> are the ones I've
> found either in common use or at least defined in only one 
> place (ie they're at
> least definitely (in)accurate):
> 
> Label	Component
> bc		businessCategory
> c		countryName
> cn		commonName
> d		description
> dc		domainComponent
> email	emailAddress (PKCS #9)
> g		givenName
> i		initials
> isdn	internationalISDNNumber
> l		locality
> o		organisationName
> ou		organisationalUnitName
> s		surname
> sn		serialNumber
> sp		stateOrProvinceName
> st		streetAddress
> t		title
> 
> Peter.
> 


Received: by above.proper.com (8.9.3/8.9.3) id RAA15513 for ietf-pkix-bks; Fri, 18 May 2001 17:33:42 -0700 (PDT)
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA15492 for <[e-mail]>; Fri, 18 May 2001 17:33:33 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id MAA03758; Sat, 19 May 2001 12:33:35 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <99023241500375>; Sat, 19 May 2001 12:33:35 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: C=country; just a convention?
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Sat, 19 May 2001 12:33:35 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Vivian Cancio <[e-mail]> writes:

>I noticed that RFC 1485 is not included in the RFC 2459 references and the
>table (in RFC 1485) is rather limited.

The short forms of DN components is another one of these "hunt the thimble"
affairs which is even more fun than looking for OIDs.  Here are the ones I've
found either in common use or at least defined in only one place (ie they're at
least definitely (in)accurate):

Label	Component
bc		businessCategory
c		countryName
cn		commonName
d		description
dc		domainComponent
email	emailAddress (PKCS #9)
g		givenName
i		initials
isdn	internationalISDNNumber
l		locality
o		organisationName
ou		organisationalUnitName
s		surname
sn		serialNumber
sp		stateOrProvinceName
st		streetAddress
t		title

Peter.



Received: by above.proper.com (8.9.3/8.9.3) id QAA03747 for ietf-pkix-bks; Fri, 18 May 2001 16:34:50 -0700 (PDT)
Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA03737 for <[e-mail]>; Fri, 18 May 2001 16:34:44 -0700 (PDT)
Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19) id <JHZ8B6H6>; Fri, 18 May 2001 16:34:42 -0700
Message-ID: <[e-mail]>
From: Vivian Cancio <[e-mail]>
To: "'Peter Williams'" <[e-mail]>, "'PKI List'" <[e-mail]>
Subject: RE: C=country; just a convention?
Date: Fri, 18 May 2001 16:34:40 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Thanks Peter,
I noticed that RFC 1485 is not included in the RFC 2459 references and the
table (in RFC 1485) is rather limited.  Also it references "X.520 keys", but
these are only examples in X.520, and the RFC incorrectly uses ST for State:

                       Key  Attribute (X.520 keys)
                        ______________________________
                        CN   CommonName
                        L    LocalityName
                        ST   StateOrProvinceName
                        O    OrganizationName
                        OU   OrganizationalUnitName
                        C    CountryName

                      Table 1:  Standardised Keywords

The example in X.520 Section 5.3.3 State or Province Name - shows the "S="
and not "ST=".

"An attribute value for State or Province Name is a string, e.g. S = "Ohio".

stateOrProvinceName  ATTRIBUTE  ::=  {
	SUBTYPE OF	name
	WITH SYNTAX	DirectoryString {ub-state-name}
	ID			id-at-stateOrProvinceName }

I'm assuming that since it doesn't go "on the wire" it is somewhat
irrelevant?

Vivian


> -----Original Message-----
> From: Peter Williams [mailto:[e-mail]]
> Sent: Friday, May 18, 2001 3:05 PM
> To: Vivian Cancio; 'PKI List'
> Subject: RE: C=country; just a convention?
> 
> 
> 
> RFC 1485
> 
> 
> -----Original Message-----
> From: Vivian Cancio [mailto:[e-mail]]
> Sent: Friday, May 18, 2001 2:18 PM
> To: 'PKI List'
> Subject: C=country; just a convention?
> 
> 
> A simple question ...
> Security applications which display certificate attributes use short
> 'acronyms' to describe the parts of the "relative distinguish 
> name" such as
> C=country, O=organization, S=state, etc.
> 
> I'm aware of the OIDs for the ASN1 structures ... I haven't found a
> description of this 'acronym' convention which is also used in X.5xx
> examples.
> 
> Is it just a de-facto convention or is it specified somewhere?
> 
> I checked just about all the X.5xx documents and I couldn't 
> find even a
> legend for the examples using this convention, ... although 
> it might be
> specified in some of the  many references. Can someone tell 
> me where they
> are defined?
> 
> Thanks,
> Vivian
> 


Received: by above.proper.com (8.9.3/8.9.3) id PAA27700 for ietf-pkix-bks; Fri, 18 May 2001 15:06:51 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA27681 for <[e-mail]>; Fri, 18 May 2001 15:06:44 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 18 May 2001 15:07:01 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Fri, 18 May 2001 15:07:01 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <HR26SRQX>; Fri, 18 May 2001 15:04:39 -0700
Content-return: allowed
Date: Fri, 18 May 2001 15:04:38 -0700
From: Peter Williams <[e-mail]>
Subject: RE: C=country; just a convention?
To: "'Vivian Cancio'" <[e-mail]>, "'PKI List'" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

RFC 1485


-----Original Message-----
From: Vivian Cancio [mailto:[e-mail]]
Sent: Friday, May 18, 2001 2:18 PM
To: 'PKI List'
Subject: C=country; just a convention?


A simple question ...
Security applications which display certificate attributes use short
'acronyms' to describe the parts of the "relative distinguish name" such as
C=country, O=organization, S=state, etc.

I'm aware of the OIDs for the ASN1 structures ... I haven't found a
description of this 'acronym' convention which is also used in X.5xx
examples.

Is it just a de-facto convention or is it specified somewhere?

I checked just about all the X.5xx documents and I couldn't find even a
legend for the examples using this convention, ... although it might be
specified in some of the  many references. Can someone tell me where they
are defined?

Thanks,
Vivian


Received: by above.proper.com (8.9.3/8.9.3) id OAA24766 for ietf-pkix-bks; Fri, 18 May 2001 14:18:20 -0700 (PDT)
Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA24762 for <[e-mail]>; Fri, 18 May 2001 14:18:14 -0700 (PDT)
Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19) id <JHZ8B58Y>; Fri, 18 May 2001 14:18:11 -0700
Message-ID: <[e-mail]>
From: Vivian Cancio <[e-mail]>
To: "'PKI List'" <[e-mail]>
Subject: C=country; just a convention?
Date: Fri, 18 May 2001 14:18:07 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

A simple question ...
Security applications which display certificate attributes use short
'acronyms' to describe the parts of the "relative distinguish name" such as
C=country, O=organization, S=state, etc.

I'm aware of the OIDs for the ASN1 structures ... I haven't found a
description of this 'acronym' convention which is also used in X.5xx
examples.

Is it just a de-facto convention or is it specified somewhere?

I checked just about all the X.5xx documents and I couldn't find even a
legend for the examples using this convention, ... although it might be
specified in some of the  many references. Can someone tell me where they
are defined?

Thanks,
Vivian



Received: by above.proper.com (8.9.3/8.9.3) id NAA18506 for ietf-pkix-bks; Fri, 18 May 2001 13:01:55 -0700 (PDT)
Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA18488 for <[e-mail]>; Fri, 18 May 2001 13:01:49 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f4IK1kj23042; Fri, 18 May 2001 13:01:46 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Minor OID mistakes in OCSPv2 and the official OID list
Date: Fri, 18 May 2001 13:01:16 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

On Saturday, May 19, 2001, at the inspiring hour of 3:30 AM, Peter Gutman
advised:

> Given that there are already certs (and lots of software)
> out there which use the current OID, wouldn't it be better
> to relocate temporalDataAuthority (what is that anyway?
> Does anyone use it? It looks like an oddly-named TSA OID).
>
> (Given that the OCSP OID is already in active use, I suspect
> {id-kp 9} will remain "the OCSP OID" even if it's officially
>  reassigned, this my comment that it's going to be easier for
> Mohammed to go to the mountain).
>
> Peter.

Peter,

Certainly a more pragmatic approach.  As a consequence I've spent some time
today searching across the various current and historical IETF work products
to do kind of an environmental impact assessment of simply re-labelling
{id-kp 9} from "id-kp-temporalDataAuthority" to "id-kp-OCSPSigning".

As it turns out, the notion of a Temporal Data Authority (TDA) and a
corresponding {id-kp 9} definition was introduced at least by
http://www.ietf.org/proceedings/99jul/I-D/draft-ietf-pkix-time-stamp-02.txt.
However, by the -14 edition the concept went away:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-14.txt.

So the path seems clear to redefine {id-kp 9} as id-kp-OCSPSigning with no
impact to timestamping implementors.  Doing so would benefit standing OCSP
implementations but does not excuse the OCSP authors, myself included, from
a swift kick in the butt for failing to coordinate across the WG on this
point.

Incidentally, it might be useful to produce the relevant OID list into a
PKIX work product so that once PKIX wraps clues are left behind how the
pieces are supposed to bolt together.

Mike


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



Received: by above.proper.com (8.9.3/8.9.3) id MAA15374 for ietf-pkix-bks; Fri, 18 May 2001 12:05:47 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA15359 for <[e-mail]>; Fri, 18 May 2001 12:05:41 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 18 May 2001 12:05:58 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Fri, 18 May 2001 12:05:58 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <HR26SPTQ>; Fri, 18 May 2001 12:03:36 -0700
Content-return: allowed
Date: Fri, 18 May 2001 12:03:35 -0700
From: Ryan Hurst <[e-mail]>
Subject: RE: Minor OID mistakes in OCSPv2 and the official OID list
To: "'Michael Myers'" <[e-mail]>, Jeff Jacoby <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Michael --

A number of existing OCSP client and server implementations (CA, ValiCert,
Kyberpass, etc) already use id-kp-OCSPSigning {id-kp 9} any changes to this
would certainly break a number of production systems. I am unsure what the
id-kp-temporalDataAuthority is used for or how broadly it is used but before
we formally change id-kp-OCSPSigning we need to explore which will effect
existing systems the least.

Ryan M. Hurst
Manager Solutions Engineering
ValiCert, Inc.
-----Original Message-----
From: Michael Myers [mailto:[e-mail]]
Sent: Thursday, May 17, 2001 5:56 PM
To: Jeff Jacoby; [e-mail]
Subject: RE: Minor OID mistakes in OCSPv2 and the official OID list


Jeff,

Thanks for the catch.  Yes, clearly the OID {id-kp 9} was assigned to
id-kp-temporalDataAuthority for EKU.  In coordination with the PKIX OID
Registrar and the IESG, we will correct this defect with the result of a new
OID for id-kp-OCSPSigning for use in EKU.

BTW, are you and/or your interoperability partners facing a need that
depends upon this feature?

Mike


Received: by above.proper.com (8.9.3/8.9.3) id MAA15294 for ietf-pkix-bks; Fri, 18 May 2001 12:05:08 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA15275 for <[e-mail]>; Fri, 18 May 2001 12:05:01 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <LFHJ39YX>; Fri, 18 May 2001 15:04:29 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: "Steve Kent (E-mail)" <[e-mail]>
Cc: "David Cooper (E-mail)" <[e-mail]>, "David Kemp (E-mail)" <[e-mail]>, [e-mail]
Subject: cA Flag -- cRLSign
Date: Fri, 18 May 2001 14:55:03 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DFCC.0BFE1FE0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0DFCC.0BFE1FE0
Content-Type: text/plain;
	charset="iso-8859-1"

Steve:

I have a compromise proposal in this area.  As Russ Housley says: In the
interest of interoperability, the generator should be strict and processor
should be forgiving (assuming no security) is compromised.

I would say let us do the following:

1.  A PKIX compliant CA must assert basicConstraints with cA set to TRUE if
cRLSign bit is set, and

2.  A PKIX compliant relying party client must check cRLSign flag in the
keyUsage extension, if keyUsage extension is present, when using the public
key of the subject to verify a signature on the CRL.  However, if the
keyUsage extension is absent, basicConstraints must be present with cA =
TRUE

Santosh Chokhani
CygnaCom Solutions, Inc.
an Entrust Technologies company
7927 Jones Branch Drive, Suite 100 West
McLean, VA 22102
[e-mail]; [e-mail]
[phone]  [phone] (fax)


------_=_NextPart_001_01C0DFCC.0BFE1FE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>cA Flag -- cRLSign</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Steve:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I have a compromise proposal in this =
area.&nbsp; As Russ Housley says: In the interest of interoperability, =
the generator should be strict and processor should be forgiving =
(assuming no security) is compromised.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I would say let us do the =
following:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">1.&nbsp; A PKIX compliant CA must =
assert basicConstraints with cA set to TRUE if cRLSign bit is set, =
and</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">2.&nbsp; A PKIX compliant relying =
party client must check cRLSign flag in the keyUsage extension, if =
keyUsage extension is present, when using the public key of the subject =
to verify a signature on the CRL.&nbsp; However, if the keyUsage =
extension is absent, basicConstraints must be present with cA =3D =
TRUE</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Santosh Chokhani</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">CygnaCom Solutions, Inc.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">an Entrust Technologies =
company</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">7927 Jones Branch Drive, Suite 100 =
West</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">McLean, VA 22102</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">[e-mail]; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">[phone]&nbsp; [phone] =
(fax)</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0DFCC.0BFE1FE0--


Received: by above.proper.com (8.9.3/8.9.3) id LAA14482 for ietf-pkix-bks; Fri, 18 May 2001 11:41:34 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA14478 for <[e-mail]>; Fri, 18 May 2001 11:41:28 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 18 May 2001 11:41:45 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]> for [e-mail]; Fri, 18 May 2001 11:41:45 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <HR26SPPC>; Fri, 18 May 2001 11:39:23 -0700
Content-return: allowed
Date: Fri, 18 May 2001 11:39:23 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: Minor OID mistakes in OCSPv2 and the official OID list
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I agree (with Peter).

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Friday, May 18, 2001 8:30 PM
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: Minor OID mistakes in OCSPv2 and the official OID list
> 
> 
> "Michael Myers" <[e-mail]> writes:
> 
> >Thanks for the catch.  Yes, clearly the OID {id-kp 9} was 
> assigned to id-kp-
> >temporalDataAuthority for EKU.  In coordination with the 
> PKIX OID Registrar
> >and the IESG, we will correct this defect with the result of 
> a new OID for id-
> >kp-OCSPSigning for use in EKU.
> 
> Given that there are already certs (and lots of software) out 
> there which use
> the current OID, wouldn't it be better to relocate 
> temporalDataAuthority (what
> is that anyway?  Does anyone use it?  It looks like an 
> oddly-named TSA OID).
> 
> (Given that the OCSP OID is already in active use, I suspect 
> {id-kp 9} will
>  remain "the OCSP OID" even if it's officially reassigned, 
> this my comment
>  that it's going to be easier for Mohammed to go to the mountain).
> 
> Peter.
> 


Received: by above.proper.com (8.9.3/8.9.3) id KAA13368 for ietf-pkix-bks; Fri, 18 May 2001 10:50:11 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id KAA13364 for <[e-mail]>; Fri, 18 May 2001 10:50:05 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 18 May 2001 17:49:38 UT
Received: from tuna.rsa.com (tuna.rsa.com [10.80.211.153]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id NAA25521; Fri, 18 May 2001 13:50:06 -0400 (EDT)
Received: from rsasecurity.com ([10.81.217.242]) by tuna.rsa.com (8.8.8+Sun/8.8.8) with ESMTP id KAA19793; Fri, 18 May 2001 10:50:49 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 18 May 2001 10:49:47 -0700
From: Jeff Jacoby <[e-mail]>
Organization: RSA Security, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: [e-mail]
Subject: Re: Minor OID mistakes in OCSPv2 and the official OID list
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Mike,

> Thanks for the catch.  Yes, clearly the OID {id-kp 9} was assigned to
> id-kp-temporalDataAuthority for EKU.  In coordination with the PKIX OID
> Registrar and the IESG, we will correct this defect with the result of a
> new
> OID for id-kp-OCSPSigning for use in EKU.

If it's possible, I would prefer id-kp-OCSPSigning remain as {id-kp 9}
and 
that id-kp-temporalDataAuthority (whatever that is) be {id-kp
somethingelse}

> BTW, are you and/or your interoperability partners facing a need that
> depends upon this feature?

We determine the response signer is an authorized signer (as opposed to 
a trusted signer) based on the presense of that OID (id-kp 9) in the 
response signer's cert.  This significantly affects how our client
validates 
the signer.  I know of at least one VA vendor that, so far, has used 
{id-dp 9} so we would have to be able to handle 2 possible values if 
id-kp-OCSPSigning gets a new value.

Jeff


Received: by above.proper.com (8.9.3/8.9.3) id KAA11957 for ietf-pkix-bks; Fri, 18 May 2001 10:20:30 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA11947 for <[e-mail]>; Fri, 18 May 2001 10:20:23 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA02302; Fri, 18 May 2001 19:20:18 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 18 May 2001 19:20:18 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id TAA18424; Fri, 18 May 2001 19:20:17 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA03728; Fri, 18 May 2001 19:20:17 +0200 (MET DST)
Date: Fri, 18 May 2001 19:20:17 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RE: Minor OID mistakes in OCSPv2 and the official OID list
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

> Given that there are already certs (and lots of software) out there which use
> the current OID, wouldn't it be better to relocate temporalDataAuthority (what
> is that anyway?  Does anyone use it?  It looks like an oddly-named TSA OID).
> 

I support Peter's view, the kp 9 is in a standards track RFC (2560), 
and the only definition of TDA is in an expired draft of timestamping, 
and this data is already obsolete.   

Also 2459 stops at kp 8 and even the new draft.


C.4. Identification of the TDA

The TDA MUST sign all temporal data tokens with a key reserved 
specifically for that purpose.  The corresponding certificate MUST 
contain the extended key usage field extension as defined in [RFC2459] 
Section 4.2.1.14 with KeyPurposeID having value 
id-kp-temporalDataAuthority.  This extension MUST be critical.

id-kp-temporalDataAuthority    OBJECT IDENTIFIER ::= {id-kp  9}
  -- Providing temporal data in support of time stamping services.  Key 
  -- usage bits that may be consistent:  digitalSignature, 
  -- nonRepudiation



Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id KAA10742 for ietf-pkix-bks; Fri, 18 May 2001 10:00:00 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA10729 for <[e-mail]>; Fri, 18 May 2001 09:59:54 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id TAA22646; Fri, 18 May 2001 19:00:02 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id SAA17306; Fri, 18 May 2001 18:59:19 +0200
Message-ID: <[e-mail]>
Date: Fri, 18 May 2001 18:58:17 +0200
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "David P. Kemp" <[e-mail]>
CC: [e-mail]
Subject: Re: Strawman on Delta CRLs
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

David,

I agree with Sabari, so I feel sorry to disagree with you.

> Sarbari,
> 
> The CRLs in the examples do not give contradictory results because CRLs
> do *not* have a validity period, they have a validity instant.

The text from X.509 (nor RFC 2459) does not say this.

Now let us look what people do in practice. They want to make sure that a
CRL is valid at the instant T. So any CRL where the following condition is
met is a good CRL.

thisUpdate < T < nextUpdate

So if an emergency CRL is issued, two CRLs will meet the condition.

For that reason it is dangerous to issue "emergency CRLs", that contain
references to non repudiation certificates, as soon as there is a key
compromise, because one party may get it, while the other may not. 

If, using a CRL mechanism, there is a need to advertise as early as possible
a key compromise then delta CRLs should be used. Delta-CRLs can be issued
much more frequently. If relying parties are informed that they MUST fetch
delta CRLs, and if there is a denial of service attack on the delta CRLs,
then relying parties must not accept the certificate: they may either reject
it if they cannot wait or if they can wait, wait until they can get access
to the delta CRLs again.
 
Denis
 
> CRL #1 is valid at 12:00.  The next CRL might be issued at
> 15:00, but it also might be issued at 12:05.
> 
> CRL #3 is valid at 14:00.
> 
> CRL #3's thisUpdate is two hours later than CRL #1's. CRL #3
> contains fresher revocation information, and it is incorrect
> to assert that that information "contradicts" the staler
> information in CRL #1.
> 
> CRLs, like OCSP responses, are valid at the instant they
> are issued, and no longer.  Relying Parties may use nextUpdate to
> determine when to look for a new CRL.  But RPs must not delude
> themselves into thinking that an old CRL is magically "valid"
> until its nextUpdate, because another CRL, delta or full, could
> have been issued seconds later.
> 
> Dave
> 
> Sarbari Gupta wrote:
> >
> > Tim, David, Russ,
> >
> > The "strawman" on the use of delta CRLs was very precise and clear - thank you. I know this thread had been discussed to death already, but I did have a comment:
> >
> > It seems counterproductive to have CRLs and delta-CRLs that are valid in parallel as in your examples. CRL #1 is valid between 12:00 and 15:00, and delta CRL #3 is valid between 14:00 and 15:00. If I am trying to validate certificate 124 at 14:30, I will get opposite results if I use CRL #1 versus delta CRL #3 - yet both are valid at the time.
> >
> > I can understand CRLs and OCSP giving different revocation status because of the different levels of latency. Why is it a good idea to have contradictory results with the same (CRL) mechanism? More importantly, why should the standard be formulated to allow such usage of CRLs, where you can have two CRLs that are both valid yet contradict each other?
> >
> > I would vote for CRLs and delta CRLs to have non-overlapping validity periods so that there is no possibility of a contradictory revocation status. If network delays are a problem, engineering solutions need to be found - the validity period of the CRL may need to be adjusted to be larger than the anticipated network delay, or the scope of the CRL may be adjusted to allow smaller-sized CRLs, or perhaps, a different revocation checking mechanism should be considered.
> >
> > - Sarbari Gupta
> > ==============================
> > Sarbari Gupta
> > Electrosoft Services, Inc.
> > Tel: [phone]
> > FAX: [phone]
> > Email: [e-mail]
> > Web: <http://www.electrosoft-inc.com/>
> > ==============================


Received: by above.proper.com (8.9.3/8.9.3) id JAA10648 for ietf-pkix-bks; Fri, 18 May 2001 09:56:24 -0700 (PDT)
Received: from zrc2s03g.nortelnetworks.com ([47.103.122.66]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA10644 for <[e-mail]>; Fri, 18 May 2001 09:56:17 -0700 (PDT)
Received: from zsc4s001.baynetworks.com (zsc4s001.baynetworks.com [134.177.3.62]) by zrc2s03g.nortelnetworks.com (8.9.3+Sun/8.9.1) with ESMTP id LAA29853 for <[e-mail]>; Fri, 18 May 2001 11:56:37 -0500 (CDT)
Received: from zsc4c000.us.nortel.com by zsc4s001.baynetworks.com; Fri, 18 May 2001 09:48:37 -0700
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19)  id <K0VN1HM5>; Fri, 18 May 2001 09:55:29 -0700
Message-ID: <[e-mail]>
From: "Kwok Lee" <[e-mail]>
To: [e-mail]
Subject: verification and encryption certificate...
Date: Fri, 18 May 2001 09:55:24 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DFBB.55409C70"
X-Orig: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0DFBB.55409C70
Content-Type: text/plain;
	charset="iso-8859-1"

Hi All, 

I am not sure whether this question has been asked before. 
If it did, please beat with me one more time.

I am a little confused by how to obtain verification and encryption
certificate using CMP. 
Is it possible to request for one certificate for signing, encryption
instead of one for each purpose ?
According to appendix B3 in rfc2510bis-03, it seems that I need to include
two CertReqMsg
in CertReqMessages. The first crm[0] is for verification certificate and the
second crm[1] for the 
encryption certificate. 

Thanks and appreciate any input on this
kc


------_=_NextPart_001_01C0DFBB.55409C70
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.59">
<TITLE>verification and encryption certificate...</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi All, </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I am not sure whether this question =
has been asked before. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">If it did, please beat with me one =
more time.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I am a little confused by how to =
obtain verification and encryption certificate using CMP. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Is it possible to request for one =
certificate for signing, encryption instead of one for each purpose =
?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">According to appendix B3 in =
rfc2510bis-03, it seems that I need to include two CertReqMsg</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">in CertReqMessages. The first crm[0] =
is for verification certificate and the second crm[1] for the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">encryption certificate. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks and appreciate any input on =
this</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">kc</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0DFBB.55409C70--


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA07401 for ietf-pkix-bks; Fri, 18 May 2001 08:56:07 -0700 (PDT)
Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA07392 for <[e-mail]>; Fri, 18 May 2001 08:56:01 -0700 (PDT)
From: [e-mail]
Subject: Re: Semantics of cRLSign (new-part1-06)?
To: "David A. Cooper" <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
Date: Fri, 18 May 2001 11:49:59 -0400
X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 05/18/2001 11:57:12 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

David,

>
>On the other hand, even if it isn't set, an RP could construct a valid
path
>
>from a trust anchor through me that acquires the cRLSign capability if I
>
>issue a self-signed certificate that asserts the bit.  Such self-signed
>
>certiicates are explicitly excluded from being limited by the
path-length
>
>constraints in the validation algorithm in new-part1-06, so such a
>
>certificate ought to be able to be inserted into any valid chain without
>
>invalidating it.
>
>
Yes. A CA can always issue a certificate to itself with whatever key
usage bits set that it wants. This is OK, >however, since the purpose of
setting the key usage bits in certificates issued to CAs is to limit the
possible >uses of the subject public key, not the CA in general.

The case I meant was that the CA would issue itself a self-signed cert
asserting the cRLSign bit, not a cert for a different key.  So the key
would no longer be limited.



>
>How about the converse: A CA certificate that includes cRLSign but not
>
>keyCertSign?  This would seem to allow a CA to delegate the ability to
sign
>
>CRLs to another entity or key which is an important operational feature.
>
>
Exactly. Imagine the example above, with the exception that different
>keys are used to sign certificates and CRLs, and the CRL signing key
>is less well protected than the certificate signing key.
>
>
>With the new text about pathLenConstraint in new-part1-06 (which
>
>incidentally is mis-spelled at "pathLengthConstraint" in the path
>
>validation section), a CRL-signing certificate shouldn't be counted
towards
>
>the maximum path length, as it's the last certificate in the chain.  But
>
>what I don't understand is what the bit buys you.  If a certificate
>
>contains a CDP extension naming entity A as the appropriate cRLIssuer,
yet
>
>the trust chain the the RP constructs that ends with A doesn't contain
the
>
>keyCertSign bit, I presume the RP is supposed to say that revocation
status
.
>can't be verified.  But how would this situation arise in practice?
>
>
The example above in which the CRL was signed using a compromised key
that
>was never intended by the CA to be used to sign CRLs works. In this case,
>the cRLSign bit not being set protects the relying party from trusting a
>CRL that was signed by an attacker.

I don't understand this.  An RP would only consider trusting a CRL if that
CRL is signed either by the certificate issuer, or by an entity named as a
CRLIssuer in the CDP extension of the certificate.  The only possible
effect of the cRLSign bit (or rather its absence) is in preventing one of
these entities from being trusted to sign CRLs.  The RP is already
protected from spoofing by random third parties.

It doesn't make sense (I think) to ever not trust a CA to sign its own
CRLs, so the only plausible effect if the cRLSign bit is on entities that
appear in the CDP extension.  Now, if the CA put some entity's name into a
certificate as a CRLIssuer, it presumably trusted that entity when it cut
the certificate.  So the only deliberate reason for there not to be a
cRLSign bit in the entity's certificate is if the CA has tried to revoke
that ability.

However, since the cRLSign bit isn't "scoped", the CRLIssuer might be an
authorized CRL signer for some other CA (it might even be a
certificate-issuing CA itself), so it might well have some other
certificate for the same key that does assert cRLSign.  So it seems like
the only plausible use of the cRLSign bit (to allow revoking of CRL-signing
ability) doesn't in fact work.



The only way that I can see that a CA could ever guarantee that it would be
able revoke the delegation of CRL signing capability is if the trust path
to that CRL-signer was restricted (by RPs) to direct trust from the CA
(i.e. the path used by an RP when validating a CRL-signer's key for the
purpose of CRL checking must include, as its final certificate, a
certificate issued by the CA, and with the cRLSign bit asserted).

The CA would also have to take responsibility for revoking such
CRL-delegation certificates itself :)



If we want to allow CAs to delegate the ability to sign CRLs to third
parties, or even to seperate keys (and there are compelling operational
reasons to do so), I think we need to add a restriction like the above on
suitable trust paths for CRL-signer validation.


John




Received: by above.proper.com (8.9.3/8.9.3) id IAA05975 for ietf-pkix-bks; Fri, 18 May 2001 08:30:33 -0700 (PDT)
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA05965 for <[e-mail]>; Fri, 18 May 2001 08:30:26 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id DAA20349; Sat, 19 May 2001 03:30:18 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <99019981831092>; Sat, 19 May 2001 03:30:18 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: Minor OID mistakes in OCSPv2 and the official OID list
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Sat, 19 May 2001 03:30:18 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

"Michael Myers" <[e-mail]> writes:

>Thanks for the catch.  Yes, clearly the OID {id-kp 9} was assigned to id-kp-
>temporalDataAuthority for EKU.  In coordination with the PKIX OID Registrar
>and the IESG, we will correct this defect with the result of a new OID for id-
>kp-OCSPSigning for use in EKU.

Given that there are already certs (and lots of software) out there which use
the current OID, wouldn't it be better to relocate temporalDataAuthority (what
is that anyway?  Does anyone use it?  It looks like an oddly-named TSA OID).

(Given that the OCSP OID is already in active use, I suspect {id-kp 9} will
 remain "the OCSP OID" even if it's officially reassigned, this my comment
 that it's going to be easier for Mohammed to go to the mountain).

Peter.



Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA05000 for ietf-pkix-bks; Fri, 18 May 2001 08:09:13 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA04995 for <[e-mail]>; Fri, 18 May 2001 08:09:06 -0700 (PDT)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id LAA22264; Fri, 18 May 2001 11:08:56 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Fri, 18 May 2001 11:08:11 -0400
To: [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: Re: Semantics of cRLSign (new-part1-06)?
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

John,

Here are my thoughts on the usefulness of the keyUsage bits in certificates issued to CAs. Others may have different (better?) thoughts on the issue.

At 02:44 PM 5/17/01 -0400, [e-mail] wrote:

>So, if I am a CA, and want to be sure that RPs will be able to check the
>revocation status of my certificates without having to install me as a
>trust anchor, I need to ensure that any cross-certificates in which I am
>named as a subject include a cRLSign key-usage?  Now, I can't force the
>other CAs to do anything special (although some request protocols would
>allow me to request that the bit be set), so this seems to be saying that,
>in order for a distributed PKI to work, the cRLSign bit ought always to be
>set in CA certificates.

Yes. I would say that if one CA is issuing a cross-certificate to another CA, that certificate should have both the keyCertSign and cRLSign key usage bits set, unless the certificate issuer knows that the subject public key will not be verify signatures on CRLs. 

>On the other hand, even if it isn't set, an RP could construct a valid path
>from a trust anchor through me that acquires the cRLSign capability if I
>issue a self-signed certificate that asserts the bit.  Such self-signed
>certiicates are explicitly excluded from being limited by the path-length
>constraints in the validation algorithm in new-part1-06, so such a
>certificate ought to be able to be inserted into any valid chain without
>invalidating it.

Yes. A CA can always issue a certificate to itself with whatever key usage bits set that it wants. This is OK, however, since the purpose of setting the key usage bits in certificates issued to CAs is to limit the possible uses of the subject public key, not the CA in general.

>So it sounds as though any CA certificate in which keyCertSign also grants
>the target CA the right to sign CRLs (which makes not setting the bit
>somewhat useless).

A CA should always be able to sign CRLs that cover the certificates that it issues. It would make no sense to allow a CA to issue certificates but prevent it from revoking those certificates through CRLs. That does not mean that not setting the bit is useless. 

Suppose that a CA maintains 2 public/private key pairs. One private key is used to sign certificates and CRLs. This private key is stored in a FIPS 140-1 Level 4 validated cryptographic module, and the certificate/CRL generating hardware along with the cryptographic module are kept off-line and are placed in a tightly secured room. The second private key is only intended to be used to sign administrative messages (e.g., S/MIME messages exchanged with other CAs to make cross-certification arrangements). This second key is stored in a FIPS 140-1 Level 1 module on a standard desktop machine that is connected to the Internet and is placed in an office with limited physical access controls.

Clearly their is a higher risk that the second private key will be compromised than that the first key will. So, the CA will arrange for the all cross certificates issued to it to include the first private key as the subject public key. This key will have the keyCertSign and cRLSign key usages set. The CA will issue itself a certificate with the second public key as the subject public key. This certificate will have the digitalSignature key usage set, but neither keyCertSign nor cRLSign will be set.

So, if an attacker manages to compromise the second private key, he will be able to sign S/MIME messages that will be trusted as having come from the CA. However, since neither the keyCertSign nor cRLSign bits were set in the certificate that certified the corresponding public key, no certificates or CRLs signed by the attacker with the compromised key will be trusted by relying parties as having been signed by the CA.

>How about the converse: A CA certificate that includes cRLSign but not
>keyCertSign?  This would seem to allow a CA to delegate the ability to sign
>CRLs to another entity or key which is an important operational feature.

Exactly. Imagine the example above, with the exception that different keys are used to sign certificates and CRLs, and the CRL signing key is less well protected than the certificate signing key.

>With the new text about pathLenConstraint in new-part1-06 (which
>incidentally is mis-spelled at "pathLengthConstraint" in the path
>validation section), a CRL-signing certificate shouldn't be counted towards
>the maximum path length, as it's the last certificate in the chain.  But
>what I don't understand is what the bit buys you.  If a certificate
>contains a CDP extension naming entity A as the appropriate cRLIssuer, yet
>the trust chain the the RP constructs that ends with A doesn't contain the
>keyCertSign bit, I presume the RP is supposed to say that revocation status
>can't be verified.  But how would this situation arise in practice?

The example above in which the CRL was signed using a compromised key that was never intended by the CA to be used to sign CRLs works. In this case, the cRLSign bit not being set protects the relying party from trusting a CRL that was signed by an attacker.

>I can think of only two possibilities: either the CA made a mistake and didn't
>set the cRLIssuer key-usage bit in the cert it issued for the CRL-signer,
>or the RP constructed the wrong chain to party A.  In the first case, the
>bit has merely served to introduce the possibility of an operational
>failure (with no benefit); the latter case can be divided into two
>sub-cases: either the key derived for A verifies the signature on the CRL
>or it doesn't.  In the latter case the absence of the cRLSign bit has
>changed nothing - the RP wouldn't have used the CRL anyway.  In the former
>case, it has again merely introduced the possibility of a spurious failure
>with no apparent benefit.
>
>Even if the chain I build to CRL-signer "A" does assert the cRLSign
>key-usage, I don't see anything that verifies whether that particular chain
>has anything to do with the CA that issued the cert that is bing checked.
>"A" might be acting as a CRL-signer for another CA as well, and the trust
>chain the the RP built happened to terminate with the CRL-signing cert
>issued by that other CA.  I don't see that it's any more appropriate to use
>some random CA's CRL-signing cert than to use a cert that doesn't assert
>cRLSign at all.

As I said in my last message, a CRL signed by CRL-signer "A" should only be trusted to provide information about certificate "B" if:

         a) CRL-signer "A" was also the issuer of certificate "B"; or

         b) certificate "B" contains a CRLDistributionPoints extension in which the cRLIssuer field is
             present and has the value "A". In this case the issuer of certificate "B" is specifically
             telling the relying party to trust CRLs signed by "A".

If neither of these conditions is met, then the relying party should not trust "A"'s CRL with respect to the status of certificate "B". It is not sufficient to find a random CA that is authorized to issue CRLs, one must only use CRLs that have been signed by CAs authorized by the certificate issuer. Once the correct CRL-issuer has been identified, the cRLSign bit can be used to determine whether a particular public key belonging to the authorized CRL-issuer can be used to verify signatures on CRLs (because if it wasn't, but the private key was used to sign CRLs anyway, this may be an indication of a key compromise).

>Hopefully I'm just overlooking something obvious, and there is a real
>function that this bit provides.
>
>John




Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id FAA24100 for ietf-pkix-bks; Fri, 18 May 2001 05:12:45 -0700 (PDT)
Received: from mailserver.exocom.com (smtp.exocom.com [216.95.175.231]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA24077 for <[e-mail]>; Fri, 18 May 2001 05:12:38 -0700 (PDT)
Received: by mailserver.alacris.com with Internet Mail Service (5.5.2653.19) id <KT2KLB9H>; Fri, 18 May 2001 08:15:21 -0400
Message-ID: <[e-mail]>
From: "Issoupov, Denis" <[e-mail]>
To: [e-mail]
Subject: Possible mistake in OCSPv2 draft
Date: Fri, 18 May 2001 08:15:20 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DF94.351CFD20"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0DF94.351CFD20
Content-Type: text/plain

 
Greetings,
 
Section 3.2.3
 
> 3.2.3  Signed Responses
>
> Response messages containing only a value for responseStatus SHALL NOT be 
> digitally signed.  Response signatures SHALL be computed over the DER
encoding 
> of the tbsRequest structure.
 
 
But in RFC2560:
 
>   The value for signature SHALL be computed on the hash of the DER
>   encoding ResponseData.
 
 
Regards,
 
Denis Issoupov
Sr. Developer,
[e-mail] <mailto:[e-mail]> 
 
Alacris, Inc.
www.alacris.com <http://www.alacris.com/> 
 
 
 

------_=_NextPart_001_01C0DF94.351CFD20
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C0DF72.39063DB0">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:35.4pt;
	mso-footer-margin:35.4pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]--><!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body bgcolor=3Dwhite lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:36.0pt'>

<div class=3DSection1>

<div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Greetings,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Section 3.2.3<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&gt; 3.2.3<span style=3D'mso-tab-count:1'>&nbsp; =
</span>Signed
Responses<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&gt;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&gt; Response messages containing only a value for =
<span
class=3DSpellE><font color=3Dred><span =
style=3D'color:red'>responseStatus</span></font></span>
SHALL NOT be <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&gt; <span class=3DGramE>digitally</span> =
signed.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>Response signatures SHALL be =
computed
over the DER encoding <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&gt; <span class=3DGramE>of</span> the <span =
class=3DSpellE><font
color=3Dred><span style=3D'color:red'>tbsRequest</span></font></span> =
structure.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>But in RFC2560:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&gt;<span style=3D'mso-spacerun:yes'>&nbsp;&nbsp; =
</span>The
value for signature SHALL be computed on the hash of the =
DER<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&gt;<span style=3D'mso-spacerun:yes'>&nbsp;&nbsp;
</span>encoding <span class=3DSpellE><font color=3Dred><span =
style=3D'color:red'>ResponseData</span></font></span>.<o:p></o:p></span>=
</font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;mso-bidi-font-size:10.0pt;color:navy'><o:p>&nb=
sp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Regards,<o:p></o:p></span></font></=
p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><span
style=3D'mso-spacerun:yes'>&nbsp;</span><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Denis =
Issoupov<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Sr. =
Developer,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><a =
href=3D"mailto:[e-mail]">[e-mail]</a><o:p></o:p></span=
></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Alacris, =
Inc.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><a =
href=3D"http://www.alacris.com/">www.alacris.com</a><o:p></o:p></span></=
font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


</div>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C0DF94.351CFD20--


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id XAA18320 for ietf-pkix-bks; Thu, 17 May 2001 23:16:17 -0700 (PDT)
Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by above.proper.com (8.9.3/8.9.3) with SMTP id XAA18246 for <[e-mail]>; Thu, 17 May 2001 23:16:01 -0700 (PDT)
Received: (qmail 30815 invoked from network); 18 May 2001 06:22:10 -0000
Received: from unknown (HELO shylock) (203.8.85.11) by arnie.adacel.com.au with SMTP; 18 May 2001 06:22:10 -0000
Reply-To: <[e-mail]>
From: "Andrew Sciberras" <[e-mail]>
To: <[e-mail]>
Subject: Possible mistake in OCSPv2 draft
Date: Fri, 18 May 2001 16:15:19 +1000
Message-ID: <000001c0df61$fa59e130$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C0DFB5.CC05F130"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C0DFB5.CC05F130
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

G'day

I think that I may have located a typo in the OCSPv2 draft.

Section 7.1 reads:
"A DPD request SHALL contain a value of id-pkix-ocsp-path-req in the
ResponseType
field of the ResponseBytes syntax.

id-pkix-ocsp-path-req   OBJECT IDENTIFIER ::= { id-pkix-ocsp X  }"

Shouldn't this be:
"A DPD request SHALL contain a value of id-pkix-ocsp-path-req in the
requestExtensions
field of TBSRequest.

id-pkix-ocsp-path-req   OBJECT IDENTIFIER ::= { id-pkix-ocsp X  }"


Cheers,
Andrew Sciberras
Software Engineer
Adacel Technologies Ltd

------=_NextPart_000_0001_01C0DFB5.CC05F130
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 5.50.4611.1300" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><SPAN class=3D544234305-18052001><FONT face=3DArial=20
size=3D2>G'day</FONT></SPAN></DIV>
<DIV><SPAN class=3D544234305-18052001><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D544234305-18052001><FONT face=3DArial size=3D2>I =
think that I may=20
have located a typo in the OCSPv2 draft.</FONT></SPAN></DIV>
<DIV><SPAN class=3D544234305-18052001><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D544234305-18052001><FONT face=3DArial =
size=3D2>Section 7.1=20
reads:</FONT></SPAN></DIV>
<DIV><SPAN class=3D544234305-18052001><FONT face=3DArial =
size=3D2>"</FONT><FONT=20
face=3DArial size=3D2>A DPD request SHALL contain a value of =
id-pkix-ocsp-path-req=20
in the ResponseType <BR>field of the ResponseBytes=20
syntax.<BR><BR>id-pkix-ocsp-path-req&nbsp;&nbsp; OBJECT IDENTIFIER ::=3D =
{=20
id-pkix-ocsp X&nbsp; }"<BR><BR>Shouldn't this be:</FONT></SPAN></DIV>
<DIV><SPAN class=3D544234305-18052001><SPAN =
class=3D544234305-18052001><FONT=20
face=3DArial size=3D2>"</FONT><FONT face=3DArial size=3D2>A DPD request =
SHALL contain a=20
value of id-pkix-ocsp-path-req in the&nbsp;<FONT=20
color=3D#ff0000>requestExtensions</FONT> <BR>field of&nbsp;<FONT=20
color=3D#ff0000>TBSRequest</FONT>.<BR><BR>id-pkix-ocsp-path-req&nbsp;&nbs=
p; OBJECT=20
IDENTIFIER ::=3D { id-pkix-ocsp X&nbsp; =
}"<BR></FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=3D544234305-18052001><SPAN =
class=3D544234305-18052001><FONT=20
face=3DArial size=3D2></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D544234305-18052001><SPAN =
class=3D544234305-18052001><FONT=20
face=3DArial size=3D2>Cheers,</FONT></SPAN></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2><STRONG>Andrew =
Sciberras</STRONG></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Software Engineer</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Adacel Technologies=20
Ltd</FONT></DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_0001_01C0DFB5.CC05F130--



Received: by above.proper.com (8.9.3/8.9.3) id RAA07905 for ietf-pkix-bks; Thu, 17 May 2001 17:56:37 -0700 (PDT)
Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA07901 for <[e-mail]>; Thu, 17 May 2001 17:56:31 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f4I0uXj09798; Thu, 17 May 2001 17:56:33 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Jeff Jacoby" <[e-mail]>, <[e-mail]>
Subject: RE: Minor OID mistakes in OCSPv2 and the official OID list
Date: Thu, 17 May 2001 17:55:59 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Jeff,

Thanks for the catch.  Yes, clearly the OID {id-kp 9} was assigned to
id-kp-temporalDataAuthority for EKU.  In coordination with the PKIX OID
Registrar and the IESG, we will correct this defect with the result of a new
OID for id-kp-OCSPSigning for use in EKU.

BTW, are you and/or your interoperability partners facing a need that
depends upon this feature?

Mike



Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id LAA15990 for ietf-pkix-bks; Thu, 17 May 2001 11:47:43 -0700 (PDT)
Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA15984 for <[e-mail]>; Thu, 17 May 2001 11:47:37 -0700 (PDT)
From: [e-mail]
Subject: Re: Semantics of cRLSign (new-part1-06)?
To: "David A. Cooper" <[e-mail]>
Cc: [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
Date: Thu, 17 May 2001 14:44:33 -0400
X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 05/17/2001 02:49:51 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

So, if I am a CA, and want to be sure that RPs will be able to check the
revocation status of my certificates without having to install me as a
trust anchor, I need to ensure that any cross-certificates in which I am
named as a subject include a cRLSign key-usage?  Now, I can't force the
other CAs to do anything special (although some request protocols would
allow me to request that the bit be set), so this seems to be saying that,
in order for a distributed PKI to work, the cRLSign bit ought always to be
set in CA certificates.

On the other hand, even if it isn't set, an RP could construct a valid path
from a trust anchor through me that acquires the cRLSign capability if I
issue a self-signed certificate that asserts the bit.  Such self-signed
certiicates are explicitly excluded from being limited by the path-length
constraints in the validation algorithm in new-part1-06, so such a
certificate ought to be able to be inserted into any valid chain without
invalidating it.

So it sounds as though any CA certificate in which keyCertSign also grants
the target CA the right to sign CRLs (which makes not setting the bit
somewhat useless).

How about the converse: A CA certificate that includes cRLSign but not
keyCertSign?  This would seem to allow a CA to delegate the ability to sign
CRLs to another entity or key which is an important operational feature.
With the new text about pathLenConstraint in new-part1-06 (which
incidentally is mis-spelled at "pathLengthConstraint" in the path
validation section), a CRL-signing certificate shouldn't be counted towards
the maximum path length, as it's the last certificate in the chain.  But
what I don't understand is what the bit buys you.  If a certificate
contains a CDP extension naming entity A as the appropriate cRLIssuer, yet
the trust chain the the RP constructs that ends with A doesn't contain the
keyCertSign bit, I presume the RP is supposed to say that revocation status
can't be verified.  But how would this situation arise in practice?  I can
think of only two possibilities: either the CA made a mistake and didn't
set the cRLIssuer key-usage bit in the cert it issued for the CRL-signer,
or the RP constructed the wrong chain to party A.  In the first case, the
bit has merely served to introduce the possibility of an operational
failure (with no benefit); the latter case can be divided into two
sub-cases: either the key derived for A verifies the signature on the CRL
or it doesn't.  In the latter case the absence of the cRLSign bit has
changed nothing - the RP wouldn't have used the CRL anyway.  In the former
case, it has again merely introduced the possibility of a spurious failure
with no apparent benefit.

Even if the chain I build to CRL-signer "A" does assert the cRLSign
key-usage, I don't see anything that verifies whether that particular chain
has anything to do with the CA that issued the cert that is bing checked.
"A" might be acting as a CRL-signer for another CA as well, and the trust
chain the the RP built happened to terminate with the CRL-signing cert
issued by that other CA.  I don't see that it's any more appropriate to use
some random CA's CRL-signing cert than to use a cert that doesn't assert
cRLSign at all.

Hopefully I'm just overlooking something obvious, and there is a real
function that this bit provides.

John



                                                                                                                      
                    "David A. Cooper"                                                                                 
                    <david.cooper@nist        To:     [e-mail]                                              
                    .gov>                     cc:     [e-mail]                                               
                    Sent by:                  Subject:     Re: Semantics of cRLSign (new-part1-06)?                   
                    owner-ietf-pkix@ma                                                                                
                    il.imc.org                                                                                        
                                                                                                                      
                                                                                                                      
                    05/16/01 04:53 PM                                                                                 
                                                                                                                      
                                                                                                                      




John,

The cRLSign bit merely indicates whether the subject public key may be used
to verify signatures on CRLs (any CRLs). If the cRLSign bit is not set, it
does not necessarily indicate that the subject of the certificate should
not be trusted to sign CRLs, it simply means that this particular public
key should not be used to verify CRLs (the subject may have other certified
public keys).

More to the point, however, the cRLSign bit is not the place to be looking
to determine who is trusted to do what. By default a CA should be trusted
to sign CRLs containing revocation information about its own certificates.
If an entity other than the certificate issuer is to sign the CRLs that
cover a certificate, the identity of that CRL issuer should be specified in
the CRLDistributionPoints extension.

So, if a certificate contains the CRLDistributionPoints extension with the
cRLIssuer field present, then the entity identified in the cRLIssuer field
should be trusted to sign the CRLs that provide revocation information for
that certificate. If the extension is not present (or is present, but the
cRLIssuer field is not), then only the certificate issuer should be trusted
to sign the CRLs.

Once the identity of the CRL signer has been determined, the cRLSign key
usage bit can be used to determine whether a particular public key
belonging to that entity should be trusted to sign CRLs.

So, technically meaning (1) below is correct (or is closest to correct).
However, one should only trust the information in a CRL about a particular
certificate if the certificate specifies that the CRL signer should be
trusted to sign the CRLs for that certificate.

At 04:02 PM 5/16/01 -0400, [e-mail] wrote:

>What are the semantics of the cRLSign bit?  Does it mean:
>1)  "The subject of this certificate should be trusted to sign (arbitrary)
>CRLs", or
>2)  "The subject of this certificate should be trusted to sign CRLs
>containing certificates signed by the subject of this certificate", or
>3)  "The subject of this certificate should be trusted to sign CRLs
>containing certificates signed by the issuer of this certificate"
>
>(1) is hopelessly vague, and (I hope) not what is intended although it is
>what a literal reading of the text seems to imply.
>(2) would allow a parent CA to create a child CA with two distinct keys,
>one of which is used for certificate signing, and the other for CRL
>signing.  But it wouldn't allow the child CA to manage its own CRL-signing
>key.  It would be possible for a child CA to issue a CRL-signing
>certificate to itself under another key, though.
>(3) explicitly permits a CA to delegate responsibility for creating its
>CRLs to another entity (or to a different key that it owns and manages
>itself), which is a useful function, and allows a CA to deal with
>revocation however it wants, and roll-over its CRL-signing key without
>having to get new certificates issued to it by parent CAs or other CAs
that
>have cross-certified it.
>
>The definition of the indirectCRL extension implies that it is possible
for
>a CRL-signer to have a different name from the name of the issuer of the
>certificates in the CRL, so this implies that (2) isn't what's meant, but
>it should be made clearer.
>
>If a CA is certified by a certificate that doesn't have the cRLSign bit
>set, does that meant that the CA shouldn't be trusted revoke certificates
>it has issued?  Or is a CA always trusted to revoke its own certificates,
>and can additionally choose to use the cRLSign bit to delegate that
ability
>to another entity or key (which would be in line with interpretation (3)
>above)?

Again, the cRLSign bit only makes a statement about the particular public
key in the certificate. Even if "a CA is certified by a certificate that
doesn't have the cRLSign bit set", there may be another certificate
(perhaps a self-signed one) issued to the CA in which the cRLSign bit is
set. Perhaps, for security reasons, the CA issues CRLs under a different
key than the one it uses to sign certificates.

>There's nothing I could see in section 6.3 of new-part1-06 (CRL
Validation)
>that says anything about cRLSign being required (or even looked at)
>anywhere along the trust path to the CRL being checked.  I think this
needs
>to be fixed.

Section 6.3 does not specify how to validate signatures on CRLs. The
general rule for validating a signature is to (1) determine which public
key needs to be used to validate the signature, (2) validate a path in
which the end certificate certificates that public key, and (3) use the
results of path validation to determine if the public key may be used for
the intended purpose (e.g., check key usage, extended key usage, policies,
etc.). This applies whether one is validating signatures on CRLs or S/MIME
messages.

Bear in mind, however, that there is no requirement to perform path
validation to validate the public key used to sign a CRL. For example, if
the CRL is to be verified using a key that belongs to one of the relying
party's trust roots (i.e., the key is contained in one of the trusted
self-signed certificates), then no path validation may be necessary, and so
there would be no key usage bits to examine.


Dave







Received: by above.proper.com (8.9.3/8.9.3) id JAA10327 for ietf-pkix-bks; Thu, 17 May 2001 09:21:58 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id JAA10319 for <[e-mail]>; Thu, 17 May 2001 09:21:51 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 17 May 2001 16:21:25 UT
Received: from tuna.rsa.com (tuna.rsa.com [10.80.211.153]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA03593 for <[e-mail]>; Thu, 17 May 2001 12:21:52 -0400 (EDT)
Received: from rsasecurity.com ([10.81.217.242]) by tuna.rsa.com (8.8.8+Sun/8.8.8) with ESMTP id JAA17756 for <[e-mail]>; Thu, 17 May 2001 09:22:35 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 17 May 2001 09:21:35 -0700
From: Jeff Jacoby <[e-mail]>
Organization: RSA Security, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Minor OID mistakes in OCSPv2 and the official OID list
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Greetings,

I believe there are two minor mistakes (or maybe just typos) in 
the OCSPv2 draft (draft-ietf-pkix-ocspv2-02) and in the "Official" 
list of PKIX OIDs.

1. Througout the draft are references to id-kp-OCSPSigning as
   
    id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}

   However, in the official list, (id-kp 9) is something
   called id-kp-temporalDataAuthority

    id-kp-temporalDataAuthority  OBJECT IDENTIFIER ::= { id-kp 9 }

   Is this a mistake in the list document?


2. In section 3.4 of the draft (and this was true in the equivilent
   section in 2560) there are two references to "id-ad-ocspSigning"
   There is no such id in the list of PKIX OIDs.

   Is this just a typo in the draft, and that id-kp-OCSPSigning was
   intended?


Regards,

Jeff
   
-- 
Jeff Jacoby, Sr. Programmer
RSA Security Inc., SMDC

2755 Campus Dr., Ste. 300       [e-mail]
San Mateo, CA  94403            [phone]


Received: by above.proper.com (8.9.3/8.9.3) id GAA25488 for ietf-pkix-bks; Thu, 17 May 2001 06:37:33 -0700 (PDT)
Received: from indy.gradient.com ([e-mail] [192.92.110.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA25480 for <[e-mail]>; Thu, 17 May 2001 06:37:27 -0700 (PDT)
Received: from bigbird.gradient.com (bigbird.gradient.com [192.92.110.50]) by indy.gradient.com (8.9.1a/8.9.1) with ESMTP id JAA19012; Thu, 17 May 2001 09:37:26 -0400 (EDT)
Received: by BIGBIRD with Internet Mail Service (5.5.2650.10) id <LBJCTFW8>; Thu, 17 May 2001 09:42:27 -0400
Message-ID: <899128A30EEDD1118FC900A0C9C74A34BA97F0@BIGBIRD>
From: Hal Lockhart <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, "David A. Cooper" <[e-mail]>
Cc: [e-mail]
Subject: RE: cA flag and CRL issuers (was Re: Last Call:   draft-ietf-pkix -new-part1-06.txt comments)
Date: Thu, 17 May 2001 09:42:26 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

>Stephen Kent wrote:

> One might be able to retain the definitions of CA and AA and add a 
> new authority, but I think it probably would be clearer to refine the 
> CA and AA definitions to make it clear that these entities may 
> explicitly authorize another, newly named authority type, to issue 
> just CRLs.

The obvious name is Revocation Authority. Unfortunately we already have an
R.A.

Hal


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id PAA07214 for ietf-pkix-bks; Wed, 16 May 2001 15:07:19 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA07201 for <[e-mail]>; Wed, 16 May 2001 15:07:12 -0700 (PDT)
Received: from [128.33.238.22] (TC077.BBN.COM [128.33.238.77]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA09814; Wed, 16 May 2001 18:07:10 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010405b728971e9066@[128.33.238.22]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <000801c0c6a7$60e9d870$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 16 May 2001 18:03:27 -0400
To: "David A. Cooper" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: cA flag and CRL issuers (was Re: Last Call:   draft-ietf-pkix-new-part1-06.txt comments)
Cc: [e-mail]
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id PAA07202
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

David,

>Steve,
>
>My interest is in ensuring that the PKIX Certificate and CRL Profile 
>is correct, consistent, and complete. If these issues are not of 
>interest to you, then feel free to ignore this message.

I wrote the first Internet standard on PKI (RFC 1422) almost 10 years 
ago. If I didn't share the goals you cite, I would not still be 
working on this stuff.  I respect your desire to make this document a 
good one, but I am frustrated by what I perceive as a very narrow 
reading of selected portions of the previous standards in support of 
your point of view re one aspect of this topic.

>
>At 06:45 PM 5/15/01 -0400, Stephen Kent wrote:
>>Dave,
>>
>>I provided an analysis of the evolution of CRL signing from V1 + V2 
>>certs, to the changes you cite re V3 certs.
>
>As far as I am concerned, v1 and v2 is irrelevant. Extensions did 
>not exist prior to v3, so neither v1 nor v2 could have included any 
>requirements with respect to the proper setting of the cA bit in the 
>basicConstraints extension.

I cite the previous versions only because they establish context for 
v3. Note that ITU has a strong tradition of not making changes that 
are not backward compatible. Evidence of that abounds. Thus, it is 
appropriate to interpret each revised version of an ITU standard in 
such a context.

>  >You have chosen to ignore large parts of this analysis, and focus 
>on text in the current version of X.509 that emphasizes syntactic 
>details but not the larger semantic context.
>
>We are discussing the cA bit. I have quoted the text from X.509 that 
>provides the semantics for the cA bit numerous times. You have 
>chosen to ignore this text.

As I noted in my response to Dave Kemp, you are arguing like a lawyer 
who tries to build a case around one fragment of a law, ignoring the 
legislative history that expresses the intent of the lawmakers. 
Sharon's message several weeks ago clearly stated that intent.

>  >You have not adressed the fact that both X.509 and RFC 2459 make 
>repeated references to "authorities" or CAs re CRL issuance. You 
>have received feedback from Sharon, and I think several of the 2459 
>authors have weighed in on this topic during the multi-week debate.
>>
>>I see no point in continuing the discussion.
>
>
>Based on the discussions that have occurred in this thread it seems 
>to me that there are a number of issues in X.509 and PKIX that need 
>to be resolved:
>
>
>1) Who can issue CRLs?
>
>          a) There seems to be consensus that it is acceptable for an 
>entity that does
>              not sign certificates to sign CRLs.
>
>          b) There has been suggestion that the standards only allow 
>for authorities to issue CRLs.

It's more than a suggestion; it is a well-documented intent of the 
authors' of the standards in question.

>
>          c) X.509 defines an authority as "[a]n entity, responsible 
>for the issuance of certificates.
>               Two types are defined in this Specification; 
>certification authority which issues public-key
>              certificates and attribute authority which issues 
>attribute certificates."
>
>              X.509 similarly defines an CA as "An authority trusted 
>by one or more users to create and
>              assign public-key certificates. Optionally the 
>certification authority may create the users’ keys."
>              An attribute authority is defined to be "[a]n authority 
>which assigns privileges by issuing
>              attribute certificates".
>
>      So, if we wish to allow entities to sign CRLs but not 
>certificates, we either need to allow for entities
>      other than authorities to issue CRLs or we need to redefine the 
>terms CA, AA, and authority to include
>      include entities that do not issue certificates.

One might be able to retain the definitions of CA and AA and add a 
new authority, but I think it probably would be clearer to refine the 
CA and AA definitions to make it clear that these entities may 
explicitly authorize another, newly named authority type, to issue 
just CRLs.

>2) In which directory attributes should certificates that are issued 
>to subjects that are CAs be placed?
>
>          a) RFC 2587 states that certificates issued to end entities 
>must be placed in the userCertificate
>              attribute and that certificates issued to CAs must be 
>placed in the cACertificate and/or
>              crossCertificatePair attributes (with specific rules on 
>when each of these attributes is to
>              be populated).
>
>          b) RFC 2587 also states  that "none of the ... CA 
>certificates shall include a basicConstraints
>              extension with the cA value set to FALSE".
>
>          c) There has been no consensus that the cA value in 
>basicConstraints must be set to TRUE
>              whenever the certificate subject is a CA. This lack of 
>consensus is particularly the case
>              when the certificate contains a keyUsage extension with 
>neither the keyCertSign nor the
>              cRLSign bit set. (I believe that Tim Polk has proposed 
>changing the standards to require
>              the cA value to be set to TRUE whenever the subject is 
>a CA, but there has been no
>              consensus that such a change should  be made).

agreed, this is still unresolved.

>      So, either we need to change X.509 and PKIX to state that the 
>cA bit in basicConstraints indicates
>      whether the certificate subject is a CA or LDAP schema needs to 
>be clarified to clearly indicate in
>      which attribute(s) certificates issued to CAs should be placed 
>when basicConstraints is present but
>      cA is set to FALSE (e.g., if the subject public key is used to 
>sign CMP transactions, but not to sign
>      certificates or CRLs).

This is a valid concern, relevant to how we decide the CA flag issue. 
Have we adequately addressed the problem of where to place the cert 
used to verify a CRL under the circumstances that we're exploring?

>What does the cA bit in basicConstraints mean?
>
>      As a result of the changes from new-part1-05 to new-part1-06, 
>the text in the PKIX profile describing
>      the cA bit is contradictory. It states: "The cA bit indicates 
>if the certified public key may be used to
>      verify signatures on other certificates. If the cA bit is 
>asserted, then either the keyCertSign bit or the
>      cRLSign bit in the key usage extension (see 4.2.1.3) MUST also 
>be asserted."
>
>      The first sentence, which is essentially copied from X.509, 
>states that the bit indicates whether the
>      subject public key may be used to verify signatures on 
>certificates. The next sentence, however,
>      seems to contradict this by stating that the cA bit may be set 
>to TRUE even if the subject public key
>      may not be used to verify signatures on certificates (if the 
>subject public key may be used to verify
>      signatures on CRLs).

yes, the text in question needs to be made consistent. one could do 
so in several ways, one of which would be to change the definition of 
the CA flag.

>      Of course, if there were a requirement to only set the cRLSign 
>bit in KeyUsage if the keyCertSign bit
>      is also set, then there would be no contradiction. If this were 
>the case, then the cA bit really would
>      indicate is the subject public key may be used to verify 
>signatures on certificates. However, there has
>      certainly been agreement that it should be acceptable to 
>specify that a key may be used to verify
>      signatures on CRLs but not certificates. So, we must either 
>revert to the new-part1-05 text which
>      clearly ties the cA bit to the keyCertSign bit, or we must 
>redefine the cA bit in both X.509 and PKIX.

yes, there is consensus that we want to be able to have a key that is 
used to verify CRLs but not certs.

>There may be other issues that I am not recalling at the moment.
>
>We need to step back and try to view this standard from the 
>perspective of someone who is new to X.509. We cannot expect that 
>everyone who makes use of the X.509 standard will have read through 
>all of the messages on the PKIX mailing list. If the X.509 
>certificate generation and processing rules can not be unambiguously 
>determined from the written standards, then the standards need to be 
>fixed. Arguments to the effect of "the standard says X, but it 
>really means Y, and to see why Y is the correct interpretation 
>you'll need to read the relevant discussions from the PKIX mailing 
>list from April of 1998." Similarly, claims that people should 
>somehow determine the processing rules by looking at the "larger 
>semantic context" instead of "text in the current version of X.509 
>that emphasizes syntactic details" are unacceptable. If the 
>syntactic details are incorrect, then we should fix them. We can not 
>have a standard that provides incorrect "syntactic details" and then 
>expect people !
>!
>!
>to correctly implement the standard based on an interpretation of 
>the "larger semantic context".

I agree that it should not be necessary for people to read the 
background material to understand a standard, but it is quite 
reasonable to expect people creating a revised version of the 
standard to be cognizant of such background.

I agree that the current standards (X.509 and RFC 2459) have proven 
to be somewhat ambiguous with regard to the issue of what class of 
entities are allowed to issue CRLs. You and others have cited text 
that, if read in isolation, supports the notion that a non-CA entity 
could sign a CRL. However, this text is not consistent with the 
persistent, repeated references to CAs (or CAs and AAs) as the issuer 
of CRLs that appear throughout the standards in question. So, I don't 
agree that the ambiguity is a great as you assert. Nonetheless, we 
both agree that the goal is to move forward with a new version that 
is unambiguous.

I'm looking to the 2459 editors to propose text that is consistent, 
allows for separate keys for cert and CRL signing, and that makes it 
clear what class of entity is authorized to sign CRLs for certs 
issued by a specified CA. Given the extent of the analysis that we 
have endured, it is clear that the new reader of the document should 
not be expected to infer correct answer to this last question if we 
merely state in the context of the definition of the CA flag that it 
need not be asserted in a cert used to verify a CRL. There are too 
many places where we refer to CAs (and AAs in X.509) as the entities 
who sign CRLs.

I said earlier that I can live with a change to the specs, a 
clarification if you prefer, that makes it explicit that we wish to 
state that non-CA entities can be authorized to sign CRLs. But, I 
also noted that we have to agree to make the changes throughout the 
document to make this clear, and that amounts to a lot of editing. 
Also, we it would be preferable to get our X.509 friends to agree to 
these changes, so that we remain in synch. As I have said several 
time before, I prefer the original intent as articulated by the 
authors of these documents, but I can live with the change so long as 
we are very explicit about that change.

Steve



Received: by above.proper.com (8.9.3/8.9.3) id PAA07199 for ietf-pkix-bks; Wed, 16 May 2001 15:07:10 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA07191 for <[e-mail]>; Wed, 16 May 2001 15:07:04 -0700 (PDT)
Received: from [128.33.238.22] (TC077.BBN.COM [128.33.238.77]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA09773; Wed, 16 May 2001 18:06:56 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010403b7288eeda3d6@[128.33.238.22]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <000801c0c6a7$60e9d870$[e-mail]>	 <[e-mail]>	 <[e-mail]> <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]> <p05010406b72760acb0bf@[128.33.238.68]> <[e-mail]>
Date: Wed, 16 May 2001 16:41:02 -0400
To: "David P. Kemp" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: cA flag and CRL issuers (was Re: Last Call:    draft-ietf-pkix-new-part1-06.txt comments)
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Dave,

We have a fundamental disagreement here. You have posited that there 
is no need to change the text to make it clear that a non-CA entity 
can sign CRLs. We have heard from Sharon, who clearly stated that the 
intent of the authors of X.509 was to impose such a requirement, and 
I think Tim said the same. Russ, I think may have concurred, even 
though he now agrees with your reasoning about what is a reasonable 
interpretation going forward.

What we have here is analogous to a lawyer proposing an 
interpretation of a law, but not being willing to examine the 
legislative history. That's simply mot acceptable. I won't argue 
whether it is appropriate to CHANGE to a scheme in which there is no 
need to check the CA flag when validating the signature on a CRL. if 
we have arrived at a consensus that this is OK, then fine. But, it is 
clearly a change relative to the expressed intent of the authors of 
previous versions of the standards and thus it merits an explicit 
change to the text of the next rev of the standards.

As per the message text cites you forwarded, I don't interpret any of 
the quotes as supportive of your contention that there is no need to 
change the text of these standards when if we drop the CA flag bit 
requirement.  Most of these messages are supportive of the change 
(some are taken out of context and so it's hard to tell even if that 
is the case).  None of these addresses the issue you raise.

So, no, I will not call for a poll on the question you pose because 
it ignores the stated intent of the authors and flies in the face of 
a reasonable interpretation of all preceding text by an intelligent 
reader.  One cannot vote to change history, and I will not conduct a 
poll to determine if people want to change history.

The only question o the table is whether we want to remove the 
implied restriction that used to exist, and thus accept the editing 
changes that it implies.


Steve


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA06499 for ietf-pkix-bks; Wed, 16 May 2001 14:57:53 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA06472 for <[e-mail]>; Wed, 16 May 2001 14:57:46 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <LBMBN8D9>; Wed, 16 May 2001 17:57:18 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: Semantics of cRLSign (new-part1-06)?
Date: Wed, 16 May 2001 17:47:55 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DE51.DDB22210"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0DE51.DDB22210
Content-Type: text/plain;
	charset="iso-8859-1"

I will not speak for X.509 or for pkix.  But from my humble notion of
security, a trust anchor can do whatever it pleases.  After that, if the key
usage extension is present in a certificate and is marked critical, and does
NOT have cRLSign bit set, the public key in the certificate MAY NOT be used
to verify a signature on a CRL.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Wednesday, May 16, 2001 4:02 PM
To: [e-mail]
Subject: Semantics of cRLSign (new-part1-06)?



Reading through the treatment of CRLs in the new-part1-06, plus the earlier
discussions including the one about path length constraints that petered
out without an obvious resolution, I realized I am completely confused by
the whole topic :)    So I'm going to try to ask the major questions I have
in individual messages.


What are the semantics of the cRLSign bit?  Does it mean:
1)  "The subject of this certificate should be trusted to sign (arbitrary)
CRLs", or
2)  "The subject of this certificate should be trusted to sign CRLs
containing certificates signed by the subject of this certificate", or
3)  "The subject of this certificate should be trusted to sign CRLs
containing certificates signed by the issuer of this certificate"

(1) is hopelessly vague, and (I hope) not what is intended although it is
what a literal reading of the text seems to imply.
(2) would allow a parent CA to create a child CA with two distinct keys,
one of which is used for certificate signing, and the other for CRL
signing.  But it wouldn't allow the child CA to manage its own CRL-signing
key.  It would be possible for a child CA to issue a CRL-signing
certificate to itself under another key, though.
(3) explicitly permits a CA to delegate responsibility for creating its
CRLs to another entity (or to a different key that it owns and manages
itself), which is a useful function, and allows a CA to deal with
revocation however it wants, and roll-over its CRL-signing key without
having to get new certificates issued to it by parent CAs or other CAs that
have cross-certified it.

The definition of the indirectCRL extension implies that it is possible for
a CRL-signer to have a different name from the name of the issuer of the
certificates in the CRL, so this implies that (2) isn't what's meant, but
it should be made clearer.

If a CA is certified by a certificate that doesn't have the cRLSign bit
set, does that meant that the CA shouldn't be trusted revoke certificates
it has issued?  Or is a CA always trusted to revoke its own certificates,
and can additionally choose to use the cRLSign bit to delegate that ability
to another entity or key (which would be in line with interpretation (3)
above)?


There's nothing I could see in section 6.3 of new-part1-06 (CRL Validation)
that says anything about cRLSign being required (or even looked at)
anywhere along the trust path to the CRL being checked.  I think this needs
to be fixed.


John


------_=_NextPart_001_01C0DE51.DDB22210
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Semantics of cRLSign (new-part1-06)?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I will not speak for X.509 or for pkix.&nbsp; But =
from my humble notion of security, a trust anchor can do whatever it =
pleases.&nbsp; After that, if the key usage extension is present in a =
certificate and is marked critical, and does NOT have cRLSign bit set, =
the public key in the certificate MAY NOT be used to verify a signature =
on a CRL.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: [e-mail] [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>=

<BR><FONT SIZE=3D2>Sent: Wednesday, May 16, 2001 4:02 PM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Semantics of cRLSign (new-part1-06)?</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Reading through the treatment of CRLs in the =
new-part1-06, plus the earlier</FONT>
<BR><FONT SIZE=3D2>discussions including the one about path length =
constraints that petered</FONT>
<BR><FONT SIZE=3D2>out without an obvious resolution, I realized I am =
completely confused by</FONT>
<BR><FONT SIZE=3D2>the whole topic :)&nbsp;&nbsp;&nbsp; So I'm going to =
try to ask the major questions I have</FONT>
<BR><FONT SIZE=3D2>in individual messages.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>What are the semantics of the cRLSign bit?&nbsp; Does =
it mean:</FONT>
<BR><FONT SIZE=3D2>1)&nbsp; &quot;The subject of this certificate =
should be trusted to sign (arbitrary)</FONT>
<BR><FONT SIZE=3D2>CRLs&quot;, or</FONT>
<BR><FONT SIZE=3D2>2)&nbsp; &quot;The subject of this certificate =
should be trusted to sign CRLs</FONT>
<BR><FONT SIZE=3D2>containing certificates signed by the subject of =
this certificate&quot;, or</FONT>
<BR><FONT SIZE=3D2>3)&nbsp; &quot;The subject of this certificate =
should be trusted to sign CRLs</FONT>
<BR><FONT SIZE=3D2>containing certificates signed by the issuer of this =
certificate&quot;</FONT>
</P>

<P><FONT SIZE=3D2>(1) is hopelessly vague, and (I hope) not what is =
intended although it is</FONT>
<BR><FONT SIZE=3D2>what a literal reading of the text seems to =
imply.</FONT>
<BR><FONT SIZE=3D2>(2) would allow a parent CA to create a child CA =
with two distinct keys,</FONT>
<BR><FONT SIZE=3D2>one of which is used for certificate signing, and =
the other for CRL</FONT>
<BR><FONT SIZE=3D2>signing.&nbsp; But it wouldn't allow the child CA to =
manage its own CRL-signing</FONT>
<BR><FONT SIZE=3D2>key.&nbsp; It would be possible for a child CA to =
issue a CRL-signing</FONT>
<BR><FONT SIZE=3D2>certificate to itself under another key, =
though.</FONT>
<BR><FONT SIZE=3D2>(3) explicitly permits a CA to delegate =
responsibility for creating its</FONT>
<BR><FONT SIZE=3D2>CRLs to another entity (or to a different key that =
it owns and manages</FONT>
<BR><FONT SIZE=3D2>itself), which is a useful function, and allows a CA =
to deal with</FONT>
<BR><FONT SIZE=3D2>revocation however it wants, and roll-over its =
CRL-signing key without</FONT>
<BR><FONT SIZE=3D2>having to get new certificates issued to it by =
parent CAs or other CAs that</FONT>
<BR><FONT SIZE=3D2>have cross-certified it.</FONT>
</P>

<P><FONT SIZE=3D2>The definition of the indirectCRL extension implies =
that it is possible for</FONT>
<BR><FONT SIZE=3D2>a CRL-signer to have a different name from the name =
of the issuer of the</FONT>
<BR><FONT SIZE=3D2>certificates in the CRL, so this implies that (2) =
isn't what's meant, but</FONT>
<BR><FONT SIZE=3D2>it should be made clearer.</FONT>
</P>

<P><FONT SIZE=3D2>If a CA is certified by a certificate that doesn't =
have the cRLSign bit</FONT>
<BR><FONT SIZE=3D2>set, does that meant that the CA shouldn't be =
trusted revoke certificates</FONT>
<BR><FONT SIZE=3D2>it has issued?&nbsp; Or is a CA always trusted to =
revoke its own certificates,</FONT>
<BR><FONT SIZE=3D2>and can additionally choose to use the cRLSign bit =
to delegate that ability</FONT>
<BR><FONT SIZE=3D2>to another entity or key (which would be in line =
with interpretation (3)</FONT>
<BR><FONT SIZE=3D2>above)?</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>There's nothing I could see in section 6.3 of =
new-part1-06 (CRL Validation)</FONT>
<BR><FONT SIZE=3D2>that says anything about cRLSign being required (or =
even looked at)</FONT>
<BR><FONT SIZE=3D2>anywhere along the trust path to the CRL being =
checked.&nbsp; I think this needs</FONT>
<BR><FONT SIZE=3D2>to be fixed.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>John</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0DE51.DDB22210--


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA06299 for ietf-pkix-bks; Wed, 16 May 2001 14:55:13 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA06273 for <[e-mail]>; Wed, 16 May 2001 14:55:06 -0700 (PDT)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id RAA04660; Wed, 16 May 2001 17:55:06 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Wed, 16 May 2001 17:54:08 -0400
To: Denis Pinkas <[e-mail]>
From: "David A. Cooper" <[e-mail]>
Subject: Re: delta CRLs
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Denis,

It appears that the concerns you expressed below are not specifically related to the use of delta-CRLs, but are instead related to the use of CRLs in general. You seem to be suggesting that, in order to support non-repudiation, CRLs must be issued in a certain way and that you want to require that CRLs only be issued in a manner that supports non-repudiation. While I do not agree that all PKIs should be required to support the special needs of non-repudiation, I will set aside that issue for the moment.

Even if I were to agree that CRLs must be issued in a manner that supports non-repudiation, I would still disagree with the requirements you propose for the following reasons:

1) You state that any two CRLs issued for a given scope must not have overlapping validity periods (where the validity period of a CRL is defined as [thisUpdate ... nextUpdate]). This is troubling for two reasons:

         a) As Trevor Freeman has pointed out, there may be significant delays between the
             time that a CRL is issued and when it is available in repositories. If the validity
             periods of CRLs can not overlap, then there will be gaps (periods of time in which
             no valid CRL is available to relying parties). This is not acceptable.

         b) If a CRL issuer discovers that a private key has been compromised, your requirements,
             by not allowing the issuing of an "emergency" CRL, would require the CRL issuer to
             hide the compromise of the private key from relying parties until the end of the validity
             period of the currently valid CRL. While this would ensure that all relying parties receive
             the same information, it would also ensure that all relying parties receive incorrect
             information. Does this really help to support non-repudiation?

2) You state that in a non-repudiation dispute, the issue would be settled by using CRLs or OCSP responses to determine the status of the certificate at some time T and that all possible methods of determining that status at time T must provide the same result. You did not state when time T should be. Time T could either be the time that the signature was created or the time that the signature is being validated. Since the signature could be validated at different times, it seems that the only way to ensure consistency is make time T the time that the signature was created.

You state that one should use a CRL for which thisUpdate <= T <= nextUpdate.  This, however, contradicts the requirements stated in "Internet X.509 Public Key Infrastructure Technical Requirements for a non-Repudiation Service" (http://www.ietf.org/internet-drafts/draft-ietf-pkix-technr-03.txt). According to this draft, in order to make a final judgement about the validity of a signature, one must use a CRL that has a thisUpdate time later than the time at which the signature was created (i.e, T <= thisUpdate). If one follows these guidelines, then consistency is assured.  If the certificate was revoked at the time that the signature was created (T), then it will appear as revoked on any CRL issued after time T (at least until the certificate expires) with a revocationDate <= T.  So, following the rules in the draft document on non-repudiation, one will always receive a consistent answer as to the status of the certificate, even if the CRL issuer creates "emergency" CRLs.


Perhaps you believe that the draft document on non-repudiation does not accurately reflect the requirements for supporting non-repudiation. If this is the case, though, then any necessary changes should be made to that document, not to the text in the Certificate and CRL profile on how to use delta-CRLs.

At 06:58 PM 5/11/01 +0200, Denis Pinkas wrote:
>The thread has been focussing on the mechanisms, forgetting what is the
>rational about them. So let us come back to the rationals. One of them
>relates top the use of CRLs when applied to a non repudiation service.
>
>X.509 has been originally written to use CRLs for other security services
>and for these other services, the problems are different.
>
>We all want to be able to use either CRLs or OSCP responses for non
>repudiation purposes. In fact we want to allow any of these two techniques
>to be used in single or in combination. Right ?
>
>Having said this, we can now explain some of the rational. 
>
>When validating a digital signature, for a given time T, for non repudiation
>purposes, it is important for a verifier to be able to prove that the
>certificate was NOT revoked. It is also important that two different
>verifiers come to the same result, for the same time T, because of the goal
>of non repudiation is to solve disputes.

The only way to determine whether a certificate was revoked at time T is to use a CRL that was issued after time T (i.e., T <= thisUpdate). If the certificate was revoked at time T, any CRL issued after time T will state that. The rules that you propose, on the other hand (thisUpdate <= T <= nextUpdate), would not achieve the result that you claim to desire.

Perhaps the rules should instead state that in order to determine the status of a certificate at time T, one should obtain a CRL whose scope includes the certificate for which T <= thisUpdate (in the CRL) < notAfter (in the certificate). If the certificate is not listed or is listed with a revocationDate > T, then the certificate was not revoked at time T.

>The same properties must be achieved whether OCSP or CRLs are used. When an
>OCSP response is received with a time T in it, there can be no dispute about
>it: it contains three possible answers (not revoked, revoked, don't know).
>If an OCSP responder produces one such answer with a time T and one of the
>three statuses, no one else can present an answer with the same time T in it
>with a different answer from the same OCSP responder. Once again, it would
>not be acceptable that at a given time T two opposite responses could be
>obtained. This would result in disputes.

Actually, this is not technically correct. There is no guarantee that an OCSP response that is received at time T was generated at time T. An OCSP response contains three fields: thisUpdate, nextUpdate, and producedAt. Any response received by a relying party for which T < nextUpdate should be considered a good response. However, there is no guarantee that the producedAt time is after the time at which the request was made. Furthermore, even if it were, the thisUpdate time in the response could precede the producedAt time. So, again, a response from an OCSP server at time T that states that a certificate is "not revoked" only guarantees that the status was "not revoked" at time thisUpdate. It is not a guarantee about the certificate's status at time T if T > thisUpdate.

>This means that at time T, there is must be one and only one possible
>answer. This allows to use OCSP responses for non repudiation purposes. The
>same property must be supported so that CRLs can be used for non repudiation
>purposes. So the goal is that when using CRLs in the context of non
>repudiation, only one response (i.e. not revoked, revoked, don't know) can
>be obtained.
>
>I do know that non repudiation is only one use of the PKI and that there are
>other usages such as authentication, integrity and confidentiality. So let
>us now describe what is necessary, if the CRL contains at least one
>certificate that can be used for non repudiation purposes (e.g. it has the
>NR bit set).
>
>If at time T there is more than one CRL valid, then there is a possibility
>to miss the most recent, in case there is a denial of service attack on it
>(i.e. suppression of the latest CRL while in transit).
>
>This means that "emergency" CRLs will not necessarily be seen. "Emergency"
>CRLs may be used for authentication, integrity and confidentiality, but may
>create problems when used in the context of non repudiation.
>
>This has several implications: we should deprecate the use of "emergency"
>CRLs for being used for a non repudiation service, because they could
>provide two different responses. 
>
>People using full CRLs, i.e. without taking advantage of the delta CRLs,
>would get only one result.
>
>People using base CRLs and thus taking advantage of the delta CRLs would
>also get one single result. For that reason we should also deprecate the use
>of "emergency" delta CRLs.
>
>This now explains why it is important to get one answer, at most, at a time.
>I do understand that lacking this information, the mechanism seems to be
>constrained without any "good" reason.
>
>Now how can a verifier be sure to get the freshest information ?
>
>This depends on the verification rules. Let us restrict the discussion to
>the leaf certificate.
>
>If the validation rules (be careful this has strong relationships with the
>DPV protocol) say : "use full CRLs only" and there is no "emergency CRL",
>then everything works nice.
>
>If the validation rules say: "use the freshest information that is provided
>by the CA", then the question is how can a verifier know how the freshest
>information is obtained ? The answer is: only through extensions. Why ?
>
>Let us assume first that no extension either in the certificate or the CRL
>is being used. The answer would be : make a search for delta CRLs in the
>directory. The problem is that, in case a denial of service attack, the
>delta CRLs, even if they exist, will not be "seen". So the verifier will use
>the base CRL and thus two verifications done at the same time T will provide
>two different results. :-(
>
>So there needs to be some way, so that, in the event of a denial of service
>attacks, either the right information is obtained or that no information at
>all is obtained. In the later case, if the revocation information is not
>found, then the signature is not accepted (in some cases a try can be done
>later on).
>
>A consequence is the following: verifiers must know without ambiguity
>whether a delta CRL mechanism is supported, so that if delta CRL are
>supported it is possible to know unambiguously that it is the case. 
>
>There are two options. 
>
>1) Should we use the freshestCRL extension from the leaf certificate ? This
>means that the CA MUST support delta CRLs at any time during whole the
>life-time of the certificate. This is quite constraining for the CA, but
>this is possible.
>
>2) Should we use the freshestCRL extension from the CRL? This means that the
>CA will only support delta CRLs for that CRL without any engagement to
>support a delta CRL mechanism for the next one. This is more flexible.
>
>What does this means ? That it is very likely that we will not end up wit
>the same mechanism when using delta CRLs for a certificate used for non
>repudiation purposes and when using a certificate for other purposes. One of
>the algorithms may look first at the delta CRLs, whether they exist or not,
>while the other will only take a look for them after making sure that they
>must exit.
>
>The best guess, if it succeeds, is certainly valid for "other purposes". So
>I will now focus on the algorithm to be used for non repudiation purposes.
>
>    An application that is willing to obtain the freshest CRL 
>    information for a given certificate used for non repudiation 
>    purposes, must know if a delta CRL mechanism is supported. 
>    Either the certificate or any CRL that is able to reference 
>    that certificate MUST include a freshestCRL extension 
>    (a.k.a. a Delta CRL distribution point). 
>
>    The application may then construct an updated CRL for that 
>    base, for a specific time T, by combining it with a delta 
>    CRL which contains a delta CRL indicator extension with the 
>    same CRL number as the base CRL. Applications that support 
>    delta CRLs MUST ensure that time T falls between thisUpdate 
>    and nextUpdate for both the base CRL and the delta CRL.
>
>    Note: An application could also reconstruct an updated CRL, 
>    for a specific time T, by using a previously locally 
>    reconstructed CRL based on the current base CRL, and 
>    combining it with a delta CRL which contains a delta CRL 
>    indicator extension with the same CRL number as the base 
>    CRL.
>
>For the constraint about the CA:
>
>    For any CRL that may reference a certificate used for 
>    non repudiation purposes, and for any time T until 
>    the nextUpdate time indicated in a base CRL, the CA MUST 
>    provide one and only one base CRL and one and only delta 
>    CRL that refers to that base CRL and for which time T 
>    falls between thisUpdate and nextUpdate from the delta CRL.
>
>There are still other issues to discuss, like the CRL numbering,
>whether it is unique or not, let us wait for next week for that topic.
>
>Regards,
>
>Denis




Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA27508 for ietf-pkix-bks; Wed, 16 May 2001 13:54:49 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA27490 for <[e-mail]>; Wed, 16 May 2001 13:54:43 -0700 (PDT)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id QAA27971; Wed, 16 May 2001 16:54:29 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Wed, 16 May 2001 16:53:35 -0400
To: [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: Re: Semantics of cRLSign (new-part1-06)?
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

John,

The cRLSign bit merely indicates whether the subject public key may be used to verify signatures on CRLs (any CRLs). If the cRLSign bit is not set, it does not necessarily indicate that the subject of the certificate should not be trusted to sign CRLs, it simply means that this particular public key should not be used to verify CRLs (the subject may have other certified public keys).

More to the point, however, the cRLSign bit is not the place to be looking to determine who is trusted to do what. By default a CA should be trusted to sign CRLs containing revocation information about its own certificates. If an entity other than the certificate issuer is to sign the CRLs that cover a certificate, the identity of that CRL issuer should be specified in the CRLDistributionPoints extension.

So, if a certificate contains the CRLDistributionPoints extension with the cRLIssuer field present, then the entity identified in the cRLIssuer field should be trusted to sign the CRLs that provide revocation information for that certificate. If the extension is not present (or is present, but the cRLIssuer field is not), then only the certificate issuer should be trusted to sign the CRLs.

Once the identity of the CRL signer has been determined, the cRLSign key usage bit can be used to determine whether a particular public key belonging to that entity should be trusted to sign CRLs.

So, technically meaning (1) below is correct (or is closest to correct). However, one should only trust the information in a CRL about a particular certificate if the certificate specifies that the CRL signer should be trusted to sign the CRLs for that certificate.

At 04:02 PM 5/16/01 -0400, [e-mail] wrote:

>What are the semantics of the cRLSign bit?  Does it mean:
>1)  "The subject of this certificate should be trusted to sign (arbitrary)
>CRLs", or
>2)  "The subject of this certificate should be trusted to sign CRLs
>containing certificates signed by the subject of this certificate", or
>3)  "The subject of this certificate should be trusted to sign CRLs
>containing certificates signed by the issuer of this certificate"
>
>(1) is hopelessly vague, and (I hope) not what is intended although it is
>what a literal reading of the text seems to imply.
>(2) would allow a parent CA to create a child CA with two distinct keys,
>one of which is used for certificate signing, and the other for CRL
>signing.  But it wouldn't allow the child CA to manage its own CRL-signing
>key.  It would be possible for a child CA to issue a CRL-signing
>certificate to itself under another key, though.
>(3) explicitly permits a CA to delegate responsibility for creating its
>CRLs to another entity (or to a different key that it owns and manages
>itself), which is a useful function, and allows a CA to deal with
>revocation however it wants, and roll-over its CRL-signing key without
>having to get new certificates issued to it by parent CAs or other CAs that
>have cross-certified it.
>
>The definition of the indirectCRL extension implies that it is possible for
>a CRL-signer to have a different name from the name of the issuer of the
>certificates in the CRL, so this implies that (2) isn't what's meant, but
>it should be made clearer.
>
>If a CA is certified by a certificate that doesn't have the cRLSign bit
>set, does that meant that the CA shouldn't be trusted revoke certificates
>it has issued?  Or is a CA always trusted to revoke its own certificates,
>and can additionally choose to use the cRLSign bit to delegate that ability
>to another entity or key (which would be in line with interpretation (3)
>above)?

Again, the cRLSign bit only makes a statement about the particular public key in the certificate. Even if "a CA is certified by a certificate that doesn't have the cRLSign bit set", there may be another certificate (perhaps a self-signed one) issued to the CA in which the cRLSign bit is set. Perhaps, for security reasons, the CA issues CRLs under a different key than the one it uses to sign certificates.

>There's nothing I could see in section 6.3 of new-part1-06 (CRL Validation)
>that says anything about cRLSign being required (or even looked at)
>anywhere along the trust path to the CRL being checked.  I think this needs
>to be fixed.

Section 6.3 does not specify how to validate signatures on CRLs. The general rule for validating a signature is to (1) determine which public key needs to be used to validate the signature, (2) validate a path in which the end certificate certificates that public key, and (3) use the results of path validation to determine if the public key may be used for the intended purpose (e.g., check key usage, extended key usage, policies, etc.). This applies whether one is validating signatures on CRLs or S/MIME messages.

Bear in mind, however, that there is no requirement to perform path validation to validate the public key used to sign a CRL. For example, if the CRL is to be verified using a key that belongs to one of the relying party's trust roots (i.e., the key is contained in one of the trusted self-signed certificates), then no path validation may be necessary, and so there would be no key usage bits to examine.


Dave




Received: by above.proper.com (8.9.3/8.9.3) id NAA23336 for ietf-pkix-bks; Wed, 16 May 2001 13:05:53 -0700 (PDT)
Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA23322 for <[e-mail]>; Wed, 16 May 2001 13:05:44 -0700 (PDT)
From: [e-mail]
Subject: Semantics of cRLSign (new-part1-06)?
To: [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
Date: Wed, 16 May 2001 16:02:24 -0400
X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 05/16/2001 04:07:59 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Reading through the treatment of CRLs in the new-part1-06, plus the earlier
discussions including the one about path length constraints that petered
out without an obvious resolution, I realized I am completely confused by
the whole topic :)    So I'm going to try to ask the major questions I have
in individual messages.


What are the semantics of the cRLSign bit?  Does it mean:
1)  "The subject of this certificate should be trusted to sign (arbitrary)
CRLs", or
2)  "The subject of this certificate should be trusted to sign CRLs
containing certificates signed by the subject of this certificate", or
3)  "The subject of this certificate should be trusted to sign CRLs
containing certificates signed by the issuer of this certificate"

(1) is hopelessly vague, and (I hope) not what is intended although it is
what a literal reading of the text seems to imply.
(2) would allow a parent CA to create a child CA with two distinct keys,
one of which is used for certificate signing, and the other for CRL
signing.  But it wouldn't allow the child CA to manage its own CRL-signing
key.  It would be possible for a child CA to issue a CRL-signing
certificate to itself under another key, though.
(3) explicitly permits a CA to delegate responsibility for creating its
CRLs to another entity (or to a different key that it owns and manages
itself), which is a useful function, and allows a CA to deal with
revocation however it wants, and roll-over its CRL-signing key without
having to get new certificates issued to it by parent CAs or other CAs that
have cross-certified it.

The definition of the indirectCRL extension implies that it is possible for
a CRL-signer to have a different name from the name of the issuer of the
certificates in the CRL, so this implies that (2) isn't what's meant, but
it should be made clearer.

If a CA is certified by a certificate that doesn't have the cRLSign bit
set, does that meant that the CA shouldn't be trusted revoke certificates
it has issued?  Or is a CA always trusted to revoke its own certificates,
and can additionally choose to use the cRLSign bit to delegate that ability
to another entity or key (which would be in line with interpretation (3)
above)?


There's nothing I could see in section 6.3 of new-part1-06 (CRL Validation)
that says anything about cRLSign being required (or even looked at)
anywhere along the trust path to the CRL being checked.  I think this needs
to be fixed.


John




Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA19917 for ietf-pkix-bks; Wed, 16 May 2001 12:08:55 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA19910 for <[e-mail]>; Wed, 16 May 2001 12:08:47 -0700 (PDT)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id PAA09190; Wed, 16 May 2001 15:08:45 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 16 May 2001 15:06:30 -0400
To: <[e-mail]>, "Tim Polk" <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: RE: Strawman on Delta CRLs
Cc: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Sarbari,

Having CRLs and delta-CRLs that are valid in parallel is a *feature*. 
<smile>  It may be reasonable in some applications to accept CRLs that are 
updated relatively infrequently.  Other applications may demand the 
freshest information available.  By including the freshestCRL extension in 
a CRL, the relying party can determine which category they fall in and 
decide if they should retrieve the delta.  This lets the relying party 
manage the risk according to the threat it faces.

However, a CA that wants to maintain control can do so.  If a CA wishes to 
ensure that all parties use the freshest information possible, they can 
always issue a full CRL simultaneously with each delta.  In this case, the 
full CRLs are valid for relatively short periods, and clients that cannot 
process delta CRLs may consume a lot of network bandwidth downloading full 
CRLs.

There are tradeoffs with both approaches (i.e., relying party control vs. 
CA control).  The algorithms described in the delta CRL strawman have the 
flexibility to support local requirements.  I think that is the right choice.

BTW, I do not accept the notion that OCSP requests and CRL processing 
inherently provides different latency to the relying party.  Since most 
OCSP servers obtain certificate status information in the form of CRLs, the 
information obtained by relying parties has the same latency regardless of 
the source.  Where an OCSP server and CA are the same system, the latency 
will be different.  However, this is a theoretical distinction since (most? 
all?) OCSP servers are separate systems.

Thanks,

Tim

At 11:02 AM 5/16/01 -0400, Sarbari Gupta wrote:
>Tim, David, Russ,
>
>The "strawman" on the use of delta CRLs was very precise and clear - thank 
>you. I know this thread had been discussed to death already, but I did 
>have a comment:
>
>It seems counterproductive to have CRLs and delta-CRLs that are valid in 
>parallel as in your examples. CRL #1 is valid between 12:00 and 15:00, and 
>delta CRL #3 is valid between 14:00 and 15:00. If I am trying to validate 
>certificate 124 at 14:30, I will get opposite results if I use CRL #1 
>versus delta CRL #3 - yet both are valid at the time.
>
>I can understand CRLs and OCSP giving different revocation status because 
>of the different levels of latency. Why is it a good idea to have 
>contradictory results with the same (CRL) mechanism? More importantly, why 
>should the standard be formulated to allow such usage of CRLs, where you 
>can have two CRLs that are both valid yet contradict each other?
>
>I would vote for CRLs and delta CRLs to have non-overlapping validity 
>periods so that there is no possibility of a contradictory revocation 
>status. If network delays are a problem, engineering solutions need to be 
>found - the validity period of the CRL may need to be adjusted to be 
>larger than the anticipated network delay, or the scope of the CRL may be 
>adjusted to allow smaller-sized CRLs, or perhaps, a different revocation 
>checking mechanism should be considered.
>
>- Sarbari Gupta
>==============================
>Sarbari Gupta
>Electrosoft Services, Inc.
>Tel: [phone]
>FAX: [phone]
>Email: [e-mail]
>Web: <http://www.electrosoft-inc.com/>
>==============================
>
>-----Original Message-----
>From: [e-mail]
>[mailto:[e-mail]]On Behalf Of Tim Polk
>Sent: Friday, May 11, 2001 3:07 PM
>To: [e-mail]
>Subject: Strawman on Delta CRLs
>
>
>
>Folks,
>
>David Cooper, Russ Housley and I have collaborated on a "strawman"
>describing the use of delta CRLs in PKIX implementations.  We believe the
>functionality we describe is consistent with ISO X.509 as well.
>
>The text describes algorithms for using deltas and base CRLs to (a) check
>the status of a certificate or (b) create a constructed CRL.  This is
>followed by three scenarios for the use of deltas - "traditional deltas",
>"sliding window deltas", and a variant on sliding window deltas that
>factors in the real world delays in populating repositories with base and
>delta CRLs.
>
>I have appended the strawman below in ASCII text.  The text includes tables
>for the examples.  Please note, these tables *require* a fixed font to be
>legible.  If you would prefer a copy in either Word or PDF, I have posted
>them at the following URLs:
>http://csrc.nist.gov/pki/documents/PKIX/PKIXdeltas.doc and
>http://csrc.nist.gov/pki/documents/PKIX/PKIXdeltas.pdf
>
>Hopefully, this strawman will serve to frame further discussions and
>accelerate consensus.   Once we agree on the requirements, Russ and I will
>draft the necessary changes and we can finish Last Call.  (I am nothing if
>not an optimist.)
>
>We would also like to add the examples as an *informative* appendix in
>son-of-2459.
>
>Thanks,
>
>Tim Polk
>
>
>--------------------------------strawman---------------------------
>
>Implementing Delta CRLs Using PKIX
>
>This paper addresses the use of delta CRLs in PKIX-compliant systems.
>This paper assumes that delta CRLs include the delta CRL indicator
>extension (rather than a CRL scope extension) and ignores
>complications involving combined delta CRLs from indirect CRL issuers.
>
>This paper also assumes that CRLs with different scopes are distributed
>using different distribution points.
>
>Terms
>
>Revoked: A statement that a particular certificate's status has changed
>and it should no longer be trusted.  Once a certificate is revoked, it
>is always revoked.
>
>Suspension: A statement that a particular certificate may not be
>trustworthy. Once placed on hold, a certificate may be revoked or the
>suspension may be lifted.
>
>Revocation notice: A statement that a particular certificate has been
>suspended or revoked.  The revocation statement identifies the certificate
>by the issuer name and serial number.  The issuer may be specified
>explicitly or implicitly. The issuer may be explicitly identified using
>the certificate issuer extension. If not specified explicitly, the issuer
>of the certificate is implicitly identified as the issuer of the CRL. A
>revocation notice includes the date and time the certificate was revoked.
>A revocation notice may optionally include a revocation reason in the
>reason code CRL entry extension. [Note: A revocation notice may optionally
>specify in the invalidity date extension the date from which the
>certificate should be considered invalid.  This date may precede the actual
>revocation date.  The invalidity date extension does not feature in this
>discussion, so it is not considered further in this paper.]
>
>Certificate revocation list (CRL):  a list of revocation notices for
>certificates.
>
>CRL scope: the set of certificates that could appear on a given CRL.
>For example, the scope may be "all certificates issued by CA X", "all
>CA and end entity certificates issued by CA X", "all certificates issued
>by CA X that have been revoked for key compromise and CA compromise", or
>may be a set of certificates based on local information, such as "all
>certificates issued to the NIST employees located in Boulder".
>
>Full CRL: a CRL that lists all unexpired certificates, in its scope, that
>have been revoked for one of the revocation reasons covered by the scope
>of the CRL. The scope of a full CRL does not necessarily include all of
>the certificates issued by a CA or all possible revocation reasons.
>
>Base CRL:  the particular CRL used as the foundation for a delta CRL.  The
>base must be a full CRL.
>
>Delta CRL:  a CRL that only lists those unexpired certificates, in its scope,
>whose revocation status has changed since the issuance of a particular,
>referenced base CRL. The scope of a delta CRL is must be the same as the base
>CRL that it references
>
>CRL Numbering
>
>A CRL issuer may generate full CRLs for more than one scope.  The CRL issuer
>may also generate delta CRLs.  Each delta CRLs must have the same scope as the
>full CRL referenced as its base.
>
>For each scope supported by the CRL issuer, a numbering sequence must be
>maintained.  For each scope, the CRLs are numbered in a monotonically
>increasing
>sequence.  (Wrapping is not permitted in the PKIX profile.)  If a CRL issuer
>generates CRLs for one scope (e.g., full CRLs and deltas CRLs), the issuer 
>must
>maintain one numbering sequence.  If a delta CRL and a full CRL that cover the
>same scope are issued at the same time, they will have the same CRL number.
>
>If a CRL issuer generates CRLs for two scopes (e.g., one covering CA
>certificates and one covering end entity certificates), then the CRL issuer
>must
>maintain two number sequences.  The CRLs and deltas for the same scope
>(e.g., CA
>certificates) will share one numbering sequence.  The CRLs and deltas for the
>second scope (e.g., end entity certificates) will share one numbering
>sequence.
>There is no requirement that these sequences be disjoint.
>
>Algorithms for Determining Status from a Full CRL and a Delta CRL
>
>Consider a full CRL, F, with CRL number X.  A client may obtain BF in 
>either of
>the following ways:
>(a) the full CRL F may have been pushed to the client or pulled from a
>repository; or
>(b) F may have been constructed from a full CRL and a delta CRL using this
>algorithm.
>
>Consider a delta CRL, D, which specifies base CRL Y and has CRL number 
>Z.  This
>means that all certificates whose statuses have changed since the issuance
>of CRL Y
>will be listed on the delta CRL.  Note that the PKIX profile requires the
>CA to issue
>CRL Y as a full CRL.
>
>Determining Whether a Full CRL and Delta CRL May Be Combined
>
>F and D may be combined if each of the following conditions are met:
>
>(1)     X is greater than or equal to Y.  That is, the full CRL must (at a 
>minimum)
>contain all the revocation information held by the referenced base CRL.
>(2)     X is less than Z.  That is, the delta CRL must cover some time 
>that was not
>covered by the full CRL.
>
>Determining Status of a Certificate from a Full CRL and a Delta CRL
>
>If the PKI client maintains the delta and full CRL, the status of an unexpired
>certificate C may be determined as follows:
>
>(1)     If C is listed on the delta CRL, then:
>a.      If C is listed on the delta CRL with reason code "removeFromCRL", 
>then C
>is not revoked.
>b.      Otherwise, certificate C is revoked.
>(2)     If C was not listed on the delta CRL, then the full CRL is 
>checked, and the
>status is as follows:
>a.      If C is listed on the full CRL, then C is revoked.
>b.      If C is not listed on the full CRL, then C is not revoked.
>
>Combining a Full CRL and Delta CRL into a Constructed CRL
>
>If the PKI client maintains the current CRL in a local cache:
>
>The revocation information on F is assumed as the initial condition.  F is
>a list
>of revoked certificates; each certificate is listed with a revocation reason
>(which may be "unspecified").
>
>The list of revoked certificates L with n entries denoted as L[i] where 1
><= i <= n.
>(The value n may shrink or grow as the combination process proceeds.)
>
>Initialize L to the revocation notices on F.  For each certificate C on the
>delta CRL,
>update the contents of L as follows.
>
>If a certificate C appears on the delta CRL, and C is not currently in the
>list L,
>then:
>(a)     if C has a revocation reason other than "removeFromCRL", add C as 
>a new
>entry
>in  the list of revoked certificates L.
>(b)     If C has revocation reason "removeFromCRL", skip this 
>certificate.  No
>update
>to the cache is needed.
>
>If a certificate C appears on the delta CRL, and C is presently listed in L
>as entry
>L[i], then:
>(a)     If C is listed on the delta CRL with a revocation reason of
>"removeFromCRL",
>delete entry L[i]
>(b)     If C is listed on the delta CRL without a revocation reason or with a
>revocation
>reason other than "removeFromCRL", change the reason code associated with
>L[i] to the
>reason code specified in the delta CRL.
>
>The combination of F and D forms a new full CRL with CRL number Z.  This
>full CRL has
>complete information until the time specified in the next update field in
>the delta CRL
>is reached.  If a relying party is validating a certificate with respect to
>time T, and
>T is before the next update field in the delta CRL, they may assume
>complete information.
>
>If an unexpired certificate C within the scope of the constructed CRL is
>not listed, then
>certificate C is not revoked for one of the revocation reasons covered by
>this CRL.  If
>the constructed CRL covers all reasons, then the certificate C is not revoked.
>
>Using Deltas to Distribute Revocation Information
>
>This section provides three different scenarios for the use of delta
>CRLs.  For the
>purpose of these examples, assume a goal of providing revocation
>information to relying
>parties that is no more than one hour old.
>
>The following notation is used to denote a revoked certificate on a CRL:
>                 Xr      certificate X is listed for reason r, where r in 
> {a,k,h,r}
>The reason codes {a,k,h,r} correspond to "affiliation changed", "key
>compromise",
>"certificate hold", and "remove from CRL" respectively.
>
>(Note:  The remaining reason codes are omitted for simplicity.  The 
>handling of
>certificates revoked for  the reasons "unspecified", "CA compromise",
>"superseded", and
>"cessationOfOperation" are identical to "affiliation changed or "key
>compromise").
>
>
>
>Example #1
>
>The example below shows the "traditional" method of issuing delta CRLs.
>In this example, full CRLs are issued once every 3 hours and deltas are
>issued once an hour. For consistency, the issuer begins issuing deltas
>at the same time as the very first full CRL. After that, however, a delta
>can always use a previously issued full CRL as its base. Notice that
>starting with cRLNumber 4, the delta CRL issued at the same time as a
>full CRL uses the previously issued full CRL as its base. However, the
>delta-CRLs never provide more than 3 hours of history.
>
>In this example:
>Certificate 14 was revoked for key compromise before 12:00 when the first
>CRL was issued.
>Certificate 124 was revoked for key compromise between 12:00 and 13:00.
>Certificate 39 was placed on hold between 14:00 and 15:00, and its
>suspension was lifted between 16:00 and 17:00.
>Certificate 67 was revoked for an affiliation change between 16:00 and
>17:00.  The reason was changed to key compromise between 18:00 and 19:00.
>
>current  | Revoked      | Full CRL                 | Delta-CRL
>time     | certificates |                          |
>---------|--------------|--------------------------|----------------------
>12:00    | {14k}        | cRLNumber = 1            | cRLNumber = 1
>           |              | thisUpdate = 12:00       | thisUpdate =
>12:00
>           |              | nextUpdate = 15:00       | nextUpdate = 13:00
>           |              | CertificateList = {14k}  | BaseCRLNumber = 1
>           |              |                          | CertificateList =
>{}
>---------|--------------|--------------------------|----------------------
>13:00    | {14k, 124k}  |                          | cRLNumber = 2
>           |              |                          | thisUpdate = 13:00
>           |              |                          | nextUpdate = 14:00
>           |              |                          | BaseCRLNumber = 1
>           |              |                          | CertificateList = 
> {124k}
>---------|--------------|--------------------------|----------------------
>14:00    | {14k, 124k}  |                          | cRLNumber = 3
>           |              |                          | thisUpdate = 14:00
>           |              |                          | nextUpdate = 15:00
>           |              |                          | BaseCRLNumber = 1
>           |              |                          | CertificateList = 
> {124k}
>---------|--------------|--------------------------|----------------------
>15:00    | {14k, 124k,  | cRLNumber = 4            | cRLNumber = 4
>           |   39h}       | thisUpdate = 15:00       | thisUpdate =
>15:00
>           |              | nextUpdate = 18:00       | nextUpdate = 16:00
>           |              | CertificateList =        | BaseCRLNumber = 1
>           |              |  {14k, 124k, 39h}        | CertificateList =
>           |              |                          | {124k, 39h}
>---------|--------------|--------------------------|----------------------
>16:00    | {14k, 124k,  |                          | cRLNumber = 5
>           |   39h, 67a}  |                          | thisUpdate = 16:00
>           |              |                          | nextUpdate = 17:00
>           |              |                          | BaseCRLNumber = 4
>           |              |                          | CertificateList = {67a}
>           |              |                          |
>---------|--------------|--------------------------|----------------------
>17:00    | {14k, 124k,  |                          | cRLNumber = 6
>           |   67a}       |                          | thisUpdate = 17:00
>           |              |                          | nextUpdate = 18:00
>           |              |                          | BaseCRLNumber = 4
>           |              |                          | CertificateList =
>           |              |                          | {39r, 67a}
>---------|--------------|--------------------------|----------------------
>18:00    | {14k, 124k,  | cRLNumber = 7            | cRLNumber = 7
>           |   67a}       | thisUpdate = 18:00       | thisUpdate =
>18:00
>           |              | nextUpdate = 21:00       | nextUpdate = 19:00
>           |              | CertificateList =        | BaseCRLNumber = 4
>           |              | {14k, 124k, 67a}         | CertificateList =
>           |              |                          | {39r,
>67a}
>---------|--------------|--------------------------|----------------------
>19:00    | {14k, 124k,  |                          | cRLNumber = 8
>           |   67k}       |                          | thisUpdate = 19:00
>           |              |                          | nextUpdate = 20:00
>           |              |                          | BaseCRLNumber = 7
>           |              |                          | CertificateList = {67k}
>---------|--------------|--------------------------|----------------------
>
>Scenario #2
>
>The example below shows the "sliding window" method of issuing delta-CRLs.
>In this example, full CRLs are issued once every 3 hours and deltas are
>issued once an hour. For consistency, the issuer begins issuing deltas at
>the same time as the very first full CRL. Notice that starting with
>cRLNumber 7, the delta CRL issued at the same time as a full CRL does not
>use the previously issued full CRL as its base but the preceding CRL instead.
>However, these delta-CRLs never provide more than 6 hours of history.
>
>As in example #1:
>Certificate 14 was revoked for key compromise before 12:00 when the first
>CRL was issued.
>Certificate 124 was revoked for key compromise between 12:00 and 13:00.
>Certificate 39 was placed on hold between 14:00 and 15:00, and its
>suspension was lifted between
>16:00 and 17:00.
>Certificate 67 was revoked for an affiliation change between 16:00 and 17:00.
>The reason was changed to key compromise between 18:00 and 19:00.
>
>current  | Revoked      | Full CRL                 | Delta-CRL
>time     | certificates |                          |
>---------|--------------|--------------------------|----------------------
>12:00    | {14k}        | cRLNumber = 1            | cRLNumber = 1
>           |              | thisUpdate = 12:00       | thisUpdate =
>12:00
>           |              | nextUpdate = 15:00       | nextUpdate = 13:00
>           |              | CertificateList = {14k}  | BaseCRLNumber = 1
>           |              |                          | CertificateList =
>{}
>---------|--------------|--------------------------|----------------------
>13:00    | {14k, 124k}  |                          | cRLNumber = 2
>           |              |                          | thisUpdate = 13:00
>           |              |                          | nextUpdate = 14:00
>           |              |                          | BaseCRLNumber = 1
>           |              |                          | CertificateList = 
> {124k}
>---------|--------------|--------------------------|----------------------
>14:00    | {14k, 124k}  |                          | cRLNumber = 3
>           |              |                          | thisUpdate = 14:00
>           |              |                          | nextUpdate = 15:00
>           |              |                          | BaseCRLNumber = 1
>           |              |                          | CertificateList = 
> {124k}
>---------|--------------|--------------------------|----------------------
>15:00    | {14k, 124k,  | cRLNumber = 4            | cRLNumber = 4
>           |   39h}       | thisUpdate = 15:00       | thisUpdate =
>15:00
>           |              | nextUpdate = 18:00       | nextUpdate = 16:00
>           |              | CertificateList =        | BaseCRLNumber = 1
>           |              |  {14k, 124k, 39h}        | CertificateList =
>           |              |                          | {124k, 39h}
>---------|--------------|--------------------------|----------------------
>16:00    | {14k, 124k,  |                          | cRLNumber = 5
>           |   39h, 67a}  |                          | thisUpdate = 16:00
>           |              |                          | nextUpdate = 17:00
>           |              |                          | BaseCRLNumber = 1
>           |              |                          | CertificateList =
>           |              |                          | {124k, 39h, 67a}
>---------|--------------|--------------------------|----------------------
>17:00    | {14k, 124k,  |                          | cRLNumber = 6
>           |   67a}       |                          | thisUpdate = 17:00
>           |              |                          | nextUpdate = 18:00
>           |              |                          | BaseCRLNumber = 1
>           |              |                          | CertificateList =
>           |              |                          | {124k, 39h, 67a}
>---------|--------------|--------------------------|----------------------
>18:00    | {14k, 124k,  | cRLNumber = 7            | cRLNumber = 7
>           |   67a}       | thisUpdate = 18:00       | thisUpdate =
>18:00
>           |              | nextUpdate = 21:00       | nextUpdate = 19:00
>           |              | CertificateList =        | BaseCRLNumber = 1
>           |              | {14k, 124k, 67a}         | CertificateList =
>           |              |                          | {124k, 39r, 67a}
>---------|--------------|--------------------------|----------------------
>19:00    | {14k, 124k,  |                          | cRLNumber = 8
>           |   67k}       |                          | thisUpdate = 19:00
>           |              |                          | nextUpdate = 20:00
>           |              |                          | BaseCRLNumber = 7
>           |              |                          | CertificateList =
>           |              |                          | {39r, 67k
>---------|--------------|--------------------------|----------------------
>
>
>Note that the delta CRLs are marginally larger than in the first scenario
>since they cover a longer time period.  On the other hand, a relying party
>is less likely to download full CRLs in the second scenario.
>
>For example, a relying party that validated one certificate at 12:15, then
>a second certificate at 16:15 would not require a new full CRL in scenario #2.
>In scenario #1, the relying party would be forced to obtain both full CRL 4
>and delta CRL 5.
>
>Scenario #3 Allowing for Replication/Propagation Delays
>
>In this scenario, full CRLs and delta CRLs are replicated throughout a
>repository system.  Data is replicated through the system at different
>rates based on the size of the file.  The CA operators estimate that full
>CRLs will be available throughout the system within three hours.  Delta CRLs
>will be available within 15 minutes.  (Assume the initial CRL is small and
>will propagate as if a delta CRL to resolve the bootstrap issues.)
>
>The example below uses the "sliding window" method of issuing delta-CRLs,
>but overlaps the thisUpdate and nextUpdate times to allow for propagation.
>In this example, full CRLs are issued once every 3 hours and deltas are
>issued every 45 minutes. For consistency, the issuer begins issuing deltas
>at the same time as the very first full CRL. Notice that starting with
>cRLNumber 7, the delta CRL issued at the same time as a full CRL does not
>use the previously issued full CRL as its base but the preceding CRL instead.
>As in example #2, these delta-CRLs never provide more than 6 hours of history.
>
>Similary to examples #1 and #2:
>Certificate 14 was revoked for key compromise before 12:00 when the first CRL
>was issued.
>Certificate 124 was revoked for key compromise between 12:00 and 12:45.
>Certificate 39 was placed on hold between 14:15 and 15:00, and its suspension
>was lifted between 16:00 and 17:00.
>Certificate 67 was revoked for an affiliation change between 15:45 and 16:30.
>The reason was changed to key compromise between 18:00 and 18:45.
>
>current  | Revoked      | Full CRL                 | Delta-CRL
>time     | certificates |                          |
>---------|--------------|--------------------------|----------------------
>12:00    | {14k}        | cRLNumber = 1            | cRLNumber = 1
>           |              | thisUpdate = 12:00       | thisUpdate =
>12:00
>           |              | nextUpdate = 18:00       | nextUpdate = 13:00
>           |              | CertificateList = {14k}  | BaseCRLNumber = 1
>           |              |                          | CertificateList =
>{}
>---------|--------------|--------------------------|----------------------
>12:45    | {14k, 124k}  |                          | cRLNumber = 2
>           |              |                          | thisUpdate = 12:45
>           |              |                          | nextUpdate = 13:45
>           |              |                          | BaseCRLNumber = 1
>           |              |                          | CertificateList = 
> {124k}
>---------|--------------|--------------------------|----------------------
>13:30    | {14k, 124k}  |                          | cRLNumber = 3
>           |              |                          | thisUpdate = 13:30
>           |              |                          | nextUpdate = 14:30
>           |              |                          | BaseCRLNumber = 1
>           |              |                          | CertificateList = 
> {124k}
>---------|--------------|--------------------------|----------------------
>14:15    | {14k, 124k}  |                          | cRLNumber = 4
>           |              |                          | thisUpdate = 14:15
>           |              |                          | nextUpdate = 15:15
>           |              |                          | BaseCRLNumber = 1
>           |              |                          | CertificateList = 
> {124k}
>---------|--------------|--------------------------|----------------------
>15:00    | {14k, 124k,  | cRLNumber = 5            | cRLNumber = 5
>           |   39h}       | thisUpdate = 15:00       | thisUpdate =
>15:00
>           |              | nextUpdate = 21:00       | nextUpdate = 16:00
>           |              | CertificateList =        | BaseCRLNumber = 1
>           |              |  {14k, 124k, 39h}        | CertificateList =
>           |              |                          | {124k, 39h}
>---------|--------------|--------------------------|----------------------
>15:45    | {14k, 124k,  |                          | cRLNumber = 6
>           |   39h, 67a}  |                          | thisUpdate = 15:45
>           |              |                          | nextUpdate = 16:45
>           |              |                          | BaseCRLNumber = 1
>           |              |                          | CertificateList =
>           |              |                          | {124k, 39h, 67a}
>---------|--------------|--------------------------|----------------------
>16:30    | {14k, 124k,  |                          | cRLNumber = 7
>           |   67a}       |                          | thisUpdate = 16:30
>           |              |                          | nextUpdate = 17:30
>           |              |                          | BaseCRLNumber = 1
>           |              |                          | CertificateList =
>           |              |                          | {124k, 39r, 67a}
>---------|--------------|--------------------------|----------------------
>17:15    | {14k, 124k,  |                          | cRLNumber = 8
>           |  67a}        |                          | thisUpdate = 17:15
>           |              |                          | nextUpdate = 18:15
>           |              |                          | BaseCRLNumber = 1
>           |              |                          | CertificateList =
>           |              |                          | {124k, 39r, 67a}
>---------|--------------|--------------------------|----------------------
>18:00    | {14k, 124k,  | cRLNumber = 9            | cRLNumber = 9
>           |   67a}       | thisUpdate = 18:00       | thisUpdate =
>18:00
>           |              | nextUpdate = 24:00       | nextUpdate = 19:00
>           |              | CertificateList =        | BaseCRLNumber = 5
>           |              | {14k, 124k, 67a}         | CertificateList =
>           |              |                          | {39r, 67a}
>---------|--------------|--------------------------|----------------------
>18:45    | {14k, 124k,  |                          | cRLNumber = 10
>           |   67k}       |                          | thisUpdate = 18:45
>           |              |                          | nextUpdate = 19:45
>           |              |                          | BaseCRLNumber = 5
>           |              |                          | CertificateList =
>           |              |                          | {39r, 67k}
>---------|--------------|--------------------------|----------------------
>
>
>
>Delta CRL number 6 is issued at 15:45.  By 16:00, delta CRL number 6 should
>be available throughout the system.  As a result, delta CRL number 5 specified
>16:00 as its nextUpdate time.
>
>However, full CRL number 5 was issued at 15:00 and may not be available
>throughout the system  until 18:00.  As a result, full CRL number 1 specified
>18:00 as its nextUpdate time.  In addition, delta CRL number 6 must be based
>on full CRL number 1 which was issued at 12:00.
>
>If the relying party finds full CRL number 5 in the repository, they may still
>apply delta CRL number 6 and achieve the correct answer.
>
>Finally, note that a CRL issuer must generate more CRLs to achieve the goal of
>status information that is no more than one hour old when factoring in the
>propagation delays.
>
>
>



Received: by above.proper.com (8.9.3/8.9.3) id MAA19518 for ietf-pkix-bks; Wed, 16 May 2001 12:01:49 -0700 (PDT)
Received: from luc.ab.org (mail.ab.org [209.112.11.37]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA19505 for <[e-mail]>; Wed, 16 May 2001 12:01:37 -0700 (PDT)
Received: from d00364 ([206.222.76.33]) by luc.ab.org (Netscape Messaging Server 3.6)  with SMTP id AAACB3B for <[e-mail]>; Wed, 16 May 2001 15:10:46 -0400
Reply-To: <[e-mail]>
From: "Mario Gratton" <[e-mail]>
To: <[e-mail]>
Subject: 2 Identities on 1 Certificate
Date: Wed, 16 May 2001 15:00:41 -0400
Message-ID: <003201c0de3a$816dcca0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Is it possible to include 2 Public keys (and also two email address) on 1
certificate?

The particular scenario that prompted this question is as follow:

I have two individuals each with their own PKI credentials that were created
under the same CPS. Both these individuals work in the same office (same OU,
O, C). Private correspondance to one of these individuals would be encrypted
using his/her public certificate but "office" correspondance would be
achieved using this "office" certificate and therefore encrypted using both
public keys.

Please note that I can not create a third PKI entity and share its private
keys to both individuals. The scenario described above seems to be my only
option unless I create a Secure Mail List expansion agent!

Thanks.


Mario Gratton
Manager IT Security Engineering
AEPOS Technologies Corporation
[phone]



Received: by above.proper.com (8.9.3/8.9.3) id KAA16065 for ietf-pkix-bks; Wed, 16 May 2001 10:20:55 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil ([144.51.50.70]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA16046 for <[e-mail]>; Wed, 16 May 2001 10:20:48 -0700 (PDT)
Message-Id: <[e-mail]>
Received: from mfil.terminal (mfil@localhost) by roadblock.missi.ncsc.mil with SMTP id NAA21257 for <[e-mail]>; Wed, 16 May 2001 13:04:38 -0400 (EDT)
Received: from reject.missi.ncsc.mil (reject.missi.ncsc.mil [144.51.60.17]) by roadblock.missi.ncsc.mil with SMTP id NAA21252 for <[e-mail]>; Wed, 16 May 2001 13:04:35 -0400 (EDT)
Received: from 144.51.60.215 by reject.missi.ncsc.mil (InterScan E-Mail VirusWall NT); Wed, 16 May 2001 13:04:02 -0400 (Eastern Daylight Time)
Received: from missi.ncsc.mil (ara.missi.ncsc.mil [144.51.55.128]) by amx.missi.ncsc.mil with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JSFMBZGZ; Wed, 16 May 2001 13:04:22 -0400
Date: Wed, 16 May 2001 12:58:18 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Strawman on Delta CRLs
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Sarbari,

The CRLs in the examples do not give contradictory results because CRLs
do *not* have a validity period, they have a validity instant.

CRL #1 is valid at 12:00.  The next CRL might be issued at
15:00, but it also might be issued at 12:05.

CRL #3 is valid at 14:00.

CRL #3's thisUpdate is two hours later than CRL #1's. CRL #3
contains fresher revocation information, and it is incorrect
to assert that that information "contradicts" the staler
information in CRL #1.

CRLs, like OCSP responses, are valid at the instant they
are issued, and no longer.  Relying Parties may use nextUpdate to
determine when to look for a new CRL.  But RPs must not delude
themselves into thinking that an old CRL is magically "valid"
until its nextUpdate, because another CRL, delta or full, could
have been issued seconds later.

Dave



Sarbari Gupta wrote:
> 
> Tim, David, Russ,
> 
> The "strawman" on the use of delta CRLs was very precise and clear - thank you. I know this thread had been discussed to death already, but I did have a comment:
> 
> It seems counterproductive to have CRLs and delta-CRLs that are valid in parallel as in your examples. CRL #1 is valid between 12:00 and 15:00, and delta CRL #3 is valid between 14:00 and 15:00. If I am trying to validate certificate 124 at 14:30, I will get opposite results if I use CRL #1 versus delta CRL #3 - yet both are valid at the time.
> 
> I can understand CRLs and OCSP giving different revocation status because of the different levels of latency. Why is it a good idea to have contradictory results with the same (CRL) mechanism? More importantly, why should the standard be formulated to allow such usage of CRLs, where you can have two CRLs that are both valid yet contradict each other?
> 
> I would vote for CRLs and delta CRLs to have non-overlapping validity periods so that there is no possibility of a contradictory revocation status. If network delays are a problem, engineering solutions need to be found - the validity period of the CRL may need to be adjusted to be larger than the anticipated network delay, or the scope of the CRL may be adjusted to allow smaller-sized CRLs, or perhaps, a different revocation checking mechanism should be considered.
> 
> - Sarbari Gupta
> ==============================
> Sarbari Gupta
> Electrosoft Services, Inc.
> Tel: [phone]
> FAX: [phone]
> Email: [e-mail]
> Web: <http://www.electrosoft-inc.com/>
> ==============================


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id JAA13474 for ietf-pkix-bks; Wed, 16 May 2001 09:48:45 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil ([144.51.50.70]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA13461 for <[e-mail]>; Wed, 16 May 2001 09:48:38 -0700 (PDT)
Message-Id: <[e-mail]>
Received: from mfil.terminal (mfil@localhost) by roadblock.missi.ncsc.mil with SMTP id MAA20993 for <[e-mail]>; Wed, 16 May 2001 12:38:27 -0400 (EDT)
Received: from reject.missi.ncsc.mil (reject.missi.ncsc.mil [144.51.60.17]) by roadblock.missi.ncsc.mil with SMTP id MAA20988 for <[e-mail]>; Wed, 16 May 2001 12:38:23 -0400 (EDT)
Received: from 144.51.60.215 by reject.missi.ncsc.mil (InterScan E-Mail VirusWall NT); Wed, 16 May 2001 12:37:50 -0400 (Eastern Daylight Time)
Received: from missi.ncsc.mil (ara.missi.ncsc.mil [144.51.55.128]) by amx.missi.ncsc.mil with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JSFMBZD9; Wed, 16 May 2001 12:38:10 -0400
Date: Wed, 16 May 2001 12:31:48 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: cA flag and CRL issuers (was Re: Last Call:   draft-ietf-pkix-new-part1-06.txt comments)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <000801c0c6a7$60e9d870$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <p05010406b72760acb0bf@[128.33.238.68]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Steve,

Santosh has stated that setting both the cA flag and the cRLSign
bit provides no security advantage over setting the cRLSign bit only.


Tom Gindin has said:
>   Just BTW, my reasoning is similar to Santosh's.  I would like to
> mention that the reasons for issuing a distinct CMP certificate for a CA
> are even stronger than those for a distinct CRL certificate.  However, it
> is not obvious whether this should be classed as a CA certificate since a
> certificate to be used with CMP looks more like a standard server
> certificate.



Russ Housley has said:
> Dave:
>
> Your first two arguments seem to be compelling.
>
> Russ
>
> At 11:42 AM 4/30/2001 -0400, you [David Kemp] wrote:
> >
> >1) Previously, conforming clients could validate a CRL if the cRLSign
> >    bit is asserted and the cA flag is not asserted.  This change
> >    would declare such clients to be non-conforming.
> >
> >2) [snip]
> >    My position is that no additional flag is needed in either the CA or
> >    the AA case.  If the CRL signer has a valid certificate with the
> >    cRLSign bit set, then it is an authority because the certificate
> >    signer (or it's parent) has said so. Requiring two flags in the
> >    same certificate is no more secure than requiring one.



Denis Pinkas has said:
> As far as I remember, originally the cA boolean in the basic constraints 
> extension only allowed to make the difference between leaf  certificates and 
> CA certificates. This boolean now seems to be be used with a different 
> meaning (and, maybe, we should change its meaning - not the syntax). 
>
> Could someone say again, why that change was requested and 
> what are the real benefits of that change ? 




You have ignored David Cooper's point that the CA signs the certificate
containing the cRLSign bit, and therefore relying parties know
conclusively that a certificate with cRLSign asserted (and cA not
necessarily asserted) contains the public key that the CA uses to
sign CRLs.  This is the semantic context that matters - as you say,
the CA is responsible for signing CRLs.  The CA can unambiguously
designate the key RPs use to validate its CRLs by setting only the
cRLSign bit in a self-issued certificate.

I believe it is time for you to call for a straw poll on whether
to make extensive changes to the texts of PKIX and X.509 to
require the cA flag to be set in certificates used to validate CRLs

By my count, at least 5 people believe there is no need for such
a change:

Santosh Chokhani
David Cooper
Denis Pinkas
Russ Housley
Dave Kemp

I have not heard from Tim Polk since Russ' conversion :-), and I can't
determine a position from postings by Tom Ginden and Sharon Boeyen.

Dave





----------------- Begin Included Message ---------------------------

> Date: Tue, 15 May 2001 18:45:26 -0400
> To: "David A. Cooper" <[e-mail]>
> From: Stephen Kent <[e-mail]>
> Subject: Re: cA flag and CRL issuers (was Re: Last Call:   
draft-ietf-pkix-new-part1-06.txt comments)
> Cc: [e-mail]
> 
> Dave,
> 
> I provided an analysis of the evolution of CRL signing from V1 + V2 
> certs, to the changes you cite re V3 certs.  You have chosen to 
> ignore large parts of this analysis, and focus on text in the current 
> version of X.509 that emphasizes syntactic details but not the larger 
> semantic context. You have not adressed the fact that both X.509 and 
> RFC 2459 make repeated references to "authorities" or CAs re CRL 
> issuance. You have received feedback from Sharon, and I think several 
> of the 2459 authors have weighed in on this topic during the 
> multi-week debate.
> 
> I see no point in continuing the discussion.
> 
> Steve


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA04483 for ietf-pkix-bks; Wed, 16 May 2001 08:02:32 -0700 (PDT)
Received: from mail01.san.yahoo.com (mail01.san.yahoo.com [209.132.1.35]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA04475 for <[e-mail]>; Wed, 16 May 2001 08:02:25 -0700 (PDT)
Received: from sgupta (66.44.46.12) by mail01.san.yahoo.com (5.1.062) id 3AEBC0F800886F90; Wed, 16 May 2001 07:55:45 -0700
Reply-To: <[e-mail]>
From: "Sarbari Gupta" <[e-mail]>
To: "Tim Polk" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Strawman on Delta CRLs
Date: Wed, 16 May 2001 11:02:52 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id IAA04476
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Tim, David, Russ,

The "strawman" on the use of delta CRLs was very precise and clear - thank you. I know this thread had been discussed to death already, but I did have a comment:

It seems counterproductive to have CRLs and delta-CRLs that are valid in parallel as in your examples. CRL #1 is valid between 12:00 and 15:00, and delta CRL #3 is valid between 14:00 and 15:00. If I am trying to validate certificate 124 at 14:30, I will get opposite results if I use CRL #1 versus delta CRL #3 - yet both are valid at the time. 

I can understand CRLs and OCSP giving different revocation status because of the different levels of latency. Why is it a good idea to have contradictory results with the same (CRL) mechanism? More importantly, why should the standard be formulated to allow such usage of CRLs, where you can have two CRLs that are both valid yet contradict each other? 

I would vote for CRLs and delta CRLs to have non-overlapping validity periods so that there is no possibility of a contradictory revocation status. If network delays are a problem, engineering solutions need to be found - the validity period of the CRL may need to be adjusted to be larger than the anticipated network delay, or the scope of the CRL may be adjusted to allow smaller-sized CRLs, or perhaps, a different revocation checking mechanism should be considered. 

- Sarbari Gupta
==============================
Sarbari Gupta
Electrosoft Services, Inc.
Tel: [phone]
FAX: [phone]
Email: [e-mail]
Web: <http://www.electrosoft-inc.com/>
==============================

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Tim Polk
Sent: Friday, May 11, 2001 3:07 PM
To: [e-mail]
Subject: Strawman on Delta CRLs



Folks,

David Cooper, Russ Housley and I have collaborated on a "strawman" 
describing the use of delta CRLs in PKIX implementations.  We believe the 
functionality we describe is consistent with ISO X.509 as well.

The text describes algorithms for using deltas and base CRLs to (a) check 
the status of a certificate or (b) create a constructed CRL.  This is 
followed by three scenarios for the use of deltas - "traditional deltas", 
"sliding window deltas", and a variant on sliding window deltas that 
factors in the real world delays in populating repositories with base and 
delta CRLs.

I have appended the strawman below in ASCII text.  The text includes tables 
for the examples.  Please note, these tables *require* a fixed font to be 
legible.  If you would prefer a copy in either Word or PDF, I have posted 
them at the following URLs:
http://csrc.nist.gov/pki/documents/PKIX/PKIXdeltas.doc and 
http://csrc.nist.gov/pki/documents/PKIX/PKIXdeltas.pdf

Hopefully, this strawman will serve to frame further discussions and 
accelerate consensus.   Once we agree on the requirements, Russ and I will 
draft the necessary changes and we can finish Last Call.  (I am nothing if 
not an optimist.)

We would also like to add the examples as an *informative* appendix in 
son-of-2459.

Thanks,

Tim Polk


--------------------------------strawman---------------------------

Implementing Delta CRLs Using PKIX

This paper addresses the use of delta CRLs in PKIX-compliant systems.
This paper assumes that delta CRLs include the delta CRL indicator
extension (rather than a CRL scope extension) and ignores
complications involving combined delta CRLs from indirect CRL issuers.

This paper also assumes that CRLs with different scopes are distributed
using different distribution points.

Terms

Revoked: A statement that a particular certificate's status has changed
and it should no longer be trusted.  Once a certificate is revoked, it
is always revoked.

Suspension: A statement that a particular certificate may not be
trustworthy. Once placed on hold, a certificate may be revoked or the
suspension may be lifted.

Revocation notice: A statement that a particular certificate has been
suspended or revoked.  The revocation statement identifies the certificate
by the issuer name and serial number.  The issuer may be specified
explicitly or implicitly. The issuer may be explicitly identified using
the certificate issuer extension. If not specified explicitly, the issuer
of the certificate is implicitly identified as the issuer of the CRL. A
revocation notice includes the date and time the certificate was revoked.
A revocation notice may optionally include a revocation reason in the
reason code CRL entry extension. [Note: A revocation notice may optionally
specify in the invalidity date extension the date from which the
certificate should be considered invalid.  This date may precede the actual
revocation date.  The invalidity date extension does not feature in this
discussion, so it is not considered further in this paper.]

Certificate revocation list (CRL):  a list of revocation notices for
certificates.

CRL scope: the set of certificates that could appear on a given CRL.
For example, the scope may be "all certificates issued by CA X", "all
CA and end entity certificates issued by CA X", "all certificates issued
by CA X that have been revoked for key compromise and CA compromise", or
may be a set of certificates based on local information, such as "all
certificates issued to the NIST employees located in Boulder".

Full CRL: a CRL that lists all unexpired certificates, in its scope, that
have been revoked for one of the revocation reasons covered by the scope
of the CRL. The scope of a full CRL does not necessarily include all of
the certificates issued by a CA or all possible revocation reasons.

Base CRL:  the particular CRL used as the foundation for a delta CRL.  The
base must be a full CRL.

Delta CRL:  a CRL that only lists those unexpired certificates, in its scope,
whose revocation status has changed since the issuance of a particular,
referenced base CRL. The scope of a delta CRL is must be the same as the base
CRL that it references

CRL Numbering

A CRL issuer may generate full CRLs for more than one scope.  The CRL issuer
may also generate delta CRLs.  Each delta CRLs must have the same scope as the
full CRL referenced as its base.

For each scope supported by the CRL issuer, a numbering sequence must be
maintained.  For each scope, the CRLs are numbered in a monotonically 
increasing
sequence.  (Wrapping is not permitted in the PKIX profile.)  If a CRL issuer
generates CRLs for one scope (e.g., full CRLs and deltas CRLs), the issuer must
maintain one numbering sequence.  If a delta CRL and a full CRL that cover the
same scope are issued at the same time, they will have the same CRL number.

If a CRL issuer generates CRLs for two scopes (e.g., one covering CA
certificates and one covering end entity certificates), then the CRL issuer 
must
maintain two number sequences.  The CRLs and deltas for the same scope 
(e.g., CA
certificates) will share one numbering sequence.  The CRLs and deltas for the
second scope (e.g., end entity certificates) will share one numbering 
sequence.
There is no requirement that these sequences be disjoint.

Algorithms for Determining Status from a Full CRL and a Delta CRL

Consider a full CRL, F, with CRL number X.  A client may obtain BF in either of
the following ways:
(a) the full CRL F may have been pushed to the client or pulled from a 
repository; or
(b) F may have been constructed from a full CRL and a delta CRL using this 
algorithm.

Consider a delta CRL, D, which specifies base CRL Y and has CRL number Z.  This
means that all certificates whose statuses have changed since the issuance 
of CRL Y
will be listed on the delta CRL.  Note that the PKIX profile requires the 
CA to issue
CRL Y as a full CRL.

Determining Whether a Full CRL and Delta CRL May Be Combined

F and D may be combined if each of the following conditions are met:

(1)	X is greater than or equal to Y.  That is, the full CRL must (at a minimum)
contain all the revocation information held by the referenced base CRL.
(2)	X is less than Z.  That is, the delta CRL must cover some time that was not
covered by the full CRL.

Determining Status of a Certificate from a Full CRL and a Delta CRL

If the PKI client maintains the delta and full CRL, the status of an unexpired
certificate C may be determined as follows:

(1)	If C is listed on the delta CRL, then:
a.	If C is listed on the delta CRL with reason code "removeFromCRL", then C
is not revoked.
b.	Otherwise, certificate C is revoked.
(2)	If C was not listed on the delta CRL, then the full CRL is checked, and the
status is as follows:
a.	If C is listed on the full CRL, then C is revoked.
b.	If C is not listed on the full CRL, then C is not revoked.

Combining a Full CRL and Delta CRL into a Constructed CRL

If the PKI client maintains the current CRL in a local cache:

The revocation information on F is assumed as the initial condition.  F is 
a list
of revoked certificates; each certificate is listed with a revocation reason
(which may be "unspecified").

The list of revoked certificates L with n entries denoted as L[i] where 1 
<= i <= n.
(The value n may shrink or grow as the combination process proceeds.)

Initialize L to the revocation notices on F.  For each certificate C on the 
delta CRL,
update the contents of L as follows.

If a certificate C appears on the delta CRL, and C is not currently in the 
list L,
then:
(a)	if C has a revocation reason other than "removeFromCRL", add C as a new 
entry
in  the list of revoked certificates L.
(b)	If C has revocation reason "removeFromCRL", skip this certificate.  No 
update
to the cache is needed.

If a certificate C appears on the delta CRL, and C is presently listed in L 
as entry
L[i], then:
(a)	If C is listed on the delta CRL with a revocation reason of 
"removeFromCRL",
delete entry L[i]
(b)	If C is listed on the delta CRL without a revocation reason or with a 
revocation
reason other than "removeFromCRL", change the reason code associated with 
L[i] to the
reason code specified in the delta CRL.

The combination of F and D forms a new full CRL with CRL number Z.  This 
full CRL has
complete information until the time specified in the next update field in 
the delta CRL
is reached.  If a relying party is validating a certificate with respect to 
time T, and
T is before the next update field in the delta CRL, they may assume 
complete information.

If an unexpired certificate C within the scope of the constructed CRL is 
not listed, then
certificate C is not revoked for one of the revocation reasons covered by 
this CRL.  If
the constructed CRL covers all reasons, then the certificate C is not revoked.

Using Deltas to Distribute Revocation Information

This section provides three different scenarios for the use of delta 
CRLs.  For the
purpose of these examples, assume a goal of providing revocation 
information to relying
parties that is no more than one hour old.

The following notation is used to denote a revoked certificate on a CRL:
		Xr	certificate X is listed for reason r, where r in {a,k,h,r}
The reason codes {a,k,h,r} correspond to "affiliation changed", "key 
compromise",
"certificate hold", and "remove from CRL" respectively.

(Note:  The remaining reason codes are omitted for simplicity.  The handling of
certificates revoked for  the reasons "unspecified", "CA compromise", 
"superseded", and
"cessationOfOperation" are identical to "affiliation changed or "key 
compromise").



Example #1

The example below shows the "traditional" method of issuing delta CRLs.
In this example, full CRLs are issued once every 3 hours and deltas are
issued once an hour. For consistency, the issuer begins issuing deltas
at the same time as the very first full CRL. After that, however, a delta
can always use a previously issued full CRL as its base. Notice that
starting with cRLNumber 4, the delta CRL issued at the same time as a
full CRL uses the previously issued full CRL as its base. However, the
delta-CRLs never provide more than 3 hours of history.

In this example:
Certificate 14 was revoked for key compromise before 12:00 when the first
CRL was issued.
Certificate 124 was revoked for key compromise between 12:00 and 13:00.
Certificate 39 was placed on hold between 14:00 and 15:00, and its
suspension was lifted between 16:00 and 17:00.
Certificate 67 was revoked for an affiliation change between 16:00 and
17:00.  The reason was changed to key compromise between 18:00 and 19:00.

current  | Revoked      | Full CRL                 | Delta-CRL
time     | certificates |                          |
---------|--------------|--------------------------|----------------------
12:00    | {14k}        | cRLNumber = 1            | cRLNumber = 1
          |              | thisUpdate = 12:00       | thisUpdate = 
12:00
          |              | nextUpdate = 15:00       | nextUpdate = 13:00
          |              | CertificateList = {14k}  | BaseCRLNumber = 1
          |              |                          | CertificateList = 
{}
---------|--------------|--------------------------|----------------------
13:00    | {14k, 124k}  |                          | cRLNumber = 2
          |              |                          | thisUpdate = 13:00
          |              |                          | nextUpdate = 14:00
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList = {124k}
---------|--------------|--------------------------|----------------------
14:00    | {14k, 124k}  |                          | cRLNumber = 3
          |              |                          | thisUpdate = 14:00
          |              |                          | nextUpdate = 15:00
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList = {124k}
---------|--------------|--------------------------|----------------------
15:00    | {14k, 124k,  | cRLNumber = 4            | cRLNumber = 4
          |   39h}       | thisUpdate = 15:00       | thisUpdate = 
15:00
          |              | nextUpdate = 18:00       | nextUpdate = 16:00
          |              | CertificateList =        | BaseCRLNumber = 1
          |              |  {14k, 124k, 39h}        | CertificateList =
          |              |                          | {124k, 39h}
---------|--------------|--------------------------|----------------------
16:00    | {14k, 124k,  |                          | cRLNumber = 5
          |   39h, 67a}  |                          | thisUpdate = 16:00
          |              |                          | nextUpdate = 17:00
          |              |                          | BaseCRLNumber = 4
          |              |                          | CertificateList = {67a}
          |              |                          |
---------|--------------|--------------------------|----------------------
17:00    | {14k, 124k,  |                          | cRLNumber = 6
          |   67a}       |                          | thisUpdate = 17:00
          |              |                          | nextUpdate = 18:00
          |              |                          | BaseCRLNumber = 4
          |              |                          | CertificateList =
          |              |                          | {39r, 67a}
---------|--------------|--------------------------|----------------------
18:00    | {14k, 124k,  | cRLNumber = 7            | cRLNumber = 7
          |   67a}       | thisUpdate = 18:00       | thisUpdate = 
18:00
          |              | nextUpdate = 21:00       | nextUpdate = 19:00
          |              | CertificateList =        | BaseCRLNumber = 4
          |              | {14k, 124k, 67a}         | CertificateList =
          |              |                          | {39r, 
67a}
---------|--------------|--------------------------|----------------------
19:00    | {14k, 124k,  |                          | cRLNumber = 8
          |   67k}       |                          | thisUpdate = 19:00
          |              |                          | nextUpdate = 20:00
          |              |                          | BaseCRLNumber = 7
          |              |                          | CertificateList = {67k}
---------|--------------|--------------------------|----------------------

Scenario #2

The example below shows the "sliding window" method of issuing delta-CRLs.
In this example, full CRLs are issued once every 3 hours and deltas are
issued once an hour. For consistency, the issuer begins issuing deltas at
the same time as the very first full CRL. Notice that starting with
cRLNumber 7, the delta CRL issued at the same time as a full CRL does not
use the previously issued full CRL as its base but the preceding CRL instead.
However, these delta-CRLs never provide more than 6 hours of history.

As in example #1:
Certificate 14 was revoked for key compromise before 12:00 when the first
CRL was issued.
Certificate 124 was revoked for key compromise between 12:00 and 13:00.
Certificate 39 was placed on hold between 14:00 and 15:00, and its
suspension was lifted between
16:00 and 17:00.
Certificate 67 was revoked for an affiliation change between 16:00 and 17:00.
The reason was changed to key compromise between 18:00 and 19:00.

current  | Revoked      | Full CRL                 | Delta-CRL
time     | certificates |                          |
---------|--------------|--------------------------|----------------------
12:00    | {14k}        | cRLNumber = 1            | cRLNumber = 1
          |              | thisUpdate = 12:00       | thisUpdate = 
12:00
          |              | nextUpdate = 15:00       | nextUpdate = 13:00
          |              | CertificateList = {14k}  | BaseCRLNumber = 1
          |              |                          | CertificateList = 
{}
---------|--------------|--------------------------|----------------------
13:00    | {14k, 124k}  |                          | cRLNumber = 2
          |              |                          | thisUpdate = 13:00
          |              |                          | nextUpdate = 14:00
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList = {124k}
---------|--------------|--------------------------|----------------------
14:00    | {14k, 124k}  |                          | cRLNumber = 3
          |              |                          | thisUpdate = 14:00
          |              |                          | nextUpdate = 15:00
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList = {124k}
---------|--------------|--------------------------|----------------------
15:00    | {14k, 124k,  | cRLNumber = 4            | cRLNumber = 4
          |   39h}       | thisUpdate = 15:00       | thisUpdate = 
15:00
          |              | nextUpdate = 18:00       | nextUpdate = 16:00
          |              | CertificateList =        | BaseCRLNumber = 1
          |              |  {14k, 124k, 39h}        | CertificateList =
          |              |                          | {124k, 39h}
---------|--------------|--------------------------|----------------------
16:00    | {14k, 124k,  |                          | cRLNumber = 5
          |   39h, 67a}  |                          | thisUpdate = 16:00
          |              |                          | nextUpdate = 17:00
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList =
          |              |                          | {124k, 39h, 67a}
---------|--------------|--------------------------|----------------------
17:00    | {14k, 124k,  |                          | cRLNumber = 6
          |   67a}       |                          | thisUpdate = 17:00
          |              |                          | nextUpdate = 18:00
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList =
          |              |                          | {124k, 39h, 67a}
---------|--------------|--------------------------|----------------------
18:00    | {14k, 124k,  | cRLNumber = 7            | cRLNumber = 7
          |   67a}       | thisUpdate = 18:00       | thisUpdate = 
18:00
          |              | nextUpdate = 21:00       | nextUpdate = 19:00
          |              | CertificateList =        | BaseCRLNumber = 1
          |              | {14k, 124k, 67a}         | CertificateList =
          |              |                          | {124k, 39r, 67a}
---------|--------------|--------------------------|----------------------
19:00    | {14k, 124k,  |                          | cRLNumber = 8
          |   67k}       |                          | thisUpdate = 19:00
          |              |                          | nextUpdate = 20:00
          |              |                          | BaseCRLNumber = 7
          |              |                          | CertificateList =
          |              |                          | {39r, 67k
---------|--------------|--------------------------|----------------------


Note that the delta CRLs are marginally larger than in the first scenario
since they cover a longer time period.  On the other hand, a relying party
is less likely to download full CRLs in the second scenario.

For example, a relying party that validated one certificate at 12:15, then
a second certificate at 16:15 would not require a new full CRL in scenario #2.
In scenario #1, the relying party would be forced to obtain both full CRL 4
and delta CRL 5.

Scenario #3 Allowing for Replication/Propagation Delays

In this scenario, full CRLs and delta CRLs are replicated throughout a
repository system.  Data is replicated through the system at different
rates based on the size of the file.  The CA operators estimate that full
CRLs will be available throughout the system within three hours.  Delta CRLs
will be available within 15 minutes.  (Assume the initial CRL is small and
will propagate as if a delta CRL to resolve the bootstrap issues.)

The example below uses the "sliding window" method of issuing delta-CRLs,
but overlaps the thisUpdate and nextUpdate times to allow for propagation.
In this example, full CRLs are issued once every 3 hours and deltas are
issued every 45 minutes. For consistency, the issuer begins issuing deltas
at the same time as the very first full CRL. Notice that starting with
cRLNumber 7, the delta CRL issued at the same time as a full CRL does not
use the previously issued full CRL as its base but the preceding CRL instead.
As in example #2, these delta-CRLs never provide more than 6 hours of history.

Similary to examples #1 and #2:
Certificate 14 was revoked for key compromise before 12:00 when the first CRL
was issued.
Certificate 124 was revoked for key compromise between 12:00 and 12:45.
Certificate 39 was placed on hold between 14:15 and 15:00, and its suspension
was lifted between 16:00 and 17:00.
Certificate 67 was revoked for an affiliation change between 15:45 and 16:30.
The reason was changed to key compromise between 18:00 and 18:45.

current  | Revoked      | Full CRL                 | Delta-CRL
time     | certificates |                          |
---------|--------------|--------------------------|----------------------
12:00    | {14k}        | cRLNumber = 1            | cRLNumber = 1
          |              | thisUpdate = 12:00       | thisUpdate = 
12:00
          |              | nextUpdate = 18:00       | nextUpdate = 13:00
          |              | CertificateList = {14k}  | BaseCRLNumber = 1
          |              |                          | CertificateList = 
{}
---------|--------------|--------------------------|----------------------
12:45    | {14k, 124k}  |                          | cRLNumber = 2
          |              |                          | thisUpdate = 12:45
          |              |                          | nextUpdate = 13:45
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList = {124k}
---------|--------------|--------------------------|----------------------
13:30    | {14k, 124k}  |                          | cRLNumber = 3
          |              |                          | thisUpdate = 13:30
          |              |                          | nextUpdate = 14:30
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList = {124k}
---------|--------------|--------------------------|----------------------
14:15    | {14k, 124k}  |                          | cRLNumber = 4
          |              |                          | thisUpdate = 14:15
          |              |                          | nextUpdate = 15:15
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList = {124k}
---------|--------------|--------------------------|----------------------
15:00    | {14k, 124k,  | cRLNumber = 5            | cRLNumber = 5
          |   39h}       | thisUpdate = 15:00       | thisUpdate = 
15:00
          |              | nextUpdate = 21:00       | nextUpdate = 16:00
          |              | CertificateList =        | BaseCRLNumber = 1
          |              |  {14k, 124k, 39h}        | CertificateList =
          |              |                          | {124k, 39h}
---------|--------------|--------------------------|----------------------
15:45    | {14k, 124k,  |                          | cRLNumber = 6
          |   39h, 67a}  |                          | thisUpdate = 15:45
          |              |                          | nextUpdate = 16:45
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList =
          |              |                          | {124k, 39h, 67a}
---------|--------------|--------------------------|----------------------
16:30    | {14k, 124k,  |                          | cRLNumber = 7
          |   67a}       |                          | thisUpdate = 16:30
          |              |                          | nextUpdate = 17:30
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList =
          |              |                          | {124k, 39r, 67a}
---------|--------------|--------------------------|----------------------
17:15    | {14k, 124k,  |                          | cRLNumber = 8
          |  67a}        |                          | thisUpdate = 17:15
          |              |                          | nextUpdate = 18:15
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList =
          |              |                          | {124k, 39r, 67a}
---------|--------------|--------------------------|----------------------
18:00    | {14k, 124k,  | cRLNumber = 9            | cRLNumber = 9
          |   67a}       | thisUpdate = 18:00       | thisUpdate = 
18:00
          |              | nextUpdate = 24:00       | nextUpdate = 19:00
          |              | CertificateList =        | BaseCRLNumber = 5
          |              | {14k, 124k, 67a}         | CertificateList =
          |              |                          | {39r, 67a}
---------|--------------|--------------------------|----------------------
18:45    | {14k, 124k,  |                          | cRLNumber = 10
          |   67k}       |                          | thisUpdate = 18:45
          |              |                          | nextUpdate = 19:45
          |              |                          | BaseCRLNumber = 5
          |              |                          | CertificateList =
          |              |                          | {39r, 67k}
---------|--------------|--------------------------|----------------------



Delta CRL number 6 is issued at 15:45.  By 16:00, delta CRL number 6 should
be available throughout the system.  As a result, delta CRL number 5 specified
16:00 as its nextUpdate time.

However, full CRL number 5 was issued at 15:00 and may not be available
throughout the system  until 18:00.  As a result, full CRL number 1 specified
18:00 as its nextUpdate time.  In addition, delta CRL number 6 must be based
on full CRL number 1 which was issued at 12:00.

If the relying party finds full CRL number 5 in the repository, they may still
apply delta CRL number 6 and achieve the correct answer.

Finally, note that a CRL issuer must generate more CRLs to achieve the goal of
status information that is no more than one hour old when factoring in the
propagation delays.






Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA03816 for ietf-pkix-bks; Wed, 16 May 2001 07:47:33 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA03812 for <[e-mail]>; Wed, 16 May 2001 07:47:26 -0700 (PDT)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id KAA17499 for <[e-mail]>; Wed, 16 May 2001 10:47:26 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Wed, 16 May 2001 10:46:45 -0400
To: [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: Re: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments)
In-Reply-To: <p05010406b72760acb0bf@[128.33.238.68]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <000801c0c6a7$60e9d870$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id HAA03813
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Steve,

My interest is in ensuring that the PKIX Certificate and CRL Profile is correct, consistent, and complete. If these issues are not of interest to you, then feel free to ignore this message.

At 06:45 PM 5/15/01 -0400, Stephen Kent wrote:
>Dave,
>
>I provided an analysis of the evolution of CRL signing from V1 + V2 certs, to the changes you cite re V3 certs.

As far as I am concerned, v1 and v2 is irrelevant. Extensions did not exist prior to v3, so neither v1 nor v2 could have included any requirements with respect to the proper setting of the cA bit in the basicConstraints extension.

>You have chosen to ignore large parts of this analysis, and focus on text in the current version of X.509 that emphasizes syntactic details but not the larger semantic context.

We are discussing the cA bit. I have quoted the text from X.509 that provides the semantics for the cA bit numerous times. You have chosen to ignore this text.

>You have not adressed the fact that both X.509 and RFC 2459 make repeated references to "authorities" or CAs re CRL issuance. You have received feedback from Sharon, and I think several of the 2459 authors have weighed in on this topic during the multi-week debate.
>
>I see no point in continuing the discussion.


Based on the discussions that have occurred in this thread it seems to me that there are a number of issues in X.509 and PKIX that need to be resolved:


1) Who can issue CRLs?

         a) There seems to be consensus that it is acceptable for an entity that does
             not sign certificates to sign CRLs.

         b) There has been suggestion that the standards only allow for authorities to issue CRLs.

         c) X.509 defines an authority as "[a]n entity, responsible for the issuance of certificates.
              Two types are defined in this Specification; certification authority which issues public-key
             certificates and attribute authority which issues attribute certificates."

             X.509 similarly defines an CA as "An authority trusted by one or more users to create and
             assign public-key certificates. Optionally the certification authority may create the users’ keys."
             An attribute authority is defined to be "[a]n authority which assigns privileges by issuing
             attribute certificates".

     So, if we wish to allow entities to sign CRLs but not certificates, we either need to allow for entities
     other than authorities to issue CRLs or we need to redefine the terms CA, AA, and authority to include
     include entities that do not issue certificates.



2) In which directory attributes should certificates that are issued to subjects that are CAs be placed?

         a) RFC 2587 states that certificates issued to end entities must be placed in the userCertificate
             attribute and that certificates issued to CAs must be placed in the cACertificate and/or
             crossCertificatePair attributes (with specific rules on when each of these attributes is to
             be populated).

         b) RFC 2587 also states  that "none of the ... CA certificates shall include a basicConstraints
             extension with the cA value set to FALSE".

         c) There has been no consensus that the cA value in basicConstraints must be set to TRUE
             whenever the certificate subject is a CA. This lack of consensus is particularly the case
             when the certificate contains a keyUsage extension with neither the keyCertSign nor the
             cRLSign bit set. (I believe that Tim Polk has proposed changing the standards to require
             the cA value to be set to TRUE whenever the subject is a CA, but there has been no
             consensus that such a change should  be made).

     So, either we need to change X.509 and PKIX to state that the cA bit in basicConstraints indicates
     whether the certificate subject is a CA or LDAP schema needs to be clarified to clearly indicate in
     which attribute(s) certificates issued to CAs should be placed when basicConstraints is present but
     cA is set to FALSE (e.g., if the subject public key is used to sign CMP transactions, but not to sign
     certificates or CRLs).



What does the cA bit in basicConstraints mean?

     As a result of the changes from new-part1-05 to new-part1-06, the text in the PKIX profile describing
     the cA bit is contradictory. It states: "The cA bit indicates if the certified public key may be used to
     verify signatures on other certificates. If the cA bit is asserted, then either the keyCertSign bit or the
     cRLSign bit in the key usage extension (see 4.2.1.3) MUST also be asserted."

     The first sentence, which is essentially copied from X.509, states that the bit indicates whether the
     subject public key may be used to verify signatures on certificates. The next sentence, however,
     seems to contradict this by stating that the cA bit may be set to TRUE even if the subject public key
     may not be used to verify signatures on certificates (if the subject public key may be used to verify
     signatures on CRLs).

     Of course, if there were a requirement to only set the cRLSign bit in KeyUsage if the keyCertSign bit
     is also set, then there would be no contradiction. If this were the case, then the cA bit really would
     indicate is the subject public key may be used to verify signatures on certificates. However, there has
     certainly been agreement that it should be acceptable to specify that a key may be used to verify
     signatures on CRLs but not certificates. So, we must either revert to the new-part1-05 text which
     clearly ties the cA bit to the keyCertSign bit, or we must redefine the cA bit in both X.509 and PKIX.


There may be other issues that I am not recalling at the moment.

We need to step back and try to view this standard from the perspective of someone who is new to X.509. We cannot expect that everyone who makes use of the X.509 standard will have read through all of the messages on the PKIX mailing list. If the X.509 certificate generation and processing rules can not be unambiguously determined from the written standards, then the standards need to be fixed. Arguments to the effect of "the standard says X, but it really means Y, and to see why Y is the correct interpretation you'll need to read the relevant discussions from the PKIX mailing list from April of 1998." Similarly, claims that people should somehow determine the processing rules by looking at the "larger semantic context" instead of "text in the current version of X.509 that emphasizes syntactic details" are unacceptable. If the syntactic details are incorrect, then we should fix them. We can not have a standard that provides incorrect "syntactic details" and then expect people to correctly implement the standard based on an interpretation of the "larger semantic context".


Dave





Received: by above.proper.com (8.9.3/8.9.3) id DAA10652 for ietf-pkix-bks; Wed, 16 May 2001 03:25:39 -0700 (PDT)
Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA10647 for <[e-mail]>; Wed, 16 May 2001 03:25:31 -0700 (PDT)
Received: from kant [129.27.152.76] by iaik.tu-graz.ac.at (SMTPD32-6.06) id A58962C5003A; Wed, 16 May 2001 12:25:13 +0200
Message-ID: <004701c0ddf2$65c09d40$4c981b81@kant>
From: "Andreas Sterbenz" <[e-mail]>
To: "Housley, Russ" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: keyCertSign and Path Validation
Date: Wed, 16 May 2001 12:24:31 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2462.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

The point I was making is that the key usage extension, if present, is
handled differently depending on whether or not it is critical. This may be
for a reason, but it seems neither intuitive to me nor explained in the rest
of the document.

The reason I came across this is the X.509 conformance test suite by NIST,
Cygnacom, and others posted to the list by Tim Polk some time ago. It
requires that CA certificates with a non-critical key usage extension and
the keyCertSign bit cleared are rejected (IC.05.02). This is in obvious
contradiction to the PKIX validation algorithm.

This may be either due to an oversight in either of the two, or due to an
incompatible interpretation of X.509. I believe the issue should be
addressed in either case. The text below from X.509 4th ed. draft 8 seems to
confirm the NIST position.

===
If the extension if flagged non-critical, then it indicates the intended
purpose or purposes of the key, and may be used in finding the correct
key/certificate of an entity that has multiple keys/certificates. If this
extension is present, and the certificate-using system recognizes and
processes the keyUsage extension type, then the certificate-using system
shall ensure that the certificate shall be used only for a purpose for which
the corresponding key usage bit is set to one. A bit set to zero indicates
that the key is not intended for that purpose. If all bits are zero, it
indicates the key is intended for some purpose other than those listed.
===

 Andreas Sterbenz              mailto:[e-mail]


----- Original Message -----
From: "Housley, Russ" <[e-mail]>
To: "Andreas Sterbenz" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, May 14, 2001 10:48 PM
Subject: Re: keyCertSign and Path Validation


> It is intentional.  I do not recall all of the reasons.  One reason was to
> permit support for version 1 certificates. A version 1 certificate cannot
> be part of a certification path if we handle it differently.
>
> Russ
>
> At 01:55 PM 5/14/2001 +0200, Andreas Sterbenz wrote:
> >All,
> >
> >new-part1-06 states in section 6.1.4 (Preparation for Certificate i+1)
that
> >
> >   (n) If a key usage extension is present and marked critical,
> >   verify that the keyCertSign bit is set.
> >
> >A certificate that fails this check is rejected. However, this means that
a
> >certificate with a non-critical key usage extension is always accepted,
even
> >if the keyCertSign bit is not set.
> >
> >I am wondering if that behavior is intentional as it seems to conflict
with
> >the text describing the key usage and basic constraints extension.
> >
> >  Andreas Sterbenz              mailto:[e-mail]
>



Received: by above.proper.com (8.9.3/8.9.3) id PAA24159 for ietf-pkix-bks; Tue, 15 May 2001 15:46:56 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA24144 for <[e-mail]>; Tue, 15 May 2001 15:46:49 -0700 (PDT)
Received: from [128.33.238.68] (TC069.BBN.COM [128.33.238.69]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA05713; Tue, 15 May 2001 18:46:50 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010406b72760acb0bf@[128.33.238.68]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <000801c0c6a7$60e9d870$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 15 May 2001 18:45:26 -0400
To: "David A. Cooper" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: cA flag and CRL issuers (was Re: Last Call:   draft-ietf-pkix-new-part1-06.txt comments)
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Dave,

I provided an analysis of the evolution of CRL signing from V1 + V2 
certs, to the changes you cite re V3 certs.  You have chosen to 
ignore large parts of this analysis, and focus on text in the current 
version of X.509 that emphasizes syntactic details but not the larger 
semantic context. You have not adressed the fact that both X.509 and 
RFC 2459 make repeated references to "authorities" or CAs re CRL 
issuance. You have received feedback from Sharon, and I think several 
of the 2459 authors have weighed in on this topic during the 
multi-week debate.

I see no point in continuing the discussion.

Steve


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id PAA20950 for ietf-pkix-bks; Tue, 15 May 2001 15:12:44 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA20939 for <[e-mail]>; Tue, 15 May 2001 15:12:37 -0700 (PDT)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id SAA16971 for <[e-mail]>; Tue, 15 May 2001 18:12:39 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Tue, 15 May 2001 18:11:05 -0400
To: [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: Re: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments)
In-Reply-To: <p05010401b710bf7aa776@[128.33.238.42]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <000801c0c6a7$60e9d870$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_34911567==_.ALT"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--=====================_34911567==_.ALT
Content-Type: text/plain; charset="us-ascii"

At 05:31 PM 4/28/01 -0400, Stephen Kent wrote:
>So, my "interpretation" of the CA bit is simple; it identifies a cert as belonging to a CA and used to validate certs or CRLs. This is consistent with the notion that the bit needs to be set whenever the processing of the object using the public key from the cert is constrained by the presence or absence of that bit.

I still can not find any text that justifies the requirements that you claim to exist. X.509 clearly states:

         The cA component indicates if the certified public key may be used to verify certificate signatures

         if the value of cA is not set to true then the certified public key shall not be used to verify a
         certificate signature

         If this extension is not present, or is flagged non-critical and is not recognized by a
         certificate-using system, then the certificate is to be considered an end-entity certificate
         and cannot be used to verify certificate signatures

These statement clearly impose a requirement on certificate issuers to include basicConstraints with cA=true if the subject public key in the certificate is to be used to verify signatures on certificates. The third quote seems to impose a requirement on relying parties to check for the presence of basicConstraints with cA=true before using a subject public key to verify signatures on certificates. Where is the corresponding text for CRLs?

You seem to suggest that the requirement exists implicitly as a result of a requirement for only CAs to issue CRLs. However, according to the text in X.509, the cA bit does not indicate whether or not the certificate subject is a CA. It only indicates whether the particular subject public key may be used to verify signatures on certificates.

I think the proper interpretation of a requirement that only CAs can issue CRLs is that it imposes a requirement on certificate issuers to only set the cRLSign bit in a certificate if the subject is a CA. If only CAs can issue CRLs, and certificate has the cRLSign bit set, then the relying party should be able to conclude that the subject of the certificate is a CA. Given this, why should the relying party need to check to see if the cA bit is set (a bit that merely indicates whether the subject public key can be used to verify signatures on certificates)? There are certainly no security implications.

>>  From what I have read so far, it appears that you believe that the cA bit should be used to indicate if the subject of the certificate is a CA. But, if this is the case, then new-part1-06 still does not accurately reflect your notion of the cA bit. Currently the text states that the cA bit may only be set if the keyCertSign bit or the cRLSign bit in keyUsage is set. However, a CA does more than just issue certificates and CRLs. A CA may have a private key dedicated to signing PKI transaction messages (e.g., certification response, revocation response, proof-of-possession challenge). If a certificate were issued to a CA with its PKI transaction message verification key as the subject public key, neither the keyCertSign nor the cRLSign bit in KeyUsage would be set, but the subject of the certificate would still be a CA.
>
>This is an example where the processing of the signature on the signed object is not constrained by the presence or absence of the CA bit. I think the text you cite about setting the CA bit ONLY when other bits are set should be reviewed; it may be fine as is, but we need to decide whether we backed into this characterization or whether we mean exactly what it says.

Again, other than for verifying the signature on a certificate, where is the use of a public key to verify a signature constrained by the presence or absence of the cA bit? You claim that X.509 requires CRL issuers to be CAs, but that is not sufficient to demonstrate a requirement with respect the cA bit. If X.509 stated that the cA bit indicates whether the subject is a CA, then perhaps you would be correct in claiming that such a processing requirement exists. However, X.509 is very clear about the meaning of the cA bit, and it states that the cA bit is simply an indicator of whether the subject public key may be used to verify signatures on certificates.

>>So, should the cA bit be used to indicate if the certificate subject is a CA or to indicate that the subject public key may be used to verify signatures on certificates and/or CRLs? If the latter, then not all certificates issued to CAs will have the cA bit set.
>
>A fair question. My answer above would say that not all certs employed by a CA would have to have the bit set, e.g., because some objects signed using a key associated with a CA are employed in protocols that do not mandate checking the CA flag.

So, does this mean that the cA bit is not fully defined? There are some cases where the bit should definitely be set, others where it should definitely not be set, and then other times when proper value for the bit is undetermined. Somehow a definition of "the cA flag should be set when the subject public key may be employed in protocols that mandate checking the cA flag" seems inappropriate.

The cA bit should be a source of information. CAs should know when the bit should or should not be set and relying parties should know what it means when the bit is or is not set. How can certificate processing requirements be meaningful if the data in the certificates that is used in the processing has no meaning?

Dave


--=====================_34911567==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
At 05:31 PM 4/28/01 -0400, Stephen Kent wrote:<br>
<blockquote type=cite cite>So, my &quot;interpretation&quot; of the CA
bit is simple; it identifies a cert as belonging to a CA and used to
validate certs or CRLs. This is consistent with the notion that the bit
needs to be set whenever the processing of the object using the public
key from the cert is constrained by the presence or absence of that
bit.</blockquote><br>
I still can not find any text that justifies the requirements that you
claim to exist. X.509 clearly states:<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>The
<font size=2>cA</font> component indicates if the certified public key
may be used to verify certificate signatures<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>if the
value of <font size=2>cA</font> is not set to true then the certified
public key shall not be used to verify a<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>certificate
signature<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>If this
extension is not present, or is flagged non-critical and is not
recognized by a<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>certificate-using
system, then the certificate is to be considered an end-entity
certificate<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>and cannot
be used to verify certificate signatures<br>
<br>
These statement clearly impose a requirement on certificate issuers to
include basicConstraints with cA=true if the subject public key in the
certificate is to be used to verify signatures on certificates. The third
quote seems to impose a requirement on relying parties to check for the
presence of basicConstraints with cA=true before using a subject public
key to verify signatures on certificates. Where is the corresponding text
for CRLs?<br>
<br>
You seem to suggest that the requirement exists implicitly as a result of
a requirement for only CAs to issue CRLs. However, according to the text
in X.509, the cA bit does not indicate whether or not the certificate
subject is a CA. It only indicates whether the particular subject public
key may be used to verify signatures on certificates.<br>
<br>
I think the proper interpretation of a requirement that only CAs can
issue CRLs is that it imposes a requirement on certificate issuers to
only set the cRLSign bit in a certificate if the subject is a CA. If only
CAs can issue CRLs, and certificate has the cRLSign bit set, then the
relying party should be able to conclude that the subject of the
certificate is a CA. Given this, why should the relying party need to
check to see if the cA bit is set (a bit that merely indicates whether
the subject public key can be used to verify signatures on certificates)?
There are certainly no security implications.<br>
<br>
<blockquote type=cite cite><blockquote type=cite cite>&nbsp;From what I
have read so far, it appears that you believe that the cA bit should be
used to indicate if the subject of the certificate is a CA. But, if this
is the case, then new-part1-06 still does not accurately reflect your
notion of the cA bit. Currently the text states that the cA bit may only
be set if the keyCertSign bit or the cRLSign bit in keyUsage is set.
However, a CA does more than just issue certificates and CRLs. A CA may
have a private key dedicated to signing PKI transaction messages (e.g.,
certification response, revocation response, proof-of-possession
challenge). If a certificate were issued to a CA with its PKI transaction
message verification key as the subject public key, neither the
keyCertSign nor the cRLSign bit in KeyUsage would be set, but the subject
of the certificate would still be a CA.</blockquote><br>
This is an example where the processing of the signature on the signed
object is not constrained by the presence or absence of the CA bit. I
think the text you cite about setting the CA bit ONLY when other bits are
set should be reviewed; it may be fine as is, but we need to decide
whether we backed into this characterization or whether we mean exactly
what it says.</blockquote><br>
Again, other than for verifying the signature on a certificate, where is
the use of a public key to verify a signature constrained by the presence
or absence of the cA bit? You claim that X.509 requires CRL issuers to be
CAs, but that is not sufficient to demonstrate a requirement with respect
the cA bit. If X.509 stated that the cA bit indicates whether the subject
is a CA, then perhaps you would be correct in claiming that such a
processing requirement exists. However, X.509 is very clear about the
meaning of the cA bit, and it states that the cA bit is simply an
indicator of whether the subject public key may be used to verify
signatures on certificates.<br>
<br>
<blockquote type=cite cite><blockquote type=cite cite>So, should the cA
bit be used to indicate if the certificate subject is a CA or to indicate
that the subject public key may be used to verify signatures on
certificates and/or CRLs? If the latter, then not all certificates issued
to CAs will have the cA bit set.</blockquote><br>
A fair question. My answer above would say that not all certs employed by
a CA would have to have the bit set, e.g., because some objects signed
using a key associated with a CA are employed in protocols that do not
mandate checking the CA flag.</blockquote><br>
So, does this mean that the cA bit is not fully defined? There are some
cases where the bit should definitely be set, others where it should
definitely not be set, and then other times when proper value for the bit
is undetermined. Somehow a definition of &quot;the cA flag should be set
when the subject public key may be employed in protocols that mandate
checking the cA flag&quot; seems inappropriate.<br>
<br>
The cA bit should be a source of information. CAs should know when the
bit should or should not be set and relying parties should know what it
means when the bit is or is not set. How can certificate processing
requirements be meaningful if the data in the certificates that is used
in the processing has no meaning?<br>
<br>
Dave<br>
<br>
</html>

--=====================_34911567==_.ALT--



Received: by above.proper.com (8.9.3/8.9.3) id IAA22745 for ietf-pkix-bks; Tue, 15 May 2001 08:34:08 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA22731 for <[e-mail]>; Tue, 15 May 2001 08:33:59 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA08459 for <[e-mail]>; Tue, 15 May 2001 17:34:00 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 15 May 2001 17:34:00 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id RAA04028 for <[e-mail]>; Tue, 15 May 2001 17:33:59 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA02489 for [e-mail]; Tue, 15 May 2001 17:33:58 +0200 (MET DST)
Date: Tue, 15 May 2001 17:33:58 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: CRL signing certificats
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I would like to know the position of the group concerning
certificates for CRL signing. If I resume the previous
discussions then it seems to me that it is possible
to have 

- separate signing keys and certificates for crl and cert signing.
- that a crl signing certificate can have the same DN as CA
  in order to avoid an extension.

If this is the case, then it seems to me that the comment on
page 60 concerning self issued certificates may need some
clarification. 


Received: by above.proper.com (8.9.3/8.9.3) id AAA11352 for ietf-pkix-bks; Tue, 15 May 2001 00:20:56 -0700 (PDT)
Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.121.85]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA11310 for <[e-mail]>; Tue, 15 May 2001 00:20:48 -0700 (PDT)
Received: from [10.0.1.2] (user-38ldjsb.dialup.mindspring.com [209.86.207.139]) by gull.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id AAA28053; Tue, 15 May 2001 00:19:46 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <a05100312b7268608ad11@[10.0.1.2]>
Date: Tue, 15 May 2001 00:17:21 -0700
To: "X.509":;
From: "Hoyt L. Kesterson II" <[e-mail]>
Subject: a new version of the 4th edition of x.509
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Hello all

Believe it or not, the ITU is very close to publishing the new 4th 
edition. During the final document shakedown we found a number of 
very minor editorials.

I have posted that new version upon the server in pdf and word formats at

 
ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X509_4thEditionDraftV8.doc 
and

 
ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X509_4thEditionDraftV8.pdf

Newly revised drafts of the 4th edition of the other parts of X.500 
are also available at the same server in

    ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts

I am beginning to feel like chicken littlle in warning you that I am 
about to remove X.509 from this server. However, I have seen the 
FINAL text this week and ITU and ISO are very close to publishing.

But as I said before, ITU is allowing any three recommendations to be 
downloaded at no cost from their server. It is an interesting 
experiment that they are evaluating for 2001. For more information see

    http://www.itu.int/publications/bookshop/how-to-buy.html

Be gentle

   hoyt
-- 


Received: by above.proper.com (8.9.3/8.9.3) id NAA09662 for ietf-pkix-bks; Mon, 14 May 2001 13:52:06 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id NAA09652 for <[e-mail]>; Mon, 14 May 2001 13:51:53 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 14 May 2001 20:51:31 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA04016 for <[e-mail]>; Mon, 14 May 2001 16:51:53 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <JY8NXZ0F>; Mon, 14 May 2001 16:51:52 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.15]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JY8NXZ0D; Mon, 14 May 2001 16:51:49 -0400
From: "Housley, Russ" <[e-mail]>
To: Andreas Sterbenz <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 14 May 2001 16:48:51 -0400
Subject: Re: keyCertSign and Path Validation
In-Reply-To: <006401c0dc6c$bd00f870$4c981b81@kant>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

It is intentional.  I do not recall all of the reasons.  One reason was to 
permit support for version 1 certificates. A version 1 certificate cannot 
be part of a certification path if we handle it differently.

Russ

At 01:55 PM 5/14/2001 +0200, Andreas Sterbenz wrote:
>All,
>
>new-part1-06 states in section 6.1.4 (Preparation for Certificate i+1) that
>
>   (n) If a key usage extension is present and marked critical,
>   verify that the keyCertSign bit is set.
>
>A certificate that fails this check is rejected. However, this means that a
>certificate with a non-critical key usage extension is always accepted, even
>if the keyCertSign bit is not set.
>
>I am wondering if that behavior is intentional as it seems to conflict with
>the text describing the key usage and basic constraints extension.
>
>  Andreas Sterbenz              mailto:[e-mail]


Received: by above.proper.com (8.9.3/8.9.3) id EAA00386 for ietf-pkix-bks; Mon, 14 May 2001 04:58:03 -0700 (PDT)
Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA00382 for <[e-mail]>; Mon, 14 May 2001 04:57:55 -0700 (PDT)
Received: from kant [129.27.152.76] by iaik.tu-graz.ac.at (SMTPD32-6.06) id A83281A0100; Mon, 14 May 2001 13:57:38 +0200
Message-ID: <006401c0dc6c$bd00f870$4c981b81@kant>
From: "Andreas Sterbenz" <[e-mail]>
To: <[e-mail]>
Subject: keyCertSign and Path Validation
Date: Mon, 14 May 2001 13:55:14 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2462.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

All,

new-part1-06 states in section 6.1.4 (Preparation for Certificate i+1) that

  (n) If a key usage extension is present and marked critical,
  verify that the keyCertSign bit is set.

A certificate that fails this check is rejected. However, this means that a
certificate with a non-critical key usage extension is always accepted, even
if the keyCertSign bit is not set.

I am wondering if that behavior is intentional as it seems to conflict with
the text describing the key usage and basic constraints extension.

 Andreas Sterbenz              mailto:[e-mail]




Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id EAA13958 for ietf-pkix-bks; Sat, 12 May 2001 04:27:57 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA13939 for <[e-mail]>; Sat, 12 May 2001 04:27:49 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <KXJY5K35>; Sat, 12 May 2001 07:27:19 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Denis Pinkas <[e-mail]>, "Housley, Russ" <[e-mail]>
Cc: [e-mail], Tim Polk <[e-mail]>, "David A. Cooper" <[e-mail]>
Subject: RE: delta CRLs
Date: Sat, 12 May 2001 07:18:02 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DAD5.35616B40"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0DAD5.35616B40
Content-Type: text/plain;
	charset="iso-8859-1"

Denis:

You assumptions and recommendations may be appropriate for your environment
and PKIX should accommodate your design.  In my mind PKIX DOES accommodate
your design.

However, others may want to design PKI where the freshness of revocation
information is not guaranteed beyond nextUpdate, but could be published be
available, modulo network security assumptions.  In that scenario,
publishing revocation information via full or delta CRL's that are not
promised via nextxUpdate is also fine, knowing full well that the CA can not
guarantee that RP will be ensured of out of cycle CRL availability.

In short, RP knows that the non-repudiation between thisUpdate of CRL and
current time is up in air.

Thus, I am not in favor of the constraints on the CA you cited.

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Friday, May 11, 2001 12:58 PM
To: Housley, Russ
Cc: [e-mail]; Tim Polk; David A. Cooper
Subject: Re: delta CRLs


Russ, 

Thanks for this very detailed collective response.

I have been hoping to have a phone call with some of you today, but since
this had not been possible, here is an answer to your email.

FYI, I will be out of my office during three days, so do no expect a reply
before next Thursday.

The thread has been focussing on the mechanisms, forgetting what is the
rational about them. So let us come back to the rationals. One of them
relates top the use of CRLs when applied to a non repudiation service.

X.509 has been originally written to use CRLs for other security services
and for these other services, the problems are different.

We all want to be able to use either CRLs or OSCP responses for non
repudiation purposes. In fact we want to allow any of these two techniques
to be used in single or in combination. Right ?

Having said this, we can now explain some of the rational. 

When validating a digital signature, for a given time T, for non repudiation
purposes, it is important for a verifier to be able to prove that the
certificate was NOT revoked. It is also important that two different
verifiers come to the same result, for the same time T, because of the goal
of non repudiation is to solve disputes.

The same properties must be achieved whether OCSP or CRLs are used. When an
OCSP response is received with a time T in it, there can be no dispute about
it: it contains three possible answers (not revoked, revoked, don't know).
If an OCSP responder produces one such answer with a time T and one of the
three statuses, no one else can present an answer with the same time T in it
with a different answer from the same OCSP responder. Once again, it would
not be acceptable that at a given time T two opposite responses could be
obtained. This would result in disputes.

This means that at time T, there is must be one and only one possible
answer. This allows to use OCSP responses for non repudiation purposes. The
same property must be supported so that CRLs can be used for non repudiation
purposes. So the goal is that when using CRLs in the context of non
repudiation, only one response (i.e. not revoked, revoked, don't know) can
be obtained.

I do know that non repudiation is only one use of the PKI and that there are
other usages such as authentication, integrity and confidentiality. So let
us now describe what is necessary, if the CRL contains at least one
certificate that can be used for non repudiation purposes (e.g. it has the
NR bit set).

If at time T there is more than one CRL valid, then there is a possibility
to miss the most recent, in case there is a denial of service attack on it
(i.e. suppression of the latest CRL while in transit).

This means that "emergency" CRLs will not necessarily be seen. "Emergency"
CRLs may be used for authentication, integrity and confidentiality, but may
create problems when used in the context of non repudiation.

This has several implications: we should deprecate the use of "emergency"
CRLs for being used for a non repudiation service, because they could
provide two different responses. 

People using full CRLs, i.e. without taking advantage of the delta CRLs,
would get only one result.

People using base CRLs and thus taking advantage of the delta CRLs would
also get one single result. For that reason we should also deprecate the use
of "emergency" delta CRLs.

This now explains why it is important to get one answer, at most, at a time.
I do understand that lacking this information, the mechanism seems to be
constrained without any "good" reason.

Now how can a verifier be sure to get the freshest information ?

This depends on the verification rules. Let us restrict the discussion to
the leaf certificate.

If the validation rules (be careful this has strong relationships with the
DPV protocol) say : "use full CRLs only" and there is no "emergency CRL",
then everything works nice.

If the validation rules say: "use the freshest information that is provided
by the CA", then the question is how can a verifier know how the freshest
information is obtained ? The answer is: only through extensions. Why ?

Let us assume first that no extension either in the certificate or the CRL
is being used. The answer would be : make a search for delta CRLs in the
directory. The problem is that, in case a denial of service attack, the
delta CRLs, even if they exist, will not be "seen". So the verifier will use
the base CRL and thus two verifications done at the same time T will provide
two different results. :-(

So there needs to be some way, so that, in the event of a denial of service
attacks, either the right information is obtained or that no information at
all is obtained. In the later case, if the revocation information is not
found, then the signature is not accepted (in some cases a try can be done
later on).

A consequence is the following: verifiers must know without ambiguity
whether a delta CRL mechanism is supported, so that if delta CRL are
supported it is possible to know unambiguously that it is the case. 

There are two options. 

1) Should we use the freshestCRL extension from the leaf certificate ? This
means that the CA MUST support delta CRLs at any time during whole the
life-time of the certificate. This is quite constraining for the CA, but
this is possible.

2) Should we use the freshestCRL extension from the CRL? This means that the
CA will only support delta CRLs for that CRL without any engagement to
support a delta CRL mechanism for the next one. This is more flexible.

What does this means ? That it is very likely that we will not end up wit
the same mechanism when using delta CRLs for a certificate used for non
repudiation purposes and when using a certificate for other purposes. One of
the algorithms may look first at the delta CRLs, whether they exist or not,
while the other will only take a look for them after making sure that they
must exit.

The best guess, if it succeeds, is certainly valid for "other purposes". So
I will now focus on the algorithm to be used for non repudiation purposes.

   An application that is willing to obtain the freshest CRL 
   information for a given certificate used for non repudiation 
   purposes, must know if a delta CRL mechanism is supported. 
   Either the certificate or any CRL that is able to reference 
   that certificate MUST include a freshestCRL extension 
   (a.k.a. a Delta CRL distribution point). 

   The application may then construct an updated CRL for that 
   base, for a specific time T, by combining it with a delta 
   CRL which contains a delta CRL indicator extension with the 
   same CRL number as the base CRL. Applications that support 
   delta CRLs MUST ensure that time T falls between thisUpdate 
   and nextUpdate for both the base CRL and the delta CRL.

   Note: An application could also reconstruct an updated CRL, 
   for a specific time T, by using a previously locally 
   reconstructed CRL based on the current base CRL, and 
   combining it with a delta CRL which contains a delta CRL 
   indicator extension with the same CRL number as the base 
   CRL.

For the constraint about the CA:

   For any CRL that may reference a certificate used for 
   non repudiation purposes, and for any time T until 
   the nextUpdate time indicated in a base CRL, the CA MUST 
   provide one and only one base CRL and one and only delta 
   CRL that refers to that base CRL and for which time T 
   falls between thisUpdate and nextUpdate from the delta CRL.

There are still other issues to discuss, like the CRL numbering,
whether it is unique or not, let us wait for next week for that topic.

Regards,

Denis


> Denis:
> 
> Please excuse the half-done message from this morning.  My mailer and I
had
> a disagreement...
> 
> Anyway, since I was not going to get the full message out before the end
of
> the business day in France, I took the time to coordinate a response with
> Tim Polk and David Cooper.  This mail thread is quite long, so hopefully
> our coordination on the side will reduce the overall number of messages to
> the list and help to reach consensus faster.
> 
> Here goes ....
> 
>  >There is difference between a base CRL and a full CRL : a base CRL MUST
>  >include a freshestCRL extension (a.k.a. a Delta CRL distribution point),
>  >whereas a full CRL may not include that extension. In other words, a
base
>  >CRL is a also a full CRL, but a full CRL is not necessarily a base CRL.
> 
> There is no requirement in X.509 to include any extension in a certificate
> or CRL advertising the availability of delta CRLs. PKIX makes the
> freshestCRL extension available for advertising the existence of delta
> CRLs, but again does not mandate its use. Furthermore, even if the
> freshestCRL extension is used, it may be placed in either the certificate
> or the full CRL. If the extension is placed in certificates, there is no
> need for it to be in the full CRL (but, it could be).
> 
> Finally, if delta CRLs are being issued, and are being advertised through
> the freshestCRL CRL extension, then the extension should be included in
all
> full CRLs for that scope, not just the base CRLs. If a relying party
> obtains the most recently issued full CRL for a scope from a repository,
> and that full CRL is not a base CRL, how will the relying party know that
> delta CRLs are available?
> 
>  >At any time a CA may issue a full CRL, whether or not a base CRL has
already
>  >been issued. This additional CRL SHOULD have nextUpdate equal to the
>  >nextUpdate of the last issued full CRL. However, there is no guarantee
that
>  >this additional CRL will ever be seen by the relying party (because
there
>  >will be two CRLs matching the thisUpdate and nextUpdate rule and if one
is
>  >deleted, this is not seen by a relying party).
> 
> The nextUpdate field in a full CRL (base or otherwise) should specify the
> time by which new revocation information will be available. So, if a new
> base CRL is issued once a day, but full CRLs are issued every hour, the
> nextUpdate field of each full CRL should one hour after that CRL's
> thisUpdate time.
> 
>  >Due to the fact that CRLs numbers are strictly increasing, two CRLs
whether
>  >they are a base CRL or delta CRL, CANNOT have the same CRL number. So a
>  >delta CRL and a full CRL that cover the same scope and are issued at the
>  >same time CANNOT have the same number.
> 
> We disagree.  If a full CRL and a delta CRL are issued at the same time
for
> the same scope, then they ARE the same CRL and MUST have the same CRL
number.
> 
>  >If a full CRL is issued, its CRL
>  >number bears no relationship with the previous base CRL, if any.
> 
> Again, we disagree. A sequence of CRLs for a given scope must contain a
> monotonically increasing sequence of CRL numbers. Relying parties that do
> not process delta CRLs, and thus do not recognize the non-critical
> freshestCRL extension, will not be able to distinguish between those full
> CRLs that are base CRLs and those full CRLs that are not base CRLs. The
CRL
> numbers for these full CRLs must be from one monotonically increasing
sequence.
> 
>  >The only
>  >relationship between the numbers is defined by the rule that CRLs
numbers
>  >are strictly increasing. As Santosh said : "the CRL number is unique
>  >whether it is a base or a delta ".
>  >
>  >This is fairly important to be able to unambiguously (and thus uniquely)
>  >refer to a CRL by only providing its CRL number.
> 
> Exactly. If a full CRL and the delta CRL are issued for the same scope at
> the same time, they are the same CRL. The CRL number unambiguously and
> uniquely refers to this ONE CRL.
> 
>  >Besides the fact that a CRL issued later MUST have a higher CRL number,
full
>  >CRLs and delta CRLs have independent numbering rules. As noticed by
Santosh,
>  >" if the delta thisUpdate > base thisUpdate, delta CRL number > base CRL
>  >number (for the same or no stream identifier).
> 
> If you agree that delta thisUpdate > base thisUpdate implies delta CRL
> number > base CRL, then you are acknowledging that the CRL numbers of the
> full CRLs and delta CRLs are not independent.
> 
>  >As Santosh said : "a check based on thisUpdate is more general and
>  >preferred [to the use of CRL numbers]. "
>  >
>  >Related to the three rules mentioned by Russ :
>  >
>  >1) the first rule is not understandable to me.
>  >2) the second rule does not say anything more than the basic rule valid
>  >    for any CRL (i.e. a CRL issued later MUST have a higher CRL number).
>  >3) we will debate the hold condition, once we will have sorted the main
>  >    issue.
>  >
>  >Russ said : "If separate number sequence is used, then you will have to
>  >periodically fetch base CRLs ". This is true.
>  >
>  >Tim said that he would *not* like to be forced to download new base
CRLs.
>  >This is the core of the "dispute".
> 
> Our goal should be to allow delta CRL enabled clients to obtain accurate
> information in the most efficient manner possible. Forcing clients to
> periodically download full CRLs, when this is not necessary, is
inefficient.
> 
>  > From the definition of what a delta CRL is, it is *not* possible to
>  >get rid of the fetching of base CRLs. Unless we add a new sentence to
>  >expand/change that definition, base CRL fetching will remain mandatory.
> 
> True. However, if one performs validations frequently enough, it is
> possible to obtain a single full CRL and then subsequently download only
> delta CRLs. We need to require that full CRL be issued periodically so
that
> clients whose locally stored information is not sufficiently up-to-date to
> apply the delta CRLs being issued can obtain the full CRLs that they need,
> but we should not require clients to download full CRLs when it is not
> necessary for them to do so.
> 
>  >Remember that the goal of delta CRLs is to provide the freshest
information,
>  >and to my knowledge the goal was not to get rid of the fetching of base
CRLs
>  >(which may less frequent due to the support of delta CRLs).
> 
> Yes, but the goal should be to minimize the fetching of full CRLs.
> 
>  >If I understand correctly, Tim/David/Russ would like to *always* achieve
the
>  >following property : it is possible to reconstruct the current CRL by
using
>  >a base CRL from, e.g. 1990, i.e. by capturing every delta CRL that has
been
>  >issued at the same time a base CRL was issued and which contains updates
>  >made to the *previous* base.
>  >
>  >By this way the fetching of base CRLs could be avoided. However, note
that
>  >it is perfectly " legal " to stop issuing base and delta CRLs during
some
>  >period of time and to issue full CRLs instead (see the difference
between
>  >"full" and "base" at the top of this e-mail). In other words there is no
>  >need to issue a new base CRL at the end of the validity period of the
>  >previous base CRL. Doing this would mandate to prescribe issuing rules
>  >for CAs that we have not prescripted.
> 
> You are mixing apples and oranges. Obviously the scheme of keeping
> up-to-date by obtaining a base from 1990 and then only downloading deltas
> will only work so long as deltas continue to be issued. If the CRL issuer
> ceases to issue deltas, then the relying parties will have to revert to
> downloading full CRLs.
> 
>  >I will now raise a series of questions, for which I believe we have
>  >different answers. Tim/David/Russ do not hesitate to correct
>  >if my guess is wrong. ;-)
>  >
>  >Common point:
>  >
>  >1) What will be the value of the nextUpdate field from the last issued
delta
>  >CRL for a given base CRL ?
>  >
>  >Denis: the nextUpdate field from the last issued delta CRL MUST be equal
to
>  >the value of nextUpdate from the base CRL.
>  >
>  >Tim/David/Russ: ???
> 
> The nextUpdate field in a base CRL states when the next full CRL will be
> available. This is important for supporting clients that do not handle
> delta CRLs. The nextUpdate field in a delta CRL states when the next CRL
> (either a delta CRL or a full CRL) will be available. As a general rule,
if
> the CA is continuing to issue deltas, the nextUpdate in the delta will be
> the time by which the next delta will be available. If this is the last
> delta that the CA is going to issue, then the nextUpdate in the delta will
> be the time by which the next full CRL will be available. ("Available"
> SHOULD reflect distribution delays associated with the repository
> architecture.)
> 
>  >2) Does a CA needs to issue a delta CRL at the time a full CRL is issued
?
>  >
>  >Denis: No.
>  >Tim/David/Russ : ???
> 
> No. A CA never is required to issue deltas. However, it would be helpful
to
> delta CRL enabled clients to allow them to construct the full CRL.
> 
> If the full CRL contains a freshestCRL extension, then it is a very good
> idea to generate a delta CRL at the same time. In this way, any client
will
> be able to find a current delta CRL.
> 
>  >3) Does a CA needs to issue a new base CRL at the end of the validity of
a
>  >current base CRL ?
>  >
>  >Denis: No.
>  >Tim/David/Russ : ???
> 
> No. HOWEVER, the CA must issue a new full CRL by the nextUpdate in the
> previously issued full CRL (whether that full CRL is a base CRL or not).
> There is no requirement that the next full CRL be a base CRL. (The CA
could
> quit issuing deltas, etc. etc.)
> 
> Every base CRL MUST be a full CRL, but not every full CRL is a base CRL.
> But, a CA could make every full CRL a base CRL if they wanted to.
> 
>  >4) Does a CA needs to issue a delta CRL at the same time a new base is
>  >issued ?
>  >
>  >Denis: Yes. The delta CRL refers to the *new* base.
>  >Tim/David/Russ : ???
> 
> No. HOWEVER, in practice we belive that CAs will do so. The delta CRL
needs
> to exist so that clients can follow the freshest CRL extension (either in
a
> certificate or a base CRL). The delta CRL that is issued at the same time
> SHOULD point to a previously issued full CRL (which will then, by
> definition be a base CRL) whenever possible. There is no information to
add
> to the new base CRL! By providing the delta as an update to a previous
base
> CRL, clients can download the delta CRL to construct the new base CRL.
> 
>  >The last point highlights the most noticeable difference. Other
differences
>  >appears when considering the guaranty to get the freshest information :
>  >using the traditional scheme and the thisUpdate and nextUpdate fields
the
>  >guaranty to get the freshest information is obtained, but cannot be
obtained
>  >using the other scheme. :-(
>  >
>  >Several people are referring to the X.509 document for arguments to
support
>  >that discussion. However, it is important to remember that we are
defining
>  >PKIX, not X.509, so we DO NOT need to copy and paste everything from
X.509,
>  >but only what we believe is relevant.
> 
> PKIX is a profile of X.509.  PKIX may impose additional requirements
beyond
> those in X.509 or may exclude features that are optional in X.509, but
> otherwise PKIX must be consistent with X.509. In that context, references
> to X.509 are appropriate.
> 
>  >We first need to clearly define the processing rules applicable to the
>  >relying parties. These rules will certainly contain SHALL/MUST
statements,
>  >but may also include some MAY statements which may even be conditional
to
>  >what the CA is doing. (I let Tim/David or Russ provide the MAY
statement).
>  >
>  >Here is a proposal for the MUST statement, based on the previous text I
>  >produced:
>  >
>  >    An application that is wishing to take advantage of delta CRLs
>  >    for a given scope, MUST first find a base CRL for that scope,
>  >    i.e. a full CRL that that contains a freshestCRL extension
>  >    (a.k.a. a Delta CRL distribution point).
> 
> No. The relying party needs a full CRL (either one that has been
downloaded
> from a repository or one that has been locally generated) against which
the
> delta CRL of interest may be applied. There is no requirement that the
full
> CRL be a base CRL.
> 
>  >    It may then construct
>  >    an updated CRL for that base, for a specific time T, by combining
>  >    it with a delta CRL which contains a delta CRL indicator extension
>  >    with the same CRL number as the base CRL.
> 
> It may construct an updated CRL by combining the delta CRL with any full
> CRL whose CRL number is greater than or equal to the CRL number of the
> referenced base.  By saying "equal" instead of "greater than or equal" we
> would be hiding useful information from implementors. We should not be
> hiding useful information.
> 
>  >    Applications that support
>  >    delta CRLs MUST ensure that time T falls between thisUpdate and
>  >    nextUpdate for both the base CRL and the delta CRL.
> 
> As stated above, the nextUpdate field in a base CRL specifies the time by
> which new revocation information will be available through full CRLs. A
> delta CRL may be applied to a base CRL as long as the CRL number in the
> base CRL is greater than or equal to the CRL number of the base CRL
> referenced by the delta CRL. The nextUpdate time of the base CRL is
irrelevant.
> 
>  >    Note: An application could also reconstruct an updated CRL, for
>  >    a specific time T, by using a previously locally reconstructed CRL
>  >    based on the current base CRL, and combining it with a delta CRL
which
>  >    contains a delta CRL indicator extension with the same CRL number as
>  >    the base CRL.
> 
> Same problem as above.  Need to say "greater than or equal to".
> 
>  >We also need to clearly separate the issuing rules applicable for the
CAs.
>  >These rules will certainly contain SHALL statements, but could also
include
>  >some MAY statements. (I let Tim/David or Russ provide the MAY
statement).
>  >
>  >Here is a proposal for the MUST statement, based on the previous text I
>  >produced:
>  >
>  >    A CA that supports delta-CRLs, MUST issue a base CRL,
> 
> This is an unnecessary statement. A delta CRL must include a
BaseCRLNumber.
> The CRL specified by that BaseCRLNumber is by definition a base CRL.  Of
> course, the referenced base CRL MUST be a full CRL.
> 
>  >    i.e. a full
>  >    CRL that contains a freshestCRL extension (a.k.a. a Delta CRL
>  >    distribution point).
> 
> While it might be a good idea to mandate the inclusion of the frestestCRL
> extension in full CRLs that are issued for scopes in which delta CRLs are
> also being issued, there is currently no such requirement in the draft
PKIX
> profile.
> 
>  >    For any time T until the nextUpdate time
>  >    indicated in a base CRL, the CA MUST provide one and only one
>  >    delta CRL that refers to that base CRL and for which time T
>  >    falls between thisUpdate and nextUpdate from the delta CRL.
> 
> This sentence has several problems:
> 
> 1) The nextUpdate time of a base CRL is the time when the next full CRL
> will be available, which may precede the time that the next base CRL will
> be issued.
> 
> 2) There is no requirement that a delta CRL use the most recently issued
> base CRL as its base.  I suppose that we could add this requirement for
the
> PKIX profile, but why?  Does it really simplify the client?  Or, does it
> just make it a wee bit harder to make a conforming CA that supports delta
CRLs?
> 
> 3) If the thisUpdate time of one delta CRL must equal the nextUpdate time
> of the previously issued delta CRL, then no time can be allotted to
account
> for propagation delays between when a delta-CRL is issued and when it is
> available in repositories for relying parties to obtain. Thus, there would
> be gaps between when the nextUpdate time of one delta-CRL was reached and
> when the next delta-CRL was available.
> 
> 4) There is nothing in either X.509 or the PKIX profile that prevents a CA
> from issuing an unscheduled (or "emergency") delta CRL. And, there should
> not be!  Many CAs intend to issue a new CRL (delta or otherwise)
> immediately upon the revocation of a certificate due to key compromise.
> When such an "emergency" delta CRL is issued, there will be two delta CRLs
> for which T falls between thisUpdate and nextUpdate. While it is true that
> there is no guarantee that relying parties will obtain the fresher of
these
> two delta CRLs, that is no reason to prevent the CA from issuing the
> "emergency" delta.  Some clients will obtain the emergency CRL.
> 
>  >In his e-mail from Wednesday, May 9, David said that delta-CRL
processing
>  >rules could be base on time instead of CRL numbers. This is a point of
which
>  >I strongly agree. Let us do it!
>  >
>  >(However, there is no need to add to PKIX, as he suggested, the support
of
>  >the baseUpdateTime extension from X.509 which would even more complicate
the
>  >problem.)
> 
> No. In order to base delta CRL processing on time, the baseUpdateTime
> extension must be present in the delta CRL. Furthermore, the presence of
> this extension would not complicate the problem. baseUpdateTime is a
> non-critical extension that merely provides useful information. If you
> don't think that the information provided by baseUpdateTime is useful,
> ignore it. Since the extension is non-critical and can be ignored, its
> presence can not complicate the problem.
> 
> At 09:05 AM 5/10/2001 -0400, Housley, Russ wrote:
> >Denis:
> >
> >>There is difference between a base CRL and a full CRL
> >
> >You are quite right.  I, for one, will try to be more careful about the
> >use of them.
> >
> >>Due to the fact that CRLs numbers are strictly increasing, two CRLs
whether
> >>they are a base CRL or delta CRL, CANNOT have the same CRL number.
> >
> >I disagree.  A full CRL (that may be a base CRL for subsequent delta
CRLs)
> >and a delta CRL issued at the same time as that full CRL may actually
> >represent the same revocation information.  In this case, they are the
> >same CRL, and they should have the same number.  There have been several
> >tables posted that illustrate this numbering scheme, and I do not see any
> >text in X.509-200 that indicates this scheme is
> [snip - truncate - the message is too long anyway]

------_=_NextPart_001_01C0DAD5.35616B40
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: delta CRLs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Denis:</FONT>
</P>

<P><FONT SIZE=3D2>You assumptions and recommendations may be =
appropriate for your environment and PKIX should accommodate your =
design.&nbsp; In my mind PKIX DOES accommodate your design.</FONT></P>

<P><FONT SIZE=3D2>However, others may want to design PKI where the =
freshness of revocation information is not guaranteed beyond =
nextUpdate, but could be published be available, modulo network =
security assumptions.&nbsp; In that scenario, publishing revocation =
information via full or delta CRL's that are not promised via =
nextxUpdate is also fine, knowing full well that the CA can not =
guarantee that RP will be ensured of out of cycle CRL =
availability.</FONT></P>

<P><FONT SIZE=3D2>In short, RP knows that the non-repudiation between =
thisUpdate of CRL and current time is up in air.</FONT>
</P>

<P><FONT SIZE=3D2>Thus, I am not in favor of the constraints on the CA =
you cited.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Denis Pinkas [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Friday, May 11, 2001 12:58 PM</FONT>
<BR><FONT SIZE=3D2>To: Housley, Russ</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]; Tim Polk; David A. =
Cooper</FONT>
<BR><FONT SIZE=3D2>Subject: Re: delta CRLs</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Russ, </FONT>
</P>

<P><FONT SIZE=3D2>Thanks for this very detailed collective =
response.</FONT>
</P>

<P><FONT SIZE=3D2>I have been hoping to have a phone call with some of =
you today, but since</FONT>
<BR><FONT SIZE=3D2>this had not been possible, here is an answer to =
your email.</FONT>
</P>

<P><FONT SIZE=3D2>FYI, I will be out of my office during three days, so =
do no expect a reply</FONT>
<BR><FONT SIZE=3D2>before next Thursday.</FONT>
</P>

<P><FONT SIZE=3D2>The thread has been focussing on the mechanisms, =
forgetting what is the</FONT>
<BR><FONT SIZE=3D2>rational about them. So let us come back to the =
rationals. One of them</FONT>
<BR><FONT SIZE=3D2>relates top the use of CRLs when applied to a non =
repudiation service.</FONT>
</P>

<P><FONT SIZE=3D2>X.509 has been originally written to use CRLs for =
other security services</FONT>
<BR><FONT SIZE=3D2>and for these other services, the problems are =
different.</FONT>
</P>

<P><FONT SIZE=3D2>We all want to be able to use either CRLs or OSCP =
responses for non</FONT>
<BR><FONT SIZE=3D2>repudiation purposes. In fact we want to allow any =
of these two techniques</FONT>
<BR><FONT SIZE=3D2>to be used in single or in combination. Right =
?</FONT>
</P>

<P><FONT SIZE=3D2>Having said this, we can now explain some of the =
rational. </FONT>
</P>

<P><FONT SIZE=3D2>When validating a digital signature, for a given time =
T, for non repudiation</FONT>
<BR><FONT SIZE=3D2>purposes, it is important for a verifier to be able =
to prove that the</FONT>
<BR><FONT SIZE=3D2>certificate was NOT revoked. It is also important =
that two different</FONT>
<BR><FONT SIZE=3D2>verifiers come to the same result, for the same time =
T, because of the goal</FONT>
<BR><FONT SIZE=3D2>of non repudiation is to solve disputes.</FONT>
</P>

<P><FONT SIZE=3D2>The same properties must be achieved whether OCSP or =
CRLs are used. When an</FONT>
<BR><FONT SIZE=3D2>OCSP response is received with a time T in it, there =
can be no dispute about</FONT>
<BR><FONT SIZE=3D2>it: it contains three possible answers (not revoked, =
revoked, don't know).</FONT>
<BR><FONT SIZE=3D2>If an OCSP responder produces one such answer with a =
time T and one of the</FONT>
<BR><FONT SIZE=3D2>three statuses, no one else can present an answer =
with the same time T in it</FONT>
<BR><FONT SIZE=3D2>with a different answer from the same OCSP =
responder. Once again, it would</FONT>
<BR><FONT SIZE=3D2>not be acceptable that at a given time T two =
opposite responses could be</FONT>
<BR><FONT SIZE=3D2>obtained. This would result in disputes.</FONT>
</P>

<P><FONT SIZE=3D2>This means that at time T, there is must be one and =
only one possible</FONT>
<BR><FONT SIZE=3D2>answer. This allows to use OCSP responses for non =
repudiation purposes. The</FONT>
<BR><FONT SIZE=3D2>same property must be supported so that CRLs can be =
used for non repudiation</FONT>
<BR><FONT SIZE=3D2>purposes. So the goal is that when using CRLs in the =
context of non</FONT>
<BR><FONT SIZE=3D2>repudiation, only one response (i.e. not revoked, =
revoked, don't know) can</FONT>
<BR><FONT SIZE=3D2>be obtained.</FONT>
</P>

<P><FONT SIZE=3D2>I do know that non repudiation is only one use of the =
PKI and that there are</FONT>
<BR><FONT SIZE=3D2>other usages such as authentication, integrity and =
confidentiality. So let</FONT>
<BR><FONT SIZE=3D2>us now describe what is necessary, if the CRL =
contains at least one</FONT>
<BR><FONT SIZE=3D2>certificate that can be used for non repudiation =
purposes (e.g. it has the</FONT>
<BR><FONT SIZE=3D2>NR bit set).</FONT>
</P>

<P><FONT SIZE=3D2>If at time T there is more than one CRL valid, then =
there is a possibility</FONT>
<BR><FONT SIZE=3D2>to miss the most recent, in case there is a denial =
of service attack on it</FONT>
<BR><FONT SIZE=3D2>(i.e. suppression of the latest CRL while in =
transit).</FONT>
</P>

<P><FONT SIZE=3D2>This means that &quot;emergency&quot; CRLs will not =
necessarily be seen. &quot;Emergency&quot;</FONT>
<BR><FONT SIZE=3D2>CRLs may be used for authentication, integrity and =
confidentiality, but may</FONT>
<BR><FONT SIZE=3D2>create problems when used in the context of non =
repudiation.</FONT>
</P>

<P><FONT SIZE=3D2>This has several implications: we should deprecate =
the use of &quot;emergency&quot;</FONT>
<BR><FONT SIZE=3D2>CRLs for being used for a non repudiation service, =
because they could</FONT>
<BR><FONT SIZE=3D2>provide two different responses. </FONT>
</P>

<P><FONT SIZE=3D2>People using full CRLs, i.e. without taking advantage =
of the delta CRLs,</FONT>
<BR><FONT SIZE=3D2>would get only one result.</FONT>
</P>

<P><FONT SIZE=3D2>People using base CRLs and thus taking advantage of =
the delta CRLs would</FONT>
<BR><FONT SIZE=3D2>also get one single result. For that reason we =
should also deprecate the use</FONT>
<BR><FONT SIZE=3D2>of &quot;emergency&quot; delta CRLs.</FONT>
</P>

<P><FONT SIZE=3D2>This now explains why it is important to get one =
answer, at most, at a time.</FONT>
<BR><FONT SIZE=3D2>I do understand that lacking this information, the =
mechanism seems to be</FONT>
<BR><FONT SIZE=3D2>constrained without any &quot;good&quot; =
reason.</FONT>
</P>

<P><FONT SIZE=3D2>Now how can a verifier be sure to get the freshest =
information ?</FONT>
</P>

<P><FONT SIZE=3D2>This depends on the verification rules. Let us =
restrict the discussion to</FONT>
<BR><FONT SIZE=3D2>the leaf certificate.</FONT>
</P>

<P><FONT SIZE=3D2>If the validation rules (be careful this has strong =
relationships with the</FONT>
<BR><FONT SIZE=3D2>DPV protocol) say : &quot;use full CRLs only&quot; =
and there is no &quot;emergency CRL&quot;,</FONT>
<BR><FONT SIZE=3D2>then everything works nice.</FONT>
</P>

<P><FONT SIZE=3D2>If the validation rules say: &quot;use the freshest =
information that is provided</FONT>
<BR><FONT SIZE=3D2>by the CA&quot;, then the question is how can a =
verifier know how the freshest</FONT>
<BR><FONT SIZE=3D2>information is obtained ? The answer is: only =
through extensions. Why ?</FONT>
</P>

<P><FONT SIZE=3D2>Let us assume first that no extension either in the =
certificate or the CRL</FONT>
<BR><FONT SIZE=3D2>is being used. The answer would be : make a search =
for delta CRLs in the</FONT>
<BR><FONT SIZE=3D2>directory. The problem is that, in case a denial of =
service attack, the</FONT>
<BR><FONT SIZE=3D2>delta CRLs, even if they exist, will not be =
&quot;seen&quot;. So the verifier will use</FONT>
<BR><FONT SIZE=3D2>the base CRL and thus two verifications done at the =
same time T will provide</FONT>
<BR><FONT SIZE=3D2>two different results. :-(</FONT>
</P>

<P><FONT SIZE=3D2>So there needs to be some way, so that, in the event =
of a denial of service</FONT>
<BR><FONT SIZE=3D2>attacks, either the right information is obtained or =
that no information at</FONT>
<BR><FONT SIZE=3D2>all is obtained. In the later case, if the =
revocation information is not</FONT>
<BR><FONT SIZE=3D2>found, then the signature is not accepted (in some =
cases a try can be done</FONT>
<BR><FONT SIZE=3D2>later on).</FONT>
</P>

<P><FONT SIZE=3D2>A consequence is the following: verifiers must know =
without ambiguity</FONT>
<BR><FONT SIZE=3D2>whether a delta CRL mechanism is supported, so that =
if delta CRL are</FONT>
<BR><FONT SIZE=3D2>supported it is possible to know unambiguously that =
it is the case. </FONT>
</P>

<P><FONT SIZE=3D2>There are two options. </FONT>
</P>

<P><FONT SIZE=3D2>1) Should we use the freshestCRL extension from the =
leaf certificate ? This</FONT>
<BR><FONT SIZE=3D2>means that the CA MUST support delta CRLs at any =
time during whole the</FONT>
<BR><FONT SIZE=3D2>life-time of the certificate. This is quite =
constraining for the CA, but</FONT>
<BR><FONT SIZE=3D2>this is possible.</FONT>
</P>

<P><FONT SIZE=3D2>2) Should we use the freshestCRL extension from the =
CRL? This means that the</FONT>
<BR><FONT SIZE=3D2>CA will only support delta CRLs for that CRL without =
any engagement to</FONT>
<BR><FONT SIZE=3D2>support a delta CRL mechanism for the next one. This =
is more flexible.</FONT>
</P>

<P><FONT SIZE=3D2>What does this means ? That it is very likely that we =
will not end up wit</FONT>
<BR><FONT SIZE=3D2>the same mechanism when using delta CRLs for a =
certificate used for non</FONT>
<BR><FONT SIZE=3D2>repudiation purposes and when using a certificate =
for other purposes. One of</FONT>
<BR><FONT SIZE=3D2>the algorithms may look first at the delta CRLs, =
whether they exist or not,</FONT>
<BR><FONT SIZE=3D2>while the other will only take a look for them after =
making sure that they</FONT>
<BR><FONT SIZE=3D2>must exit.</FONT>
</P>

<P><FONT SIZE=3D2>The best guess, if it succeeds, is certainly valid =
for &quot;other purposes&quot;. So</FONT>
<BR><FONT SIZE=3D2>I will now focus on the algorithm to be used for non =
repudiation purposes.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; An application that is willing to obtain =
the freshest CRL </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; information for a given certificate =
used for non repudiation </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; purposes, must know if a delta CRL =
mechanism is supported. </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; Either the certificate or any CRL that =
is able to reference </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; that certificate MUST include a =
freshestCRL extension </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; (a.k.a. a Delta CRL distribution =
point). </FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; The application may then construct an =
updated CRL for that </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; base, for a specific time T, by =
combining it with a delta </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; CRL which contains a delta CRL =
indicator extension with the </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; same CRL number as the base CRL. =
Applications that support </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; delta CRLs MUST ensure that time T =
falls between thisUpdate </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; and nextUpdate for both the base CRL =
and the delta CRL.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; Note: An application could also =
reconstruct an updated CRL, </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; for a specific time T, by using a =
previously locally </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; reconstructed CRL based on the current =
base CRL, and </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; combining it with a delta CRL which =
contains a delta CRL </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; indicator extension with the same CRL =
number as the base </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; CRL.</FONT>
</P>

<P><FONT SIZE=3D2>For the constraint about the CA:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; For any CRL that may reference a =
certificate used for </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; non repudiation purposes, and for any =
time T until </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; the nextUpdate time indicated in a base =
CRL, the CA MUST </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; provide one and only one base CRL and =
one and only delta </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; CRL that refers to that base CRL and =
for which time T </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; falls between thisUpdate and nextUpdate =
from the delta CRL.</FONT>
</P>

<P><FONT SIZE=3D2>There are still other issues to discuss, like the CRL =
numbering,</FONT>
<BR><FONT SIZE=3D2>whether it is unique or not, let us wait for next =
week for that topic.</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Denis</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; Denis:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Please excuse the half-done message from this =
morning.&nbsp; My mailer and I had</FONT>
<BR><FONT SIZE=3D2>&gt; a disagreement...</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Anyway, since I was not going to get the full =
message out before the end of</FONT>
<BR><FONT SIZE=3D2>&gt; the business day in France, I took the time to =
coordinate a response with</FONT>
<BR><FONT SIZE=3D2>&gt; Tim Polk and David Cooper.&nbsp; This mail =
thread is quite long, so hopefully</FONT>
<BR><FONT SIZE=3D2>&gt; our coordination on the side will reduce the =
overall number of messages to</FONT>
<BR><FONT SIZE=3D2>&gt; the list and help to reach consensus =
faster.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Here goes ....</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;There is difference between a base =
CRL and a full CRL : a base CRL MUST</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;include a freshestCRL extension =
(a.k.a. a Delta CRL distribution point),</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;whereas a full CRL may not include =
that extension. In other words, a base</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;CRL is a also a full CRL, but a full =
CRL is not necessarily a base CRL.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; There is no requirement in X.509 to include any =
extension in a certificate</FONT>
<BR><FONT SIZE=3D2>&gt; or CRL advertising the availability of delta =
CRLs. PKIX makes the</FONT>
<BR><FONT SIZE=3D2>&gt; freshestCRL extension available for advertising =
the existence of delta</FONT>
<BR><FONT SIZE=3D2>&gt; CRLs, but again does not mandate its use. =
Furthermore, even if the</FONT>
<BR><FONT SIZE=3D2>&gt; freshestCRL extension is used, it may be placed =
in either the certificate</FONT>
<BR><FONT SIZE=3D2>&gt; or the full CRL. If the extension is placed in =
certificates, there is no</FONT>
<BR><FONT SIZE=3D2>&gt; need for it to be in the full CRL (but, it =
could be).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Finally, if delta CRLs are being issued, and =
are being advertised through</FONT>
<BR><FONT SIZE=3D2>&gt; the freshestCRL CRL extension, then the =
extension should be included in all</FONT>
<BR><FONT SIZE=3D2>&gt; full CRLs for that scope, not just the base =
CRLs. If a relying party</FONT>
<BR><FONT SIZE=3D2>&gt; obtains the most recently issued full CRL for a =
scope from a repository,</FONT>
<BR><FONT SIZE=3D2>&gt; and that full CRL is not a base CRL, how will =
the relying party know that</FONT>
<BR><FONT SIZE=3D2>&gt; delta CRLs are available?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;At any time a CA may issue a full =
CRL, whether or not a base CRL has already</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;been issued. This additional CRL =
SHOULD have nextUpdate equal to the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;nextUpdate of the last issued full =
CRL. However, there is no guarantee that</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;this additional CRL will ever be seen =
by the relying party (because there</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;will be two CRLs matching the =
thisUpdate and nextUpdate rule and if one is</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;deleted, this is not seen by a =
relying party).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The nextUpdate field in a full CRL (base or =
otherwise) should specify the</FONT>
<BR><FONT SIZE=3D2>&gt; time by which new revocation information will =
be available. So, if a new</FONT>
<BR><FONT SIZE=3D2>&gt; base CRL is issued once a day, but full CRLs =
are issued every hour, the</FONT>
<BR><FONT SIZE=3D2>&gt; nextUpdate field of each full CRL should one =
hour after that CRL's</FONT>
<BR><FONT SIZE=3D2>&gt; thisUpdate time.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;Due to the fact that CRLs numbers are =
strictly increasing, two CRLs whether</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;they are a base CRL or delta CRL, =
CANNOT have the same CRL number. So a</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;delta CRL and a full CRL that cover =
the same scope and are issued at the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;same time CANNOT have the same =
number.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; We disagree.&nbsp; If a full CRL and a delta =
CRL are issued at the same time for</FONT>
<BR><FONT SIZE=3D2>&gt; the same scope, then they ARE the same CRL and =
MUST have the same CRL number.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;If a full CRL is issued, its =
CRL</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;number bears no relationship with the =
previous base CRL, if any.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Again, we disagree. A sequence of CRLs for a =
given scope must contain a</FONT>
<BR><FONT SIZE=3D2>&gt; monotonically increasing sequence of CRL =
numbers. Relying parties that do</FONT>
<BR><FONT SIZE=3D2>&gt; not process delta CRLs, and thus do not =
recognize the non-critical</FONT>
<BR><FONT SIZE=3D2>&gt; freshestCRL extension, will not be able to =
distinguish between those full</FONT>
<BR><FONT SIZE=3D2>&gt; CRLs that are base CRLs and those full CRLs =
that are not base CRLs. The CRL</FONT>
<BR><FONT SIZE=3D2>&gt; numbers for these full CRLs must be from one =
monotonically increasing sequence.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;The only</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;relationship between the numbers is =
defined by the rule that CRLs numbers</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;are strictly increasing. As Santosh =
said : &quot;the CRL number is unique</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;whether it is a base or a delta =
&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;This is fairly important to be able =
to unambiguously (and thus uniquely)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;refer to a CRL by only providing its =
CRL number.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Exactly. If a full CRL and the delta CRL are =
issued for the same scope at</FONT>
<BR><FONT SIZE=3D2>&gt; the same time, they are the same CRL. The CRL =
number unambiguously and</FONT>
<BR><FONT SIZE=3D2>&gt; uniquely refers to this ONE CRL.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;Besides the fact that a CRL issued =
later MUST have a higher CRL number, full</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;CRLs and delta CRLs have independent =
numbering rules. As noticed by Santosh,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&quot; if the delta thisUpdate &gt; =
base thisUpdate, delta CRL number &gt; base CRL</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;number (for the same or no stream =
identifier).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If you agree that delta thisUpdate &gt; base =
thisUpdate implies delta CRL</FONT>
<BR><FONT SIZE=3D2>&gt; number &gt; base CRL, then you are =
acknowledging that the CRL numbers of the</FONT>
<BR><FONT SIZE=3D2>&gt; full CRLs and delta CRLs are not =
independent.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;As Santosh said : &quot;a check based =
on thisUpdate is more general and</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;preferred [to the use of CRL =
numbers]. &quot;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;Related to the three rules mentioned =
by Russ :</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;1) the first rule is not =
understandable to me.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;2) the second rule does not say =
anything more than the basic rule valid</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; for any CRL (i.e. =
a CRL issued later MUST have a higher CRL number).</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;3) we will debate the hold condition, =
once we will have sorted the main</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; issue.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;Russ said : &quot;If separate number =
sequence is used, then you will have to</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;periodically fetch base CRLs &quot;. =
This is true.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;Tim said that he would *not* like to =
be forced to download new base CRLs.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;This is the core of the =
&quot;dispute&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Our goal should be to allow delta CRL enabled =
clients to obtain accurate</FONT>
<BR><FONT SIZE=3D2>&gt; information in the most efficient manner =
possible. Forcing clients to</FONT>
<BR><FONT SIZE=3D2>&gt; periodically download full CRLs, when this is =
not necessary, is inefficient.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; From the definition of what a delta =
CRL is, it is *not* possible to</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;get rid of the fetching of base CRLs. =
Unless we add a new sentence to</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;expand/change that definition, base =
CRL fetching will remain mandatory.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; True. However, if one performs validations =
frequently enough, it is</FONT>
<BR><FONT SIZE=3D2>&gt; possible to obtain a single full CRL and then =
subsequently download only</FONT>
<BR><FONT SIZE=3D2>&gt; delta CRLs. We need to require that full CRL be =
issued periodically so that</FONT>
<BR><FONT SIZE=3D2>&gt; clients whose locally stored information is not =
sufficiently up-to-date to</FONT>
<BR><FONT SIZE=3D2>&gt; apply the delta CRLs being issued can obtain =
the full CRLs that they need,</FONT>
<BR><FONT SIZE=3D2>&gt; but we should not require clients to download =
full CRLs when it is not</FONT>
<BR><FONT SIZE=3D2>&gt; necessary for them to do so.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;Remember that the goal of delta CRLs =
is to provide the freshest information,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;and to my knowledge the goal was not =
to get rid of the fetching of base CRLs</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;(which may less frequent due to the =
support of delta CRLs).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Yes, but the goal should be to minimize the =
fetching of full CRLs.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;If I understand correctly, =
Tim/David/Russ would like to *always* achieve the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;following property : it is possible =
to reconstruct the current CRL by using</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;a base CRL from, e.g. 1990, i.e. by =
capturing every delta CRL that has been</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;issued at the same time a base CRL =
was issued and which contains updates</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;made to the *previous* base.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;By this way the fetching of base CRLs =
could be avoided. However, note that</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;it is perfectly &quot; legal &quot; =
to stop issuing base and delta CRLs during some</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;period of time and to issue full CRLs =
instead (see the difference between</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&quot;full&quot; and &quot;base&quot; =
at the top of this e-mail). In other words there is no</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;need to issue a new base CRL at the =
end of the validity period of the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;previous base CRL. Doing this would =
mandate to prescribe issuing rules</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;for CAs that we have not =
prescripted.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; You are mixing apples and oranges. Obviously =
the scheme of keeping</FONT>
<BR><FONT SIZE=3D2>&gt; up-to-date by obtaining a base from 1990 and =
then only downloading deltas</FONT>
<BR><FONT SIZE=3D2>&gt; will only work so long as deltas continue to be =
issued. If the CRL issuer</FONT>
<BR><FONT SIZE=3D2>&gt; ceases to issue deltas, then the relying =
parties will have to revert to</FONT>
<BR><FONT SIZE=3D2>&gt; downloading full CRLs.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;I will now raise a series of =
questions, for which I believe we have</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;different answers. Tim/David/Russ do =
not hesitate to correct</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;if my guess is wrong. ;-)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;Common point:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;1) What will be the value of the =
nextUpdate field from the last issued delta</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;CRL for a given base CRL ?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;Denis: the nextUpdate field from the =
last issued delta CRL MUST be equal to</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;the value of nextUpdate from the base =
CRL.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;Tim/David/Russ: ???</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The nextUpdate field in a base CRL states when =
the next full CRL will be</FONT>
<BR><FONT SIZE=3D2>&gt; available. This is important for supporting =
clients that do not handle</FONT>
<BR><FONT SIZE=3D2>&gt; delta CRLs. The nextUpdate field in a delta CRL =
states when the next CRL</FONT>
<BR><FONT SIZE=3D2>&gt; (either a delta CRL or a full CRL) will be =
available. As a general rule, if</FONT>
<BR><FONT SIZE=3D2>&gt; the CA is continuing to issue deltas, the =
nextUpdate in the delta will be</FONT>
<BR><FONT SIZE=3D2>&gt; the time by which the next delta will be =
available. If this is the last</FONT>
<BR><FONT SIZE=3D2>&gt; delta that the CA is going to issue, then the =
nextUpdate in the delta will</FONT>
<BR><FONT SIZE=3D2>&gt; be the time by which the next full CRL will be =
available. (&quot;Available&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; SHOULD reflect distribution delays associated =
with the repository</FONT>
<BR><FONT SIZE=3D2>&gt; architecture.)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;2) Does a CA needs to issue a delta =
CRL at the time a full CRL is issued ?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;Denis: No.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;Tim/David/Russ : ???</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; No. A CA never is required to issue deltas. =
However, it would be helpful to</FONT>
<BR><FONT SIZE=3D2>&gt; delta CRL enabled clients to allow them to =
construct the full CRL.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If the full CRL contains a freshestCRL =
extension, then it is a very good</FONT>
<BR><FONT SIZE=3D2>&gt; idea to generate a delta CRL at the same time. =
In this way, any client will</FONT>
<BR><FONT SIZE=3D2>&gt; be able to find a current delta CRL.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;3) Does a CA needs to issue a new =
base CRL at the end of the validity of a</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;current base CRL ?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;Denis: No.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;Tim/David/Russ : ???</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; No. HOWEVER, the CA must issue a new full CRL =
by the nextUpdate in the</FONT>
<BR><FONT SIZE=3D2>&gt; previously issued full CRL (whether that full =
CRL is a base CRL or not).</FONT>
<BR><FONT SIZE=3D2>&gt; There is no requirement that the next full CRL =
be a base CRL. (The CA could</FONT>
<BR><FONT SIZE=3D2>&gt; quit issuing deltas, etc. etc.)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Every base CRL MUST be a full CRL, but not =
every full CRL is a base CRL.</FONT>
<BR><FONT SIZE=3D2>&gt; But, a CA could make every full CRL a base CRL =
if they wanted to.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;4) Does a CA needs to issue a delta =
CRL at the same time a new base is</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;issued ?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;Denis: Yes. The delta CRL refers to =
the *new* base.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;Tim/David/Russ : ???</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; No. HOWEVER, in practice we belive that CAs =
will do so. The delta CRL needs</FONT>
<BR><FONT SIZE=3D2>&gt; to exist so that clients can follow the =
freshest CRL extension (either in a</FONT>
<BR><FONT SIZE=3D2>&gt; certificate or a base CRL). The delta CRL that =
is issued at the same time</FONT>
<BR><FONT SIZE=3D2>&gt; SHOULD point to a previously issued full CRL =
(which will then, by</FONT>
<BR><FONT SIZE=3D2>&gt; definition be a base CRL) whenever possible. =
There is no information to add</FONT>
<BR><FONT SIZE=3D2>&gt; to the new base CRL! By providing the delta as =
an update to a previous base</FONT>
<BR><FONT SIZE=3D2>&gt; CRL, clients can download the delta CRL to =
construct the new base CRL.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;The last point highlights the most =
noticeable difference. Other differences</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;appears when considering the guaranty =
to get the freshest information :</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;using the traditional scheme and the =
thisUpdate and nextUpdate fields the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;guaranty to get the freshest =
information is obtained, but cannot be obtained</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;using the other scheme. :-(</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;Several people are referring to the =
X.509 document for arguments to support</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;that discussion. However, it is =
important to remember that we are defining</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;PKIX, not X.509, so we DO NOT need to =
copy and paste everything from X.509,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;but only what we believe is =
relevant.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; PKIX is a profile of X.509.&nbsp; PKIX may =
impose additional requirements beyond</FONT>
<BR><FONT SIZE=3D2>&gt; those in X.509 or may exclude features that are =
optional in X.509, but</FONT>
<BR><FONT SIZE=3D2>&gt; otherwise PKIX must be consistent with X.509. =
In that context, references</FONT>
<BR><FONT SIZE=3D2>&gt; to X.509 are appropriate.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;We first need to clearly define the =
processing rules applicable to the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;relying parties. These rules will =
certainly contain SHALL/MUST statements,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;but may also include some MAY =
statements which may even be conditional to</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;what the CA is doing. (I let =
Tim/David or Russ provide the MAY statement).</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;Here is a proposal for the MUST =
statement, based on the previous text I</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;produced:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; An application =
that is wishing to take advantage of delta CRLs</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; for a given scope, =
MUST first find a base CRL for that scope,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; i.e. a full CRL =
that that contains a freshestCRL extension</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; (a.k.a. a Delta =
CRL distribution point).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; No. The relying party needs a full CRL (either =
one that has been downloaded</FONT>
<BR><FONT SIZE=3D2>&gt; from a repository or one that has been locally =
generated) against which the</FONT>
<BR><FONT SIZE=3D2>&gt; delta CRL of interest may be applied. There is =
no requirement that the full</FONT>
<BR><FONT SIZE=3D2>&gt; CRL be a base CRL.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; It may then =
construct</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; an updated CRL for =
that base, for a specific time T, by combining</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; it with a delta =
CRL which contains a delta CRL indicator extension</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; with the same CRL =
number as the base CRL.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; It may construct an updated CRL by combining =
the delta CRL with any full</FONT>
<BR><FONT SIZE=3D2>&gt; CRL whose CRL number is greater than or equal =
to the CRL number of the</FONT>
<BR><FONT SIZE=3D2>&gt; referenced base.&nbsp; By saying =
&quot;equal&quot; instead of &quot;greater than or equal&quot; =
we</FONT>
<BR><FONT SIZE=3D2>&gt; would be hiding useful information from =
implementors. We should not be</FONT>
<BR><FONT SIZE=3D2>&gt; hiding useful information.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; Applications that =
support</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; delta CRLs MUST =
ensure that time T falls between thisUpdate and</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; nextUpdate for =
both the base CRL and the delta CRL.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; As stated above, the nextUpdate field in a base =
CRL specifies the time by</FONT>
<BR><FONT SIZE=3D2>&gt; which new revocation information will be =
available through full CRLs. A</FONT>
<BR><FONT SIZE=3D2>&gt; delta CRL may be applied to a base CRL as long =
as the CRL number in the</FONT>
<BR><FONT SIZE=3D2>&gt; base CRL is greater than or equal to the CRL =
number of the base CRL</FONT>
<BR><FONT SIZE=3D2>&gt; referenced by the delta CRL. The nextUpdate =
time of the base CRL is irrelevant.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; Note: An =
application could also reconstruct an updated CRL, for</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; a specific time T, =
by using a previously locally reconstructed CRL</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; based on the =
current base CRL, and combining it with a delta CRL which</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; contains a delta =
CRL indicator extension with the same CRL number as</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; the base =
CRL.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Same problem as above.&nbsp; Need to say =
&quot;greater than or equal to&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;We also need to clearly separate the =
issuing rules applicable for the CAs.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;These rules will certainly contain =
SHALL statements, but could also include</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;some MAY statements. (I let Tim/David =
or Russ provide the MAY statement).</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;Here is a proposal for the MUST statem=
ent, based on the previous text I</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;produced:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; A CA that supports =
delta-CRLs, MUST issue a base CRL,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; This is an unnecessary statement. A delta CRL =
must include a BaseCRLNumber.</FONT>
<BR><FONT SIZE=3D2>&gt; The CRL specified by that BaseCRLNumber is by =
definition a base CRL.&nbsp; Of</FONT>
<BR><FONT SIZE=3D2>&gt; course, the referenced base CRL MUST be a full =
CRL.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; i.e. a full</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; CRL that contains =
a freshestCRL extension (a.k.a. a Delta CRL</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; distribution =
point).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; While it might be a good idea to mandate the =
inclusion of the frestestCRL</FONT>
<BR><FONT SIZE=3D2>&gt; extension in full CRLs that are issued for =
scopes in which delta CRLs are</FONT>
<BR><FONT SIZE=3D2>&gt; also being issued, there is currently no such =
requirement in the draft PKIX</FONT>
<BR><FONT SIZE=3D2>&gt; profile.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; For any time T =
until the nextUpdate time</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; indicated in a =
base CRL, the CA MUST provide one and only one</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; delta CRL that =
refers to that base CRL and for which time T</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; falls between =
thisUpdate and nextUpdate from the delta CRL.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; This sentence has several problems:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 1) The nextUpdate time of a base CRL is the =
time when the next full CRL</FONT>
<BR><FONT SIZE=3D2>&gt; will be available, which may precede the time =
that the next base CRL will</FONT>
<BR><FONT SIZE=3D2>&gt; be issued.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 2) There is no requirement that a delta CRL use =
the most recently issued</FONT>
<BR><FONT SIZE=3D2>&gt; base CRL as its base.&nbsp; I suppose that we =
could add this requirement for the</FONT>
<BR><FONT SIZE=3D2>&gt; PKIX profile, but why?&nbsp; Does it really =
simplify the client?&nbsp; Or, does it</FONT>
<BR><FONT SIZE=3D2>&gt; just make it a wee bit harder to make a =
conforming CA that supports delta CRLs?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 3) If the thisUpdate time of one delta CRL must =
equal the nextUpdate time</FONT>
<BR><FONT SIZE=3D2>&gt; of the previously issued delta CRL, then no =
time can be allotted to account</FONT>
<BR><FONT SIZE=3D2>&gt; for propagation delays between when a delta-CRL =
is issued and when it is</FONT>
<BR><FONT SIZE=3D2>&gt; available in repositories for relying parties =
to obtain. Thus, there would</FONT>
<BR><FONT SIZE=3D2>&gt; be gaps between when the nextUpdate time of one =
delta-CRL was reached and</FONT>
<BR><FONT SIZE=3D2>&gt; when the next delta-CRL was available.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 4) There is nothing in either X.509 or the PKIX =
profile that prevents a CA</FONT>
<BR><FONT SIZE=3D2>&gt; from issuing an unscheduled (or =
&quot;emergency&quot;) delta CRL. And, there should</FONT>
<BR><FONT SIZE=3D2>&gt; not be!&nbsp; Many CAs intend to issue a new =
CRL (delta or otherwise)</FONT>
<BR><FONT SIZE=3D2>&gt; immediately upon the revocation of a =
certificate due to key compromise.</FONT>
<BR><FONT SIZE=3D2>&gt; When such an &quot;emergency&quot; delta CRL is =
issued, there will be two delta CRLs</FONT>
<BR><FONT SIZE=3D2>&gt; for which T falls between thisUpdate and =
nextUpdate. While it is true that</FONT>
<BR><FONT SIZE=3D2>&gt; there is no guarantee that relying parties will =
obtain the fresher of these</FONT>
<BR><FONT SIZE=3D2>&gt; two delta CRLs, that is no reason to prevent =
the CA from issuing the</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;emergency&quot; delta.&nbsp; Some clients =
will obtain the emergency CRL.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;In his e-mail from Wednesday, May 9, =
David said that delta-CRL processing</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;rules could be base on time instead =
of CRL numbers. This is a point of which</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;I strongly agree. Let us do =
it!</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;(However, there is no need to add to =
PKIX, as he suggested, the support of</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;the baseUpdateTime extension from =
X.509 which would even more complicate the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;problem.)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; No. In order to base delta CRL processing on =
time, the baseUpdateTime</FONT>
<BR><FONT SIZE=3D2>&gt; extension must be present in the delta CRL. =
Furthermore, the presence of</FONT>
<BR><FONT SIZE=3D2>&gt; this extension would not complicate the =
problem. baseUpdateTime is a</FONT>
<BR><FONT SIZE=3D2>&gt; non-critical extension that merely provides =
useful information. If you</FONT>
<BR><FONT SIZE=3D2>&gt; don't think that the information provided by =
baseUpdateTime is useful,</FONT>
<BR><FONT SIZE=3D2>&gt; ignore it. Since the extension is non-critical =
and can be ignored, its</FONT>
<BR><FONT SIZE=3D2>&gt; presence can not complicate the problem.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; At 09:05 AM 5/10/2001 -0400, Housley, Russ =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Denis:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;There is difference between a base CRL =
and a full CRL</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;You are quite right.&nbsp; I, for one, will =
try to be more careful about the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;use of them.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;Due to the fact that CRLs numbers are =
strictly increasing, two CRLs whether</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;they are a base CRL or delta CRL, =
CANNOT have the same CRL number.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;I disagree.&nbsp; A full CRL (that may be a =
base CRL for subsequent delta CRLs)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;and a delta CRL issued at the same time as =
that full CRL may actually</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;represent the same revocation =
information.&nbsp; In this case, they are the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;same CRL, and they should have the same =
number.&nbsp; There have been several</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;tables posted that illustrate this =
numbering scheme, and I do not see any</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;text in X.509-200 that indicates this =
scheme is</FONT>
<BR><FONT SIZE=3D2>&gt; [snip - truncate - the message is too long =
anyway]</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0DAD5.35616B40--


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA07885 for ietf-pkix-bks; Fri, 11 May 2001 12:09:36 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA07874 for <[e-mail]>; Fri, 11 May 2001 12:09:30 -0700 (PDT)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id PAA29130 for <[e-mail]>; Fri, 11 May 2001 15:09:22 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 11 May 2001 15:07:08 -0400
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: Strawman on Delta CRLs
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Folks,

David Cooper, Russ Housley and I have collaborated on a "strawman" 
describing the use of delta CRLs in PKIX implementations.  We believe the 
functionality we describe is consistent with ISO X.509 as well.

The text describes algorithms for using deltas and base CRLs to (a) check 
the status of a certificate or (b) create a constructed CRL.  This is 
followed by three scenarios for the use of deltas - "traditional deltas", 
"sliding window deltas", and a variant on sliding window deltas that 
factors in the real world delays in populating repositories with base and 
delta CRLs.

I have appended the strawman below in ASCII text.  The text includes tables 
for the examples.  Please note, these tables *require* a fixed font to be 
legible.  If you would prefer a copy in either Word or PDF, I have posted 
them at the following URLs:
http://csrc.nist.gov/pki/documents/PKIX/PKIXdeltas.doc and 
http://csrc.nist.gov/pki/documents/PKIX/PKIXdeltas.pdf

Hopefully, this strawman will serve to frame further discussions and 
accelerate consensus.   Once we agree on the requirements, Russ and I will 
draft the necessary changes and we can finish Last Call.  (I am nothing if 
not an optimist.)

We would also like to add the examples as an *informative* appendix in 
son-of-2459.

Thanks,

Tim Polk


--------------------------------strawman---------------------------

Implementing Delta CRLs Using PKIX

This paper addresses the use of delta CRLs in PKIX-compliant systems.
This paper assumes that delta CRLs include the delta CRL indicator
extension (rather than a CRL scope extension) and ignores
complications involving combined delta CRLs from indirect CRL issuers.

This paper also assumes that CRLs with different scopes are distributed
using different distribution points.

Terms

Revoked: A statement that a particular certificate's status has changed
and it should no longer be trusted.  Once a certificate is revoked, it
is always revoked.

Suspension: A statement that a particular certificate may not be
trustworthy. Once placed on hold, a certificate may be revoked or the
suspension may be lifted.

Revocation notice: A statement that a particular certificate has been
suspended or revoked.  The revocation statement identifies the certificate
by the issuer name and serial number.  The issuer may be specified
explicitly or implicitly. The issuer may be explicitly identified using
the certificate issuer extension. If not specified explicitly, the issuer
of the certificate is implicitly identified as the issuer of the CRL. A
revocation notice includes the date and time the certificate was revoked.
A revocation notice may optionally include a revocation reason in the
reason code CRL entry extension. [Note: A revocation notice may optionally
specify in the invalidity date extension the date from which the
certificate should be considered invalid.  This date may precede the actual
revocation date.  The invalidity date extension does not feature in this
discussion, so it is not considered further in this paper.]

Certificate revocation list (CRL):  a list of revocation notices for
certificates.

CRL scope: the set of certificates that could appear on a given CRL.
For example, the scope may be "all certificates issued by CA X", "all
CA and end entity certificates issued by CA X", "all certificates issued
by CA X that have been revoked for key compromise and CA compromise", or
may be a set of certificates based on local information, such as "all
certificates issued to the NIST employees located in Boulder".

Full CRL: a CRL that lists all unexpired certificates, in its scope, that
have been revoked for one of the revocation reasons covered by the scope
of the CRL. The scope of a full CRL does not necessarily include all of
the certificates issued by a CA or all possible revocation reasons.

Base CRL:  the particular CRL used as the foundation for a delta CRL.  The
base must be a full CRL.

Delta CRL:  a CRL that only lists those unexpired certificates, in its scope,
whose revocation status has changed since the issuance of a particular,
referenced base CRL. The scope of a delta CRL is must be the same as the base
CRL that it references

CRL Numbering

A CRL issuer may generate full CRLs for more than one scope.  The CRL issuer
may also generate delta CRLs.  Each delta CRLs must have the same scope as the
full CRL referenced as its base.

For each scope supported by the CRL issuer, a numbering sequence must be
maintained.  For each scope, the CRLs are numbered in a monotonically 
increasing
sequence.  (Wrapping is not permitted in the PKIX profile.)  If a CRL issuer
generates CRLs for one scope (e.g., full CRLs and deltas CRLs), the issuer must
maintain one numbering sequence.  If a delta CRL and a full CRL that cover the
same scope are issued at the same time, they will have the same CRL number.

If a CRL issuer generates CRLs for two scopes (e.g., one covering CA
certificates and one covering end entity certificates), then the CRL issuer 
must
maintain two number sequences.  The CRLs and deltas for the same scope 
(e.g., CA
certificates) will share one numbering sequence.  The CRLs and deltas for the
second scope (e.g., end entity certificates) will share one numbering 
sequence.
There is no requirement that these sequences be disjoint.

Algorithms for Determining Status from a Full CRL and a Delta CRL

Consider a full CRL, F, with CRL number X.  A client may obtain BF in either of
the following ways:
(a) the full CRL F may have been pushed to the client or pulled from a 
repository; or
(b) F may have been constructed from a full CRL and a delta CRL using this 
algorithm.

Consider a delta CRL, D, which specifies base CRL Y and has CRL number Z.  This
means that all certificates whose statuses have changed since the issuance 
of CRL Y
will be listed on the delta CRL.  Note that the PKIX profile requires the 
CA to issue
CRL Y as a full CRL.

Determining Whether a Full CRL and Delta CRL May Be Combined

F and D may be combined if each of the following conditions are met:

(1)	X is greater than or equal to Y.  That is, the full CRL must (at a minimum)
contain all the revocation information held by the referenced base CRL.
(2)	X is less than Z.  That is, the delta CRL must cover some time that was not
covered by the full CRL.

Determining Status of a Certificate from a Full CRL and a Delta CRL

If the PKI client maintains the delta and full CRL, the status of an unexpired
certificate C may be determined as follows:

(1)	If C is listed on the delta CRL, then:
a.	If C is listed on the delta CRL with reason code "removeFromCRL", then C
is not revoked.
b.	Otherwise, certificate C is revoked.
(2)	If C was not listed on the delta CRL, then the full CRL is checked, and the
status is as follows:
a.	If C is listed on the full CRL, then C is revoked.
b.	If C is not listed on the full CRL, then C is not revoked.

Combining a Full CRL and Delta CRL into a Constructed CRL

If the PKI client maintains the current CRL in a local cache:

The revocation information on F is assumed as the initial condition.  F is 
a list
of revoked certificates; each certificate is listed with a revocation reason
(which may be "unspecified").

The list of revoked certificates L with n entries denoted as L[i] where 1 
<= i <= n.
(The value n may shrink or grow as the combination process proceeds.)

Initialize L to the revocation notices on F.  For each certificate C on the 
delta CRL,
update the contents of L as follows.

If a certificate C appears on the delta CRL, and C is not currently in the 
list L,
then:
(a)	if C has a revocation reason other than "removeFromCRL", add C as a new 
entry
in  the list of revoked certificates L.
(b)	If C has revocation reason "removeFromCRL", skip this certificate.  No 
update
to the cache is needed.

If a certificate C appears on the delta CRL, and C is presently listed in L 
as entry
L[i], then:
(a)	If C is listed on the delta CRL with a revocation reason of 
"removeFromCRL",
delete entry L[i]
(b)	If C is listed on the delta CRL without a revocation reason or with a 
revocation
reason other than "removeFromCRL", change the reason code associated with 
L[i] to the
reason code specified in the delta CRL.

The combination of F and D forms a new full CRL with CRL number Z.  This 
full CRL has
complete information until the time specified in the next update field in 
the delta CRL
is reached.  If a relying party is validating a certificate with respect to 
time T, and
T is before the next update field in the delta CRL, they may assume 
complete information.

If an unexpired certificate C within the scope of the constructed CRL is 
not listed, then
certificate C is not revoked for one of the revocation reasons covered by 
this CRL.  If
the constructed CRL covers all reasons, then the certificate C is not revoked.

Using Deltas to Distribute Revocation Information

This section provides three different scenarios for the use of delta 
CRLs.  For the
purpose of these examples, assume a goal of providing revocation 
information to relying
parties that is no more than one hour old.

The following notation is used to denote a revoked certificate on a CRL:
		Xr	certificate X is listed for reason r, where r in {a,k,h,r}
The reason codes {a,k,h,r} correspond to "affiliation changed", "key 
compromise",
"certificate hold", and "remove from CRL" respectively.

(Note:  The remaining reason codes are omitted for simplicity.  The handling of
certificates revoked for  the reasons "unspecified", "CA compromise", 
"superseded", and
"cessationOfOperation" are identical to "affiliation changed or "key 
compromise").



Example #1

The example below shows the "traditional" method of issuing delta CRLs.
In this example, full CRLs are issued once every 3 hours and deltas are
issued once an hour. For consistency, the issuer begins issuing deltas
at the same time as the very first full CRL. After that, however, a delta
can always use a previously issued full CRL as its base. Notice that
starting with cRLNumber 4, the delta CRL issued at the same time as a
full CRL uses the previously issued full CRL as its base. However, the
delta-CRLs never provide more than 3 hours of history.

In this example:
Certificate 14 was revoked for key compromise before 12:00 when the first
CRL was issued.
Certificate 124 was revoked for key compromise between 12:00 and 13:00.
Certificate 39 was placed on hold between 14:00 and 15:00, and its
suspension was lifted between 16:00 and 17:00.
Certificate 67 was revoked for an affiliation change between 16:00 and
17:00.  The reason was changed to key compromise between 18:00 and 19:00.

current  | Revoked      | Full CRL                 | Delta-CRL
time     | certificates |                          |
---------|--------------|--------------------------|----------------------
12:00    | {14k}        | cRLNumber = 1            | cRLNumber = 1
          |              | thisUpdate = 12:00       | thisUpdate = 
12:00
          |              | nextUpdate = 15:00       | nextUpdate = 13:00
          |              | CertificateList = {14k}  | BaseCRLNumber = 1
          |              |                          | CertificateList = 
{}
---------|--------------|--------------------------|----------------------
13:00    | {14k, 124k}  |                          | cRLNumber = 2
          |              |                          | thisUpdate = 13:00
          |              |                          | nextUpdate = 14:00
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList = {124k}
---------|--------------|--------------------------|----------------------
14:00    | {14k, 124k}  |                          | cRLNumber = 3
          |              |                          | thisUpdate = 14:00
          |              |                          | nextUpdate = 15:00
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList = {124k}
---------|--------------|--------------------------|----------------------
15:00    | {14k, 124k,  | cRLNumber = 4            | cRLNumber = 4
          |   39h}       | thisUpdate = 15:00       | thisUpdate = 
15:00
          |              | nextUpdate = 18:00       | nextUpdate = 16:00
          |              | CertificateList =        | BaseCRLNumber = 1
          |              |  {14k, 124k, 39h}        | CertificateList =
          |              |                          | {124k, 39h}
---------|--------------|--------------------------|----------------------
16:00    | {14k, 124k,  |                          | cRLNumber = 5
          |   39h, 67a}  |                          | thisUpdate = 16:00
          |              |                          | nextUpdate = 17:00
          |              |                          | BaseCRLNumber = 4
          |              |                          | CertificateList = {67a}
          |              |                          |
---------|--------------|--------------------------|----------------------
17:00    | {14k, 124k,  |                          | cRLNumber = 6
          |   67a}       |                          | thisUpdate = 17:00
          |              |                          | nextUpdate = 18:00
          |              |                          | BaseCRLNumber = 4
          |              |                          | CertificateList =
          |              |                          | {39r, 67a}
---------|--------------|--------------------------|----------------------
18:00    | {14k, 124k,  | cRLNumber = 7            | cRLNumber = 7
          |   67a}       | thisUpdate = 18:00       | thisUpdate = 
18:00
          |              | nextUpdate = 21:00       | nextUpdate = 19:00
          |              | CertificateList =        | BaseCRLNumber = 4
          |              | {14k, 124k, 67a}         | CertificateList =
          |              |                          | {39r, 
67a}
---------|--------------|--------------------------|----------------------
19:00    | {14k, 124k,  |                          | cRLNumber = 8
          |   67k}       |                          | thisUpdate = 19:00
          |              |                          | nextUpdate = 20:00
          |              |                          | BaseCRLNumber = 7
          |              |                          | CertificateList = {67k}
---------|--------------|--------------------------|----------------------

Scenario #2

The example below shows the "sliding window" method of issuing delta-CRLs.
In this example, full CRLs are issued once every 3 hours and deltas are
issued once an hour. For consistency, the issuer begins issuing deltas at
the same time as the very first full CRL. Notice that starting with
cRLNumber 7, the delta CRL issued at the same time as a full CRL does not
use the previously issued full CRL as its base but the preceding CRL instead.
However, these delta-CRLs never provide more than 6 hours of history.

As in example #1:
Certificate 14 was revoked for key compromise before 12:00 when the first
CRL was issued.
Certificate 124 was revoked for key compromise between 12:00 and 13:00.
Certificate 39 was placed on hold between 14:00 and 15:00, and its
suspension was lifted between
16:00 and 17:00.
Certificate 67 was revoked for an affiliation change between 16:00 and 17:00.
The reason was changed to key compromise between 18:00 and 19:00.

current  | Revoked      | Full CRL                 | Delta-CRL
time     | certificates |                          |
---------|--------------|--------------------------|----------------------
12:00    | {14k}        | cRLNumber = 1            | cRLNumber = 1
          |              | thisUpdate = 12:00       | thisUpdate = 
12:00
          |              | nextUpdate = 15:00       | nextUpdate = 13:00
          |              | CertificateList = {14k}  | BaseCRLNumber = 1
          |              |                          | CertificateList = 
{}
---------|--------------|--------------------------|----------------------
13:00    | {14k, 124k}  |                          | cRLNumber = 2
          |              |                          | thisUpdate = 13:00
          |              |                          | nextUpdate = 14:00
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList = {124k}
---------|--------------|--------------------------|----------------------
14:00    | {14k, 124k}  |                          | cRLNumber = 3
          |              |                          | thisUpdate = 14:00
          |              |                          | nextUpdate = 15:00
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList = {124k}
---------|--------------|--------------------------|----------------------
15:00    | {14k, 124k,  | cRLNumber = 4            | cRLNumber = 4
          |   39h}       | thisUpdate = 15:00       | thisUpdate = 
15:00
          |              | nextUpdate = 18:00       | nextUpdate = 16:00
          |              | CertificateList =        | BaseCRLNumber = 1
          |              |  {14k, 124k, 39h}        | CertificateList =
          |              |                          | {124k, 39h}
---------|--------------|--------------------------|----------------------
16:00    | {14k, 124k,  |                          | cRLNumber = 5
          |   39h, 67a}  |                          | thisUpdate = 16:00
          |              |                          | nextUpdate = 17:00
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList =
          |              |                          | {124k, 39h, 67a}
---------|--------------|--------------------------|----------------------
17:00    | {14k, 124k,  |                          | cRLNumber = 6
          |   67a}       |                          | thisUpdate = 17:00
          |              |                          | nextUpdate = 18:00
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList =
          |              |                          | {124k, 39h, 67a}
---------|--------------|--------------------------|----------------------
18:00    | {14k, 124k,  | cRLNumber = 7            | cRLNumber = 7
          |   67a}       | thisUpdate = 18:00       | thisUpdate = 
18:00
          |              | nextUpdate = 21:00       | nextUpdate = 19:00
          |              | CertificateList =        | BaseCRLNumber = 1
          |              | {14k, 124k, 67a}         | CertificateList =
          |              |                          | {124k, 39r, 67a}
---------|--------------|--------------------------|----------------------
19:00    | {14k, 124k,  |                          | cRLNumber = 8
          |   67k}       |                          | thisUpdate = 19:00
          |              |                          | nextUpdate = 20:00
          |              |                          | BaseCRLNumber = 7
          |              |                          | CertificateList =
          |              |                          | {39r, 67k
---------|--------------|--------------------------|----------------------


Note that the delta CRLs are marginally larger than in the first scenario
since they cover a longer time period.  On the other hand, a relying party
is less likely to download full CRLs in the second scenario.

For example, a relying party that validated one certificate at 12:15, then
a second certificate at 16:15 would not require a new full CRL in scenario #2.
In scenario #1, the relying party would be forced to obtain both full CRL 4
and delta CRL 5.

Scenario #3 Allowing for Replication/Propagation Delays

In this scenario, full CRLs and delta CRLs are replicated throughout a
repository system.  Data is replicated through the system at different
rates based on the size of the file.  The CA operators estimate that full
CRLs will be available throughout the system within three hours.  Delta CRLs
will be available within 15 minutes.  (Assume the initial CRL is small and
will propagate as if a delta CRL to resolve the bootstrap issues.)

The example below uses the "sliding window" method of issuing delta-CRLs,
but overlaps the thisUpdate and nextUpdate times to allow for propagation.
In this example, full CRLs are issued once every 3 hours and deltas are
issued every 45 minutes. For consistency, the issuer begins issuing deltas
at the same time as the very first full CRL. Notice that starting with
cRLNumber 7, the delta CRL issued at the same time as a full CRL does not
use the previously issued full CRL as its base but the preceding CRL instead.
As in example #2, these delta-CRLs never provide more than 6 hours of history.

Similary to examples #1 and #2:
Certificate 14 was revoked for key compromise before 12:00 when the first CRL
was issued.
Certificate 124 was revoked for key compromise between 12:00 and 12:45.
Certificate 39 was placed on hold between 14:15 and 15:00, and its suspension
was lifted between 16:00 and 17:00.
Certificate 67 was revoked for an affiliation change between 15:45 and 16:30.
The reason was changed to key compromise between 18:00 and 18:45.

current  | Revoked      | Full CRL                 | Delta-CRL
time     | certificates |                          |
---------|--------------|--------------------------|----------------------
12:00    | {14k}        | cRLNumber = 1            | cRLNumber = 1
          |              | thisUpdate = 12:00       | thisUpdate = 
12:00
          |              | nextUpdate = 18:00       | nextUpdate = 13:00
          |              | CertificateList = {14k}  | BaseCRLNumber = 1
          |              |                          | CertificateList = 
{}
---------|--------------|--------------------------|----------------------
12:45    | {14k, 124k}  |                          | cRLNumber = 2
          |              |                          | thisUpdate = 12:45
          |              |                          | nextUpdate = 13:45
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList = {124k}
---------|--------------|--------------------------|----------------------
13:30    | {14k, 124k}  |                          | cRLNumber = 3
          |              |                          | thisUpdate = 13:30
          |              |                          | nextUpdate = 14:30
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList = {124k}
---------|--------------|--------------------------|----------------------
14:15    | {14k, 124k}  |                          | cRLNumber = 4
          |              |                          | thisUpdate = 14:15
          |              |                          | nextUpdate = 15:15
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList = {124k}
---------|--------------|--------------------------|----------------------
15:00    | {14k, 124k,  | cRLNumber = 5            | cRLNumber = 5
          |   39h}       | thisUpdate = 15:00       | thisUpdate = 
15:00
          |              | nextUpdate = 21:00       | nextUpdate = 16:00
          |              | CertificateList =        | BaseCRLNumber = 1
          |              |  {14k, 124k, 39h}        | CertificateList =
          |              |                          | {124k, 39h}
---------|--------------|--------------------------|----------------------
15:45    | {14k, 124k,  |                          | cRLNumber = 6
          |   39h, 67a}  |                          | thisUpdate = 15:45
          |              |                          | nextUpdate = 16:45
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList =
          |              |                          | {124k, 39h, 67a}
---------|--------------|--------------------------|----------------------
16:30    | {14k, 124k,  |                          | cRLNumber = 7
          |   67a}       |                          | thisUpdate = 16:30
          |              |                          | nextUpdate = 17:30
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList =
          |              |                          | {124k, 39r, 67a}
---------|--------------|--------------------------|----------------------
17:15    | {14k, 124k,  |                          | cRLNumber = 8
          |  67a}        |                          | thisUpdate = 17:15
          |              |                          | nextUpdate = 18:15
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList =
          |              |                          | {124k, 39r, 67a}
---------|--------------|--------------------------|----------------------
18:00    | {14k, 124k,  | cRLNumber = 9            | cRLNumber = 9
          |   67a}       | thisUpdate = 18:00       | thisUpdate = 
18:00
          |              | nextUpdate = 24:00       | nextUpdate = 19:00
          |              | CertificateList =        | BaseCRLNumber = 5
          |              | {14k, 124k, 67a}         | CertificateList =
          |              |                          | {39r, 67a}
---------|--------------|--------------------------|----------------------
18:45    | {14k, 124k,  |                          | cRLNumber = 10
          |   67k}       |                          | thisUpdate = 18:45
          |              |                          | nextUpdate = 19:45
          |              |                          | BaseCRLNumber = 5
          |              |                          | CertificateList =
          |              |                          | {39r, 67k}
---------|--------------|--------------------------|----------------------



Delta CRL number 6 is issued at 15:45.  By 16:00, delta CRL number 6 should
be available throughout the system.  As a result, delta CRL number 5 specified
16:00 as its nextUpdate time.

However, full CRL number 5 was issued at 15:00 and may not be available
throughout the system  until 18:00.  As a result, full CRL number 1 specified
18:00 as its nextUpdate time.  In addition, delta CRL number 6 must be based
on full CRL number 1 which was issued at 12:00.

If the relying party finds full CRL number 5 in the repository, they may still
apply delta CRL number 6 and achieve the correct answer.

Finally, note that a CRL issuer must generate more CRLs to achieve the goal of
status information that is no more than one hour old when factoring in the
propagation delays.







Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id JAA03664 for ietf-pkix-bks; Fri, 11 May 2001 09:59:07 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA03656 for <[e-mail]>; Fri, 11 May 2001 09:59:00 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA11688; Fri, 11 May 2001 18:58:59 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id SAA15220; Fri, 11 May 2001 18:58:23 +0200
Message-ID: <[e-mail]>
Date: Fri, 11 May 2001 18:58:27 +0200
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail], Tim Polk <[e-mail]>, "David A. Cooper" <[e-mail]>
Subject: Re: delta CRLs
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Russ, 

Thanks for this very detailed collective response.

I have been hoping to have a phone call with some of you today, but since
this had not been possible, here is an answer to your email.

FYI, I will be out of my office during three days, so do no expect a reply
before next Thursday.

The thread has been focussing on the mechanisms, forgetting what is the
rational about them. So let us come back to the rationals. One of them
relates top the use of CRLs when applied to a non repudiation service.

X.509 has been originally written to use CRLs for other security services
and for these other services, the problems are different.

We all want to be able to use either CRLs or OSCP responses for non
repudiation purposes. In fact we want to allow any of these two techniques
to be used in single or in combination. Right ?

Having said this, we can now explain some of the rational. 

When validating a digital signature, for a given time T, for non repudiation
purposes, it is important for a verifier to be able to prove that the
certificate was NOT revoked. It is also important that two different
verifiers come to the same result, for the same time T, because of the goal
of non repudiation is to solve disputes.

The same properties must be achieved whether OCSP or CRLs are used. When an
OCSP response is received with a time T in it, there can be no dispute about
it: it contains three possible answers (not revoked, revoked, don't know).
If an OCSP responder produces one such answer with a time T and one of the
three statuses, no one else can present an answer with the same time T in it
with a different answer from the same OCSP responder. Once again, it would
not be acceptable that at a given time T two opposite responses could be
obtained. This would result in disputes.

This means that at time T, there is must be one and only one possible
answer. This allows to use OCSP responses for non repudiation purposes. The
same property must be supported so that CRLs can be used for non repudiation
purposes. So the goal is that when using CRLs in the context of non
repudiation, only one response (i.e. not revoked, revoked, don't know) can
be obtained.

I do know that non repudiation is only one use of the PKI and that there are
other usages such as authentication, integrity and confidentiality. So let
us now describe what is necessary, if the CRL contains at least one
certificate that can be used for non repudiation purposes (e.g. it has the
NR bit set).

If at time T there is more than one CRL valid, then there is a possibility
to miss the most recent, in case there is a denial of service attack on it
(i.e. suppression of the latest CRL while in transit).

This means that "emergency" CRLs will not necessarily be seen. "Emergency"
CRLs may be used for authentication, integrity and confidentiality, but may
create problems when used in the context of non repudiation.

This has several implications: we should deprecate the use of "emergency"
CRLs for being used for a non repudiation service, because they could
provide two different responses. 

People using full CRLs, i.e. without taking advantage of the delta CRLs,
would get only one result.

People using base CRLs and thus taking advantage of the delta CRLs would
also get one single result. For that reason we should also deprecate the use
of "emergency" delta CRLs.

This now explains why it is important to get one answer, at most, at a time.
I do understand that lacking this information, the mechanism seems to be
constrained without any "good" reason.

Now how can a verifier be sure to get the freshest information ?

This depends on the verification rules. Let us restrict the discussion to
the leaf certificate.

If the validation rules (be careful this has strong relationships with the
DPV protocol) say : "use full CRLs only" and there is no "emergency CRL",
then everything works nice.

If the validation rules say: "use the freshest information that is provided
by the CA", then the question is how can a verifier know how the freshest
information is obtained ? The answer is: only through extensions. Why ?

Let us assume first that no extension either in the certificate or the CRL
is being used. The answer would be : make a search for delta CRLs in the
directory. The problem is that, in case a denial of service attack, the
delta CRLs, even if they exist, will not be "seen". So the verifier will use
the base CRL and thus two verifications done at the same time T will provide
two different results. :-(

So there needs to be some way, so that, in the event of a denial of service
attacks, either the right information is obtained or that no information at
all is obtained. In the later case, if the revocation information is not
found, then the signature is not accepted (in some cases a try can be done
later on).

A consequence is the following: verifiers must know without ambiguity
whether a delta CRL mechanism is supported, so that if delta CRL are
supported it is possible to know unambiguously that it is the case. 

There are two options. 

1) Should we use the freshestCRL extension from the leaf certificate ? This
means that the CA MUST support delta CRLs at any time during whole the
life-time of the certificate. This is quite constraining for the CA, but
this is possible.

2) Should we use the freshestCRL extension from the CRL? This means that the
CA will only support delta CRLs for that CRL without any engagement to
support a delta CRL mechanism for the next one. This is more flexible.

What does this means ? That it is very likely that we will not end up wit
the same mechanism when using delta CRLs for a certificate used for non
repudiation purposes and when using a certificate for other purposes. One of
the algorithms may look first at the delta CRLs, whether they exist or not,
while the other will only take a look for them after making sure that they
must exit.

The best guess, if it succeeds, is certainly valid for "other purposes". So
I will now focus on the algorithm to be used for non repudiation purposes.

   An application that is willing to obtain the freshest CRL 
   information for a given certificate used for non repudiation 
   purposes, must know if a delta CRL mechanism is supported. 
   Either the certificate or any CRL that is able to reference 
   that certificate MUST include a freshestCRL extension 
   (a.k.a. a Delta CRL distribution point). 

   The application may then construct an updated CRL for that 
   base, for a specific time T, by combining it with a delta 
   CRL which contains a delta CRL indicator extension with the 
   same CRL number as the base CRL. Applications that support 
   delta CRLs MUST ensure that time T falls between thisUpdate 
   and nextUpdate for both the base CRL and the delta CRL.

   Note: An application could also reconstruct an updated CRL, 
   for a specific time T, by using a previously locally 
   reconstructed CRL based on the current base CRL, and 
   combining it with a delta CRL which contains a delta CRL 
   indicator extension with the same CRL number as the base 
   CRL.

For the constraint about the CA:

   For any CRL that may reference a certificate used for 
   non repudiation purposes, and for any time T until 
   the nextUpdate time indicated in a base CRL, the CA MUST 
   provide one and only one base CRL and one and only delta 
   CRL that refers to that base CRL and for which time T 
   falls between thisUpdate and nextUpdate from the delta CRL.

There are still other issues to discuss, like the CRL numbering,
whether it is unique or not, let us wait for next week for that topic.

Regards,

Denis


> Denis:
> 
> Please excuse the half-done message from this morning.  My mailer and I had
> a disagreement...
> 
> Anyway, since I was not going to get the full message out before the end of
> the business day in France, I took the time to coordinate a response with
> Tim Polk and David Cooper.  This mail thread is quite long, so hopefully
> our coordination on the side will reduce the overall number of messages to
> the list and help to reach consensus faster.
> 
> Here goes ....
> 
>  >There is difference between a base CRL and a full CRL : a base CRL MUST
>  >include a freshestCRL extension (a.k.a. a Delta CRL distribution point),
>  >whereas a full CRL may not include that extension. In other words, a base
>  >CRL is a also a full CRL, but a full CRL is not necessarily a base CRL.
> 
> There is no requirement in X.509 to include any extension in a certificate
> or CRL advertising the availability of delta CRLs. PKIX makes the
> freshestCRL extension available for advertising the existence of delta
> CRLs, but again does not mandate its use. Furthermore, even if the
> freshestCRL extension is used, it may be placed in either the certificate
> or the full CRL. If the extension is placed in certificates, there is no
> need for it to be in the full CRL (but, it could be).
> 
> Finally, if delta CRLs are being issued, and are being advertised through
> the freshestCRL CRL extension, then the extension should be included in all
> full CRLs for that scope, not just the base CRLs. If a relying party
> obtains the most recently issued full CRL for a scope from a repository,
> and that full CRL is not a base CRL, how will the relying party know that
> delta CRLs are available?
> 
>  >At any time a CA may issue a full CRL, whether or not a base CRL has already
>  >been issued. This additional CRL SHOULD have nextUpdate equal to the
>  >nextUpdate of the last issued full CRL. However, there is no guarantee that
>  >this additional CRL will ever be seen by the relying party (because there
>  >will be two CRLs matching the thisUpdate and nextUpdate rule and if one is
>  >deleted, this is not seen by a relying party).
> 
> The nextUpdate field in a full CRL (base or otherwise) should specify the
> time by which new revocation information will be available. So, if a new
> base CRL is issued once a day, but full CRLs are issued every hour, the
> nextUpdate field of each full CRL should one hour after that CRL's
> thisUpdate time.
> 
>  >Due to the fact that CRLs numbers are strictly increasing, two CRLs whether
>  >they are a base CRL or delta CRL, CANNOT have the same CRL number. So a
>  >delta CRL and a full CRL that cover the same scope and are issued at the
>  >same time CANNOT have the same number.
> 
> We disagree.  If a full CRL and a delta CRL are issued at the same time for
> the same scope, then they ARE the same CRL and MUST have the same CRL number.
> 
>  >If a full CRL is issued, its CRL
>  >number bears no relationship with the previous base CRL, if any.
> 
> Again, we disagree. A sequence of CRLs for a given scope must contain a
> monotonically increasing sequence of CRL numbers. Relying parties that do
> not process delta CRLs, and thus do not recognize the non-critical
> freshestCRL extension, will not be able to distinguish between those full
> CRLs that are base CRLs and those full CRLs that are not base CRLs. The CRL
> numbers for these full CRLs must be from one monotonically increasing sequence.
> 
>  >The only
>  >relationship between the numbers is defined by the rule that CRLs numbers
>  >are strictly increasing. As Santosh said : "the CRL number is unique
>  >whether it is a base or a delta ".
>  >
>  >This is fairly important to be able to unambiguously (and thus uniquely)
>  >refer to a CRL by only providing its CRL number.
> 
> Exactly. If a full CRL and the delta CRL are issued for the same scope at
> the same time, they are the same CRL. The CRL number unambiguously and
> uniquely refers to this ONE CRL.
> 
>  >Besides the fact that a CRL issued later MUST have a higher CRL number, full
>  >CRLs and delta CRLs have independent numbering rules. As noticed by Santosh,
>  >" if the delta thisUpdate > base thisUpdate, delta CRL number > base CRL
>  >number (for the same or no stream identifier).
> 
> If you agree that delta thisUpdate > base thisUpdate implies delta CRL
> number > base CRL, then you are acknowledging that the CRL numbers of the
> full CRLs and delta CRLs are not independent.
> 
>  >As Santosh said : "a check based on thisUpdate is more general and
>  >preferred [to the use of CRL numbers]. "
>  >
>  >Related to the three rules mentioned by Russ :
>  >
>  >1) the first rule is not understandable to me.
>  >2) the second rule does not say anything more than the basic rule valid
>  >    for any CRL (i.e. a CRL issued later MUST have a higher CRL number).
>  >3) we will debate the hold condition, once we will have sorted the main
>  >    issue.
>  >
>  >Russ said : "If separate number sequence is used, then you will have to
>  >periodically fetch base CRLs ". This is true.
>  >
>  >Tim said that he would *not* like to be forced to download new base CRLs.
>  >This is the core of the "dispute".
> 
> Our goal should be to allow delta CRL enabled clients to obtain accurate
> information in the most efficient manner possible. Forcing clients to
> periodically download full CRLs, when this is not necessary, is inefficient.
> 
>  > From the definition of what a delta CRL is, it is *not* possible to
>  >get rid of the fetching of base CRLs. Unless we add a new sentence to
>  >expand/change that definition, base CRL fetching will remain mandatory.
> 
> True. However, if one performs validations frequently enough, it is
> possible to obtain a single full CRL and then subsequently download only
> delta CRLs. We need to require that full CRL be issued periodically so that
> clients whose locally stored information is not sufficiently up-to-date to
> apply the delta CRLs being issued can obtain the full CRLs that they need,
> but we should not require clients to download full CRLs when it is not
> necessary for them to do so.
> 
>  >Remember that the goal of delta CRLs is to provide the freshest information,
>  >and to my knowledge the goal was not to get rid of the fetching of base CRLs
>  >(which may less frequent due to the support of delta CRLs).
> 
> Yes, but the goal should be to minimize the fetching of full CRLs.
> 
>  >If I understand correctly, Tim/David/Russ would like to *always* achieve the
>  >following property : it is possible to reconstruct the current CRL by using
>  >a base CRL from, e.g. 1990, i.e. by capturing every delta CRL that has been
>  >issued at the same time a base CRL was issued and which contains updates
>  >made to the *previous* base.
>  >
>  >By this way the fetching of base CRLs could be avoided. However, note that
>  >it is perfectly " legal " to stop issuing base and delta CRLs during some
>  >period of time and to issue full CRLs instead (see the difference between
>  >"full" and "base" at the top of this e-mail). In other words there is no
>  >need to issue a new base CRL at the end of the validity period of the
>  >previous base CRL. Doing this would mandate to prescribe issuing rules
>  >for CAs that we have not prescripted.
> 
> You are mixing apples and oranges. Obviously the scheme of keeping
> up-to-date by obtaining a base from 1990 and then only downloading deltas
> will only work so long as deltas continue to be issued. If the CRL issuer
> ceases to issue deltas, then the relying parties will have to revert to
> downloading full CRLs.
> 
>  >I will now raise a series of questions, for which I believe we have
>  >different answers. Tim/David/Russ do not hesitate to correct
>  >if my guess is wrong. ;-)
>  >
>  >Common point:
>  >
>  >1) What will be the value of the nextUpdate field from the last issued delta
>  >CRL for a given base CRL ?
>  >
>  >Denis: the nextUpdate field from the last issued delta CRL MUST be equal to
>  >the value of nextUpdate from the base CRL.
>  >
>  >Tim/David/Russ: ???
> 
> The nextUpdate field in a base CRL states when the next full CRL will be
> available. This is important for supporting clients that do not handle
> delta CRLs. The nextUpdate field in a delta CRL states when the next CRL
> (either a delta CRL or a full CRL) will be available. As a general rule, if
> the CA is continuing to issue deltas, the nextUpdate in the delta will be
> the time by which the next delta will be available. If this is the last
> delta that the CA is going to issue, then the nextUpdate in the delta will
> be the time by which the next full CRL will be available. ("Available"
> SHOULD reflect distribution delays associated with the repository
> architecture.)
> 
>  >2) Does a CA needs to issue a delta CRL at the time a full CRL is issued ?
>  >
>  >Denis: No.
>  >Tim/David/Russ : ???
> 
> No. A CA never is required to issue deltas. However, it would be helpful to
> delta CRL enabled clients to allow them to construct the full CRL.
> 
> If the full CRL contains a freshestCRL extension, then it is a very good
> idea to generate a delta CRL at the same time. In this way, any client will
> be able to find a current delta CRL.
> 
>  >3) Does a CA needs to issue a new base CRL at the end of the validity of a
>  >current base CRL ?
>  >
>  >Denis: No.
>  >Tim/David/Russ : ???
> 
> No. HOWEVER, the CA must issue a new full CRL by the nextUpdate in the
> previously issued full CRL (whether that full CRL is a base CRL or not).
> There is no requirement that the next full CRL be a base CRL. (The CA could
> quit issuing deltas, etc. etc.)
> 
> Every base CRL MUST be a full CRL, but not every full CRL is a base CRL.
> But, a CA could make every full CRL a base CRL if they wanted to.
> 
>  >4) Does a CA needs to issue a delta CRL at the same time a new base is
>  >issued ?
>  >
>  >Denis: Yes. The delta CRL refers to the *new* base.
>  >Tim/David/Russ : ???
> 
> No. HOWEVER, in practice we belive that CAs will do so. The delta CRL needs
> to exist so that clients can follow the freshest CRL extension (either in a
> certificate or a base CRL). The delta CRL that is issued at the same time
> SHOULD point to a previously issued full CRL (which will then, by
> definition be a base CRL) whenever possible. There is no information to add
> to the new base CRL! By providing the delta as an update to a previous base
> CRL, clients can download the delta CRL to construct the new base CRL.
> 
>  >The last point highlights the most noticeable difference. Other differences
>  >appears when considering the guaranty to get the freshest information :
>  >using the traditional scheme and the thisUpdate and nextUpdate fields the
>  >guaranty to get the freshest information is obtained, but cannot be obtained
>  >using the other scheme. :-(
>  >
>  >Several people are referring to the X.509 document for arguments to support
>  >that discussion. However, it is important to remember that we are defining
>  >PKIX, not X.509, so we DO NOT need to copy and paste everything from X.509,
>  >but only what we believe is relevant.
> 
> PKIX is a profile of X.509.  PKIX may impose additional requirements beyond
> those in X.509 or may exclude features that are optional in X.509, but
> otherwise PKIX must be consistent with X.509. In that context, references
> to X.509 are appropriate.
> 
>  >We first need to clearly define the processing rules applicable to the
>  >relying parties. These rules will certainly contain SHALL/MUST statements,
>  >but may also include some MAY statements which may even be conditional to
>  >what the CA is doing. (I let Tim/David or Russ provide the MAY statement).
>  >
>  >Here is a proposal for the MUST statement, based on the previous text I
>  >produced:
>  >
>  >    An application that is wishing to take advantage of delta CRLs
>  >    for a given scope, MUST first find a base CRL for that scope,
>  >    i.e. a full CRL that that contains a freshestCRL extension
>  >    (a.k.a. a Delta CRL distribution point).
> 
> No. The relying party needs a full CRL (either one that has been downloaded
> from a repository or one that has been locally generated) against which the
> delta CRL of interest may be applied. There is no requirement that the full
> CRL be a base CRL.
> 
>  >    It may then construct
>  >    an updated CRL for that base, for a specific time T, by combining
>  >    it with a delta CRL which contains a delta CRL indicator extension
>  >    with the same CRL number as the base CRL.
> 
> It may construct an updated CRL by combining the delta CRL with any full
> CRL whose CRL number is greater than or equal to the CRL number of the
> referenced base.  By saying "equal" instead of "greater than or equal" we
> would be hiding useful information from implementors. We should not be
> hiding useful information.
> 
>  >    Applications that support
>  >    delta CRLs MUST ensure that time T falls between thisUpdate and
>  >    nextUpdate for both the base CRL and the delta CRL.
> 
> As stated above, the nextUpdate field in a base CRL specifies the time by
> which new revocation information will be available through full CRLs. A
> delta CRL may be applied to a base CRL as long as the CRL number in the
> base CRL is greater than or equal to the CRL number of the base CRL
> referenced by the delta CRL. The nextUpdate time of the base CRL is irrelevant.
> 
>  >    Note: An application could also reconstruct an updated CRL, for
>  >    a specific time T, by using a previously locally reconstructed CRL
>  >    based on the current base CRL, and combining it with a delta CRL which
>  >    contains a delta CRL indicator extension with the same CRL number as
>  >    the base CRL.
> 
> Same problem as above.  Need to say "greater than or equal to".
> 
>  >We also need to clearly separate the issuing rules applicable for the CAs.
>  >These rules will certainly contain SHALL statements, but could also include
>  >some MAY statements. (I let Tim/David or Russ provide the MAY statement).
>  >
>  >Here is a proposal for the MUST statement, based on the previous text I
>  >produced:
>  >
>  >    A CA that supports delta-CRLs, MUST issue a base CRL,
> 
> This is an unnecessary statement. A delta CRL must include a BaseCRLNumber.
> The CRL specified by that BaseCRLNumber is by definition a base CRL.  Of
> course, the referenced base CRL MUST be a full CRL.
> 
>  >    i.e. a full
>  >    CRL that contains a freshestCRL extension (a.k.a. a Delta CRL
>  >    distribution point).
> 
> While it might be a good idea to mandate the inclusion of the frestestCRL
> extension in full CRLs that are issued for scopes in which delta CRLs are
> also being issued, there is currently no such requirement in the draft PKIX
> profile.
> 
>  >    For any time T until the nextUpdate time
>  >    indicated in a base CRL, the CA MUST provide one and only one
>  >    delta CRL that refers to that base CRL and for which time T
>  >    falls between thisUpdate and nextUpdate from the delta CRL.
> 
> This sentence has several problems:
> 
> 1) The nextUpdate time of a base CRL is the time when the next full CRL
> will be available, which may precede the time that the next base CRL will
> be issued.
> 
> 2) There is no requirement that a delta CRL use the most recently issued
> base CRL as its base.  I suppose that we could add this requirement for the
> PKIX profile, but why?  Does it really simplify the client?  Or, does it
> just make it a wee bit harder to make a conforming CA that supports delta CRLs?
> 
> 3) If the thisUpdate time of one delta CRL must equal the nextUpdate time
> of the previously issued delta CRL, then no time can be allotted to account
> for propagation delays between when a delta-CRL is issued and when it is
> available in repositories for relying parties to obtain. Thus, there would
> be gaps between when the nextUpdate time of one delta-CRL was reached and
> when the next delta-CRL was available.
> 
> 4) There is nothing in either X.509 or the PKIX profile that prevents a CA
> from issuing an unscheduled (or "emergency") delta CRL. And, there should
> not be!  Many CAs intend to issue a new CRL (delta or otherwise)
> immediately upon the revocation of a certificate due to key compromise.
> When such an "emergency" delta CRL is issued, there will be two delta CRLs
> for which T falls between thisUpdate and nextUpdate. While it is true that
> there is no guarantee that relying parties will obtain the fresher of these
> two delta CRLs, that is no reason to prevent the CA from issuing the
> "emergency" delta.  Some clients will obtain the emergency CRL.
> 
>  >In his e-mail from Wednesday, May 9, David said that delta-CRL processing
>  >rules could be base on time instead of CRL numbers. This is a point of which
>  >I strongly agree. Let us do it!
>  >
>  >(However, there is no need to add to PKIX, as he suggested, the support of
>  >the baseUpdateTime extension from X.509 which would even more complicate the
>  >problem.)
> 
> No. In order to base delta CRL processing on time, the baseUpdateTime
> extension must be present in the delta CRL. Furthermore, the presence of
> this extension would not complicate the problem. baseUpdateTime is a
> non-critical extension that merely provides useful information. If you
> don't think that the information provided by baseUpdateTime is useful,
> ignore it. Since the extension is non-critical and can be ignored, its
> presence can not complicate the problem.
> 
> At 09:05 AM 5/10/2001 -0400, Housley, Russ wrote:
> >Denis:
> >
> >>There is difference between a base CRL and a full CRL
> >
> >You are quite right.  I, for one, will try to be more careful about the
> >use of them.
> >
> >>Due to the fact that CRLs numbers are strictly increasing, two CRLs whether
> >>they are a base CRL or delta CRL, CANNOT have the same CRL number.
> >
> >I disagree.  A full CRL (that may be a base CRL for subsequent delta CRLs)
> >and a delta CRL issued at the same time as that full CRL may actually
> >represent the same revocation information.  In this case, they are the
> >same CRL, and they should have the same number.  There have been several
> >tables posted that illustrate this numbering scheme, and I do not see any
> >text in X.509-200 that indicates this scheme is
> [snip - truncate - the message is too long anyway]


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA22564 for ietf-pkix-bks; Fri, 11 May 2001 07:45:06 -0700 (PDT)
Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA22540 for <[e-mail]>; Fri, 11 May 2001 07:44:58 -0700 (PDT)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <KXGS832Y>; Fri, 11 May 2001 10:44:29 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: Santosh Chokhani <[e-mail]>, "Housley, Russ" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: delta CRLs
Date: Fri, 11 May 2001 10:44:28 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DA28.E1DFEE30"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0DA28.E1DFEE30
Content-Type: text/plain;
	charset="iso-8859-1"

I agree as well. Santosh, regarding the term "full" I don't like that term
at all. Although it is defined as a crl that is complete for a given scope,
I think 
the human being in us tends sometimes to confuse it with a CRL that is
complete for all certs issued by a CA and that is a dangerous confusion.
 
However, since the term is defined, I don't have any strong feeling on its
use. I too agree with the email Russ sent after discussing with Tim and
Dave.
 
Cheers
Sharon

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Thursday, May 10, 2001 6:44 PM
To: Housley, Russ; [e-mail]
Cc: [e-mail]
Subject: RE: delta CRLs



Russ: 

I agree with most of what you say except the following. 

I think use of the "full" is dangerous.  These CRLs are "full" only with
respect to the scope as defined in the CRLScope and/or IDP extension.  This
is simply a nit.

You say "Relying parties that do 
not process delta CRLs, and thus do not recognize the non-critical 
freshestCRL extension, will not be able to distinguish between those full 
CRLs that are base CRLs and those full CRLs that are not base CRLs."  Do you
mean a base could also be a delta as opposed to a full?  If so, that
distinction can be and will be made through the deltaCRLIndicator extension
without.  In any case, this point seems to be irrelevant.

You also say that "Every base CRL MUST be a full CRL, but not every full CRL
is a base CRL." 

While I agree with most of what you say, your distinction between base and
full (for scope) does not seem relevant or germane to me and seems to
confuse the issue.  But, I think (and hope) I understand this enough to know
that I do NOT disagree with the final conclusions.  Your rationale comes
across more convoluted and confusing than it needs to be due to this
needless distinction between base and full.

-----Original Message----- 
From: Housley, Russ [ mailto:[e-mail]
<mailto:[e-mail]> ] 
Sent: Thursday, May 10, 2001 2:36 PM 
To: [e-mail] 
Cc: [e-mail] 
Subject: Re: delta CRLs 


Denis: 

Please excuse the half-done message from this morning.  My mailer and I had 
a disagreement... 

Anyway, since I was not going to get the full message out before the end of 
the business day in France, I took the time to coordinate a response with 
Tim Polk and David Cooper.  This mail thread is quite long, so hopefully 
our coordination on the side will reduce the overall number of messages to 
the list and help to reach consensus faster. 

Here goes .... 

 >There is difference between a base CRL and a full CRL : a base CRL MUST 
 >include a freshestCRL extension (a.k.a. a Delta CRL distribution point), 
 >whereas a full CRL may not include that extension. In other words, a base 
 >CRL is a also a full CRL, but a full CRL is not necessarily a base CRL. 

There is no requirement in X.509 to include any extension in a certificate 
or CRL advertising the availability of delta CRLs. PKIX makes the 
freshestCRL extension available for advertising the existence of delta 
CRLs, but again does not mandate its use. Furthermore, even if the 
freshestCRL extension is used, it may be placed in either the certificate 
or the full CRL. If the extension is placed in certificates, there is no 
need for it to be in the full CRL (but, it could be). 

Finally, if delta CRLs are being issued, and are being advertised through 
the freshestCRL CRL extension, then the extension should be included in all 
full CRLs for that scope, not just the base CRLs. If a relying party 
obtains the most recently issued full CRL for a scope from a repository, 
and that full CRL is not a base CRL, how will the relying party know that 
delta CRLs are available? 

 >At any time a CA may issue a full CRL, whether or not a base CRL has
already 
 >been issued. This additional CRL SHOULD have nextUpdate equal to the 
 >nextUpdate of the last issued full CRL. However, there is no guarantee
that 
 >this additional CRL will ever be seen by the relying party (because there 
 >will be two CRLs matching the thisUpdate and nextUpdate rule and if one is

 >deleted, this is not seen by a relying party). 

The nextUpdate field in a full CRL (base or otherwise) should specify the 
time by which new revocation information will be available. So, if a new 
base CRL is issued once a day, but full CRLs are issued every hour, the 
nextUpdate field of each full CRL should one hour after that CRL's 
thisUpdate time. 

 >Due to the fact that CRLs numbers are strictly increasing, two CRLs
whether 
 >they are a base CRL or delta CRL, CANNOT have the same CRL number. So a 
 >delta CRL and a full CRL that cover the same scope and are issued at the 
 >same time CANNOT have the same number. 

We disagree.  If a full CRL and a delta CRL are issued at the same time for 
the same scope, then they ARE the same CRL and MUST have the same CRL
number. 

 >If a full CRL is issued, its CRL 
 >number bears no relationship with the previous base CRL, if any. 

Again, we disagree. A sequence of CRLs for a given scope must contain a 
monotonically increasing sequence of CRL numbers. Relying parties that do 
not process delta CRLs, and thus do not recognize the non-critical 
freshestCRL extension, will not be able to distinguish between those full 
CRLs that are base CRLs and those full CRLs that are not base CRLs. The CRL 
numbers for these full CRLs must be from one monotonically increasing
sequence. 

 >The only 
 >relationship between the numbers is defined by the rule that CRLs numbers 
 >are strictly increasing. As Santosh said : "the CRL number is unique 
 >whether it is a base or a delta ". 
 > 
 >This is fairly important to be able to unambiguously (and thus uniquely) 
 >refer to a CRL by only providing its CRL number. 

Exactly. If a full CRL and the delta CRL are issued for the same scope at 
the same time, they are the same CRL. The CRL number unambiguously and 
uniquely refers to this ONE CRL. 

 >Besides the fact that a CRL issued later MUST have a higher CRL number,
full 
 >CRLs and delta CRLs have independent numbering rules. As noticed by
Santosh, 
 >" if the delta thisUpdate > base thisUpdate, delta CRL number > base CRL 
 >number (for the same or no stream identifier). 

If you agree that delta thisUpdate > base thisUpdate implies delta CRL 
number > base CRL, then you are acknowledging that the CRL numbers of the 
full CRLs and delta CRLs are not independent. 

 >As Santosh said : "a check based on thisUpdate is more general and 
 >preferred [to the use of CRL numbers]. " 
 > 
 >Related to the three rules mentioned by Russ : 
 > 
 >1) the first rule is not understandable to me. 
 >2) the second rule does not say anything more than the basic rule valid 
 >    for any CRL (i.e. a CRL issued later MUST have a higher CRL number). 
 >3) we will debate the hold condition, once we will have sorted the main 
 >    issue. 
 > 
 >Russ said : "If separate number sequence is used, then you will have to 
 >periodically fetch base CRLs ". This is true. 
 > 
 >Tim said that he would *not* like to be forced to download new base CRLs. 
 >This is the core of the "dispute". 

Our goal should be to allow delta CRL enabled clients to obtain accurate 
information in the most efficient manner possible. Forcing clients to 
periodically download full CRLs, when this is not necessary, is inefficient.


 > From the definition of what a delta CRL is, it is *not* possible to 
 >get rid of the fetching of base CRLs. Unless we add a new sentence to 
 >expand/change that definition, base CRL fetching will remain mandatory. 

True. However, if one performs validations frequently enough, it is 
possible to obtain a single full CRL and then subsequently download only 
delta CRLs. We need to require that full CRL be issued periodically so that 
clients whose locally stored information is not sufficiently up-to-date to 
apply the delta CRLs being issued can obtain the full CRLs that they need, 
but we should not require clients to download full CRLs when it is not 
necessary for them to do so. 

 >Remember that the goal of delta CRLs is to provide the freshest
information, 
 >and to my knowledge the goal was not to get rid of the fetching of base
CRLs 
 >(which may less frequent due to the support of delta CRLs). 

Yes, but the goal should be to minimize the fetching of full CRLs. 

 >If I understand correctly, Tim/David/Russ would like to *always* achieve
the 
 >following property : it is possible to reconstruct the current CRL by
using 
 >a base CRL from, e.g. 1990, i.e. by capturing every delta CRL that has
been 
 >issued at the same time a base CRL was issued and which contains updates 
 >made to the *previous* base. 
 > 
 >By this way the fetching of base CRLs could be avoided. However, note that

 >it is perfectly " legal " to stop issuing base and delta CRLs during some 
 >period of time and to issue full CRLs instead (see the difference between 
 >"full" and "base" at the top of this e-mail). In other words there is no 
 >need to issue a new base CRL at the end of the validity period of the 
 >previous base CRL. Doing this would mandate to prescribe issuing rules 
 >for CAs that we have not prescripted. 

You are mixing apples and oranges. Obviously the scheme of keeping 
up-to-date by obtaining a base from 1990 and then only downloading deltas 
will only work so long as deltas continue to be issued. If the CRL issuer 
ceases to issue deltas, then the relying parties will have to revert to 
downloading full CRLs. 

 >I will now raise a series of questions, for which I believe we have 
 >different answers. Tim/David/Russ do not hesitate to correct 
 >if my guess is wrong. ;-) 
 > 
 >Common point: 
 > 
 >1) What will be the value of the nextUpdate field from the last issued
delta 
 >CRL for a given base CRL ? 
 > 
 >Denis: the nextUpdate field from the last issued delta CRL MUST be equal
to 
 >the value of nextUpdate from the base CRL. 
 > 
 >Tim/David/Russ: ??? 

The nextUpdate field in a base CRL states when the next full CRL will be 
available. This is important for supporting clients that do not handle 
delta CRLs. The nextUpdate field in a delta CRL states when the next CRL 
(either a delta CRL or a full CRL) will be available. As a general rule, if 
the CA is continuing to issue deltas, the nextUpdate in the delta will be 
the time by which the next delta will be available. If this is the last 
delta that the CA is going to issue, then the nextUpdate in the delta will 
be the time by which the next full CRL will be available. ("Available" 
SHOULD reflect distribution delays associated with the repository 
architecture.) 

 >2) Does a CA needs to issue a delta CRL at the time a full CRL is issued ?

 > 
 >Denis: No. 
 >Tim/David/Russ : ??? 

No. A CA never is required to issue deltas. However, it would be helpful to 
delta CRL enabled clients to allow them to construct the full CRL. 

If the full CRL contains a freshestCRL extension, then it is a very good 
idea to generate a delta CRL at the same time. In this way, any client will 
be able to find a current delta CRL. 

 >3) Does a CA needs to issue a new base CRL at the end of the validity of a

 >current base CRL ? 
 > 
 >Denis: No. 
 >Tim/David/Russ : ??? 

No. HOWEVER, the CA must issue a new full CRL by the nextUpdate in the 
previously issued full CRL (whether that full CRL is a base CRL or not). 
There is no requirement that the next full CRL be a base CRL. (The CA could 
quit issuing deltas, etc. etc.) 

Every base CRL MUST be a full CRL, but not every full CRL is a base CRL. 
But, a CA could make every full CRL a base CRL if they wanted to. 

 >4) Does a CA needs to issue a delta CRL at the same time a new base is 
 >issued ? 
 > 
 >Denis: Yes. The delta CRL refers to the *new* base. 
 >Tim/David/Russ : ??? 

No. HOWEVER, in practice we belive that CAs will do so. The delta CRL needs 
to exist so that clients can follow the freshest CRL extension (either in a 
certificate or a base CRL). The delta CRL that is issued at the same time 
SHOULD point to a previously issued full CRL (which will then, by 
definition be a base CRL) whenever possible. There is no information to add 
to the new base CRL! By providing the delta as an update to a previous base 
CRL, clients can download the delta CRL to construct the new base CRL. 

 >The last point highlights the most noticeable difference. Other
differences 
 >appears when considering the guaranty to get the freshest information : 
 >using the traditional scheme and the thisUpdate and nextUpdate fields the 
 >guaranty to get the freshest information is obtained, but cannot be
obtained 
 >using the other scheme. :-( 
 > 
 >Several people are referring to the X.509 document for arguments to
support 
 >that discussion. However, it is important to remember that we are defining

 >PKIX, not X.509, so we DO NOT need to copy and paste everything from
X.509, 
 >but only what we believe is relevant. 

PKIX is a profile of X.509.  PKIX may impose additional requirements beyond 
those in X.509 or may exclude features that are optional in X.509, but 
otherwise PKIX must be consistent with X.509. In that context, references 
to X.509 are appropriate. 

 >We first need to clearly define the processing rules applicable to the 
 >relying parties. These rules will certainly contain SHALL/MUST statements,

 >but may also include some MAY statements which may even be conditional to 
 >what the CA is doing. (I let Tim/David or Russ provide the MAY statement).

 > 
 >Here is a proposal for the MUST statement, based on the previous text I 
 >produced: 
 > 
 >    An application that is wishing to take advantage of delta CRLs 
 >    for a given scope, MUST first find a base CRL for that scope, 
 >    i.e. a full CRL that that contains a freshestCRL extension 
 >    (a.k.a. a Delta CRL distribution point). 

No. The relying party needs a full CRL (either one that has been downloaded 
from a repository or one that has been locally generated) against which the 
delta CRL of interest may be applied. There is no requirement that the full 
CRL be a base CRL. 

 >    It may then construct 
 >    an updated CRL for that base, for a specific time T, by combining 
 >    it with a delta CRL which contains a delta CRL indicator extension 
 >    with the same CRL number as the base CRL. 

It may construct an updated CRL by combining the delta CRL with any full 
CRL whose CRL number is greater than or equal to the CRL number of the 
referenced base.  By saying "equal" instead of "greater than or equal" we 
would be hiding useful information from implementors. We should not be 
hiding useful information. 

 >    Applications that support 
 >    delta CRLs MUST ensure that time T falls between thisUpdate and 
 >    nextUpdate for both the base CRL and the delta CRL. 

As stated above, the nextUpdate field in a base CRL specifies the time by 
which new revocation information will be available through full CRLs. A 
delta CRL may be applied to a base CRL as long as the CRL number in the 
base CRL is greater than or equal to the CRL number of the base CRL 
referenced by the delta CRL. The nextUpdate time of the base CRL is
irrelevant. 

 >    Note: An application could also reconstruct an updated CRL, for 
 >    a specific time T, by using a previously locally reconstructed CRL 
 >    based on the current base CRL, and combining it with a delta CRL which

 >    contains a delta CRL indicator extension with the same CRL number as 
 >    the base CRL. 

Same problem as above.  Need to say "greater than or equal to". 

 >We also need to clearly separate the issuing rules applicable for the CAs.

 >These rules will certainly contain SHALL statements, but could also
include 
 >some MAY statements. (I let Tim/David or Russ provide the MAY statement). 
 > 
 >Here is a proposal for the MUST statement, based on the previous text I 
 >produced: 
 > 
 >    A CA that supports delta-CRLs, MUST issue a base CRL, 

This is an unnecessary statement. A delta CRL must include a BaseCRLNumber. 
The CRL specified by that BaseCRLNumber is by definition a base CRL.  Of 
course, the referenced base CRL MUST be a full CRL. 

 >    i.e. a full 
 >    CRL that contains a freshestCRL extension (a.k.a. a Delta CRL 
 >    distribution point). 

While it might be a good idea to mandate the inclusion of the frestestCRL 
extension in full CRLs that are issued for scopes in which delta CRLs are 
also being issued, there is currently no such requirement in the draft PKIX 
profile. 

 >    For any time T until the nextUpdate time 
 >    indicated in a base CRL, the CA MUST provide one and only one 
 >    delta CRL that refers to that base CRL and for which time T 
 >    falls between thisUpdate and nextUpdate from the delta CRL. 

This sentence has several problems: 

1) The nextUpdate time of a base CRL is the time when the next full CRL 
will be available, which may precede the time that the next base CRL will 
be issued. 

2) There is no requirement that a delta CRL use the most recently issued 
base CRL as its base.  I suppose that we could add this requirement for the 
PKIX profile, but why?  Does it really simplify the client?  Or, does it 
just make it a wee bit harder to make a conforming CA that supports delta
CRLs? 

3) If the thisUpdate time of one delta CRL must equal the nextUpdate time 
of the previously issued delta CRL, then no time can be allotted to account 
for propagation delays between when a delta-CRL is issued and when it is 
available in repositories for relying parties to obtain. Thus, there would 
be gaps between when the nextUpdate time of one delta-CRL was reached and 
when the next delta-CRL was available. 

4) There is nothing in either X.509 or the PKIX profile that prevents a CA 
from issuing an unscheduled (or "emergency") delta CRL. And, there should 
not be!  Many CAs intend to issue a new CRL (delta or otherwise) 
immediately upon the revocation of a certificate due to key compromise. 
When such an "emergency" delta CRL is issued, there will be two delta CRLs 
for which T falls between thisUpdate and nextUpdate. While it is true that 
there is no guarantee that relying parties will obtain the fresher of these 
two delta CRLs, that is no reason to prevent the CA from issuing the 
"emergency" delta.  Some clients will obtain the emergency CRL. 

 >In his e-mail from Wednesday, May 9, David said that delta-CRL processing 
 >rules could be base on time instead of CRL numbers. This is a point of
which 
 >I strongly agree. Let us do it! 
 > 
 >(However, there is no need to add to PKIX, as he suggested, the support of

 >the baseUpdateTime extension from X.509 which would even more complicate
the 
 >problem.) 

No. In order to base delta CRL processing on time, the baseUpdateTime 
extension must be present in the delta CRL. Furthermore, the presence of 
this extension would not complicate the problem. baseUpdateTime is a 
non-critical extension that merely provides useful information. If you 
don't think that the information provided by baseUpdateTime is useful, 
ignore it. Since the extension is non-critical and can be ignored, its 
presence can not complicate the problem. 

At 09:05 AM 5/10/2001 -0400, Housley, Russ wrote: 
>Denis: 
> 
>>There is difference between a base CRL and a full CRL 
> 
>You are quite right.  I, for one, will try to be more careful about the 
>use of them. 
> 
>>Due to the fact that CRLs numbers are strictly increasing, two CRLs
whether 
>>they are a base CRL or delta CRL, CANNOT have the same CRL number. 
> 
>I disagree.  A full CRL (that may be a base CRL for subsequent delta CRLs) 
>and a delta CRL issued at the same time as that full CRL may actually 
>represent the same revocation information.  In this case, they are the 
>same CRL, and they should have the same number.  There have been several 
>tables posted that illustrate this numbering scheme, and I do not see any 
>text in X.509-200 that indicates this scheme is 
[snip - truncate - the message is too long anyway] 


------_=_NextPart_001_01C0DA28.E1DFEE30
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: delta CRLs</TITLE>

<META content="MSHTML 5.50.4522.1800" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=982334214-11052001><FONT face=Arial color=#0000ff size=2>I 
agree as well. Santosh, regarding the term "full" I don't like that term at all. 
Although it is defined as a crl that is complete for a given scope, I think 
</FONT></SPAN></DIV>
<DIV><SPAN class=982334214-11052001><FONT face=Arial color=#0000ff size=2>the 
human being in us tends sometimes to confuse it with a CRL that is complete for 
all certs issued by a CA and that is a dangerous confusion.</FONT></SPAN></DIV>
<DIV><SPAN class=982334214-11052001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=982334214-11052001><FONT face=Arial color=#0000ff 
size=2>However, since the term is defined, I don't have any strong feeling on 
its use. I too agree with the email Russ sent after discussing with Tim and 
Dave.</FONT></SPAN></DIV>
<DIV><SPAN class=982334214-11052001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=982334214-11052001><FONT face=Arial color=#0000ff 
size=2>Cheers</FONT></SPAN></DIV>
<DIV><SPAN class=982334214-11052001><FONT face=Arial color=#0000ff 
size=2>Sharon</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Santosh Chokhani 
  [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, May 10, 2001 6:44 
  PM<BR><B>To:</B> Housley, Russ; [e-mail]<BR><B>Cc:</B> 
  [e-mail]<BR><B>Subject:</B> RE: delta CRLs<BR><BR></FONT></DIV>
  <P><FONT size=2>Russ:</FONT> </P>
  <P><FONT size=2>I agree with most of what you say except the following.</FONT> 
  </P>
  <P><FONT size=2>I think use of the "full" is dangerous.&nbsp; These CRLs are 
  "full" only with respect to the scope as defined in the CRLScope and/or IDP 
  extension.&nbsp; This is simply a nit.</FONT></P>
  <P><FONT size=2>You say "Relying parties that do </FONT><BR><FONT size=2>not 
  process delta CRLs, and thus do not recognize the non-critical 
  </FONT><BR><FONT size=2>freshestCRL extension, will not be able to distinguish 
  between those full </FONT><BR><FONT size=2>CRLs that are base CRLs and those 
  full CRLs that are not base CRLs."&nbsp; Do you mean a base could also be a 
  delta as opposed to a full?&nbsp; If so, that distinction can be and will be 
  made through the deltaCRLIndicator extension without.&nbsp; In any case, this 
  point seems to be irrelevant.</FONT></P>
  <P><FONT size=2>You also say that "Every base CRL MUST be a full CRL, but not 
  every full CRL is a base CRL." </FONT></P>
  <P><FONT size=2>While I agree with most of what you say, your distinction 
  between base and full (for scope) does not seem relevant or germane to me and 
  seems to confuse the issue.&nbsp; But, I think (and hope) I understand this 
  enough to know that I do NOT disagree with the final conclusions.&nbsp; Your 
  rationale comes across more convoluted and confusing than it needs to be due 
  to this needless distinction between base and full.</FONT></P>
  <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: 
  Housley, Russ [<A 
  href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
  <BR><FONT size=2>Sent: Thursday, May 10, 2001 2:36 PM</FONT> <BR><FONT 
  size=2>To: [e-mail]</FONT> <BR><FONT size=2>Cc: 
  [e-mail]</FONT> <BR><FONT size=2>Subject: Re: delta CRLs</FONT> 
  </P><BR>
  <P><FONT size=2>Denis:</FONT> </P>
  <P><FONT size=2>Please excuse the half-done message from this morning.&nbsp; 
  My mailer and I had </FONT><BR><FONT size=2>a disagreement...</FONT> </P>
  <P><FONT size=2>Anyway, since I was not going to get the full message out 
  before the end of </FONT><BR><FONT size=2>the business day in France, I took 
  the time to coordinate a response with </FONT><BR><FONT size=2>Tim Polk and 
  David Cooper.&nbsp; This mail thread is quite long, so hopefully 
  </FONT><BR><FONT size=2>our coordination on the side will reduce the overall 
  number of messages to </FONT><BR><FONT size=2>the list and help to reach 
  consensus faster.</FONT> </P>
  <P><FONT size=2>Here goes ....</FONT> </P>
  <P><FONT size=2>&nbsp;&gt;There is difference between a base CRL and a full 
  CRL : a base CRL MUST</FONT> <BR><FONT size=2>&nbsp;&gt;include a freshestCRL 
  extension (a.k.a. a Delta CRL distribution point),</FONT> <BR><FONT 
  size=2>&nbsp;&gt;whereas a full CRL may not include that extension. In other 
  words, a base</FONT> <BR><FONT size=2>&nbsp;&gt;CRL is a also a full CRL, but 
  a full CRL is not necessarily a base CRL.</FONT> </P>
  <P><FONT size=2>There is no requirement in X.509 to include any extension in a 
  certificate </FONT><BR><FONT size=2>or CRL advertising the availability of 
  delta CRLs. PKIX makes the </FONT><BR><FONT size=2>freshestCRL extension 
  available for advertising the existence of delta </FONT><BR><FONT size=2>CRLs, 
  but again does not mandate its use. Furthermore, even if the </FONT><BR><FONT 
  size=2>freshestCRL extension is used, it may be placed in either the 
  certificate </FONT><BR><FONT size=2>or the full CRL. If the extension is 
  placed in certificates, there is no </FONT><BR><FONT size=2>need for it to be 
  in the full CRL (but, it could be).</FONT> </P>
  <P><FONT size=2>Finally, if delta CRLs are being issued, and are being 
  advertised through </FONT><BR><FONT size=2>the freshestCRL CRL extension, then 
  the extension should be included in all </FONT><BR><FONT size=2>full CRLs for 
  that scope, not just the base CRLs. If a relying party </FONT><BR><FONT 
  size=2>obtains the most recently issued full CRL for a scope from a 
  repository, </FONT><BR><FONT size=2>and that full CRL is not a base CRL, how 
  will the relying party know that </FONT><BR><FONT size=2>delta CRLs are 
  available?</FONT> </P>
  <P><FONT size=2>&nbsp;&gt;At any time a CA may issue a full CRL, whether or 
  not a base CRL has already</FONT> <BR><FONT size=2>&nbsp;&gt;been issued. This 
  additional CRL SHOULD have nextUpdate equal to the</FONT> <BR><FONT 
  size=2>&nbsp;&gt;nextUpdate of the last issued full CRL. However, there is no 
  guarantee that</FONT> <BR><FONT size=2>&nbsp;&gt;this additional CRL will ever 
  be seen by the relying party (because there</FONT> <BR><FONT 
  size=2>&nbsp;&gt;will be two CRLs matching the thisUpdate and nextUpdate rule 
  and if one is</FONT> <BR><FONT size=2>&nbsp;&gt;deleted, this is not seen by a 
  relying party).</FONT> </P>
  <P><FONT size=2>The nextUpdate field in a full CRL (base or otherwise) should 
  specify the </FONT><BR><FONT size=2>time by which new revocation information 
  will be available. So, if a new </FONT><BR><FONT size=2>base CRL is issued 
  once a day, but full CRLs are issued every hour, the </FONT><BR><FONT 
  size=2>nextUpdate field of each full CRL should one hour after that CRL's 
  </FONT><BR><FONT size=2>thisUpdate time.</FONT> </P>
  <P><FONT size=2>&nbsp;&gt;Due to the fact that CRLs numbers are strictly 
  increasing, two CRLs whether</FONT> <BR><FONT size=2>&nbsp;&gt;they are a base 
  CRL or delta CRL, CANNOT have the same CRL number. So a</FONT> <BR><FONT 
  size=2>&nbsp;&gt;delta CRL and a full CRL that cover the same scope and are 
  issued at the</FONT> <BR><FONT size=2>&nbsp;&gt;same time CANNOT have the same 
  number.</FONT> </P>
  <P><FONT size=2>We disagree.&nbsp; If a full CRL and a delta CRL are issued at 
  the same time for </FONT><BR><FONT size=2>the same scope, then they ARE the 
  same CRL and MUST have the same CRL number.</FONT> </P>
  <P><FONT size=2>&nbsp;&gt;If a full CRL is issued, its CRL</FONT> <BR><FONT 
  size=2>&nbsp;&gt;number bears no relationship with the previous base CRL, if 
  any.</FONT> </P>
  <P><FONT size=2>Again, we disagree. A sequence of CRLs for a given scope must 
  contain a </FONT><BR><FONT size=2>monotonically increasing sequence of CRL 
  numbers. Relying parties that do </FONT><BR><FONT size=2>not process delta 
  CRLs, and thus do not recognize the non-critical </FONT><BR><FONT 
  size=2>freshestCRL extension, will not be able to distinguish between those 
  full </FONT><BR><FONT size=2>CRLs that are base CRLs and those full CRLs that 
  are not base CRLs. The CRL </FONT><BR><FONT size=2>numbers for these full CRLs 
  must be from one monotonically increasing sequence.</FONT> </P>
  <P><FONT size=2>&nbsp;&gt;The only</FONT> <BR><FONT 
  size=2>&nbsp;&gt;relationship between the numbers is defined by the rule that 
  CRLs numbers</FONT> <BR><FONT size=2>&nbsp;&gt;are strictly increasing. As 
  Santosh said : "the CRL number is unique</FONT> <BR><FONT 
  size=2>&nbsp;&gt;whether it is a base or a delta ".</FONT> <BR><FONT 
  size=2>&nbsp;&gt;</FONT> <BR><FONT size=2>&nbsp;&gt;This is fairly important 
  to be able to unambiguously (and thus uniquely)</FONT> <BR><FONT 
  size=2>&nbsp;&gt;refer to a CRL by only providing its CRL number.</FONT> </P>
  <P><FONT size=2>Exactly. If a full CRL and the delta CRL are issued for the 
  same scope at </FONT><BR><FONT size=2>the same time, they are the same CRL. 
  The CRL number unambiguously and </FONT><BR><FONT size=2>uniquely refers to 
  this ONE CRL.</FONT> </P>
  <P><FONT size=2>&nbsp;&gt;Besides the fact that a CRL issued later MUST have a 
  higher CRL number, full</FONT> <BR><FONT size=2>&nbsp;&gt;CRLs and delta CRLs 
  have independent numbering rules. As noticed by Santosh,</FONT> <BR><FONT 
  size=2>&nbsp;&gt;" if the delta thisUpdate &gt; base thisUpdate, delta CRL 
  number &gt; base CRL</FONT> <BR><FONT size=2>&nbsp;&gt;number (for the same or 
  no stream identifier).</FONT> </P>
  <P><FONT size=2>If you agree that delta thisUpdate &gt; base thisUpdate 
  implies delta CRL </FONT><BR><FONT size=2>number &gt; base CRL, then you are 
  acknowledging that the CRL numbers of the </FONT><BR><FONT size=2>full CRLs 
  and delta CRLs are not independent.</FONT> </P>
  <P><FONT size=2>&nbsp;&gt;As Santosh said : "a check based on thisUpdate is 
  more general and</FONT> <BR><FONT size=2>&nbsp;&gt;preferred [to the use of 
  CRL numbers]. "</FONT> <BR><FONT size=2>&nbsp;&gt;</FONT> <BR><FONT 
  size=2>&nbsp;&gt;Related to the three rules mentioned by Russ :</FONT> 
  <BR><FONT size=2>&nbsp;&gt;</FONT> <BR><FONT size=2>&nbsp;&gt;1) the first 
  rule is not understandable to me.</FONT> <BR><FONT size=2>&nbsp;&gt;2) the 
  second rule does not say anything more than the basic rule valid</FONT> 
  <BR><FONT size=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; for any CRL (i.e. a CRL issued 
  later MUST have a higher CRL number).</FONT> <BR><FONT size=2>&nbsp;&gt;3) we 
  will debate the hold condition, once we will have sorted the main</FONT> 
  <BR><FONT size=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; issue.</FONT> <BR><FONT 
  size=2>&nbsp;&gt;</FONT> <BR><FONT size=2>&nbsp;&gt;Russ said : "If separate 
  number sequence is used, then you will have to</FONT> <BR><FONT 
  size=2>&nbsp;&gt;periodically fetch base CRLs ". This is true.</FONT> 
  <BR><FONT size=2>&nbsp;&gt;</FONT> <BR><FONT size=2>&nbsp;&gt;Tim said that he 
  would *not* like to be forced to download new base CRLs.</FONT> <BR><FONT 
  size=2>&nbsp;&gt;This is the core of the "dispute".</FONT> </P>
  <P><FONT size=2>Our goal should be to allow delta CRL enabled clients to 
  obtain accurate </FONT><BR><FONT size=2>information in the most efficient 
  manner possible. Forcing clients to </FONT><BR><FONT size=2>periodically 
  download full CRLs, when this is not necessary, is inefficient.</FONT> </P>
  <P><FONT size=2>&nbsp;&gt; From the definition of what a delta CRL is, it is 
  *not* possible to</FONT> <BR><FONT size=2>&nbsp;&gt;get rid of the fetching of 
  base CRLs. Unless we add a new sentence to</FONT> <BR><FONT 
  size=2>&nbsp;&gt;expand/change that definition, base CRL fetching will remain 
  mandatory.</FONT> </P>
  <P><FONT size=2>True. However, if one performs validations frequently enough, 
  it is </FONT><BR><FONT size=2>possible to obtain a single full CRL and then 
  subsequently download only </FONT><BR><FONT size=2>delta CRLs. We need to 
  require that full CRL be issued periodically so that </FONT><BR><FONT 
  size=2>clients whose locally stored information is not sufficiently up-to-date 
  to </FONT><BR><FONT size=2>apply the delta CRLs being issued can obtain the 
  full CRLs that they need, </FONT><BR><FONT size=2>but we should not require 
  clients to download full CRLs when it is not </FONT><BR><FONT size=2>necessary 
  for them to do so.</FONT> </P>
  <P><FONT size=2>&nbsp;&gt;Remember that the goal of delta CRLs is to provide 
  the freshest information,</FONT> <BR><FONT size=2>&nbsp;&gt;and to my 
  knowledge the goal was not to get rid of the fetching of base CRLs</FONT> 
  <BR><FONT size=2>&nbsp;&gt;(which may less frequent due to the support of 
  delta CRLs).</FONT> </P>
  <P><FONT size=2>Yes, but the goal should be to minimize the fetching of full 
  CRLs.</FONT> </P>
  <P><FONT size=2>&nbsp;&gt;If I understand correctly, Tim/David/Russ would like 
  to *always* achieve the</FONT> <BR><FONT size=2>&nbsp;&gt;following property : 
  it is possible to reconstruct the current CRL by using</FONT> <BR><FONT 
  size=2>&nbsp;&gt;a base CRL from, e.g. 1990, i.e. by capturing every delta CRL 
  that has been</FONT> <BR><FONT size=2>&nbsp;&gt;issued at the same time a base 
  CRL was issued and which contains updates</FONT> <BR><FONT 
  size=2>&nbsp;&gt;made to the *previous* base.</FONT> <BR><FONT 
  size=2>&nbsp;&gt;</FONT> <BR><FONT size=2>&nbsp;&gt;By this way the fetching 
  of base CRLs could be avoided. However, note that</FONT> <BR><FONT 
  size=2>&nbsp;&gt;it is perfectly " legal " to stop issuing base and delta CRLs 
  during some</FONT> <BR><FONT size=2>&nbsp;&gt;period of time and to issue full 
  CRLs instead (see the difference between</FONT> <BR><FONT 
  size=2>&nbsp;&gt;"full" and "base" at the top of this e-mail). In other words 
  there is no</FONT> <BR><FONT size=2>&nbsp;&gt;need to issue a new base CRL at 
  the end of the validity period of the</FONT> <BR><FONT 
  size=2>&nbsp;&gt;previous base CRL. Doing this would mandate to prescribe 
  issuing rules</FONT> <BR><FONT size=2>&nbsp;&gt;for CAs that we have not 
  prescripted.</FONT> </P>
  <P><FONT size=2>You are mixing apples and oranges. Obviously the scheme of 
  keeping </FONT><BR><FONT size=2>up-to-date by obtaining a base from 1990 and 
  then only downloading deltas </FONT><BR><FONT size=2>will only work so long as 
  deltas continue to be issued. If the CRL issuer </FONT><BR><FONT size=2>ceases 
  to issue deltas, then the relying parties will have to revert to 
  </FONT><BR><FONT size=2>downloading full CRLs.</FONT> </P>
  <P><FONT size=2>&nbsp;&gt;I will now raise a series of questions, for which I 
  believe we have</FONT> <BR><FONT size=2>&nbsp;&gt;different answers. 
  Tim/David/Russ do not hesitate to correct</FONT> <BR><FONT size=2>&nbsp;&gt;if 
  my guess is wrong. ;-)</FONT> <BR><FONT size=2>&nbsp;&gt;</FONT> <BR><FONT 
  size=2>&nbsp;&gt;Common point:</FONT> <BR><FONT size=2>&nbsp;&gt;</FONT> 
  <BR><FONT size=2>&nbsp;&gt;1) What will be the value of the nextUpdate field 
  from the last issued delta</FONT> <BR><FONT size=2>&nbsp;&gt;CRL for a given 
  base CRL ?</FONT> <BR><FONT size=2>&nbsp;&gt;</FONT> <BR><FONT 
  size=2>&nbsp;&gt;Denis: the nextUpdate field from the last issued delta CRL 
  MUST be equal to</FONT> <BR><FONT size=2>&nbsp;&gt;the value of nextUpdate 
  from the base CRL.</FONT> <BR><FONT size=2>&nbsp;&gt;</FONT> <BR><FONT 
  size=2>&nbsp;&gt;Tim/David/Russ: ???</FONT> </P>
  <P><FONT size=2>The nextUpdate field in a base CRL states when the next full 
  CRL will be </FONT><BR><FONT size=2>available. This is important for 
  supporting clients that do not handle </FONT><BR><FONT size=2>delta CRLs. The 
  nextUpdate field in a delta CRL states when the next CRL </FONT><BR><FONT 
  size=2>(either a delta CRL or a full CRL) will be available. As a general 
  rule, if </FONT><BR><FONT size=2>the CA is continuing to issue deltas, the 
  nextUpdate in the delta will be </FONT><BR><FONT size=2>the time by which the 
  next delta will be available. If this is the last </FONT><BR><FONT 
  size=2>delta that the CA is going to issue, then the nextUpdate in the delta 
  will </FONT><BR><FONT size=2>be the time by which the next full CRL will be 
  available. ("Available" </FONT><BR><FONT size=2>SHOULD reflect distribution 
  delays associated with the repository </FONT><BR><FONT 
  size=2>architecture.)</FONT> </P>
  <P><FONT size=2>&nbsp;&gt;2) Does a CA needs to issue a delta CRL at the time 
  a full CRL is issued ?</FONT> <BR><FONT size=2>&nbsp;&gt;</FONT> <BR><FONT 
  size=2>&nbsp;&gt;Denis: No.</FONT> <BR><FONT size=2>&nbsp;&gt;Tim/David/Russ : 
  ???</FONT> </P>
  <P><FONT size=2>No. A CA never is required to issue deltas. However, it would 
  be helpful to </FONT><BR><FONT size=2>delta CRL enabled clients to allow them 
  to construct the full CRL.</FONT> </P>
  <P><FONT size=2>If the full CRL contains a freshestCRL extension, then it is a 
  very good </FONT><BR><FONT size=2>idea to generate a delta CRL at the same 
  time. In this way, any client will </FONT><BR><FONT size=2>be able to find a 
  current delta CRL.</FONT> </P>
  <P><FONT size=2>&nbsp;&gt;3) Does a CA needs to issue a new base CRL at the 
  end of the validity of a</FONT> <BR><FONT size=2>&nbsp;&gt;current base CRL 
  ?</FONT> <BR><FONT size=2>&nbsp;&gt;</FONT> <BR><FONT size=2>&nbsp;&gt;Denis: 
  No.</FONT> <BR><FONT size=2>&nbsp;&gt;Tim/David/Russ : ???</FONT> </P>
  <P><FONT size=2>No. HOWEVER, the CA must issue a new full CRL by the 
  nextUpdate in the </FONT><BR><FONT size=2>previously issued full CRL (whether 
  that full CRL is a base CRL or not). </FONT><BR><FONT size=2>There is no 
  requirement that the next full CRL be a base CRL. (The CA could 
  </FONT><BR><FONT size=2>quit issuing deltas, etc. etc.)</FONT> </P>
  <P><FONT size=2>Every base CRL MUST be a full CRL, but not every full CRL is a 
  base CRL. </FONT><BR><FONT size=2>But, a CA could make every full CRL a base 
  CRL if they wanted to.</FONT> </P>
  <P><FONT size=2>&nbsp;&gt;4) Does a CA needs to issue a delta CRL at the same 
  time a new base is</FONT> <BR><FONT size=2>&nbsp;&gt;issued ?</FONT> <BR><FONT 
  size=2>&nbsp;&gt;</FONT> <BR><FONT size=2>&nbsp;&gt;Denis: Yes. The delta CRL 
  refers to the *new* base.</FONT> <BR><FONT size=2>&nbsp;&gt;Tim/David/Russ : 
  ???</FONT> </P>
  <P><FONT size=2>No. HOWEVER, in practice we belive that CAs will do so. The 
  delta CRL needs </FONT><BR><FONT size=2>to exist so that clients can follow 
  the freshest CRL extension (either in a </FONT><BR><FONT size=2>certificate or 
  a base CRL). The delta CRL that is issued at the same time </FONT><BR><FONT 
  size=2>SHOULD point to a previously issued full CRL (which will then, by 
  </FONT><BR><FONT size=2>definition be a base CRL) whenever possible. There is 
  no information to add </FONT><BR><FONT size=2>to the new base CRL! By 
  providing the delta as an update to a previous base </FONT><BR><FONT 
  size=2>CRL, clients can download the delta CRL to construct the new base 
  CRL.</FONT> </P>
  <P><FONT size=2>&nbsp;&gt;The last point highlights the most noticeable 
  difference. Other differences</FONT> <BR><FONT size=2>&nbsp;&gt;appears when 
  considering the guaranty to get the freshest information :</FONT> <BR><FONT 
  size=2>&nbsp;&gt;using the traditional scheme and the thisUpdate and 
  nextUpdate fields the</FONT> <BR><FONT size=2>&nbsp;&gt;guaranty to get the 
  freshest information is obtained, but cannot be obtained</FONT> <BR><FONT 
  size=2>&nbsp;&gt;using the other scheme. :-(</FONT> <BR><FONT 
  size=2>&nbsp;&gt;</FONT> <BR><FONT size=2>&nbsp;&gt;Several people are 
  referring to the X.509 document for arguments to support</FONT> <BR><FONT 
  size=2>&nbsp;&gt;that discussion. However, it is important to remember that we 
  are defining</FONT> <BR><FONT size=2>&nbsp;&gt;PKIX, not X.509, so we DO NOT 
  need to copy and paste everything from X.509,</FONT> <BR><FONT 
  size=2>&nbsp;&gt;but only what we believe is relevant.</FONT> </P>
  <P><FONT size=2>PKIX is a profile of X.509.&nbsp; PKIX may impose additional 
  requirements beyond </FONT><BR><FONT size=2>those in X.509 or may exclude 
  features that are optional in X.509, but </FONT><BR><FONT size=2>otherwise 
  PKIX must be consistent with X.509. In that context, references 
  </FONT><BR><FONT size=2>to X.509 are appropriate.</FONT> </P>
  <P><FONT size=2>&nbsp;&gt;We first need to clearly define the processing rules 
  applicable to the</FONT> <BR><FONT size=2>&nbsp;&gt;relying parties. These 
  rules will certainly contain SHALL/MUST statements,</FONT> <BR><FONT 
  size=2>&nbsp;&gt;but may also include some MAY statements which may even be 
  conditional to</FONT> <BR><FONT size=2>&nbsp;&gt;what the CA is doing. (I let 
  Tim/David or Russ provide the MAY statement).</FONT> <BR><FONT 
  size=2>&nbsp;&gt;</FONT> <BR><FONT size=2>&nbsp;&gt;Here is a proposal for the 
  MUST statement, based on the previous text I</FONT> <BR><FONT 
  size=2>&nbsp;&gt;produced:</FONT> <BR><FONT size=2>&nbsp;&gt;</FONT> <BR><FONT 
  size=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; An application that is wishing to take 
  advantage of delta CRLs</FONT> <BR><FONT size=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; 
  for a given scope, MUST first find a base CRL for that scope,</FONT> <BR><FONT 
  size=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; i.e. a full CRL that that contains a 
  freshestCRL extension</FONT> <BR><FONT size=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; 
  (a.k.a. a Delta CRL distribution point).</FONT> </P>
  <P><FONT size=2>No. The relying party needs a full CRL (either one that has 
  been downloaded </FONT><BR><FONT size=2>from a repository or one that has been 
  locally generated) against which the </FONT><BR><FONT size=2>delta CRL of 
  interest may be applied. There is no requirement that the full 
  </FONT><BR><FONT size=2>CRL be a base CRL.</FONT> </P>
  <P><FONT size=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; It may then construct</FONT> 
  <BR><FONT size=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; an updated CRL for that base, 
  for a specific time T, by combining</FONT> <BR><FONT 
  size=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; it with a delta CRL which contains a delta 
  CRL indicator extension</FONT> <BR><FONT size=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; 
  with the same CRL number as the base CRL.</FONT> </P>
  <P><FONT size=2>It may construct an updated CRL by combining the delta CRL 
  with any full </FONT><BR><FONT size=2>CRL whose CRL number is greater than or 
  equal to the CRL number of the </FONT><BR><FONT size=2>referenced base.&nbsp; 
  By saying "equal" instead of "greater than or equal" we </FONT><BR><FONT 
  size=2>would be hiding useful information from implementors. We should not be 
  </FONT><BR><FONT size=2>hiding useful information.</FONT> </P>
  <P><FONT size=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; Applications that support</FONT> 
  <BR><FONT size=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; delta CRLs MUST ensure that time 
  T falls between thisUpdate and</FONT> <BR><FONT 
  size=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; nextUpdate for both the base CRL and the 
  delta CRL.</FONT> </P>
  <P><FONT size=2>As stated above, the nextUpdate field in a base CRL specifies 
  the time by </FONT><BR><FONT size=2>which new revocation information will be 
  available through full CRLs. A </FONT><BR><FONT size=2>delta CRL may be 
  applied to a base CRL as long as the CRL number in the </FONT><BR><FONT 
  size=2>base CRL is greater than or equal to the CRL number of the base CRL 
  </FONT><BR><FONT size=2>referenced by the delta CRL. The nextUpdate time of 
  the base CRL is irrelevant.</FONT> </P>
  <P><FONT size=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; Note: An application could also 
  reconstruct an updated CRL, for</FONT> <BR><FONT 
  size=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; a specific time T, by using a previously 
  locally reconstructed CRL</FONT> <BR><FONT size=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; 
  based on the current base CRL, and combining it with a delta CRL which</FONT> 
  <BR><FONT size=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; contains a delta CRL indicator 
  extension with the same CRL number as</FONT> <BR><FONT 
  size=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; the base CRL.</FONT> </P>
  <P><FONT size=2>Same problem as above.&nbsp; Need to say "greater than or 
  equal to".</FONT> </P>
  <P><FONT size=2>&nbsp;&gt;We also need to clearly separate the issuing rules 
  applicable for the CAs.</FONT> <BR><FONT size=2>&nbsp;&gt;These rules will 
  certainly contain SHALL statements, but could also include</FONT> <BR><FONT 
  size=2>&nbsp;&gt;some MAY statements. (I let Tim/David or Russ provide the MAY 
  statement).</FONT> <BR><FONT size=2>&nbsp;&gt;</FONT> <BR><FONT 
  size=2>&nbsp;&gt;Here is a proposal for the MUST statement, based on the 
  previous text I</FONT> <BR><FONT size=2>&nbsp;&gt;produced:</FONT> <BR><FONT 
  size=2>&nbsp;&gt;</FONT> <BR><FONT size=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; A CA 
  that supports delta-CRLs, MUST issue a base CRL,</FONT> </P>
  <P><FONT size=2>This is an unnecessary statement. A delta CRL must include a 
  BaseCRLNumber. </FONT><BR><FONT size=2>The CRL specified by that BaseCRLNumber 
  is by definition a base CRL.&nbsp; Of </FONT><BR><FONT size=2>course, the 
  referenced base CRL MUST be a full CRL.</FONT> </P>
  <P><FONT size=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; i.e. a full</FONT> <BR><FONT 
  size=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; CRL that contains a freshestCRL extension 
  (a.k.a. a Delta CRL</FONT> <BR><FONT size=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; 
  distribution point).</FONT> </P>
  <P><FONT size=2>While it might be a good idea to mandate the inclusion of the 
  frestestCRL </FONT><BR><FONT size=2>extension in full CRLs that are issued for 
  scopes in which delta CRLs are </FONT><BR><FONT size=2>also being issued, 
  there is currently no such requirement in the draft PKIX </FONT><BR><FONT 
  size=2>profile.</FONT> </P>
  <P><FONT size=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; For any time T until the 
  nextUpdate time</FONT> <BR><FONT size=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; indicated 
  in a base CRL, the CA MUST provide one and only one</FONT> <BR><FONT 
  size=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; delta CRL that refers to that base CRL and 
  for which time T</FONT> <BR><FONT size=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; falls 
  between thisUpdate and nextUpdate from the delta CRL.</FONT> </P>
  <P><FONT size=2>This sentence has several problems:</FONT> </P>
  <P><FONT size=2>1) The nextUpdate time of a base CRL is the time when the next 
  full CRL </FONT><BR><FONT size=2>will be available, which may precede the time 
  that the next base CRL will </FONT><BR><FONT size=2>be issued.</FONT> </P>
  <P><FONT size=2>2) There is no requirement that a delta CRL use the most 
  recently issued </FONT><BR><FONT size=2>base CRL as its base.&nbsp; I suppose 
  that we could add this requirement for the </FONT><BR><FONT size=2>PKIX 
  profile, but why?&nbsp; Does it really simplify the client?&nbsp; Or, does it 
  </FONT><BR><FONT size=2>just make it a wee bit harder to make a conforming CA 
  that supports delta CRLs?</FONT> </P>
  <P><FONT size=2>3) If the thisUpdate time of one delta CRL must equal the 
  nextUpdate time </FONT><BR><FONT size=2>of the previously issued delta CRL, 
  then no time can be allotted to account </FONT><BR><FONT size=2>for 
  propagation delays between when a delta-CRL is issued and when it is 
  </FONT><BR><FONT size=2>available in repositories for relying parties to 
  obtain. Thus, there would </FONT><BR><FONT size=2>be gaps between when the 
  nextUpdate time of one delta-CRL was reached and </FONT><BR><FONT size=2>when 
  the next delta-CRL was available.</FONT> </P>
  <P><FONT size=2>4) There is nothing in either X.509 or the PKIX profile that 
  prevents a CA </FONT><BR><FONT size=2>from issuing an unscheduled (or 
  "emergency") delta CRL. And, there should </FONT><BR><FONT size=2>not 
  be!&nbsp; Many CAs intend to issue a new CRL (delta or otherwise) 
  </FONT><BR><FONT size=2>immediately upon the revocation of a certificate due 
  to key compromise. </FONT><BR><FONT size=2>When such an "emergency" delta CRL 
  is issued, there will be two delta CRLs </FONT><BR><FONT size=2>for which T 
  falls between thisUpdate and nextUpdate. While it is true that 
  </FONT><BR><FONT size=2>there is no guarantee that relying parties will obtain 
  the fresher of these </FONT><BR><FONT size=2>two delta CRLs, that is no reason 
  to prevent the CA from issuing the </FONT><BR><FONT size=2>"emergency" 
  delta.&nbsp; Some clients will obtain the emergency CRL.</FONT> </P>
  <P><FONT size=2>&nbsp;&gt;In his e-mail from Wednesday, May 9, David said that 
  delta-CRL processing</FONT> <BR><FONT size=2>&nbsp;&gt;rules could be base on 
  time instead of CRL numbers. This is a point of which</FONT> <BR><FONT 
  size=2>&nbsp;&gt;I strongly agree. Let us do it!</FONT> <BR><FONT 
  size=2>&nbsp;&gt;</FONT> <BR><FONT size=2>&nbsp;&gt;(However, there is no need 
  to add to PKIX, as he suggested, the support of</FONT> <BR><FONT 
  size=2>&nbsp;&gt;the baseUpdateTime extension from X.509 which would even more 
  complicate the</FONT> <BR><FONT size=2>&nbsp;&gt;problem.)</FONT> </P>
  <P><FONT size=2>No. In order to base delta CRL processing on time, the 
  baseUpdateTime </FONT><BR><FONT size=2>extension must be present in the delta 
  CRL. Furthermore, the presence of </FONT><BR><FONT size=2>this extension would 
  not complicate the problem. baseUpdateTime is a </FONT><BR><FONT 
  size=2>non-critical extension that merely provides useful information. If you 
  </FONT><BR><FONT size=2>don't think that the information provided by 
  baseUpdateTime is useful, </FONT><BR><FONT size=2>ignore it. Since the 
  extension is non-critical and can be ignored, its </FONT><BR><FONT 
  size=2>presence can not complicate the problem.</FONT> </P>
  <P><FONT size=2>At 09:05 AM 5/10/2001 -0400, Housley, Russ wrote:</FONT> 
  <BR><FONT size=2>&gt;Denis:</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
  size=2>&gt;&gt;There is difference between a base CRL and a full CRL</FONT> 
  <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;You are quite right.&nbsp; 
  I, for one, will try to be more careful about the </FONT><BR><FONT 
  size=2>&gt;use of them.</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
  size=2>&gt;&gt;Due to the fact that CRLs numbers are strictly increasing, two 
  CRLs whether</FONT> <BR><FONT size=2>&gt;&gt;they are a base CRL or delta CRL, 
  CANNOT have the same CRL number.</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
  size=2>&gt;I disagree.&nbsp; A full CRL (that may be a base CRL for subsequent 
  delta CRLs) </FONT><BR><FONT size=2>&gt;and a delta CRL issued at the same 
  time as that full CRL may actually </FONT><BR><FONT size=2>&gt;represent the 
  same revocation information.&nbsp; In this case, they are the </FONT><BR><FONT 
  size=2>&gt;same CRL, and they should have the same number.&nbsp; There have 
  been several </FONT><BR><FONT size=2>&gt;tables posted that illustrate this 
  numbering scheme, and I do not see any </FONT><BR><FONT size=2>&gt;text in 
  X.509-200 that indicates this scheme is</FONT> <BR><FONT size=2>[snip - 
  truncate - the message is too long anyway]</FONT> 
</P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C0DA28.E1DFEE30--


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id FAA14984 for ietf-pkix-bks; Fri, 11 May 2001 05:35:40 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA14953 for <[e-mail]>; Fri, 11 May 2001 05:35:31 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id OAA20535; Fri, 11 May 2001 14:35:29 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 11 May 2001 14:35:29 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id OAA21576; Fri, 11 May 2001 14:35:26 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id OAA01044; Fri, 11 May 2001 14:35:26 +0200 (MET DST)
Date: Fri, 11 May 2001 14:35:26 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: RE: delta CRLs
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

> 	charset="iso-8859-1"
> 
> Dr. Henson:
> 
> The rules for handling hold and release from hold are different when a delta
> is applied to a base issued after the delta (I let you figure out the
> rules).  But, if you have to know if the base was issued after the delta or
> not, why apply the delta at all; just use the new base.
> 
> Thus if thisUpdate of base > = thisUpdate of delta, just use the base and do
> not process the delta.

This is obviously right. If you have a full CRL that is younger than a delta,
then one can just use the full, but the point made by drh was that
a delta can reference a base which is not necessarily the youngest full
crl that can be used, i.e. any base/full that is between the base indicated
in the dcrl and which is not younger that the dcrl can be used.

So one is in the situation of have a dcrl with a base reference, and some
full crl that may be a candidate for a dcrl update since the thisUpdate of
that file is older than that of the dCRL; What has to be ensured is that
this full crl is not older than the referenced base in order not to miss
information. And since the basereference is just a number, i.e. one
doesn't know the thisUpdate of the base, one can only use the 
crlnumber assuming that they are non-decreasing. 


> 
> -----Original Message-----
> From: Dr S N Henson [mailto:[e-mail]]
> Sent: Wednesday, May 09, 2001 6:37 PM
> To: [e-mail]
> Subject: Re: delta CRLs
> 
> 
> 
> 
> Peter Sylvester wrote:
> > 
> > 
> > Is is necessary that the crlNumber of base URLs are strictly
> > increasing? I am not convinced. The numbers are only used to
> > create references to a chain of crls that can be used to create
> > final 'virtual' base crl with an appropriate ThisUpdate.
> > 
> 
> Well since you can combine any full CRL whose number is greater than or
> equal to the base CRL number in the delta it has to be increasing.
> 
> If the full CRL has a number greater than the base CRL in the delta it
> can still be combined but the delta CRL may contain some revocation data
> already present in the base.
> 
> If the CRL number isn't strictly increasing then there's no way for the
> CRL number of deltas to reference which full CRL the constructed CRL
> represents.
> 
> This only applies if the only way to reference constructed and base CRLs
> is the CRL number. If baseUpdateTime is used instead then it isn't
> necessary except for the fact that some clients may not use
> baseUpdateTime.
> 
> Steve.
> -- 
> Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
> Personal Email: [e-mail] 
> Senior crypto engineer, Celo Communications: http://www.celocom.com/
> Core developer of the   OpenSSL project: http://www.openssl.org/
> Business Email: [e-mail] PGP key: via homepage.
> 
> ------_=_NextPart_001_01C0D8FD.23508960
> Content-Type: text/html;
> 	charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
> 
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> <HTML>
> <HEAD>
> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> charset=3Diso-8859-1">
> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
> 5.5.2652.35">
> <TITLE>RE: delta CRLs</TITLE>
> </HEAD>
> <BODY>
> 
> <P><FONT SIZE=3D2>Dr. Henson:</FONT>
> </P>
> 
> <P><FONT SIZE=3D2>The rules for handling hold and release from hold are =
> different when a delta is applied to a base issued after the delta (I =
> let you figure out the rules).&nbsp; But, if you have to know if the =
> base was issued after the delta or not, why apply the delta at all; =
> just use the new base.</FONT></P>
> 
> <P><FONT SIZE=3D2>Thus if thisUpdate of base &gt; =3D thisUpdate of =
> delta, just use the base and do not process the delta.</FONT>
> </P>
> 
> <P><FONT SIZE=3D2>-----Original Message-----</FONT>
> <BR><FONT SIZE=3D2>From: Dr S N Henson [<A =
> HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
> <BR><FONT SIZE=3D2>Sent: Wednesday, May 09, 2001 6:37 PM</FONT>
> <BR><FONT SIZE=3D2>To: [e-mail]</FONT>
> <BR><FONT SIZE=3D2>Subject: Re: delta CRLs</FONT>
> </P>
> <BR>
> <BR>
> <BR>
> 
> <P><FONT SIZE=3D2>Peter Sylvester wrote:</FONT>
> <BR><FONT SIZE=3D2>&gt; </FONT>
> <BR><FONT SIZE=3D2>&gt; </FONT>
> <BR><FONT SIZE=3D2>&gt; Is is necessary that the crlNumber of base URLs =
> are strictly</FONT>
> <BR><FONT SIZE=3D2>&gt; increasing? I am not convinced. The numbers are =
> only used to</FONT>
> <BR><FONT SIZE=3D2>&gt; create references to a chain of crls that can =
> be used to create</FONT>
> <BR><FONT SIZE=3D2>&gt; final 'virtual' base crl with an appropriate =
> ThisUpdate.</FONT>
> <BR><FONT SIZE=3D2>&gt; </FONT>
> </P>
> 
> <P><FONT SIZE=3D2>Well since you can combine any full CRL whose number =
> is greater than or</FONT>
> <BR><FONT SIZE=3D2>equal to the base CRL number in the delta it has to =
> be increasing.</FONT>
> </P>
> 
> <P><FONT SIZE=3D2>If the full CRL has a number greater than the base =
> CRL in the delta it</FONT>
> <BR><FONT SIZE=3D2>can still be combined but the delta CRL may contain =
> some revocation data</FONT>
> <BR><FONT SIZE=3D2>already present in the base.</FONT>
> </P>
> 
> <P><FONT SIZE=3D2>If the CRL number isn't strictly increasing then =
> there's no way for the</FONT>
> <BR><FONT SIZE=3D2>CRL number of deltas to reference which full CRL the =
> constructed CRL</FONT>
> <BR><FONT SIZE=3D2>represents.</FONT>
> </P>
> 
> <P><FONT SIZE=3D2>This only applies if the only way to reference =
> constructed and base CRLs</FONT>
> <BR><FONT SIZE=3D2>is the CRL number. If baseUpdateTime is used instead =
> then it isn't</FONT>
> <BR><FONT SIZE=3D2>necessary except for the fact that some clients may =
> not use</FONT>
> <BR><FONT SIZE=3D2>baseUpdateTime.</FONT>
> </P>
> 
> <P><FONT SIZE=3D2>Steve.</FONT>
> <BR><FONT SIZE=3D2>-- </FONT>
> <BR><FONT SIZE=3D2>Dr Stephen N. Henson.&nbsp;&nbsp; <A =
> HREF=3D"http://www.drh-consultancy.demon.co.uk/" =
> TARGET=3D"_blank">http://www.drh-consultancy.demon.co.uk/</A></FONT>
> <BR><FONT SIZE=3D2>Personal Email: [e-mail] =
> </FONT>
> <BR><FONT SIZE=3D2>Senior crypto engineer, Celo Communications: <A =
> HREF=3D"http://www.celocom.com/" =
> TARGET=3D"_blank">http://www.celocom.com/</A></FONT>
> <BR><FONT SIZE=3D2>Core developer of the&nbsp;&nbsp; OpenSSL project: =
> <A HREF=3D"http://www.openssl.org/" =
> TARGET=3D"_blank">http://www.openssl.org/</A></FONT>
> <BR><FONT SIZE=3D2>Business Email: [e-mail] PGP key: via =
> homepage.</FONT>
> </P>
> 
> </BODY>
> </HTML>
> ------_=_NextPart_001_01C0D8FD.23508960--
> 


Received: by above.proper.com (8.9.3/8.9.3) id RAA13914 for ietf-pkix-bks; Thu, 10 May 2001 17:25:04 -0700 (PDT)
Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA13909 for <[e-mail]>; Thu, 10 May 2001 17:24:59 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0510032ab720e140894d@[165.227.249.20]>
Date: Thu, 10 May 2001 17:24:51 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: ADMINISTRIVIA: Reduction in spam on this list
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Due to the high volume of complaints about spam, this list is now 
restricted for posting. This should not affect the discussion much, 
as I will try to quickly add anyone whose (non-spam) mail bounces. 
Please report any list problems directly to me, not to the mailing 
list. Thanks!

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA08618 for <[e-mail]>; Thu, 10 May 2001 15:53:28 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <K4X9NPZK>; Thu, 10 May 2001 18:53:00 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: "Housley, Russ" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: delta CRLs
Date: Thu, 10 May 2001 18:43:46 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D9A2.AC5D2A10"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D9A2.AC5D2A10
Content-Type: text/plain;
	charset="iso-8859-1"

Russ:

I agree with most of what you say except the following.

I think use of the "full" is dangerous.  These CRLs are "full" only with
respect to the scope as defined in the CRLScope and/or IDP extension.  This
is simply a nit.

You say "Relying parties that do 
not process delta CRLs, and thus do not recognize the non-critical 
freshestCRL extension, will not be able to distinguish between those full 
CRLs that are base CRLs and those full CRLs that are not base CRLs."  Do you
mean a base could also be a delta as opposed to a full?  If so, that
distinction can be and will be made through the deltaCRLIndicator extension
without.  In any case, this point seems to be irrelevant.

You also say that "Every base CRL MUST be a full CRL, but not every full CRL
is a base CRL." 

While I agree with most of what you say, your distinction between base and
full (for scope) does not seem relevant or germane to me and seems to
confuse the issue.  But, I think (and hope) I understand this enough to know
that I do NOT disagree with the final conclusions.  Your rationale comes
across more convoluted and confusing than it needs to be due to this
needless distinction between base and full.

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Thursday, May 10, 2001 2:36 PM
To: [e-mail]
Cc: [e-mail]
Subject: Re: delta CRLs


Denis:

Please excuse the half-done message from this morning.  My mailer and I had 
a disagreement...

Anyway, since I was not going to get the full message out before the end of 
the business day in France, I took the time to coordinate a response with 
Tim Polk and David Cooper.  This mail thread is quite long, so hopefully 
our coordination on the side will reduce the overall number of messages to 
the list and help to reach consensus faster.

Here goes ....

 >There is difference between a base CRL and a full CRL : a base CRL MUST
 >include a freshestCRL extension (a.k.a. a Delta CRL distribution point),
 >whereas a full CRL may not include that extension. In other words, a base
 >CRL is a also a full CRL, but a full CRL is not necessarily a base CRL.

There is no requirement in X.509 to include any extension in a certificate 
or CRL advertising the availability of delta CRLs. PKIX makes the 
freshestCRL extension available for advertising the existence of delta 
CRLs, but again does not mandate its use. Furthermore, even if the 
freshestCRL extension is used, it may be placed in either the certificate 
or the full CRL. If the extension is placed in certificates, there is no 
need for it to be in the full CRL (but, it could be).

Finally, if delta CRLs are being issued, and are being advertised through 
the freshestCRL CRL extension, then the extension should be included in all 
full CRLs for that scope, not just the base CRLs. If a relying party 
obtains the most recently issued full CRL for a scope from a repository, 
and that full CRL is not a base CRL, how will the relying party know that 
delta CRLs are available?

 >At any time a CA may issue a full CRL, whether or not a base CRL has
already
 >been issued. This additional CRL SHOULD have nextUpdate equal to the
 >nextUpdate of the last issued full CRL. However, there is no guarantee
that
 >this additional CRL will ever be seen by the relying party (because there
 >will be two CRLs matching the thisUpdate and nextUpdate rule and if one is
 >deleted, this is not seen by a relying party).

The nextUpdate field in a full CRL (base or otherwise) should specify the 
time by which new revocation information will be available. So, if a new 
base CRL is issued once a day, but full CRLs are issued every hour, the 
nextUpdate field of each full CRL should one hour after that CRL's 
thisUpdate time.

 >Due to the fact that CRLs numbers are strictly increasing, two CRLs
whether
 >they are a base CRL or delta CRL, CANNOT have the same CRL number. So a
 >delta CRL and a full CRL that cover the same scope and are issued at the
 >same time CANNOT have the same number.

We disagree.  If a full CRL and a delta CRL are issued at the same time for 
the same scope, then they ARE the same CRL and MUST have the same CRL
number.

 >If a full CRL is issued, its CRL
 >number bears no relationship with the previous base CRL, if any.

Again, we disagree. A sequence of CRLs for a given scope must contain a 
monotonically increasing sequence of CRL numbers. Relying parties that do 
not process delta CRLs, and thus do not recognize the non-critical 
freshestCRL extension, will not be able to distinguish between those full 
CRLs that are base CRLs and those full CRLs that are not base CRLs. The CRL 
numbers for these full CRLs must be from one monotonically increasing
sequence.

 >The only
 >relationship between the numbers is defined by the rule that CRLs numbers
 >are strictly increasing. As Santosh said : "the CRL number is unique
 >whether it is a base or a delta ".
 >
 >This is fairly important to be able to unambiguously (and thus uniquely)
 >refer to a CRL by only providing its CRL number.

Exactly. If a full CRL and the delta CRL are issued for the same scope at 
the same time, they are the same CRL. The CRL number unambiguously and 
uniquely refers to this ONE CRL.

 >Besides the fact that a CRL issued later MUST have a higher CRL number,
full
 >CRLs and delta CRLs have independent numbering rules. As noticed by
Santosh,
 >" if the delta thisUpdate > base thisUpdate, delta CRL number > base CRL
 >number (for the same or no stream identifier).

If you agree that delta thisUpdate > base thisUpdate implies delta CRL 
number > base CRL, then you are acknowledging that the CRL numbers of the 
full CRLs and delta CRLs are not independent.

 >As Santosh said : "a check based on thisUpdate is more general and
 >preferred [to the use of CRL numbers]. "
 >
 >Related to the three rules mentioned by Russ :
 >
 >1) the first rule is not understandable to me.
 >2) the second rule does not say anything more than the basic rule valid
 >    for any CRL (i.e. a CRL issued later MUST have a higher CRL number).
 >3) we will debate the hold condition, once we will have sorted the main
 >    issue.
 >
 >Russ said : "If separate number sequence is used, then you will have to
 >periodically fetch base CRLs ". This is true.
 >
 >Tim said that he would *not* like to be forced to download new base CRLs.
 >This is the core of the "dispute".

Our goal should be to allow delta CRL enabled clients to obtain accurate 
information in the most efficient manner possible. Forcing clients to 
periodically download full CRLs, when this is not necessary, is inefficient.

 > From the definition of what a delta CRL is, it is *not* possible to
 >get rid of the fetching of base CRLs. Unless we add a new sentence to
 >expand/change that definition, base CRL fetching will remain mandatory.

True. However, if one performs validations frequently enough, it is 
possible to obtain a single full CRL and then subsequently download only 
delta CRLs. We need to require that full CRL be issued periodically so that 
clients whose locally stored information is not sufficiently up-to-date to 
apply the delta CRLs being issued can obtain the full CRLs that they need, 
but we should not require clients to download full CRLs when it is not 
necessary for them to do so.

 >Remember that the goal of delta CRLs is to provide the freshest
information,
 >and to my knowledge the goal was not to get rid of the fetching of base
CRLs
 >(which may less frequent due to the support of delta CRLs).

Yes, but the goal should be to minimize the fetching of full CRLs.

 >If I understand correctly, Tim/David/Russ would like to *always* achieve
the
 >following property : it is possible to reconstruct the current CRL by
using
 >a base CRL from, e.g. 1990, i.e. by capturing every delta CRL that has
been
 >issued at the same time a base CRL was issued and which contains updates
 >made to the *previous* base.
 >
 >By this way the fetching of base CRLs could be avoided. However, note that
 >it is perfectly " legal " to stop issuing base and delta CRLs during some
 >period of time and to issue full CRLs instead (see the difference between
 >"full" and "base" at the top of this e-mail). In other words there is no
 >need to issue a new base CRL at the end of the validity period of the
 >previous base CRL. Doing this would mandate to prescribe issuing rules
 >for CAs that we have not prescripted.

You are mixing apples and oranges. Obviously the scheme of keeping 
up-to-date by obtaining a base from 1990 and then only downloading deltas 
will only work so long as deltas continue to be issued. If the CRL issuer 
ceases to issue deltas, then the relying parties will have to revert to 
downloading full CRLs.

 >I will now raise a series of questions, for which I believe we have
 >different answers. Tim/David/Russ do not hesitate to correct
 >if my guess is wrong. ;-)
 >
 >Common point:
 >
 >1) What will be the value of the nextUpdate field from the last issued
delta
 >CRL for a given base CRL ?
 >
 >Denis: the nextUpdate field from the last issued delta CRL MUST be equal
to
 >the value of nextUpdate from the base CRL.
 >
 >Tim/David/Russ: ???

The nextUpdate field in a base CRL states when the next full CRL will be 
available. This is important for supporting clients that do not handle 
delta CRLs. The nextUpdate field in a delta CRL states when the next CRL 
(either a delta CRL or a full CRL) will be available. As a general rule, if 
the CA is continuing to issue deltas, the nextUpdate in the delta will be 
the time by which the next delta will be available. If this is the last 
delta that the CA is going to issue, then the nextUpdate in the delta will 
be the time by which the next full CRL will be available. ("Available" 
SHOULD reflect distribution delays associated with the repository 
architecture.)

 >2) Does a CA needs to issue a delta CRL at the time a full CRL is issued ?
 >
 >Denis: No.
 >Tim/David/Russ : ???

No. A CA never is required to issue deltas. However, it would be helpful to 
delta CRL enabled clients to allow them to construct the full CRL.

If the full CRL contains a freshestCRL extension, then it is a very good 
idea to generate a delta CRL at the same time. In this way, any client will 
be able to find a current delta CRL.

 >3) Does a CA needs to issue a new base CRL at the end of the validity of a
 >current base CRL ?
 >
 >Denis: No.
 >Tim/David/Russ : ???

No. HOWEVER, the CA must issue a new full CRL by the nextUpdate in the 
previously issued full CRL (whether that full CRL is a base CRL or not). 
There is no requirement that the next full CRL be a base CRL. (The CA could 
quit issuing deltas, etc. etc.)

Every base CRL MUST be a full CRL, but not every full CRL is a base CRL. 
But, a CA could make every full CRL a base CRL if they wanted to.

 >4) Does a CA needs to issue a delta CRL at the same time a new base is
 >issued ?
 >
 >Denis: Yes. The delta CRL refers to the *new* base.
 >Tim/David/Russ : ???

No. HOWEVER, in practice we belive that CAs will do so. The delta CRL needs 
to exist so that clients can follow the freshest CRL extension (either in a 
certificate or a base CRL). The delta CRL that is issued at the same time 
SHOULD point to a previously issued full CRL (which will then, by 
definition be a base CRL) whenever possible. There is no information to add 
to the new base CRL! By providing the delta as an update to a previous base 
CRL, clients can download the delta CRL to construct the new base CRL.

 >The last point highlights the most noticeable difference. Other
differences
 >appears when considering the guaranty to get the freshest information :
 >using the traditional scheme and the thisUpdate and nextUpdate fields the
 >guaranty to get the freshest information is obtained, but cannot be
obtained
 >using the other scheme. :-(
 >
 >Several people are referring to the X.509 document for arguments to
support
 >that discussion. However, it is important to remember that we are defining
 >PKIX, not X.509, so we DO NOT need to copy and paste everything from
X.509,
 >but only what we believe is relevant.

PKIX is a profile of X.509.  PKIX may impose additional requirements beyond 
those in X.509 or may exclude features that are optional in X.509, but 
otherwise PKIX must be consistent with X.509. In that context, references 
to X.509 are appropriate.

 >We first need to clearly define the processing rules applicable to the
 >relying parties. These rules will certainly contain SHALL/MUST statements,
 >but may also include some MAY statements which may even be conditional to
 >what the CA is doing. (I let Tim/David or Russ provide the MAY statement).
 >
 >Here is a proposal for the MUST statement, based on the previous text I
 >produced:
 >
 >    An application that is wishing to take advantage of delta CRLs
 >    for a given scope, MUST first find a base CRL for that scope,
 >    i.e. a full CRL that that contains a freshestCRL extension
 >    (a.k.a. a Delta CRL distribution point).

No. The relying party needs a full CRL (either one that has been downloaded 
from a repository or one that has been locally generated) against which the 
delta CRL of interest may be applied. There is no requirement that the full 
CRL be a base CRL.

 >    It may then construct
 >    an updated CRL for that base, for a specific time T, by combining
 >    it with a delta CRL which contains a delta CRL indicator extension
 >    with the same CRL number as the base CRL.

It may construct an updated CRL by combining the delta CRL with any full 
CRL whose CRL number is greater than or equal to the CRL number of the 
referenced base.  By saying "equal" instead of "greater than or equal" we 
would be hiding useful information from implementors. We should not be 
hiding useful information.

 >    Applications that support
 >    delta CRLs MUST ensure that time T falls between thisUpdate and
 >    nextUpdate for both the base CRL and the delta CRL.

As stated above, the nextUpdate field in a base CRL specifies the time by 
which new revocation information will be available through full CRLs. A 
delta CRL may be applied to a base CRL as long as the CRL number in the 
base CRL is greater than or equal to the CRL number of the base CRL 
referenced by the delta CRL. The nextUpdate time of the base CRL is
irrelevant.

 >    Note: An application could also reconstruct an updated CRL, for
 >    a specific time T, by using a previously locally reconstructed CRL
 >    based on the current base CRL, and combining it with a delta CRL which
 >    contains a delta CRL indicator extension with the same CRL number as
 >    the base CRL.

Same problem as above.  Need to say "greater than or equal to".

 >We also need to clearly separate the issuing rules applicable for the CAs.
 >These rules will certainly contain SHALL statements, but could also
include
 >some MAY statements. (I let Tim/David or Russ provide the MAY statement).
 >
 >Here is a proposal for the MUST statement, based on the previous text I
 >produced:
 >
 >    A CA that supports delta-CRLs, MUST issue a base CRL,

This is an unnecessary statement. A delta CRL must include a BaseCRLNumber. 
The CRL specified by that BaseCRLNumber is by definition a base CRL.  Of 
course, the referenced base CRL MUST be a full CRL.

 >    i.e. a full
 >    CRL that contains a freshestCRL extension (a.k.a. a Delta CRL
 >    distribution point).

While it might be a good idea to mandate the inclusion of the frestestCRL 
extension in full CRLs that are issued for scopes in which delta CRLs are 
also being issued, there is currently no such requirement in the draft PKIX 
profile.

 >    For any time T until the nextUpdate time
 >    indicated in a base CRL, the CA MUST provide one and only one
 >    delta CRL that refers to that base CRL and for which time T
 >    falls between thisUpdate and nextUpdate from the delta CRL.

This sentence has several problems:

1) The nextUpdate time of a base CRL is the time when the next full CRL 
will be available, which may precede the time that the next base CRL will 
be issued.

2) There is no requirement that a delta CRL use the most recently issued 
base CRL as its base.  I suppose that we could add this requirement for the 
PKIX profile, but why?  Does it really simplify the client?  Or, does it 
just make it a wee bit harder to make a conforming CA that supports delta
CRLs?

3) If the thisUpdate time of one delta CRL must equal the nextUpdate time 
of the previously issued delta CRL, then no time can be allotted to account 
for propagation delays between when a delta-CRL is issued and when it is 
available in repositories for relying parties to obtain. Thus, there would 
be gaps between when the nextUpdate time of one delta-CRL was reached and 
when the next delta-CRL was available.

4) There is nothing in either X.509 or the PKIX profile that prevents a CA 
from issuing an unscheduled (or "emergency") delta CRL. And, there should 
not be!  Many CAs intend to issue a new CRL (delta or otherwise) 
immediately upon the revocation of a certificate due to key compromise. 
When such an "emergency" delta CRL is issued, there will be two delta CRLs 
for which T falls between thisUpdate and nextUpdate. While it is true that 
there is no guarantee that relying parties will obtain the fresher of these 
two delta CRLs, that is no reason to prevent the CA from issuing the 
"emergency" delta.  Some clients will obtain the emergency CRL.

 >In his e-mail from Wednesday, May 9, David said that delta-CRL processing
 >rules could be base on time instead of CRL numbers. This is a point of
which
 >I strongly agree. Let us do it!
 >
 >(However, there is no need to add to PKIX, as he suggested, the support of
 >the baseUpdateTime extension from X.509 which would even more complicate
the
 >problem.)

No. In order to base delta CRL processing on time, the baseUpdateTime 
extension must be present in the delta CRL. Furthermore, the presence of 
this extension would not complicate the problem. baseUpdateTime is a 
non-critical extension that merely provides useful information. If you 
don't think that the information provided by baseUpdateTime is useful, 
ignore it. Since the extension is non-critical and can be ignored, its 
presence can not complicate the problem.

At 09:05 AM 5/10/2001 -0400, Housley, Russ wrote:
>Denis:
>
>>There is difference between a base CRL and a full CRL
>
>You are quite right.  I, for one, will try to be more careful about the 
>use of them.
>
>>Due to the fact that CRLs numbers are strictly increasing, two CRLs
whether
>>they are a base CRL or delta CRL, CANNOT have the same CRL number.
>
>I disagree.  A full CRL (that may be a base CRL for subsequent delta CRLs) 
>and a delta CRL issued at the same time as that full CRL may actually 
>represent the same revocation information.  In this case, they are the 
>same CRL, and they should have the same number.  There have been several 
>tables posted that illustrate this numbering scheme, and I do not see any 
>text in X.509-200 that indicates this scheme is
[snip - truncate - the message is too long anyway]

------_=_NextPart_001_01C0D9A2.AC5D2A10
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: delta CRLs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Russ:</FONT>
</P>

<P><FONT SIZE=3D2>I agree with most of what you say except the =
following.</FONT>
</P>

<P><FONT SIZE=3D2>I think use of the &quot;full&quot; is =
dangerous.&nbsp; These CRLs are &quot;full&quot; only with respect to =
the scope as defined in the CRLScope and/or IDP extension.&nbsp; This =
is simply a nit.</FONT></P>

<P><FONT SIZE=3D2>You say &quot;Relying parties that do </FONT>
<BR><FONT SIZE=3D2>not process delta CRLs, and thus do not recognize =
the non-critical </FONT>
<BR><FONT SIZE=3D2>freshestCRL extension, will not be able to =
distinguish between those full </FONT>
<BR><FONT SIZE=3D2>CRLs that are base CRLs and those full CRLs that are =
not base CRLs.&quot;&nbsp; Do you mean a base could also be a delta as =
opposed to a full?&nbsp; If so, that distinction can be and will be =
made through the deltaCRLIndicator extension without.&nbsp; In any =
case, this point seems to be irrelevant.</FONT></P>

<P><FONT SIZE=3D2>You also say that &quot;Every base CRL MUST be a full =
CRL, but not every full CRL is a base CRL.&quot; </FONT>
</P>

<P><FONT SIZE=3D2>While I agree with most of what you say, your =
distinction between base and full (for scope) does not seem relevant or =
germane to me and seems to confuse the issue.&nbsp; But, I think (and =
hope) I understand this enough to know that I do NOT disagree with the =
final conclusions.&nbsp; Your rationale comes across more convoluted =
and confusing than it needs to be due to this needless distinction =
between base and full.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Housley, Russ [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, May 10, 2001 2:36 PM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: delta CRLs</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Denis:</FONT>
</P>

<P><FONT SIZE=3D2>Please excuse the half-done message from this =
morning.&nbsp; My mailer and I had </FONT>
<BR><FONT SIZE=3D2>a disagreement...</FONT>
</P>

<P><FONT SIZE=3D2>Anyway, since I was not going to get the full message =
out before the end of </FONT>
<BR><FONT SIZE=3D2>the business day in France, I took the time to =
coordinate a response with </FONT>
<BR><FONT SIZE=3D2>Tim Polk and David Cooper.&nbsp; This mail thread is =
quite long, so hopefully </FONT>
<BR><FONT SIZE=3D2>our coordination on the side will reduce the overall =
number of messages to </FONT>
<BR><FONT SIZE=3D2>the list and help to reach consensus faster.</FONT>
</P>

<P><FONT SIZE=3D2>Here goes ....</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&gt;There is difference between a base CRL and =
a full CRL : a base CRL MUST</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;include a freshestCRL extension (a.k.a. a =
Delta CRL distribution point),</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;whereas a full CRL may not include that =
extension. In other words, a base</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;CRL is a also a full CRL, but a full CRL =
is not necessarily a base CRL.</FONT>
</P>

<P><FONT SIZE=3D2>There is no requirement in X.509 to include any =
extension in a certificate </FONT>
<BR><FONT SIZE=3D2>or CRL advertising the availability of delta CRLs. =
PKIX makes the </FONT>
<BR><FONT SIZE=3D2>freshestCRL extension available for advertising the =
existence of delta </FONT>
<BR><FONT SIZE=3D2>CRLs, but again does not mandate its use. =
Furthermore, even if the </FONT>
<BR><FONT SIZE=3D2>freshestCRL extension is used, it may be placed in =
either the certificate </FONT>
<BR><FONT SIZE=3D2>or the full CRL. If the extension is placed in =
certificates, there is no </FONT>
<BR><FONT SIZE=3D2>need for it to be in the full CRL (but, it could =
be).</FONT>
</P>

<P><FONT SIZE=3D2>Finally, if delta CRLs are being issued, and are =
being advertised through </FONT>
<BR><FONT SIZE=3D2>the freshestCRL CRL extension, then the extension =
should be included in all </FONT>
<BR><FONT SIZE=3D2>full CRLs for that scope, not just the base CRLs. If =
a relying party </FONT>
<BR><FONT SIZE=3D2>obtains the most recently issued full CRL for a =
scope from a repository, </FONT>
<BR><FONT SIZE=3D2>and that full CRL is not a base CRL, how will the =
relying party know that </FONT>
<BR><FONT SIZE=3D2>delta CRLs are available?</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&gt;At any time a CA may issue a full CRL, =
whether or not a base CRL has already</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;been issued. This additional CRL SHOULD =
have nextUpdate equal to the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;nextUpdate of the last issued full CRL. =
However, there is no guarantee that</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;this additional CRL will ever be seen by =
the relying party (because there</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;will be two CRLs matching the thisUpdate =
and nextUpdate rule and if one is</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;deleted, this is not seen by a relying =
party).</FONT>
</P>

<P><FONT SIZE=3D2>The nextUpdate field in a full CRL (base or =
otherwise) should specify the </FONT>
<BR><FONT SIZE=3D2>time by which new revocation information will be =
available. So, if a new </FONT>
<BR><FONT SIZE=3D2>base CRL is issued once a day, but full CRLs are =
issued every hour, the </FONT>
<BR><FONT SIZE=3D2>nextUpdate field of each full CRL should one hour =
after that CRL's </FONT>
<BR><FONT SIZE=3D2>thisUpdate time.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&gt;Due to the fact that CRLs numbers are =
strictly increasing, two CRLs whether</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;they are a base CRL or delta CRL, CANNOT =
have the same CRL number. So a</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;delta CRL and a full CRL that cover the =
same scope and are issued at the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;same time CANNOT have the same =
number.</FONT>
</P>

<P><FONT SIZE=3D2>We disagree.&nbsp; If a full CRL and a delta CRL are =
issued at the same time for </FONT>
<BR><FONT SIZE=3D2>the same scope, then they ARE the same CRL and MUST =
have the same CRL number.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&gt;If a full CRL is issued, its CRL</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;number bears no relationship with the =
previous base CRL, if any.</FONT>
</P>

<P><FONT SIZE=3D2>Again, we disagree. A sequence of CRLs for a given =
scope must contain a </FONT>
<BR><FONT SIZE=3D2>monotonically increasing sequence of CRL numbers. =
Relying parties that do </FONT>
<BR><FONT SIZE=3D2>not process delta CRLs, and thus do not recognize =
the non-critical </FONT>
<BR><FONT SIZE=3D2>freshestCRL extension, will not be able to =
distinguish between those full </FONT>
<BR><FONT SIZE=3D2>CRLs that are base CRLs and those full CRLs that are =
not base CRLs. The CRL </FONT>
<BR><FONT SIZE=3D2>numbers for these full CRLs must be from one =
monotonically increasing sequence.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&gt;The only</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;relationship between the numbers is =
defined by the rule that CRLs numbers</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;are strictly increasing. As Santosh said : =
&quot;the CRL number is unique</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;whether it is a base or a delta =
&quot;.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;This is fairly important to be able to =
unambiguously (and thus uniquely)</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;refer to a CRL by only providing its CRL =
number.</FONT>
</P>

<P><FONT SIZE=3D2>Exactly. If a full CRL and the delta CRL are issued =
for the same scope at </FONT>
<BR><FONT SIZE=3D2>the same time, they are the same CRL. The CRL number =
unambiguously and </FONT>
<BR><FONT SIZE=3D2>uniquely refers to this ONE CRL.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&gt;Besides the fact that a CRL issued later =
MUST have a higher CRL number, full</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;CRLs and delta CRLs have independent =
numbering rules. As noticed by Santosh,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;&quot; if the delta thisUpdate &gt; base =
thisUpdate, delta CRL number &gt; base CRL</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;number (for the same or no stream =
identifier).</FONT>
</P>

<P><FONT SIZE=3D2>If you agree that delta thisUpdate &gt; base =
thisUpdate implies delta CRL </FONT>
<BR><FONT SIZE=3D2>number &gt; base CRL, then you are acknowledging =
that the CRL numbers of the </FONT>
<BR><FONT SIZE=3D2>full CRLs and delta CRLs are not independent.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&gt;As Santosh said : &quot;a check based on =
thisUpdate is more general and</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;preferred [to the use of CRL numbers]. =
&quot;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;Related to the three rules mentioned by =
Russ :</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;1) the first rule is not understandable to =
me.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;2) the second rule does not say anything =
more than the basic rule valid</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; for any CRL (i.e. a CRL =
issued later MUST have a higher CRL number).</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;3) we will debate the hold condition, once =
we will have sorted the main</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; issue.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;Russ said : &quot;If separate number =
sequence is used, then you will have to</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;periodically fetch base CRLs &quot;. This =
is true.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;Tim said that he would *not* like to be =
forced to download new base CRLs.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;This is the core of the =
&quot;dispute&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>Our goal should be to allow delta CRL enabled clients =
to obtain accurate </FONT>
<BR><FONT SIZE=3D2>information in the most efficient manner possible. =
Forcing clients to </FONT>
<BR><FONT SIZE=3D2>periodically download full CRLs, when this is not =
necessary, is inefficient.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&gt; From the definition of what a delta CRL =
is, it is *not* possible to</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;get rid of the fetching of base CRLs. =
Unless we add a new sentence to</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;expand/change that definition, base CRL =
fetching will remain mandatory.</FONT>
</P>

<P><FONT SIZE=3D2>True. However, if one performs validations frequently =
enough, it is </FONT>
<BR><FONT SIZE=3D2>possible to obtain a single full CRL and then =
subsequently download only </FONT>
<BR><FONT SIZE=3D2>delta CRLs. We need to require that full CRL be =
issued periodically so that </FONT>
<BR><FONT SIZE=3D2>clients whose locally stored information is not =
sufficiently up-to-date to </FONT>
<BR><FONT SIZE=3D2>apply the delta CRLs being issued can obtain the =
full CRLs that they need, </FONT>
<BR><FONT SIZE=3D2>but we should not require clients to download full =
CRLs when it is not </FONT>
<BR><FONT SIZE=3D2>necessary for them to do so.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&gt;Remember that the goal of delta CRLs is to =
provide the freshest information,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;and to my knowledge the goal was not to =
get rid of the fetching of base CRLs</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;(which may less frequent due to the =
support of delta CRLs).</FONT>
</P>

<P><FONT SIZE=3D2>Yes, but the goal should be to minimize the fetching =
of full CRLs.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&gt;If I understand correctly, Tim/David/Russ =
would like to *always* achieve the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;following property : it is possible to =
reconstruct the current CRL by using</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;a base CRL from, e.g. 1990, i.e. by =
capturing every delta CRL that has been</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;issued at the same time a base CRL was =
issued and which contains updates</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;made to the *previous* base.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;By this way the fetching of base CRLs =
could be avoided. However, note that</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;it is perfectly &quot; legal &quot; to =
stop issuing base and delta CRLs during some</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;period of time and to issue full CRLs =
instead (see the difference between</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;&quot;full&quot; and &quot;base&quot; at =
the top of this e-mail). In other words there is no</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;need to issue a new base CRL at the end of =
the validity period of the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;previous base CRL. Doing this would =
mandate to prescribe issuing rules</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;for CAs that we have not =
prescripted.</FONT>
</P>

<P><FONT SIZE=3D2>You are mixing apples and oranges. Obviously the =
scheme of keeping </FONT>
<BR><FONT SIZE=3D2>up-to-date by obtaining a base from 1990 and then =
only downloading deltas </FONT>
<BR><FONT SIZE=3D2>will only work so long as deltas continue to be =
issued. If the CRL issuer </FONT>
<BR><FONT SIZE=3D2>ceases to issue deltas, then the relying parties =
will have to revert to </FONT>
<BR><FONT SIZE=3D2>downloading full CRLs.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&gt;I will now raise a series of questions, for =
which I believe we have</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;different answers. Tim/David/Russ do not =
hesitate to correct</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;if my guess is wrong. ;-)</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;Common point:</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;1) What will be the value of the =
nextUpdate field from the last issued delta</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;CRL for a given base CRL ?</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;Denis: the nextUpdate field from the last =
issued delta CRL MUST be equal to</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;the value of nextUpdate from the base =
CRL.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;Tim/David/Russ: ???</FONT>
</P>

<P><FONT SIZE=3D2>The nextUpdate field in a base CRL states when the =
next full CRL will be </FONT>
<BR><FONT SIZE=3D2>available. This is important for supporting clients =
that do not handle </FONT>
<BR><FONT SIZE=3D2>delta CRLs. The nextUpdate field in a delta CRL =
states when the next CRL </FONT>
<BR><FONT SIZE=3D2>(either a delta CRL or a full CRL) will be =
available. As a general rule, if </FONT>
<BR><FONT SIZE=3D2>the CA is continuing to issue deltas, the nextUpdate =
in the delta will be </FONT>
<BR><FONT SIZE=3D2>the time by which the next delta will be available. =
If this is the last </FONT>
<BR><FONT SIZE=3D2>delta that the CA is going to issue, then the =
nextUpdate in the delta will </FONT>
<BR><FONT SIZE=3D2>be the time by which the next full CRL will be =
available. (&quot;Available&quot; </FONT>
<BR><FONT SIZE=3D2>SHOULD reflect distribution delays associated with =
the repository </FONT>
<BR><FONT SIZE=3D2>architecture.)</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&gt;2) Does a CA needs to issue a delta CRL at =
the time a full CRL is issued ?</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;Denis: No.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;Tim/David/Russ : ???</FONT>
</P>

<P><FONT SIZE=3D2>No. A CA never is required to issue deltas. However, =
it would be helpful to </FONT>
<BR><FONT SIZE=3D2>delta CRL enabled clients to allow them to construct =
the full CRL.</FONT>
</P>

<P><FONT SIZE=3D2>If the full CRL contains a freshestCRL extension, =
then it is a very good </FONT>
<BR><FONT SIZE=3D2>idea to generate a delta CRL at the same time. In =
this way, any client will </FONT>
<BR><FONT SIZE=3D2>be able to find a current delta CRL.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&gt;3) Does a CA needs to issue a new base CRL =
at the end of the validity of a</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;current base CRL ?</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;Denis: No.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;Tim/David/Russ : ???</FONT>
</P>

<P><FONT SIZE=3D2>No. HOWEVER, the CA must issue a new full CRL by the =
nextUpdate in the </FONT>
<BR><FONT SIZE=3D2>previously issued full CRL (whether that full CRL is =
a base CRL or not). </FONT>
<BR><FONT SIZE=3D2>There is no requirement that the next full CRL be a =
base CRL. (The CA could </FONT>
<BR><FONT SIZE=3D2>quit issuing deltas, etc. etc.)</FONT>
</P>

<P><FONT SIZE=3D2>Every base CRL MUST be a full CRL, but not every full =
CRL is a base CRL. </FONT>
<BR><FONT SIZE=3D2>But, a CA could make every full CRL a base CRL if =
they wanted to.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&gt;4) Does a CA needs to issue a delta CRL at =
the same time a new base is</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;issued ?</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;Denis: Yes. The delta CRL refers to the =
*new* base.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;Tim/David/Russ : ???</FONT>
</P>

<P><FONT SIZE=3D2>No. HOWEVER, in practice we belive that CAs will do =
so. The delta CRL needs </FONT>
<BR><FONT SIZE=3D2>to exist so that clients can follow the freshest CRL =
extension (either in a </FONT>
<BR><FONT SIZE=3D2>certificate or a base CRL). The delta CRL that is =
issued at the same time </FONT>
<BR><FONT SIZE=3D2>SHOULD point to a previously issued full CRL (which =
will then, by </FONT>
<BR><FONT SIZE=3D2>definition be a base CRL) whenever possible. There =
is no information to add </FONT>
<BR><FONT SIZE=3D2>to the new base CRL! By providing the delta as an =
update to a previous base </FONT>
<BR><FONT SIZE=3D2>CRL, clients can download the delta CRL to construct =
the new base CRL.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&gt;The last point highlights the most =
noticeable difference. Other differences</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;appears when considering the guaranty to =
get the freshest information :</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;using the traditional scheme and the =
thisUpdate and nextUpdate fields the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;guaranty to get the freshest information =
is obtained, but cannot be obtained</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;using the other scheme. :-(</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;Several people are referring to the X.509 =
document for arguments to support</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;that discussion. However, it is important =
to remember that we are defining</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;PKIX, not X.509, so we DO NOT need to copy =
and paste everything from X.509,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;but only what we believe is =
relevant.</FONT>
</P>

<P><FONT SIZE=3D2>PKIX is a profile of X.509.&nbsp; PKIX may impose =
additional requirements beyond </FONT>
<BR><FONT SIZE=3D2>those in X.509 or may exclude features that are =
optional in X.509, but </FONT>
<BR><FONT SIZE=3D2>otherwise PKIX must be consistent with X.509. In =
that context, references </FONT>
<BR><FONT SIZE=3D2>to X.509 are appropriate.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&gt;We first need to clearly define the =
processing rules applicable to the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;relying parties. These rules will =
certainly contain SHALL/MUST statements,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;but may also include some MAY statements =
which may even be conditional to</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;what the CA is doing. (I let Tim/David or =
Russ provide the MAY statement).</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;Here is a proposal for the MUST statement, =
based on the previous text I</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;produced:</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; An application that is =
wishing to take advantage of delta CRLs</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; for a given scope, MUST =
first find a base CRL for that scope,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; i.e. a full CRL that =
that contains a freshestCRL extension</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; (a.k.a. a Delta CRL =
distribution point).</FONT>
</P>

<P><FONT SIZE=3D2>No. The relying party needs a full CRL (either one =
that has been downloaded </FONT>
<BR><FONT SIZE=3D2>from a repository or one that has been locally =
generated) against which the </FONT>
<BR><FONT SIZE=3D2>delta CRL of interest may be applied. There is no =
requirement that the full </FONT>
<BR><FONT SIZE=3D2>CRL be a base CRL.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; It may then =
construct</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; an updated CRL for that =
base, for a specific time T, by combining</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; it with a delta CRL =
which contains a delta CRL indicator extension</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; with the same CRL =
number as the base CRL.</FONT>
</P>

<P><FONT SIZE=3D2>It may construct an updated CRL by combining the =
delta CRL with any full </FONT>
<BR><FONT SIZE=3D2>CRL whose CRL number is greater than or equal to the =
CRL number of the </FONT>
<BR><FONT SIZE=3D2>referenced base.&nbsp; By saying &quot;equal&quot; =
instead of &quot;greater than or equal&quot; we </FONT>
<BR><FONT SIZE=3D2>would be hiding useful information from =
implementors. We should not be </FONT>
<BR><FONT SIZE=3D2>hiding useful information.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; Applications that =
support</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; delta CRLs MUST ensure =
that time T falls between thisUpdate and</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; nextUpdate for both the =
base CRL and the delta CRL.</FONT>
</P>

<P><FONT SIZE=3D2>As stated above, the nextUpdate field in a base CRL =
specifies the time by </FONT>
<BR><FONT SIZE=3D2>which new revocation information will be available =
through full CRLs. A </FONT>
<BR><FONT SIZE=3D2>delta CRL may be applied to a base CRL as long as =
the CRL number in the </FONT>
<BR><FONT SIZE=3D2>base CRL is greater than or equal to the CRL number =
of the base CRL </FONT>
<BR><FONT SIZE=3D2>referenced by the delta CRL. The nextUpdate time of =
the base CRL is irrelevant.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; Note: An application =
could also reconstruct an updated CRL, for</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; a specific time T, by =
using a previously locally reconstructed CRL</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; based on the current =
base CRL, and combining it with a delta CRL which</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; contains a delta CRL =
indicator extension with the same CRL number as</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; the base CRL.</FONT>
</P>

<P><FONT SIZE=3D2>Same problem as above.&nbsp; Need to say =
&quot;greater than or equal to&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&gt;We also need to clearly separate the =
issuing rules applicable for the CAs.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;These rules will certainly contain SHALL =
statements, but could also include</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;some MAY statements. (I let Tim/David or =
Russ provide the MAY statement).</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;Here is a proposal for the MUST statement, =
based on the previous text I</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;produced:</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; A CA that supports =
delta-CRLs, MUST issue a base CRL,</FONT>
</P>

<P><FONT SIZE=3D2>This is an unnecessary statement. A delta CRL must =
include a BaseCRLNumber. </FONT>
<BR><FONT SIZE=3D2>The CRL specified by that BaseCRLNumber is by =
definition a base CRL.&nbsp; Of </FONT>
<BR><FONT SIZE=3D2>course, the referenced base CRL MUST be a full =
CRL.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; i.e. a full</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; CRL that contains a =
freshestCRL extension (a.k.a. a Delta CRL</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; distribution =
point).</FONT>
</P>

<P><FONT SIZE=3D2>While it might be a good idea to mandate the =
inclusion of the frestestCRL </FONT>
<BR><FONT SIZE=3D2>extension in full CRLs that are issued for scopes in =
which delta CRLs are </FONT>
<BR><FONT SIZE=3D2>also being issued, there is currently no such =
requirement in the draft PKIX </FONT>
<BR><FONT SIZE=3D2>profile.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; For any time T until the =
nextUpdate time</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; indicated in a base =
CRL, the CA MUST provide one and only one</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; delta CRL that refers =
to that base CRL and for which time T</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; falls between =
thisUpdate and nextUpdate from the delta CRL.</FONT>
</P>

<P><FONT SIZE=3D2>This sentence has several problems:</FONT>
</P>

<P><FONT SIZE=3D2>1) The nextUpdate time of a base CRL is the time when =
the next full CRL </FONT>
<BR><FONT SIZE=3D2>will be available, which may precede the time that =
the next base CRL will </FONT>
<BR><FONT SIZE=3D2>be issued.</FONT>
</P>

<P><FONT SIZE=3D2>2) There is no requirement that a delta CRL use the =
most recently issued </FONT>
<BR><FONT SIZE=3D2>base CRL as its base.&nbsp; I suppose that we could =
add this requirement for the </FONT>
<BR><FONT SIZE=3D2>PKIX profile, but why?&nbsp; Does it really simplify =
the client?&nbsp; Or, does it </FONT>
<BR><FONT SIZE=3D2>just make it a wee bit harder to make a conforming =
CA that supports delta CRLs?</FONT>
</P>

<P><FONT SIZE=3D2>3) If the thisUpdate time of one delta CRL must equal =
the nextUpdate time </FONT>
<BR><FONT SIZE=3D2>of the previously issued delta CRL, then no time can =
be allotted to account </FONT>
<BR><FONT SIZE=3D2>for propagation delays between when a delta-CRL is =
issued and when it is </FONT>
<BR><FONT SIZE=3D2>available in repositories for relying parties to =
obtain. Thus, there would </FONT>
<BR><FONT SIZE=3D2>be gaps between when the nextUpdate time of one =
delta-CRL was reached and </FONT>
<BR><FONT SIZE=3D2>when the next delta-CRL was available.</FONT>
</P>

<P><FONT SIZE=3D2>4) There is nothing in either X.509 or the PKIX =
profile that prevents a CA </FONT>
<BR><FONT SIZE=3D2>from issuing an unscheduled (or =
&quot;emergency&quot;) delta CRL. And, there should </FONT>
<BR><FONT SIZE=3D2>not be!&nbsp; Many CAs intend to issue a new CRL =
(delta or otherwise) </FONT>
<BR><FONT SIZE=3D2>immediately upon the revocation of a certificate due =
to key compromise. </FONT>
<BR><FONT SIZE=3D2>When such an &quot;emergency&quot; delta CRL is =
issued, there will be two delta CRLs </FONT>
<BR><FONT SIZE=3D2>for which T falls between thisUpdate and nextUpdate. =
While it is true that </FONT>
<BR><FONT SIZE=3D2>there is no guarantee that relying parties will =
obtain the fresher of these </FONT>
<BR><FONT SIZE=3D2>two delta CRLs, that is no reason to prevent the CA =
from issuing the </FONT>
<BR><FONT SIZE=3D2>&quot;emergency&quot; delta.&nbsp; Some clients will =
obtain the emergency CRL.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&gt;In his e-mail from Wednesday, May 9, David =
said that delta-CRL processing</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;rules could be base on time instead of CRL =
numbers. This is a point of which</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;I strongly agree. Let us do it!</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;(However, there is no need to add to PKIX, =
as he suggested, the support of</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;the baseUpdateTime extension from X.509 =
which would even more complicate the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;problem.)</FONT>
</P>

<P><FONT SIZE=3D2>No. In order to base delta CRL processing on time, =
the baseUpdateTime </FONT>
<BR><FONT SIZE=3D2>extension must be present in the delta CRL. =
Furthermore, the presence of </FONT>
<BR><FONT SIZE=3D2>this extension would not complicate the problem. =
baseUpdateTime is a </FONT>
<BR><FONT SIZE=3D2>non-critical extension that merely provides useful =
information. If you </FONT>
<BR><FONT SIZE=3D2>don't think that the information provided by =
baseUpdateTime is useful, </FONT>
<BR><FONT SIZE=3D2>ignore it. Since the extension is non-critical and =
can be ignored, its </FONT>
<BR><FONT SIZE=3D2>presence can not complicate the problem.</FONT>
</P>

<P><FONT SIZE=3D2>At 09:05 AM 5/10/2001 -0400, Housley, Russ =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;Denis:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;There is difference between a base CRL and a =
full CRL</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;You are quite right.&nbsp; I, for one, will try =
to be more careful about the </FONT>
<BR><FONT SIZE=3D2>&gt;use of them.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;Due to the fact that CRLs numbers are =
strictly increasing, two CRLs whether</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;they are a base CRL or delta CRL, CANNOT =
have the same CRL number.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;I disagree.&nbsp; A full CRL (that may be a base =
CRL for subsequent delta CRLs) </FONT>
<BR><FONT SIZE=3D2>&gt;and a delta CRL issued at the same time as that =
full CRL may actually </FONT>
<BR><FONT SIZE=3D2>&gt;represent the same revocation information.&nbsp; =
In this case, they are the </FONT>
<BR><FONT SIZE=3D2>&gt;same CRL, and they should have the same =
number.&nbsp; There have been several </FONT>
<BR><FONT SIZE=3D2>&gt;tables posted that illustrate this numbering =
scheme, and I do not see any </FONT>
<BR><FONT SIZE=3D2>&gt;text in X.509-200 that indicates this scheme =
is</FONT>
<BR><FONT SIZE=3D2>[snip - truncate - the message is too long =
anyway]</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0D9A2.AC5D2A10--


Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA01604 for <[e-mail]>; Thu, 10 May 2001 14:12:54 -0700 (PDT)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id RAA23893 for <[e-mail]>; Thu, 10 May 2001 17:12:54 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Thu, 10 May 2001 17:12:16 -0400
To: [e-mail]
From: Tim Polk <[e-mail]> (by way of "David A. Cooper" <[e-mail]>)
Subject: Fwd: Strawman on Delta CRLs
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====================_32329696==_"

--=====================_32329696==_
Content-Type: text/plain; charset="us-ascii"

Folks,

David Cooper, Russ Housley and I have collaborated on a "strawman" describing the use of delta CRLs in PKIX implementations.  We believe the functionality we describe is consistent with ISO X.509 as well.

The text describes algorithms for using deltas and base CRLs to (a) check the status of a certificate or (b) create a constructed CRL.  This is followed by three scenarios for the use of deltas - "traditional deltas", "sliding window deltas", and a variant on sliding window deltas that factors in the real world delays in populating repositories with base and delta CRLs.

I have appended the strawman below in ASCII text.  The text includes tables for the examples.  Please note, these tables *require* a fixed font to be legible.  I have also attached a copy of the document in Word, for those that would prefer that format.  The Word version may be easier to read.

Hopefully, this strawman will serve to frame further discussions and accelerate consensus.   Once we agree on the requirements, Russ and I will draft the necessary changes and we can finish Last Call.  (I am nothing if not an optimist.)

We would also like to add the examples as an *informative* appendix in son-of-2459.

Thanks,

Tim Polk


--------------------------------strawman---------------------------

Implementing Delta CRLs Using PKIX

This paper addresses the use of delta CRLs in PKIX-compliant systems.
This paper assumes that delta CRLs include the delta CRL indicator
extension (rather than a CRL scope extension) and ignores
complications involving combined delta CRLs from indirect CRL issuers.

This paper also assumes that CRLs with different scopes are distributed
using different distribution points.

Terms

Revoked: A statement that a particular certificate's status has changed
and it should no longer be trusted.  Once a certificate is revoked, it
is always revoked.

Suspension: A statement that a particular certificate may not be
trustworthy. Once placed on hold, a certificate may be revoked or the
suspension may be lifted.

Revocation notice: A statement that a particular certificate has been
suspended or revoked.  The revocation statement identifies the certificate
by the issuer name and serial number.  The issuer may be specified
explicitly or implicitly. The issuer may be explicitly identified using
the certificate issuer extension. If not specified explicitly, the issuer
of the certificate is implicitly identified as the issuer of the CRL. A
revocation notice includes the date and time the certificate was revoked.
A revocation notice may optionally include a revocation reason in the
reason code CRL entry extension. [Note: A revocation notice may optionally
specify in the invalidity date extension the date from which the
certificate should be considered invalid.  This date may precede the actual
revocation date.  The invalidity date extension does not feature in this
discussion, so it is not considered further in this paper.]

Certificate revocation list (CRL):  a list of revocation notices for
certificates.

CRL scope: the set of certificates that could appear on a given CRL.
For example, the scope may be "all certificates issued by CA X", "all
CA and end entity certificates issued by CA X", "all certificates issued
by CA X that have been revoked for key compromise and CA compromise", or
may be a set of certificates based on local information, such as "all
certificates issued to the NIST employees located in Boulder".

Full CRL: a CRL that lists all unexpired certificates, in its scope, that
have been revoked for one of the revocation reasons covered by the scope
of the CRL. The scope of a full CRL does not necessarily include all of
the certificates issued by a CA or all possible revocation reasons.

Base CRL:  the particular CRL used as the foundation for a delta CRL.  The
base must be a full CRL.

Delta CRL:  a CRL that only lists those unexpired certificates, in its scope,
whose revocation status has changed since the issuance of a particular,
referenced base CRL. The scope of a delta CRL is must be the same as the base
CRL that it references

CRL Numbering

A CRL issuer may generate full CRLs for more than one scope.  The CRL issuer
may also generate delta CRLs.  Each delta CRLs must have the same scope as the
full CRL referenced as its base.

For each scope supported by the CRL issuer, a numbering sequence must be
maintained.  For each scope, the CRLs are numbered in a monotonically increasing
sequence.  (Wrapping is not permitted in the PKIX profile.)  If a CRL issuer
generates CRLs for one scope (e.g., full CRLs and deltas CRLs), the issuer must
maintain one numbering sequence.  If a delta CRL and a full CRL that cover the
same scope are issued at the same time, they will have the same CRL number.

If a CRL issuer generates CRLs for two scopes (e.g., one covering CA
certificates and one covering end entity certificates), then the CRL issuer must
maintain two number sequences.  The CRLs and deltas for the same scope (e.g., CA
certificates) will share one numbering sequence.  The CRLs and deltas for the
second scope (e.g., end entity certificates) will share one numbering sequence.
There is no requirement that these sequences be disjoint.

Algorithms for Determining Status from a Full CRL and a Delta CRL

Consider a full CRL, F, with CRL number X.  A client may obtain BF in either of
the following ways:
(a) the full CRL F may have been pushed to the client or pulled from a repository; or
(b) F may have been constructed from a full CRL and a delta CRL using this algorithm.

Consider a delta CRL, D, which specifies base CRL Y and has CRL number Z.  This
means that all certificates whose statuses have changed since the issuance of CRL Y
will be listed on the delta CRL.  Note that the PKIX profile requires the CA to issue
CRL Y as a full CRL.

Determining Whether a Full CRL and Delta CRL May Be Combined

F and D may be combined if each of the following conditions are met:

(1)     X is greater than or equal to Y.  That is, the full CRL must (at a minimum)
contain all the revocation information held by the referenced base CRL.
(2)     X is less than Z.  That is, the delta CRL must cover some time that was not
covered by the full CRL.

Determining Status of a Certificate from a Full CRL and a Delta CRL

If the PKI client maintains the delta and full CRL, the status of an unexpired
certificate C may be determined as follows:

(1)     If C is listed on the delta CRL, then:
a.      If C is listed on the delta CRL with reason code "removeFromCRL", then C
is not revoked.
b.      Otherwise, certificate C is revoked.
(2)     If C was not listed on the delta CRL, then the full CRL is checked, and the
status is as follows:
a.      If C is listed on the full CRL, then C is revoked.
b.      If C is not listed on the full CRL, then C is not revoked.

Combining a Full CRL and Delta CRL into a Constructed CRL

If the PKI client maintains the current CRL in a local cache:

The revocation information on F is assumed as the initial condition.  F is a list
of revoked certificates; each certificate is listed with a revocation reason
(which may be "unspecified").

The list of revoked certificates L with n entries denoted as L[i] where 1 <= i <= n.
(The value n may shrink or grow as the combination process proceeds.)

Initialize L to the revocation notices on F.  For each certificate C on the delta CRL,
update the contents of L as follows.

If a certificate C appears on the delta CRL, and C is not currently in the list L,
then:
(a)     if C has a revocation reason other than "removeFromCRL", add C as a new entry
in  the list of revoked certificates L.
(b)     If C has revocation reason "removeFromCRL", skip this certificate.  No update
to the cache is needed.

If a certificate C appears on the delta CRL, and C is presently listed in L as entry
L[i], then:
(a)     If C is listed on the delta CRL with a revocation reason of "removeFromCRL",
delete entry L[i]
(b)     If C is listed on the delta CRL without a revocation reason or with a revocation
reason other than "removeFromCRL", change the reason code associated with L[i] to the
reason code specified in the delta CRL.

The combination of F and D forms a new full CRL with CRL number Z.  This full CRL has
complete information until the time specified in the next update field in the delta CRL
is reached.  If a relying party is validating a certificate with respect to time T, and
T is before the next update field in the delta CRL, they may assume complete information.

If an unexpired certificate C within the scope of the constructed CRL is not listed, then
certificate C is not revoked for one of the revocation reasons covered by this CRL.  If
the constructed CRL covers all reasons, then the certificate C is not revoked.

Using Deltas to Distribute Revocation Information

This section provides three different scenarios for the use of delta CRLs.  For the
purpose of these examples, assume a goal of providing revocation information to relying
parties that is no more than one hour old.

The following notation is used to denote a revoked certificate on a CRL:
                 Xr      certificate X is listed for reason r, where r in {a,k,h,r}
The reason codes {a,k,h,r} correspond to "affiliation changed", "key compromise",
"certificate hold", and "remove from CRL" respectively.

(Note:  The remaining reason codes are omitted for simplicity.  The handling of
certificates revoked for  the reasons "unspecified", "CA compromise", "superseded", and
"cessationOfOperation" are identical to "affiliation changed or "key compromise").



Example #1

The example below shows the "traditional" method of issuing delta CRLs.
In this example, full CRLs are issued once every 3 hours and deltas are
issued once an hour. For consistency, the issuer begins issuing deltas
at the same time as the very first full CRL. After that, however, a delta
can always use a previously issued full CRL as its base. Notice that
starting with cRLNumber 4, the delta CRL issued at the same time as a
full CRL uses the previously issued full CRL as its base. However, the
delta-CRLs never provide more than 3 hours of history.

In this example:
Certificate 14 was revoked for key compromise before 12:00 when the first
CRL was issued.
Certificate 124 was revoked for key compromise between 12:00 and 13:00.
Certificate 39 was placed on hold between 14:00 and 15:00, and its
suspension was lifted between 16:00 and 17:00.
Certificate 67 was revoked for an affiliation change between 16:00 and
17:00.  The reason was changed to key compromise between 18:00 and 19:00.

current  | Revoked      | Full CRL                 | Delta-CRL
time     | certificates |                          |
---------|--------------|--------------------------|----------------------
12:00    | {14k}        | cRLNumber = 1            | cRLNumber = 1
          |              | thisUpdate = 12:00       | thisUpdate = 12:00
          |              | nextUpdate = 15:00       | nextUpdate = 13:00
          |              | CertificateList = {14k}  | BaseCRLNumber = 1
          |              |                          | CertificateList = {}
---------|--------------|--------------------------|----------------------
13:00    | {14k, 124k}  |                          | cRLNumber = 2
          |              |                          | thisUpdate = 13:00
          |              |                          | nextUpdate = 14:00
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList = {124k}
---------|--------------|--------------------------|----------------------
14:00    | {14k, 124k}  |                          | cRLNumber = 3
          |              |                          | thisUpdate = 14:00
          |              |                          | nextUpdate = 15:00
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList = {124k}
---------|--------------|--------------------------|----------------------
15:00    | {14k, 124k,  | cRLNumber = 4            | cRLNumber = 4
          |   39h}       | thisUpdate = 15:00       | thisUpdate = 15:00
          |              | nextUpdate = 18:00       | nextUpdate = 16:00
          |              | CertificateList =        | BaseCRLNumber = 1
          |              |  {14k, 124k, 39h}        | CertificateList =
          |              |                          | {124k, 39h}
---------|--------------|--------------------------|----------------------
16:00    | {14k, 124k,  |                          | cRLNumber = 5
          |   39h, 67a}  |                          | thisUpdate = 16:00
          |              |                          | nextUpdate = 17:00
          |              |                          | BaseCRLNumber = 4
          |              |                          | CertificateList = {67a}
          |              |                          |
---------|--------------|--------------------------|----------------------
17:00    | {14k, 124k,  |                          | cRLNumber = 6
          |   67a}       |                          | thisUpdate = 17:00
          |              |                          | nextUpdate = 18:00
          |              |                          | BaseCRLNumber = 4
          |              |                          | CertificateList =
          |              |                          | {39r, 67a}
---------|--------------|--------------------------|----------------------
18:00    | {14k, 124k,  | cRLNumber = 7            | cRLNumber = 7
          |   67a}       | thisUpdate = 18:00       | thisUpdate = 18:00
          |              | nextUpdate = 21:00       | nextUpdate = 19:00
          |              | CertificateList =        | BaseCRLNumber = 4
          |              | {14k, 124k, 67a}         | CertificateList =
          |              |                          | {39r, 67a}
---------|--------------|--------------------------|----------------------
19:00    | {14k, 124k,  |                          | cRLNumber = 8
          |   67k}       |                          | thisUpdate = 19:00
          |              |                          | nextUpdate = 20:00
          |              |                          | BaseCRLNumber = 7
          |              |                          | CertificateList = {67k}
---------|--------------|--------------------------|----------------------

Scenario #2

The example below shows the "sliding window" method of issuing delta-CRLs.
In this example, full CRLs are issued once every 3 hours and deltas are
issued once an hour. For consistency, the issuer begins issuing deltas at
the same time as the very first full CRL. Notice that starting with
cRLNumber 7, the delta CRL issued at the same time as a full CRL does not
use the previously issued full CRL as its base but the preceding CRL instead.
However, these delta-CRLs never provide more than 6 hours of history.

As in example #1:
Certificate 14 was revoked for key compromise before 12:00 when the first
CRL was issued.
Certificate 124 was revoked for key compromise between 12:00 and 13:00.
Certificate 39 was placed on hold between 14:00 and 15:00, and its
suspension was lifted between
16:00 and 17:00.
Certificate 67 was revoked for an affiliation change between 16:00 and 17:00.
The reason was changed to key compromise between 18:00 and 19:00.

current  | Revoked      | Full CRL                 | Delta-CRL
time     | certificates |                          |
---------|--------------|--------------------------|----------------------
12:00    | {14k}        | cRLNumber = 1            | cRLNumber = 1
          |              | thisUpdate = 12:00       | thisUpdate = 12:00
          |              | nextUpdate = 15:00       | nextUpdate = 13:00
          |              | CertificateList = {14k}  | BaseCRLNumber = 1
          |              |                          | CertificateList = {}
---------|--------------|--------------------------|----------------------
13:00    | {14k, 124k}  |                          | cRLNumber = 2
          |              |                          | thisUpdate = 13:00
          |              |                          | nextUpdate = 14:00
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList = {124k}
---------|--------------|--------------------------|----------------------
14:00    | {14k, 124k}  |                          | cRLNumber = 3
          |              |                          | thisUpdate = 14:00
          |              |                          | nextUpdate = 15:00
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList = {124k}
---------|--------------|--------------------------|----------------------
15:00    | {14k, 124k,  | cRLNumber = 4            | cRLNumber = 4
          |   39h}       | thisUpdate = 15:00       | thisUpdate = 15:00
          |              | nextUpdate = 18:00       | nextUpdate = 16:00
          |              | CertificateList =        | BaseCRLNumber = 1
          |              |  {14k, 124k, 39h}        | CertificateList =
          |              |                          | {124k, 39h}
---------|--------------|--------------------------|----------------------
16:00    | {14k, 124k,  |                          | cRLNumber = 5
          |   39h, 67a}  |                          | thisUpdate = 16:00
          |              |                          | nextUpdate = 17:00
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList =
          |              |                          | {124k, 39h, 67a}
---------|--------------|--------------------------|----------------------
17:00    | {14k, 124k,  |                          | cRLNumber = 6
          |   67a}       |                          | thisUpdate = 17:00
          |              |                          | nextUpdate = 18:00
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList =
          |              |                          | {124k, 39h, 67a}
---------|--------------|--------------------------|----------------------
18:00    | {14k, 124k,  | cRLNumber = 7            | cRLNumber = 7
          |   67a}       | thisUpdate = 18:00       | thisUpdate = 18:00
          |              | nextUpdate = 21:00       | nextUpdate = 19:00
          |              | CertificateList =        | BaseCRLNumber = 1
          |              | {14k, 124k, 67a}         | CertificateList =
          |              |                          | {124k, 39r, 67a}
---------|--------------|--------------------------|----------------------
19:00    | {14k, 124k,  |                          | cRLNumber = 8
          |   67k}       |                          | thisUpdate = 19:00
          |              |                          | nextUpdate = 20:00
          |              |                          | BaseCRLNumber = 7
          |              |                          | CertificateList =
          |              |                          | {39r, 67k
---------|--------------|--------------------------|----------------------


Note that the delta CRLs are marginally larger than in the first scenario
since they cover a longer time period.  On the other hand, a relying party
is less likely to download full CRLs in the second scenario.

For example, a relying party that validated one certificate at 12:15, then
a second certificate at 16:15 would not require a new full CRL in scenario #2.
In scenario #1, the relying party would be forced to obtain both full CRL 4
and delta CRL 5.

Scenario #3 Allowing for Replication/Propagation Delays

In this scenario, full CRLs and delta CRLs are replicated throughout a
repository system.  Data is replicated through the system at different
rates based on the size of the file.  The CA operators estimate that full
CRLs will be available throughout the system within three hours.  Delta CRLs
will be available within 15 minutes.  (Assume the initial CRL is small and
will propagate as if a delta CRL to resolve the bootstrap issues.)

The example below uses the "sliding window" method of issuing delta-CRLs,
but overlaps the thisUpdate and nextUpdate times to allow for propagation.
In this example, full CRLs are issued once every 3 hours and deltas are
issued every 45 minutes. For consistency, the issuer begins issuing deltas
at the same time as the very first full CRL. Notice that starting with
cRLNumber 7, the delta CRL issued at the same time as a full CRL does not
use the previously issued full CRL as its base but the preceding CRL instead.
As in example #2, these delta-CRLs never provide more than 6 hours of history.

Similary to examples #1 and #2:
Certificate 14 was revoked for key compromise before 12:00 when the first CRL
was issued.
Certificate 124 was revoked for key compromise between 12:00 and 12:45.
Certificate 39 was placed on hold between 14:15 and 15:00, and its suspension
was lifted between 16:00 and 17:00.
Certificate 67 was revoked for an affiliation change between 15:45 and 16:30.
The reason was changed to key compromise between 18:00 and 18:45.

current  | Revoked      | Full CRL                 | Delta-CRL
time     | certificates |                          |
---------|--------------|--------------------------|----------------------
12:00    | {14k}        | cRLNumber = 1            | cRLNumber = 1
          |              | thisUpdate = 12:00       | thisUpdate = 12:00
          |              | nextUpdate = 18:00       | nextUpdate = 13:00
          |              | CertificateList = {14k}  | BaseCRLNumber = 1
          |              |                          | CertificateList = {}
---------|--------------|--------------------------|----------------------
12:45    | {14k, 124k}  |                          | cRLNumber = 2
          |              |                          | thisUpdate = 12:45
          |              |                          | nextUpdate = 13:45
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList = {124k}
---------|--------------|--------------------------|----------------------
13:30    | {14k, 124k}  |                          | cRLNumber = 3
          |              |                          | thisUpdate = 13:30
          |              |                          | nextUpdate = 14:30
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList = {124k}
---------|--------------|--------------------------|----------------------
14:15    | {14k, 124k}  |                          | cRLNumber = 4
          |              |                          | thisUpdate = 14:15
          |              |                          | nextUpdate = 15:15
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList = {124k}
---------|--------------|--------------------------|----------------------
15:00    | {14k, 124k,  | cRLNumber = 5            | cRLNumber = 5
          |   39h}       | thisUpdate = 15:00       | thisUpdate = 15:00
          |              | nextUpdate = 21:00       | nextUpdate = 16:00
          |              | CertificateList =        | BaseCRLNumber = 1
          |              |  {14k, 124k, 39h}        | CertificateList =
          |              |                          | {124k, 39h}
---------|--------------|--------------------------|----------------------
15:45    | {14k, 124k,  |                          | cRLNumber = 6
          |   39h, 67a}  |                          | thisUpdate = 15:45
          |              |                          | nextUpdate = 16:45
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList =
          |              |                          | {124k, 39h, 67a}
---------|--------------|--------------------------|----------------------
16:30    | {14k, 124k,  |                          | cRLNumber = 7
          |   67a}       |                          | thisUpdate = 16:30
          |              |                          | nextUpdate = 17:30
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList =
          |              |                          | {124k, 39r, 67a}
---------|--------------|--------------------------|----------------------
17:15    | {14k, 124k,  |                          | cRLNumber = 8
          |  67a}        |                          | thisUpdate = 17:15
          |              |                          | nextUpdate = 18:15
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList =
          |              |                          | {124k, 39r, 67a}
---------|--------------|--------------------------|----------------------
18:00    | {14k, 124k,  | cRLNumber = 9            | cRLNumber = 9
          |   67a}       | thisUpdate = 18:00       | thisUpdate = 18:00
          |              | nextUpdate = 24:00       | nextUpdate = 19:00
          |              | CertificateList =        | BaseCRLNumber = 5
          |              | {14k, 124k, 67a}         | CertificateList =
          |              |                          | {39r, 67a}
---------|--------------|--------------------------|----------------------
18:45    | {14k, 124k,  |                          | cRLNumber = 10
          |   67k}       |                          | thisUpdate = 18:45
          |              |                          | nextUpdate = 19:45
          |              |                          | BaseCRLNumber = 5
          |              |                          | CertificateList =
          |              |                          | {39r, 67k}
---------|--------------|--------------------------|----------------------



Delta CRL number 6 is issued at 15:45.  By 16:00, delta CRL number 6 should
be available throughout the system.  As a result, delta CRL number 5 specified
16:00 as its nextUpdate time.

However, full CRL number 5 was issued at 15:00 and may not be available
throughout the system  until 18:00.  As a result, full CRL number 1 specified
18:00 as its nextUpdate time.  In addition, delta CRL number 6 must be based
on full CRL number 1 which was issued at 12:00.

If the relying party finds full CRL number 5 in the repository, they may still
apply delta CRL number 6 and achieve the correct answer.

Finally, note that a CRL issuer must generate more CRLs to achieve the goal of
status information that is no more than one hour old when factoring in the
propagation delays.

--=====================_32329696==_
Content-Type: application/msword; name="PKIX deltas.doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="PKIX deltas.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAnAAAAAAAAAAA
EAAAngAAAAEAAAD+////AAAAAJoAAACbAAAA////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////s
pcEATSAJBAAA8BK/AAAAAAAAEAAAAAAABAAAXmMAAA4AYmpiauI94j0AAAAAAAAAAAAAAAAAAAAA
AAAJBBYAIsoAAIBXAACAVwAA8F0AAG0BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA
AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAAgCAAAAAAAACAIAAAgC
AAAKAAAAEgIAAAwAAAAeAgAAAAAAAB4CAAAAAAAAHgIAABQAAAAAAAAAAAAAADICAAAAAAAAHiAA
AAAAAAAeIAAAAAAAAB4gAAAAAAAAHiAAAIwAAACqIAAADAEAADICAAAAAAAAy0IAAPYAAADCIQAA
AAAAAMIhAAAAAAAAwiEAAAAAAADCIQAAAAAAAMIhAAAAAAAAwiEAAAAAAADCIQAAAAAAAMIhAAAA
AAAAqkEAAAIAAACsQQAAAAAAAKxBAAAAAAAArEEAAAAAAACsQQAAAAAAAKxBAAAAAAAArEEAACQA
AADBQwAAIAIAAOFFAADIAAAA0EEAABUAAAAAAAAAAAAAAAAAAAAAAAAAHgIAAAAAAADCIQAAAAAA
AAAAAAAAAAAAAAAAAAAAAADCIQAAAAAAAMIhAAAAAAAAwiEAAAAAAADCIQAAAAAAANBBAAAAAAAA
Ci0AAAAAAAAeAgAAAAAAAB4CAAAAAAAAwiEAAAAAAAAAAAAAAAAAAMIhAAAAAAAA5UEAAIYAAAAK
LQAAAAAAAAotAAAAAAAACi0AAAAAAADCIQAATAkAAB4CAAAAAAAAwiEAAAAAAAAeAgAAAAAAAMIh
AAAAAAAAqkEAAAAAAAAAAAAAAAAAAAotAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAwiEAAAAAAACqQQAAAAAAAAotAACmBgAACi0AAAAAAACwMwAA
cgAAAF48AABUAAAAHgIAAAAAAAAeAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAzjwAAAAAAADCIQAAAAAAALYhAAAMAAAAoKEqD3/Z
wAEyAgAA7B0AAB4gAAAAAAAADisAAPwBAACyPAAADgAAAAAAAAAAAAAAzjwAANwEAABrQgAAYAAA
AMtCAAAAAAAAwDwAAA4AAACpRgAAAAAAAAotAAAAAAAAqUYAAAAAAADOPAAAAAAAAAotAAAAAAAA
MgIAAAAAAAAyAgAAAAAAAB4CAAAAAAAAHgIAAAAAAAAeAgAAAAAAAB4CAAAAAAAAAgDZAAAAIERl
bHRhIENSTHMNDVRoaXMgcGFwZXIgYWRkcmVzc2VzIHRoZSB1c2Ugb2YgZGVsdGEgQ1JMcyBpbiBQ
S0lYLWNvbXBsaWFudCBzeXN0ZW1zLiAgVGhpcyBwYXBlciBhc3N1bWVzIHRoYXQgZGVsdGEgQ1JM
cyBpbmNsdWRlIHRoZSBkZWx0YSBDUkwgaW5kaWNhdG9yIGV4dGVuc2lvbiAocmF0aGVyIHRoYW4g
YSBDUkwgc2NvcGUgZXh0ZW5zaW9uKSBhbmQgaWdub3JlcyBjb21wbGljYXRpb25zIGludm9sdmlu
ZyBjb21iaW5lZCBkZWx0YSBDUmxzIENSTHMgZnJvbSBpbmRpcmVjdCBDUkwgaXNzdWVycy4NDVRo
aXMgcGFwZXIgYWxzbyBhc3N1bWVzIHRoYXQgQ1JMcyB3aXRoIGRpZmZlcmVudCBzY29wZXMgYXJl
IGRpc3RyaWJ1dGVkIHVzaW5nIGRpZmZlcmVudCBkaXN0cmlidXRpb24gcG9pbnRzLg0NVGVybXMN
DVJldm9rZWQ6IEEgc3RhdGVtZW50IHRoYXQgYSBwYXJ0aWN1bGFyIGNlcnRpZmljYXRlknMgc3Rh
dHVzIGhhcyBjaGFuZ2VkIGFuZCBpdCBzaG91bGQgbm8gbG9uZ2VyIGJlIHRydXN0ZWQuICBPbmNl
IGEgY2VydGlmaWNhdGUgaXMgcmV2b2tlZCwgaXQgaXMgYWx3YXlzIHJldm9rZWQuDQ1TdXNwZW5z
aW9uOiBBIHN0YXRlbWVudCB0aGF0IGEgcGFydGljdWxhciBjZXJ0aWZpY2F0ZSBtYXkgbm90IGJl
IHRydXN0d29ydGh5LiAgT25jZSBwbGFjZWQgb24gaG9sZCwgYSBjZXJ0aWZpY2F0ZSBtYXkgYmUg
cmV2b2tlZCBvciB0aGUgc3VzcGVuc2lvbiBtYXkgYmUgbGlmdGVkLg0NUmV2b2NhdGlvbiBub3Rp
Y2U6IEEgc3RhdGVtZW50IHRoYXQgYSBwYXJ0aWN1bGFyIGNlcnRpZmljYXRlIGhhcyBiZWVuIHN1
c3BlbmRlZCBvciByZXZva2VkLiAgVGhlIHJldm9jYXRpb24gc3RhdGVtZW50IGlkZW50aWZpZXMg
dGhlIGNlcnRpZmljYXRlIGJ5IHRoZSBpc3N1ZXIgbmFtZSBhbmQgc2VyaWFsIG51bWJlci4gIFRo
ZSBpc3N1ZXIgbWF5IGJlIHNwZWNpZmllZCBleHBsaWNpdGx5IG9yIGltcGxpY2l0bHkuICBUaGUg
aXNzdWVyIG1heSBiZSBleHBsaWNpdGx5IGlkZW50aWZpZWQgdXNpbmcgdGhlIGNlcnRpZmljYXRl
IGlzc3VlciBleHRlbnNpb24uIElmIG5vdCBzcGVjaWZpZWQgZXhwbGljaXRseSwgdGhlIGlzc3Vl
ciBvZiB0aGUgY2VydGlmaWNhdGUgaXMgaW1wbGljaXRseSBpZGVudGlmaWVkIGFzIHRoZSBpc3N1
ZXIgb2YgdGhlIENSTC4gQSByZXZvY2F0aW9uIG5vdGljZSBpbmNsdWRlcyB0aGUgZGF0ZSBhbmQg
dGltZSB0aGUgY2VydGlmaWNhdGUgd2FzIHJldm9rZWQuICBBIHJldm9jYXRpb24gbm90aWNlIG1h
eSBvcHRpb25hbGx5IGluY2x1ZGUgYSByZXZvY2F0aW9uIHJlYXNvbiBpbiB0aGUgcmVhc29uIGNv
ZGUgQ1JMIGVudHJ5IGV4dGVuc2lvbi4CDQ1DZXJ0aWZpY2F0ZSByZXZvY2F0aW9uIGxpc3QgKENS
TCk6ICBhIGxpc3Qgb2YgcmV2b2NhdGlvbiBub3RpY2VzIGZvciBjZXJ0aWZpY2F0ZXMuDQ1DUkwg
c2NvcGU6IHRoZSBzZXQgb2YgY2VydGlmaWNhdGVzIHRoYXQgY291bGQgYXBwZWFyIG9uIGEgZ2l2
ZW4gQ1JMLiAgRm9yIGV4YW1wbGUsIHRUaGUgc2NvcGUgbWF5IGJlIJNhbGwgY2VydGlmaWNhdGVz
IGlzc3VlZCBieSBDQSBYlCwgk2FsbCBbQ0EgYW5kfCBlbmQgZW50aXR5XSBjZXJ0aWZpY2F0ZXMg
aXNzdWVkIGJ5IENBIFiULCCTYWxsIGNlcnRpZmljYXRlcyBpc3N1ZWQgYnkgQ0EgWCB0aGF0IGhh
dmUgYmVlbiByZXZva2VkIGZvciBba2V5IGNvbXByb21pc2UgfCBldGMuXWFuZCBDQSBjb21wcm9t
aXNllCwgb3IgbWF5IGJlIGEgc2V0IG9mIGNlcnRpZmljYXRlcyBiYXNlZCBvbiBsb2NhbCBpbmZv
cm1hdGlvbiwgc3VjaCBhcyCTYWxsIGNlcnRpZmljYXRlcyBpc3N1ZWQgdG8gdGhlIE5JU1QgZW1w
bG95ZWVzIGxvY2F0ZWQgaW4gQm91bGRlcpQuDQ1GdWxsIENSTDogYSBDUkwgdGhhdCBsaXN0cyBh
bGwgdW4tZXhwaXJlZHVuZXhwaXJlZCBjZXJ0aWZpY2F0ZXMsIGluIGl0cyBzY29wZSwgdGhhdCBo
YXZlIGJlZW4gcmV2b2tlZCBmb3Igb25lIG9mIHRoZSByZXZvY2F0aW9uIHJlYXNvbnMgY292ZXJl
ZCBieSB0aGUgc2NvcGUgb2YgdGhlIENSTC4gIFRoZSBzY29wZSBvZiBhIGZ1bGwgQ1JMIGRvZXMg
bm90IG5lY2Vzc2FyaWx5IGluY2x1ZGUgYWxsIG9mIHRoZSBjZXJ0aWZpY2F0ZXMgaXNzdWVkIGJ5
IGEgQ0Egb3IgYWxsIHBvc3NpYmxlIHJldm9jYXRpb24gcmVhc29ucy4gIHRoZSBzY29wZSBvZiBh
IGZ1bGwgQ1JMIGlzIHNldCBvZiB1bi1leHBpcmVkIGNlcnRpZmljYXRlcyB3aG9zZSBjdXJyZW50
IHN0YXR1cyBpcyBub3QgZnVsbHkgdHJ1c3RlZC4gIFRoZSBmdWxsIENSTCBtYXkgY292ZXIgYWxs
IGNlcnRpZmljYXRlcyBpc3N1ZWQgYnkgYSBDQSwgb3IgYSBzdWJzZXQgdGhvc2UgY2VydGlmaWNh
dGVzIChlLmcuLCBhIENSTCBzZWdtZW50KSBiYXNlZCBvbiBjZXJ0aWZpY2F0ZSBzdWJqZWN0IHR5
cGUsIHJldm9jYXRpb24gcmVhc29ucywgb3Igb3RoZXIgbG9jYWwgcmVhc29ucyAoZS5nLiwgk2Fs
bCBjZXJ0aWZpY2F0ZXMgaXNzdWVkIHRvIE5JU1SScyBCb3VsZGVyIGVtcGxveWVlc5QpLg0NQmFz
ZSBDUkw6ICB0aGUgcGFydGljdWxhciBDUkwgdXNlZCBhcyB0aGUgZm91bmRhdGlvbiBmb3IgYSBk
ZWx0YSBDUkwuICBUaGUgYmFzZSBtdXN0IGhhdmUgYmVlbiBpc3N1ZWQgYXMgYSBmdWxsIENSTC4N
DURlbHRhIENSTDogIGEgQ1JMIHRoYXQgb25seSBsaXN0cyB0aG9zZSB1bi1leHBpcmVkdW5leHBp
cmVkIGNlcnRpZmljYXRlcywgaW4gaXRzIHNjb3BlLCB3aG9zZSByZXZvY2F0aW9uIHN0YXR1cyBo
YXMgY2hhbmdlZCBzaW5jZSB0aGUgaXNzdWFuY2Ugb2YgYSBwYXJ0aWN1bGFyLCByZWZlcmVuY2Vk
IGJhc2UgQ1JMLiBUaGUgc2NvcGUgb2YgYSBkZWx0YSBDUkwgaXMgbXVzdCBiZSB0aGUgc2FtZSBh
cyB0aGUgYmFzZSBDUkwgdGhhdCBpdCByZWZlcmVuY2VzIFRoZSBzY29wZSBvZiBhIGRlbHRhIENS
TCBpcyB0aGUgc2FtZSBhcyB0aGUgYmFzZSBDUkwsIGJ1dCB0aGUgY29udGVudHMgYXJlIGxpbWl0
ZWQgdG8gdGhlIGxpc3Qgb2YgY2VydGlmaWNhdGVzIHdob3NlIHN0YXR1cyBoYXMgY2hhbmdlZCBz
aW5jZSB0aGUgaXNzdWFuY2Ugb2YgdGhlIGJhc2UgQ1JMLg0NQmFzZSBDUkw6ICBUaGUgcGFydGlj
dWxhciBDUkwgdXNlZCBhcyB0aGUgZm91bmRhdGlvbiBmb3IgYSBkZWx0YSBDUkwuICBUaGUgYmFz
ZSBtdXN0IGhhdmUgYmVlbiBpc3N1ZWQgYXMgYSBmdWxsIENSTC4NDUNvbnN0cnVjdGVkIENSTDog
dGhlIGNvbWJpbmF0aW9uIG9mIGEgZGVsdGEgQ1JMIGFuZCBhIGJhc2UgQ1JMDQ1DUkwgTnVtYmVy
aW5nDQ1BIENSTCBpc3N1ZXIgbWF5IGlzc3VlIGdlbmVyYXRlIGZ1bGwgQ1JMcyBmb3IgbW9yZSB0
aGFuIG9uZSBzY29wZS5hbnkgY29tYmluYXRpb24gb2YgZnVsbCBzZWdtZW50ZWQgQ1JMcyBhbmQg
dW5zZWdtZW50ZWQgQ1JMcyB7e3sgVGhlc2UgdHdvIHRlcm1zIGFyZSBub3QgZGVmaW5lZCBhYm92
ZS4gSSBob3BlIHRoYXQgeW91IGNhbiBzdGljayB0byB0aGUgZGVmaW5lZCB0ZXJtIJNzY29wZS6U
IH19fS4gIFRoZSBDUkwgaXNzdWVyIG1heSBhbHNvIGlzc3VlIGdlbmVyYXRlIGRlbHRhIENSTHMu
ICBFYWNoOyB0aGUgZGVsdGEgQ1JMcyB3aWxsIG11c3QgaGF2ZSB0aGUgc2FtZSBzY29wZXMgYXMg
ZWl0aGVyIGF0aGUgZnVsbCBzZWdtZW50ZWQgQ1JMIG9yIHVuYSBzZWdtZW50ZWRmdWxsIENSTHMg
aXNzdWVkIGJ5IHRoZSBDUkwgaXNzdWVydGhhdCB0aGV5IHIgcmVmZXJlbmNlZCBhcyB0aGVpcml0
cyBiYXNlcy4NDUZvciBlYWNoIHNjb3BlIHN1cHBvcnRlZCBieSB0aGUgQ1JMIGlzc3VlciwgYSBz
ZXBhcmF0ZSBudW1iZXJpbmcgc2VxdWVuY2UgbXVzdCBiZSBtYWludGFpbmVkLiAgRm9yIGVhY2gg
c2NvcGUsIHRoZSBDUkxzIGFyZSBudW1iZXJlZCBpbiBhIG1vbm90b25pY2FsbHkgaW5jcmVhc2lu
ZyBzZXF1ZW5jZS4gIChXcmFwcGluZyBpcyBub3QgcGVybWl0dGVkIGluIHRoZSBQS0lYIHByb2Zp
bGUuICBJZiB0aGUgYSBkZWx0YSBDUkwgYW5kIGEgY29tcGxldGUgZnVsbCBDUkwgdGhhdCBjb3Zl
ciB0aGUgc2FtZSBzY29wZSBhcmUgaXNzdWVkIGF0IHRoZSBzYW1lIHRpbWUsIGVhY2ggdGhleSB3
aWxsIGhhdmUgdGhlIHNhbWUgQ1JMIG51bWJlci4pICANDUlUaGF0IGlzLCBpZiBhIENSTCBpc3N1
ZXIgaXNzdWVzIGdlbmVyYXRlcyBDUkxzIGZvciBvbmUgc2NvcGUgKGUuZy4sIGZ1bGwgQ1JMcyBh
bmQgZGVsdGFzIGZvciBmdWxsIENDUkxzKSwgdGhlIGlzc3VlciBtdXN0IG1haW50YWluIG9uZSBu
dW1iZXJpbmcgc2VxdWVuY2UuICBJZiBhIGRlbHRhIENSTCBhbmQgYSBmdWxsIENSTCB0aGF0IGNv
dmVyIHRoZSBzYW1lIHNjb3BlIGFyZSBpc3N1ZWQgYXQgdGhlIHNhbWUgdGltZSwgdGhleSB3aWxs
IGhhdmUgdGhlIHNhbWUgQ1JMIG51bWJlci4NDUlmIGEgQ1JMIGlzc3VlciBpc3N1ZXMgZ2VuZXJh
dGVzIENSTHMgZm9yIHR3byBzY29wZXMgKGUuZy4sIGFsbCBvbmUgY292ZXJpbmcgQ0EgY2VydGlm
aWNhdGVzIGFuZCBhbGwgb25lIGNvdmVyaW5nIGVuZCBlbnRpdHkgY2VydGlmaWNhdGVzKSwgdGhl
biB0aGUgQ1JMIGlzc3VlciBtdXN0IG1haW50YWluIHR3byBudW1iZXIgc2VxdWVuY2VzLiAgVGhl
IENSTHMgYW5kIGRlbHRhcyBmb3IgdGhlIHNhbWUgc2NvcGUgKGUuZy4sIENBIGNlcnRpZmljYXRl
cykgd2lsbCBzaGFyZSBvbmUgbnVtYmVyaW5nIHNlcXVlbmNlLiAgVGhlIENSTHMgYW5kIGRlbHRh
cyBmb3IgdGhlIHNlY29uZCBzY29wZSAoZS5nLiwgZW5kIGVudGl0eSBjZXJ0aWZpY2F0ZXMpIHdp
bGwgc2hhcmUgb25lIG51bWJlcmluZyBzZXF1ZW5jZS4gICBUaGVyZSBpcyBubyByZXF1aXJlbWVu
dCB0aGF0IHRoZXNlIHNlcXVlbmNlcyBiZSBkaXNqb2ludC4NDUFsZ29yaXRobXMgZm9yIERldGVy
bWluaW5nIFN0YXR1cyBmcm9tIGEgQmFzZSBGdWxsIENSTCBhbmQgYSBEZWx0YSBDUkwNDUNvbnNp
ZGVyIGEgY29tcGxldGUgZnVsbCBDUkwsIEJGLCB3aXRoIENSTCBudW1iZXIgWC4gIEEgVGhlIFBL
SVggcHJvZmlsZSByZXF1aXJlcyB0aGUgQ0EgdG8gaXNzdWUgQiBhcyBhIGZ1bGwgQ1JMLCBidXQg
YSBjbGllbnQoQiBtYXkgYmUgb2J0YWluIEJGZWQgaW4gZWl0aGVyIG9mIHRoZSBmb2xsb3dpbmcg
d2F5czogKGEpIHRoZSBmdWxsIENSTCBCIEYgbWF5IGhhdmUgYmVlbiBwdXNoZWQgdG8gdGhlIGNs
aWVudCBvZnIgcHVsbGVkIGZyb20gYSByZXBvc2l0b3J5O2lzc3VlZCBhcyBhIGNvbXBsZXRlIGZ1
bGwgQ1JMIHdoaWNoIGNvbnRhaW5zIGEgQ1JMIG51bWJlciBleHRlbnNpb24gd2l0aCB2YWx1ZSBY
LiBvciAoYikgQWx0ZXJuYXRpdmVseSwgRkIgbWF5IGhhdmUgYmVlbiBjb25zdHJ1Y3RlZCBmcm9t
IGEgYmFzZSBmdWxsIENSTCBhbmQgYSBkZWx0YSBDUkwgdXNpbmcgdGhpcyBhbGdvcml0aG0uDS4N
Q29uc2lkZXIgYSBkZWx0YSBDUkwsIEQsIHdoaWNoIHNwZWNpZmllcyBiYXNlIENSTCBZIGFuZCBo
YXMgQ1JMIG51bWJlciBaLiAgVGhpcyBtZWFucyB0aGF0IGFsbCBjZXJ0aWZpY2F0ZXMgd2hvc2Ug
c3RhdHVzZXMgaGF2ZSBjaGFuZ2VkIHNpbmNlIHRoZSBpc3N1YW5jZSBvZiBDUkwgWSB3aWxsIGJl
IGxpc3RlZCBvbiB0aGUgZGVsdGEgQ1JMLiAgTm90ZSB0aGF0IHRoZSBQS0lYIHByb2ZpbGUgcmVx
dWlyZXMgdGhlIENBIHRvIGlzc3VlIENSTCBZIGFzIGEgZnVsbCBDUkwuDQ1EZXRlcm1pbmluZyBX
aGV0aGVyIGEgQmFzZSBGdWxsIENSTCBhbmQgRGVsdGEgQ1JMIE1heSBCZSBDb21iaW5lZA0NQ29u
c2lkZXIgYSBkZWx0YSBDUkwsIEQsIHdoaWNoIHNwZWNpZmllcyBiYXNlIENSTCBZIGFuZCBoYXMg
Q1JMIG51bWJlciBaLiAgVGhpcyBtZWFucyB0aGF0IGFsbCBjZXJ0aWZpY2F0ZXMgd2hvc2Ugc3Rh
dHVzZXMgaGF2ZXMgY2hhbmdlZCBzaW5jZSB0aGUgaXNzdWFuY2Ugb2YgQ1JMIFkgd2lsbCBiZSBs
aXN0ZWQgb24gdGhlIGRlbHRhIENSTC4NDUJGIGFuZCBEIG1heSBiZSBjb21iaW5lZCBpZiBlYWNo
IG9mIHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucyBhcmUgbWV0Og0NWCBpcyBncmVhdGVyIHRoYW4g
b3IgZXF1YWwgdG8gWS4gIFRoYXQgaXMsIHRoZSBjb21wbGV0ZSBmdWxsIENSTCBtdXN0IChhdCBh
IG1pbmltdW0pIGNvbnRhaW4gYWxsIHRoZSByZXZvY2F0aW9uIGluZm9ybWF0aW9uIGhlbGQgYnkg
dGhlIHJlZmVyZW5jZWQgYmFzZSBDUkwuDVggaXMgbGVzcyB0aGFuIFouICBUaGF0IGlzLCB0aGUg
ZGVsdGEgQ1JMIG11c3QgY292ZXIgc29tZSB0aW1lIHRoYXQgd2FzIG5vdCBjb3ZlcmVkIGJ5IHRo
ZSBjb21wbGV0ZSBmdWxsIENSTC4gDQ1EZXRlcm1pbmluZyBTdGF0dXMgb2YgYSBjZXJ0aWZpY2F0
ZSBDZXJ0aWZpY2F0ZSBmcm9tIGEgYmFzZSBGdWxsIENSTCBhbmQgYSBEZGVsdGEgQ1JMDQ1JZiB0
aGUgUEtJIGNsaWVudCBtYWludGFpbnMgdGhlIGRlbHRhIGFuZCBiYXNlIGZ1bGwgQ1JMLCB0aGUg
c3RhdHVzIG9mIGFuIHVuZXhwaXJlZCBjZXJ0aWZpY2F0ZSBDIGlzIG1heSBiZSBkZXRlcm1pbmVk
IGFzIGZvbGxvd3M6DQ1JZiBDIGlzIGxpc3RlZCBvbiB0aGUgZGVsdGEgQ1JMLCB0aGVuOg1JZiBD
IGlzIGxpc3RlZCBvbiB0aGUgZGVsdGEgQ1JMIHdpdGggcmVhc29uIGNvZGUgInJlbW92ZUZvcnJv
bUNSTCIsIHRoZW4gQyBpcyBub3QgcmV2b2tlZC5JZiBDIHdhcyBsaXN0ZWQgd2l0aG91dCBhbiBh
c3NvY2lhdGVkIHJldm9jYXRpb24gcmVhc29uIG9yIGEgcmV2b2NhdGlvbiByZWFzb24gb3RoZXIg
dGhhbiBjZXJ0aWZpY2F0ZSBob2xkLCB0aGVuIGNlcnRpZmljYXRlIEMgaXMgY29uc2lkZXJlZCBy
ZXZva2VkLg1PdGhlcndpc2UsIGNlcnRpZmljYXRlIEMgaXMgcmV2b2tlZC5JZiBDIGlzIGxpc3Rl
ZCBvbiB0aGUgZGVsdGEgQ1JMIHdpdGggcmVhc29uIGNvZGUgInJlbW92ZSBmb3JtIGNybENSTCIs
IHRoZW4gQyBpcyBub3QgcmV2b2tlZC4NSWYgQyB3YXMgbm90IGxpc3RlZCBvbiB0aGUgZGVsdGEg
Q1JMLCB0aGVuIHRoZSBiYXNlIGZ1bGwgQ1JMIGlzIGNoZWNrZWQsIGFuZCB0aGUgc3RhdHVzIGlz
IGFzIGZvbGxvd3M6DUlmIEMgaXMgbGlzdGVkIG9uIHRoZSBiYXNlIGZ1bGwgQ1JMLCB0aGVuIEMg
aXMgcmV2b2tlZC4NSWYgQyBpcyBub3QgbGlzdGVkIG9uIHRoZSBiYXNlIGZ1bGwgQ1JMLCB0aGVu
IEMgaXMgbm90IHJldm9rZWQuDQ1Db21iaW5pbmcgYSBCYXNlIEZ1bGwgQ1JMIGFuZCBEZWx0YSBD
UkwgaW50byBhIENvbnN0cnVjdGVkIENSTA0NSWYgdGhlIFBLSSBjbGllbnQgbWFpbnRhaW5zIHRo
ZSBjdXJyZW50IENSTCBpbiBlbGVjdHJvbmljIGZvcm1hIGxvY2FsIGNhY2hlOg0NVGhlIHJldm9j
YXRpb24gaW5mb3JtYXRpb24gb24gQkYgaXMgYXNzdW1lZCBhcyB0aGUgaW5pdGlhbCBjb25kaXRp
b24uICBCRiBpcyBhIGxpc3Qgb2YgcmV2b2tlZCBjZXJ0aWZpY2F0ZXM7IGVhY2ggY2VydGlmaWNh
dGUgaXMgbGlzdGVkIHdpdGggYSByZXZvY2F0aW9uIHJlYXNvbiAod2hpY2ggbWF5IGJlIJN1bnNw
ZWNpZmllZJQpLiAgDQ1UaGUgbGlzdCBvZiByZXZva2VkIGNlcnRpZmljYXRlcyBMIHdpdGggbiBl
bnRyaWVzIGRlbm90ZWQgYXMgTGkgd2hlcmUgMSA8PSBpIDw9IG4uICAoVGhlIHZhbHVlIG4gbWF5
IHNocmluayBvciBncm93IGFzIHRoZSBjb21iaW5hdGlvbiBwcm9jZXNzIHByb2NlZWRzLikNDUlu
aXRpYWxpemUgTCB0byB0aGUgcmV2b2NhdGlvbiBub3RpY2VzIG9uIEJGLiAgRm9yIGVhY2ggY2Vy
dGlmaWNhdGUgQyBvbiB0aGUgZGVsdGEgQ1JMLCB1cGRhdGUgdGhlIGNvbnRlbnRzIG9mIEwgYXMg
Zm9sbG93cy4NDUEgY2VydGlmaWNhdGUgQyBpcyBhZGRlZCB0byB0aGUgbGlzdCBvZiByZXZva2Vk
IGNlcnRpZmljYXRlcyBMIGFzIGZvbGxvd3M6DUlmICBhIGNlcnRpZmljYXRlIEMgYXBwZWFycyBv
biB0aGUgZGVsdGEgQ1JMIEQsIGFuZCBDIGlzIG5vdCBjdXJyZW50bHkgaW4gdGhlIGxpc3QgTCwg
dGhlbjoNaWYgQyBoYXMgYSByZXZvY2F0aW9uIHJlYXNvbiBvdGhlciB0aGFuIJNyZW1vdmVGcm9t
Q1JMlCwgYWRkIEMgYXMgYSBuZXcgZW50cnkgaW4gIHRoZSBsaXN0IG9mIHJldm9rZWQgY2VydGlm
aWNhdGVzIEwuDUlmIEMgaGFzIHJldm9jYXRpb24gcmVhc29uIJNyZW1vdmVGcm9tQ1JMlCwgc2tp
cCB0aGlzIGNlcnRpZmljYXRlLiAgTm8gdXBkYXRlIHRvIHRoZSBjYWNoZSBpcyBuZWVkZWQuDUlm
IGEgY2VydGlmaWNhdGUgQyBhcHBlYXJzIG9uIHRoZSBkZWx0YSBDUkwgRCwgYW5kIEMgaXMgcHJl
c2VudGx5IGxpc3RlZCBpbiBMIGFzIGVudHJ5IExpLCB0aGVuOg1JZiBDIGhhcyByZXZvY2F0aW9u
IHJlYXNvbmlzIGxpc3RlZCBvbiB0aGUgZGVsdGEgQ1JMIHdpdGggYSByZXZvY2F0aW9uIHJlYXNv
biBvZiCTcmVtb3ZlRnJvbUNSTJQsIHRoZW4gZGVsZXRlIGVudHJ5IExpIA1JZiAgQyBoYXMgaXMg
bGlzdGVkIG9uIHRoZSBkZWx0YSBDUkwgd2l0aG91dCBhIHJldm9jYXRpb24gcmVhc29uIG9yIHdp
dGggYSByZXZvY2F0aW9uIHJlYXNvbiBvdGhlciB0aGFuIJNyZW1vdmVGcm9tQ1JMLJQsIHRoZW4g
dXBkYXRlIGNoYW5nZSB0aGUgcmVhc29uIGNvZGUgYXNzb2NpYXRlZCB3aXRoIExpIHRvIHRoZSBy
ZWFzb24gY29kZSBzcGVjaWZpZWQgaW4gdGhlIGRlbHRhIENSTC4NDVRoZSBjb21iaW5hdGlvbiBv
ZiBCRiBhbmQgRCBmb3JtcyBhIG5ldyBjb21wbGV0ZSBmdWxsIENSTCB3aXRoIENSTCBudW1iZXIg
Wi4gIFRoaXMgY29tcGxldGUgZnVsbCBDUkwgaXMgYXNzdW1lZCB0byBoYXZlcyBjb21wbGV0ZSBp
bmZvcm1hdGlvbiB1bnRpbCB0aGUgdGltZSBzcGVjaWZpZWQgaW4gdGhlIG5leHQgdXBkYXRlIGZp
ZWxkIGluIHRoZSBkZWx0YSBDUkwgaXMgcmVhY2hlZC4gIElmIGEgcmVseWluZyBwYXJ0eSBpcyB2
YWxpZGF0aW5nIGEgY2VydGlmaWNhdGUgd2l0aCByZXNwZWN0IHRvIHRpbWUgVCwgIGFuZCBUIGlz
IGJlZm9yZSB0aGUgbmV4dCB1cGRhdGUgZmllbGQgaW4gdGhlIGRlbHRhIENSTCwgdGhleSBtYXkg
YXNzdW1lIGNvbXBsZXRlIGluZm9ybWF0aW9uLg0NSWYgYW4gdW5leHBpcmVkIGNlcnRpZmljYXRl
IEMgd2l0aGluIHRoZSBzY29wZSBvZiAgdGhlIGNvbnN0cnVjdGVkIENSTCBpcyBub3QgbGlzdGVk
LCB0aGVuIGNlcnRpZmljYXRlIEMgaXMgbm90IHJldm9rZWQgZm9yIG9uZSBvZiB0aGUgcmV2b2Nh
dGlvbiByZWFzb25zIGNvdmVyZWQgYnkgdGhpcyBDUkwuICBJZiB0aGUgY29uc3RydWN0ZWQgQ1JM
IGNvdmVycyBhbGwgcmVhc29ucywgdGhlbiB0aGUgY2VydGlmaWNhdGUgQyBpcyBub3QgcmV2b2tl
ZC4NDVVzaW5nIERlbHRhcyB0byBEaXN0cmlidXRlIFJldm9jYXRpb24gSW5mb3JtYXRpb24NDVRo
aXMgc2VjdGlvbiBwcm92aWRlcyB0aHJlZSBkaWZmZXJlbnQgc2NlbmFyaW9zIGZvciB0aGUgdXNl
IG9mIGRlbHRhIENSTHMuICBGb3IgdGhlIHB1cnBvc2Ugb2YgdGhlc2UgZXhhbXBsZXMsIGFzc3Vt
ZSBhIGdvYWwgb2YgaGUgZ29hbCBpcyB0byBwcm92aWRpbmdlIHJldm9jYXRpb24gaW5mb3JtYXRp
b24gdG8gcmVseWluZyBwYXJ0aWVzIHRoYXQgaXMgbm8gbW9yZSB0aGFuIG9uZSBob3VyIG9sZC4g
e3t7IFdoZXJlIGRvZXMgdGhpcyBjb21lIGZyb20/ICBFeGFtcGxlPyAgSXQgaXMgY2VydGFpbmx5
IG5vdCBhIFBLSVggcmVxdWlyZW1lbnQhIH19fQ0NDVRoZSBmb2xsb3dpbmcgbm90YXRpb24gaXMg
dXNlZCB0byBkZW5vdGUgYSByZXZva2VkIGNlcnRpZmljYXRlIG9uIGEgQ1JMOiAgDQkJWHIJY2Vy
dGlmaWNhdGUgWCBpcyBsaXN0ZWQgZm9yIHJlYXNvbiByLCB3aGVyZSByIGluIHthLGssaCxyfSAN
VGhlIHJlYXNvbiBjb2RlcyB7YSxrLGgscn0gY29ycmVzcG9uZCB0byCTYWZmaWxpYXRpb24gY2hh
bmdlZJQsIJNrZXkgY29tcHJvbWlzZZQsIJNjZXJ0aWZpY2F0ZSBob2xklCwgYW5kIJNyZW1vdmUg
ZnJvbSBDUkyUIHJlc3BlY3RpdmVseS4NDShOb3RlOiAgVGhlIHJlbWFpbmluZyByZWFzb24gY29k
ZXMgYXJlIG9taXR0ZWQgZm9yIHNpbXBsaWNpdHkuICBUaGUgaGFuZGxpbmcgb2YgY2VydGlmaWNh
dGVzIHJldm9rZWQgZm9yICB0aGUgcmVhc29ucyCTdW5zcGVjaWZpZWSULCCTQ0EgY29tcHJvbWlz
ZZQsIJNzdXBlcnNlZGVklCwgYW5kIJNjZXNzYXRpb25PZk9wZXJhdGlvbpQgYXJlIGlkZW50aWNh
bCB0byCTYWZmaWxpYXRpb24gY2hhbmdlZCBvciCTa2V5IGNvbXByb21pc2WUKS4NDQ0Ne3t7DVdo
ZXJlIGFyZSB0aGUgcmVzdD8gIEFnYWluLCBtYXliZSB0aGlzIGlzIGJlY2F1c2Ugd2UgbWFkZSBh
IGNsdW1zeSB0cmFuc2l0aW9uIGludG8gYW4gZXhhbXBsZS4NDSAgIENSTFJlYXNvbiA6Oj0gRU5V
TUVSQVRFRCB7DSAgICAgICAgdW5zcGVjaWZpZWQgICAgICAgICAgICAgKDApLA0gICAgICAgIGtl
eUNvbXByb21pc2UgICAgICAgICAgICgxKSwNICAgICAgICBjQUNvbXByb21pc2UgICAgICAgICAg
ICAoMiksDSAgICAgICAgYWZmaWxpYXRpb25DaGFuZ2VkICAgICAgKDMpLA0gICAgICAgIHN1cGVy
c2VkZWQgICAgICAgICAgICAgICg0KSwNICAgICAgICBjZXNzYXRpb25PZk9wZXJhdGlvbiAgICAo
NSksDSAgICAgICAgY2VydGlmaWNhdGVIb2xkICAgICAgICAgKDYpLA0gICAgICAgIHJlbW92ZUZy
b21DUkwgICAgICAgICAgICg4KSB9DX19fQ0NRXhhbXBsZSAjMQ0NVGhlIGV4YW1wbGUgYmVsb3cg
c2hvd3MgdGhlICJ0cmFkaXRpb25hbCIgbWV0aG9kIG9mIGlzc3VpbmcgZGVsdGEgLUNSTHMuIElu
IHRoaXMgZXhhbXBsZSwgZnVsbCBDUkxzIGFyZSBpc3N1ZWQgb25jZSBldmVyeSAzIGhvdXJzIGFu
ZCBkZWx0YXMgYXJlIGlzc3VlZCBvbmNlIGFuIGhvdXIuIEZvciBjb25zaXN0ZW5jeSwgdGhlIGlz
c3VlciBiZWdpbnMgaXNzdWluZyBkZWx0YXMgYXQgdGhlIHNhbWUgdGltZSBhcyB0aGUgdmVyeSBm
aXJzdCBmdWxsIENSTC4gQWZ0ZXIgdGhhdCwgaG93ZXZlciwgYSBkZWx0YSBjYW4gYWx3YXlzIHVz
ZSBhIHByZXZpb3VzbHkgaXNzdWVkIGZ1bGwgQ1JMIGFzIGl0cyBiYXNlLiBOb3RpY2UgdGhhdCBz
dGFydGluZyB3aXRoIGNSTE51bWJlciA0LCB0aGUgZGVsdGEgQ1JMIGlzc3VlZCBhdCB0aGUgc2Ft
ZSB0aW1lIGFzIGEgZnVsbCBDUkwgdXNlcyB0aGUgcHJldmlvdXNseSBpc3N1ZWQgZnVsbCBDUkwg
YXMgaXRzIGJhc2UuIEhvd2V2ZXIsIHRoZSBkZWx0YS1DUkxzIG5ldmVyIHByb3ZpZGUgbW9yZSB0
aGFuIDMgaG91cnMgb2YgaGlzdG9yeS4NDUluIHRoaXMgZXhhbXBsZToNQ2VydGlmaWNhdGUgMTQg
d2FzIHJldm9rZWQgZm9yIGtleSBjb21wcm9taXNlIGJlZm9yZSAxMjowMCB3aGVuIHRoZSBmaXJz
dCBDUkwgd2FzIGlzc3VlZC4NQ2VydGlmaWNhdGUgMTI0IHdhcyByZXZva2VkIGZvciBrZXkgY29t
cHJvbWlzZSBiZXR3ZWVuIDEyOjAwIGFuZCAxMzowMC4NQ2VydGlmaWNhdGUgMzkgd2FzIHBsYWNl
ZCBvbiBob2xkIGJldHdlZW4gMTQ6MDAgYW5kIDE1OjAwLCBhbmQgaXRzIHN1c3BlbnNpb24gd2Fz
IGxpZnRlZCBiZXR3ZWVuIDE2OjAwIGFuZCAxNzowMC4NQ2VydGlmaWNhdGUgNjcgd2FzIHJldm9r
ZWQgZm9yIGFuIGFmZmlsaWF0aW9uIGNoYW5nZSBiZXR3ZWVuIDE2MTU6MDAgYW5kIDE3MTY6MDAu
ICBUaGUgcmVhc29uIHdhcyBjaGFuZ2VkIHRvIGtleSBjb21wcm9taXNlIGJldHdlZW4gMTg2OjAw
IGFuZCAxOTc6MDAue3t7IFRoZXNlIHR3byB0aW1lIHNwYW5zIGNhbm5vdCBiZSB0aGUgc2FtZSEg
fX19Lg0NY3VycmVudCB0aW1lICAgICAHUmV2b2tlZCBjZXJ0aWZpY2F0ZXMHRnVsbCBDUkwHRGVs
dGEtQ1JMBwcxMjowMAd7MTRrfSAgICAgICAgICAgIAdjUkxOdW1iZXIgPSAxICAgICAgICAgICAg
ICAgICAgIHRoaXNVcGRhdGUgPSAxMjowMCAgICAgICAgICAgICAgbmV4dFVwZGF0ZSA9IDE1OjAw
ICAgICAgICAgICAgICBDZXJ0aWZpY2F0ZUxpc3QgPSB7MTRrfQdjUkxOdW1iZXIgPSAxICAgICAg
ICAgICAgICAgICAgIHRoaXNVcGRhdGUgPSAxMjowMA1uZXh0VXBkYXRlID0gMTM6MDAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBC
YXNlQ1JMTnVtYmVyID0gMQ1DZXJ0aWZpY2F0ZUxpc3QgPSB7fSAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAcHMTM6MDAHezE0aywgMTI0a30gICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAHB2NSTE51bWJlciA9IDIgICAgICAgICAg
ICAgICAgICAgdGhpc1VwZGF0ZSA9IDEzOjAwDW5leHRVcGRhdGUgPSAxNDowMCAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJhc2VD
UkxOdW1iZXIgPSAxDUNlcnRpZmljYXRlTGlzdCA9IHsxMjRrfSAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAcHMTQ6MDAHezE0aywgMTI0a30gICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAHB2NSTE51bWJlciA9IDMgICAgICAgICAg
ICAgICAgICAgdGhpc1VwZGF0ZSA9IDE0OjAwDW5leHRVcGRhdGUgPSAxNTowMCAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJhc2VD
UkxOdW1iZXIgPSAxDUNlcnRpZmljYXRlTGlzdCA9IHsxMjRrfSAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAcHMTU6MDAHezE0aywgMTI0aywgMzlofSAg
IAdjUkxOdW1iZXIgPSA0ICAgICAgICAgICAgICAgICAgIHRoaXNVcGRhdGUgPSAxNTowMCAgICAg
ICAgICAgICAgbmV4dFVwZGF0ZSA9IDE4OjAwICAgICAgICAgICAgICBDZXJ0aWZpY2F0ZUxpc3Qg
PSB7MTRrLCAxMjRrLCAzOWh9B2NSTE51bWJlciA9IDQNdGhpc1VwZGF0ZSA9IDE1NjowMCAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbmV4dFVwZGF0ZSA9IDE2Nzow
MCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCYXNlQ1JMTnVtYmVy
ID0gMSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDZXJ0aWZpY2F0
ZUxpc3QgPSB7MTI0aywgMzlofQcHMTY6MDAHezE0aywgMTI0aywgMzloLCA2N2F9ICAgBwdjUkxO
dW1iZXIgPSA1DXRoaXNVcGRhdGUgPSAxNjowMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgbmV4dFVwZGF0ZSA9IDE3OjAwICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIEJhc2VDUkxOdW1iZXIgPSA0ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIENlcnRpZmljYXRlTGlzdCA9IHszOWgsIDY3YX1XaHkgaXMg
MzloIGhlcmU/ICBJdCBpcyBvbiB0aGUgYmFzZSEHBzE3OjAwB3sxNGssIDEyNGssIDY3YX0gICAH
B2NSTE51bWJlciA9IDYNdGhpc1VwZGF0ZSA9IDE3OjAwICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBuZXh0VXBkYXRlID0gMTg6MDAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgQmFzZUNSTE51bWJlciA9IDQgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2VydGlmaWNhdGVMaXN0ID0gezM5ciwgNjdhfQcH
MTg6MDAHezE0aywgMTI0aywgNjdhfSAgIAdjUkxOdW1iZXIgPSA3ICAgICAgICAgICAgICAgICAg
IHRoaXNVcGRhdGUgPSAxODowMCAgICAgICAgICAgICAgbmV4dFVwZGF0ZSA9IDIxOjAwICAgICAg
ICAgICAgICBDZXJ0aWZpY2F0ZUxpc3QgPSB7MTRrLCAxMjRrLCA2N2F9B2NSTE51bWJlciA9IDcN
dGhpc1VwZGF0ZSA9IDE4OjAwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBuZXh0VXBkYXRlID0gMTk6MDAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgQmFzZUNSTE51bWJlciA9IDQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgQ2VydGlmaWNhdGVMaXN0ID0gezM5ciwgNjdhfQcHMTk6MDAHezE0aywgMTI0
aywgNjdrfSAgIAcHY1JMTnVtYmVyID0gOA10aGlzVXBkYXRlID0gMTk6MDAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5leHRVcGRhdGUgPSAyMDowMCAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCYXNlQ1JMTnVtYmVyID0gNyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDZXJ0aWZpY2F0ZUxpc3QgPSB7
NjdrfQcHDQ1Db25zZXF1ZW5jZXMgb2YgdGhpcyANDQ1TY2VuYXJpbyAjMg0NVGhlIGV4YW1wbGUg
YmVsb3cgc2hvd3MgdGhlICJzbGlkaW5nIHdpbmRvdyIgbWV0aG9kIG9mIGlzc3VpbmcgZGVsdGEt
Q1JMcy4gSW4gdGhpcyBleGFtcGxlLCBmdWxsIENSTHMgYXJlIGlzc3VlZCBvbmNlIGV2ZXJ5IDMg
aG91cnMgYW5kIGRlbHRhcyBhcmUgaXNzdWVkIG9uY2UgYW4gaG91ci4gRm9yIGNvbnNpc3RlbmN5
LCB0aGUgaXNzdWVyIGJlZ2lucyBpc3N1aW5nIGRlbHRhcyBhdCB0aGUgc2FtZSB0aW1lIGFzIHRo
ZSB2ZXJ5IGZpcnN0IGZ1bGwgQ1JMLiBOb3RpY2UgdGhhdCBzdGFydGluZyB3aXRoIGNSTE51bWJl
ciA3LCB0aGUgZGVsdGEgQ1JMIGlzc3VlZCBhdCB0aGUgc2FtZSB0aW1lIGFzIGEgZnVsbCBDUkwg
ZG9lcyBub3QgdXNlIHRoZSBwcmV2aW91c2x5IGlzc3VlZCBmdWxsIENSTCBhcyBpdHMgYmFzZSBi
dXQgdGhlIHByZWNlZGluZyBDUkwgaW5zdGVhZC4gIEhvd2V2ZXIsIHRoZXNlIGRlbHRhLUNSTHMg
bmV2ZXIgcHJvdmlkZSBtb3JlIHRoYW4gNiBob3VycyBvZiBoaXN0b3J5Lg0NQXMgaW4gZXhhbXBs
ZSAjMToNQ2VydGlmaWNhdGUgMTQgd2FzIHJldm9rZWQgZm9yIGtleSBjb21wcm9taXNlIGJlZm9y
ZSAxMjowMCB3aGVuIHRoZSBmaXJzdCBDUkwgd2FzIGlzc3VlZC4NQ2VydGlmaWNhdGUgMTI0IHdh
cyByZXZva2VkIGZvciBrZXkgY29tcHJvbWlzZSBiZXR3ZWVuIDEyOjAwIGFuZCAxMzowMC4NQ2Vy
dGlmaWNhdGUgMzkgd2FzIHBsYWNlZCBvbiBob2xkIGJldHdlZW4gMTQ6MDAgYW5kIDE1OjAwLCBh
bmQgaXRzIHN1c3BlbnNpb24gd2FzIGxpZnRlZCBiZXR3ZWVuIDE2OjAwIGFuZCAxNzowMC4NQ2Vy
dGlmaWNhdGUgNjcgd2FzIHJldm9rZWQgZm9yIGFuIGFmZmlsaWF0aW9uIGNoYW5nZSBiZXR3ZWVu
IDE2MTU6MDAgYW5kIDE3MTY6MDAuICBUaGUgcmVhc29uIHdhcyBjaGFuZ2VkIHRvIGtleSBjb21w
cm9taXNlIGJldHdlZW4gMTg2OjAwIGFuZCAxOTc6MDAuIHt7eyBBZ2FpbiwgdGhlc2UgY2Fubm90
IGhhdmUgdGhlIHNhbWUgdGltZSBzcGFuISB9fX0NDQ1jdXJyZW50IHRpbWUgICAgIAdSZXZva2Vk
IGNlcnRpZmljYXRlcwdGdWxsIENSTAdEZWx0YS1DUkwHBzEyOjAwB3sxNGt9ICAgICAgICAgICAg
B2NSTE51bWJlciA9IDEgICAgICAgICAgICAgICAgICAgdGhpc1VwZGF0ZSA9IDEyOjAwICAgICAg
ICAgICAgICBuZXh0VXBkYXRlID0gMTU6MDAgICAgICAgICAgICAgIENlcnRpZmljYXRlTGlzdCA9
IHsxNGt9B2NSTE51bWJlciA9IDEgICAgICAgICAgICAgICAgICAgdGhpc1VwZGF0ZSA9IDEyOjAw
DW5leHRVcGRhdGUgPSAxMzowMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIEJhc2VDUkxOdW1iZXIgPSAxDUNlcnRpZmljYXRlTGlz
dCA9IHt9ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
BwcxMzowMAd7MTRrLCAxMjRrfSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IAcHY1JMTnVtYmVyID0gMiAgICAgICAgICAgICAgICAgICB0aGlzVXBkYXRlID0gMTM6MDANbmV4
dFVwZGF0ZSA9IDE0OjAwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgQmFzZUNSTE51bWJlciA9IDENQ2VydGlmaWNhdGVMaXN0ID0g
ezEyNGt9ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
BwcxNDowMAd7MTRrLCAxMjRrfSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IAcHY1JMTnVtYmVyID0gMyAgICAgICAgICAgICAgICAgICB0aGlzVXBkYXRlID0gMTQ6MDANbmV4
dFVwZGF0ZSA9IDE1OjAwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgQmFzZUNSTE51bWJlciA9IDENQ2VydGlmaWNhdGVMaXN0ID0g
ezEyNGt9ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
BwcxNTowMAd7MTRrLCAxMjRrLCAzOWh9ICAgB2NSTE51bWJlciA9IDQgICAgICAgICAgICAgICAg
ICAgdGhpc1VwZGF0ZSA9IDE1OjAwICAgICAgICAgICAgICBuZXh0VXBkYXRlID0gMTg6MDAgICAg
ICAgICAgICAgIENlcnRpZmljYXRlTGlzdCA9IHsxNGssIDEyNGssIDM5aH0HY1JMTnVtYmVyID0g
NA10aGlzVXBkYXRlID0gMTU2OjAwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBuZXh0VXBkYXRlID0gMTY3OjAwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIEJhc2VDUkxOdW1iZXIgPSAxICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIENlcnRpZmljYXRlTGlzdCA9IHsxMjRrLCAzOWh9BwcxNjowMAd7MTRr
LCAxMjRrLCAzOWgsIDY3YX0gICAHB2NSTE51bWJlciA9IDUNdGhpc1VwZGF0ZSA9IDE2OjAwICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBuZXh0VXBkYXRlID0gMTc6
MDAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQmFzZUNSTE51bWJl
ciA9IDEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2VydGlmaWNh
dGVMaXN0ID0gezEyNGssIDM5aCwgNjdhfQcHMTc6MDAHezE0aywgMTI0aywgNjdhfSAgIAcHY1JM
TnVtYmVyID0gNg10aGlzVXBkYXRlID0gMTc6MDAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIG5leHRVcGRhdGUgPSAxODowMCAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBCYXNlQ1JMTnVtYmVyID0gMSAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBDZXJ0aWZpY2F0ZUxpc3QgPSB7MTI0aywgMzlyLCA2N2F9
BwcxODowMAd7MTRrLCAxMjRrLCA2N2F9ICAgB2NSTE51bWJlciA9IDcgICAgICAgICAgICAgICAg
ICAgdGhpc1VwZGF0ZSA9IDE4OjAwICAgICAgICAgICAgICBuZXh0VXBkYXRlID0gMjE6MDAgICAg
ICAgICAgICAgIENlcnRpZmljYXRlTGlzdCA9IHsxNGssIDEyNGssIDY3YX0HY1JMTnVtYmVyID0g
Nw10aGlzVXBkYXRlID0gMTg6MDAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIG5leHRVcGRhdGUgPSAxOTowMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBCYXNlQ1JMTnVtYmVyID0gMSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBDZXJ0aWZpY2F0ZUxpc3QgPSB7MTI0aywgMzlyLCA2N2F9BwcxOTowMAd7
MTRrLCAxMjRrLCA2N2t9ICAgBwdjUkxOdW1iZXIgPSA4DXRoaXNVcGRhdGUgPSAxOTowMCAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbmV4dFVwZGF0ZSA9IDIwOjAw
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJhc2VDUkxOdW1iZXIg
PSA0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENlcnRpZmljYXRl
TGlzdCA9IHszOXIsIDY3a30HBw1Ob3RlIHRoYXQgdGhlIGRlbHRhIENSTHMgYXJlIG1hcmdpbmFs
bHkgbGFyZ2VyIHRoYW4gaW4gdGhlIGZpcnN0IHNjZW5hcmlvIHNpbmNlIHRoZXkgY292ZXIgYSBs
b25nZXIgdGltZSBwZXJpb2QuICBPbiB0aGUgb3RoZXIgaGFuZCwgYSByZWx5aW5nIHBhcnR5IGlz
IGxlc3MgbGlrZWx5IHRvIGRvd25sb2FkIGZ1bGwgQ1JMcyBpbiB0aGUgc2Vjb25kIHNjZW5hcmlv
Lg0NRm9yIGV4YW1wbGUsIGEgcmVseWluZyBwYXJ0eSB0aGF0IHZhbGlkYXRlZCBvbmUgY2VydGlm
aWNhdGUgYXQgMTI6MTUsIHRoZW4gYSBzZWNvbmQgY2VydGlmaWNhdGUgYXQgMTY6MTUgd291bGQg
bm90IHJlcXVpcmUgYSBuZXcgZnVsbCBDUkwgaW4gc2NlbmFyaW8gIzIuICBJbiBzY2VuYXJpbyAj
MSwgdGhlIHJlbHlpbmcgcGFydHkgd291bGQgYmUgZm9yY2VkIHRvIG9idGFpbiBib3RoIGZ1bGwg
Q1JMIDQgYW5kIGRlbHRhIENSTCA1Lg0NU2NlbmFyaW8gIzMgQWxsb3dpbmcgZm9yIFJlcGxpY2F0
aW9uL1Byb3BhZ2F0aW9uIERlbGF5cw0NSW4gdGhpcyBzY2VuYXJpbywgZnVsbCBDUkxzIGFuZCBk
ZWx0YSBDUkxzIGFyZSByZXBsaWNhdGVkIHRocm91Z2hvdXQgYSByZXBvc2l0b3J5IHN5c3RlbS4g
IERhdGEgaXMgcmVwbGljYXRlZCB0aHJvdWdoIHRoZSBzeXN0ZW0gYXQgZGlmZmVyZW50IHJhdGVz
IGJhc2VkIG9uIHRoZSBzaXplIG9mIHRoZSBmaWxlLiAgVGhlIENBIG9wZXJhdG9ycyBlc3RpbWF0
ZSB0aGF0IGZ1bGwgQ1JMcyB3aWxsIGJlIGF2YWlsYWJsZSB0aHJvdWdob3V0IHRoZSBzeXN0ZW0g
d2l0aGluIHRocmVlIGhvdXJzLiAgRGVsdGEgQ1JMcyB3aWxsIGJlIGF2YWlsYWJsZSB3aXRoaW4g
MTUgbWludXRlcy4gIChBc3N1bWUgdGhlIGluaXRpYWwgQ1JMIGlzIHNtYWxsIGFuZCB3aWxsIHBy
b3BhZ2F0ZSBhcyBpZiBhIGRlbHRhIENSTCB0byByZXNvbHZlIHRoZSBib290c3RyYXAgaXNzdWVz
LikNDVRoZSBleGFtcGxlIGJlbG93IHVzZXMgdGhlICJzbGlkaW5nIHdpbmRvdyIgbWV0aG9kIG9m
IGlzc3VpbmcgZGVsdGEtQ1JMcywgYnV0IG92ZXJsYXBzIHRoZSB0aGlzVXVwZGF0ZSBhbmQgbmV4
dFV1cGRhdGUgdGltZXMgdG8gYWxsb3cgZm9yIHByb3BhZ2F0aW9uLi4gSW4gdGhpcyBleGFtcGxl
LCBmdWxsIENSTHMgYXJlIGlzc3VlZCBvbmNlIGV2ZXJ5IDMgaG91cnMgYW5kIGRlbHRhcyBhcmUg
aXNzdWVkIG9uY2UgYW4gaG91cmV2ZXJ5IDQ1IG1pbnV0ZXMuIEZvciBjb25zaXN0ZW5jeSwgdGhl
IGlzc3VlciBiZWdpbnMgaXNzdWluZyBkZWx0YXMgYXQgdGhlIHNhbWUgdGltZSBhcyB0aGUgdmVy
eSBmaXJzdCBmdWxsIENSTC4gTm90aWNlIHRoYXQgc3RhcnRpbmcgd2l0aCBjUkxOdW1iZXIgNywg
dGhlIGRlbHRhIENSTCBpc3N1ZWQgYXQgdGhlIHNhbWUgdGltZSBhcyBhIGZ1bGwgQ1JMIGRvZXMg
bm90IHVzZSB0aGUgcHJldmlvdXNseSBpc3N1ZWQgZnVsbCBDUkwgYXMgaXRzIGJhc2UgYnV0IHRo
ZSBwcmVjZWRpbmcgQ1JMIGluc3RlYWQuICBIb3dldmVyLCB0aGVzZSBkZWx0YS1DUkxzIG5ldmVy
IHByb3ZpZGUgbW9yZSB0aGFuIDYgaG91cnMgb2YgaGlzdG9yeS4NDUFzIGluU2ltaWxhcmx5IHRv
IGV4YW1wbGVzICMxIGFuZCAjMjoNQ2VydGlmaWNhdGUgMTQgd2FzIHJldm9rZWQgZm9yIGtleSBj
b21wcm9taXNlIGJlZm9yZSAxMjowMCB3aGVuIHRoZSBmaXJzdCBDUkwgd2FzIGlzc3VlZC4NQ2Vy
dGlmaWNhdGUgMTI0IHdhcyByZXZva2VkIGZvciBrZXkgY29tcHJvbWlzZSBiZXR3ZWVuIDEyOjAw
IGFuZCAxMzowMDEyOjQ1Lg1DZXJ0aWZpY2F0ZSAzOSB3YXMgcGxhY2VkIG9uIGhvbGQgYmV0d2Vl
biAxNDowMCAxNSBhbmQgMTU6MDAsIGFuZCBpdHMgc3VzcGVuc2lvbiB3YXMgbGlmdGVkIGJldHdl
ZW4gMTYxNTowMCA0NSBhbmQgMTc6MDAxNjozMC4NQ2VydGlmaWNhdGUgNjcgd2FzIHJldm9rZWQg
Zm9yIGFuIGFmZmlsaWF0aW9uIGNoYW5nZSBiZXR3ZWVuIDE2OjAwIDE1OjAwIGFuZCAxNzowMDE1
OjQ1LiAgVGhlIHJlYXNvbiB3YXMgY2hhbmdlZCB0byBrZXkgY29tcHJvbWlzZSBiZXR3ZWVuIDE4
NjowMCBhbmQgMTc6MDAxODo0NS4gIHt7eyBDYW5ub3QgaGF2ZSBzYW1lIHRpbWUgc3BhbiEgfX19
DQ1jdXJyZW50IHRpbWUgICAgIAdSZXZva2VkIGNlcnRpZmljYXRlcwdGdWxsIENSTAdEZWx0YS1D
UkwHBzEyOjAwB3sxNGt9ICAgICAgICAgICAgB2NSTE51bWJlciA9IDEgICAgICAgICAgICAgICAg
ICAgdGhpc1VwZGF0ZSA9IDEyOjAwICAgICAgICAgICAgICBuZXh0VXBkYXRlID0gMTg6MDAgICAg
ICAgICAgICAgIENlcnRpZmljYXRlTGlzdCA9IHsxNGt9B2NSTE51bWJlciA9IDEgICAgICAgICAg
ICAgICAgICAgdGhpc1VwZGF0ZSA9IDEyOjAwDW5leHRVcGRhdGUgPSAxMzoxNSAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDAwICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgQmFzZUNSTE51bWJlciA9IDENQ2VydGlmaWNhdGVMaXN0ID0ge30gICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAHBzEzOjAwMTI6NDUHezE0aywgMTI0
a30gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAHB2NSTE51bWJlciA9IDIg
ICAgICAgICAgICAgICAgICAgdGhpc1VwZGF0ZSA9IDEzOjAwMTI6NDUNbmV4dFVwZGF0ZSA9IDE0
OjE1ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgMTM6NDUNQmFzZUNSTE51bWJlciA9IDENQ2VydGlmaWNhdGVMaXN0ID0gezEyNGt9
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgBwcxNDow
MDEzOjMwB3sxNGssIDEyNGt9ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
BwdjUkxOdW1iZXIgPSAzICAgICAgICAgICAgICAgICAgIHRoaXNVcGRhdGUgPSAxNDowMDEzOjMw
DW5leHRVcGRhdGUgPSAxNDU6MTUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAzMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJhc2VDUkxOdW1iZXIgPSAxDUNlcnRp
ZmljYXRlTGlzdCA9IHsxMjRrfSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIAcHMTQ6MTUHezE0aywgMTI0a30gICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAHB2NSTE51bWJlciA9IDQgICAgICAgICAgICAgICAgICAgdGhpc1VwZGF0
ZSA9IDE0OjE1DW5leHRVcGRhdGUgPSAxNToxNSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJhc2VDUkxOdW1iZXIgPSAxDUNlcnRp
ZmljYXRlTGlzdCA9DXsxMjRrfQcHMTU6MDAHezE0aywgMTI0aywgMzlofSAgIAdjUkxOdW1iZXIg
PSA0ICAgICAgICAgICAgICAgICAgIDUgICAgICAgICAgICAgICAgICAgdGhpc1VwZGF0ZSA9IDE1
OjAwICAgICAgICAgICAgICBuZXh0VXBkYXRlID0gMjE6MDAgICAgICAgICAgICAgIENlcnRpZmlj
YXRlTGlzdCA9IHsxNGssIDEyNGssIDM5aH0HY1JMTnVtYmVyID0gNDUNdGhpc1VwZGF0ZSA9IDE1
NjowMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbmV4dFVwZGF0
ZSA9IDE3MTY6MTUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMDAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQmFzZUNSTE51bWJlciA9
IDEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2VydGlmaWNhdGVM
aXN0ID0gezEyNGssIDM5aH0HBzE2OjAwMTU6NDUHezE0aywgMTI0aywgMzloLCA2N2F9ICAgBwdj
UkxOdW1iZXIgPSA1Ng10aGlzVXBkYXRlID0gMTY6MDAxNTo0NSAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgbmV4dFVwZGF0ZSA9IDE2OjQ3OjE1ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJhc2VDUkxOdW1iZXIgPSAxICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENlcnRpZmljYXRlTGlzdCA9IHsxMjRr
LCAzOWgsIDY3YX0HBzE3OjAwMTY6MzAHezE0aywgMTI0aywgNjdhfSAgIAcHY1JMTnVtYmVyID0g
NjcNdGhpc1VwZGF0ZSA9IDE2OjM3OjAwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBuZXh0VXBkYXRlID0gMTg6MTUxNzozMCAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBCYXNlQ1JMTnVtYmVyID0gMSAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBDZXJ0aWZpY2F0ZUxpc3QgPSB7MTI0aywgMzlyLCA2N2F9
BwcxNzoxNQd7MTRrLCAxMjRrLCA2N2F9ICAgBwdjUkxOdW1iZXIgPSA4DXRoaXNVcGRhdGUgPSAx
NzoxNSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbmV4dFVwZGF0
ZSA9IDE4OjE1ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJhc2VD
UkxOdW1iZXIgPSAxICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENl
cnRpZmljYXRlTGlzdCA9IHsxMjRrLCAzOXIsIDY3YX0HBzE4OjAwB3sxNGssIDEyNGssIDY3YX0g
ICAHY1JMTnVtYmVyID0gNyAgICAgICAgICAgICAgICAgICA5ICAgICAgICAgICAgICAgICAgIHRo
aXNVcGRhdGUgPSAxODowMCAgICAgICAgICAgICAgbmV4dFVwZGF0ZSA9IDI0OjAwICAgICAgICAg
ICAgICBDZXJ0aWZpY2F0ZUxpc3QgPSB7MTRrLCAxMjRrLCA2N2F9B2NSTE51bWJlciA9IDc5DXRo
aXNVcGRhdGUgPSAxODowMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgbmV4dFVwZGF0ZSA9IDE5OjE1ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIDAwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJhc2VD
UkxOdW1iZXIgPSAxICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDUg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2VydGlmaWNhdGVMaXN0
ID0gezEyNGssIDM5ciwgNjdhfQcHMTkxODowMDQ1B3sxNGssIDEyNGssIDY3a30gICAHB2NSTE51
bWJlciA9IDgxMA10aGlzVXBkYXRlID0gMTg6NDU5OjAwICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBuZXh0VXBkYXRlID0gMjA6MTUxOTo0NSAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCYXNlQ1JMTnVtYmVyID0gNCAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA1ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIENlcnRpZmljYXRlTGlzdCA9IHszOXIsIDY3a30HBw1EZWx0YSBD
UkwgbnVtYmVyIDYgaXMgaXNzdWVkIGF0IDE3OjAwMTU6NDUuICBCeSAxNjowMDc6MTUsIGRlbHRh
IENSTCBudW1iZXIgNiBzaG91bGQgYmUgYXZhaWxhYmxlIHRocm91Z2hvdXQgdGhlIHN5c3RlbS4g
IEFzIGEgcmVzdWx0LCBkZWx0YSBDUkwgbnVtYmVyIDUgc3BlY2lmaWVkIDE3OjE1MTY6MDAgYXMg
aXRzIG5leHRVcGRhdGUgdGltZS4NDUhvd2V2ZXIsIEZ1bGwgZnVsbCBDUkwgQ1JMIG51bWJlciA0
IDUgd2FzIGlzc3VlZCBhdCAxNTowMCBhbmQgbWF5IG5vdCBiZSBhdmFpbGFibGUgdGhyb3VnaG91
dCB0aGUgc3lzdGVtIHVudGlsIDE4OjAwLiAgQXMgYSByZXN1bHQsIGRlbHRhIENSTCBudW1iZXIg
NiBtdXN0IGJlIGJhc2VkIG9uIEZ1bGwgZnVsbCBDUkwgbnVtYmVyIDEgd2hpY2ggd2FzIGlzc3Vl
ZCBhdCAxMjowMC4NDUlmIHRoZSByZWx5aW5nIHBhcnR5IGZpbmRzIEZ1bGwgZnVsbCBDUkwgbnVt
YmVyIDQgNSBpbiB0aGUgcmVwb3NpdG9yeSwgdGhleSBtYXkgc3RpbGwgYXBwbHkgZGVsdGEgQ1JM
IG51bWJlciA2IGFuZCBhY2hpZXZlIHRoZSBjb3JyZWN0IGFuc3dlci4NDUZpbmFsbHksIG5vdGUg
dGhhdCBhIENSTCBpc3N1ZXIgbXVzdCBnZW5lcmF0ZSBtb3JlIENSTHMgdG8gYWNoaWV2ZSB0aGUg
Z29hbCBvZiBzdGF0dXMgaW5mb3JtYXRpb24gdGhhdCBpcyBubyBtb3JlIHRoYW4gb25lIGhvdXIg
b2xkIHdoZW4gZmFjdG9yaW5nIGluIHRoZSBwcm9wYWdhdGlvbiBkZWxheXMuDQ0NAiBBIHJldm9j
YXRpb24gbm90aWNlIG1heSBvcHRpb25hbGx5IHNwZWNpZnkgaW4gdGhlIGludmFsaWRpdHkgZGF0
ZSBleHRlbnNpb24gdGhlIGRhdGUgYXQgZnJvbSB3aGljaCB0aGUgY2VydGlmaWNhdGUgc2hvdWxk
IGJlIGNvbnNpZGVyZWQgaW52YWxpZCBpbiB0aGUgaW52YWxpZGl0eSBkYXRlIGV4dGVuc2lvbiwg
YXMgd2VsbC4gIFRoaXMgZGF0ZSBtYXkgcHJlY2VkZSB0aGUgYWN0dWFsIHJldm9jYXRpb24gZGF0
ZS4gIFRoZSBpbnZhbGlkdHlpbnZhbGlkaXR5IGRhdGUgZXh0ZW5zaW9uIGRvZXMgbm90IGZlYXR1
cmUgaW4gdGhpcyBkaXNjdXNzaW9uLCBzbyBpdCBpcyBub3QgY29uc2lkZXJlZCBmdXJ0aGVyIGlu
IHRoaXMgcGFwZXIuDQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAQAAAEEAACXBAAAoQQAAPgEAAD9BAAAAgUAAPoHAAAMCAAAGQkAACQJAAA5CQAAOgkA
ANYJAADkCQAA5QkAAB0KAAAeCgAAIQoAACQKAAAlCgAAMAoAADEKAACMCgAAjQoAAJwKAACjCgAA
tAoAAEoLAABfCwAAaQsAAHILAABqDAAAyg0AAMsNAAAhDgAAJg4AACgOAAAqDgAAKw4AADUOAABB
DgAATQ4AAGoOAAB0DgAAfQ4AAEYPAAD4APEA6vEA6ADoAOEA2tMAzADFzADMAMwA09oAvrCpvqIA
m42bjZuNmwCGeKmGAAAAAAAAGgAIgQEIgQRIAgAFaARDVUZjSAQAZGhrRFVGAA0BCIEESAIABWgE
Q1VGGgAIgQEIgQRIAgAFaANDVUZjSAMAZGjPQ1VGAA0BCIEESAIABWgDQ1VGDQAIgWNIAgBkaABD
VUYNAQiBBEgEAAVoa0RVRhoACIEBCIEESAIABWgAQ1VGY0gEAGRoa0RVRgANAQiBBEgCAAVoAENV
Rg0BCIEESAMABWjMQ1VGDQAIgWNIAwBkaMxDVUYNAAiBY0gDAGRozUNVRg0BCIEESAMABWjNQ1VG
DQNqAAAAADBKEgBVCAEDNgiBDQAIgWNIAgBkaPVCVUYNAQiBBEgCAAVo9UJVRg0BCIEESAEABWhA
RFVGAC4ABAAADAQAAA0EAAAdBQAAHgUAAIsFAACMBQAAkgUAAJMFAAA1BgAANgYAANgGAADZBgAA
OwkAADwJAACPCQAAkAkAAD8LAABACwAAyw0AAMwNAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAA
APsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD5AAAA
AAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAA
AAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7
AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAAtAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARAAAQyQBRcaAAAACAANDVUYAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQMAAAEAAAAB
DwAAFAAEAADwYQAAXWMAAP7+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC
AQECzA0AAEEOAABCDgAA8w8AAPQPAABpEAAAahAAAKkQAACqEAAAuBAAALkQAACFEgAAhhIAAPMT
AAD0EwAAChUAAAsVAADbFgAA3BYAACMXAAAkFwAA7xgAALoAAAAAAAAAAAAAAAC4AAAAAAAAAAAA
AAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgA
AAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAtgAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAA
AAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAA
ALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALYAAAAAAAAAAAAAAAC4AAAA
AAAAAAAAAAAAuAAAAAAAAAAAAAAAAAAAAAABAQAAAQAAAEQAAEMkAUXGgAAAAgADQ1VGAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ABVGDwAA8w8AAGoQAACoEAAAyhAAANAQAAD1EAAA+xAAAA4RAAATEQAAHREAACYRAAAoEQAANhEA
ADcRAABhEQAAmBEAAJwRAACdEQAAtxEAAL0RAADGEQAA0BEAANcRAADcEQAA6BEAAO0RAADyEQAA
BRIAAAYSAAAKEgAAEhIAABUSAAAWEgAAGxIAACUSAAApEgAALBIAAC4SAAD48fgA6uPc1c7A1cDV
sqOUo9UA1dwA3I0AjYYAeADOcQDOeM6NYwAAAAAaAAiBAQiBBEgCAAVoBkNVRmNIBABkaFBEVUYA
DQEIgQRIAgAFaAVDVUYaAAiBAQiBBEgCAAVoBUNVRmNIBABkaFBEVUYADQEIgQRIBAAFaFBEVUYN
AAiBY0gEAGRoUERVRh0ACIEBCIEESAMABWjRQ1VGDCoHY0gEAGRoT0RVRh0ACIEBCIEESAMABWjQ
Q1VGDCoHY0gEAGRoT0RVRhoACIEBCIEESAMABWjQQ1VGY0gEAGRoT0RVRgAaAAiBAQiBBEgCAAVo
BUNVRmNIBABkaE9EVUYADQAIgWNIAgBkaAVDVUYNAAiBY0gEAGRoT0RVRg0BCIEESAQABWhPRFVG
DQEIgQRIBAAFaE5EVUYNAAiBY0gEAGRoTkRVRg0ACIFjSAIAZGgDQ1VGDQAIgWNIAgBkaARDVUYA
Ji4SAAAwEgAAORIAAD0SAABBEgAAQhIAAEMSAABbEgAAZhIAAGgSAABwEgAAcRIAAHUSAAB6EgAA
fRIAAIISAACDEgAAtBIAAL0SAAA0EwAANRMAAGITAABlEwAAaBMAAGwTAABuEwAAfBMAAH4TAACH
EwAAjBMAAJATAACqEwAAxxMAAMwTAADREwAA7hMAAO8TAADwEwAA8hMAAPQTAAD1EwAA/xMAAA4U
AAAVFAAAHxQAAE4UAAD48eoA3PHV3OrO6s7c6s7cAMcAwLmrx9Wdx4+Ij8ePx4iPxwDAgYjAegB6
wAAAAAAAAAAAAAAAAAAAAAANAAiBY0gEAGRoUkRVRg0BCIEESAIABWgHQ1VGDQAIgWNIAgBkaAdD
VUYaAAiBAQiBBEgCAAVoB0NVRmNIBABkaFFEVUYAGgAIgQEIgQRIAgAFaAZDVUZjSAQAZGhRRFVG
ABoACIEBCIEESAMABWjRQ1VGY0gEAGRoUURVRgANAQiBBEgDAAVo0UNVRg0BCIEESAQABWhSRFVG
DQAIgWNIBABkaFFEVUYNAQiBBEgCAAVoBkNVRg0ACIFjSAIAZGgGQ1VGGgAIgQEIgQRIAgAFaAZD
VUZjSAQAZGhQRFVGAA0BCIEESAQABWhQRFVGDQAIgWNIBABkaFBEVUYNAAiBY0gCAGRoBUNVRgAt
ThQAAFgUAABZFAAAjhQAAAgVAAAbFQAAIhUAACwVAABHFQAASxUAAFgVAABsFQAAcBUAAH0VAACf
FgAAoBYAAAUXAAAKFwAADxcAACMXAAAkFwAALxcAADgXAAA9FwAAQhcAAEMXAABEFwAAWhcAAFwX
AACdFwAAoxcAAKUXAACqFwAArRcAALMXAAC1FwAAthcAALgXAADeFwAA6xcAAO0XAADvFwAA/RcA
ABMYAAD48QDqAOPcANXOANXOAMcAwLkAtwCwqQDAuQCilI2GAH8AeLl/AHjAuQBxAAAAAAAAAA0B
CIEESAMABWjWQ1VGDQEIgQRIAwAFaNVDVUYNAAiBY0gDAGRo1UNVRg0ACIFjSAMAZGjUQ1VGDQEI
gQRIAwAFaNRDVUYaAAiBAQiBBEgDAAVo1ENVRmNIBABkaFdEVUYADQEIgQRIBAAFaFdEVUYNAQiB
BEgCAAVoIUNVRg0ACIFjSAIAZGghQ1VGAzUIgQ0BCIEESAQABWhiRFVGDQAIgWNIBABkaGJEVUYN
AAiBY0gDAGRo00NVRg0BCIEESAMABWjSQ1VGDQAIgWNIAwBkaNJDVUYNAQiBBEgEAAVoVERVRg0A
CIFjSAQAZGhURFVGDQEIgQRIBAAFaFFEVUYNAQiBBEgEAAVoU0RVRg0ACIFjSAQAZGhTRFVGACsT
GAAAFBgAABUYAAAvGAAAOxgAAEQYAABJGAAAgBgAAIEYAACDGAAAiBgAAJcYAACYGAAAmRgAALsY
AADAGAAAxRgAAO4YAADvGAAA8BgAAPEYAAAAGgAAFxoAABwaAAAlGgAALxoAADMaAABEGgAAvBoA
AL4aAADBGgAAwxoAAMQaAAAJGwAACxsAAAwbAAANGwAAgRsAAIobAADy6+Td1sjdAMEA3bqzAKyl
ALqeALoAl5AAkACzgrOCe7OXdG0AZgAAAAAAAAAAAAANAAiBY0gCAGRoIUNVRg0BCIEESAQABWhm
RFVGDQAIgWNIBABkaGZEVUYNAAiBY0gCAGRoHUNVRhoACIEBCIEESAIABWgdQ1VGY0gEAGRoYkRV
RgANAQiBBEgEAAVoZURVRg0ACIFjSAQAZGhlRFVGDQAIgWNIAgBkaAhDVUYNAQiBBEgEAAVoaURV
Rg0ACIFjSAQAZGhpRFVGDQAIgWNIBABkaGJEVUYNAQiBBEgEAAVoYkRVRg0BCIEESAMABWjXQ1VG
GgAIgQEIgQRIAgAFaBxDVUZjSAMAZGjXQ1VGAA0ACIFjSAIAZGgcQ1VGDQAIgWNIAwBkaNdDVUYN
AQiBBEgDAAVo1kNVRg0BCIEESAQABWhjRFVGGgAIgQEIgQRIAwAFaNZDVUZjSAQAZGhjRFVGJu8Y
AADxGAAAABoAAAEaAABDGgAARBoAAAobAAALGwAAURsAAFIbAADvGwAAugAAAAAAAAAAAAAAALgA
AAAAAAAAAAAAAAC6AAAAAAAAAAAAAAAAswAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAA
AAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAbAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABGAAAKJgALRgEARcaA
AQACAPVCVUYCAAAAAAAAAAAABAIABAIABAIAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAMAKAAAACkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAABAIAAyQBYSQBAAEAAABEAABDJAFFxoAAAAQAYkRVRgAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKihsA
AI8bAABKHAAAUxwAAFgcAABcHAAAXRwAAF8cAAB3HAAAgxwAAI8cAACWHAAAmxwAAKQcAACoHAAA
qxwAAKwcAACwHAAAtBwAALUcAADgHAAA5RwAAOocAADvHAAA8xwAABgdAAAbHQAAIh0AAGEdAACa
HQAAnB0AAJ4dAAC7HQAAUB4AAFEeAABaHgAAWx4AAHUeAACzHgAAth4AALkeAADSHgAAAh8AAAcf
AAD4APH4APEA7+bd7+bd793m793vANbPAMgAwcgAuqzPuqUAnpeQicF7iQB0AAAAAAAAAAAAAAAA
AA0ACIFjSAQAZGhrRFVGGgAIgQEIgQRIAgAFaCJDVUZjSAMAZGjaQ1VGAA0ACIFjSAMAZGjaQ1VG
DQEIgQRIAwAFaNtDVUYNAQiBBEgDAAVo3ENVRg0BCIEESAMABWjiQ1VGDQAIgWNIAwBkaNtDVUYa
AAiBAQiBBEgDAAVo2kNVRmNIBABkaGpEVUYADQEIgQRIAwAFaNpDVUYNAAiBY0gCAGRoIkNVRg0B
CIEESAIABWgiQ1VGDQEIgQRIBAAFaGpEVUYNAAiBY0gEAGRoakRVRhABCIEESAQABWhpRFVGNgiB
ABAACIE2CIFjSAQAZGhpRFVGAAM2CIENAAiBY0gCAGRoIUNVRg0BCIEESAIABWghQ1VGACvvGwAA
XhwAAF8cAAC1HAAAthwAADkdAAA6HQAAYR0AALgAAAAAAAAAAAAAAAC2AAAAAAAAAAAAAAAAsQAA
AAAAAAAAAAAAALYAAAAAAAAAAAAAAAC2AAAAAAAAAAAAAAAAtgAAAAAAAAAAAAAAAGoAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABGAAAKJgALRgQARcaAAQACAPVC
VUYCAAAAAAAAAAAABAIABAIABAIAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAMAKAAAACkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAABAAAAyQBYSQBAAEAAABGAAAKJgALRgEARcaAAQACAPVCVUYCAAAAAAAAAAAABAIA
BAIABAIAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAKAAAACkAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB2EdAABR
HgAA0x4AADofAAC4AAAAAAAAAAAAAAAAcQAAAAAAAAAAAAAAACoAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABGAAAKJgALRgQARcaAAQACAPVCVUYCAAAAAAAAAAAABAIA
BAIABAIAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAKAAAACkAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARgAACiYB
C0YEAEXGgAEAAgD1QlVGAQAAAAAAAAAAAAQCAAQCAAQCAAABAAAAAgAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAACAAEALgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEYAAAomAQtGBABFxoABAAIA9UJVRgEAAAAAAAAAAAAEAgAE
AgAEAgAAAQAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgABAC4AAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADBx8AAAwf
AABQHwAAVR8AAFofAACMHwAAkR8AAJYfAACzHwAAvx8AAMQfAADNHwAA1h8AANofAADyHwAAIiAA
ADEgAAA+IAAAXyAAAGAgAABhIAAAiCAAAIkgAACKIAAAQSEAAEIhAADIIQAAySEAAMohAAAcIgAA
ZyIAAGoiAABrIgAAkyIAAJUiAAB7IwAAniMAAMojAADMIwAA9yMAAPgjAAAFJAAAGiQAAFAkAABg
JAAAYSQAAGYkAAB1JAAAdiQAAHckAAB7JAAAfCQAAH4kAAD4APH4APH4AO/m3e/U7wDNxgC/uAC/
uAC2AL+4AK8ArwCoAKEAmgC2AJOMAIWaALaTAJMAAAANAQiBBEgEAAVobURVRg0BCIEESAIABWgm
Q1VGDQAIgWNIAgBkaCZDVUYNAAiBY0gEAGRobURVRg0BCIEESAMABWjoQ1VGDQAIgWNIBABkaGxE
VUYNAAiBY0gCAGRoJENVRgNIKgINAQiBBEgEAAVoZ0RVRg0ACIFjSAQAZGhnRFVGDQEIgQRIAwAF
aOZDVUYNAAiBY0gDAGRo5kNVRhABCIEESAQABWhsRFVGNgiBABABCIEESAQABWhrRFVGNgiBABAA
CIE2CIFjSAQAZGhrRFVGAAM2CIENAAiBY0gEAGRoa0RVRg0BCIEESAQABWhrRFVGADQ6HwAAch8A
ALIfAACzHwAA8h8AAPMfAABAIAAAQSAAAAIhAAADIQAAnSEAAJ4hAAAbIgAAuAAAAAAAAAAAAAAA
AHEAAAAAAAAAAAAAAABvAAAAAAAAAAAAAAAAagAAAAAAAAAAAAAAAG8AAAAAAAAAAAAAAABvAAAA
AAAAAAAAAAAAbwAAAAAAAAAAAAAAAG8AAAAAAAAAAAAAAABvAAAAAAAAAAAAAAAAbwAAAAAAAAAA
AAAAAG8AAAAAAAAAAAAAAABvAAAAAAAAAAAAAAAAAAAAAAAEAAADJAFhJAEAAQAAAEYAAAomAQtG
BABFxoABAAIA9UJVRgEAAAAAAAAAAAAEAgAEAgAEAgAAAgAAAAIAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAgABAC4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAABGAAAKJgELRgQARcaAAQACAPVCVUYBAAAAAAAAAAAABAIABAIA
BAIAAAIAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAQAuAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADBsiAAAcIgAA
ZyIAAMMiAAA5IwAAnyMAAAAkAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA
AAC2AAAAAAAAAAAAAAAAbwAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABGAAAKJgALRgIARcaA
AQACAPVCVUYCAAAAAAAAAAAEBAIABAIABAIAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAMAKAAAACkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAARgAACiYAC0YCAEXGgAEAAgD1QlVGAgAAAAAAAAAABAQCAAQCAAQCAAAB
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADACgAAAApAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAGACQAAHgkAABX
JQAAWCUAANwmAADdJgAA3ycAAOAnAAASKAAAEygAAE8pAAC4AAAAAAAAAAAAAAAAcQAAAAAAAAAA
AAAAAG8AAAAAAAAAAAAAAABvAAAAAAAAAAAAAAAAbwAAAAAAAAAAAAAAAG8AAAAAAAAAAAAAAABv
AAAAAAAAAAAAAAAAbQAAAAAAAAAAAAAAAG8AAAAAAAAAAAAAAABvAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQMAAAEAAABGAAAKJgALRgMA
RcaAAQACAPVCVUYCAAAAAAAAAAAEBAIABAIABAIAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAMAKAAAACkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAARgAACiYAC0YDAEXGgAEAAgD1QlVGAgAAAAAAAAAABAQCAAQCAAQC
AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADACgAAAApAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAp+JAAAgiQAAKEk
AADAJAAAwyQAAO4kAADvJAAA8CQAAPEkAADyJAAA9yQAAP4kAAAFJQAAJiUAACclAABVJQAAayUA
AGwlAABtJQAAgCUAAIklAACOJQAAqyUAALQlAAC5JQAAvSUAAMslAADNJQAAzyUAANAlAAB9JgAA
fiYAALAmAAC0JgAADycAABAnAABUJwAA3ScAABQoAABfKAAAkygAAKEoAACnKAAAqigAAKsoAAD4
KAAA+PHq8QDj3NUA487HAMDHALmyAM7HAKukAJ0AndwAzgCWAKsAjwCIgXoAgXoAAAAAAAAAAAAA
AAAAAAAADQAIgWNIBABkaHBEVUYNAQiBBEgEAAVocERVRg0BCIEESAQABWhvRFVGDQEIgQRIBAAF
aG5EVUYNAQiBBEgDAAVo6kNVRg0ACIFjSAMAZGjpQ1VGDQEIgQRIAgAFaChDVUYNAAiBY0gCAGRo
KENVRg0BCIEESAQABWhnRFVGDQAIgWNIBABkaGdEVUYNSCoCV8oHAQIAJ0NVRg0BCIEESAIABWgn
Q1VGDQAIgWNIAgBkaCdDVUYNAQiBBEgEAAVobURVRg0BCIEESAMABWjpQ1VGDQAIgWNIBABkaG1E
VUYNAQiBBEgDAAVo6ENVRg0BCIEESAIABWgmQ1VGDQAIgWNIAgBkaCZDVUYALfgoAAD5KAAATikA
AE8pAABQKQAAZioAAGgqAABpKgAAcCoAANAqAADeKgAA3yoAAOoqAADrKgAA7SoAAO4qAADxKgAA
/CoAAP4qAAD/KgAACSsAABErAAAlKwAAUCsAAGQrAABmKwAAaisAAMgrAADJKwAAyisAABQtAAAW
LQAAYy0AAGQtAABlLQAAsDAAALIwAAC0MAAAvDAAAL4wAADAMAAA+DAAAPkwAAD46eLbANTN1M3G
v8a/xr/Gv9S/xr/Gv9S4qZqpmqmTAIyFAH53AH53AHAAAAAAAAAAAAAADQEIgQRIBAAFaGdEVUYN
AQiBBEgEAAVoh0pVZg0ACIFjSAQAZGiHSlVmDQAIgWNIAgBkaClDVUYNAQiBBEgCAAVoKUNVRg0A
CIFjSAQAZGh0RFVGHQAIgQEIgQRIAwAFaO1DVUYMKgdjSAQAZGh0RFVGHQAIgQEIgQRIAwAFaO5D
VUYMKgdjSAQAZGh0RFVGDQEIgQRIAwAFaO1DVUYNAQiBBEgEAAVoc0RVRg0BCIEESAQABWhyRFVG
DQEIgQRIBAAFaHFEVUYNAQiBBEgEAAVodERVRg0BCIEESAQABWhwRFVGDQAIgWNIBABkaHBEVUYd
AAiBAQiBBEgDAAVo60NVRgwqB2NIBABkaHBEVUYNAQiBBEgDAAVo60NVRgAqTykAAFApAABRKQAA
nCkAAN0pAABnKgAAugAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAA
AAAAAAAAAHUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQwAARcaA
AAAEAHJEVUYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAQAAAEQAAEMkAUXGgAAABABwRFVGAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVnKgAAaCoAAGMrAABk
KwAAZSsAAGYrAABqKwAAugAAAAAAAAAAAAAAALoAAAAAAAAAAAAAAAC6AAAAAAAAAAAAAAAAugAA
AAAAAAAAAAAAAHUAAAAAAAAAAAAAAAB1AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARAAAQyQB
RcaAAAADAO1DVUYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAARAAAQyQBRcaAAAAEAHREVUYAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABmorAADJKwAAyisAAOgr
AAANLAAAMiwAAFcsAAB8LAAAoSwAAMYsAADrLAAAES0AABUtAAAWLQAAIS0AACItAABNLwAATi8A
AF8vAAC5LwAAATAAAHMwAAC6AAAAAAAAAAAAAAAAugAAAAAAAAAAAAAAALoAAAAAAAAAAAAAAAC6
AAAAAAAAAAAAAAAAugAAAAAAAAAAAAAAALoAAAAAAAAAAAAAAAC6AAAAAAAAAAAAAAAAugAAAAAA
AAAAAAAAALoAAAAAAAAAAAAAAAC6AAAAAAAAAAAAAAAAugAAAAAAAAAAAAAAALoAAAAAAAAAAAAA
AAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAA
AAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAA
AAAAAAAAAAAAAAAAAAEAAABEAABDJAFFxoAAAAMA7kNVRgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAV+TAAAPowAAADMQAABDEA
AAUxAAAIMQAACTEAADkxAAA6MQAASDEAAE0xAAB9MQAAjjEAAI8xAACoMQAArTEAAAYyAAAHMgAA
5DIAAOwyAAAeMwAAIDMAAAE0AAAJNAAAOzQAAD00AAAeNQAAJjUAADk1AAA6NQAAvDUAAL01AADZ
NQAA2jUAANs1AAAYNgAAGTYAABo2AAChNgAAqTYAAME2AADDNgAAmzcAAKA3AACkNwAAyDcAANA3
AADjNwAA5TcAAMY4AADOOAAA4TgAAOI4AAD4APH4AOrb1ADNAM0AzcDNAM0AzQDNAM0AzQDNAM0A
zbOmzbOmzQDNAM2ZzYQAzQDNAM0AKQAIgQEIgQRIAwAFaANEVUYMKgdDShIAT0oDAFFKAwBjSAQA
ZGh1RFVGGQAIgUNKEgBPSgMAUUoDAGNIBABkaHVEVUYZAAiBQ0oSAE9KAwBRSgMAY0gBAGRoYVNV
hhkBCIEESAEABWhhU1WGQ0oSAE9KAwBRSgMAGQAIgUNKEgBPSgMAUUoDAGNIAwBkaPBDVUYMQ0oS
AE9KAwBRSgMAAA0BCIEESAQABWhoRFVGHQAIgQEIgQRIAwAFaAREVUYMKgdjSAQAZGhoRFVGDQAI
gWNIBABkaGhEVUYNAQiBBEgEAAVoZ0RVRg0ACIFjSAQAZGhnRFVGADRzMAAAOzEAADwxAABOMQAA
YzEAAGwxAAB2MQAAdzEAAH0xAACPMQAABzIAADoyAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA
APcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAABnvAUA
AAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAACPAAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAABAEA
AAQBAAAEAQAACNZcAASU/ycJuhJOHOIlAAaTCQAAAAAAAAAAAAAAAAAAAAAABpMJAAAAAAAAAAAA
AAAAAAAAAAAGlAkAAAAAAAAAAAAAAAAAAAAAAAaUCQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/BAEA
AAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gEAABrWEAAAAP8AAAD/
AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/
AAAA/wAAAP801gYAAQoDbABh9gMAAAYAABYkAUlmAQAAAAABAAAACzoyAACdMgAA5TIAAOYyAADs
MgAAHzMAACAzAABTMwAAtjMAAAI0AAADNAAACTQAADw0AAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAA
AAAAAGl0BAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5
AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAABpdAQAAAAAAAAAAAAA+QAAAAAA
AAAAAAAAAPkAAAAAAAAAAAAAAAAAAACPAAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAA
BAEAAAQBAAAEAQAACNZcAASU/ycJuhJOHOIlAAaTCQAAAAAAAAAAAAAAAAAAAAAABpMJAAAAAAAA
AAAAAAAAAAAAAAAGlAkAAAAAAAAAAAAAAAAAAAAAAAaUCQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/
BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gEAABrWEAAAAP8A
AAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8A
AAD/AAAA/wAAAP801gYAAQoDbABh9gMAAAYAABYkAUlmAQAAAAAMPDQAAD00AABwNAAA0zQAAB81
AAAgNQAAJjUAADo1AAC9NQAAyzUAAKI2AACjNgAAqTYAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA
AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAABpDAYAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkA
AAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAABpnAQAAAAA
AAAAAAAA+QAAAAAAAAAAAAAAAAAAAI8AABYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQBAAAE
AQAABAEAAAQBAAAI1lwABJT/Jwm6Ek4c4iUABpMJAAAAAAAAAAAAAAAAAAAAAAAGkwkAAAAAAAAA
AAAAAAAAAAAAAAaUCQAAAAAAAAAAAAAAAAAAAAAABpQJAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8E
AQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2AQAAGtYQAAAA/wAA
AP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAA
AP8AAAD/AAAA/zTWBgABCgNsAGH2AwAABgAAFiQBSWYBAAAAAAypNgAAwjYAAMM2AADRNgAAyTcA
AMo3AADQNwAA5DcAAOU3AADzNwAAxzgAAMg4AADOOAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAA
AAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAGn4AwAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA
AAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAGkABgAAAAAA
AAAAAAD5AAAAAAAAAAAAAAAAAAAAjwAAFiQBFyQBSWYBAAAAApZsAAXWGAQBAAAEAQAABAEAAAQB
AAAEAQAABAEAAAjWXAAElP8nCboSThziJQAGkwkAAAAAAAAAAAAAAAAAAAAAAAaTCQAAAAAAAAAA
AAAAAAAAAAAABpQJAAAAAAAAAAAAAAAAAAAAAAAGlAkAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wQB
AAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAa1hAAAAD/AAAA
/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA
/wAAAP8AAAD/NNYGAAEKA2wAYfYDAAAGAAAWJAFJZgEAAAAADM44AADiOAAAZTkAAHM5AABHOgAA
SDoAAE46AABiOgAAYzoAAHE6AABAOwAAQTsAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA
AAAAAAAAAAAAAPkAAAAAAAAAAAAAAABp5AMAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA
AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAABpAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAACPAAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAABAEA
AAQBAAAEAQAACNZcAASU/ycJuhJOHOIlAAaTCQAAAAAAAAAAAAAAAAAAAAAABpMJAAAAAAAAAAAA
AAAAAAAAAAAGlAkAAAAAAAAAAAAAAAAAAAAAAAaUCQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/BAEA
AAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gEAABrWEAAAAP8AAAD/
AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/
AAAA/wAAAP801gYAAQoDbABh9gMAAAYAABYkAUlmAQAAAAAL4jgAAGQ5AABlOQAAPToAAEI6AABG
OgAATjoAAD87AABDOwAAWDsAAMw+AADOPgAA0D4AANg+AADaPgAA3D4AABQ/AAAVPwAAFj8AAB8/
AAAgPwAAIT8AACU/AAAmPwAAWj8AAFs/AABcPwAAaT8AAG4/AACePwAArz8AALA/AAAnQAAAKEAA
AAVBAAANQQAAP0EAAEFBAAAiQgAAKkIAAFxCAABeQgAAP0MAAEdDAABaQwAAW0MAAN1DAADeQwAA
+kMAAPtDAAD8QwAAOUQAADpEAAA7RAAAwkQAAPkA+ez5APkA5QDe1wDQyQDCuwDCuwC0pbvCAPkA
+QD5APkA+QD5APkA+QD5APkA+ZiL+ZiL+QAAAAAZAAiBQ0oSAE9KAwBRSgMAY0gBAGRoYVNVhhkB
CIEESAEABWhhU1WGQ0oSAE9KAwBRSgMAHQAIgQEIgQRIAwAFaAZEVUYMKgdjSAQAZGhoRFVGDQEI
gQRIAwAFaAZEVUYNAAiBY0gEAGRoaERVRg0BCIEESAQABWhoRFVGDQEIgQRIBAAFaIhKVWYNAAiB
Y0gEAGRoiEpVZg0BCIEESAQABWiHSlVmDQAIgWNIBABkaIdKVWYNAAiBY0gBAGRoWkNVRhkBCIEE
SAIABWgrQ1VGQ0oSAE9KAwBRSgMADENKEgBPSgMAUUoDADZBOwAAQjsAAEM7AABZOwAAWjsAAFs7
AABnOwAAaDsAAGg9AABpPQAAez0AANU9AAAdPgAAjz4AAFs/AABcPwAAXT8AAG8/AACEPwAAjT8A
AJc/AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA
/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA
AAAA/QAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAsgAAAAAAAAAAAAAAALIA
AAAAAAAAAAAAAACyAAAAAAAAAAAAAAAAsgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlm
AQAAAABEAABDJAFFxoAAAAQAaERVRgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAFJc/AACYPwAAnj8AALA/AAAoQAAAW0AA
AL5AAAAGQQAAB0EAAA1BAABAQQAAQUEAAHRBAABvvAUAAAAAAAAAAAAAaQAAAAAAAAAAAAAAAGkA
AAAAAAAAAAAAAABpAAAAAAAAAAAAAAAAaQAAAAAAAAAAAAAAAGkAAAAAAAAAAAAAAABpAAAAAAAA
AAAAAAAAb3QEAAAAAAAAAAAAAGkAAAAAAAAAAAAAAABpAAAAAAAAAAAAAAAAaQAAAAAAAAAAAAAA
AGkAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAACPAAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQB
AAAEAQAABAEAAAQBAAAEAQAACNZcAASU/ycJuhJOHOIlAAaTCQAAAAAAAAAAAAAAAAAAAAAABpMJ
AAAAAAAAAAAAAAAAAAAAAAAGlAkAAAAAAAAAAAAAAAAAAAAAAAaUCQAAAAAAAAAAAAAAAAAAAAAT
1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gEAABrW
EAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3W
EAAAAP8AAAD/AAAA/wAAAP801gYAAQoDbABh9gMAAAAMdEEAANdBAAAjQgAAJEIAACpCAABdQgAA
XkIAAJFCAAD0QgAAQEMAAEFDAABHQwAAW0MAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAAaXQE
AAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA
AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAGkMBgAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA
+QAAAAAAAAAAAAAAAAAAAI8AABYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEA
AAQBAAAI1lwABJT/Jwm6Ek4c4iUABpMJAAAAAAAAAAAAAAAAAAAAAAAGkwkAAAAAAAAAAAAAAAAA
AAAAAAaUCQAAAAAAAAAAAAAAAAAAAAAABpQJAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8EAQAAAAAA
/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2AQAAGtYQAAAA/wAAAP8AAAD/
AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/
AAAA/zTWBgABCgNsAGH2AwAABgAAFiQBSWYBAAAAAAxbQwAA3kMAAOxDAADDRAAAxEQAAMpEAADj
RAAA5EQAAPJEAADMRQAAzUUAANNFAADnRQAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAA
AAAAAAAAAAAAaSQEAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAA
AAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAAaRAEAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5
AAAAAAAAAAAAAAAAAAAAjwAAFiQBFyQBSWYBAAAAApZsAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAA
BAEAAAjWXAAElP8nCboSThziJQAGkwkAAAAAAAAAAAAAAAAAAAAAAAaTCQAAAAAAAAAAAAAAAAAA
AAAABpQJAAAAAAAAAAAAAAAAAAAAAAAGlAkAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wQBAAAAAAD/
BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAa1hAAAAD/AAAA/wAAAP8A
AAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8A
AAD/NNYGAAEKA2wAYfYDAAAGAAAWJAFJZgEAAAAADMJEAADKRAAA4kQAAOREAADLRQAA00UAAOZF
AADoRQAAz0YAANdGAADqRgAA60YAAG1HAABuRwAAVUgAAF1IAABTSQAAVkkAAJ9JAADaSQAA3EkA
AA5KAAAmSgAAJ0oAAClKAABpSgAAakoAAIxKAACNSgAAjkoAAA9LAAAgSwAAIUsAACJLAABuTQAA
b00AAHBNAAB+TQAAf00AAIBNAACkTQAApU0AAPZNAAACTgAAEk4AAG1PAAByTwAAfk8AAIZPAACH
TwAAik8AAJFPAAAuUAAAM1AAADhQAABnUAAAalAAAAD5APkA+QD5APkA+QD5APkA8uvk8uTy5N3W
3c/Wz9by3QDIwQDIwQDBALqzAKylAKUApQCelwCQAAAAAA0ACIFjSAQAZGiRRFVGDQEIgQRIBAAF
aJJEVUYNAAiBY0gEAGRokkRVRg0BCIEESAQABWiJSlVmDQAIgWNIBABkaIlKVWYNAQiBBEgEAAVo
dkRVRg0ACIFjSAQAZGh2RFVGDQAIgWNIAwBkaAhEVUYNAQiBBEgDAAVoCERVRg0BCIEESAQABWiY
RFVGDQEIgQRIBAAFaJlEVUYNAQiBBEgEAAVol0RVRg0BCIEESAQABWibRFVGDQEIgQRIBAAFaJpE
VUYNAQiBBEgEAAVolkRVRgxDShIAT0oDAFFKAwA450UAAOhFAAD2RQAA0EYAANFGAADXRgAA60YA
AG5HAAB8RwAAVkgAAFdIAABdSAAAcUgAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA
AAAAAAAAAGkYBgAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAA
AAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAGn4AwAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA
AAAAAAAAAAAAAAAAAI8AABYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQB
AAAI1lwABJT/Jwm6Ek4c4iUABpMJAAAAAAAAAAAAAAAAAAAAAAAGkwkAAAAAAAAAAAAAAAAAAAAA
AAaUCQAAAAAAAAAAAAAAAAAAAAAABpQJAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8EAQAAAAAA/wQB
AAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2AQAAGtYQAAAA/wAAAP8AAAD/AAAA
/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA
/zTWBgABCgNsAGH2AwAABgAAFiQBSWYBAAAAAAxxSAAAckgAAIBIAABUSQAAVUkAAFZJAAAoSgAA
+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAAaQAAAAAAAAAAAAAAAGcAAAAA
AAAAAAAAAABnAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAABAAAAjwAAFiQBFyQBSWYBAAAAApZsAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEA
AAjWXAAElP8nCboSThziJQAGkwkAAAAAAAAAAAAAAAAAAAAAAAaTCQAAAAAAAAAAAAAAAAAAAAAA
BpQJAAAAAAAAAAAAAAAAAAAAAAAGlAkAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wQBAAAAAAD/BAEA
AAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAa1hAAAAD/AAAA/wAAAP8AAAD/
G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/
NNYGAAEKA2wAYfYDAAAGAAAWJAFJZgEAAAAABihKAAApSgAAIUsAACJLAABaSwAAW0sAALoAAAAA
AAAAAAAAAAC6AAAAAAAAAAAAAAAAdQAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAuAAAAAAAAAAAA
AAAAAAAAAAEAAABEAABDJAFFxoAAAAQAlkRVRgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABEAABDJAFFxoAAAAQAl0RVRgAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AABEAABDJAFFxoAAAAQAm0RVRgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFW0sAAA5NAAAPTQAAbE8AAG1PAACTTwAA7U8AADpQ
AAC5UAAAgFEAAIFRAACTUQAAqFEAALFRAAC7UQAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9
AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA
AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAA
AAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAGAAAWJAFJZgEAAAAAAQAAAA5qUAAAbVAAAJ5QAACgUAAAolAAAKNQAACmUAAAqVAA
AK1QAACyUAAAt1AAAPZQAAD8UAAA/1AAAAFRAAACUQAABlEAAAtRAAAQUQAARVEAAEZRAABHUQAA
T1EAAFBRAABRUQAAVFEAAFlRAABaUQAAXFEAAF1RAABeUQAAf1EAAI1RAACSUQAAwlEAANNRAADU
UQAAS1IAAExSAACPUgAA0FIAABFTAABqUwAAbFMAAHFTAAD4APHqAPHqAOPcANXO3M4A1dwAx8AA
1cDVzgC5qpuqAJQAlACUAJSHepQAcwAAAAAAAA0ACIFjSAQAZGh3RFVGGQEIgQRIBAAFaHZEVUZD
ShIAT0oDAFFKAwAZAAiBQ0oSAE9KAwBRSgMAY0gEAGRodkRVRgxDShIAT0oDAFFKAwAAHQAIgQEI
gQRIAwAFaAlEVUYMKgdjSAQAZGh2RFVGHQAIgQEIgQRIAwAFaAhEVUYMKgdjSAQAZGh2RFVGDQEI
gQRIAwAFaAhEVUYNAAiBY0gEAGRoaURVRg0BCIEESAQABWhpRFVGDQEIgQRIBAAFaJNEVUYNAAiB
Y0gEAGRok0RVRg0BCIEESAQABWiJSlVmDQAIgWNIBABkaIlKVWYNAQiBBEgEAAVoiEpVZg0ACIFj
SAQAZGiISlVmDQEIgQRIBAAFaJFEVUYALLtRAAC8UQAAwlEAANRRAABMUgAAf1IAACNTAABrUwAA
bFMAAHdTAACqUwAAq1MAAONTAABvwAYAAAAAAAAAAAAAaQAAAAAAAAAAAAAAAGkAAAAAAAAAAAAA
AABpAAAAAAAAAAAAAAAAaQAAAAAAAAAAAAAAAGkAAAAAAAAAAAAAAABpAAAAAAAAAAAAAAAAb7QE
AAAAAAAAAAAAAGkAAAAAAAAAAAAAAABpAAAAAAAAAAAAAAAAaQAAAAAAAAAAAAAAAGkAAAAAAAAA
AAAAAAAAAAYAABYkAUlmAQAAAACPAAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAABAEA
AAQBAAAEAQAACNZcAASU/ycJuhJOHOIlAAaTCQAAAAAAAAAAAAAAAAAAAAAABpMJAAAAAAAAAAAA
AAAAAAAAAAAGlAkAAAAAAAAAAAAAAAAAAAAAAAaUCQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/BAEA
AAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gEAABrWEAAAAP8AAAD/
AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/
AAAA/wAAAP801gYAAQoDbABh9gMAAAAMcVMAAHZTAAB3UwAAqVMAAKtTAADYUwAA3VMAAOJTAADw
UwAANFQAADpUAACXVAAAmVQAAJ5UAACjVAAApFQAANZUAADYVAAABVUAAApVAAAPVQAAHlUAAB9V
AAAgVQAAIVUAAGJVAACjVQAAAFYAAAJWAAAIVgAAOlYAADtWAAA8VgAAaVYAAG5WAAB9VgAAflYA
AONWAADqVgAA61YAAOxWAADyVgAABVcAAAZXAAASVwAA+ADxAPHk1/Hk1/EA0PgA8QDxw7bxtsPx
qZzxAPiPtvi2graCtnW2+ADxAPEAAAAAAAAAAAAAGQEIgQRIBAAFaIlEVUZDShIAT0oDAFFKAwAZ
AQiBBEgEAAVoekRVRkNKEgBPSgMAUUoDABkBCIEESAEABWhpU1WGQ0oSAE9KAwBRSgMAGQEIgQRI
BAAFaHlEVUZDShIAT0oDAFFKAwAZAAiBQ0oSAE9KAwBRSgMAY0gEAGRoeURVRhkBCIEESAQABWh3
RFVGQ0oSAE9KAwBRSgMAGQAIgUNKEgBPSgMAUUoDAGNIBABkaHdEVUYNAAiBY0gEAGRod0RVRhkB
CIEESAQABWh2RFVGQ0oSAE9KAwBRSgMAGQAIgUNKEgBPSgMAUUoDAGNIBABkaHZEVUYMQ0oSAE9K
AwBRSgMAAA0BCIEESAQABWh3RFVGACzjUwAAOlQAAExUAACYVAAA+QAAAAAAAAAAAAAAALAAAAAA
AAAAAAAAAAD5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASQAAFiQBQyQBRcaAAAAEAHZEVUYAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AABJZgEAAAAGAAAWJAFJZgEAAAAAA5hUAACZVAAApFQAANdUAADYVAAAEFUAALVVAAABVgAAAlYA
AAhWAAA7VgAAPFYAAG+kBQAAAAAAAAAAAABpAAAAAAAAAAAAAAAAaQAAAAAAAAAAAAAAAGkAAAAA
AAAAAAAAAABpAAAAAAAAAAAAAAAAaQAAAAAAAAAAAAAAAGkAAAAAAAAAAAAAAABvqAMAAAAAAAAA
AAAAaQAAAAAAAAAAAAAAAGkAAAAAAAAAAAAAAABpAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAYAABYkAUlmAQAAAACPAAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAABAEAAAQB
AAAEAQAACNZcAASU/ycJuhJOHOIlAAaTCQAAAAAAAAAAAAAAAAAAAAAABpMJAAAAAAAAAAAAAAAA
AAAAAAAGlAkAAAAAAAAAAAAAAAAAAAAAAAaUCQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/BAEAAAAA
AP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gEAABrWEAAAAP8AAAD/AAAA
/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA
/wAAAP801gYAAQoDbABh9gMAAAALPFYAAG9WAADSVgAA5FYAAOtWAAC2AAAAAAAAAAAAAAAAtgAA
AAAAAAAAAAAAALAAAAAAAAAAAAAAAABnAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABJ
AAAWJAFDJAFFxoAAAAQAiURVRgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAElmAQAAAAYAABYkAUlmAQAAAEkAABYkAUMkAUXGgAAA
BAB3RFVGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAASWYBAAAAAATrVgAA7FYAAPJWAAAGVwAAnVcAAKxXAACxWAAAslgAAL1YAADW
WAAA11gAAOZYAADIWQAAbxgHAAAAAAAAAAAAAGkAAAAAAAAAAAAAAABpAAAAAAAAAAAAAAAAaQAA
AAAAAAAAAAAAAGkAAAAAAAAAAAAAAABpAAAAAAAAAAAAAAAAb1wEAAAAAAAAAAAAAGkAAAAAAAAA
AAAAAABpAAAAAAAAAAAAAAAAaQAAAAAAAAAAAAAAAGkAAAAAAAAAAAAAAABpAAAAAAAAAAAAAAAA
AAAGAAAWJAFJZgEAAAAAjwAAFiQBFyQBSWYBAAAAApZsAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAA
BAEAAAjWXAAElP8nCboSThziJQAGkwkAAAAAAAAAAAAAAAAAAAAAAAaTCQAAAAAAAAAAAAAAAAAA
AAAABpQJAAAAAAAAAAAAAAAAAAAAAAAGlAkAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wQBAAAAAAD/
BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAa1hAAAAD/AAAA/wAAAP8A
AAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8A
AAD/NNYGAAEKA2wAYfYDAAAADBJXAAAmVwAAOlcAAJxXAACdVwAAqVcAAKpXAACrVwAAulcAALtX
AAC8VwAA+FcAAPpXAAD8VwAA/VcAACpYAABXWAAAsFgAALJYAAC3WAAAvFgAAL1YAADVWAAA11gA
AONYAADkWAAA5VgAAPNYAAD4WAAA/VgAADdZAAA6WQAAPVkAAMdZAADJWQAAzlkAANNZAADUWQAA
51kAAOlZAAD1WQAA9lkAAPdZAAAGWgAACVoAAAxaAABGWgAAS1oAAFBaAADZWgAA21oAAOFaAAD1
WgAA9loAAAJbAAADWwAAUlsAAPLl3gDe0cTexNHe0cTe0cTeAL22AN4A3qmc3qmc3pyp3gC9tgDe
AN6pnN6cqd6pnN4Ato+2j5yPAAAZAQiBBEgEAAVoeERVRkNKEgBPSgMAUUoDABkBCIEESAQABWiF
RFVGQ0oSAE9KAwBRSgMAGQAIgUNKEgBPSgMAUUoDAGNIBABkaIVEVUYNAQiBBEgEAAVoeERVRg0A
CIFjSAQAZGh4RFVGGQEIgQRIBAAFaHlEVUZDShIAT0oDAFFKAwAZAAiBQ0oSAE9KAwBRSgMAY0gE
AGRoeURVRgxDShIAT0oDAFFKAwAAGQEIgQRIBAAFaHpEVUZDShIAT0oDAFFKAwAZAAiBQ0oSAE9K
AwBRSgMAY0gEAGRoekRVRgA4yFkAAMlZAADUWQAA6FkAAOlZAAD4WQAA2loAANtaAADhWgAA9VoA
APZaAABvSAQAAAAAAAAAAAAAaQAAAAAAAAAAAAAAAGkAAAAAAAAAAAAAAABpAAAAAAAAAAAAAAAA
aQAAAAAAAAAAAAAAAGkAAAAAAAAAAAAAAABvEAQAAAAAAAAAAAAAaQAAAAAAAAAAAAAAAGkAAAAA
AAAAAAAAAABpAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
BgAAFiQBSWYBAAAAAI8AABYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQB
AAAI1lwABJT/Jwm6Ek4c4iUABpMJAAAAAAAAAAAAAAAAAAAAAAAGkwkAAAAAAAAAAAAAAAAAAAAA
AAaUCQAAAAAAAAAAAAAAAAAAAAAABpQJAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8EAQAAAAAA/wQB
AAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2AQAAGtYQAAAA/wAAAP8AAAD/AAAA
/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA
/zTWBgABCgNsAGH2AwAAAAr2WgAABFsAAN5bAADfWwAAtgAAAAAAAAAAAAAAALAAAAAAAAAAAAAA
AAAg0AcAAAAAAAAAAAAAAAAAAAAAAAAAAI8AABYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQB
AAAEAQAABAEAAAQBAAAI1lwABJT/Jwm6Ek4c4iUABpMJAAAAAAAAAAAAAAAAAAAAAAAGkwkAAAAA
AAAAAAAAAAAAAAAAAAaUCQAAAAAAAAAAAAAAAAAAAAAABpQJAAAAAAAAAAAAAAAAAAAAABPWMAAA
AP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2AQAAGtYQAAAA
/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA
/wAAAP8AAAD/AAAA/zTWBgABCgNsAGH2AwAABgAAFiQBSWYBAAAASQAAFiQBQyQBRcaAAAAEAHhE
VUYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAABJZgEAAAAAA1JbAABUWwAA3lsAAN9bAADlWwAA+FsAAPlbAAAFXAAAGVwAAC1cAACP
XAAAkFwAAJxcAACdXAAAnlwAAO1cAAAaXQAAR10AAFddAACDXQAAr10AAMJdAADIXQAA0V0AANNd
AADVXQAA110AANhdAADaXQAA3F0AAN1dAAD+XQAA/10AAAFeAAAQXgAAFF4AABheAABRXgAAVl4A
AFteAACWXgAAwl4AAO5eAAAKXwAALV8AADJfAADy5d4A1wDXyr3XANfKvdfKvdewo9ew1wCclQCc
lQDXyr3XiHvXe4jXsKPXAHQAAAANAAiBY0gEAGRoh0RVRhkACIFDShIAT0oDAFFKAwBjSAQAZGiR
RFVGGQEIgQRIBAAFaJFEVUZDShIAT0oDAFFKAwANAQiBBEgEAAVohkRVRg0ACIFjSAQAZGiGRFVG
GQEIgQRIBAAFaIlEVUZDShIAT0oDAFFKAwAZAAiBQ0oSAE9KAwBRSgMAY0gEAGRoiURVRhkBCIEE
SAQABWiGRFVGQ0oSAE9KAwBRSgMAGQAIgUNKEgBPSgMAUUoDAGNIBABkaIZEVUYMQ0oSAE9KAwBR
SgMAAA0BCIEESAQABWh4RFVGGQEIgQRIBAAFaHhEVUZDShIAT0oDAFFKAwAZAQiBBEgEAAVohURV
RkNKEgBPSgMAUUoDAAAt31sAAOVbAAD5WwAAkFwAAJ9cAADSXQAA010AAN1dAADxXQAA8l0AAAJe
AAALXwAADF8AAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA
AAAAAAD5AAAAAAAAAAAAAAAAaeQEAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA
+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAAaQAAAAAAAAAAAAAAAAAAAI8A
ABYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1lwABJT/Jwm6Ek4c
4iUABpMJAAAAAAAAAAAAAAAAAAAAAAAGkwkAAAAAAAAAAAAAAAAAAAAAAAaUCQAAAAAAAAAAAAAA
AAAAAAAABpQJAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8E
AQAAAAAA/wQBAAAAAAD/BAEAABT2AQAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA
/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABCgNsAGH2AwAA
BgAAFiQBSWYBAAAAAAwMXwAADV8AANRfAADVXwAAr2AAALBgAAA/YQAAQGEAAO5hAADvYQAA8GEA
AFxjAABdYwAAXmMAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAA
AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAC2AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAERAABEAABDJAFFxoAAAAQAlERV
RgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAABAAAADTJfAAA3XwAAPl8AAEJfAABGXwAAsV8AALZfAAC7XwAA3l8AAONfAADoXwAA
7F8AAPBfAAD3XwAA+V8AAPtfAAB9YAAAgmAAAIdgAADLYAAA0GAAANVgAADgYAAA4mAAAORgAAAe
YQAAPmEAAO1hAADwYQAA8WEAAB1iAAAkYgAAM2IAAD5iAABHYgAASmIAAFViAACBYgAAiWIAAJhi
AACrYgAA5WIAAO5iAAD4YgAAXmMAAPgA+PEA8fgA6uMA6gDq4wDq4wDq4wDx+ADc1QDOAMe+xwC3
sACpoKkAmZIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAANAQiBBEgBAAVoWUNVRg0ACIFjSAEAZGhZQ1VGEAAIgTYIgWNI
AgBkaPlCVUYADQAIgWNIAgBkaPlCVUYNAQiBBEgCAAVo+EJVRg0ACIFjSAIAZGj4QlVGEAEIgQRI
AgAFaPlCVUY2CIEADQEIgQRIAgAFaPlCVUYNA2oAAAAAMEoSAFUIAQ0BCIEESAQABWiURFVGDQEI
gQRIAQAFaFpDVUYNAQiBBEgEAAVoiERVRg0ACIFjSAQAZGiIRFVGDQAIgWNIBABkaIdEVUYNAQiB
BEgEAAVoh0RVRgAsIAAxkGgBH7DQLyCw4D0hsC0FIrAtBSOQ8AMkkPADJbAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAUABMACgABAGkADwADAAAAAAAAAAAAOAAAQPH/AgA4AAwABgBOAG8AcgBtAGEA
bAAAAAIAAAAYAENKGABfSAEEYUoYAG1ICQRzSAkEdEgJBDYAAUABAAIANgAMAAkASABlAGEAZABp
AG4AZwAgADEAAAAOAAEAAyQBBiQBQCYAYSQBBABDShwAMgACQAEAAgAyAAwACQBIAGUAYQBkAGkA
bgBnACAAMgAAAAgAAgAGJAFAJgEGADYIgV0IgTgAA0ABAAIAOAAMAAkASABlAGEAZABpAG4AZwAg
ADMAAAAOAAMAAyQBBiQBQCYCYSQBBgA2CIFdCIEAAAAAAAAAAAAAAAA8AEFA8v+hADwADAAWAEQA
ZQBmAGEAdQBsAHQAIABQAGEAcgBhAGcAcgBhAHAAaAAgAEYAbwBuAHQAAAAAAAAAAAAAAAAAKAA+
QAEA8gAoAAwABQBUAGkAdABsAGUAAAAIAA8AAyQBYSQBBABDShwAIgBXQKIAAQEiAAwABgBTAHQA
cgBvAG4AZwAAAAYANQgBXAgBNgAdQAEAEgE2AAwADQBGAG8AbwB0AG4AbwB0AGUAIABUAGUAeAB0
AAAAAgARAAgAQ0oUAGFKFAA4ACZAogAhATgADAASAEYAbwBvAHQAbgBvAHQAZQAgAFIAZQBmAGUA
cgBlAG4AYwBlAAAAAwBIKgEAOQUAAF5fAAABAAAAAABsAQAAbwEAAAAAAABeXwAABgAAygAABQD/
////AAAAAAwAAAANAAAAHQEAAB4BAACLAQAAjAEAAJIBAACTAQAANQIAADYCAADYAgAA2QIAADsF
AAA8BQAAjwUAAJAFAAA/BwAAQAcAAMsJAADMCQAAQQoAAEIKAADzCwAA9AsAAGkMAABqDAAAqQwA
AKoMAAC4DAAAuQwAAIUOAACGDgAA8w8AAPQPAAAKEQAACxEAANsSAADcEgAAIxMAACQTAADvFAAA
8RQAAAAWAAABFgAAQxYAAEQWAAAKFwAACxcAAFEXAABSFwAA7xcAAF4YAABfGAAAtRgAALYYAAA5
GQAAOhkAAGEZAABRGgAA0xoAADobAAByGwAAshsAALMbAADyGwAA8xsAAEAcAABBHAAAAh0AAAMd
AACdHQAAnh0AABseAAAcHgAAZx4AAMMeAAA5HwAAnx8AAAAgAAB4IAAAVyEAAFghAADcIgAA3SIA
AN8jAADgIwAAEiQAABMkAABPJQAAUCUAAFElAACcJQAA3SUAAGcmAABoJgAAYycAAGQnAABlJwAA
ZicAAGonAADJJwAAyicAAOgnAAANKAAAMigAAFcoAAB8KAAAoSgAAMYoAADrKAAAESkAABUpAAAW
KQAAISkAACIpAABNKwAATisAAF8rAAC5KwAAASwAAHMsAAA7LQAAPC0AAE4tAABjLQAAbC0AAHYt
AAB3LQAAfS0AAI8tAAAHLgAAOi4AAJ0uAADlLgAA5i4AAOwuAAAfLwAAIC8AAFMvAAC2LwAAAjAA
AAMwAAAJMAAAPDAAAD0wAABwMAAA0zAAAB8xAAAgMQAAJjEAADoxAAC9MQAAyzEAAKIyAACjMgAA
qTIAAMIyAADDMgAA0TIAAMkzAADKMwAA0DMAAOQzAADlMwAA8zMAAMc0AADINAAAzjQAAOI0AABl
NQAAczUAAEc2AABINgAATjYAAGI2AABjNgAAcTYAAEA3AABBNwAAQjcAAEM3AABZNwAAWjcAAFs3
AABnNwAAaDcAAGg5AABpOQAAezkAANU5AAAdOgAAjzoAAFs7AABcOwAAXTsAAG87AACEOwAAjTsA
AJc7AACYOwAAnjsAALA7AAAoPAAAWzwAAL48AAAGPQAABz0AAA09AABAPQAAQT0AAHQ9AADXPQAA
Iz4AACQ+AAAqPgAAXT4AAF4+AACRPgAA9D4AAEA/AABBPwAARz8AAFs/AADePwAA7D8AAMNAAADE
QAAAykAAAONAAADkQAAA8kAAAMxBAADNQQAA00EAAOdBAADoQQAA9kEAANBCAADRQgAA10IAAOtC
AABuQwAAfEMAAFZEAABXRAAAXUQAAHFEAAByRAAAgEQAAFRFAABVRQAAVkUAAChGAAApRgAAIUcA
ACJHAABaRwAAW0cAAA5JAAAPSQAAbEsAAG1LAACTSwAA7UsAADpMAAC5TAAAgE0AAIFNAACTTQAA
qE0AALFNAAC7TQAAvE0AAMJNAADUTQAATE4AAH9OAAAjTwAAa08AAGxPAAB3TwAAqk8AAKtPAADj
TwAAOlAAAExQAACYUAAAmVAAAKRQAADXUAAA2FAAABBRAAC1UQAAAVIAAAJSAAAIUgAAO1IAADxS
AABvUgAA0lIAAOtSAADsUgAA8lIAAAZTAACdUwAArFMAALFUAACyVAAAvVQAANZUAADXVAAA5lQA
AMhVAADJVQAA1FUAAOhVAADpVQAA+FUAANpWAADbVgAA4VYAAPVWAAD2VgAABFcAAN5XAADfVwAA
5VcAAPlXAACQWAAAn1gAANJZAADTWQAA3VkAAPFZAADyWQAAAloAAAtbAAAMWwAADVsAANRbAADV
WwAAr1wAALBcAAA/XQAAQF0AAO5dAADvXQAAX18AAJgAAAAPMAAAAAAAAACAAAAAgJgAAAAAAAAA
AAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAA
AACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgCgAAAADAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACA
jAEAAJgAAAAAAAAAAAAAAACAjAEAAJgAAAAAAAAAAAAAAACAjAEAAJgAAAAAAAAAAAAAAACAjAEA
AJgAAAAAAAAAAAAAAACAjAEAAJgAAAAAAAAAAAAAAACAjAEAAJgAAAAAAAAAAAAAAACAjAEAAJgA
AAAAAAAAAAAAAACAjAEAAJgAAAAAAAAAAAAAAACAjAEAAJgAAAAAMAAAAAAAAACAjAEAAJgAAAAA
AAAAAAAAAACAjAEAAJgAAAAAMAAAAAAAAACAjAEAAJgAAAAAAAAAAAAAAACAjAEAAJgAAAAAMAAA
AAAAAACAjAEAAJgAAAAAAAAAAAAAAACAjAEAAJgAAAAAMAAAAAAAAACAjAEAAJgAAAAAAAAAAAAA
AACAjAEAAJgAAAAAAAAAAAAAAACAjAEAAJgAAAAAAAAAAAAAAACAjAEAAJgAAAAAAAAAAAAAAACA
jAEAAJgAAAAAAAAAAAAAAACAjAEAAAgAAAABAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAqgwA
AJgAAAAAMAAAAAAAAACAqgwAAJgAAAAAAAAAAAAAAACAqgwAAJgAAAAAMAAAAAAAAACAqgwAAJgA
AAAAAAAAAAAAAACAqgwAAJgAAAAAMAAAAAAAAACAqgwAAJgAAAAAAAAAAAAAAACAqgwAAJgAAAAA
MAAAAAAAAACAqgwAAJgAAAAAAAAAAAAAAACAqgwAAAgAAAABMAAAAAAAAACAAAAAgJgAAAAAAAAA
AAAAAACA3BIAAJgAAAAAMAAAAAAAAACA3BIAAJgAAAAAMAAAAAAAAACA3BIAAJgAAAAAMAAAAAAA
AACA3BIAAJgAAAAAMAAAAAAAAACA3BIAABgAAAACMAAAAAAAAACA3BIAAJgAAAAAAAAAAAAAAACA
ARYAAJgAAAAAMAAAAAAAAACAARYAAJgAAAAAMAAAAAAAAACAARYAAJgAAAAAMAAAAAAAAACAARYA
AJgAAAAAAAAAAAAAAACAARYAAJgAASAAAAAAAAAAAACAARYAAJgAASAAAAEAAAAAAACAARYAAJgA
AAAAAAAAAAAAAACAARYAAJgAAAAAMAAAAAAAAACAARYAAJgAAAAAAAAAAAAAAACAARYAAJgAAAAA
MAAAAAAAAACAARYAAJgAAAAAAAAAAAAAAACAARYAAJgABCAAAAAAAAAAAACAARYAAJgBBCAAMAAA
AAA6GQAAARYAAJgBBCAAMAEAAAA6GQAAARYAAJgABCAAMAEAAAAAAACAARYAAJgBBCAAMAAAAADT
GgAAARYAAJgBBCAAMAEAAADTGgAAARYAAJgAAAAAAAAAAAAAAACAARYAAJgAAAAAMAAAAAAAAACA
ARYAAJgAAAAAAAAAAAAAAACAARYAAJgAAAAAMAAAAAAAAACAARYAAJgAAAAAAAAAAAAAAACAARYA
AJgAAAAAMAAAAAAAAACAARYAAJgAAAAAAAAAAAAAAACAARYAAJgAAAAAAAAAAAAAAACAARYAAJgA
AAAAAAAAAAAAAACAARYAAJgAAAAAMAAAAAAAAACAARYAAJgAAAAAAAAAAAAAAACAARYAAJgAAAAA
AAAAAAAAAACAARYAAJgAAAAAMAAAAAAAAACAARYAAJgAAiAAAAAAAAAAAACAARYAAJgAAiAAMAEA
AAAAAACAARYAAJgAAAAAMAAAAAAAAACAARYAAJgAAyAAMAAAAAAAAACAARYAAJgAAyAAMAEAAAAA
AACAARYAAJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACA
AAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgCgAAAADAAAAAAAAAACAAAAA
gJgAAAAAAAAAAAAAAACAuB4AAJgAAAAAMAAAAAAAAACAAAAAgJoAAAAAAAAAAAAAAACAuB4AAJgA
AAAAMAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAuB4AAJgAAAAAAAAAAAAAAACAuB4AAJgAAAAA
MAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAA
AAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAA
AACAAAAAgJoAAAAAMAAAAAAAAACAAAAAgJoAAAAAMAAAAAAAAACAAAAAgJoAAAAAMAAAAAAAAACA
AAAAgJoAAAAAMAAAAAAAAACAAAAAgJoAAAAAMAAAAAAAAACAAAAAgJoAAAAAMAAAAAAAAACAAAAA
gJoAAAAAMAAAAAAAAACAAAAAgJoAAAAAMAAAAAAAAACAAAAAgJoAAAAAMAAAAAAAAACAAAAAgJoA
AAAAMAAAAAAAAACAAAAAgJoAAAAAMAAAAAAAAACAAAAAgJoAAAAAMAAAAAAAAACAAAAAgJoAAAAA
AAAAAAAAAACAuB4AAJgAAAAAAAAAAAAAAACAuB4AAJgAAAAAAAAAAAAAAACAuB4AAJgAAAAAAAAA
AAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAA
AACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACA
AAAAgJgAAAAAAAAAAAAAAACAAAAAgKkAAAAAAAAAAAAAAACAAAAAgKkAAAAAAAAAAAAAAACAAAAA
gKkAAAAAAAAAAAAAAACAAAAAgKkAAAAAAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgKkA
AAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKtAAAAAMAAAAAAAAACAAAAAgKsAAAAA
MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAA
AAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAA
AACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACA
AAAAgJkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA
gKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkA
AAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAA
MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKsAAAAAMAAA
AAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAA
AACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKsAAAAAMAAAAAAAAACA
AAAAgJkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA
gKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkA
AAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAA
MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAA
AAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAA
AACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACA
AAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAA
gJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJhA
AAAAAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJhAAAAAAAAAAAAAAACAAAAAgJgAAAAA
AAAAAAAAAACAAAAAgJhAAAAAAAAAAAAAAACAAAAAgJhAAAAAAAAAAAAAAACAAAAAgJgAAAAAAAAA
AAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJpAAAAAAAAAAAAAAACAAAAAgJgAAAAAMAAAAAAA
AACAAAAAgKlAAAAAAAAAAAAAAACAAAAAgKkAAAAAAAAAAAAAAACAAAAAgKlAAAAAAAAAAAAAAACA
AAAAgKlAAAAAAAAAAAAAAACAAAAAgJ4AAAAAAAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA
gKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkA
AAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKkAAAAA
MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAA
AAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAA
AACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACA
AAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA
gJkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkA
AAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKsAAAAAMAAAAAAAAACAAAAAgJkAAAAA
MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAA
AAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAA
AACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACA
AAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAA
gKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkA
AAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKkAAAAA
MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAA
AAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAA
AACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACA
AAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAA
gJgAAAAAAAAAAAAAAACAAAAAgJhAAAAAAAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJhA
AAAAAAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJhAAAAAAAAAAAAAAACAAAAAgJgAAAAA
MAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJhAAAAAAAAA
AAAAAACAAAAAgKlAAAAAAAAAAAAAAACAAAAAgKkAAAAAAAAAAAAAAACAAAAAgKlAAAAAAAAAAAAA
AACAAAAAgKlAAAAAAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACA
AAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA
gKsAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKkA
AAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAA
MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAA
AAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAA
AACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACA
AAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA
gKsAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKtAAAAAMAAAAAAAAACAAAAAgKtA
AAAAMAAAAAAAAACAAAAAgKsAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKkAAAAA
MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKsAAAAAMAAAAAAAAACAAAAAgKsAAAAAMAAA
AAAAAACAAAAAgKsAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAA
AACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKsAAAAAMAAAAAAAAACA
AAAAgKsAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA
gKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKsAAAAAMAAAAAAAAACAAAAAgKsA
AAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAA
MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKsAAAAAMAAA
AAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAA
AACAAAAAgKtAAAAAMAAAAAAAAACAAAAAgKtAAAAAMAAAAAAAAACAAAAAgKtAAAAAMAAAAAAAAACA
AAAAgJlAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA
gKkAAAAAMAAAAAAAAACAAAAAgKsAAAAAMAAAAAAAAACAAAAAgKsAAAAAMAAAAAAAAACAAAAAgJkA
AAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAA
AAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAMAAA
AAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJhAAAAAAAAAAAAA
AACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgAAEAABGDwAALhIAAE4UAAATGAAAihsAAAcfAAB+JAAA
+CgAAPkwAADiOAAAwkQAAGpQAABxUwAAElcAAFJbAAAyXwAAXmMAADIAAAA2AAAANwAAADgAAAA5
AAAAOwAAAD4AAABCAAAAQwAAAEcAAABNAAAAUgAAAFcAAABZAAAAXgAAAGEAAABkAAAAAAQAAMwN
AADvGAAA7xsAAGEdAAA6HwAAGyIAAAAkAABPKQAAZyoAAGorAABzMAAAOjIAADw0AACpNgAAzjgA
AEE7AACXPwAAdEEAAFtDAADnRQAAcUgAAChKAABbSwAAu1EAAONTAACYVAAAPFYAAOtWAADIWQAA
9loAAN9bAAAMXwAAXmMAADMAAAA1AAAAOgAAADwAAAA9AAAAPwAAAEAAAABBAAAARAAAAEUAAABG
AAAASAAAAEkAAABKAAAASwAAAEwAAABOAAAATwAAAFAAAABRAAAAUwAAAFQAAABVAAAAVgAAAFgA
AABaAAAAWwAAAFwAAABdAAAAXwAAAGAAAABiAAAAYwAAAAAEAABdYwAANAAAAAAAAAAHAAAACwAA
AGkHAAByBwAAdAoAAH0KAADeDAAA4gwAAMwNAADQDQAA4w0AAOcNAAAfEAAAIxAAAFgQAABcEAAA
LBEAADARAAAAGQAACRkAAJMZAACiGQAATh0AAE8dAADsHgAA+R4AAFUfAABiHwAAUiAAAF8gAADh
IAAA7iAAAOMiAADsIgAAWCQAAFwkAACeJQAAoCUAANMlAADaJQAA7yUAAPYlAAARJwAAJScAAJcq
AACgKgAAjy0AAJgtAACvLQAAuS0AAM8tAADZLQAA7y0AAP4tAAAHLgAAEC4AACcuAAAxLgAAOi4A
AEQuAACLLgAAmC4AAJ0uAACsLgAAIC8AACkvAABALwAASi8AAFMvAABdLwAApC8AALEvAAC2LwAA
xS8AAD0wAABGMAAAXTAAAGcwAABwMAAAejAAAMEwAADOMAAA0zAAAOIwAAA6MQAAQzEAAFoxAABk
MQAAejEAAIQxAACaMQAAqTEAAL0xAADGMQAAyzEAANUxAAAKMgAAFDIAAEgyAABVMgAAhDIAAJMy
AADDMgAAzDIAANEyAADbMgAADzMAABkzAABMMwAAWTMAAIgzAACXMwAA5TMAAO4zAADzMwAA/TMA
ADE0AAA7NAAAbjQAAHs0AACqNAAAuTQAAOI0AADrNAAAAjUAAAw1AAAiNQAALDUAAEI1AABRNQAA
ZTUAAG41AABzNQAAfTUAALE1AAC7NQAA7jUAAPs1AAAqNgAAOTYAAGM2AABsNgAAcTYAAHs2AACv
NgAAuTYAAOw2AAD5NgAAKDcAADc3AACJOAAAkjgAALA7AAC5OwAA0DsAANo7AADwOwAA+jsAABA8
AAAfPAAAKDwAADE8AABIPAAAUjwAAFs8AABlPAAArDwAALk8AAC+PAAAzTwAAEE9AABKPQAAYT0A
AGs9AAB0PQAAfj0AAMU9AADSPQAA1z0AAOY9AABePgAAZz4AAH4+AACIPgAAkT4AAJs+AADiPgAA
7z4AAPQ+AAADPwAAWz8AAGQ/AAB7PwAAhT8AAJs/AAClPwAAuz8AAMo/AADePwAA5z8AAOw/AAD2
PwAAK0AAADVAAABpQAAAdkAAAKVAAAC0QAAA5EAAAO1AAADyQAAA/EAAADBBAAA6QQAAbUEAAHpB
AACpQQAAuEEAAOhBAADxQQAA9kEAAABCAAA0QgAAPkIAAHFCAAB+QgAArUIAALxCAADrQgAA9EIA
AAtDAAAVQwAAK0MAADVDAABLQwAAWkMAAG5DAAB3QwAAfEMAAIZDAAC6QwAAxEMAAPdDAAAERAAA
M0QAAEJEAAByRAAAe0QAAIBEAACKRAAAvkQAAMhEAAD7RAAACEUAADdFAABGRQAAakUAAG5FAAAL
RgAAD0YAAGpJAAB1SQAAekkAAIVJAACNSgAAlkoAANRNAADdTQAA9E0AAP5NAAAUTgAAHk4AADRO
AABDTgAATE4AAFVOAABsTgAAdk4AAH9OAACJTgAAEU8AAB5PAAAjTwAAMk8AAKtPAAC0TwAAy08A
ANVPAADjTwAA7U8AADpQAABHUAAATFAAAFtQAADYUAAA4VAAAPhQAAACUQAAEFEAABpRAACjUQAA
sFEAALVRAADEUQAAPFIAAEVSAABcUgAAZlIAAG9SAAB5UgAAwFIAAM1SAADSUgAA4VIAAAZTAAAP
UwAAOlMAAERTAABaUwAAZFMAAHpTAACJUwAAnVMAAKZTAACsUwAAtlMAAOtTAAD1UwAAV1QAAGRU
AACTVAAAolQAANdUAADgVAAA5lQAAPBUAAApVQAAM1UAAGlVAAB2VQAApVUAALRVAADpVQAA8lUA
APhVAAACVgAAOVYAAENWAAB7VgAAiFYAALdWAADGVgAA9lYAAP9WAAAEVwAADlcAAEJXAABMVwAA
f1cAAIxXAAC7VwAAylcAAPlXAAACWAAALVgAADdYAABNWAAAV1gAAG1YAAB8WAAAkFgAAJlYAACf
WAAAqVgAAN1YAADnWAAAR1kAAFRZAACvWQAAvlkAAPJZAAD7WQAAAloAAAxaAABEWgAATloAAIZa
AACTWgAA7loAAP1aAADDWwAAzVsAAHNdAAB3XQAA8F0AAF9fAAAHABwABwAcAAcAHAAHABwABwAc
AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA
BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH
ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc
AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA
BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH
ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc
AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA
BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH
ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc
AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA
BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcABwAAAAAAsiwAALIsAACzLAAAtCwAAL4sAAC+
LAAAvywAAMAsAADZMQAA2jEAANsxAADbMQAAGDIAABkyAAAaMgAAGjIAAM46AADOOgAAzzoAANA6
AADaOgAA2joAANs6AADcOgAA+j8AAPs/AAA5QAAAOkAAADtAAAA7QAAAVkUAACJHAABySwAAfksA
AIZLAACHSwAAiksAAJFLAAAzTAAAOEwAAGpMAABsTAAAbUwAAG1MAACgTAAAoEwAAKFMAACiTAAA
pkwAAKhMAACpTAAAqUwAALJMAAC3TAAA/EwAAAJNAAALTQAAEE0AAFBNAABQTQAAVE0AAFlNAAAI
UgAAOlIAABBaAAAUWgAAFVoAABVaAAAWWgAAFloAABdaAAAXWgAAGFoAABhaAABWWgAAW1oAAMJa
AADDWgAAPl0AAO1dAADvXQAA8F0AAFxfAABfXwAAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAE
AAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQA
AwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAAD
AAQAAwAEAAMABAADAAQAAwAEAAMABwAHAAcA//8UAAAADABSAHUAcwBzACAASABvAHUAcwBsAGUA
eQBMAEMAOgBcAHAAcgBvAGcAcgBhAG0AIABmAGkAbABlAHMAXABxAHUAYQBsAGMAbwBtAG0AXABl
AHUAZABvAHIAYQBcAGEAdAB0AGEAYwBoAFwAQQBsAGcAbwByAGkAdABoAG0AIABmAG8AcgAgAEMA
bwBuAHMAdAByAHUAYwB0AGkAbgBnACAAQwBSAEwAcwAxAC4AZABvAGMADABSAHUAcwBzACAASABv
AHUAcwBsAGUAeQBMAEMAOgBcAHAAcgBvAGcAcgBhAG0AIABmAGkAbABlAHMAXABxAHUAYQBsAGMA
bwBtAG0AXABlAHUAZABvAHIAYQBcAGEAdAB0AGEAYwBoAFwAQQBsAGcAbwByAGkAdABoAG0AIABm
AG8AcgAgAEMAbwBuAHMAdAByAHUAYwB0AGkAbgBnACAAQwBSAEwAcwAxAC4AZABvAGMACABUAGkA
bQAgAFAAbwBsAGsALABBADoAXABBAGwAZwBvAHIAaQB0AGgAbQAgAGYAbwByACAAQwBvAG4AcwB0
AHIAdQBjAHQAaQBuAGcAIABDAFIATABzACAAZgBpAG4AYQBsAC4AZABvAGMAFABWAEEATABVAEUA
RAAgAFMATwBOAFkAIABDAFUAUwBUAE8ATQBFAFIAaQBDADoAXABXAEkATgBEAE8AVwBTAFwAQQBw
AHAAbABpAGMAYQB0AGkAbwBuACAARABhAHQAYQBcAE0AaQBjAHIAbwBzAG8AZgB0AFwAVwBvAHIA
ZABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAEEAbABnAG8AcgBp
AHQAaABtACAAZgBvAHIAIABDAG8AbgBzAHQAcgB1AGMAdABpAG4AZwAgAEMAUgBMAHMAIABmAGkA
bgBhAGwALgBhAHMAZAAUAFYAQQBMAFUARQBEACAAUwBPAE4AWQAgAEMAVQBTAFQATwBNAEUAUgA8
AEMAOgBcAFcASQBOAEQATwBXAFMAXABEAGUAcwBrAHQAbwBwAFwAQQBsAGcAbwByAGkAdABoAG0A
IABmAG8AcgAgAEMAbwBuAHMAdAByAHUAYwB0AGkAbgBnACAAQwBSAEwAcwAgAGYAaQBuAGEAbAAu
AGQAbwBjABQAVgBBAEwAVQBFAEQAIABTAE8ATgBZACAAQwBVAFMAVABPAE0ARQBSADwAQwA6AFwA
VwBJAE4ARABPAFcAUwBcAEQAZQBzAGsAdABvAHAAXABBAGwAZwBvAHIAaQB0AGgAbQAgAGYAbwBy
ACAAQwBvAG4AcwB0AHIAdQBjAHQAaQBuAGcAIABDAFIATABzACAAZgBpAG4AYQBsAC4AZABvAGMA
FABWAEEATABVAEUARAAgAFMATwBOAFkAIABDAFUAUwBUAE8ATQBFAFIAPABDADoAXABXAEkATgBE
AE8AVwBTAFwARABlAHMAawB0AG8AcABcAEEAbABnAG8AcgBpAHQAaABtACAAZgBvAHIAIABDAG8A
bgBzAHQAcgB1AGMAdABpAG4AZwAgAEMAUgBMAHMAIABmAGkAbgBhAGwALgBkAG8AYwAUAFYAQQBM
AFUARQBEACAAUwBPAE4AWQAgAEMAVQBTAFQATwBNAEUAUgA8AEMAOgBcAFcASQBOAEQATwBXAFMA
XABEAGUAcwBrAHQAbwBwAFwAQQBsAGcAbwByAGkAdABoAG0AIABmAG8AcgAgAEMAbwBuAHMAdABy
AHUAYwB0AGkAbgBnACAAQwBSAEwAcwAgAGYAaQBuAGEAbAAuAGQAbwBjAAgAVABpAG0AIABQAG8A
bABrAGkAQwA6AFwAVwBJAE4ARABPAFcAUwBcAEEAcABwAGwAaQBjAGEAdABpAG8AbgAgAEQAYQB0
AGEAXABNAGkAYwByAG8AcwBvAGYAdABcAFcAbwByAGQAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIA
eQAgAHMAYQB2AGUAIABvAGYAIABBAGwAZwBvAHIAaQB0AGgAbQAgAGYAbwByACAAQwBvAG4AcwB0
AHIAdQBjAHQAaQBuAGcAIABDAFIATABzACAAZgBpAG4AYQBsAC4AYQBzAGQACABUAGkAbQAgAFAA
bwBsAGsAIgBDADoAXABXAEkATgBEAE8AVwBTAFwARABlAHMAawB0AG8AcABcAFAASwBJAFgAIABk
AGUAbAB0AGEAcwAuAGQAbwBjAAQA1WoHBsaTbN7/D/8P/w//D/8P/w//D/8P/w8AAPgXsy/Gk2ze
/w//D/8P/w//D/8P/w//D/8PEADgFKVJ6ALyNf8P/w//D/8P/w//D/8P/w//DxAAugbSZY7tlGH/
D/8P/w//D/8P/w//D/8P/w8QAAEAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAMYAAAPhNACEYSY/hXG
BQAB0AIGXoTQAmCEmP5vKAADACgAAAApAAEAAAAEAAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhKAF
EYSY/hXGBQABoAUGXoSgBWCEmP4CAAEALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4Rw
CBGETP8VxgUAAXAIBl6EcAhghEz/AgACAC4AAQAAAACAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+E
QAsRhJj+FcYFAAFACwZehEALYISY/gIAAwAuAAEAAAAEgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAP
hBAOEYSY/hXGBQABEA4GXoQQDmCEmP4CAAQALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAAGAAA
D4TgEBGETP8VxgUAAeAQBl6E4BBghEz/AgAFAC4AAQAAAACAAQAAAAAAAAAAAAAAAAAAAAAAABgA
AA+EsBMRhJj+FcYFAAGwEwZehLATYISY/gIABgAuAAEAAAAEgAEAAAAAAAAAAAAAAAAAAAAAAAAY
AAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP4CAAcALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAA
GAAAD4RQGRGETP8VxgUAAVAZBl6EUBlghEz/AgAIAC4AAQAAAAAAAgAAAAAAAAAAAAAAAAAAAAAA
AxgAAA+E0AIRhJj+FcYFAAHQAgZehNACYISY/m8oAAMAKAAAACkAAQAAAASAAQAAAAAAAAAAAAAA
AAAAAAAAABgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/gIAAQAuAAEAAAACggEAAAAAAAAAAAAA
AAAAAAAAAAAYAAAPhHAIEYRM/xXGBQABcAgGXoRwCGCETP8CAAIALgABAAAAAIABAAAAAAAAAAAA
AAAAAAAAAAAAGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+AgADAC4AAQAAAASAAQAAAAAAAAAA
AAAAAAAAAAAAABgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/gIABAAuAAEAAAACggEAAAAAAAAA
AAAAAAAAAAAAAAAYAAAPhOAQEYRM/xXGBQAB4BAGXoTgEGCETP8CAAUALgABAAAAAIABAAAAAAAA
AAAAAAAAAAAAAAAAGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+AgAGAC4AAQAAAASAAQAAAAAA
AAAAAAAAAAAAAAAAABgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/gIABwAuAAEAAAACggEAAAAA
AAAAAAAAAAAAAAAAAAAYAAAPhFAZEYRM/xXGBQABUBkGXoRQGWCETP8CAAgALgABAAAABAACAAAA
AAAAAAAAAAAAAAAAAAADGAAAD4TQAhGEmP4VxgUAAdACBl6E0AJghJj+bygAAwAoAAAAKQABAAAA
BIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+AgABAC4AAQAA
AAKCAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EcAgRhEz/FcYFAAFwCAZehHAIYIRM/wIAAgAuAAEA
AAAAgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP4CAAMALgAB
AAAABIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+AgAEAC4A
AQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+E4BARhEz/FcYFAAHgEAZehOAQYIRM/wIABQAu
AAEAAAAAgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP4CAAYA
LgABAAAABIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4SAFhGEmP4VxgUAAYAWBl6EgBZghJj+AgAH
AC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EUBkRhEz/FcYFAAFQGQZehFAZYIRM/wIA
CAAuAAEAAAAEEAIAAAAAAAAAAABoAQAAAAAAAAMYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5v
KAADACgAAAApAAEAAAAEEAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhKAFEYSY/hXGBQABoAUGXoSg
BWCEmP4CAAEALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4RwCBGETP8VxgUAAXAIBl6E
cAhghEz/AgACAC4AAQAAAACQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EQAsRhJj+FcYFAAFACwZe
hEALYISY/gIAAwAuAAEAAAAEkAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhBAOEYSY/hXGBQABEA4G
XoQQDmCEmP4CAAQALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4TgEBGETP8VxgUAAeAQ
Bl6E4BBghEz/AgAFAC4AAQAAAACQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EsBMRhJj+FcYFAAGw
EwZehLATYISY/gIABgAuAAEAAAAEkAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhIAWEYSY/hXGBQAB
gBYGXoSAFmCEmP4CAAcALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4RQGRGETP8VxgUA
AVAZBl6EUBlghEz/AgAIAC4ABAAAAPgXsy8AAAAAAAAAAAAAAADgFKVJAAAAAAAAAAAAAAAAugbS
ZQAAAAAAAAAAAAAAANVqBwYAAAAAAAAAAAAAAAD///////////////////////8EAAAAAAAAAAAA
AAD//wQAAAAAAAAAAAAAAAAAAAA7LQAAPC0AAE4tAABjLQAAbC0AAHYtAAB3LQAAfS0AAI8tAAAH
LgAA5S4AAOYuAADsLgAAHy8AACAvAAACMAAAAzAAAAkwAAA8MAAAPTAAAB8xAAAgMQAAJjEAADox
AAC9MQAAojIAAKMyAACpMgAAwjIAAMMyAADJMwAAyjMAANAzAADkMwAA5TMAAMc0AADINAAAzjQA
AOI0AABlNQAARzYAAEg2AABONgAAYjYAAGM2AABANwAAQTcAAFs7AABdOwAAbzsAAIQ7AACNOwAA
lzsAAJg7AACeOwAAsDsAACg8AAAGPQAABz0AAA09AABAPQAAQT0AACM+AAAkPgAAKj4AAF0+AABe
PgAAQD8AAEE/AABHPwAAWz8AAN4/AADDQAAAxEAAAMpAAADjQAAA5EAAAMxBAADNQQAA00EAAOdB
AADoQQAA0EIAANFCAADXQgAA60IAAG5DAABWRAAAV0QAAF1EAABxRAAAckQAAFRFAABVRQAAgE0A
AIFNAACTTQAAqE0AALFNAAC7TQAAvE0AAMJNAADUTQAATE4AAGtPAABsTwAAd08AAKpPAACrTwAA
mFAAAJlQAACkUAAA11AAANhQAAABUgAAAlIAAAhSAAA7UgAAPFIAAOtSAADsUgAA8lIAAAZTAACd
UwAAsVQAALJUAAC9VAAA1lQAANdUAADIVQAAyVUAANRVAADoVQAA6VUAANpWAADbVgAA4VYAAPVW
AAD2VgAA3lcAAN9XAADlVwAA+VcAAJBYAADSWQAA01kAAN1ZAADxWQAA8lkAAAtbAAAMWwAA710A
APBdAABcXwAAX18AAAAAAAABAAAACAAAAAIBAAACAQAAAgEAAAIBAAAeAQAAAgEAAAIBAAACAQAA
AgEAAB4BAAACAQAAAgEAAAIBAAACAQAAHgEAAAIBAAACAQAAAgEAAAIBAAAeAQAAAgEAAAIBAAAC
AQAAAgEAAB4BAAACAQAAAgEAAAIBAAACAQAAHgEAAAIBAAACAQAAAgEAAAIBAAAeAQAAAgEAAAIB
AAACAQAAAgEAAB4BAAACAQAAAgEAAAIBAAACAQAAFgEAAAEAAAAIAAAAAgEAAAIBAAACAQAAAgEA
AB4BAAACAQAAAgEAAAIBAAACAQAAHgEAAAIBAAACAQAAAgEAAAIBAAAeAQAAAgEAAAIBAAACAQAA
AgEAAB4BAAACAQAAAgEAAAIBAAACAQAAHgEAAAIBAAACAQAAAgEAAAIBAAAeAQAAAgEAAAIBAAAC
AQAAAgEAAB4BAAACAQAAAgEAAAIBAAACAQAAHgEAAAIBAAACAQAAAgEAAAIBAAAWAQAAAQAAAAgA
AAACAQAAAgEAAAIBAAACAQAAHgEAAAIBAAACAQAAAgEAAAIBAAAeAQAAAgEAAAIBAAACAQAAAgEA
AB4BAAACAQAAAgEAAAIBAAACAQAAHgEAAAIBAAACAQAAAgEAAAIBAAAeAQAAAgEAAAIBAAACAQAA
AgEAAB4BAAACAQAAAgEAAAIBAAACAQAAHgEAAAIBAAACAQAAAgEAAAIBAAAeAQAAAgEAAAIBAAAC
AQAAAgEAAB4BAAACAQAAAgEAAAIBAAACAQAAHgEAAAIBAAACAQAAAgEAAAIBAAAWAQAAAd0AAAAA
AAABAAAA/0APgAEAOlIAADpSAAAUnGQAAQABADpSAAAAAAEAOlIAACcJuhICEAAAAAAAAABeXwAA
YAAACABAAAD//wUAAAAHAFUAbgBrAG4AbwB3AG4ACABUAGkAbQAgAFAAbwBsAGsADABEAGEAdgBp
AGQAIABDAG8AbwBwAGUAcgAMAFIAdQBzAHMAIABIAG8AdQBzAGwAZQB5ABQAVgBBAEwAVQBFAEQA
IABTAE8ATgBZACAAQwBVAFMAVABPAE0ARQBSAP//BQAIAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAA
AAAAAAACAAAAAAAAAAAAAwAAAAAAAAAAAAQA//8FAAAAAAAAAAAAAAAAAP//AAACAP//AAAAAP//
AAACAP//AAAAAAQAAABHFpABAAACAgYDBQQFAgMEhzoAAAAAAAAAAAAAAAAAAP8AAAAAAAAAVABp
AG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAA
AAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzJpABAAACCwYEAgICAgIEhzoAAAAAAAAAAAAAAAAA
AP8AAAAAAAAAQQByAGkAYQBsAAAAPzWQAQAAAgcDCQICBQIEBIc6AAAAAAAAAAAAAAAAAAD/AAAA
AAAAAEMAbwB1AHIAaQBlAHIAIABOAGUAdwAAACIABABxiIwAAPDQAgAAaAEAAAAAnFNVhpxTVYZG
U1WGAgAiAAAAlg0AAHVNAAABACcAAAAEAAMQpQAAAAAAAAAAAAAAAQABAAAAAQAAAAAAAAAhAwDw
EAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtBfADeAC0AIKCEjAAABAAGQBkAAAAGQAAAB9f
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABXIQAAAAAAAAAAAAAA
AAAAAAAAAAAAAgAAAAAAAAAAAAAygxEA8BAA3wMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAD//xIAAAAAAAAAPwBBAGwAZwBvAHIAaQB0AGgAbQAgAGYAbwByACAAQwBvAG4AcwB0AHIAdQBj
AHQAaQBuAGcAIABDAFIATABzACAAZgByAG8AbQAgAGEAIABiAGEAcwBlACAAQwBSAEwAIABhAG4A
ZAAgAGEAIABkAGUAbAB0AGEAIABDAFIATAAAAAAAAAAIAFQAaQBtACAAUABvAGwAawAIAFQAaQBt
ACAAUABvAGwAawAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAoCAAAAAAAAAAAAAAAAAAAAAAAB
AAAA4IWf8vlPaBCrkQgAKyez2TAAAADAAQAAEgAAAAEAAACYAAAAAgAAAKAAAAADAAAA6AAAAAQA
AAD0AAAABQAAAAgBAAAGAAAAFAEAAAcAAAAgAQAACAAAADQBAAAJAAAASAEAABIAAABUAQAACgAA
AHABAAALAAAAfAEAAAwAAACIAQAADQAAAJQBAAAOAAAAoAEAAA8AAACoAQAAEAAAALABAAATAAAA
uAEAAAIAAADkBAAAHgAAAEAAAABBbGdvcml0aG0gZm9yIENvbnN0cnVjdGluZyBDUkxzIGZyb20g
YSBiYXNlIENSTCBhbmQgYSBkZWx0YSBDUkwAHgAAAAEAAAAAbGdvHgAAAAkAAABUaW0gUG9sawAg
Zm8eAAAAAQAAAABpbSAeAAAAAQAAAABpbSAeAAAACwAAAE5vcm1hbC5kb3QAbx4AAAAJAAAAVGlt
IFBvbGsAdABvHgAAAAIAAAAyAG0gHgAAABMAAABNaWNyb3NvZnQgV29yZCA5LjAAckAAAAAATO+/
BAAAAEAAAAAADIZ8c9nAAUAAAAAAeBLxftnAAUAAAAAAeBLxftnAAQMAAAABAAAAAwAAAJYNAAAD
AAAAdU0AAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQKAgAAAAAAAAAAAAAAAAAAAAAAAQAAAALVzdWc
LhsQk5cIACss+a4wAAAANAEAAAwAAAABAAAAaAAAAA8AAABwAAAABQAAAIgAAAAGAAAAkAAAABEA
AACYAAAAFwAAAKAAAAALAAAAqAAAABAAAACwAAAAEwAAALgAAAAWAAAAwAAAAA0AAADIAAAADAAA
ABQBAAACAAAA5AQAAB4AAAANAAAAQ1NEL0lUTC9OSVNUAABvAAMAAAClAAAAAwAAACcAAAADAAAA
H18AAAMAAADtDgkACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAAEAAAABB
bGdvcml0aG0gZm9yIENvbnN0cnVjdGluZyBDUkxzIGZyb20gYSBiYXNlIENSTCBhbmQgYSBkZWx0
YSBDUkwADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAAL
AAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkA
AAAaAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAA
ACgAAAApAAAAKgAAACsAAAAsAAAALQAAAC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQAAAA1AAAA
NgAAADcAAAA4AAAAOQAAADoAAAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABBAAAAQgAAAEMAAABE
AAAARQAAAEYAAABHAAAASAAAAEkAAABKAAAASwAAAEwAAABNAAAATgAAAE8AAABQAAAAUQAAAFIA
AABTAAAAVAAAAFUAAABWAAAAVwAAAFgAAABZAAAAWgAAAFsAAABcAAAAXQAAAF4AAABfAAAAYAAA
AGEAAABiAAAAYwAAAGQAAABlAAAA/v///2cAAABoAAAAaQAAAGoAAABrAAAAbAAAAG0AAABuAAAA
bwAAAHAAAABxAAAAcgAAAHMAAAB0AAAAdQAAAHYAAAB3AAAAeAAAAHkAAAB6AAAAewAAAHwAAAB9
AAAAfgAAAH8AAACAAAAAgQAAAIIAAACDAAAAhAAAAIUAAACGAAAAhwAAAIgAAACJAAAA/v///4sA
AACMAAAAjQAAAI4AAACPAAAAkAAAAJEAAAD+////kwAAAJQAAACVAAAAlgAAAJcAAACYAAAAmQAA
AP7////9/////f///50AAAD+/////v////7/////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAA
AAAAAAAAAACgoSoPf9nAAZ8AAACAAAAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIA////////////////AAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZgAAAKlGAAAAAAAAVwBvAHIAZABEAG8AYwB1
AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgEFAAAA
//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIsoAAAAAAAAF
AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAKAACAQIAAAAEAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AIoAAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0A
YQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAkgAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgEBAAAABgAAAP////8AAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAagAAAAAAAABPAGIAagBlAGMAdABQAG8A
bwBsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgABAP//////
/////////wAAAAAAAAAAAAAAAAAAAAAAAAAAoKEqD3/ZwAGgoSoPf9nAAQAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAQAAAP7/////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29mdCBXb3Jk
IERvY3VtZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAA==
--=====================_32329696==_--



Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA27082 for <[e-mail]>; Thu, 10 May 2001 13:15:28 -0700 (PDT)
Message-Id: <[e-mail]>
Received: from mfil.terminal (mfil@localhost) by roadblock.missi.ncsc.mil with SMTP id QAA27173 for <[e-mail]>; Thu, 10 May 2001 16:12:39 -0400 (EDT)
Received: from reject.missi.ncsc.mil (reject.missi.ncsc.mil [144.51.60.17]) by roadblock.missi.ncsc.mil with SMTP id QAA27168 for <[e-mail]>; Thu, 10 May 2001 16:12:36 -0400 (EDT)
Received: from 144.51.60.215 by reject.missi.ncsc.mil (InterScan E-Mail VirusWall NT); Thu, 10 May 2001 16:12:28 -0400 (Eastern Daylight Time)
Received: from missi.ncsc.mil (ara.missi.ncsc.mil [144.51.55.128]) by amx.missi.ncsc.mil with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JSFMBHKM; Thu, 10 May 2001 16:12:28 -0400
Sender: [e-mail]
Date: Thu, 10 May 2001 16:06:41 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: delta CRLs
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I agree with Russ, Tim, and David on **every single point** made in
this long note.

Dave



"Housley, Russ" wrote:
> 
> Denis:
> 
> Please excuse the half-done message from this morning.  My mailer and I had
> a disagreement...
> 
> Anyway, since I was not going to get the full message out before the end of
> the business day in France, I took the time to coordinate a response with
> Tim Polk and David Cooper.  This mail thread is quite long, so hopefully
> our coordination on the side will reduce the overall number of messages to
> the list and help to reach consensus faster.
> 
> Here goes ....  [ remainder snipped ]
> 



Only one editorial glitch:

>  >    An application that is wishing to take advantage of delta CRLs
>  >    for a given scope, MUST first find a base CRL for that scope,
>  >    i.e. a full CRL that that contains a freshestCRL extension
>  >    (a.k.a. a Delta CRL distribution point).
> 
> No. The relying party needs a full CRL (either one that has been downloaded
> from a repository or one that has been locally generated) against which the
> delta CRL of interest may be applied. There is no requirement that the full
> CRL be a base CRL.


  ... which was later corrected:
> 
> A delta CRL must include a BaseCRLNumber.
> The CRL specified by that BaseCRLNumber is by definition a base CRL.
> Of course, the referenced base CRL MUST be a full CRL.


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id LAA21891 for <[e-mail]>; Thu, 10 May 2001 11:48:11 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 10 May 2001 18:47:53 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA25362 for <[e-mail]>; Thu, 10 May 2001 14:48:12 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <JY8NWWV5>; Thu, 10 May 2001 14:48:11 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.11]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JY8NWWVT; Thu, 10 May 2001 14:47:53 -0400
From: "Housley, Russ" <[e-mail]>
To: Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 10 May 2001 14:42:50 -0400
Subject: RE: delta CRLs
In-Reply-To: <[e-mail]. com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Santosh:

Any CRL that does not include the deltaCRLIndicator extension is a full 
CRL.  I some delta CRL references it, then that full CRL is also a base CRL.

Russ

At 12:28 PM 5/10/2001 -0400, Santosh Chokhani wrote:

>Denis:
>
>I do not agree with you.  Any CRL that is not a delta CRL (i.e., 
>deltaCRLIndicator extension is absent), is a base CRL for some scope as 
>defined in CRLScope extension and/or the IDP extension.
>
>-----Original Message-----
>From: Denis Pinkas 
>[<mailto:[e-mail]>mailto:[e-mail]]
>Sent: Thursday, May 10, 2001 12:30 PM
>To: Carlin Covey; Sharon Boeyen
>Cc: [e-mail]
>Subject: Re: delta CRLs
>
>Carlin and Sharon (at the same time),
>
> > Denis,
>
> > Now I'm confused again (or still).
>
>:-)
>
> > I agree that there is a difference
> > between a base CRL and a full CRL.  However, my understanding was that 
> a CRL
> > is a "base CRL" with respect to some delta CRL only by virtue of having 
> been
> > so identified in that delta CRL.
>
>I believe that a base CRL must include the Freshest CRL extension (a.k.a.
>Delta CRL Distribution Point) defined in section 4.2.1.16. It indicates both
>that the service exists and where to fetch the information. It is a
>non-critical extension so that a base CRL may also be used as a full CL for
>relying parties not supporting delta CRLs.
>
> > According to the PKIX profile, this base CRL must be a full CRL
> > (complete for the intended scope).
> > I believe that X.509 does not require that a base CRL be a full CRL.
>
>You just say above: "According to the PKIX profile, this base CRL must be a
>full CRL (complete for the intended scope". So do you mean that X.509 and
>PKIX are taking different approaches ?
>
>Regards,
>
>Denis
>
> > Regards,
> >
> > Carlin
> >
> > ____________________________
> >
> > -  Carlin Covey
> >    Cylink Corporation
> >
> > -----Original Message-----
> > From: Denis Pinkas 
> [<mailto:[e-mail]>mailto:[e-mail]]
> > Sent: Thursday, May 10, 2001 1:19 AM
> > Cc: [e-mail]
> > Subject: Re: delta CRLs
> >
> > Tim, David, Russ, Santosh, Carlin, and many others ...
> >
> > There is difference between a base CRL and a full CRL : a base CRL MUST
> > include a freshestCRL extension (a.k.a. a Delta CRL distribution point),
> > whereas a full CRL may not include that extension. In other words, a base
> > CRL is a also a full CRL, but a full CRL is not necessarily a base CRL.
> >
> > At any time a CA may issue a full CRL, whether or not a base CRL has 
> already
> > been issued. This additional CRL SHOULD have nextUpdate equal to the
> > nextUpdate of the last issued full CRL. However, there is no guarantee 
> that
> > this additional CRL will ever be seen by the relying party (because there
> > will be two CRLs matching the thisUpdate and nextUpdate rule and if one is
> > deleted, this is not seen by a relying party).
> >
> > Due to the fact that CRLs numbers are strictly increasing, two CRLs 
> whether
> > they are a base CRL or delta CRL, CANNOT have the same CRL number. So a
> > delta CRL and a full CRL that cover the same scope and are issued at the
> > same time CANNOT have the same number. If a full CRL is issued, its CRL
> > number bears no relationship with the previous base CRL, if any. The only
> > relationship between the numbers is defined by the rule that CRLs numbers
> > are strictly increasing. As Santosh said : "the CRL number is unique
> > whether it is a base or a delta ".
> >
> > This is fairly important to be able to unambiguously (and thus uniquely)
> > refer to a CRL by only providing its CRL number.
> >
> > Besides the fact that a CRL issued later MUST have a higher CRL number, 
> full
> > CRLs and delta CRLs have independent numbering rules. As noticed by 
> Santosh,
> > " if the delta thisUpdate > base thisUpdate, delta CRL number > base CRL
> > number (for the same or no stream identifier).
> >
> > As Santosh said : "a check based on thisUpdate is more general and
> > preferred [to the use of CRL numbers]. "
> >
> > Related to the three rules mentioned by Russ :
> >
> > 1) the first rule is not understandable to me.
> > 2) the second rule does not say anything more than the basic rule valid
> >    for any CRL (i.e. a CRL issued later MUST have a higher CRL number).
> > 3) we will debate the hold condition, once we will have sorted the main
> >    issue.
> >
> > Russ said : "If separate number sequence is used, then you will have to
> > periodically fetch base CRLs ". This is true.
> >
> > Tim said that he would *not* like to be forced to download new base CRLs.
> > This is the core of the "dispute".
> >
> > >From the definition of what a delta CRL is, it is *not* possible to
> > get rid of the fetching of base CRLs. Unless we add a new sentence to
> > expand/change that definition, base CRL fetching will remain mandatory.
> >
> > Remember that the goal of delta CRLs is to provide the freshest 
> information,
> > and to my knowledge the goal was not to get rid of the fetching of base 
> CRLs
> > (which may less frequent due to the support of delta CRLs).
> >
> > If I understand correctly, Tim/David/Russ would like to *always* 
> achieve the
> > following property : it is possible to reconstruct the current CRL by 
> using
> > a base CRL from, e.g. 1990, i.e. by capturing every delta CRL that has 
> been
> > issued at the same time a base CRL was issued and which contains updates
> > made to the *previous* base.
> >
> > By this way the fetching of base CRLs could be avoided. However, note that
> > it is perfectly " legal " to stop issuing base and delta CRLs during some
> > period of time and to issue full CRLs instead (see the difference between
> > "full" and "base" at the top of this e-mail). In other words there is no
> > need to issue a new base CRL at the end of the validity period of the
> > previous base CRL. Doing this would mandate to prescribe issuing rules
> > for CAs that we have not prescripted.
> >
> > I will now raise a series of questions, for which I believe we have
> > different answers. Tim/David/Russ do not hesitate to correct
> > if my guess is wrong. ;-)
> >
> > Common point:
> >
> > 1) What will be the value of the nextUpdate field from the last issued 
> delta
> > CRL for a given base CRL ?
> >
> > Denis: the nextUpdate field from the last issued delta CRL MUST be 
> equal to
> > the value of nextUpdate from the base CRL.
> >
> > Tim/David/Russ: ???
> >
> > 2) Does a CA needs to issue a delta CRL at the time a full CRL is issued ?
> >
> > Denis: No.
> > Tim/David/Russ : ???
> >
> > 3) Does a CA needs to issue a new base CRL at the end of the validity of a
> > current base CRL ?
> >
> > Denis: No.
> > Tim/David/Russ : ???
> >
> > 4) Does a CA needs to issue a delta CRL at the same time a new base is
> > issued ?
> >
> > Denis: Yes. The delta CRL refers to the *new* base.
> > Tim/David/Russ : Yes. The delta CRL refers to the *previous* base. [Note
> > that there can be no previous at all, or the "previous" may even be three
> > months old].
> >
> > The last point highlights the most noticeable difference. Other 
> differences
> > appears when considering the guaranty to get the freshest information :
> > using the traditional scheme and the thisUpdate and nextUpdate fields the
> > guaranty to get the freshest information is obtained, but cannot be 
> obtained
> > using the other scheme. :-(
> >
> > Several people are referring to the X.509 document for arguments to 
> support
> > that discussion. However, it is important to remember that we are defining
> > PKIX, not X.509, so we DO NOT need to copy and paste everything from 
> X.509,
> > but only what we believe is relevant.
> >
> > We first need to clearly define the processing rules applicable to the
> > relying parties. These rules will certainly contain SHALL/MUST statements,
> > but may also include some MAY statements which may even be conditional to
> > what the CA is doing. (I let Tim/David or Russ provide the MAY statement).
> >
> > Here is a proposal for the MUST statement, based on the previous text I
> > produced:
> >
> >    An application that is wishing to take advantage of delta CRLs
> >    for a given scope, MUST first find a base CRL for that scope,
> >    i.e. a full CRL that that contains a freshestCRL extension
> >    (a.k.a. a Delta CRL distribution point). It may then construct
> >    an updated CRL for that base, for a specific time T, by combining
> >    it with a delta CRL which contains a delta CRL indicator extension
> >    with the same CRL number as the base CRL. Applications that support
> >    delta CRLs MUST ensure that time T falls between thisUpdate and
> >    nextUpdate for both the base CRL and the delta CRL.
> >
> >    Note: An application could also reconstruct an updated CRL, for
> >    a specific time T, by using a previously locally reconstructed CRL
> >    based on the current base CRL, and combining it with a delta CRL which
> >    contains a delta CRL indicator extension with the same CRL number as
> >    the base CRL.
> >
> > We also need to clearly separate the issuing rules applicable for the CAs.
> > These rules will certainly contain SHALL statements, but could also 
> include
> > some MAY statements. (I let Tim/David or Russ provide the MAY statement).
> >
> > Here is a proposal for the MUST statement, based on the previous text I
> > produced:
> >
> >    A CA that supports delta-CRLs, MUST issue a base CRL, i.e. a full
> >    CRL that contains a freshestCRL extension (a.k.a. a Delta CRL
> >    distribution point). For any time T until the nextUpdate time
> >    indicated in a base CRL, the CA MUST provide one and only one
> >    delta CRL that refers to that base CRL and for which time T
> >    falls between thisUpdate and nextUpdate from the delta CRL.
> >
> > In his e-mail from Wednesday, May 9, David said that delta-CRL processing
> > rules could be base on time instead of CRL numbers. This is a point of 
> which
> > I strongly agree. Let us do it!
> >
> > (However, there is no need to add to PKIX, as he suggested, the support of
> > the baseUpdateTime extension from X.509 which would even more 
> complicate the
> > problem.)
> >
> > Regards,
> >
> > Denis


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id LAA21890 for <[e-mail]>; Thu, 10 May 2001 11:48:10 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 10 May 2001 18:47:53 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA25359 for <[e-mail]>; Thu, 10 May 2001 14:48:12 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <JY8NWWVX>; Thu, 10 May 2001 14:48:11 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.11]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JY8NWWV4; Thu, 10 May 2001 14:47:59 -0400
From: "Housley, Russ" <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 10 May 2001 14:47:43 -0400
Subject: Re: delta CRLs
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Denis:

> > I agree that there is a difference
> > between a base CRL and a full CRL.  However, my understanding was that 
> a CRL
> > is a "base CRL" with respect to some delta CRL only by virtue of having 
> been
> > so identified in that delta CRL.
>
>I believe that a base CRL must include the Freshest CRL extension (a.k.a.
>Delta CRL Distribution Point) defined in section 4.2.1.16. It indicates both
>that the service exists and where to fetch the information. It is a
>non-critical extension so that a base CRL may also be used as a full CL for
>relying parties not supporting delta CRLs.

Neither X.509 nor the draft PKIX profile requires the inclusion of the 
freshestCRL extension.  It might be a nice to advertise the availability 
(that is why it is there).  Remember that the PKIX profile does not require 
CAs to issue CRLs.  We do not want to make it difficult for them to do 
so.  Further, we do not want to make it too difficult to support delta CRLs.

> > According to the PKIX profile, this base CRL must be a full CRL
> > (complete for the intended scope).
> > I believe that X.509 does not require that a base CRL be a full CRL.
>
>You just say above: "According to the PKIX profile, this base CRL must be a
>full CRL (complete for the intended scope". So do you mean that X.509 and
>PKIX are taking different approaches ?

The PKIX profile is selecting a subset of the X.509 functionality.  Always 
has!  Always will!

Russ


Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA21820 for <[e-mail]>; Thu, 10 May 2001 11:46:24 -0700 (PDT)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id OAA02518 for <[e-mail]>; Thu, 10 May 2001 14:46:23 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 10 May 2001 14:44:11 -0400
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: Strawman on Delta CRLs
In-Reply-To: <[e-mail]. com>
References: <[e-mail]. com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====================_104696206==_"

--=====================_104696206==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

Folks,

David Cooper, Russ Housley and I have collaborated on a "strawman" 
describing the use of delta CRLs in PKIX implementations.  We believe the 
functionality we describe is consistent with ISO X.509 as well.

The text describes algorithms for using deltas and base CRLs to (a) check 
the status of a certificate or (b) create a constructed CRL.  This is 
followed by three scenarios for the use of deltas - "traditional deltas", 
"sliding window deltas", and a variant on sliding window deltas that 
factors in the real world delays in populating repositories with base and 
delta CRLs.

I have appended the strawman below in ASCII text.  The text includes tables 
for the examples.  Please note, these tables *require* a fixed font to be 
legible.  I have also attached a copy of the document in Word, for those 
that would prefer that format.  The Word version may be easier to read.

Hopefully, this strawman will serve to frame further discussions and 
accelerate consensus.   Once we agree on the requirements, Russ and I will 
draft the necessary changes and we can finish Last Call.  (I am nothing if 
not an optimist.)

We would also like to add the examples as an *informative* appendix in 
son-of-2459.

Thanks,

Tim Polk


--------------------------------strawman---------------------------

Implementing Delta CRLs Using PKIX

This paper addresses the use of delta CRLs in PKIX-compliant systems.
This paper assumes that delta CRLs include the delta CRL indicator
extension (rather than a CRL scope extension) and ignores
complications involving combined delta CRLs from indirect CRL issuers.

This paper also assumes that CRLs with different scopes are distributed
using different distribution points.

Terms

Revoked: A statement that a particular certificate's status has changed
and it should no longer be trusted.  Once a certificate is revoked, it
is always revoked.

Suspension: A statement that a particular certificate may not be
trustworthy. Once placed on hold, a certificate may be revoked or the
suspension may be lifted.

Revocation notice: A statement that a particular certificate has been
suspended or revoked.  The revocation statement identifies the certificate
by the issuer name and serial number.  The issuer may be specified
explicitly or implicitly. The issuer may be explicitly identified using
the certificate issuer extension. If not specified explicitly, the issuer
of the certificate is implicitly identified as the issuer of the CRL. A
revocation notice includes the date and time the certificate was revoked.
A revocation notice may optionally include a revocation reason in the
reason code CRL entry extension. [Note: A revocation notice may optionally
specify in the invalidity date extension the date from which the
certificate should be considered invalid.  This date may precede the actual
revocation date.  The invalidity date extension does not feature in this
discussion, so it is not considered further in this paper.]

Certificate revocation list (CRL):  a list of revocation notices for
certificates.

CRL scope: the set of certificates that could appear on a given CRL.
For example, the scope may be "all certificates issued by CA X", "all
CA and end entity certificates issued by CA X", "all certificates issued
by CA X that have been revoked for key compromise and CA compromise", or
may be a set of certificates based on local information, such as "all
certificates issued to the NIST employees located in Boulder".

Full CRL: a CRL that lists all unexpired certificates, in its scope, that
have been revoked for one of the revocation reasons covered by the scope
of the CRL. The scope of a full CRL does not necessarily include all of
the certificates issued by a CA or all possible revocation reasons.

Base CRL:  the particular CRL used as the foundation for a delta CRL.  The
base must be a full CRL.

Delta CRL:  a CRL that only lists those unexpired certificates, in its scope,
whose revocation status has changed since the issuance of a particular,
referenced base CRL. The scope of a delta CRL is must be the same as the base
CRL that it references

CRL Numbering

A CRL issuer may generate full CRLs for more than one scope.  The CRL issuer
may also generate delta CRLs.  Each delta CRLs must have the same scope as the
full CRL referenced as its base.

For each scope supported by the CRL issuer, a numbering sequence must be
maintained.  For each scope, the CRLs are numbered in a monotonically 
increasing
sequence.  (Wrapping is not permitted in the PKIX profile.)  If a CRL issuer
generates CRLs for one scope (e.g., full CRLs and deltas CRLs), the issuer must
maintain one numbering sequence.  If a delta CRL and a full CRL that cover the
same scope are issued at the same time, they will have the same CRL number.

If a CRL issuer generates CRLs for two scopes (e.g., one covering CA
certificates and one covering end entity certificates), then the CRL issuer 
must
maintain two number sequences.  The CRLs and deltas for the same scope 
(e.g., CA
certificates) will share one numbering sequence.  The CRLs and deltas for the
second scope (e.g., end entity certificates) will share one numbering 
sequence.
There is no requirement that these sequences be disjoint.

Algorithms for Determining Status from a Full CRL and a Delta CRL

Consider a full CRL, F, with CRL number X.  A client may obtain BF in either of
the following ways:
(a) the full CRL F may have been pushed to the client or pulled from a 
repository; or
(b) F may have been constructed from a full CRL and a delta CRL using this 
algorithm.

Consider a delta CRL, D, which specifies base CRL Y and has CRL number Z.  This
means that all certificates whose statuses have changed since the issuance 
of CRL Y
will be listed on the delta CRL.  Note that the PKIX profile requires the 
CA to issue
CRL Y as a full CRL.

Determining Whether a Full CRL and Delta CRL May Be Combined

F and D may be combined if each of the following conditions are met:

(1)	X is greater than or equal to Y.  That is, the full CRL must (at a minimum)
contain all the revocation information held by the referenced base CRL.
(2)	X is less than Z.  That is, the delta CRL must cover some time that was not
covered by the full CRL.

Determining Status of a Certificate from a Full CRL and a Delta CRL

If the PKI client maintains the delta and full CRL, the status of an unexpired
certificate C may be determined as follows:

(1)	If C is listed on the delta CRL, then:
a.	If C is listed on the delta CRL with reason code "removeFromCRL", then C
is not revoked.
b.	Otherwise, certificate C is revoked.
(2)	If C was not listed on the delta CRL, then the full CRL is checked, and the
status is as follows:
a.	If C is listed on the full CRL, then C is revoked.
b.	If C is not listed on the full CRL, then C is not revoked.

Combining a Full CRL and Delta CRL into a Constructed CRL

If the PKI client maintains the current CRL in a local cache:

The revocation information on F is assumed as the initial condition.  F is 
a list
of revoked certificates; each certificate is listed with a revocation reason
(which may be "unspecified").

The list of revoked certificates L with n entries denoted as L[i] where 1 
<= i <= n.
(The value n may shrink or grow as the combination process proceeds.)

Initialize L to the revocation notices on F.  For each certificate C on the 
delta CRL,
update the contents of L as follows.

If a certificate C appears on the delta CRL, and C is not currently in the 
list L,
then:
(a)	if C has a revocation reason other than "removeFromCRL", add C as a new 
entry
in  the list of revoked certificates L.
(b)	If C has revocation reason "removeFromCRL", skip this certificate.  No 
update
to the cache is needed.

If a certificate C appears on the delta CRL, and C is presently listed in L 
as entry
L[i], then:
(a)	If C is listed on the delta CRL with a revocation reason of 
"removeFromCRL",
delete entry L[i]
(b)	If C is listed on the delta CRL without a revocation reason or with a 
revocation
reason other than "removeFromCRL", change the reason code associated with 
L[i] to the
reason code specified in the delta CRL.

The combination of F and D forms a new full CRL with CRL number Z.  This 
full CRL has
complete information until the time specified in the next update field in 
the delta CRL
is reached.  If a relying party is validating a certificate with respect to 
time T, and
T is before the next update field in the delta CRL, they may assume 
complete information.

If an unexpired certificate C within the scope of the constructed CRL is 
not listed, then
certificate C is not revoked for one of the revocation reasons covered by 
this CRL.  If
the constructed CRL covers all reasons, then the certificate C is not revoked.

Using Deltas to Distribute Revocation Information

This section provides three different scenarios for the use of delta 
CRLs.  For the
purpose of these examples, assume a goal of providing revocation 
information to relying
parties that is no more than one hour old.

The following notation is used to denote a revoked certificate on a CRL:
		Xr	certificate X is listed for reason r, where r in {a,k,h,r}
The reason codes {a,k,h,r} correspond to "affiliation changed", "key 
compromise",
"certificate hold", and "remove from CRL" respectively.

(Note:  The remaining reason codes are omitted for simplicity.  The handling of
certificates revoked for  the reasons "unspecified", "CA compromise", 
"superseded", and
"cessationOfOperation" are identical to "affiliation changed or "key 
compromise").



Example #1

The example below shows the "traditional" method of issuing delta CRLs.
In this example, full CRLs are issued once every 3 hours and deltas are
issued once an hour. For consistency, the issuer begins issuing deltas
at the same time as the very first full CRL. After that, however, a delta
can always use a previously issued full CRL as its base. Notice that
starting with cRLNumber 4, the delta CRL issued at the same time as a
full CRL uses the previously issued full CRL as its base. However, the
delta-CRLs never provide more than 3 hours of history.

In this example:
Certificate 14 was revoked for key compromise before 12:00 when the first
CRL was issued.
Certificate 124 was revoked for key compromise between 12:00 and 13:00.
Certificate 39 was placed on hold between 14:00 and 15:00, and its
suspension was lifted between 16:00 and 17:00.
Certificate 67 was revoked for an affiliation change between 16:00 and
17:00.  The reason was changed to key compromise between 18:00 and 19:00.

current  | Revoked      | Full CRL                 | Delta-CRL
time     | certificates |                          |
---------|--------------|--------------------------|----------------------
12:00    | {14k}        | cRLNumber = 1            | cRLNumber = 1
          |              | thisUpdate = 12:00       | thisUpdate = 
12:00
          |              | nextUpdate = 15:00       | nextUpdate = 13:00
          |              | CertificateList = {14k}  | BaseCRLNumber = 1
          |              |                          | CertificateList = 
{}
---------|--------------|--------------------------|----------------------
13:00    | {14k, 124k}  |                          | cRLNumber = 2
          |              |                          | thisUpdate = 13:00
          |              |                          | nextUpdate = 14:00
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList = {124k}
---------|--------------|--------------------------|----------------------
14:00    | {14k, 124k}  |                          | cRLNumber = 3
          |              |                          | thisUpdate = 14:00
          |              |                          | nextUpdate = 15:00
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList = {124k}
---------|--------------|--------------------------|----------------------
15:00    | {14k, 124k,  | cRLNumber = 4            | cRLNumber = 4
          |   39h}       | thisUpdate = 15:00       | thisUpdate = 
15:00
          |              | nextUpdate = 18:00       | nextUpdate = 16:00
          |              | CertificateList =        | BaseCRLNumber = 1
          |              |  {14k, 124k, 39h}        | CertificateList =
          |              |                          | {124k, 39h}
---------|--------------|--------------------------|----------------------
16:00    | {14k, 124k,  |                          | cRLNumber = 5
          |   39h, 67a}  |                          | thisUpdate = 16:00
          |              |                          | nextUpdate = 17:00
          |              |                          | BaseCRLNumber = 4
          |              |                          | CertificateList = {67a}
          |              |                          |
---------|--------------|--------------------------|----------------------
17:00    | {14k, 124k,  |                          | cRLNumber = 6
          |   67a}       |                          | thisUpdate = 17:00
          |              |                          | nextUpdate = 18:00
          |              |                          | BaseCRLNumber = 4
          |              |                          | CertificateList =
          |              |                          | {39r, 67a}
---------|--------------|--------------------------|----------------------
18:00    | {14k, 124k,  | cRLNumber = 7            | cRLNumber = 7
          |   67a}       | thisUpdate = 18:00       | thisUpdate = 
18:00
          |              | nextUpdate = 21:00       | nextUpdate = 19:00
          |              | CertificateList =        | BaseCRLNumber = 4
          |              | {14k, 124k, 67a}         | CertificateList =
          |              |                          | {39r, 
67a}
---------|--------------|--------------------------|----------------------
19:00    | {14k, 124k,  |                          | cRLNumber = 8
          |   67k}       |                          | thisUpdate = 19:00
          |              |                          | nextUpdate = 20:00
          |              |                          | BaseCRLNumber = 7
          |              |                          | CertificateList = {67k}
---------|--------------|--------------------------|----------------------

Scenario #2

The example below shows the "sliding window" method of issuing delta-CRLs.
In this example, full CRLs are issued once every 3 hours and deltas are
issued once an hour. For consistency, the issuer begins issuing deltas at
the same time as the very first full CRL. Notice that starting with
cRLNumber 7, the delta CRL issued at the same time as a full CRL does not
use the previously issued full CRL as its base but the preceding CRL instead.
However, these delta-CRLs never provide more than 6 hours of history.

As in example #1:
Certificate 14 was revoked for key compromise before 12:00 when the first
CRL was issued.
Certificate 124 was revoked for key compromise between 12:00 and 13:00.
Certificate 39 was placed on hold between 14:00 and 15:00, and its
suspension was lifted between
16:00 and 17:00.
Certificate 67 was revoked for an affiliation change between 16:00 and 17:00.
The reason was changed to key compromise between 18:00 and 19:00.

current  | Revoked      | Full CRL                 | Delta-CRL
time     | certificates |                          |
---------|--------------|--------------------------|----------------------
12:00    | {14k}        | cRLNumber = 1            | cRLNumber = 1
          |              | thisUpdate = 12:00       | thisUpdate = 
12:00
          |              | nextUpdate = 15:00       | nextUpdate = 13:00
          |              | CertificateList = {14k}  | BaseCRLNumber = 1
          |              |                          | CertificateList = 
{}
---------|--------------|--------------------------|----------------------
13:00    | {14k, 124k}  |                          | cRLNumber = 2
          |              |                          | thisUpdate = 13:00
          |              |                          | nextUpdate = 14:00
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList = {124k}
---------|--------------|--------------------------|----------------------
14:00    | {14k, 124k}  |                          | cRLNumber = 3
          |              |                          | thisUpdate = 14:00
          |              |                          | nextUpdate = 15:00
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList = {124k}
---------|--------------|--------------------------|----------------------
15:00    | {14k, 124k,  | cRLNumber = 4            | cRLNumber = 4
          |   39h}       | thisUpdate = 15:00       | thisUpdate = 
15:00
          |              | nextUpdate = 18:00       | nextUpdate = 16:00
          |              | CertificateList =        | BaseCRLNumber = 1
          |              |  {14k, 124k, 39h}        | CertificateList =
          |              |                          | {124k, 39h}
---------|--------------|--------------------------|----------------------
16:00    | {14k, 124k,  |                          | cRLNumber = 5
          |   39h, 67a}  |                          | thisUpdate = 16:00
          |              |                          | nextUpdate = 17:00
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList =
          |              |                          | {124k, 39h, 67a}
---------|--------------|--------------------------|----------------------
17:00    | {14k, 124k,  |                          | cRLNumber = 6
          |   67a}       |                          | thisUpdate = 17:00
          |              |                          | nextUpdate = 18:00
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList =
          |              |                          | {124k, 39h, 67a}
---------|--------------|--------------------------|----------------------
18:00    | {14k, 124k,  | cRLNumber = 7            | cRLNumber = 7
          |   67a}       | thisUpdate = 18:00       | thisUpdate = 
18:00
          |              | nextUpdate = 21:00       | nextUpdate = 19:00
          |              | CertificateList =        | BaseCRLNumber = 1
          |              | {14k, 124k, 67a}         | CertificateList =
          |              |                          | {124k, 39r, 67a}
---------|--------------|--------------------------|----------------------
19:00    | {14k, 124k,  |                          | cRLNumber = 8
          |   67k}       |                          | thisUpdate = 19:00
          |              |                          | nextUpdate = 20:00
          |              |                          | BaseCRLNumber = 7
          |              |                          | CertificateList =
          |              |                          | {39r, 67k
---------|--------------|--------------------------|----------------------


Note that the delta CRLs are marginally larger than in the first scenario
since they cover a longer time period.  On the other hand, a relying party
is less likely to download full CRLs in the second scenario.

For example, a relying party that validated one certificate at 12:15, then
a second certificate at 16:15 would not require a new full CRL in scenario #2.
In scenario #1, the relying party would be forced to obtain both full CRL 4
and delta CRL 5.

Scenario #3 Allowing for Replication/Propagation Delays

In this scenario, full CRLs and delta CRLs are replicated throughout a
repository system.  Data is replicated through the system at different
rates based on the size of the file.  The CA operators estimate that full
CRLs will be available throughout the system within three hours.  Delta CRLs
will be available within 15 minutes.  (Assume the initial CRL is small and
will propagate as if a delta CRL to resolve the bootstrap issues.)

The example below uses the "sliding window" method of issuing delta-CRLs,
but overlaps the thisUpdate and nextUpdate times to allow for propagation.
In this example, full CRLs are issued once every 3 hours and deltas are
issued every 45 minutes. For consistency, the issuer begins issuing deltas
at the same time as the very first full CRL. Notice that starting with
cRLNumber 7, the delta CRL issued at the same time as a full CRL does not
use the previously issued full CRL as its base but the preceding CRL instead.
As in example #2, these delta-CRLs never provide more than 6 hours of history.

Similary to examples #1 and #2:
Certificate 14 was revoked for key compromise before 12:00 when the first CRL
was issued.
Certificate 124 was revoked for key compromise between 12:00 and 12:45.
Certificate 39 was placed on hold between 14:15 and 15:00, and its suspension
was lifted between 16:00 and 17:00.
Certificate 67 was revoked for an affiliation change between 15:45 and 16:30.
The reason was changed to key compromise between 18:00 and 18:45.

current  | Revoked      | Full CRL                 | Delta-CRL
time     | certificates |                          |
---------|--------------|--------------------------|----------------------
12:00    | {14k}        | cRLNumber = 1            | cRLNumber = 1
          |              | thisUpdate = 12:00       | thisUpdate = 
12:00
          |              | nextUpdate = 18:00       | nextUpdate = 13:00
          |              | CertificateList = {14k}  | BaseCRLNumber = 1
          |              |                          | CertificateList = 
{}
---------|--------------|--------------------------|----------------------
12:45    | {14k, 124k}  |                          | cRLNumber = 2
          |              |                          | thisUpdate = 12:45
          |              |                          | nextUpdate = 13:45
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList = {124k}
---------|--------------|--------------------------|----------------------
13:30    | {14k, 124k}  |                          | cRLNumber = 3
          |              |                          | thisUpdate = 13:30
          |              |                          | nextUpdate = 14:30
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList = {124k}
---------|--------------|--------------------------|----------------------
14:15    | {14k, 124k}  |                          | cRLNumber = 4
          |              |                          | thisUpdate = 14:15
          |              |                          | nextUpdate = 15:15
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList = {124k}
---------|--------------|--------------------------|----------------------
15:00    | {14k, 124k,  | cRLNumber = 5            | cRLNumber = 5
          |   39h}       | thisUpdate = 15:00       | thisUpdate = 
15:00
          |              | nextUpdate = 21:00       | nextUpdate = 16:00
          |              | CertificateList =        | BaseCRLNumber = 1
          |              |  {14k, 124k, 39h}        | CertificateList =
          |              |                          | {124k, 39h}
---------|--------------|--------------------------|----------------------
15:45    | {14k, 124k,  |                          | cRLNumber = 6
          |   39h, 67a}  |                          | thisUpdate = 15:45
          |              |                          | nextUpdate = 16:45
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList =
          |              |                          | {124k, 39h, 67a}
---------|--------------|--------------------------|----------------------
16:30    | {14k, 124k,  |                          | cRLNumber = 7
          |   67a}       |                          | thisUpdate = 16:30
          |              |                          | nextUpdate = 17:30
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList =
          |              |                          | {124k, 39r, 67a}
---------|--------------|--------------------------|----------------------
17:15    | {14k, 124k,  |                          | cRLNumber = 8
          |  67a}        |                          | thisUpdate = 17:15
          |              |                          | nextUpdate = 18:15
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList =
          |              |                          | {124k, 39r, 67a}
---------|--------------|--------------------------|----------------------
18:00    | {14k, 124k,  | cRLNumber = 9            | cRLNumber = 9
          |   67a}       | thisUpdate = 18:00       | thisUpdate = 
18:00
          |              | nextUpdate = 24:00       | nextUpdate = 19:00
          |              | CertificateList =        | BaseCRLNumber = 5
          |              | {14k, 124k, 67a}         | CertificateList =
          |              |                          | {39r, 67a}
---------|--------------|--------------------------|----------------------
18:45    | {14k, 124k,  |                          | cRLNumber = 10
          |   67k}       |                          | thisUpdate = 18:45
          |              |                          | nextUpdate = 19:45
          |              |                          | BaseCRLNumber = 5
          |              |                          | CertificateList =
          |              |                          | {39r, 67k}
---------|--------------|--------------------------|----------------------



Delta CRL number 6 is issued at 15:45.  By 16:00, delta CRL number 6 should
be available throughout the system.  As a result, delta CRL number 5 specified
16:00 as its nextUpdate time.

However, full CRL number 5 was issued at 15:00 and may not be available
throughout the system  until 18:00.  As a result, full CRL number 1 specified
18:00 as its nextUpdate time.  In addition, delta CRL number 6 must be based
on full CRL number 1 which was issued at 12:00.

If the relying party finds full CRL number 5 in the repository, they may still
apply delta CRL number 6 and achieve the correct answer.

Finally, note that a CRL issuer must generate more CRLs to achieve the goal of
status information that is no more than one hour old when factoring in the
propagation delays.





--=====================_104696206==_
Content-Type: application/msword; name="PKIX deltas.doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="PKIX deltas.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAnAAAAAAAAAAA
EAAAngAAAAEAAAD+////AAAAAJoAAACbAAAA////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////s
pcEATSAJBAAA8BK/AAAAAAAAEAAAAAAABAAAXmMAAA4AYmpiauI94j0AAAAAAAAAAAAAAAAAAAAA
AAAJBBYAIsoAAIBXAACAVwAA8F0AAG0BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA
AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAAgCAAAAAAAACAIAAAgC
AAAKAAAAEgIAAAwAAAAeAgAAAAAAAB4CAAAAAAAAHgIAABQAAAAAAAAAAAAAADICAAAAAAAAHiAA
AAAAAAAeIAAAAAAAAB4gAAAAAAAAHiAAAIwAAACqIAAADAEAADICAAAAAAAAy0IAAPYAAADCIQAA
AAAAAMIhAAAAAAAAwiEAAAAAAADCIQAAAAAAAMIhAAAAAAAAwiEAAAAAAADCIQAAAAAAAMIhAAAA
AAAAqkEAAAIAAACsQQAAAAAAAKxBAAAAAAAArEEAAAAAAACsQQAAAAAAAKxBAAAAAAAArEEAACQA
AADBQwAAIAIAAOFFAADIAAAA0EEAABUAAAAAAAAAAAAAAAAAAAAAAAAAHgIAAAAAAADCIQAAAAAA
AAAAAAAAAAAAAAAAAAAAAADCIQAAAAAAAMIhAAAAAAAAwiEAAAAAAADCIQAAAAAAANBBAAAAAAAA
Ci0AAAAAAAAeAgAAAAAAAB4CAAAAAAAAwiEAAAAAAAAAAAAAAAAAAMIhAAAAAAAA5UEAAIYAAAAK
LQAAAAAAAAotAAAAAAAACi0AAAAAAADCIQAATAkAAB4CAAAAAAAAwiEAAAAAAAAeAgAAAAAAAMIh
AAAAAAAAqkEAAAAAAAAAAAAAAAAAAAotAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAwiEAAAAAAACqQQAAAAAAAAotAACmBgAACi0AAAAAAACwMwAA
cgAAAF48AABUAAAAHgIAAAAAAAAeAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAzjwAAAAAAADCIQAAAAAAALYhAAAMAAAAoKEqD3/Z
wAEyAgAA7B0AAB4gAAAAAAAADisAAPwBAACyPAAADgAAAAAAAAAAAAAAzjwAANwEAABrQgAAYAAA
AMtCAAAAAAAAwDwAAA4AAACpRgAAAAAAAAotAAAAAAAAqUYAAAAAAADOPAAAAAAAAAotAAAAAAAA
MgIAAAAAAAAyAgAAAAAAAB4CAAAAAAAAHgIAAAAAAAAeAgAAAAAAAB4CAAAAAAAAAgDZAAAAIERl
bHRhIENSTHMNDVRoaXMgcGFwZXIgYWRkcmVzc2VzIHRoZSB1c2Ugb2YgZGVsdGEgQ1JMcyBpbiBQ
S0lYLWNvbXBsaWFudCBzeXN0ZW1zLiAgVGhpcyBwYXBlciBhc3N1bWVzIHRoYXQgZGVsdGEgQ1JM
cyBpbmNsdWRlIHRoZSBkZWx0YSBDUkwgaW5kaWNhdG9yIGV4dGVuc2lvbiAocmF0aGVyIHRoYW4g
YSBDUkwgc2NvcGUgZXh0ZW5zaW9uKSBhbmQgaWdub3JlcyBjb21wbGljYXRpb25zIGludm9sdmlu
ZyBjb21iaW5lZCBkZWx0YSBDUmxzIENSTHMgZnJvbSBpbmRpcmVjdCBDUkwgaXNzdWVycy4NDVRo
aXMgcGFwZXIgYWxzbyBhc3N1bWVzIHRoYXQgQ1JMcyB3aXRoIGRpZmZlcmVudCBzY29wZXMgYXJl
IGRpc3RyaWJ1dGVkIHVzaW5nIGRpZmZlcmVudCBkaXN0cmlidXRpb24gcG9pbnRzLg0NVGVybXMN
DVJldm9rZWQ6IEEgc3RhdGVtZW50IHRoYXQgYSBwYXJ0aWN1bGFyIGNlcnRpZmljYXRlknMgc3Rh
dHVzIGhhcyBjaGFuZ2VkIGFuZCBpdCBzaG91bGQgbm8gbG9uZ2VyIGJlIHRydXN0ZWQuICBPbmNl
IGEgY2VydGlmaWNhdGUgaXMgcmV2b2tlZCwgaXQgaXMgYWx3YXlzIHJldm9rZWQuDQ1TdXNwZW5z
aW9uOiBBIHN0YXRlbWVudCB0aGF0IGEgcGFydGljdWxhciBjZXJ0aWZpY2F0ZSBtYXkgbm90IGJl
IHRydXN0d29ydGh5LiAgT25jZSBwbGFjZWQgb24gaG9sZCwgYSBjZXJ0aWZpY2F0ZSBtYXkgYmUg
cmV2b2tlZCBvciB0aGUgc3VzcGVuc2lvbiBtYXkgYmUgbGlmdGVkLg0NUmV2b2NhdGlvbiBub3Rp
Y2U6IEEgc3RhdGVtZW50IHRoYXQgYSBwYXJ0aWN1bGFyIGNlcnRpZmljYXRlIGhhcyBiZWVuIHN1
c3BlbmRlZCBvciByZXZva2VkLiAgVGhlIHJldm9jYXRpb24gc3RhdGVtZW50IGlkZW50aWZpZXMg
dGhlIGNlcnRpZmljYXRlIGJ5IHRoZSBpc3N1ZXIgbmFtZSBhbmQgc2VyaWFsIG51bWJlci4gIFRo
ZSBpc3N1ZXIgbWF5IGJlIHNwZWNpZmllZCBleHBsaWNpdGx5IG9yIGltcGxpY2l0bHkuICBUaGUg
aXNzdWVyIG1heSBiZSBleHBsaWNpdGx5IGlkZW50aWZpZWQgdXNpbmcgdGhlIGNlcnRpZmljYXRl
IGlzc3VlciBleHRlbnNpb24uIElmIG5vdCBzcGVjaWZpZWQgZXhwbGljaXRseSwgdGhlIGlzc3Vl
ciBvZiB0aGUgY2VydGlmaWNhdGUgaXMgaW1wbGljaXRseSBpZGVudGlmaWVkIGFzIHRoZSBpc3N1
ZXIgb2YgdGhlIENSTC4gQSByZXZvY2F0aW9uIG5vdGljZSBpbmNsdWRlcyB0aGUgZGF0ZSBhbmQg
dGltZSB0aGUgY2VydGlmaWNhdGUgd2FzIHJldm9rZWQuICBBIHJldm9jYXRpb24gbm90aWNlIG1h
eSBvcHRpb25hbGx5IGluY2x1ZGUgYSByZXZvY2F0aW9uIHJlYXNvbiBpbiB0aGUgcmVhc29uIGNv
ZGUgQ1JMIGVudHJ5IGV4dGVuc2lvbi4CDQ1DZXJ0aWZpY2F0ZSByZXZvY2F0aW9uIGxpc3QgKENS
TCk6ICBhIGxpc3Qgb2YgcmV2b2NhdGlvbiBub3RpY2VzIGZvciBjZXJ0aWZpY2F0ZXMuDQ1DUkwg
c2NvcGU6IHRoZSBzZXQgb2YgY2VydGlmaWNhdGVzIHRoYXQgY291bGQgYXBwZWFyIG9uIGEgZ2l2
ZW4gQ1JMLiAgRm9yIGV4YW1wbGUsIHRUaGUgc2NvcGUgbWF5IGJlIJNhbGwgY2VydGlmaWNhdGVz
IGlzc3VlZCBieSBDQSBYlCwgk2FsbCBbQ0EgYW5kfCBlbmQgZW50aXR5XSBjZXJ0aWZpY2F0ZXMg
aXNzdWVkIGJ5IENBIFiULCCTYWxsIGNlcnRpZmljYXRlcyBpc3N1ZWQgYnkgQ0EgWCB0aGF0IGhh
dmUgYmVlbiByZXZva2VkIGZvciBba2V5IGNvbXByb21pc2UgfCBldGMuXWFuZCBDQSBjb21wcm9t
aXNllCwgb3IgbWF5IGJlIGEgc2V0IG9mIGNlcnRpZmljYXRlcyBiYXNlZCBvbiBsb2NhbCBpbmZv
cm1hdGlvbiwgc3VjaCBhcyCTYWxsIGNlcnRpZmljYXRlcyBpc3N1ZWQgdG8gdGhlIE5JU1QgZW1w
bG95ZWVzIGxvY2F0ZWQgaW4gQm91bGRlcpQuDQ1GdWxsIENSTDogYSBDUkwgdGhhdCBsaXN0cyBh
bGwgdW4tZXhwaXJlZHVuZXhwaXJlZCBjZXJ0aWZpY2F0ZXMsIGluIGl0cyBzY29wZSwgdGhhdCBo
YXZlIGJlZW4gcmV2b2tlZCBmb3Igb25lIG9mIHRoZSByZXZvY2F0aW9uIHJlYXNvbnMgY292ZXJl
ZCBieSB0aGUgc2NvcGUgb2YgdGhlIENSTC4gIFRoZSBzY29wZSBvZiBhIGZ1bGwgQ1JMIGRvZXMg
bm90IG5lY2Vzc2FyaWx5IGluY2x1ZGUgYWxsIG9mIHRoZSBjZXJ0aWZpY2F0ZXMgaXNzdWVkIGJ5
IGEgQ0Egb3IgYWxsIHBvc3NpYmxlIHJldm9jYXRpb24gcmVhc29ucy4gIHRoZSBzY29wZSBvZiBh
IGZ1bGwgQ1JMIGlzIHNldCBvZiB1bi1leHBpcmVkIGNlcnRpZmljYXRlcyB3aG9zZSBjdXJyZW50
IHN0YXR1cyBpcyBub3QgZnVsbHkgdHJ1c3RlZC4gIFRoZSBmdWxsIENSTCBtYXkgY292ZXIgYWxs
IGNlcnRpZmljYXRlcyBpc3N1ZWQgYnkgYSBDQSwgb3IgYSBzdWJzZXQgdGhvc2UgY2VydGlmaWNh
dGVzIChlLmcuLCBhIENSTCBzZWdtZW50KSBiYXNlZCBvbiBjZXJ0aWZpY2F0ZSBzdWJqZWN0IHR5
cGUsIHJldm9jYXRpb24gcmVhc29ucywgb3Igb3RoZXIgbG9jYWwgcmVhc29ucyAoZS5nLiwgk2Fs
bCBjZXJ0aWZpY2F0ZXMgaXNzdWVkIHRvIE5JU1SScyBCb3VsZGVyIGVtcGxveWVlc5QpLg0NQmFz
ZSBDUkw6ICB0aGUgcGFydGljdWxhciBDUkwgdXNlZCBhcyB0aGUgZm91bmRhdGlvbiBmb3IgYSBk
ZWx0YSBDUkwuICBUaGUgYmFzZSBtdXN0IGhhdmUgYmVlbiBpc3N1ZWQgYXMgYSBmdWxsIENSTC4N
DURlbHRhIENSTDogIGEgQ1JMIHRoYXQgb25seSBsaXN0cyB0aG9zZSB1bi1leHBpcmVkdW5leHBp
cmVkIGNlcnRpZmljYXRlcywgaW4gaXRzIHNjb3BlLCB3aG9zZSByZXZvY2F0aW9uIHN0YXR1cyBo
YXMgY2hhbmdlZCBzaW5jZSB0aGUgaXNzdWFuY2Ugb2YgYSBwYXJ0aWN1bGFyLCByZWZlcmVuY2Vk
IGJhc2UgQ1JMLiBUaGUgc2NvcGUgb2YgYSBkZWx0YSBDUkwgaXMgbXVzdCBiZSB0aGUgc2FtZSBh
cyB0aGUgYmFzZSBDUkwgdGhhdCBpdCByZWZlcmVuY2VzIFRoZSBzY29wZSBvZiBhIGRlbHRhIENS
TCBpcyB0aGUgc2FtZSBhcyB0aGUgYmFzZSBDUkwsIGJ1dCB0aGUgY29udGVudHMgYXJlIGxpbWl0
ZWQgdG8gdGhlIGxpc3Qgb2YgY2VydGlmaWNhdGVzIHdob3NlIHN0YXR1cyBoYXMgY2hhbmdlZCBz
aW5jZSB0aGUgaXNzdWFuY2Ugb2YgdGhlIGJhc2UgQ1JMLg0NQmFzZSBDUkw6ICBUaGUgcGFydGlj
dWxhciBDUkwgdXNlZCBhcyB0aGUgZm91bmRhdGlvbiBmb3IgYSBkZWx0YSBDUkwuICBUaGUgYmFz
ZSBtdXN0IGhhdmUgYmVlbiBpc3N1ZWQgYXMgYSBmdWxsIENSTC4NDUNvbnN0cnVjdGVkIENSTDog
dGhlIGNvbWJpbmF0aW9uIG9mIGEgZGVsdGEgQ1JMIGFuZCBhIGJhc2UgQ1JMDQ1DUkwgTnVtYmVy
aW5nDQ1BIENSTCBpc3N1ZXIgbWF5IGlzc3VlIGdlbmVyYXRlIGZ1bGwgQ1JMcyBmb3IgbW9yZSB0
aGFuIG9uZSBzY29wZS5hbnkgY29tYmluYXRpb24gb2YgZnVsbCBzZWdtZW50ZWQgQ1JMcyBhbmQg
dW5zZWdtZW50ZWQgQ1JMcyB7e3sgVGhlc2UgdHdvIHRlcm1zIGFyZSBub3QgZGVmaW5lZCBhYm92
ZS4gSSBob3BlIHRoYXQgeW91IGNhbiBzdGljayB0byB0aGUgZGVmaW5lZCB0ZXJtIJNzY29wZS6U
IH19fS4gIFRoZSBDUkwgaXNzdWVyIG1heSBhbHNvIGlzc3VlIGdlbmVyYXRlIGRlbHRhIENSTHMu
ICBFYWNoOyB0aGUgZGVsdGEgQ1JMcyB3aWxsIG11c3QgaGF2ZSB0aGUgc2FtZSBzY29wZXMgYXMg
ZWl0aGVyIGF0aGUgZnVsbCBzZWdtZW50ZWQgQ1JMIG9yIHVuYSBzZWdtZW50ZWRmdWxsIENSTHMg
aXNzdWVkIGJ5IHRoZSBDUkwgaXNzdWVydGhhdCB0aGV5IHIgcmVmZXJlbmNlZCBhcyB0aGVpcml0
cyBiYXNlcy4NDUZvciBlYWNoIHNjb3BlIHN1cHBvcnRlZCBieSB0aGUgQ1JMIGlzc3VlciwgYSBz
ZXBhcmF0ZSBudW1iZXJpbmcgc2VxdWVuY2UgbXVzdCBiZSBtYWludGFpbmVkLiAgRm9yIGVhY2gg
c2NvcGUsIHRoZSBDUkxzIGFyZSBudW1iZXJlZCBpbiBhIG1vbm90b25pY2FsbHkgaW5jcmVhc2lu
ZyBzZXF1ZW5jZS4gIChXcmFwcGluZyBpcyBub3QgcGVybWl0dGVkIGluIHRoZSBQS0lYIHByb2Zp
bGUuICBJZiB0aGUgYSBkZWx0YSBDUkwgYW5kIGEgY29tcGxldGUgZnVsbCBDUkwgdGhhdCBjb3Zl
ciB0aGUgc2FtZSBzY29wZSBhcmUgaXNzdWVkIGF0IHRoZSBzYW1lIHRpbWUsIGVhY2ggdGhleSB3
aWxsIGhhdmUgdGhlIHNhbWUgQ1JMIG51bWJlci4pICANDUlUaGF0IGlzLCBpZiBhIENSTCBpc3N1
ZXIgaXNzdWVzIGdlbmVyYXRlcyBDUkxzIGZvciBvbmUgc2NvcGUgKGUuZy4sIGZ1bGwgQ1JMcyBh
bmQgZGVsdGFzIGZvciBmdWxsIENDUkxzKSwgdGhlIGlzc3VlciBtdXN0IG1haW50YWluIG9uZSBu
dW1iZXJpbmcgc2VxdWVuY2UuICBJZiBhIGRlbHRhIENSTCBhbmQgYSBmdWxsIENSTCB0aGF0IGNv
dmVyIHRoZSBzYW1lIHNjb3BlIGFyZSBpc3N1ZWQgYXQgdGhlIHNhbWUgdGltZSwgdGhleSB3aWxs
IGhhdmUgdGhlIHNhbWUgQ1JMIG51bWJlci4NDUlmIGEgQ1JMIGlzc3VlciBpc3N1ZXMgZ2VuZXJh
dGVzIENSTHMgZm9yIHR3byBzY29wZXMgKGUuZy4sIGFsbCBvbmUgY292ZXJpbmcgQ0EgY2VydGlm
aWNhdGVzIGFuZCBhbGwgb25lIGNvdmVyaW5nIGVuZCBlbnRpdHkgY2VydGlmaWNhdGVzKSwgdGhl
biB0aGUgQ1JMIGlzc3VlciBtdXN0IG1haW50YWluIHR3byBudW1iZXIgc2VxdWVuY2VzLiAgVGhl
IENSTHMgYW5kIGRlbHRhcyBmb3IgdGhlIHNhbWUgc2NvcGUgKGUuZy4sIENBIGNlcnRpZmljYXRl
cykgd2lsbCBzaGFyZSBvbmUgbnVtYmVyaW5nIHNlcXVlbmNlLiAgVGhlIENSTHMgYW5kIGRlbHRh
cyBmb3IgdGhlIHNlY29uZCBzY29wZSAoZS5nLiwgZW5kIGVudGl0eSBjZXJ0aWZpY2F0ZXMpIHdp
bGwgc2hhcmUgb25lIG51bWJlcmluZyBzZXF1ZW5jZS4gICBUaGVyZSBpcyBubyByZXF1aXJlbWVu
dCB0aGF0IHRoZXNlIHNlcXVlbmNlcyBiZSBkaXNqb2ludC4NDUFsZ29yaXRobXMgZm9yIERldGVy
bWluaW5nIFN0YXR1cyBmcm9tIGEgQmFzZSBGdWxsIENSTCBhbmQgYSBEZWx0YSBDUkwNDUNvbnNp
ZGVyIGEgY29tcGxldGUgZnVsbCBDUkwsIEJGLCB3aXRoIENSTCBudW1iZXIgWC4gIEEgVGhlIFBL
SVggcHJvZmlsZSByZXF1aXJlcyB0aGUgQ0EgdG8gaXNzdWUgQiBhcyBhIGZ1bGwgQ1JMLCBidXQg
YSBjbGllbnQoQiBtYXkgYmUgb2J0YWluIEJGZWQgaW4gZWl0aGVyIG9mIHRoZSBmb2xsb3dpbmcg
d2F5czogKGEpIHRoZSBmdWxsIENSTCBCIEYgbWF5IGhhdmUgYmVlbiBwdXNoZWQgdG8gdGhlIGNs
aWVudCBvZnIgcHVsbGVkIGZyb20gYSByZXBvc2l0b3J5O2lzc3VlZCBhcyBhIGNvbXBsZXRlIGZ1
bGwgQ1JMIHdoaWNoIGNvbnRhaW5zIGEgQ1JMIG51bWJlciBleHRlbnNpb24gd2l0aCB2YWx1ZSBY
LiBvciAoYikgQWx0ZXJuYXRpdmVseSwgRkIgbWF5IGhhdmUgYmVlbiBjb25zdHJ1Y3RlZCBmcm9t
IGEgYmFzZSBmdWxsIENSTCBhbmQgYSBkZWx0YSBDUkwgdXNpbmcgdGhpcyBhbGdvcml0aG0uDS4N
Q29uc2lkZXIgYSBkZWx0YSBDUkwsIEQsIHdoaWNoIHNwZWNpZmllcyBiYXNlIENSTCBZIGFuZCBo
YXMgQ1JMIG51bWJlciBaLiAgVGhpcyBtZWFucyB0aGF0IGFsbCBjZXJ0aWZpY2F0ZXMgd2hvc2Ug
c3RhdHVzZXMgaGF2ZSBjaGFuZ2VkIHNpbmNlIHRoZSBpc3N1YW5jZSBvZiBDUkwgWSB3aWxsIGJl
IGxpc3RlZCBvbiB0aGUgZGVsdGEgQ1JMLiAgTm90ZSB0aGF0IHRoZSBQS0lYIHByb2ZpbGUgcmVx
dWlyZXMgdGhlIENBIHRvIGlzc3VlIENSTCBZIGFzIGEgZnVsbCBDUkwuDQ1EZXRlcm1pbmluZyBX
aGV0aGVyIGEgQmFzZSBGdWxsIENSTCBhbmQgRGVsdGEgQ1JMIE1heSBCZSBDb21iaW5lZA0NQ29u
c2lkZXIgYSBkZWx0YSBDUkwsIEQsIHdoaWNoIHNwZWNpZmllcyBiYXNlIENSTCBZIGFuZCBoYXMg
Q1JMIG51bWJlciBaLiAgVGhpcyBtZWFucyB0aGF0IGFsbCBjZXJ0aWZpY2F0ZXMgd2hvc2Ugc3Rh
dHVzZXMgaGF2ZXMgY2hhbmdlZCBzaW5jZSB0aGUgaXNzdWFuY2Ugb2YgQ1JMIFkgd2lsbCBiZSBs
aXN0ZWQgb24gdGhlIGRlbHRhIENSTC4NDUJGIGFuZCBEIG1heSBiZSBjb21iaW5lZCBpZiBlYWNo
IG9mIHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucyBhcmUgbWV0Og0NWCBpcyBncmVhdGVyIHRoYW4g
b3IgZXF1YWwgdG8gWS4gIFRoYXQgaXMsIHRoZSBjb21wbGV0ZSBmdWxsIENSTCBtdXN0IChhdCBh
IG1pbmltdW0pIGNvbnRhaW4gYWxsIHRoZSByZXZvY2F0aW9uIGluZm9ybWF0aW9uIGhlbGQgYnkg
dGhlIHJlZmVyZW5jZWQgYmFzZSBDUkwuDVggaXMgbGVzcyB0aGFuIFouICBUaGF0IGlzLCB0aGUg
ZGVsdGEgQ1JMIG11c3QgY292ZXIgc29tZSB0aW1lIHRoYXQgd2FzIG5vdCBjb3ZlcmVkIGJ5IHRo
ZSBjb21wbGV0ZSBmdWxsIENSTC4gDQ1EZXRlcm1pbmluZyBTdGF0dXMgb2YgYSBjZXJ0aWZpY2F0
ZSBDZXJ0aWZpY2F0ZSBmcm9tIGEgYmFzZSBGdWxsIENSTCBhbmQgYSBEZGVsdGEgQ1JMDQ1JZiB0
aGUgUEtJIGNsaWVudCBtYWludGFpbnMgdGhlIGRlbHRhIGFuZCBiYXNlIGZ1bGwgQ1JMLCB0aGUg
c3RhdHVzIG9mIGFuIHVuZXhwaXJlZCBjZXJ0aWZpY2F0ZSBDIGlzIG1heSBiZSBkZXRlcm1pbmVk
IGFzIGZvbGxvd3M6DQ1JZiBDIGlzIGxpc3RlZCBvbiB0aGUgZGVsdGEgQ1JMLCB0aGVuOg1JZiBD
IGlzIGxpc3RlZCBvbiB0aGUgZGVsdGEgQ1JMIHdpdGggcmVhc29uIGNvZGUgInJlbW92ZUZvcnJv
bUNSTCIsIHRoZW4gQyBpcyBub3QgcmV2b2tlZC5JZiBDIHdhcyBsaXN0ZWQgd2l0aG91dCBhbiBh
c3NvY2lhdGVkIHJldm9jYXRpb24gcmVhc29uIG9yIGEgcmV2b2NhdGlvbiByZWFzb24gb3RoZXIg
dGhhbiBjZXJ0aWZpY2F0ZSBob2xkLCB0aGVuIGNlcnRpZmljYXRlIEMgaXMgY29uc2lkZXJlZCBy
ZXZva2VkLg1PdGhlcndpc2UsIGNlcnRpZmljYXRlIEMgaXMgcmV2b2tlZC5JZiBDIGlzIGxpc3Rl
ZCBvbiB0aGUgZGVsdGEgQ1JMIHdpdGggcmVhc29uIGNvZGUgInJlbW92ZSBmb3JtIGNybENSTCIs
IHRoZW4gQyBpcyBub3QgcmV2b2tlZC4NSWYgQyB3YXMgbm90IGxpc3RlZCBvbiB0aGUgZGVsdGEg
Q1JMLCB0aGVuIHRoZSBiYXNlIGZ1bGwgQ1JMIGlzIGNoZWNrZWQsIGFuZCB0aGUgc3RhdHVzIGlz
IGFzIGZvbGxvd3M6DUlmIEMgaXMgbGlzdGVkIG9uIHRoZSBiYXNlIGZ1bGwgQ1JMLCB0aGVuIEMg
aXMgcmV2b2tlZC4NSWYgQyBpcyBub3QgbGlzdGVkIG9uIHRoZSBiYXNlIGZ1bGwgQ1JMLCB0aGVu
IEMgaXMgbm90IHJldm9rZWQuDQ1Db21iaW5pbmcgYSBCYXNlIEZ1bGwgQ1JMIGFuZCBEZWx0YSBD
UkwgaW50byBhIENvbnN0cnVjdGVkIENSTA0NSWYgdGhlIFBLSSBjbGllbnQgbWFpbnRhaW5zIHRo
ZSBjdXJyZW50IENSTCBpbiBlbGVjdHJvbmljIGZvcm1hIGxvY2FsIGNhY2hlOg0NVGhlIHJldm9j
YXRpb24gaW5mb3JtYXRpb24gb24gQkYgaXMgYXNzdW1lZCBhcyB0aGUgaW5pdGlhbCBjb25kaXRp
b24uICBCRiBpcyBhIGxpc3Qgb2YgcmV2b2tlZCBjZXJ0aWZpY2F0ZXM7IGVhY2ggY2VydGlmaWNh
dGUgaXMgbGlzdGVkIHdpdGggYSByZXZvY2F0aW9uIHJlYXNvbiAod2hpY2ggbWF5IGJlIJN1bnNw
ZWNpZmllZJQpLiAgDQ1UaGUgbGlzdCBvZiByZXZva2VkIGNlcnRpZmljYXRlcyBMIHdpdGggbiBl
bnRyaWVzIGRlbm90ZWQgYXMgTGkgd2hlcmUgMSA8PSBpIDw9IG4uICAoVGhlIHZhbHVlIG4gbWF5
IHNocmluayBvciBncm93IGFzIHRoZSBjb21iaW5hdGlvbiBwcm9jZXNzIHByb2NlZWRzLikNDUlu
aXRpYWxpemUgTCB0byB0aGUgcmV2b2NhdGlvbiBub3RpY2VzIG9uIEJGLiAgRm9yIGVhY2ggY2Vy
dGlmaWNhdGUgQyBvbiB0aGUgZGVsdGEgQ1JMLCB1cGRhdGUgdGhlIGNvbnRlbnRzIG9mIEwgYXMg
Zm9sbG93cy4NDUEgY2VydGlmaWNhdGUgQyBpcyBhZGRlZCB0byB0aGUgbGlzdCBvZiByZXZva2Vk
IGNlcnRpZmljYXRlcyBMIGFzIGZvbGxvd3M6DUlmICBhIGNlcnRpZmljYXRlIEMgYXBwZWFycyBv
biB0aGUgZGVsdGEgQ1JMIEQsIGFuZCBDIGlzIG5vdCBjdXJyZW50bHkgaW4gdGhlIGxpc3QgTCwg
dGhlbjoNaWYgQyBoYXMgYSByZXZvY2F0aW9uIHJlYXNvbiBvdGhlciB0aGFuIJNyZW1vdmVGcm9t
Q1JMlCwgYWRkIEMgYXMgYSBuZXcgZW50cnkgaW4gIHRoZSBsaXN0IG9mIHJldm9rZWQgY2VydGlm
aWNhdGVzIEwuDUlmIEMgaGFzIHJldm9jYXRpb24gcmVhc29uIJNyZW1vdmVGcm9tQ1JMlCwgc2tp
cCB0aGlzIGNlcnRpZmljYXRlLiAgTm8gdXBkYXRlIHRvIHRoZSBjYWNoZSBpcyBuZWVkZWQuDUlm
IGEgY2VydGlmaWNhdGUgQyBhcHBlYXJzIG9uIHRoZSBkZWx0YSBDUkwgRCwgYW5kIEMgaXMgcHJl
c2VudGx5IGxpc3RlZCBpbiBMIGFzIGVudHJ5IExpLCB0aGVuOg1JZiBDIGhhcyByZXZvY2F0aW9u
IHJlYXNvbmlzIGxpc3RlZCBvbiB0aGUgZGVsdGEgQ1JMIHdpdGggYSByZXZvY2F0aW9uIHJlYXNv
biBvZiCTcmVtb3ZlRnJvbUNSTJQsIHRoZW4gZGVsZXRlIGVudHJ5IExpIA1JZiAgQyBoYXMgaXMg
bGlzdGVkIG9uIHRoZSBkZWx0YSBDUkwgd2l0aG91dCBhIHJldm9jYXRpb24gcmVhc29uIG9yIHdp
dGggYSByZXZvY2F0aW9uIHJlYXNvbiBvdGhlciB0aGFuIJNyZW1vdmVGcm9tQ1JMLJQsIHRoZW4g
dXBkYXRlIGNoYW5nZSB0aGUgcmVhc29uIGNvZGUgYXNzb2NpYXRlZCB3aXRoIExpIHRvIHRoZSBy
ZWFzb24gY29kZSBzcGVjaWZpZWQgaW4gdGhlIGRlbHRhIENSTC4NDVRoZSBjb21iaW5hdGlvbiBv
ZiBCRiBhbmQgRCBmb3JtcyBhIG5ldyBjb21wbGV0ZSBmdWxsIENSTCB3aXRoIENSTCBudW1iZXIg
Wi4gIFRoaXMgY29tcGxldGUgZnVsbCBDUkwgaXMgYXNzdW1lZCB0byBoYXZlcyBjb21wbGV0ZSBp
bmZvcm1hdGlvbiB1bnRpbCB0aGUgdGltZSBzcGVjaWZpZWQgaW4gdGhlIG5leHQgdXBkYXRlIGZp
ZWxkIGluIHRoZSBkZWx0YSBDUkwgaXMgcmVhY2hlZC4gIElmIGEgcmVseWluZyBwYXJ0eSBpcyB2
YWxpZGF0aW5nIGEgY2VydGlmaWNhdGUgd2l0aCByZXNwZWN0IHRvIHRpbWUgVCwgIGFuZCBUIGlz
IGJlZm9yZSB0aGUgbmV4dCB1cGRhdGUgZmllbGQgaW4gdGhlIGRlbHRhIENSTCwgdGhleSBtYXkg
YXNzdW1lIGNvbXBsZXRlIGluZm9ybWF0aW9uLg0NSWYgYW4gdW5leHBpcmVkIGNlcnRpZmljYXRl
IEMgd2l0aGluIHRoZSBzY29wZSBvZiAgdGhlIGNvbnN0cnVjdGVkIENSTCBpcyBub3QgbGlzdGVk
LCB0aGVuIGNlcnRpZmljYXRlIEMgaXMgbm90IHJldm9rZWQgZm9yIG9uZSBvZiB0aGUgcmV2b2Nh
dGlvbiByZWFzb25zIGNvdmVyZWQgYnkgdGhpcyBDUkwuICBJZiB0aGUgY29uc3RydWN0ZWQgQ1JM
IGNvdmVycyBhbGwgcmVhc29ucywgdGhlbiB0aGUgY2VydGlmaWNhdGUgQyBpcyBub3QgcmV2b2tl
ZC4NDVVzaW5nIERlbHRhcyB0byBEaXN0cmlidXRlIFJldm9jYXRpb24gSW5mb3JtYXRpb24NDVRo
aXMgc2VjdGlvbiBwcm92aWRlcyB0aHJlZSBkaWZmZXJlbnQgc2NlbmFyaW9zIGZvciB0aGUgdXNl
IG9mIGRlbHRhIENSTHMuICBGb3IgdGhlIHB1cnBvc2Ugb2YgdGhlc2UgZXhhbXBsZXMsIGFzc3Vt
ZSBhIGdvYWwgb2YgaGUgZ29hbCBpcyB0byBwcm92aWRpbmdlIHJldm9jYXRpb24gaW5mb3JtYXRp
b24gdG8gcmVseWluZyBwYXJ0aWVzIHRoYXQgaXMgbm8gbW9yZSB0aGFuIG9uZSBob3VyIG9sZC4g
e3t7IFdoZXJlIGRvZXMgdGhpcyBjb21lIGZyb20/ICBFeGFtcGxlPyAgSXQgaXMgY2VydGFpbmx5
IG5vdCBhIFBLSVggcmVxdWlyZW1lbnQhIH19fQ0NDVRoZSBmb2xsb3dpbmcgbm90YXRpb24gaXMg
dXNlZCB0byBkZW5vdGUgYSByZXZva2VkIGNlcnRpZmljYXRlIG9uIGEgQ1JMOiAgDQkJWHIJY2Vy
dGlmaWNhdGUgWCBpcyBsaXN0ZWQgZm9yIHJlYXNvbiByLCB3aGVyZSByIGluIHthLGssaCxyfSAN
VGhlIHJlYXNvbiBjb2RlcyB7YSxrLGgscn0gY29ycmVzcG9uZCB0byCTYWZmaWxpYXRpb24gY2hh
bmdlZJQsIJNrZXkgY29tcHJvbWlzZZQsIJNjZXJ0aWZpY2F0ZSBob2xklCwgYW5kIJNyZW1vdmUg
ZnJvbSBDUkyUIHJlc3BlY3RpdmVseS4NDShOb3RlOiAgVGhlIHJlbWFpbmluZyByZWFzb24gY29k
ZXMgYXJlIG9taXR0ZWQgZm9yIHNpbXBsaWNpdHkuICBUaGUgaGFuZGxpbmcgb2YgY2VydGlmaWNh
dGVzIHJldm9rZWQgZm9yICB0aGUgcmVhc29ucyCTdW5zcGVjaWZpZWSULCCTQ0EgY29tcHJvbWlz
ZZQsIJNzdXBlcnNlZGVklCwgYW5kIJNjZXNzYXRpb25PZk9wZXJhdGlvbpQgYXJlIGlkZW50aWNh
bCB0byCTYWZmaWxpYXRpb24gY2hhbmdlZCBvciCTa2V5IGNvbXByb21pc2WUKS4NDQ0Ne3t7DVdo
ZXJlIGFyZSB0aGUgcmVzdD8gIEFnYWluLCBtYXliZSB0aGlzIGlzIGJlY2F1c2Ugd2UgbWFkZSBh
IGNsdW1zeSB0cmFuc2l0aW9uIGludG8gYW4gZXhhbXBsZS4NDSAgIENSTFJlYXNvbiA6Oj0gRU5V
TUVSQVRFRCB7DSAgICAgICAgdW5zcGVjaWZpZWQgICAgICAgICAgICAgKDApLA0gICAgICAgIGtl
eUNvbXByb21pc2UgICAgICAgICAgICgxKSwNICAgICAgICBjQUNvbXByb21pc2UgICAgICAgICAg
ICAoMiksDSAgICAgICAgYWZmaWxpYXRpb25DaGFuZ2VkICAgICAgKDMpLA0gICAgICAgIHN1cGVy
c2VkZWQgICAgICAgICAgICAgICg0KSwNICAgICAgICBjZXNzYXRpb25PZk9wZXJhdGlvbiAgICAo
NSksDSAgICAgICAgY2VydGlmaWNhdGVIb2xkICAgICAgICAgKDYpLA0gICAgICAgIHJlbW92ZUZy
b21DUkwgICAgICAgICAgICg4KSB9DX19fQ0NRXhhbXBsZSAjMQ0NVGhlIGV4YW1wbGUgYmVsb3cg
c2hvd3MgdGhlICJ0cmFkaXRpb25hbCIgbWV0aG9kIG9mIGlzc3VpbmcgZGVsdGEgLUNSTHMuIElu
IHRoaXMgZXhhbXBsZSwgZnVsbCBDUkxzIGFyZSBpc3N1ZWQgb25jZSBldmVyeSAzIGhvdXJzIGFu
ZCBkZWx0YXMgYXJlIGlzc3VlZCBvbmNlIGFuIGhvdXIuIEZvciBjb25zaXN0ZW5jeSwgdGhlIGlz
c3VlciBiZWdpbnMgaXNzdWluZyBkZWx0YXMgYXQgdGhlIHNhbWUgdGltZSBhcyB0aGUgdmVyeSBm
aXJzdCBmdWxsIENSTC4gQWZ0ZXIgdGhhdCwgaG93ZXZlciwgYSBkZWx0YSBjYW4gYWx3YXlzIHVz
ZSBhIHByZXZpb3VzbHkgaXNzdWVkIGZ1bGwgQ1JMIGFzIGl0cyBiYXNlLiBOb3RpY2UgdGhhdCBz
dGFydGluZyB3aXRoIGNSTE51bWJlciA0LCB0aGUgZGVsdGEgQ1JMIGlzc3VlZCBhdCB0aGUgc2Ft
ZSB0aW1lIGFzIGEgZnVsbCBDUkwgdXNlcyB0aGUgcHJldmlvdXNseSBpc3N1ZWQgZnVsbCBDUkwg
YXMgaXRzIGJhc2UuIEhvd2V2ZXIsIHRoZSBkZWx0YS1DUkxzIG5ldmVyIHByb3ZpZGUgbW9yZSB0
aGFuIDMgaG91cnMgb2YgaGlzdG9yeS4NDUluIHRoaXMgZXhhbXBsZToNQ2VydGlmaWNhdGUgMTQg
d2FzIHJldm9rZWQgZm9yIGtleSBjb21wcm9taXNlIGJlZm9yZSAxMjowMCB3aGVuIHRoZSBmaXJz
dCBDUkwgd2FzIGlzc3VlZC4NQ2VydGlmaWNhdGUgMTI0IHdhcyByZXZva2VkIGZvciBrZXkgY29t
cHJvbWlzZSBiZXR3ZWVuIDEyOjAwIGFuZCAxMzowMC4NQ2VydGlmaWNhdGUgMzkgd2FzIHBsYWNl
ZCBvbiBob2xkIGJldHdlZW4gMTQ6MDAgYW5kIDE1OjAwLCBhbmQgaXRzIHN1c3BlbnNpb24gd2Fz
IGxpZnRlZCBiZXR3ZWVuIDE2OjAwIGFuZCAxNzowMC4NQ2VydGlmaWNhdGUgNjcgd2FzIHJldm9r
ZWQgZm9yIGFuIGFmZmlsaWF0aW9uIGNoYW5nZSBiZXR3ZWVuIDE2MTU6MDAgYW5kIDE3MTY6MDAu
ICBUaGUgcmVhc29uIHdhcyBjaGFuZ2VkIHRvIGtleSBjb21wcm9taXNlIGJldHdlZW4gMTg2OjAw
IGFuZCAxOTc6MDAue3t7IFRoZXNlIHR3byB0aW1lIHNwYW5zIGNhbm5vdCBiZSB0aGUgc2FtZSEg
fX19Lg0NY3VycmVudCB0aW1lICAgICAHUmV2b2tlZCBjZXJ0aWZpY2F0ZXMHRnVsbCBDUkwHRGVs
dGEtQ1JMBwcxMjowMAd7MTRrfSAgICAgICAgICAgIAdjUkxOdW1iZXIgPSAxICAgICAgICAgICAg
ICAgICAgIHRoaXNVcGRhdGUgPSAxMjowMCAgICAgICAgICAgICAgbmV4dFVwZGF0ZSA9IDE1OjAw
ICAgICAgICAgICAgICBDZXJ0aWZpY2F0ZUxpc3QgPSB7MTRrfQdjUkxOdW1iZXIgPSAxICAgICAg
ICAgICAgICAgICAgIHRoaXNVcGRhdGUgPSAxMjowMA1uZXh0VXBkYXRlID0gMTM6MDAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBC
YXNlQ1JMTnVtYmVyID0gMQ1DZXJ0aWZpY2F0ZUxpc3QgPSB7fSAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAcHMTM6MDAHezE0aywgMTI0a30gICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAHB2NSTE51bWJlciA9IDIgICAgICAgICAg
ICAgICAgICAgdGhpc1VwZGF0ZSA9IDEzOjAwDW5leHRVcGRhdGUgPSAxNDowMCAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJhc2VD
UkxOdW1iZXIgPSAxDUNlcnRpZmljYXRlTGlzdCA9IHsxMjRrfSAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAcHMTQ6MDAHezE0aywgMTI0a30gICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAHB2NSTE51bWJlciA9IDMgICAgICAgICAg
ICAgICAgICAgdGhpc1VwZGF0ZSA9IDE0OjAwDW5leHRVcGRhdGUgPSAxNTowMCAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJhc2VD
UkxOdW1iZXIgPSAxDUNlcnRpZmljYXRlTGlzdCA9IHsxMjRrfSAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAcHMTU6MDAHezE0aywgMTI0aywgMzlofSAg
IAdjUkxOdW1iZXIgPSA0ICAgICAgICAgICAgICAgICAgIHRoaXNVcGRhdGUgPSAxNTowMCAgICAg
ICAgICAgICAgbmV4dFVwZGF0ZSA9IDE4OjAwICAgICAgICAgICAgICBDZXJ0aWZpY2F0ZUxpc3Qg
PSB7MTRrLCAxMjRrLCAzOWh9B2NSTE51bWJlciA9IDQNdGhpc1VwZGF0ZSA9IDE1NjowMCAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbmV4dFVwZGF0ZSA9IDE2Nzow
MCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCYXNlQ1JMTnVtYmVy
ID0gMSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDZXJ0aWZpY2F0
ZUxpc3QgPSB7MTI0aywgMzlofQcHMTY6MDAHezE0aywgMTI0aywgMzloLCA2N2F9ICAgBwdjUkxO
dW1iZXIgPSA1DXRoaXNVcGRhdGUgPSAxNjowMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgbmV4dFVwZGF0ZSA9IDE3OjAwICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIEJhc2VDUkxOdW1iZXIgPSA0ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIENlcnRpZmljYXRlTGlzdCA9IHszOWgsIDY3YX1XaHkgaXMg
MzloIGhlcmU/ICBJdCBpcyBvbiB0aGUgYmFzZSEHBzE3OjAwB3sxNGssIDEyNGssIDY3YX0gICAH
B2NSTE51bWJlciA9IDYNdGhpc1VwZGF0ZSA9IDE3OjAwICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBuZXh0VXBkYXRlID0gMTg6MDAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgQmFzZUNSTE51bWJlciA9IDQgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2VydGlmaWNhdGVMaXN0ID0gezM5ciwgNjdhfQcH
MTg6MDAHezE0aywgMTI0aywgNjdhfSAgIAdjUkxOdW1iZXIgPSA3ICAgICAgICAgICAgICAgICAg
IHRoaXNVcGRhdGUgPSAxODowMCAgICAgICAgICAgICAgbmV4dFVwZGF0ZSA9IDIxOjAwICAgICAg
ICAgICAgICBDZXJ0aWZpY2F0ZUxpc3QgPSB7MTRrLCAxMjRrLCA2N2F9B2NSTE51bWJlciA9IDcN
dGhpc1VwZGF0ZSA9IDE4OjAwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBuZXh0VXBkYXRlID0gMTk6MDAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgQmFzZUNSTE51bWJlciA9IDQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgQ2VydGlmaWNhdGVMaXN0ID0gezM5ciwgNjdhfQcHMTk6MDAHezE0aywgMTI0
aywgNjdrfSAgIAcHY1JMTnVtYmVyID0gOA10aGlzVXBkYXRlID0gMTk6MDAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5leHRVcGRhdGUgPSAyMDowMCAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCYXNlQ1JMTnVtYmVyID0gNyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDZXJ0aWZpY2F0ZUxpc3QgPSB7
NjdrfQcHDQ1Db25zZXF1ZW5jZXMgb2YgdGhpcyANDQ1TY2VuYXJpbyAjMg0NVGhlIGV4YW1wbGUg
YmVsb3cgc2hvd3MgdGhlICJzbGlkaW5nIHdpbmRvdyIgbWV0aG9kIG9mIGlzc3VpbmcgZGVsdGEt
Q1JMcy4gSW4gdGhpcyBleGFtcGxlLCBmdWxsIENSTHMgYXJlIGlzc3VlZCBvbmNlIGV2ZXJ5IDMg
aG91cnMgYW5kIGRlbHRhcyBhcmUgaXNzdWVkIG9uY2UgYW4gaG91ci4gRm9yIGNvbnNpc3RlbmN5
LCB0aGUgaXNzdWVyIGJlZ2lucyBpc3N1aW5nIGRlbHRhcyBhdCB0aGUgc2FtZSB0aW1lIGFzIHRo
ZSB2ZXJ5IGZpcnN0IGZ1bGwgQ1JMLiBOb3RpY2UgdGhhdCBzdGFydGluZyB3aXRoIGNSTE51bWJl
ciA3LCB0aGUgZGVsdGEgQ1JMIGlzc3VlZCBhdCB0aGUgc2FtZSB0aW1lIGFzIGEgZnVsbCBDUkwg
ZG9lcyBub3QgdXNlIHRoZSBwcmV2aW91c2x5IGlzc3VlZCBmdWxsIENSTCBhcyBpdHMgYmFzZSBi
dXQgdGhlIHByZWNlZGluZyBDUkwgaW5zdGVhZC4gIEhvd2V2ZXIsIHRoZXNlIGRlbHRhLUNSTHMg
bmV2ZXIgcHJvdmlkZSBtb3JlIHRoYW4gNiBob3VycyBvZiBoaXN0b3J5Lg0NQXMgaW4gZXhhbXBs
ZSAjMToNQ2VydGlmaWNhdGUgMTQgd2FzIHJldm9rZWQgZm9yIGtleSBjb21wcm9taXNlIGJlZm9y
ZSAxMjowMCB3aGVuIHRoZSBmaXJzdCBDUkwgd2FzIGlzc3VlZC4NQ2VydGlmaWNhdGUgMTI0IHdh
cyByZXZva2VkIGZvciBrZXkgY29tcHJvbWlzZSBiZXR3ZWVuIDEyOjAwIGFuZCAxMzowMC4NQ2Vy
dGlmaWNhdGUgMzkgd2FzIHBsYWNlZCBvbiBob2xkIGJldHdlZW4gMTQ6MDAgYW5kIDE1OjAwLCBh
bmQgaXRzIHN1c3BlbnNpb24gd2FzIGxpZnRlZCBiZXR3ZWVuIDE2OjAwIGFuZCAxNzowMC4NQ2Vy
dGlmaWNhdGUgNjcgd2FzIHJldm9rZWQgZm9yIGFuIGFmZmlsaWF0aW9uIGNoYW5nZSBiZXR3ZWVu
IDE2MTU6MDAgYW5kIDE3MTY6MDAuICBUaGUgcmVhc29uIHdhcyBjaGFuZ2VkIHRvIGtleSBjb21w
cm9taXNlIGJldHdlZW4gMTg2OjAwIGFuZCAxOTc6MDAuIHt7eyBBZ2FpbiwgdGhlc2UgY2Fubm90
IGhhdmUgdGhlIHNhbWUgdGltZSBzcGFuISB9fX0NDQ1jdXJyZW50IHRpbWUgICAgIAdSZXZva2Vk
IGNlcnRpZmljYXRlcwdGdWxsIENSTAdEZWx0YS1DUkwHBzEyOjAwB3sxNGt9ICAgICAgICAgICAg
B2NSTE51bWJlciA9IDEgICAgICAgICAgICAgICAgICAgdGhpc1VwZGF0ZSA9IDEyOjAwICAgICAg
ICAgICAgICBuZXh0VXBkYXRlID0gMTU6MDAgICAgICAgICAgICAgIENlcnRpZmljYXRlTGlzdCA9
IHsxNGt9B2NSTE51bWJlciA9IDEgICAgICAgICAgICAgICAgICAgdGhpc1VwZGF0ZSA9IDEyOjAw
DW5leHRVcGRhdGUgPSAxMzowMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIEJhc2VDUkxOdW1iZXIgPSAxDUNlcnRpZmljYXRlTGlz
dCA9IHt9ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
BwcxMzowMAd7MTRrLCAxMjRrfSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IAcHY1JMTnVtYmVyID0gMiAgICAgICAgICAgICAgICAgICB0aGlzVXBkYXRlID0gMTM6MDANbmV4
dFVwZGF0ZSA9IDE0OjAwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgQmFzZUNSTE51bWJlciA9IDENQ2VydGlmaWNhdGVMaXN0ID0g
ezEyNGt9ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
BwcxNDowMAd7MTRrLCAxMjRrfSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IAcHY1JMTnVtYmVyID0gMyAgICAgICAgICAgICAgICAgICB0aGlzVXBkYXRlID0gMTQ6MDANbmV4
dFVwZGF0ZSA9IDE1OjAwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgQmFzZUNSTE51bWJlciA9IDENQ2VydGlmaWNhdGVMaXN0ID0g
ezEyNGt9ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
BwcxNTowMAd7MTRrLCAxMjRrLCAzOWh9ICAgB2NSTE51bWJlciA9IDQgICAgICAgICAgICAgICAg
ICAgdGhpc1VwZGF0ZSA9IDE1OjAwICAgICAgICAgICAgICBuZXh0VXBkYXRlID0gMTg6MDAgICAg
ICAgICAgICAgIENlcnRpZmljYXRlTGlzdCA9IHsxNGssIDEyNGssIDM5aH0HY1JMTnVtYmVyID0g
NA10aGlzVXBkYXRlID0gMTU2OjAwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBuZXh0VXBkYXRlID0gMTY3OjAwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIEJhc2VDUkxOdW1iZXIgPSAxICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIENlcnRpZmljYXRlTGlzdCA9IHsxMjRrLCAzOWh9BwcxNjowMAd7MTRr
LCAxMjRrLCAzOWgsIDY3YX0gICAHB2NSTE51bWJlciA9IDUNdGhpc1VwZGF0ZSA9IDE2OjAwICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBuZXh0VXBkYXRlID0gMTc6
MDAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQmFzZUNSTE51bWJl
ciA9IDEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2VydGlmaWNh
dGVMaXN0ID0gezEyNGssIDM5aCwgNjdhfQcHMTc6MDAHezE0aywgMTI0aywgNjdhfSAgIAcHY1JM
TnVtYmVyID0gNg10aGlzVXBkYXRlID0gMTc6MDAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIG5leHRVcGRhdGUgPSAxODowMCAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBCYXNlQ1JMTnVtYmVyID0gMSAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBDZXJ0aWZpY2F0ZUxpc3QgPSB7MTI0aywgMzlyLCA2N2F9
BwcxODowMAd7MTRrLCAxMjRrLCA2N2F9ICAgB2NSTE51bWJlciA9IDcgICAgICAgICAgICAgICAg
ICAgdGhpc1VwZGF0ZSA9IDE4OjAwICAgICAgICAgICAgICBuZXh0VXBkYXRlID0gMjE6MDAgICAg
ICAgICAgICAgIENlcnRpZmljYXRlTGlzdCA9IHsxNGssIDEyNGssIDY3YX0HY1JMTnVtYmVyID0g
Nw10aGlzVXBkYXRlID0gMTg6MDAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIG5leHRVcGRhdGUgPSAxOTowMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBCYXNlQ1JMTnVtYmVyID0gMSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBDZXJ0aWZpY2F0ZUxpc3QgPSB7MTI0aywgMzlyLCA2N2F9BwcxOTowMAd7
MTRrLCAxMjRrLCA2N2t9ICAgBwdjUkxOdW1iZXIgPSA4DXRoaXNVcGRhdGUgPSAxOTowMCAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbmV4dFVwZGF0ZSA9IDIwOjAw
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJhc2VDUkxOdW1iZXIg
PSA0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENlcnRpZmljYXRl
TGlzdCA9IHszOXIsIDY3a30HBw1Ob3RlIHRoYXQgdGhlIGRlbHRhIENSTHMgYXJlIG1hcmdpbmFs
bHkgbGFyZ2VyIHRoYW4gaW4gdGhlIGZpcnN0IHNjZW5hcmlvIHNpbmNlIHRoZXkgY292ZXIgYSBs
b25nZXIgdGltZSBwZXJpb2QuICBPbiB0aGUgb3RoZXIgaGFuZCwgYSByZWx5aW5nIHBhcnR5IGlz
IGxlc3MgbGlrZWx5IHRvIGRvd25sb2FkIGZ1bGwgQ1JMcyBpbiB0aGUgc2Vjb25kIHNjZW5hcmlv
Lg0NRm9yIGV4YW1wbGUsIGEgcmVseWluZyBwYXJ0eSB0aGF0IHZhbGlkYXRlZCBvbmUgY2VydGlm
aWNhdGUgYXQgMTI6MTUsIHRoZW4gYSBzZWNvbmQgY2VydGlmaWNhdGUgYXQgMTY6MTUgd291bGQg
bm90IHJlcXVpcmUgYSBuZXcgZnVsbCBDUkwgaW4gc2NlbmFyaW8gIzIuICBJbiBzY2VuYXJpbyAj
MSwgdGhlIHJlbHlpbmcgcGFydHkgd291bGQgYmUgZm9yY2VkIHRvIG9idGFpbiBib3RoIGZ1bGwg
Q1JMIDQgYW5kIGRlbHRhIENSTCA1Lg0NU2NlbmFyaW8gIzMgQWxsb3dpbmcgZm9yIFJlcGxpY2F0
aW9uL1Byb3BhZ2F0aW9uIERlbGF5cw0NSW4gdGhpcyBzY2VuYXJpbywgZnVsbCBDUkxzIGFuZCBk
ZWx0YSBDUkxzIGFyZSByZXBsaWNhdGVkIHRocm91Z2hvdXQgYSByZXBvc2l0b3J5IHN5c3RlbS4g
IERhdGEgaXMgcmVwbGljYXRlZCB0aHJvdWdoIHRoZSBzeXN0ZW0gYXQgZGlmZmVyZW50IHJhdGVz
IGJhc2VkIG9uIHRoZSBzaXplIG9mIHRoZSBmaWxlLiAgVGhlIENBIG9wZXJhdG9ycyBlc3RpbWF0
ZSB0aGF0IGZ1bGwgQ1JMcyB3aWxsIGJlIGF2YWlsYWJsZSB0aHJvdWdob3V0IHRoZSBzeXN0ZW0g
d2l0aGluIHRocmVlIGhvdXJzLiAgRGVsdGEgQ1JMcyB3aWxsIGJlIGF2YWlsYWJsZSB3aXRoaW4g
MTUgbWludXRlcy4gIChBc3N1bWUgdGhlIGluaXRpYWwgQ1JMIGlzIHNtYWxsIGFuZCB3aWxsIHBy
b3BhZ2F0ZSBhcyBpZiBhIGRlbHRhIENSTCB0byByZXNvbHZlIHRoZSBib290c3RyYXAgaXNzdWVz
LikNDVRoZSBleGFtcGxlIGJlbG93IHVzZXMgdGhlICJzbGlkaW5nIHdpbmRvdyIgbWV0aG9kIG9m
IGlzc3VpbmcgZGVsdGEtQ1JMcywgYnV0IG92ZXJsYXBzIHRoZSB0aGlzVXVwZGF0ZSBhbmQgbmV4
dFV1cGRhdGUgdGltZXMgdG8gYWxsb3cgZm9yIHByb3BhZ2F0aW9uLi4gSW4gdGhpcyBleGFtcGxl
LCBmdWxsIENSTHMgYXJlIGlzc3VlZCBvbmNlIGV2ZXJ5IDMgaG91cnMgYW5kIGRlbHRhcyBhcmUg
aXNzdWVkIG9uY2UgYW4gaG91cmV2ZXJ5IDQ1IG1pbnV0ZXMuIEZvciBjb25zaXN0ZW5jeSwgdGhl
IGlzc3VlciBiZWdpbnMgaXNzdWluZyBkZWx0YXMgYXQgdGhlIHNhbWUgdGltZSBhcyB0aGUgdmVy
eSBmaXJzdCBmdWxsIENSTC4gTm90aWNlIHRoYXQgc3RhcnRpbmcgd2l0aCBjUkxOdW1iZXIgNywg
dGhlIGRlbHRhIENSTCBpc3N1ZWQgYXQgdGhlIHNhbWUgdGltZSBhcyBhIGZ1bGwgQ1JMIGRvZXMg
bm90IHVzZSB0aGUgcHJldmlvdXNseSBpc3N1ZWQgZnVsbCBDUkwgYXMgaXRzIGJhc2UgYnV0IHRo
ZSBwcmVjZWRpbmcgQ1JMIGluc3RlYWQuICBIb3dldmVyLCB0aGVzZSBkZWx0YS1DUkxzIG5ldmVy
IHByb3ZpZGUgbW9yZSB0aGFuIDYgaG91cnMgb2YgaGlzdG9yeS4NDUFzIGluU2ltaWxhcmx5IHRv
IGV4YW1wbGVzICMxIGFuZCAjMjoNQ2VydGlmaWNhdGUgMTQgd2FzIHJldm9rZWQgZm9yIGtleSBj
b21wcm9taXNlIGJlZm9yZSAxMjowMCB3aGVuIHRoZSBmaXJzdCBDUkwgd2FzIGlzc3VlZC4NQ2Vy
dGlmaWNhdGUgMTI0IHdhcyByZXZva2VkIGZvciBrZXkgY29tcHJvbWlzZSBiZXR3ZWVuIDEyOjAw
IGFuZCAxMzowMDEyOjQ1Lg1DZXJ0aWZpY2F0ZSAzOSB3YXMgcGxhY2VkIG9uIGhvbGQgYmV0d2Vl
biAxNDowMCAxNSBhbmQgMTU6MDAsIGFuZCBpdHMgc3VzcGVuc2lvbiB3YXMgbGlmdGVkIGJldHdl
ZW4gMTYxNTowMCA0NSBhbmQgMTc6MDAxNjozMC4NQ2VydGlmaWNhdGUgNjcgd2FzIHJldm9rZWQg
Zm9yIGFuIGFmZmlsaWF0aW9uIGNoYW5nZSBiZXR3ZWVuIDE2OjAwIDE1OjAwIGFuZCAxNzowMDE1
OjQ1LiAgVGhlIHJlYXNvbiB3YXMgY2hhbmdlZCB0byBrZXkgY29tcHJvbWlzZSBiZXR3ZWVuIDE4
NjowMCBhbmQgMTc6MDAxODo0NS4gIHt7eyBDYW5ub3QgaGF2ZSBzYW1lIHRpbWUgc3BhbiEgfX19
DQ1jdXJyZW50IHRpbWUgICAgIAdSZXZva2VkIGNlcnRpZmljYXRlcwdGdWxsIENSTAdEZWx0YS1D
UkwHBzEyOjAwB3sxNGt9ICAgICAgICAgICAgB2NSTE51bWJlciA9IDEgICAgICAgICAgICAgICAg
ICAgdGhpc1VwZGF0ZSA9IDEyOjAwICAgICAgICAgICAgICBuZXh0VXBkYXRlID0gMTg6MDAgICAg
ICAgICAgICAgIENlcnRpZmljYXRlTGlzdCA9IHsxNGt9B2NSTE51bWJlciA9IDEgICAgICAgICAg
ICAgICAgICAgdGhpc1VwZGF0ZSA9IDEyOjAwDW5leHRVcGRhdGUgPSAxMzoxNSAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDAwICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgQmFzZUNSTE51bWJlciA9IDENQ2VydGlmaWNhdGVMaXN0ID0ge30gICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAHBzEzOjAwMTI6NDUHezE0aywgMTI0
a30gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAHB2NSTE51bWJlciA9IDIg
ICAgICAgICAgICAgICAgICAgdGhpc1VwZGF0ZSA9IDEzOjAwMTI6NDUNbmV4dFVwZGF0ZSA9IDE0
OjE1ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgMTM6NDUNQmFzZUNSTE51bWJlciA9IDENQ2VydGlmaWNhdGVMaXN0ID0gezEyNGt9
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgBwcxNDow
MDEzOjMwB3sxNGssIDEyNGt9ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
BwdjUkxOdW1iZXIgPSAzICAgICAgICAgICAgICAgICAgIHRoaXNVcGRhdGUgPSAxNDowMDEzOjMw
DW5leHRVcGRhdGUgPSAxNDU6MTUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAzMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJhc2VDUkxOdW1iZXIgPSAxDUNlcnRp
ZmljYXRlTGlzdCA9IHsxMjRrfSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIAcHMTQ6MTUHezE0aywgMTI0a30gICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAHB2NSTE51bWJlciA9IDQgICAgICAgICAgICAgICAgICAgdGhpc1VwZGF0
ZSA9IDE0OjE1DW5leHRVcGRhdGUgPSAxNToxNSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJhc2VDUkxOdW1iZXIgPSAxDUNlcnRp
ZmljYXRlTGlzdCA9DXsxMjRrfQcHMTU6MDAHezE0aywgMTI0aywgMzlofSAgIAdjUkxOdW1iZXIg
PSA0ICAgICAgICAgICAgICAgICAgIDUgICAgICAgICAgICAgICAgICAgdGhpc1VwZGF0ZSA9IDE1
OjAwICAgICAgICAgICAgICBuZXh0VXBkYXRlID0gMjE6MDAgICAgICAgICAgICAgIENlcnRpZmlj
YXRlTGlzdCA9IHsxNGssIDEyNGssIDM5aH0HY1JMTnVtYmVyID0gNDUNdGhpc1VwZGF0ZSA9IDE1
NjowMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbmV4dFVwZGF0
ZSA9IDE3MTY6MTUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMDAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQmFzZUNSTE51bWJlciA9
IDEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2VydGlmaWNhdGVM
aXN0ID0gezEyNGssIDM5aH0HBzE2OjAwMTU6NDUHezE0aywgMTI0aywgMzloLCA2N2F9ICAgBwdj
UkxOdW1iZXIgPSA1Ng10aGlzVXBkYXRlID0gMTY6MDAxNTo0NSAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgbmV4dFVwZGF0ZSA9IDE2OjQ3OjE1ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJhc2VDUkxOdW1iZXIgPSAxICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENlcnRpZmljYXRlTGlzdCA9IHsxMjRr
LCAzOWgsIDY3YX0HBzE3OjAwMTY6MzAHezE0aywgMTI0aywgNjdhfSAgIAcHY1JMTnVtYmVyID0g
NjcNdGhpc1VwZGF0ZSA9IDE2OjM3OjAwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBuZXh0VXBkYXRlID0gMTg6MTUxNzozMCAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBCYXNlQ1JMTnVtYmVyID0gMSAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBDZXJ0aWZpY2F0ZUxpc3QgPSB7MTI0aywgMzlyLCA2N2F9
BwcxNzoxNQd7MTRrLCAxMjRrLCA2N2F9ICAgBwdjUkxOdW1iZXIgPSA4DXRoaXNVcGRhdGUgPSAx
NzoxNSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbmV4dFVwZGF0
ZSA9IDE4OjE1ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJhc2VD
UkxOdW1iZXIgPSAxICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENl
cnRpZmljYXRlTGlzdCA9IHsxMjRrLCAzOXIsIDY3YX0HBzE4OjAwB3sxNGssIDEyNGssIDY3YX0g
ICAHY1JMTnVtYmVyID0gNyAgICAgICAgICAgICAgICAgICA5ICAgICAgICAgICAgICAgICAgIHRo
aXNVcGRhdGUgPSAxODowMCAgICAgICAgICAgICAgbmV4dFVwZGF0ZSA9IDI0OjAwICAgICAgICAg
ICAgICBDZXJ0aWZpY2F0ZUxpc3QgPSB7MTRrLCAxMjRrLCA2N2F9B2NSTE51bWJlciA9IDc5DXRo
aXNVcGRhdGUgPSAxODowMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgbmV4dFVwZGF0ZSA9IDE5OjE1ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIDAwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJhc2VD
UkxOdW1iZXIgPSAxICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDUg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2VydGlmaWNhdGVMaXN0
ID0gezEyNGssIDM5ciwgNjdhfQcHMTkxODowMDQ1B3sxNGssIDEyNGssIDY3a30gICAHB2NSTE51
bWJlciA9IDgxMA10aGlzVXBkYXRlID0gMTg6NDU5OjAwICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBuZXh0VXBkYXRlID0gMjA6MTUxOTo0NSAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCYXNlQ1JMTnVtYmVyID0gNCAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA1ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIENlcnRpZmljYXRlTGlzdCA9IHszOXIsIDY3a30HBw1EZWx0YSBD
UkwgbnVtYmVyIDYgaXMgaXNzdWVkIGF0IDE3OjAwMTU6NDUuICBCeSAxNjowMDc6MTUsIGRlbHRh
IENSTCBudW1iZXIgNiBzaG91bGQgYmUgYXZhaWxhYmxlIHRocm91Z2hvdXQgdGhlIHN5c3RlbS4g
IEFzIGEgcmVzdWx0LCBkZWx0YSBDUkwgbnVtYmVyIDUgc3BlY2lmaWVkIDE3OjE1MTY6MDAgYXMg
aXRzIG5leHRVcGRhdGUgdGltZS4NDUhvd2V2ZXIsIEZ1bGwgZnVsbCBDUkwgQ1JMIG51bWJlciA0
IDUgd2FzIGlzc3VlZCBhdCAxNTowMCBhbmQgbWF5IG5vdCBiZSBhdmFpbGFibGUgdGhyb3VnaG91
dCB0aGUgc3lzdGVtIHVudGlsIDE4OjAwLiAgQXMgYSByZXN1bHQsIGRlbHRhIENSTCBudW1iZXIg
NiBtdXN0IGJlIGJhc2VkIG9uIEZ1bGwgZnVsbCBDUkwgbnVtYmVyIDEgd2hpY2ggd2FzIGlzc3Vl
ZCBhdCAxMjowMC4NDUlmIHRoZSByZWx5aW5nIHBhcnR5IGZpbmRzIEZ1bGwgZnVsbCBDUkwgbnVt
YmVyIDQgNSBpbiB0aGUgcmVwb3NpdG9yeSwgdGhleSBtYXkgc3RpbGwgYXBwbHkgZGVsdGEgQ1JM
IG51bWJlciA2IGFuZCBhY2hpZXZlIHRoZSBjb3JyZWN0IGFuc3dlci4NDUZpbmFsbHksIG5vdGUg
dGhhdCBhIENSTCBpc3N1ZXIgbXVzdCBnZW5lcmF0ZSBtb3JlIENSTHMgdG8gYWNoaWV2ZSB0aGUg
Z29hbCBvZiBzdGF0dXMgaW5mb3JtYXRpb24gdGhhdCBpcyBubyBtb3JlIHRoYW4gb25lIGhvdXIg
b2xkIHdoZW4gZmFjdG9yaW5nIGluIHRoZSBwcm9wYWdhdGlvbiBkZWxheXMuDQ0NAiBBIHJldm9j
YXRpb24gbm90aWNlIG1heSBvcHRpb25hbGx5IHNwZWNpZnkgaW4gdGhlIGludmFsaWRpdHkgZGF0
ZSBleHRlbnNpb24gdGhlIGRhdGUgYXQgZnJvbSB3aGljaCB0aGUgY2VydGlmaWNhdGUgc2hvdWxk
IGJlIGNvbnNpZGVyZWQgaW52YWxpZCBpbiB0aGUgaW52YWxpZGl0eSBkYXRlIGV4dGVuc2lvbiwg
YXMgd2VsbC4gIFRoaXMgZGF0ZSBtYXkgcHJlY2VkZSB0aGUgYWN0dWFsIHJldm9jYXRpb24gZGF0
ZS4gIFRoZSBpbnZhbGlkdHlpbnZhbGlkaXR5IGRhdGUgZXh0ZW5zaW9uIGRvZXMgbm90IGZlYXR1
cmUgaW4gdGhpcyBkaXNjdXNzaW9uLCBzbyBpdCBpcyBub3QgY29uc2lkZXJlZCBmdXJ0aGVyIGlu
IHRoaXMgcGFwZXIuDQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAQAAAEEAACXBAAAoQQAAPgEAAD9BAAAAgUAAPoHAAAMCAAAGQkAACQJAAA5CQAAOgkA
ANYJAADkCQAA5QkAAB0KAAAeCgAAIQoAACQKAAAlCgAAMAoAADEKAACMCgAAjQoAAJwKAACjCgAA
tAoAAEoLAABfCwAAaQsAAHILAABqDAAAyg0AAMsNAAAhDgAAJg4AACgOAAAqDgAAKw4AADUOAABB
DgAATQ4AAGoOAAB0DgAAfQ4AAEYPAAD4APEA6vEA6ADoAOEA2tMAzADFzADMAMwA09oAvrCpvqIA
m42bjZuNmwCGeKmGAAAAAAAAGgAIgQEIgQRIAgAFaARDVUZjSAQAZGhrRFVGAA0BCIEESAIABWgE
Q1VGGgAIgQEIgQRIAgAFaANDVUZjSAMAZGjPQ1VGAA0BCIEESAIABWgDQ1VGDQAIgWNIAgBkaABD
VUYNAQiBBEgEAAVoa0RVRhoACIEBCIEESAIABWgAQ1VGY0gEAGRoa0RVRgANAQiBBEgCAAVoAENV
Rg0BCIEESAMABWjMQ1VGDQAIgWNIAwBkaMxDVUYNAAiBY0gDAGRozUNVRg0BCIEESAMABWjNQ1VG
DQNqAAAAADBKEgBVCAEDNgiBDQAIgWNIAgBkaPVCVUYNAQiBBEgCAAVo9UJVRg0BCIEESAEABWhA
RFVGAC4ABAAADAQAAA0EAAAdBQAAHgUAAIsFAACMBQAAkgUAAJMFAAA1BgAANgYAANgGAADZBgAA
OwkAADwJAACPCQAAkAkAAD8LAABACwAAyw0AAMwNAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAA
APsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD5AAAA
AAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAA
AAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7
AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAAtAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARAAAQyQBRcaAAAACAANDVUYAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQMAAAEAAAAB
DwAAFAAEAADwYQAAXWMAAP7+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC
AQECzA0AAEEOAABCDgAA8w8AAPQPAABpEAAAahAAAKkQAACqEAAAuBAAALkQAACFEgAAhhIAAPMT
AAD0EwAAChUAAAsVAADbFgAA3BYAACMXAAAkFwAA7xgAALoAAAAAAAAAAAAAAAC4AAAAAAAAAAAA
AAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgA
AAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAtgAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAA
AAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAA
ALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALYAAAAAAAAAAAAAAAC4AAAA
AAAAAAAAAAAAuAAAAAAAAAAAAAAAAAAAAAABAQAAAQAAAEQAAEMkAUXGgAAAAgADQ1VGAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ABVGDwAA8w8AAGoQAACoEAAAyhAAANAQAAD1EAAA+xAAAA4RAAATEQAAHREAACYRAAAoEQAANhEA
ADcRAABhEQAAmBEAAJwRAACdEQAAtxEAAL0RAADGEQAA0BEAANcRAADcEQAA6BEAAO0RAADyEQAA
BRIAAAYSAAAKEgAAEhIAABUSAAAWEgAAGxIAACUSAAApEgAALBIAAC4SAAD48fgA6uPc1c7A1cDV
sqOUo9UA1dwA3I0AjYYAeADOcQDOeM6NYwAAAAAaAAiBAQiBBEgCAAVoBkNVRmNIBABkaFBEVUYA
DQEIgQRIAgAFaAVDVUYaAAiBAQiBBEgCAAVoBUNVRmNIBABkaFBEVUYADQEIgQRIBAAFaFBEVUYN
AAiBY0gEAGRoUERVRh0ACIEBCIEESAMABWjRQ1VGDCoHY0gEAGRoT0RVRh0ACIEBCIEESAMABWjQ
Q1VGDCoHY0gEAGRoT0RVRhoACIEBCIEESAMABWjQQ1VGY0gEAGRoT0RVRgAaAAiBAQiBBEgCAAVo
BUNVRmNIBABkaE9EVUYADQAIgWNIAgBkaAVDVUYNAAiBY0gEAGRoT0RVRg0BCIEESAQABWhPRFVG
DQEIgQRIBAAFaE5EVUYNAAiBY0gEAGRoTkRVRg0ACIFjSAIAZGgDQ1VGDQAIgWNIAgBkaARDVUYA
Ji4SAAAwEgAAORIAAD0SAABBEgAAQhIAAEMSAABbEgAAZhIAAGgSAABwEgAAcRIAAHUSAAB6EgAA
fRIAAIISAACDEgAAtBIAAL0SAAA0EwAANRMAAGITAABlEwAAaBMAAGwTAABuEwAAfBMAAH4TAACH
EwAAjBMAAJATAACqEwAAxxMAAMwTAADREwAA7hMAAO8TAADwEwAA8hMAAPQTAAD1EwAA/xMAAA4U
AAAVFAAAHxQAAE4UAAD48eoA3PHV3OrO6s7c6s7cAMcAwLmrx9Wdx4+Ij8ePx4iPxwDAgYjAegB6
wAAAAAAAAAAAAAAAAAAAAAANAAiBY0gEAGRoUkRVRg0BCIEESAIABWgHQ1VGDQAIgWNIAgBkaAdD
VUYaAAiBAQiBBEgCAAVoB0NVRmNIBABkaFFEVUYAGgAIgQEIgQRIAgAFaAZDVUZjSAQAZGhRRFVG
ABoACIEBCIEESAMABWjRQ1VGY0gEAGRoUURVRgANAQiBBEgDAAVo0UNVRg0BCIEESAQABWhSRFVG
DQAIgWNIBABkaFFEVUYNAQiBBEgCAAVoBkNVRg0ACIFjSAIAZGgGQ1VGGgAIgQEIgQRIAgAFaAZD
VUZjSAQAZGhQRFVGAA0BCIEESAQABWhQRFVGDQAIgWNIBABkaFBEVUYNAAiBY0gCAGRoBUNVRgAt
ThQAAFgUAABZFAAAjhQAAAgVAAAbFQAAIhUAACwVAABHFQAASxUAAFgVAABsFQAAcBUAAH0VAACf
FgAAoBYAAAUXAAAKFwAADxcAACMXAAAkFwAALxcAADgXAAA9FwAAQhcAAEMXAABEFwAAWhcAAFwX
AACdFwAAoxcAAKUXAACqFwAArRcAALMXAAC1FwAAthcAALgXAADeFwAA6xcAAO0XAADvFwAA/RcA
ABMYAAD48QDqAOPcANXOANXOAMcAwLkAtwCwqQDAuQCilI2GAH8AeLl/AHjAuQBxAAAAAAAAAA0B
CIEESAMABWjWQ1VGDQEIgQRIAwAFaNVDVUYNAAiBY0gDAGRo1UNVRg0ACIFjSAMAZGjUQ1VGDQEI
gQRIAwAFaNRDVUYaAAiBAQiBBEgDAAVo1ENVRmNIBABkaFdEVUYADQEIgQRIBAAFaFdEVUYNAQiB
BEgCAAVoIUNVRg0ACIFjSAIAZGghQ1VGAzUIgQ0BCIEESAQABWhiRFVGDQAIgWNIBABkaGJEVUYN
AAiBY0gDAGRo00NVRg0BCIEESAMABWjSQ1VGDQAIgWNIAwBkaNJDVUYNAQiBBEgEAAVoVERVRg0A
CIFjSAQAZGhURFVGDQEIgQRIBAAFaFFEVUYNAQiBBEgEAAVoU0RVRg0ACIFjSAQAZGhTRFVGACsT
GAAAFBgAABUYAAAvGAAAOxgAAEQYAABJGAAAgBgAAIEYAACDGAAAiBgAAJcYAACYGAAAmRgAALsY
AADAGAAAxRgAAO4YAADvGAAA8BgAAPEYAAAAGgAAFxoAABwaAAAlGgAALxoAADMaAABEGgAAvBoA
AL4aAADBGgAAwxoAAMQaAAAJGwAACxsAAAwbAAANGwAAgRsAAIobAADy6+Td1sjdAMEA3bqzAKyl
ALqeALoAl5AAkACzgrOCe7OXdG0AZgAAAAAAAAAAAAANAAiBY0gCAGRoIUNVRg0BCIEESAQABWhm
RFVGDQAIgWNIBABkaGZEVUYNAAiBY0gCAGRoHUNVRhoACIEBCIEESAIABWgdQ1VGY0gEAGRoYkRV
RgANAQiBBEgEAAVoZURVRg0ACIFjSAQAZGhlRFVGDQAIgWNIAgBkaAhDVUYNAQiBBEgEAAVoaURV
Rg0ACIFjSAQAZGhpRFVGDQAIgWNIBABkaGJEVUYNAQiBBEgEAAVoYkRVRg0BCIEESAMABWjXQ1VG
GgAIgQEIgQRIAgAFaBxDVUZjSAMAZGjXQ1VGAA0ACIFjSAIAZGgcQ1VGDQAIgWNIAwBkaNdDVUYN
AQiBBEgDAAVo1kNVRg0BCIEESAQABWhjRFVGGgAIgQEIgQRIAwAFaNZDVUZjSAQAZGhjRFVGJu8Y
AADxGAAAABoAAAEaAABDGgAARBoAAAobAAALGwAAURsAAFIbAADvGwAAugAAAAAAAAAAAAAAALgA
AAAAAAAAAAAAAAC6AAAAAAAAAAAAAAAAswAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAA
AAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAbAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABGAAAKJgALRgEARcaA
AQACAPVCVUYCAAAAAAAAAAAABAIABAIABAIAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAMAKAAAACkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAABAIAAyQBYSQBAAEAAABEAABDJAFFxoAAAAQAYkRVRgAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKihsA
AI8bAABKHAAAUxwAAFgcAABcHAAAXRwAAF8cAAB3HAAAgxwAAI8cAACWHAAAmxwAAKQcAACoHAAA
qxwAAKwcAACwHAAAtBwAALUcAADgHAAA5RwAAOocAADvHAAA8xwAABgdAAAbHQAAIh0AAGEdAACa
HQAAnB0AAJ4dAAC7HQAAUB4AAFEeAABaHgAAWx4AAHUeAACzHgAAth4AALkeAADSHgAAAh8AAAcf
AAD4APH4APEA7+bd7+bd793m793vANbPAMgAwcgAuqzPuqUAnpeQicF7iQB0AAAAAAAAAAAAAAAA
AA0ACIFjSAQAZGhrRFVGGgAIgQEIgQRIAgAFaCJDVUZjSAMAZGjaQ1VGAA0ACIFjSAMAZGjaQ1VG
DQEIgQRIAwAFaNtDVUYNAQiBBEgDAAVo3ENVRg0BCIEESAMABWjiQ1VGDQAIgWNIAwBkaNtDVUYa
AAiBAQiBBEgDAAVo2kNVRmNIBABkaGpEVUYADQEIgQRIAwAFaNpDVUYNAAiBY0gCAGRoIkNVRg0B
CIEESAIABWgiQ1VGDQEIgQRIBAAFaGpEVUYNAAiBY0gEAGRoakRVRhABCIEESAQABWhpRFVGNgiB
ABAACIE2CIFjSAQAZGhpRFVGAAM2CIENAAiBY0gCAGRoIUNVRg0BCIEESAIABWghQ1VGACvvGwAA
XhwAAF8cAAC1HAAAthwAADkdAAA6HQAAYR0AALgAAAAAAAAAAAAAAAC2AAAAAAAAAAAAAAAAsQAA
AAAAAAAAAAAAALYAAAAAAAAAAAAAAAC2AAAAAAAAAAAAAAAAtgAAAAAAAAAAAAAAAGoAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABGAAAKJgALRgQARcaAAQACAPVC
VUYCAAAAAAAAAAAABAIABAIABAIAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAMAKAAAACkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAABAAAAyQBYSQBAAEAAABGAAAKJgALRgEARcaAAQACAPVCVUYCAAAAAAAAAAAABAIA
BAIABAIAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAKAAAACkAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB2EdAABR
HgAA0x4AADofAAC4AAAAAAAAAAAAAAAAcQAAAAAAAAAAAAAAACoAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABGAAAKJgALRgQARcaAAQACAPVCVUYCAAAAAAAAAAAABAIA
BAIABAIAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAKAAAACkAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARgAACiYB
C0YEAEXGgAEAAgD1QlVGAQAAAAAAAAAAAAQCAAQCAAQCAAABAAAAAgAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAACAAEALgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEYAAAomAQtGBABFxoABAAIA9UJVRgEAAAAAAAAAAAAEAgAE
AgAEAgAAAQAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgABAC4AAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADBx8AAAwf
AABQHwAAVR8AAFofAACMHwAAkR8AAJYfAACzHwAAvx8AAMQfAADNHwAA1h8AANofAADyHwAAIiAA
ADEgAAA+IAAAXyAAAGAgAABhIAAAiCAAAIkgAACKIAAAQSEAAEIhAADIIQAAySEAAMohAAAcIgAA
ZyIAAGoiAABrIgAAkyIAAJUiAAB7IwAAniMAAMojAADMIwAA9yMAAPgjAAAFJAAAGiQAAFAkAABg
JAAAYSQAAGYkAAB1JAAAdiQAAHckAAB7JAAAfCQAAH4kAAD4APH4APH4AO/m3e/U7wDNxgC/uAC/
uAC2AL+4AK8ArwCoAKEAmgC2AJOMAIWaALaTAJMAAAANAQiBBEgEAAVobURVRg0BCIEESAIABWgm
Q1VGDQAIgWNIAgBkaCZDVUYNAAiBY0gEAGRobURVRg0BCIEESAMABWjoQ1VGDQAIgWNIBABkaGxE
VUYNAAiBY0gCAGRoJENVRgNIKgINAQiBBEgEAAVoZ0RVRg0ACIFjSAQAZGhnRFVGDQEIgQRIAwAF
aOZDVUYNAAiBY0gDAGRo5kNVRhABCIEESAQABWhsRFVGNgiBABABCIEESAQABWhrRFVGNgiBABAA
CIE2CIFjSAQAZGhrRFVGAAM2CIENAAiBY0gEAGRoa0RVRg0BCIEESAQABWhrRFVGADQ6HwAAch8A
ALIfAACzHwAA8h8AAPMfAABAIAAAQSAAAAIhAAADIQAAnSEAAJ4hAAAbIgAAuAAAAAAAAAAAAAAA
AHEAAAAAAAAAAAAAAABvAAAAAAAAAAAAAAAAagAAAAAAAAAAAAAAAG8AAAAAAAAAAAAAAABvAAAA
AAAAAAAAAAAAbwAAAAAAAAAAAAAAAG8AAAAAAAAAAAAAAABvAAAAAAAAAAAAAAAAbwAAAAAAAAAA
AAAAAG8AAAAAAAAAAAAAAABvAAAAAAAAAAAAAAAAAAAAAAAEAAADJAFhJAEAAQAAAEYAAAomAQtG
BABFxoABAAIA9UJVRgEAAAAAAAAAAAAEAgAEAgAEAgAAAgAAAAIAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAgABAC4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAABGAAAKJgELRgQARcaAAQACAPVCVUYBAAAAAAAAAAAABAIABAIA
BAIAAAIAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAQAuAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADBsiAAAcIgAA
ZyIAAMMiAAA5IwAAnyMAAAAkAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA
AAC2AAAAAAAAAAAAAAAAbwAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABGAAAKJgALRgIARcaA
AQACAPVCVUYCAAAAAAAAAAAEBAIABAIABAIAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAMAKAAAACkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAARgAACiYAC0YCAEXGgAEAAgD1QlVGAgAAAAAAAAAABAQCAAQCAAQCAAAB
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADACgAAAApAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAGACQAAHgkAABX
JQAAWCUAANwmAADdJgAA3ycAAOAnAAASKAAAEygAAE8pAAC4AAAAAAAAAAAAAAAAcQAAAAAAAAAA
AAAAAG8AAAAAAAAAAAAAAABvAAAAAAAAAAAAAAAAbwAAAAAAAAAAAAAAAG8AAAAAAAAAAAAAAABv
AAAAAAAAAAAAAAAAbQAAAAAAAAAAAAAAAG8AAAAAAAAAAAAAAABvAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQMAAAEAAABGAAAKJgALRgMA
RcaAAQACAPVCVUYCAAAAAAAAAAAEBAIABAIABAIAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAMAKAAAACkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAARgAACiYAC0YDAEXGgAEAAgD1QlVGAgAAAAAAAAAABAQCAAQCAAQC
AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADACgAAAApAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAp+JAAAgiQAAKEk
AADAJAAAwyQAAO4kAADvJAAA8CQAAPEkAADyJAAA9yQAAP4kAAAFJQAAJiUAACclAABVJQAAayUA
AGwlAABtJQAAgCUAAIklAACOJQAAqyUAALQlAAC5JQAAvSUAAMslAADNJQAAzyUAANAlAAB9JgAA
fiYAALAmAAC0JgAADycAABAnAABUJwAA3ScAABQoAABfKAAAkygAAKEoAACnKAAAqigAAKsoAAD4
KAAA+PHq8QDj3NUA487HAMDHALmyAM7HAKukAJ0AndwAzgCWAKsAjwCIgXoAgXoAAAAAAAAAAAAA
AAAAAAAADQAIgWNIBABkaHBEVUYNAQiBBEgEAAVocERVRg0BCIEESAQABWhvRFVGDQEIgQRIBAAF
aG5EVUYNAQiBBEgDAAVo6kNVRg0ACIFjSAMAZGjpQ1VGDQEIgQRIAgAFaChDVUYNAAiBY0gCAGRo
KENVRg0BCIEESAQABWhnRFVGDQAIgWNIBABkaGdEVUYNSCoCV8oHAQIAJ0NVRg0BCIEESAIABWgn
Q1VGDQAIgWNIAgBkaCdDVUYNAQiBBEgEAAVobURVRg0BCIEESAMABWjpQ1VGDQAIgWNIBABkaG1E
VUYNAQiBBEgDAAVo6ENVRg0BCIEESAIABWgmQ1VGDQAIgWNIAgBkaCZDVUYALfgoAAD5KAAATikA
AE8pAABQKQAAZioAAGgqAABpKgAAcCoAANAqAADeKgAA3yoAAOoqAADrKgAA7SoAAO4qAADxKgAA
/CoAAP4qAAD/KgAACSsAABErAAAlKwAAUCsAAGQrAABmKwAAaisAAMgrAADJKwAAyisAABQtAAAW
LQAAYy0AAGQtAABlLQAAsDAAALIwAAC0MAAAvDAAAL4wAADAMAAA+DAAAPkwAAD46eLbANTN1M3G
v8a/xr/Gv9S/xr/Gv9S4qZqpmqmTAIyFAH53AH53AHAAAAAAAAAAAAAADQEIgQRIBAAFaGdEVUYN
AQiBBEgEAAVoh0pVZg0ACIFjSAQAZGiHSlVmDQAIgWNIAgBkaClDVUYNAQiBBEgCAAVoKUNVRg0A
CIFjSAQAZGh0RFVGHQAIgQEIgQRIAwAFaO1DVUYMKgdjSAQAZGh0RFVGHQAIgQEIgQRIAwAFaO5D
VUYMKgdjSAQAZGh0RFVGDQEIgQRIAwAFaO1DVUYNAQiBBEgEAAVoc0RVRg0BCIEESAQABWhyRFVG
DQEIgQRIBAAFaHFEVUYNAQiBBEgEAAVodERVRg0BCIEESAQABWhwRFVGDQAIgWNIBABkaHBEVUYd
AAiBAQiBBEgDAAVo60NVRgwqB2NIBABkaHBEVUYNAQiBBEgDAAVo60NVRgAqTykAAFApAABRKQAA
nCkAAN0pAABnKgAAugAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAA
AAAAAAAAAHUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQwAARcaA
AAAEAHJEVUYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAQAAAEQAAEMkAUXGgAAABABwRFVGAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVnKgAAaCoAAGMrAABk
KwAAZSsAAGYrAABqKwAAugAAAAAAAAAAAAAAALoAAAAAAAAAAAAAAAC6AAAAAAAAAAAAAAAAugAA
AAAAAAAAAAAAAHUAAAAAAAAAAAAAAAB1AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARAAAQyQB
RcaAAAADAO1DVUYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAARAAAQyQBRcaAAAAEAHREVUYAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABmorAADJKwAAyisAAOgr
AAANLAAAMiwAAFcsAAB8LAAAoSwAAMYsAADrLAAAES0AABUtAAAWLQAAIS0AACItAABNLwAATi8A
AF8vAAC5LwAAATAAAHMwAAC6AAAAAAAAAAAAAAAAugAAAAAAAAAAAAAAALoAAAAAAAAAAAAAAAC6
AAAAAAAAAAAAAAAAugAAAAAAAAAAAAAAALoAAAAAAAAAAAAAAAC6AAAAAAAAAAAAAAAAugAAAAAA
AAAAAAAAALoAAAAAAAAAAAAAAAC6AAAAAAAAAAAAAAAAugAAAAAAAAAAAAAAALoAAAAAAAAAAAAA
AAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAA
AAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAA
AAAAAAAAAAAAAAAAAAEAAABEAABDJAFFxoAAAAMA7kNVRgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAV+TAAAPowAAADMQAABDEA
AAUxAAAIMQAACTEAADkxAAA6MQAASDEAAE0xAAB9MQAAjjEAAI8xAACoMQAArTEAAAYyAAAHMgAA
5DIAAOwyAAAeMwAAIDMAAAE0AAAJNAAAOzQAAD00AAAeNQAAJjUAADk1AAA6NQAAvDUAAL01AADZ
NQAA2jUAANs1AAAYNgAAGTYAABo2AAChNgAAqTYAAME2AADDNgAAmzcAAKA3AACkNwAAyDcAANA3
AADjNwAA5TcAAMY4AADOOAAA4TgAAOI4AAD4APH4AOrb1ADNAM0AzcDNAM0AzQDNAM0AzQDNAM0A
zbOmzbOmzQDNAM2ZzYQAzQDNAM0AKQAIgQEIgQRIAwAFaANEVUYMKgdDShIAT0oDAFFKAwBjSAQA
ZGh1RFVGGQAIgUNKEgBPSgMAUUoDAGNIBABkaHVEVUYZAAiBQ0oSAE9KAwBRSgMAY0gBAGRoYVNV
hhkBCIEESAEABWhhU1WGQ0oSAE9KAwBRSgMAGQAIgUNKEgBPSgMAUUoDAGNIAwBkaPBDVUYMQ0oS
AE9KAwBRSgMAAA0BCIEESAQABWhoRFVGHQAIgQEIgQRIAwAFaAREVUYMKgdjSAQAZGhoRFVGDQAI
gWNIBABkaGhEVUYNAQiBBEgEAAVoZ0RVRg0ACIFjSAQAZGhnRFVGADRzMAAAOzEAADwxAABOMQAA
YzEAAGwxAAB2MQAAdzEAAH0xAACPMQAABzIAADoyAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA
APcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAABnvAUA
AAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAACPAAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAABAEA
AAQBAAAEAQAACNZcAASU/ycJuhJOHOIlAAaTCQAAAAAAAAAAAAAAAAAAAAAABpMJAAAAAAAAAAAA
AAAAAAAAAAAGlAkAAAAAAAAAAAAAAAAAAAAAAAaUCQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/BAEA
AAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gEAABrWEAAAAP8AAAD/
AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/
AAAA/wAAAP801gYAAQoDbABh9gMAAAYAABYkAUlmAQAAAAABAAAACzoyAACdMgAA5TIAAOYyAADs
MgAAHzMAACAzAABTMwAAtjMAAAI0AAADNAAACTQAADw0AAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAA
AAAAAGl0BAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5
AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAABpdAQAAAAAAAAAAAAA+QAAAAAA
AAAAAAAAAPkAAAAAAAAAAAAAAAAAAACPAAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAA
BAEAAAQBAAAEAQAACNZcAASU/ycJuhJOHOIlAAaTCQAAAAAAAAAAAAAAAAAAAAAABpMJAAAAAAAA
AAAAAAAAAAAAAAAGlAkAAAAAAAAAAAAAAAAAAAAAAAaUCQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/
BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gEAABrWEAAAAP8A
AAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8A
AAD/AAAA/wAAAP801gYAAQoDbABh9gMAAAYAABYkAUlmAQAAAAAMPDQAAD00AABwNAAA0zQAAB81
AAAgNQAAJjUAADo1AAC9NQAAyzUAAKI2AACjNgAAqTYAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA
AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAABpDAYAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkA
AAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAABpnAQAAAAA
AAAAAAAA+QAAAAAAAAAAAAAAAAAAAI8AABYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQBAAAE
AQAABAEAAAQBAAAI1lwABJT/Jwm6Ek4c4iUABpMJAAAAAAAAAAAAAAAAAAAAAAAGkwkAAAAAAAAA
AAAAAAAAAAAAAAaUCQAAAAAAAAAAAAAAAAAAAAAABpQJAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8E
AQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2AQAAGtYQAAAA/wAA
AP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAA
AP8AAAD/AAAA/zTWBgABCgNsAGH2AwAABgAAFiQBSWYBAAAAAAypNgAAwjYAAMM2AADRNgAAyTcA
AMo3AADQNwAA5DcAAOU3AADzNwAAxzgAAMg4AADOOAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAA
AAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAGn4AwAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA
AAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAGkABgAAAAAA
AAAAAAD5AAAAAAAAAAAAAAAAAAAAjwAAFiQBFyQBSWYBAAAAApZsAAXWGAQBAAAEAQAABAEAAAQB
AAAEAQAABAEAAAjWXAAElP8nCboSThziJQAGkwkAAAAAAAAAAAAAAAAAAAAAAAaTCQAAAAAAAAAA
AAAAAAAAAAAABpQJAAAAAAAAAAAAAAAAAAAAAAAGlAkAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wQB
AAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAa1hAAAAD/AAAA
/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA
/wAAAP8AAAD/NNYGAAEKA2wAYfYDAAAGAAAWJAFJZgEAAAAADM44AADiOAAAZTkAAHM5AABHOgAA
SDoAAE46AABiOgAAYzoAAHE6AABAOwAAQTsAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA
AAAAAAAAAAAAAPkAAAAAAAAAAAAAAABp5AMAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA
AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAABpAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAACPAAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAABAEA
AAQBAAAEAQAACNZcAASU/ycJuhJOHOIlAAaTCQAAAAAAAAAAAAAAAAAAAAAABpMJAAAAAAAAAAAA
AAAAAAAAAAAGlAkAAAAAAAAAAAAAAAAAAAAAAAaUCQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/BAEA
AAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gEAABrWEAAAAP8AAAD/
AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/
AAAA/wAAAP801gYAAQoDbABh9gMAAAYAABYkAUlmAQAAAAAL4jgAAGQ5AABlOQAAPToAAEI6AABG
OgAATjoAAD87AABDOwAAWDsAAMw+AADOPgAA0D4AANg+AADaPgAA3D4AABQ/AAAVPwAAFj8AAB8/
AAAgPwAAIT8AACU/AAAmPwAAWj8AAFs/AABcPwAAaT8AAG4/AACePwAArz8AALA/AAAnQAAAKEAA
AAVBAAANQQAAP0EAAEFBAAAiQgAAKkIAAFxCAABeQgAAP0MAAEdDAABaQwAAW0MAAN1DAADeQwAA
+kMAAPtDAAD8QwAAOUQAADpEAAA7RAAAwkQAAPkA+ez5APkA5QDe1wDQyQDCuwDCuwC0pbvCAPkA
+QD5APkA+QD5APkA+QD5APkA+ZiL+ZiL+QAAAAAZAAiBQ0oSAE9KAwBRSgMAY0gBAGRoYVNVhhkB
CIEESAEABWhhU1WGQ0oSAE9KAwBRSgMAHQAIgQEIgQRIAwAFaAZEVUYMKgdjSAQAZGhoRFVGDQEI
gQRIAwAFaAZEVUYNAAiBY0gEAGRoaERVRg0BCIEESAQABWhoRFVGDQEIgQRIBAAFaIhKVWYNAAiB
Y0gEAGRoiEpVZg0BCIEESAQABWiHSlVmDQAIgWNIBABkaIdKVWYNAAiBY0gBAGRoWkNVRhkBCIEE
SAIABWgrQ1VGQ0oSAE9KAwBRSgMADENKEgBPSgMAUUoDADZBOwAAQjsAAEM7AABZOwAAWjsAAFs7
AABnOwAAaDsAAGg9AABpPQAAez0AANU9AAAdPgAAjz4AAFs/AABcPwAAXT8AAG8/AACEPwAAjT8A
AJc/AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA
/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA
AAAA/QAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAsgAAAAAAAAAAAAAAALIA
AAAAAAAAAAAAAACyAAAAAAAAAAAAAAAAsgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlm
AQAAAABEAABDJAFFxoAAAAQAaERVRgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAFJc/AACYPwAAnj8AALA/AAAoQAAAW0AA
AL5AAAAGQQAAB0EAAA1BAABAQQAAQUEAAHRBAABvvAUAAAAAAAAAAAAAaQAAAAAAAAAAAAAAAGkA
AAAAAAAAAAAAAABpAAAAAAAAAAAAAAAAaQAAAAAAAAAAAAAAAGkAAAAAAAAAAAAAAABpAAAAAAAA
AAAAAAAAb3QEAAAAAAAAAAAAAGkAAAAAAAAAAAAAAABpAAAAAAAAAAAAAAAAaQAAAAAAAAAAAAAA
AGkAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAACPAAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQB
AAAEAQAABAEAAAQBAAAEAQAACNZcAASU/ycJuhJOHOIlAAaTCQAAAAAAAAAAAAAAAAAAAAAABpMJ
AAAAAAAAAAAAAAAAAAAAAAAGlAkAAAAAAAAAAAAAAAAAAAAAAAaUCQAAAAAAAAAAAAAAAAAAAAAT
1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gEAABrW
EAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3W
EAAAAP8AAAD/AAAA/wAAAP801gYAAQoDbABh9gMAAAAMdEEAANdBAAAjQgAAJEIAACpCAABdQgAA
XkIAAJFCAAD0QgAAQEMAAEFDAABHQwAAW0MAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAAaXQE
AAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA
AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAGkMBgAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA
+QAAAAAAAAAAAAAAAAAAAI8AABYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEA
AAQBAAAI1lwABJT/Jwm6Ek4c4iUABpMJAAAAAAAAAAAAAAAAAAAAAAAGkwkAAAAAAAAAAAAAAAAA
AAAAAAaUCQAAAAAAAAAAAAAAAAAAAAAABpQJAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8EAQAAAAAA
/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2AQAAGtYQAAAA/wAAAP8AAAD/
AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/
AAAA/zTWBgABCgNsAGH2AwAABgAAFiQBSWYBAAAAAAxbQwAA3kMAAOxDAADDRAAAxEQAAMpEAADj
RAAA5EQAAPJEAADMRQAAzUUAANNFAADnRQAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAA
AAAAAAAAAAAAaSQEAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAA
AAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAAaRAEAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5
AAAAAAAAAAAAAAAAAAAAjwAAFiQBFyQBSWYBAAAAApZsAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAA
BAEAAAjWXAAElP8nCboSThziJQAGkwkAAAAAAAAAAAAAAAAAAAAAAAaTCQAAAAAAAAAAAAAAAAAA
AAAABpQJAAAAAAAAAAAAAAAAAAAAAAAGlAkAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wQBAAAAAAD/
BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAa1hAAAAD/AAAA/wAAAP8A
AAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8A
AAD/NNYGAAEKA2wAYfYDAAAGAAAWJAFJZgEAAAAADMJEAADKRAAA4kQAAOREAADLRQAA00UAAOZF
AADoRQAAz0YAANdGAADqRgAA60YAAG1HAABuRwAAVUgAAF1IAABTSQAAVkkAAJ9JAADaSQAA3EkA
AA5KAAAmSgAAJ0oAAClKAABpSgAAakoAAIxKAACNSgAAjkoAAA9LAAAgSwAAIUsAACJLAABuTQAA
b00AAHBNAAB+TQAAf00AAIBNAACkTQAApU0AAPZNAAACTgAAEk4AAG1PAAByTwAAfk8AAIZPAACH
TwAAik8AAJFPAAAuUAAAM1AAADhQAABnUAAAalAAAAD5APkA+QD5APkA+QD5APkA8uvk8uTy5N3W
3c/Wz9by3QDIwQDIwQDBALqzAKylAKUApQCelwCQAAAAAA0ACIFjSAQAZGiRRFVGDQEIgQRIBAAF
aJJEVUYNAAiBY0gEAGRokkRVRg0BCIEESAQABWiJSlVmDQAIgWNIBABkaIlKVWYNAQiBBEgEAAVo
dkRVRg0ACIFjSAQAZGh2RFVGDQAIgWNIAwBkaAhEVUYNAQiBBEgDAAVoCERVRg0BCIEESAQABWiY
RFVGDQEIgQRIBAAFaJlEVUYNAQiBBEgEAAVol0RVRg0BCIEESAQABWibRFVGDQEIgQRIBAAFaJpE
VUYNAQiBBEgEAAVolkRVRgxDShIAT0oDAFFKAwA450UAAOhFAAD2RQAA0EYAANFGAADXRgAA60YA
AG5HAAB8RwAAVkgAAFdIAABdSAAAcUgAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA
AAAAAAAAAGkYBgAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAA
AAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAGn4AwAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA
AAAAAAAAAAAAAAAAAI8AABYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQB
AAAI1lwABJT/Jwm6Ek4c4iUABpMJAAAAAAAAAAAAAAAAAAAAAAAGkwkAAAAAAAAAAAAAAAAAAAAA
AAaUCQAAAAAAAAAAAAAAAAAAAAAABpQJAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8EAQAAAAAA/wQB
AAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2AQAAGtYQAAAA/wAAAP8AAAD/AAAA
/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA
/zTWBgABCgNsAGH2AwAABgAAFiQBSWYBAAAAAAxxSAAAckgAAIBIAABUSQAAVUkAAFZJAAAoSgAA
+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAAaQAAAAAAAAAAAAAAAGcAAAAA
AAAAAAAAAABnAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAABAAAAjwAAFiQBFyQBSWYBAAAAApZsAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEA
AAjWXAAElP8nCboSThziJQAGkwkAAAAAAAAAAAAAAAAAAAAAAAaTCQAAAAAAAAAAAAAAAAAAAAAA
BpQJAAAAAAAAAAAAAAAAAAAAAAAGlAkAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wQBAAAAAAD/BAEA
AAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAa1hAAAAD/AAAA/wAAAP8AAAD/
G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/
NNYGAAEKA2wAYfYDAAAGAAAWJAFJZgEAAAAABihKAAApSgAAIUsAACJLAABaSwAAW0sAALoAAAAA
AAAAAAAAAAC6AAAAAAAAAAAAAAAAdQAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAuAAAAAAAAAAAA
AAAAAAAAAAEAAABEAABDJAFFxoAAAAQAlkRVRgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABEAABDJAFFxoAAAAQAl0RVRgAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AABEAABDJAFFxoAAAAQAm0RVRgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFW0sAAA5NAAAPTQAAbE8AAG1PAACTTwAA7U8AADpQ
AAC5UAAAgFEAAIFRAACTUQAAqFEAALFRAAC7UQAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9
AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA
AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAA
AAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAGAAAWJAFJZgEAAAAAAQAAAA5qUAAAbVAAAJ5QAACgUAAAolAAAKNQAACmUAAAqVAA
AK1QAACyUAAAt1AAAPZQAAD8UAAA/1AAAAFRAAACUQAABlEAAAtRAAAQUQAARVEAAEZRAABHUQAA
T1EAAFBRAABRUQAAVFEAAFlRAABaUQAAXFEAAF1RAABeUQAAf1EAAI1RAACSUQAAwlEAANNRAADU
UQAAS1IAAExSAACPUgAA0FIAABFTAABqUwAAbFMAAHFTAAD4APHqAPHqAOPcANXO3M4A1dwAx8AA
1cDVzgC5qpuqAJQAlACUAJSHepQAcwAAAAAAAA0ACIFjSAQAZGh3RFVGGQEIgQRIBAAFaHZEVUZD
ShIAT0oDAFFKAwAZAAiBQ0oSAE9KAwBRSgMAY0gEAGRodkRVRgxDShIAT0oDAFFKAwAAHQAIgQEI
gQRIAwAFaAlEVUYMKgdjSAQAZGh2RFVGHQAIgQEIgQRIAwAFaAhEVUYMKgdjSAQAZGh2RFVGDQEI
gQRIAwAFaAhEVUYNAAiBY0gEAGRoaURVRg0BCIEESAQABWhpRFVGDQEIgQRIBAAFaJNEVUYNAAiB
Y0gEAGRok0RVRg0BCIEESAQABWiJSlVmDQAIgWNIBABkaIlKVWYNAQiBBEgEAAVoiEpVZg0ACIFj
SAQAZGiISlVmDQEIgQRIBAAFaJFEVUYALLtRAAC8UQAAwlEAANRRAABMUgAAf1IAACNTAABrUwAA
bFMAAHdTAACqUwAAq1MAAONTAABvwAYAAAAAAAAAAAAAaQAAAAAAAAAAAAAAAGkAAAAAAAAAAAAA
AABpAAAAAAAAAAAAAAAAaQAAAAAAAAAAAAAAAGkAAAAAAAAAAAAAAABpAAAAAAAAAAAAAAAAb7QE
AAAAAAAAAAAAAGkAAAAAAAAAAAAAAABpAAAAAAAAAAAAAAAAaQAAAAAAAAAAAAAAAGkAAAAAAAAA
AAAAAAAAAAYAABYkAUlmAQAAAACPAAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAABAEA
AAQBAAAEAQAACNZcAASU/ycJuhJOHOIlAAaTCQAAAAAAAAAAAAAAAAAAAAAABpMJAAAAAAAAAAAA
AAAAAAAAAAAGlAkAAAAAAAAAAAAAAAAAAAAAAAaUCQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/BAEA
AAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gEAABrWEAAAAP8AAAD/
AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/
AAAA/wAAAP801gYAAQoDbABh9gMAAAAMcVMAAHZTAAB3UwAAqVMAAKtTAADYUwAA3VMAAOJTAADw
UwAANFQAADpUAACXVAAAmVQAAJ5UAACjVAAApFQAANZUAADYVAAABVUAAApVAAAPVQAAHlUAAB9V
AAAgVQAAIVUAAGJVAACjVQAAAFYAAAJWAAAIVgAAOlYAADtWAAA8VgAAaVYAAG5WAAB9VgAAflYA
AONWAADqVgAA61YAAOxWAADyVgAABVcAAAZXAAASVwAA+ADxAPHk1/Hk1/EA0PgA8QDxw7bxtsPx
qZzxAPiPtvi2graCtnW2+ADxAPEAAAAAAAAAAAAAGQEIgQRIBAAFaIlEVUZDShIAT0oDAFFKAwAZ
AQiBBEgEAAVoekRVRkNKEgBPSgMAUUoDABkBCIEESAEABWhpU1WGQ0oSAE9KAwBRSgMAGQEIgQRI
BAAFaHlEVUZDShIAT0oDAFFKAwAZAAiBQ0oSAE9KAwBRSgMAY0gEAGRoeURVRhkBCIEESAQABWh3
RFVGQ0oSAE9KAwBRSgMAGQAIgUNKEgBPSgMAUUoDAGNIBABkaHdEVUYNAAiBY0gEAGRod0RVRhkB
CIEESAQABWh2RFVGQ0oSAE9KAwBRSgMAGQAIgUNKEgBPSgMAUUoDAGNIBABkaHZEVUYMQ0oSAE9K
AwBRSgMAAA0BCIEESAQABWh3RFVGACzjUwAAOlQAAExUAACYVAAA+QAAAAAAAAAAAAAAALAAAAAA
AAAAAAAAAAD5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASQAAFiQBQyQBRcaAAAAEAHZEVUYAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AABJZgEAAAAGAAAWJAFJZgEAAAAAA5hUAACZVAAApFQAANdUAADYVAAAEFUAALVVAAABVgAAAlYA
AAhWAAA7VgAAPFYAAG+kBQAAAAAAAAAAAABpAAAAAAAAAAAAAAAAaQAAAAAAAAAAAAAAAGkAAAAA
AAAAAAAAAABpAAAAAAAAAAAAAAAAaQAAAAAAAAAAAAAAAGkAAAAAAAAAAAAAAABvqAMAAAAAAAAA
AAAAaQAAAAAAAAAAAAAAAGkAAAAAAAAAAAAAAABpAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAYAABYkAUlmAQAAAACPAAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAABAEAAAQB
AAAEAQAACNZcAASU/ycJuhJOHOIlAAaTCQAAAAAAAAAAAAAAAAAAAAAABpMJAAAAAAAAAAAAAAAA
AAAAAAAGlAkAAAAAAAAAAAAAAAAAAAAAAAaUCQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/BAEAAAAA
AP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gEAABrWEAAAAP8AAAD/AAAA
/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA
/wAAAP801gYAAQoDbABh9gMAAAALPFYAAG9WAADSVgAA5FYAAOtWAAC2AAAAAAAAAAAAAAAAtgAA
AAAAAAAAAAAAALAAAAAAAAAAAAAAAABnAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABJ
AAAWJAFDJAFFxoAAAAQAiURVRgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAElmAQAAAAYAABYkAUlmAQAAAEkAABYkAUMkAUXGgAAA
BAB3RFVGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAASWYBAAAAAATrVgAA7FYAAPJWAAAGVwAAnVcAAKxXAACxWAAAslgAAL1YAADW
WAAA11gAAOZYAADIWQAAbxgHAAAAAAAAAAAAAGkAAAAAAAAAAAAAAABpAAAAAAAAAAAAAAAAaQAA
AAAAAAAAAAAAAGkAAAAAAAAAAAAAAABpAAAAAAAAAAAAAAAAb1wEAAAAAAAAAAAAAGkAAAAAAAAA
AAAAAABpAAAAAAAAAAAAAAAAaQAAAAAAAAAAAAAAAGkAAAAAAAAAAAAAAABpAAAAAAAAAAAAAAAA
AAAGAAAWJAFJZgEAAAAAjwAAFiQBFyQBSWYBAAAAApZsAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAA
BAEAAAjWXAAElP8nCboSThziJQAGkwkAAAAAAAAAAAAAAAAAAAAAAAaTCQAAAAAAAAAAAAAAAAAA
AAAABpQJAAAAAAAAAAAAAAAAAAAAAAAGlAkAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wQBAAAAAAD/
BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAa1hAAAAD/AAAA/wAAAP8A
AAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8A
AAD/NNYGAAEKA2wAYfYDAAAADBJXAAAmVwAAOlcAAJxXAACdVwAAqVcAAKpXAACrVwAAulcAALtX
AAC8VwAA+FcAAPpXAAD8VwAA/VcAACpYAABXWAAAsFgAALJYAAC3WAAAvFgAAL1YAADVWAAA11gA
AONYAADkWAAA5VgAAPNYAAD4WAAA/VgAADdZAAA6WQAAPVkAAMdZAADJWQAAzlkAANNZAADUWQAA
51kAAOlZAAD1WQAA9lkAAPdZAAAGWgAACVoAAAxaAABGWgAAS1oAAFBaAADZWgAA21oAAOFaAAD1
WgAA9loAAAJbAAADWwAAUlsAAPLl3gDe0cTexNHe0cTe0cTeAL22AN4A3qmc3qmc3pyp3gC9tgDe
AN6pnN6cqd6pnN4Ato+2j5yPAAAZAQiBBEgEAAVoeERVRkNKEgBPSgMAUUoDABkBCIEESAQABWiF
RFVGQ0oSAE9KAwBRSgMAGQAIgUNKEgBPSgMAUUoDAGNIBABkaIVEVUYNAQiBBEgEAAVoeERVRg0A
CIFjSAQAZGh4RFVGGQEIgQRIBAAFaHlEVUZDShIAT0oDAFFKAwAZAAiBQ0oSAE9KAwBRSgMAY0gE
AGRoeURVRgxDShIAT0oDAFFKAwAAGQEIgQRIBAAFaHpEVUZDShIAT0oDAFFKAwAZAAiBQ0oSAE9K
AwBRSgMAY0gEAGRoekRVRgA4yFkAAMlZAADUWQAA6FkAAOlZAAD4WQAA2loAANtaAADhWgAA9VoA
APZaAABvSAQAAAAAAAAAAAAAaQAAAAAAAAAAAAAAAGkAAAAAAAAAAAAAAABpAAAAAAAAAAAAAAAA
aQAAAAAAAAAAAAAAAGkAAAAAAAAAAAAAAABvEAQAAAAAAAAAAAAAaQAAAAAAAAAAAAAAAGkAAAAA
AAAAAAAAAABpAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
BgAAFiQBSWYBAAAAAI8AABYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQB
AAAI1lwABJT/Jwm6Ek4c4iUABpMJAAAAAAAAAAAAAAAAAAAAAAAGkwkAAAAAAAAAAAAAAAAAAAAA
AAaUCQAAAAAAAAAAAAAAAAAAAAAABpQJAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8EAQAAAAAA/wQB
AAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2AQAAGtYQAAAA/wAAAP8AAAD/AAAA
/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA
/zTWBgABCgNsAGH2AwAAAAr2WgAABFsAAN5bAADfWwAAtgAAAAAAAAAAAAAAALAAAAAAAAAAAAAA
AAAg0AcAAAAAAAAAAAAAAAAAAAAAAAAAAI8AABYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQB
AAAEAQAABAEAAAQBAAAI1lwABJT/Jwm6Ek4c4iUABpMJAAAAAAAAAAAAAAAAAAAAAAAGkwkAAAAA
AAAAAAAAAAAAAAAAAAaUCQAAAAAAAAAAAAAAAAAAAAAABpQJAAAAAAAAAAAAAAAAAAAAABPWMAAA
AP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2AQAAGtYQAAAA
/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA
/wAAAP8AAAD/AAAA/zTWBgABCgNsAGH2AwAABgAAFiQBSWYBAAAASQAAFiQBQyQBRcaAAAAEAHhE
VUYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAABJZgEAAAAAA1JbAABUWwAA3lsAAN9bAADlWwAA+FsAAPlbAAAFXAAAGVwAAC1cAACP
XAAAkFwAAJxcAACdXAAAnlwAAO1cAAAaXQAAR10AAFddAACDXQAAr10AAMJdAADIXQAA0V0AANNd
AADVXQAA110AANhdAADaXQAA3F0AAN1dAAD+XQAA/10AAAFeAAAQXgAAFF4AABheAABRXgAAVl4A
AFteAACWXgAAwl4AAO5eAAAKXwAALV8AADJfAADy5d4A1wDXyr3XANfKvdfKvdewo9ew1wCclQCc
lQDXyr3XiHvXe4jXsKPXAHQAAAANAAiBY0gEAGRoh0RVRhkACIFDShIAT0oDAFFKAwBjSAQAZGiR
RFVGGQEIgQRIBAAFaJFEVUZDShIAT0oDAFFKAwANAQiBBEgEAAVohkRVRg0ACIFjSAQAZGiGRFVG
GQEIgQRIBAAFaIlEVUZDShIAT0oDAFFKAwAZAAiBQ0oSAE9KAwBRSgMAY0gEAGRoiURVRhkBCIEE
SAQABWiGRFVGQ0oSAE9KAwBRSgMAGQAIgUNKEgBPSgMAUUoDAGNIBABkaIZEVUYMQ0oSAE9KAwBR
SgMAAA0BCIEESAQABWh4RFVGGQEIgQRIBAAFaHhEVUZDShIAT0oDAFFKAwAZAQiBBEgEAAVohURV
RkNKEgBPSgMAUUoDAAAt31sAAOVbAAD5WwAAkFwAAJ9cAADSXQAA010AAN1dAADxXQAA8l0AAAJe
AAALXwAADF8AAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA
AAAAAAD5AAAAAAAAAAAAAAAAaeQEAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA
+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAAaQAAAAAAAAAAAAAAAAAAAI8A
ABYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1lwABJT/Jwm6Ek4c
4iUABpMJAAAAAAAAAAAAAAAAAAAAAAAGkwkAAAAAAAAAAAAAAAAAAAAAAAaUCQAAAAAAAAAAAAAA
AAAAAAAABpQJAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8E
AQAAAAAA/wQBAAAAAAD/BAEAABT2AQAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA
/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABCgNsAGH2AwAA
BgAAFiQBSWYBAAAAAAwMXwAADV8AANRfAADVXwAAr2AAALBgAAA/YQAAQGEAAO5hAADvYQAA8GEA
AFxjAABdYwAAXmMAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAA
AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAC2AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAERAABEAABDJAFFxoAAAAQAlERV
RgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAABAAAADTJfAAA3XwAAPl8AAEJfAABGXwAAsV8AALZfAAC7XwAA3l8AAONfAADoXwAA
7F8AAPBfAAD3XwAA+V8AAPtfAAB9YAAAgmAAAIdgAADLYAAA0GAAANVgAADgYAAA4mAAAORgAAAe
YQAAPmEAAO1hAADwYQAA8WEAAB1iAAAkYgAAM2IAAD5iAABHYgAASmIAAFViAACBYgAAiWIAAJhi
AACrYgAA5WIAAO5iAAD4YgAAXmMAAPgA+PEA8fgA6uMA6gDq4wDq4wDq4wDx+ADc1QDOAMe+xwC3
sACpoKkAmZIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAANAQiBBEgBAAVoWUNVRg0ACIFjSAEAZGhZQ1VGEAAIgTYIgWNI
AgBkaPlCVUYADQAIgWNIAgBkaPlCVUYNAQiBBEgCAAVo+EJVRg0ACIFjSAIAZGj4QlVGEAEIgQRI
AgAFaPlCVUY2CIEADQEIgQRIAgAFaPlCVUYNA2oAAAAAMEoSAFUIAQ0BCIEESAQABWiURFVGDQEI
gQRIAQAFaFpDVUYNAQiBBEgEAAVoiERVRg0ACIFjSAQAZGiIRFVGDQAIgWNIBABkaIdEVUYNAQiB
BEgEAAVoh0RVRgAsIAAxkGgBH7DQLyCw4D0hsC0FIrAtBSOQ8AMkkPADJbAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAUABMACgABAGkADwADAAAAAAAAAAAAOAAAQPH/AgA4AAwABgBOAG8AcgBtAGEA
bAAAAAIAAAAYAENKGABfSAEEYUoYAG1ICQRzSAkEdEgJBDYAAUABAAIANgAMAAkASABlAGEAZABp
AG4AZwAgADEAAAAOAAEAAyQBBiQBQCYAYSQBBABDShwAMgACQAEAAgAyAAwACQBIAGUAYQBkAGkA
bgBnACAAMgAAAAgAAgAGJAFAJgEGADYIgV0IgTgAA0ABAAIAOAAMAAkASABlAGEAZABpAG4AZwAg
ADMAAAAOAAMAAyQBBiQBQCYCYSQBBgA2CIFdCIEAAAAAAAAAAAAAAAA8AEFA8v+hADwADAAWAEQA
ZQBmAGEAdQBsAHQAIABQAGEAcgBhAGcAcgBhAHAAaAAgAEYAbwBuAHQAAAAAAAAAAAAAAAAAKAA+
QAEA8gAoAAwABQBUAGkAdABsAGUAAAAIAA8AAyQBYSQBBABDShwAIgBXQKIAAQEiAAwABgBTAHQA
cgBvAG4AZwAAAAYANQgBXAgBNgAdQAEAEgE2AAwADQBGAG8AbwB0AG4AbwB0AGUAIABUAGUAeAB0
AAAAAgARAAgAQ0oUAGFKFAA4ACZAogAhATgADAASAEYAbwBvAHQAbgBvAHQAZQAgAFIAZQBmAGUA
cgBlAG4AYwBlAAAAAwBIKgEAOQUAAF5fAAABAAAAAABsAQAAbwEAAAAAAABeXwAABgAAygAABQD/
////AAAAAAwAAAANAAAAHQEAAB4BAACLAQAAjAEAAJIBAACTAQAANQIAADYCAADYAgAA2QIAADsF
AAA8BQAAjwUAAJAFAAA/BwAAQAcAAMsJAADMCQAAQQoAAEIKAADzCwAA9AsAAGkMAABqDAAAqQwA
AKoMAAC4DAAAuQwAAIUOAACGDgAA8w8AAPQPAAAKEQAACxEAANsSAADcEgAAIxMAACQTAADvFAAA
8RQAAAAWAAABFgAAQxYAAEQWAAAKFwAACxcAAFEXAABSFwAA7xcAAF4YAABfGAAAtRgAALYYAAA5
GQAAOhkAAGEZAABRGgAA0xoAADobAAByGwAAshsAALMbAADyGwAA8xsAAEAcAABBHAAAAh0AAAMd
AACdHQAAnh0AABseAAAcHgAAZx4AAMMeAAA5HwAAnx8AAAAgAAB4IAAAVyEAAFghAADcIgAA3SIA
AN8jAADgIwAAEiQAABMkAABPJQAAUCUAAFElAACcJQAA3SUAAGcmAABoJgAAYycAAGQnAABlJwAA
ZicAAGonAADJJwAAyicAAOgnAAANKAAAMigAAFcoAAB8KAAAoSgAAMYoAADrKAAAESkAABUpAAAW
KQAAISkAACIpAABNKwAATisAAF8rAAC5KwAAASwAAHMsAAA7LQAAPC0AAE4tAABjLQAAbC0AAHYt
AAB3LQAAfS0AAI8tAAAHLgAAOi4AAJ0uAADlLgAA5i4AAOwuAAAfLwAAIC8AAFMvAAC2LwAAAjAA
AAMwAAAJMAAAPDAAAD0wAABwMAAA0zAAAB8xAAAgMQAAJjEAADoxAAC9MQAAyzEAAKIyAACjMgAA
qTIAAMIyAADDMgAA0TIAAMkzAADKMwAA0DMAAOQzAADlMwAA8zMAAMc0AADINAAAzjQAAOI0AABl
NQAAczUAAEc2AABINgAATjYAAGI2AABjNgAAcTYAAEA3AABBNwAAQjcAAEM3AABZNwAAWjcAAFs3
AABnNwAAaDcAAGg5AABpOQAAezkAANU5AAAdOgAAjzoAAFs7AABcOwAAXTsAAG87AACEOwAAjTsA
AJc7AACYOwAAnjsAALA7AAAoPAAAWzwAAL48AAAGPQAABz0AAA09AABAPQAAQT0AAHQ9AADXPQAA
Iz4AACQ+AAAqPgAAXT4AAF4+AACRPgAA9D4AAEA/AABBPwAARz8AAFs/AADePwAA7D8AAMNAAADE
QAAAykAAAONAAADkQAAA8kAAAMxBAADNQQAA00EAAOdBAADoQQAA9kEAANBCAADRQgAA10IAAOtC
AABuQwAAfEMAAFZEAABXRAAAXUQAAHFEAAByRAAAgEQAAFRFAABVRQAAVkUAAChGAAApRgAAIUcA
ACJHAABaRwAAW0cAAA5JAAAPSQAAbEsAAG1LAACTSwAA7UsAADpMAAC5TAAAgE0AAIFNAACTTQAA
qE0AALFNAAC7TQAAvE0AAMJNAADUTQAATE4AAH9OAAAjTwAAa08AAGxPAAB3TwAAqk8AAKtPAADj
TwAAOlAAAExQAACYUAAAmVAAAKRQAADXUAAA2FAAABBRAAC1UQAAAVIAAAJSAAAIUgAAO1IAADxS
AABvUgAA0lIAAOtSAADsUgAA8lIAAAZTAACdUwAArFMAALFUAACyVAAAvVQAANZUAADXVAAA5lQA
AMhVAADJVQAA1FUAAOhVAADpVQAA+FUAANpWAADbVgAA4VYAAPVWAAD2VgAABFcAAN5XAADfVwAA
5VcAAPlXAACQWAAAn1gAANJZAADTWQAA3VkAAPFZAADyWQAAAloAAAtbAAAMWwAADVsAANRbAADV
WwAAr1wAALBcAAA/XQAAQF0AAO5dAADvXQAAX18AAJgAAAAPMAAAAAAAAACAAAAAgJgAAAAAAAAA
AAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAA
AACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgCgAAAADAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACA
jAEAAJgAAAAAAAAAAAAAAACAjAEAAJgAAAAAAAAAAAAAAACAjAEAAJgAAAAAAAAAAAAAAACAjAEA
AJgAAAAAAAAAAAAAAACAjAEAAJgAAAAAAAAAAAAAAACAjAEAAJgAAAAAAAAAAAAAAACAjAEAAJgA
AAAAAAAAAAAAAACAjAEAAJgAAAAAAAAAAAAAAACAjAEAAJgAAAAAMAAAAAAAAACAjAEAAJgAAAAA
AAAAAAAAAACAjAEAAJgAAAAAMAAAAAAAAACAjAEAAJgAAAAAAAAAAAAAAACAjAEAAJgAAAAAMAAA
AAAAAACAjAEAAJgAAAAAAAAAAAAAAACAjAEAAJgAAAAAMAAAAAAAAACAjAEAAJgAAAAAAAAAAAAA
AACAjAEAAJgAAAAAAAAAAAAAAACAjAEAAJgAAAAAAAAAAAAAAACAjAEAAJgAAAAAAAAAAAAAAACA
jAEAAJgAAAAAAAAAAAAAAACAjAEAAAgAAAABAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAqgwA
AJgAAAAAMAAAAAAAAACAqgwAAJgAAAAAAAAAAAAAAACAqgwAAJgAAAAAMAAAAAAAAACAqgwAAJgA
AAAAAAAAAAAAAACAqgwAAJgAAAAAMAAAAAAAAACAqgwAAJgAAAAAAAAAAAAAAACAqgwAAJgAAAAA
MAAAAAAAAACAqgwAAJgAAAAAAAAAAAAAAACAqgwAAAgAAAABMAAAAAAAAACAAAAAgJgAAAAAAAAA
AAAAAACA3BIAAJgAAAAAMAAAAAAAAACA3BIAAJgAAAAAMAAAAAAAAACA3BIAAJgAAAAAMAAAAAAA
AACA3BIAAJgAAAAAMAAAAAAAAACA3BIAABgAAAACMAAAAAAAAACA3BIAAJgAAAAAAAAAAAAAAACA
ARYAAJgAAAAAMAAAAAAAAACAARYAAJgAAAAAMAAAAAAAAACAARYAAJgAAAAAMAAAAAAAAACAARYA
AJgAAAAAAAAAAAAAAACAARYAAJgAASAAAAAAAAAAAACAARYAAJgAASAAAAEAAAAAAACAARYAAJgA
AAAAAAAAAAAAAACAARYAAJgAAAAAMAAAAAAAAACAARYAAJgAAAAAAAAAAAAAAACAARYAAJgAAAAA
MAAAAAAAAACAARYAAJgAAAAAAAAAAAAAAACAARYAAJgABCAAAAAAAAAAAACAARYAAJgBBCAAMAAA
AAA6GQAAARYAAJgBBCAAMAEAAAA6GQAAARYAAJgABCAAMAEAAAAAAACAARYAAJgBBCAAMAAAAADT
GgAAARYAAJgBBCAAMAEAAADTGgAAARYAAJgAAAAAAAAAAAAAAACAARYAAJgAAAAAMAAAAAAAAACA
ARYAAJgAAAAAAAAAAAAAAACAARYAAJgAAAAAMAAAAAAAAACAARYAAJgAAAAAAAAAAAAAAACAARYA
AJgAAAAAMAAAAAAAAACAARYAAJgAAAAAAAAAAAAAAACAARYAAJgAAAAAAAAAAAAAAACAARYAAJgA
AAAAAAAAAAAAAACAARYAAJgAAAAAMAAAAAAAAACAARYAAJgAAAAAAAAAAAAAAACAARYAAJgAAAAA
AAAAAAAAAACAARYAAJgAAAAAMAAAAAAAAACAARYAAJgAAiAAAAAAAAAAAACAARYAAJgAAiAAMAEA
AAAAAACAARYAAJgAAAAAMAAAAAAAAACAARYAAJgAAyAAMAAAAAAAAACAARYAAJgAAyAAMAEAAAAA
AACAARYAAJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACA
AAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgCgAAAADAAAAAAAAAACAAAAA
gJgAAAAAAAAAAAAAAACAuB4AAJgAAAAAMAAAAAAAAACAAAAAgJoAAAAAAAAAAAAAAACAuB4AAJgA
AAAAMAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAuB4AAJgAAAAAAAAAAAAAAACAuB4AAJgAAAAA
MAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAA
AAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAA
AACAAAAAgJoAAAAAMAAAAAAAAACAAAAAgJoAAAAAMAAAAAAAAACAAAAAgJoAAAAAMAAAAAAAAACA
AAAAgJoAAAAAMAAAAAAAAACAAAAAgJoAAAAAMAAAAAAAAACAAAAAgJoAAAAAMAAAAAAAAACAAAAA
gJoAAAAAMAAAAAAAAACAAAAAgJoAAAAAMAAAAAAAAACAAAAAgJoAAAAAMAAAAAAAAACAAAAAgJoA
AAAAMAAAAAAAAACAAAAAgJoAAAAAMAAAAAAAAACAAAAAgJoAAAAAMAAAAAAAAACAAAAAgJoAAAAA
AAAAAAAAAACAuB4AAJgAAAAAAAAAAAAAAACAuB4AAJgAAAAAAAAAAAAAAACAuB4AAJgAAAAAAAAA
AAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAA
AACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACA
AAAAgJgAAAAAAAAAAAAAAACAAAAAgKkAAAAAAAAAAAAAAACAAAAAgKkAAAAAAAAAAAAAAACAAAAA
gKkAAAAAAAAAAAAAAACAAAAAgKkAAAAAAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgKkA
AAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKtAAAAAMAAAAAAAAACAAAAAgKsAAAAA
MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAA
AAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAA
AACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACA
AAAAgJkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA
gKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkA
AAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAA
MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKsAAAAAMAAA
AAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAA
AACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKsAAAAAMAAAAAAAAACA
AAAAgJkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA
gKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkA
AAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAA
MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAA
AAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAA
AACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACA
AAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAA
gJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJhA
AAAAAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJhAAAAAAAAAAAAAAACAAAAAgJgAAAAA
AAAAAAAAAACAAAAAgJhAAAAAAAAAAAAAAACAAAAAgJhAAAAAAAAAAAAAAACAAAAAgJgAAAAAAAAA
AAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJpAAAAAAAAAAAAAAACAAAAAgJgAAAAAMAAAAAAA
AACAAAAAgKlAAAAAAAAAAAAAAACAAAAAgKkAAAAAAAAAAAAAAACAAAAAgKlAAAAAAAAAAAAAAACA
AAAAgKlAAAAAAAAAAAAAAACAAAAAgJ4AAAAAAAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA
gKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkA
AAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKkAAAAA
MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAA
AAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAA
AACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACA
AAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA
gJkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkA
AAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKsAAAAAMAAAAAAAAACAAAAAgJkAAAAA
MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAA
AAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAA
AACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACA
AAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAA
gKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkA
AAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKkAAAAA
MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAA
AAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAA
AACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACA
AAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAA
gJgAAAAAAAAAAAAAAACAAAAAgJhAAAAAAAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJhA
AAAAAAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJhAAAAAAAAAAAAAAACAAAAAgJgAAAAA
MAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJhAAAAAAAAA
AAAAAACAAAAAgKlAAAAAAAAAAAAAAACAAAAAgKkAAAAAAAAAAAAAAACAAAAAgKlAAAAAAAAAAAAA
AACAAAAAgKlAAAAAAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACA
AAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA
gKsAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKkA
AAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAA
MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAA
AAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAA
AACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACA
AAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA
gKsAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKtAAAAAMAAAAAAAAACAAAAAgKtA
AAAAMAAAAAAAAACAAAAAgKsAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKkAAAAA
MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKsAAAAAMAAAAAAAAACAAAAAgKsAAAAAMAAA
AAAAAACAAAAAgKsAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAA
AACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKsAAAAAMAAAAAAAAACA
AAAAgKsAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA
gKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKsAAAAAMAAAAAAAAACAAAAAgKsA
AAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAA
MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKsAAAAAMAAA
AAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAAAACAAAAAgKlAAAAAMAAAAAAA
AACAAAAAgKtAAAAAMAAAAAAAAACAAAAAgKtAAAAAMAAAAAAAAACAAAAAgKtAAAAAMAAAAAAAAACA
AAAAgJlAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA
gKkAAAAAMAAAAAAAAACAAAAAgKsAAAAAMAAAAAAAAACAAAAAgKsAAAAAMAAAAAAAAACAAAAAgJkA
AAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAA
AAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAMAAA
AAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJhAAAAAAAAAAAAA
AACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgAAEAABGDwAALhIAAE4UAAATGAAAihsAAAcfAAB+JAAA
+CgAAPkwAADiOAAAwkQAAGpQAABxUwAAElcAAFJbAAAyXwAAXmMAADIAAAA2AAAANwAAADgAAAA5
AAAAOwAAAD4AAABCAAAAQwAAAEcAAABNAAAAUgAAAFcAAABZAAAAXgAAAGEAAABkAAAAAAQAAMwN
AADvGAAA7xsAAGEdAAA6HwAAGyIAAAAkAABPKQAAZyoAAGorAABzMAAAOjIAADw0AACpNgAAzjgA
AEE7AACXPwAAdEEAAFtDAADnRQAAcUgAAChKAABbSwAAu1EAAONTAACYVAAAPFYAAOtWAADIWQAA
9loAAN9bAAAMXwAAXmMAADMAAAA1AAAAOgAAADwAAAA9AAAAPwAAAEAAAABBAAAARAAAAEUAAABG
AAAASAAAAEkAAABKAAAASwAAAEwAAABOAAAATwAAAFAAAABRAAAAUwAAAFQAAABVAAAAVgAAAFgA
AABaAAAAWwAAAFwAAABdAAAAXwAAAGAAAABiAAAAYwAAAAAEAABdYwAANAAAAAAAAAAHAAAACwAA
AGkHAAByBwAAdAoAAH0KAADeDAAA4gwAAMwNAADQDQAA4w0AAOcNAAAfEAAAIxAAAFgQAABcEAAA
LBEAADARAAAAGQAACRkAAJMZAACiGQAATh0AAE8dAADsHgAA+R4AAFUfAABiHwAAUiAAAF8gAADh
IAAA7iAAAOMiAADsIgAAWCQAAFwkAACeJQAAoCUAANMlAADaJQAA7yUAAPYlAAARJwAAJScAAJcq
AACgKgAAjy0AAJgtAACvLQAAuS0AAM8tAADZLQAA7y0AAP4tAAAHLgAAEC4AACcuAAAxLgAAOi4A
AEQuAACLLgAAmC4AAJ0uAACsLgAAIC8AACkvAABALwAASi8AAFMvAABdLwAApC8AALEvAAC2LwAA
xS8AAD0wAABGMAAAXTAAAGcwAABwMAAAejAAAMEwAADOMAAA0zAAAOIwAAA6MQAAQzEAAFoxAABk
MQAAejEAAIQxAACaMQAAqTEAAL0xAADGMQAAyzEAANUxAAAKMgAAFDIAAEgyAABVMgAAhDIAAJMy
AADDMgAAzDIAANEyAADbMgAADzMAABkzAABMMwAAWTMAAIgzAACXMwAA5TMAAO4zAADzMwAA/TMA
ADE0AAA7NAAAbjQAAHs0AACqNAAAuTQAAOI0AADrNAAAAjUAAAw1AAAiNQAALDUAAEI1AABRNQAA
ZTUAAG41AABzNQAAfTUAALE1AAC7NQAA7jUAAPs1AAAqNgAAOTYAAGM2AABsNgAAcTYAAHs2AACv
NgAAuTYAAOw2AAD5NgAAKDcAADc3AACJOAAAkjgAALA7AAC5OwAA0DsAANo7AADwOwAA+jsAABA8
AAAfPAAAKDwAADE8AABIPAAAUjwAAFs8AABlPAAArDwAALk8AAC+PAAAzTwAAEE9AABKPQAAYT0A
AGs9AAB0PQAAfj0AAMU9AADSPQAA1z0AAOY9AABePgAAZz4AAH4+AACIPgAAkT4AAJs+AADiPgAA
7z4AAPQ+AAADPwAAWz8AAGQ/AAB7PwAAhT8AAJs/AAClPwAAuz8AAMo/AADePwAA5z8AAOw/AAD2
PwAAK0AAADVAAABpQAAAdkAAAKVAAAC0QAAA5EAAAO1AAADyQAAA/EAAADBBAAA6QQAAbUEAAHpB
AACpQQAAuEEAAOhBAADxQQAA9kEAAABCAAA0QgAAPkIAAHFCAAB+QgAArUIAALxCAADrQgAA9EIA
AAtDAAAVQwAAK0MAADVDAABLQwAAWkMAAG5DAAB3QwAAfEMAAIZDAAC6QwAAxEMAAPdDAAAERAAA
M0QAAEJEAAByRAAAe0QAAIBEAACKRAAAvkQAAMhEAAD7RAAACEUAADdFAABGRQAAakUAAG5FAAAL
RgAAD0YAAGpJAAB1SQAAekkAAIVJAACNSgAAlkoAANRNAADdTQAA9E0AAP5NAAAUTgAAHk4AADRO
AABDTgAATE4AAFVOAABsTgAAdk4AAH9OAACJTgAAEU8AAB5PAAAjTwAAMk8AAKtPAAC0TwAAy08A
ANVPAADjTwAA7U8AADpQAABHUAAATFAAAFtQAADYUAAA4VAAAPhQAAACUQAAEFEAABpRAACjUQAA
sFEAALVRAADEUQAAPFIAAEVSAABcUgAAZlIAAG9SAAB5UgAAwFIAAM1SAADSUgAA4VIAAAZTAAAP
UwAAOlMAAERTAABaUwAAZFMAAHpTAACJUwAAnVMAAKZTAACsUwAAtlMAAOtTAAD1UwAAV1QAAGRU
AACTVAAAolQAANdUAADgVAAA5lQAAPBUAAApVQAAM1UAAGlVAAB2VQAApVUAALRVAADpVQAA8lUA
APhVAAACVgAAOVYAAENWAAB7VgAAiFYAALdWAADGVgAA9lYAAP9WAAAEVwAADlcAAEJXAABMVwAA
f1cAAIxXAAC7VwAAylcAAPlXAAACWAAALVgAADdYAABNWAAAV1gAAG1YAAB8WAAAkFgAAJlYAACf
WAAAqVgAAN1YAADnWAAAR1kAAFRZAACvWQAAvlkAAPJZAAD7WQAAAloAAAxaAABEWgAATloAAIZa
AACTWgAA7loAAP1aAADDWwAAzVsAAHNdAAB3XQAA8F0AAF9fAAAHABwABwAcAAcAHAAHABwABwAc
AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA
BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH
ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc
AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA
BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH
ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc
AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA
BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH
ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc
AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA
BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcABwAAAAAAsiwAALIsAACzLAAAtCwAAL4sAAC+
LAAAvywAAMAsAADZMQAA2jEAANsxAADbMQAAGDIAABkyAAAaMgAAGjIAAM46AADOOgAAzzoAANA6
AADaOgAA2joAANs6AADcOgAA+j8AAPs/AAA5QAAAOkAAADtAAAA7QAAAVkUAACJHAABySwAAfksA
AIZLAACHSwAAiksAAJFLAAAzTAAAOEwAAGpMAABsTAAAbUwAAG1MAACgTAAAoEwAAKFMAACiTAAA
pkwAAKhMAACpTAAAqUwAALJMAAC3TAAA/EwAAAJNAAALTQAAEE0AAFBNAABQTQAAVE0AAFlNAAAI
UgAAOlIAABBaAAAUWgAAFVoAABVaAAAWWgAAFloAABdaAAAXWgAAGFoAABhaAABWWgAAW1oAAMJa
AADDWgAAPl0AAO1dAADvXQAA8F0AAFxfAABfXwAAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAE
AAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQA
AwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAAD
AAQAAwAEAAMABAADAAQAAwAEAAMABwAHAAcA//8UAAAADABSAHUAcwBzACAASABvAHUAcwBsAGUA
eQBMAEMAOgBcAHAAcgBvAGcAcgBhAG0AIABmAGkAbABlAHMAXABxAHUAYQBsAGMAbwBtAG0AXABl
AHUAZABvAHIAYQBcAGEAdAB0AGEAYwBoAFwAQQBsAGcAbwByAGkAdABoAG0AIABmAG8AcgAgAEMA
bwBuAHMAdAByAHUAYwB0AGkAbgBnACAAQwBSAEwAcwAxAC4AZABvAGMADABSAHUAcwBzACAASABv
AHUAcwBsAGUAeQBMAEMAOgBcAHAAcgBvAGcAcgBhAG0AIABmAGkAbABlAHMAXABxAHUAYQBsAGMA
bwBtAG0AXABlAHUAZABvAHIAYQBcAGEAdAB0AGEAYwBoAFwAQQBsAGcAbwByAGkAdABoAG0AIABm
AG8AcgAgAEMAbwBuAHMAdAByAHUAYwB0AGkAbgBnACAAQwBSAEwAcwAxAC4AZABvAGMACABUAGkA
bQAgAFAAbwBsAGsALABBADoAXABBAGwAZwBvAHIAaQB0AGgAbQAgAGYAbwByACAAQwBvAG4AcwB0
AHIAdQBjAHQAaQBuAGcAIABDAFIATABzACAAZgBpAG4AYQBsAC4AZABvAGMAFABWAEEATABVAEUA
RAAgAFMATwBOAFkAIABDAFUAUwBUAE8ATQBFAFIAaQBDADoAXABXAEkATgBEAE8AVwBTAFwAQQBw
AHAAbABpAGMAYQB0AGkAbwBuACAARABhAHQAYQBcAE0AaQBjAHIAbwBzAG8AZgB0AFwAVwBvAHIA
ZABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAEEAbABnAG8AcgBp
AHQAaABtACAAZgBvAHIAIABDAG8AbgBzAHQAcgB1AGMAdABpAG4AZwAgAEMAUgBMAHMAIABmAGkA
bgBhAGwALgBhAHMAZAAUAFYAQQBMAFUARQBEACAAUwBPAE4AWQAgAEMAVQBTAFQATwBNAEUAUgA8
AEMAOgBcAFcASQBOAEQATwBXAFMAXABEAGUAcwBrAHQAbwBwAFwAQQBsAGcAbwByAGkAdABoAG0A
IABmAG8AcgAgAEMAbwBuAHMAdAByAHUAYwB0AGkAbgBnACAAQwBSAEwAcwAgAGYAaQBuAGEAbAAu
AGQAbwBjABQAVgBBAEwAVQBFAEQAIABTAE8ATgBZACAAQwBVAFMAVABPAE0ARQBSADwAQwA6AFwA
VwBJAE4ARABPAFcAUwBcAEQAZQBzAGsAdABvAHAAXABBAGwAZwBvAHIAaQB0AGgAbQAgAGYAbwBy
ACAAQwBvAG4AcwB0AHIAdQBjAHQAaQBuAGcAIABDAFIATABzACAAZgBpAG4AYQBsAC4AZABvAGMA
FABWAEEATABVAEUARAAgAFMATwBOAFkAIABDAFUAUwBUAE8ATQBFAFIAPABDADoAXABXAEkATgBE
AE8AVwBTAFwARABlAHMAawB0AG8AcABcAEEAbABnAG8AcgBpAHQAaABtACAAZgBvAHIAIABDAG8A
bgBzAHQAcgB1AGMAdABpAG4AZwAgAEMAUgBMAHMAIABmAGkAbgBhAGwALgBkAG8AYwAUAFYAQQBM
AFUARQBEACAAUwBPAE4AWQAgAEMAVQBTAFQATwBNAEUAUgA8AEMAOgBcAFcASQBOAEQATwBXAFMA
XABEAGUAcwBrAHQAbwBwAFwAQQBsAGcAbwByAGkAdABoAG0AIABmAG8AcgAgAEMAbwBuAHMAdABy
AHUAYwB0AGkAbgBnACAAQwBSAEwAcwAgAGYAaQBuAGEAbAAuAGQAbwBjAAgAVABpAG0AIABQAG8A
bABrAGkAQwA6AFwAVwBJAE4ARABPAFcAUwBcAEEAcABwAGwAaQBjAGEAdABpAG8AbgAgAEQAYQB0
AGEAXABNAGkAYwByAG8AcwBvAGYAdABcAFcAbwByAGQAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIA
eQAgAHMAYQB2AGUAIABvAGYAIABBAGwAZwBvAHIAaQB0AGgAbQAgAGYAbwByACAAQwBvAG4AcwB0
AHIAdQBjAHQAaQBuAGcAIABDAFIATABzACAAZgBpAG4AYQBsAC4AYQBzAGQACABUAGkAbQAgAFAA
bwBsAGsAIgBDADoAXABXAEkATgBEAE8AVwBTAFwARABlAHMAawB0AG8AcABcAFAASwBJAFgAIABk
AGUAbAB0AGEAcwAuAGQAbwBjAAQA1WoHBsaTbN7/D/8P/w//D/8P/w//D/8P/w8AAPgXsy/Gk2ze
/w//D/8P/w//D/8P/w//D/8PEADgFKVJ6ALyNf8P/w//D/8P/w//D/8P/w//DxAAugbSZY7tlGH/
D/8P/w//D/8P/w//D/8P/w8QAAEAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAMYAAAPhNACEYSY/hXG
BQAB0AIGXoTQAmCEmP5vKAADACgAAAApAAEAAAAEAAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhKAF
EYSY/hXGBQABoAUGXoSgBWCEmP4CAAEALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4Rw
CBGETP8VxgUAAXAIBl6EcAhghEz/AgACAC4AAQAAAACAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+E
QAsRhJj+FcYFAAFACwZehEALYISY/gIAAwAuAAEAAAAEgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAP
hBAOEYSY/hXGBQABEA4GXoQQDmCEmP4CAAQALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAAGAAA
D4TgEBGETP8VxgUAAeAQBl6E4BBghEz/AgAFAC4AAQAAAACAAQAAAAAAAAAAAAAAAAAAAAAAABgA
AA+EsBMRhJj+FcYFAAGwEwZehLATYISY/gIABgAuAAEAAAAEgAEAAAAAAAAAAAAAAAAAAAAAAAAY
AAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP4CAAcALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAA
GAAAD4RQGRGETP8VxgUAAVAZBl6EUBlghEz/AgAIAC4AAQAAAAAAAgAAAAAAAAAAAAAAAAAAAAAA
AxgAAA+E0AIRhJj+FcYFAAHQAgZehNACYISY/m8oAAMAKAAAACkAAQAAAASAAQAAAAAAAAAAAAAA
AAAAAAAAABgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/gIAAQAuAAEAAAACggEAAAAAAAAAAAAA
AAAAAAAAAAAYAAAPhHAIEYRM/xXGBQABcAgGXoRwCGCETP8CAAIALgABAAAAAIABAAAAAAAAAAAA
AAAAAAAAAAAAGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+AgADAC4AAQAAAASAAQAAAAAAAAAA
AAAAAAAAAAAAABgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/gIABAAuAAEAAAACggEAAAAAAAAA
AAAAAAAAAAAAAAAYAAAPhOAQEYRM/xXGBQAB4BAGXoTgEGCETP8CAAUALgABAAAAAIABAAAAAAAA
AAAAAAAAAAAAAAAAGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+AgAGAC4AAQAAAASAAQAAAAAA
AAAAAAAAAAAAAAAAABgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/gIABwAuAAEAAAACggEAAAAA
AAAAAAAAAAAAAAAAAAAYAAAPhFAZEYRM/xXGBQABUBkGXoRQGWCETP8CAAgALgABAAAABAACAAAA
AAAAAAAAAAAAAAAAAAADGAAAD4TQAhGEmP4VxgUAAdACBl6E0AJghJj+bygAAwAoAAAAKQABAAAA
BIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+AgABAC4AAQAA
AAKCAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EcAgRhEz/FcYFAAFwCAZehHAIYIRM/wIAAgAuAAEA
AAAAgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP4CAAMALgAB
AAAABIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+AgAEAC4A
AQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+E4BARhEz/FcYFAAHgEAZehOAQYIRM/wIABQAu
AAEAAAAAgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP4CAAYA
LgABAAAABIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4SAFhGEmP4VxgUAAYAWBl6EgBZghJj+AgAH
AC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EUBkRhEz/FcYFAAFQGQZehFAZYIRM/wIA
CAAuAAEAAAAEEAIAAAAAAAAAAABoAQAAAAAAAAMYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5v
KAADACgAAAApAAEAAAAEEAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhKAFEYSY/hXGBQABoAUGXoSg
BWCEmP4CAAEALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4RwCBGETP8VxgUAAXAIBl6E
cAhghEz/AgACAC4AAQAAAACQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EQAsRhJj+FcYFAAFACwZe
hEALYISY/gIAAwAuAAEAAAAEkAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhBAOEYSY/hXGBQABEA4G
XoQQDmCEmP4CAAQALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4TgEBGETP8VxgUAAeAQ
Bl6E4BBghEz/AgAFAC4AAQAAAACQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EsBMRhJj+FcYFAAGw
EwZehLATYISY/gIABgAuAAEAAAAEkAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhIAWEYSY/hXGBQAB
gBYGXoSAFmCEmP4CAAcALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4RQGRGETP8VxgUA
AVAZBl6EUBlghEz/AgAIAC4ABAAAAPgXsy8AAAAAAAAAAAAAAADgFKVJAAAAAAAAAAAAAAAAugbS
ZQAAAAAAAAAAAAAAANVqBwYAAAAAAAAAAAAAAAD///////////////////////8EAAAAAAAAAAAA
AAD//wQAAAAAAAAAAAAAAAAAAAA7LQAAPC0AAE4tAABjLQAAbC0AAHYtAAB3LQAAfS0AAI8tAAAH
LgAA5S4AAOYuAADsLgAAHy8AACAvAAACMAAAAzAAAAkwAAA8MAAAPTAAAB8xAAAgMQAAJjEAADox
AAC9MQAAojIAAKMyAACpMgAAwjIAAMMyAADJMwAAyjMAANAzAADkMwAA5TMAAMc0AADINAAAzjQA
AOI0AABlNQAARzYAAEg2AABONgAAYjYAAGM2AABANwAAQTcAAFs7AABdOwAAbzsAAIQ7AACNOwAA
lzsAAJg7AACeOwAAsDsAACg8AAAGPQAABz0AAA09AABAPQAAQT0AACM+AAAkPgAAKj4AAF0+AABe
PgAAQD8AAEE/AABHPwAAWz8AAN4/AADDQAAAxEAAAMpAAADjQAAA5EAAAMxBAADNQQAA00EAAOdB
AADoQQAA0EIAANFCAADXQgAA60IAAG5DAABWRAAAV0QAAF1EAABxRAAAckQAAFRFAABVRQAAgE0A
AIFNAACTTQAAqE0AALFNAAC7TQAAvE0AAMJNAADUTQAATE4AAGtPAABsTwAAd08AAKpPAACrTwAA
mFAAAJlQAACkUAAA11AAANhQAAABUgAAAlIAAAhSAAA7UgAAPFIAAOtSAADsUgAA8lIAAAZTAACd
UwAAsVQAALJUAAC9VAAA1lQAANdUAADIVQAAyVUAANRVAADoVQAA6VUAANpWAADbVgAA4VYAAPVW
AAD2VgAA3lcAAN9XAADlVwAA+VcAAJBYAADSWQAA01kAAN1ZAADxWQAA8lkAAAtbAAAMWwAA710A
APBdAABcXwAAX18AAAAAAAABAAAACAAAAAIBAAACAQAAAgEAAAIBAAAeAQAAAgEAAAIBAAACAQAA
AgEAAB4BAAACAQAAAgEAAAIBAAACAQAAHgEAAAIBAAACAQAAAgEAAAIBAAAeAQAAAgEAAAIBAAAC
AQAAAgEAAB4BAAACAQAAAgEAAAIBAAACAQAAHgEAAAIBAAACAQAAAgEAAAIBAAAeAQAAAgEAAAIB
AAACAQAAAgEAAB4BAAACAQAAAgEAAAIBAAACAQAAFgEAAAEAAAAIAAAAAgEAAAIBAAACAQAAAgEA
AB4BAAACAQAAAgEAAAIBAAACAQAAHgEAAAIBAAACAQAAAgEAAAIBAAAeAQAAAgEAAAIBAAACAQAA
AgEAAB4BAAACAQAAAgEAAAIBAAACAQAAHgEAAAIBAAACAQAAAgEAAAIBAAAeAQAAAgEAAAIBAAAC
AQAAAgEAAB4BAAACAQAAAgEAAAIBAAACAQAAHgEAAAIBAAACAQAAAgEAAAIBAAAWAQAAAQAAAAgA
AAACAQAAAgEAAAIBAAACAQAAHgEAAAIBAAACAQAAAgEAAAIBAAAeAQAAAgEAAAIBAAACAQAAAgEA
AB4BAAACAQAAAgEAAAIBAAACAQAAHgEAAAIBAAACAQAAAgEAAAIBAAAeAQAAAgEAAAIBAAACAQAA
AgEAAB4BAAACAQAAAgEAAAIBAAACAQAAHgEAAAIBAAACAQAAAgEAAAIBAAAeAQAAAgEAAAIBAAAC
AQAAAgEAAB4BAAACAQAAAgEAAAIBAAACAQAAHgEAAAIBAAACAQAAAgEAAAIBAAAWAQAAAd0AAAAA
AAABAAAA/0APgAEAOlIAADpSAAAUnGQAAQABADpSAAAAAAEAOlIAACcJuhICEAAAAAAAAABeXwAA
YAAACABAAAD//wUAAAAHAFUAbgBrAG4AbwB3AG4ACABUAGkAbQAgAFAAbwBsAGsADABEAGEAdgBp
AGQAIABDAG8AbwBwAGUAcgAMAFIAdQBzAHMAIABIAG8AdQBzAGwAZQB5ABQAVgBBAEwAVQBFAEQA
IABTAE8ATgBZACAAQwBVAFMAVABPAE0ARQBSAP//BQAIAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAA
AAAAAAACAAAAAAAAAAAAAwAAAAAAAAAAAAQA//8FAAAAAAAAAAAAAAAAAP//AAACAP//AAAAAP//
AAACAP//AAAAAAQAAABHFpABAAACAgYDBQQFAgMEhzoAAAAAAAAAAAAAAAAAAP8AAAAAAAAAVABp
AG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAA
AAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzJpABAAACCwYEAgICAgIEhzoAAAAAAAAAAAAAAAAA
AP8AAAAAAAAAQQByAGkAYQBsAAAAPzWQAQAAAgcDCQICBQIEBIc6AAAAAAAAAAAAAAAAAAD/AAAA
AAAAAEMAbwB1AHIAaQBlAHIAIABOAGUAdwAAACIABABxiIwAAPDQAgAAaAEAAAAAnFNVhpxTVYZG
U1WGAgAiAAAAlg0AAHVNAAABACcAAAAEAAMQpQAAAAAAAAAAAAAAAQABAAAAAQAAAAAAAAAhAwDw
EAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtBfADeAC0AIKCEjAAABAAGQBkAAAAGQAAAB9f
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABXIQAAAAAAAAAAAAAA
AAAAAAAAAAAAAgAAAAAAAAAAAAAygxEA8BAA3wMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAD//xIAAAAAAAAAPwBBAGwAZwBvAHIAaQB0AGgAbQAgAGYAbwByACAAQwBvAG4AcwB0AHIAdQBj
AHQAaQBuAGcAIABDAFIATABzACAAZgByAG8AbQAgAGEAIABiAGEAcwBlACAAQwBSAEwAIABhAG4A
ZAAgAGEAIABkAGUAbAB0AGEAIABDAFIATAAAAAAAAAAIAFQAaQBtACAAUABvAGwAawAIAFQAaQBt
ACAAUABvAGwAawAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAoCAAAAAAAAAAAAAAAAAAAAAAAB
AAAA4IWf8vlPaBCrkQgAKyez2TAAAADAAQAAEgAAAAEAAACYAAAAAgAAAKAAAAADAAAA6AAAAAQA
AAD0AAAABQAAAAgBAAAGAAAAFAEAAAcAAAAgAQAACAAAADQBAAAJAAAASAEAABIAAABUAQAACgAA
AHABAAALAAAAfAEAAAwAAACIAQAADQAAAJQBAAAOAAAAoAEAAA8AAACoAQAAEAAAALABAAATAAAA
uAEAAAIAAADkBAAAHgAAAEAAAABBbGdvcml0aG0gZm9yIENvbnN0cnVjdGluZyBDUkxzIGZyb20g
YSBiYXNlIENSTCBhbmQgYSBkZWx0YSBDUkwAHgAAAAEAAAAAbGdvHgAAAAkAAABUaW0gUG9sawAg
Zm8eAAAAAQAAAABpbSAeAAAAAQAAAABpbSAeAAAACwAAAE5vcm1hbC5kb3QAbx4AAAAJAAAAVGlt
IFBvbGsAdABvHgAAAAIAAAAyAG0gHgAAABMAAABNaWNyb3NvZnQgV29yZCA5LjAAckAAAAAATO+/
BAAAAEAAAAAADIZ8c9nAAUAAAAAAeBLxftnAAUAAAAAAeBLxftnAAQMAAAABAAAAAwAAAJYNAAAD
AAAAdU0AAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQKAgAAAAAAAAAAAAAAAAAAAAAAAQAAAALVzdWc
LhsQk5cIACss+a4wAAAANAEAAAwAAAABAAAAaAAAAA8AAABwAAAABQAAAIgAAAAGAAAAkAAAABEA
AACYAAAAFwAAAKAAAAALAAAAqAAAABAAAACwAAAAEwAAALgAAAAWAAAAwAAAAA0AAADIAAAADAAA
ABQBAAACAAAA5AQAAB4AAAANAAAAQ1NEL0lUTC9OSVNUAABvAAMAAAClAAAAAwAAACcAAAADAAAA
H18AAAMAAADtDgkACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAAEAAAABB
bGdvcml0aG0gZm9yIENvbnN0cnVjdGluZyBDUkxzIGZyb20gYSBiYXNlIENSTCBhbmQgYSBkZWx0
YSBDUkwADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAAL
AAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkA
AAAaAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAA
ACgAAAApAAAAKgAAACsAAAAsAAAALQAAAC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQAAAA1AAAA
NgAAADcAAAA4AAAAOQAAADoAAAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABBAAAAQgAAAEMAAABE
AAAARQAAAEYAAABHAAAASAAAAEkAAABKAAAASwAAAEwAAABNAAAATgAAAE8AAABQAAAAUQAAAFIA
AABTAAAAVAAAAFUAAABWAAAAVwAAAFgAAABZAAAAWgAAAFsAAABcAAAAXQAAAF4AAABfAAAAYAAA
AGEAAABiAAAAYwAAAGQAAABlAAAA/v///2cAAABoAAAAaQAAAGoAAABrAAAAbAAAAG0AAABuAAAA
bwAAAHAAAABxAAAAcgAAAHMAAAB0AAAAdQAAAHYAAAB3AAAAeAAAAHkAAAB6AAAAewAAAHwAAAB9
AAAAfgAAAH8AAACAAAAAgQAAAIIAAACDAAAAhAAAAIUAAACGAAAAhwAAAIgAAACJAAAA/v///4sA
AACMAAAAjQAAAI4AAACPAAAAkAAAAJEAAAD+////kwAAAJQAAACVAAAAlgAAAJcAAACYAAAAmQAA
AP7////9/////f///50AAAD+/////v////7/////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAA
AAAAAAAAAACgoSoPf9nAAZ8AAACAAAAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIA////////////////AAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZgAAAKlGAAAAAAAAVwBvAHIAZABEAG8AYwB1
AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgEFAAAA
//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIsoAAAAAAAAF
AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAKAACAQIAAAAEAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AIoAAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0A
YQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAkgAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgEBAAAABgAAAP////8AAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAagAAAAAAAABPAGIAagBlAGMAdABQAG8A
bwBsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgABAP//////
/////////wAAAAAAAAAAAAAAAAAAAAAAAAAAoKEqD3/ZwAGgoSoPf9nAAQAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAQAAAP7/////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29mdCBXb3Jk
IERvY3VtZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAA==
--=====================_104696206==_--



Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id LAA21196 for <[e-mail]>; Thu, 10 May 2001 11:37:12 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 10 May 2001 18:36:55 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA24424 for <[e-mail]>; Thu, 10 May 2001 14:37:14 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <JY8NWWPM>; Thu, 10 May 2001 14:37:13 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.11]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JY8NWWP2; Thu, 10 May 2001 14:37:00 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 10 May 2001 14:35:58 -0400
Subject: Re: delta CRLs
In-Reply-To: <[e-mail]. com>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Denis:

Please excuse the half-done message from this morning.  My mailer and I had 
a disagreement...

Anyway, since I was not going to get the full message out before the end of 
the business day in France, I took the time to coordinate a response with 
Tim Polk and David Cooper.  This mail thread is quite long, so hopefully 
our coordination on the side will reduce the overall number of messages to 
the list and help to reach consensus faster.

Here goes ....

 >There is difference between a base CRL and a full CRL : a base CRL MUST
 >include a freshestCRL extension (a.k.a. a Delta CRL distribution point),
 >whereas a full CRL may not include that extension. In other words, a base
 >CRL is a also a full CRL, but a full CRL is not necessarily a base CRL.

There is no requirement in X.509 to include any extension in a certificate 
or CRL advertising the availability of delta CRLs. PKIX makes the 
freshestCRL extension available for advertising the existence of delta 
CRLs, but again does not mandate its use. Furthermore, even if the 
freshestCRL extension is used, it may be placed in either the certificate 
or the full CRL. If the extension is placed in certificates, there is no 
need for it to be in the full CRL (but, it could be).

Finally, if delta CRLs are being issued, and are being advertised through 
the freshestCRL CRL extension, then the extension should be included in all 
full CRLs for that scope, not just the base CRLs. If a relying party 
obtains the most recently issued full CRL for a scope from a repository, 
and that full CRL is not a base CRL, how will the relying party know that 
delta CRLs are available?

 >At any time a CA may issue a full CRL, whether or not a base CRL has already
 >been issued. This additional CRL SHOULD have nextUpdate equal to the
 >nextUpdate of the last issued full CRL. However, there is no guarantee that
 >this additional CRL will ever be seen by the relying party (because there
 >will be two CRLs matching the thisUpdate and nextUpdate rule and if one is
 >deleted, this is not seen by a relying party).

The nextUpdate field in a full CRL (base or otherwise) should specify the 
time by which new revocation information will be available. So, if a new 
base CRL is issued once a day, but full CRLs are issued every hour, the 
nextUpdate field of each full CRL should one hour after that CRL's 
thisUpdate time.

 >Due to the fact that CRLs numbers are strictly increasing, two CRLs whether
 >they are a base CRL or delta CRL, CANNOT have the same CRL number. So a
 >delta CRL and a full CRL that cover the same scope and are issued at the
 >same time CANNOT have the same number.

We disagree.  If a full CRL and a delta CRL are issued at the same time for 
the same scope, then they ARE the same CRL and MUST have the same CRL number.

 >If a full CRL is issued, its CRL
 >number bears no relationship with the previous base CRL, if any.

Again, we disagree. A sequence of CRLs for a given scope must contain a 
monotonically increasing sequence of CRL numbers. Relying parties that do 
not process delta CRLs, and thus do not recognize the non-critical 
freshestCRL extension, will not be able to distinguish between those full 
CRLs that are base CRLs and those full CRLs that are not base CRLs. The CRL 
numbers for these full CRLs must be from one monotonically increasing sequence.

 >The only
 >relationship between the numbers is defined by the rule that CRLs numbers
 >are strictly increasing. As Santosh said : "the CRL number is unique
 >whether it is a base or a delta ".
 >
 >This is fairly important to be able to unambiguously (and thus uniquely)
 >refer to a CRL by only providing its CRL number.

Exactly. If a full CRL and the delta CRL are issued for the same scope at 
the same time, they are the same CRL. The CRL number unambiguously and 
uniquely refers to this ONE CRL.

 >Besides the fact that a CRL issued later MUST have a higher CRL number, full
 >CRLs and delta CRLs have independent numbering rules. As noticed by Santosh,
 >" if the delta thisUpdate > base thisUpdate, delta CRL number > base CRL
 >number (for the same or no stream identifier).

If you agree that delta thisUpdate > base thisUpdate implies delta CRL 
number > base CRL, then you are acknowledging that the CRL numbers of the 
full CRLs and delta CRLs are not independent.

 >As Santosh said : "a check based on thisUpdate is more general and
 >preferred [to the use of CRL numbers]. "
 >
 >Related to the three rules mentioned by Russ :
 >
 >1) the first rule is not understandable to me.
 >2) the second rule does not say anything more than the basic rule valid
 >    for any CRL (i.e. a CRL issued later MUST have a higher CRL number).
 >3) we will debate the hold condition, once we will have sorted the main
 >    issue.
 >
 >Russ said : "If separate number sequence is used, then you will have to
 >periodically fetch base CRLs ". This is true.
 >
 >Tim said that he would *not* like to be forced to download new base CRLs.
 >This is the core of the "dispute".

Our goal should be to allow delta CRL enabled clients to obtain accurate 
information in the most efficient manner possible. Forcing clients to 
periodically download full CRLs, when this is not necessary, is inefficient.

 > From the definition of what a delta CRL is, it is *not* possible to
 >get rid of the fetching of base CRLs. Unless we add a new sentence to
 >expand/change that definition, base CRL fetching will remain mandatory.

True. However, if one performs validations frequently enough, it is 
possible to obtain a single full CRL and then subsequently download only 
delta CRLs. We need to require that full CRL be issued periodically so that 
clients whose locally stored information is not sufficiently up-to-date to 
apply the delta CRLs being issued can obtain the full CRLs that they need, 
but we should not require clients to download full CRLs when it is not 
necessary for them to do so.

 >Remember that the goal of delta CRLs is to provide the freshest information,
 >and to my knowledge the goal was not to get rid of the fetching of base CRLs
 >(which may less frequent due to the support of delta CRLs).

Yes, but the goal should be to minimize the fetching of full CRLs.

 >If I understand correctly, Tim/David/Russ would like to *always* achieve the
 >following property : it is possible to reconstruct the current CRL by using
 >a base CRL from, e.g. 1990, i.e. by capturing every delta CRL that has been
 >issued at the same time a base CRL was issued and which contains updates
 >made to the *previous* base.
 >
 >By this way the fetching of base CRLs could be avoided. However, note that
 >it is perfectly " legal " to stop issuing base and delta CRLs during some
 >period of time and to issue full CRLs instead (see the difference between
 >"full" and "base" at the top of this e-mail). In other words there is no
 >need to issue a new base CRL at the end of the validity period of the
 >previous base CRL. Doing this would mandate to prescribe issuing rules
 >for CAs that we have not prescripted.

You are mixing apples and oranges. Obviously the scheme of keeping 
up-to-date by obtaining a base from 1990 and then only downloading deltas 
will only work so long as deltas continue to be issued. If the CRL issuer 
ceases to issue deltas, then the relying parties will have to revert to 
downloading full CRLs.

 >I will now raise a series of questions, for which I believe we have
 >different answers. Tim/David/Russ do not hesitate to correct
 >if my guess is wrong. ;-)
 >
 >Common point:
 >
 >1) What will be the value of the nextUpdate field from the last issued delta
 >CRL for a given base CRL ?
 >
 >Denis: the nextUpdate field from the last issued delta CRL MUST be equal to
 >the value of nextUpdate from the base CRL.
 >
 >Tim/David/Russ: ???

The nextUpdate field in a base CRL states when the next full CRL will be 
available. This is important for supporting clients that do not handle 
delta CRLs. The nextUpdate field in a delta CRL states when the next CRL 
(either a delta CRL or a full CRL) will be available. As a general rule, if 
the CA is continuing to issue deltas, the nextUpdate in the delta will be 
the time by which the next delta will be available. If this is the last 
delta that the CA is going to issue, then the nextUpdate in the delta will 
be the time by which the next full CRL will be available. ("Available" 
SHOULD reflect distribution delays associated with the repository 
architecture.)

 >2) Does a CA needs to issue a delta CRL at the time a full CRL is issued ?
 >
 >Denis: No.
 >Tim/David/Russ : ???

No. A CA never is required to issue deltas. However, it would be helpful to 
delta CRL enabled clients to allow them to construct the full CRL.

If the full CRL contains a freshestCRL extension, then it is a very good 
idea to generate a delta CRL at the same time. In this way, any client will 
be able to find a current delta CRL.

 >3) Does a CA needs to issue a new base CRL at the end of the validity of a
 >current base CRL ?
 >
 >Denis: No.
 >Tim/David/Russ : ???

No. HOWEVER, the CA must issue a new full CRL by the nextUpdate in the 
previously issued full CRL (whether that full CRL is a base CRL or not). 
There is no requirement that the next full CRL be a base CRL. (The CA could 
quit issuing deltas, etc. etc.)

Every base CRL MUST be a full CRL, but not every full CRL is a base CRL. 
But, a CA could make every full CRL a base CRL if they wanted to.

 >4) Does a CA needs to issue a delta CRL at the same time a new base is
 >issued ?
 >
 >Denis: Yes. The delta CRL refers to the *new* base.
 >Tim/David/Russ : ???

No. HOWEVER, in practice we belive that CAs will do so. The delta CRL needs 
to exist so that clients can follow the freshest CRL extension (either in a 
certificate or a base CRL). The delta CRL that is issued at the same time 
SHOULD point to a previously issued full CRL (which will then, by 
definition be a base CRL) whenever possible. There is no information to add 
to the new base CRL! By providing the delta as an update to a previous base 
CRL, clients can download the delta CRL to construct the new base CRL.

 >The last point highlights the most noticeable difference. Other differences
 >appears when considering the guaranty to get the freshest information :
 >using the traditional scheme and the thisUpdate and nextUpdate fields the
 >guaranty to get the freshest information is obtained, but cannot be obtained
 >using the other scheme. :-(
 >
 >Several people are referring to the X.509 document for arguments to support
 >that discussion. However, it is important to remember that we are defining
 >PKIX, not X.509, so we DO NOT need to copy and paste everything from X.509,
 >but only what we believe is relevant.

PKIX is a profile of X.509.  PKIX may impose additional requirements beyond 
those in X.509 or may exclude features that are optional in X.509, but 
otherwise PKIX must be consistent with X.509. In that context, references 
to X.509 are appropriate.

 >We first need to clearly define the processing rules applicable to the
 >relying parties. These rules will certainly contain SHALL/MUST statements,
 >but may also include some MAY statements which may even be conditional to
 >what the CA is doing. (I let Tim/David or Russ provide the MAY statement).
 >
 >Here is a proposal for the MUST statement, based on the previous text I
 >produced:
 >
 >    An application that is wishing to take advantage of delta CRLs
 >    for a given scope, MUST first find a base CRL for that scope,
 >    i.e. a full CRL that that contains a freshestCRL extension
 >    (a.k.a. a Delta CRL distribution point).

No. The relying party needs a full CRL (either one that has been downloaded 
from a repository or one that has been locally generated) against which the 
delta CRL of interest may be applied. There is no requirement that the full 
CRL be a base CRL.

 >    It may then construct
 >    an updated CRL for that base, for a specific time T, by combining
 >    it with a delta CRL which contains a delta CRL indicator extension
 >    with the same CRL number as the base CRL.

It may construct an updated CRL by combining the delta CRL with any full 
CRL whose CRL number is greater than or equal to the CRL number of the 
referenced base.  By saying "equal" instead of "greater than or equal" we 
would be hiding useful information from implementors. We should not be 
hiding useful information.

 >    Applications that support
 >    delta CRLs MUST ensure that time T falls between thisUpdate and
 >    nextUpdate for both the base CRL and the delta CRL.

As stated above, the nextUpdate field in a base CRL specifies the time by 
which new revocation information will be available through full CRLs. A 
delta CRL may be applied to a base CRL as long as the CRL number in the 
base CRL is greater than or equal to the CRL number of the base CRL 
referenced by the delta CRL. The nextUpdate time of the base CRL is irrelevant.

 >    Note: An application could also reconstruct an updated CRL, for
 >    a specific time T, by using a previously locally reconstructed CRL
 >    based on the current base CRL, and combining it with a delta CRL which
 >    contains a delta CRL indicator extension with the same CRL number as
 >    the base CRL.

Same problem as above.  Need to say "greater than or equal to".

 >We also need to clearly separate the issuing rules applicable for the CAs.
 >These rules will certainly contain SHALL statements, but could also include
 >some MAY statements. (I let Tim/David or Russ provide the MAY statement).
 >
 >Here is a proposal for the MUST statement, based on the previous text I
 >produced:
 >
 >    A CA that supports delta-CRLs, MUST issue a base CRL,

This is an unnecessary statement. A delta CRL must include a BaseCRLNumber. 
The CRL specified by that BaseCRLNumber is by definition a base CRL.  Of 
course, the referenced base CRL MUST be a full CRL.

 >    i.e. a full
 >    CRL that contains a freshestCRL extension (a.k.a. a Delta CRL
 >    distribution point).

While it might be a good idea to mandate the inclusion of the frestestCRL 
extension in full CRLs that are issued for scopes in which delta CRLs are 
also being issued, there is currently no such requirement in the draft PKIX 
profile.

 >    For any time T until the nextUpdate time
 >    indicated in a base CRL, the CA MUST provide one and only one
 >    delta CRL that refers to that base CRL and for which time T
 >    falls between thisUpdate and nextUpdate from the delta CRL.

This sentence has several problems:

1) The nextUpdate time of a base CRL is the time when the next full CRL 
will be available, which may precede the time that the next base CRL will 
be issued.

2) There is no requirement that a delta CRL use the most recently issued 
base CRL as its base.  I suppose that we could add this requirement for the 
PKIX profile, but why?  Does it really simplify the client?  Or, does it 
just make it a wee bit harder to make a conforming CA that supports delta CRLs?

3) If the thisUpdate time of one delta CRL must equal the nextUpdate time 
of the previously issued delta CRL, then no time can be allotted to account 
for propagation delays between when a delta-CRL is issued and when it is 
available in repositories for relying parties to obtain. Thus, there would 
be gaps between when the nextUpdate time of one delta-CRL was reached and 
when the next delta-CRL was available.

4) There is nothing in either X.509 or the PKIX profile that prevents a CA 
from issuing an unscheduled (or "emergency") delta CRL. And, there should 
not be!  Many CAs intend to issue a new CRL (delta or otherwise) 
immediately upon the revocation of a certificate due to key compromise. 
When such an "emergency" delta CRL is issued, there will be two delta CRLs 
for which T falls between thisUpdate and nextUpdate. While it is true that 
there is no guarantee that relying parties will obtain the fresher of these 
two delta CRLs, that is no reason to prevent the CA from issuing the 
"emergency" delta.  Some clients will obtain the emergency CRL.

 >In his e-mail from Wednesday, May 9, David said that delta-CRL processing
 >rules could be base on time instead of CRL numbers. This is a point of which
 >I strongly agree. Let us do it!
 >
 >(However, there is no need to add to PKIX, as he suggested, the support of
 >the baseUpdateTime extension from X.509 which would even more complicate the
 >problem.)

No. In order to base delta CRL processing on time, the baseUpdateTime 
extension must be present in the delta CRL. Furthermore, the presence of 
this extension would not complicate the problem. baseUpdateTime is a 
non-critical extension that merely provides useful information. If you 
don't think that the information provided by baseUpdateTime is useful, 
ignore it. Since the extension is non-critical and can be ignored, its 
presence can not complicate the problem.

At 09:05 AM 5/10/2001 -0400, Housley, Russ wrote:
>Denis:
>
>>There is difference between a base CRL and a full CRL
>
>You are quite right.  I, for one, will try to be more careful about the 
>use of them.
>
>>Due to the fact that CRLs numbers are strictly increasing, two CRLs whether
>>they are a base CRL or delta CRL, CANNOT have the same CRL number.
>
>I disagree.  A full CRL (that may be a base CRL for subsequent delta CRLs) 
>and a delta CRL issued at the same time as that full CRL may actually 
>represent the same revocation information.  In this case, they are the 
>same CRL, and they should have the same number.  There have been several 
>tables posted that illustrate this numbering scheme, and I do not see any 
>text in X.509-200 that indicates this scheme is
[snip - truncate - the message is too long anyway]


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id KAA19648 for <[e-mail]>; Thu, 10 May 2001 10:55:48 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 10 May 2001 17:55:30 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id NAA21233; Thu, 10 May 2001 13:55:48 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <JY8NWVZ4>; Thu, 10 May 2001 13:55:47 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.11]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JY8NWVZQ; Thu, 10 May 2001 13:55:37 -0400
From: "Housley, Russ" <[e-mail]>
To: Santosh Chokhani <[e-mail]>
Cc: Denis Pinkas <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 10 May 2001 11:15:25 -0400
Subject: RE: delta CRLs
In-Reply-To: <[e-mail]. com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Santosh:

>In general, my reading of the standard is that a base CRL need not have 
>freshest CRL extension in it.

That is correct.  The freshest CRL extension is OPTIONAL.  And, it can 
appear in either the certificate or the base CRL or both.

Russ


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA17738 for <[e-mail]>; Thu, 10 May 2001 10:14:38 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <K4X9NKRQ>; Thu, 10 May 2001 13:14:09 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Sharon Boeyen <[e-mail]>, "'Denis Pinkas'" <[e-mail]>, Carlin Covey <[e-mail]>
Cc: [e-mail]
Subject: RE: delta CRLs
Date: Thu, 10 May 2001 13:03:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D973.34078B70"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D973.34078B70
Content-Type: text/plain;
	charset="iso-8859-1"

I agree with Sharon.
 
-----Original Message-----
From: Sharon Boeyen [mailto:[e-mail]]
Sent: Thursday, May 10, 2001 1:04 PM
To: 'Denis Pinkas'; Carlin Covey; Sharon Boeyen
Cc: [e-mail]
Subject: RE: delta CRLs



A full CRL is a CRL that is complete for a given scope. A base CRL is a CRL 
that is the foundation for a delta CRL. I think the reason the wording in 
the definitions doesn't tie them together any more than that is because of 
a nuance where a delta CRL may reference a base CRL that was never actually 
issued as a full CRL. This is the case where the delta provides updates 
from a certain point in time, but it may be the case, in some environments, 
that full CRLs are never issued and the relying parties always build their 
local full CRLs from deltas. I realize that is not the case PKIX describes, 
but that's at least one reason the 509 definitions are the way they are (and

yes there are definitions in clause 3 for both base CRL and full CRL). 
So, the term base is only relevant when used in the context of a delta that 
points to it. 

As for freshestRevocationInfo, that is not mandated by 509, in the same 
way that other extensions are not. It is one way to indicate where to 
go to find deltas but there can be others (e.g. perhaps the relying 
parties know that there is one indirect CRL that provides delta info 
for all CAs inside an organization - perhaps this info is listed on 
their web site). If PKIX wanted to mandate it they could, but 509 
certainly does not. 

Cheers, 
Sharon 

> -----Original Message----- 
> From: Denis Pinkas [ mailto:[e-mail]
<mailto:[e-mail]> ] 
> Sent: Thursday, May 10, 2001 12:30 PM 
> To: Carlin Covey; Sharon Boeyen 
> Cc: [e-mail] 
> Subject: Re: delta CRLs 
> 
> 
> Carlin and Sharon (at the same time), 
> 
> > Denis, 
>  
> > Now I'm confused again (or still).  
> 
> :-) 
> 
> > I agree that there is a difference 
> > between a base CRL and a full CRL.  However, my 
> understanding was that a CRL 
> > is a "base CRL" with respect to some delta CRL only by 
> virtue of having been 
> > so identified in that delta CRL. 
> 
> I believe that a base CRL must include the Freshest CRL 
> extension (a.k.a. 
> Delta CRL Distribution Point) defined in section 4.2.1.16. It 
> indicates both 
> that the service exists and where to fetch the information. It is a 
> non-critical extension so that a base CRL may also be used as 
> a full CL for 
> relying parties not supporting delta CRLs. 
> 
> > According to the PKIX profile, this base CRL must be a full CRL 
> > (complete for the intended scope).  
> > I believe that X.509 does not require that a base CRL be a full CRL. 
> 
> You just say above: "According to the PKIX profile, this base 
> CRL must be a 
> full CRL (complete for the intended scope". So do you mean 
> that X.509 and 
> PKIX are taking different approaches ? 
> 
> Regards, 
> 
> Denis 
> 
> > Regards, 
> > 
> > Carlin 
> > 
> > ____________________________ 
> > 
> > -  Carlin Covey 
> >    Cylink Corporation 
> > 
> > -----Original Message----- 
> > From: Denis Pinkas [ mailto:[e-mail]
<mailto:[e-mail]> ] 
> > Sent: Thursday, May 10, 2001 1:19 AM 
> > Cc: [e-mail] 
> > Subject: Re: delta CRLs 
> > 
> > Tim, David, Russ, Santosh, Carlin, and many others ... 
> > 
> > There is difference between a base CRL and a full CRL : a 
> base CRL MUST 
> > include a freshestCRL extension (a.k.a. a Delta CRL 
> distribution point), 
> > whereas a full CRL may not include that extension. In other 
> words, a base 
> > CRL is a also a full CRL, but a full CRL is not necessarily 
> a base CRL. 
> > 
> > At any time a CA may issue a full CRL, whether or not a 
> base CRL has already 
> > been issued. This additional CRL SHOULD have nextUpdate equal to the 
> > nextUpdate of the last issued full CRL. However, there is 
> no guarantee that 
> > this additional CRL will ever be seen by the relying party 
> (because there 
> > will be two CRLs matching the thisUpdate and nextUpdate 
> rule and if one is 
> > deleted, this is not seen by a relying party). 
> > 
> > Due to the fact that CRLs numbers are strictly increasing, 
> two CRLs whether 
> > they are a base CRL or delta CRL, CANNOT have the same CRL 
> number. So a 
> > delta CRL and a full CRL that cover the same scope and are 
> issued at the 
> > same time CANNOT have the same number. If a full CRL is 
> issued, its CRL 
> > number bears no relationship with the previous base CRL, if 
> any. The only 
> > relationship between the numbers is defined by the rule 
> that CRLs numbers 
> > are strictly increasing. As Santosh said : "the CRL number is unique 
> > whether it is a base or a delta ". 
> > 
> > This is fairly important to be able to unambiguously (and 
> thus uniquely) 
> > refer to a CRL by only providing its CRL number. 
> > 
> > Besides the fact that a CRL issued later MUST have a higher 
> CRL number, full 
> > CRLs and delta CRLs have independent numbering rules. As 
> noticed by Santosh, 
> > " if the delta thisUpdate > base thisUpdate, delta CRL 
> number > base CRL 
> > number (for the same or no stream identifier). 
> > 
> > As Santosh said : "a check based on thisUpdate is more general and 
> > preferred [to the use of CRL numbers]. " 
> > 
> > Related to the three rules mentioned by Russ : 
> > 
> > 1) the first rule is not understandable to me. 
> > 2) the second rule does not say anything more than the 
> basic rule valid 
> >    for any CRL (i.e. a CRL issued later MUST have a higher 
> CRL number). 
> > 3) we will debate the hold condition, once we will have 
> sorted the main 
> >    issue. 
> > 
> > Russ said : "If separate number sequence is used, then you 
> will have to 
> > periodically fetch base CRLs ". This is true. 
> > 
> > Tim said that he would *not* like to be forced to download 
> new base CRLs. 
> > This is the core of the "dispute". 
> > 
> > >From the definition of what a delta CRL is, it is *not* possible to 
> > get rid of the fetching of base CRLs. Unless we add a new 
> sentence to 
> > expand/change that definition, base CRL fetching will 
> remain mandatory. 
> > 
> > Remember that the goal of delta CRLs is to provide the 
> freshest information, 
> > and to my knowledge the goal was not to get rid of the 
> fetching of base CRLs 
> > (which may less frequent due to the support of delta CRLs). 
> > 
> > If I understand correctly, Tim/David/Russ would like to 
> *always* achieve the 
> > following property : it is possible to reconstruct the 
> current CRL by using 
> > a base CRL from, e.g. 1990, i.e. by capturing every delta 
> CRL that has been 
> > issued at the same time a base CRL was issued and which 
> contains updates 
> > made to the *previous* base. 
> > 
> > By this way the fetching of base CRLs could be avoided. 
> However, note that 
> > it is perfectly " legal " to stop issuing base and delta 
> CRLs during some 
> > period of time and to issue full CRLs instead (see the 
> difference between 
> > "full" and "base" at the top of this e-mail). In other 
> words there is no 
> > need to issue a new base CRL at the end of the validity 
> period of the 
> > previous base CRL. Doing this would mandate to prescribe 
> issuing rules 
> > for CAs that we have not prescripted. 
> > 
> > I will now raise a series of questions, for which I believe we have 
> > different answers. Tim/David/Russ do not hesitate to correct 
> > if my guess is wrong. ;-) 
> > 
> > Common point: 
> > 
> > 1) What will be the value of the nextUpdate field from the 
> last issued delta 
> > CRL for a given base CRL ? 
> > 
> > Denis: the nextUpdate field from the last issued delta CRL 
> MUST be equal to 
> > the value of nextUpdate from the base CRL. 
> > 
> > Tim/David/Russ: ??? 
> > 
> > 2) Does a CA needs to issue a delta CRL at the time a full 
> CRL is issued ? 
> > 
> > Denis: No. 
> > Tim/David/Russ : ??? 
> > 
> > 3) Does a CA needs to issue a new base CRL at the end of 
> the validity of a 
> > current base CRL ? 
> > 
> > Denis: No. 
> > Tim/David/Russ : ??? 
> > 
> > 4) Does a CA needs to issue a delta CRL at the same time a 
> new base is 
> > issued ? 
> > 
> > Denis: Yes. The delta CRL refers to the *new* base. 
> > Tim/David/Russ : Yes. The delta CRL refers to the 
> *previous* base. [Note 
> > that there can be no previous at all, or the "previous" may 
> even be three 
> > months old]. 
> > 
> > The last point highlights the most noticeable difference. 
> Other differences 
> > appears when considering the guaranty to get the freshest 
> information : 
> > using the traditional scheme and the thisUpdate and 
> nextUpdate fields the 
> > guaranty to get the freshest information is obtained, but 
> cannot be obtained 
> > using the other scheme. :-( 
> > 
> > Several people are referring to the X.509 document for 
> arguments to support 
> > that discussion. However, it is important to remember that 
> we are defining 
> > PKIX, not X.509, so we DO NOT need to copy and paste 
> everything from X.509, 
> > but only what we believe is relevant. 
> > 
> > We first need to clearly define the processing rules 
> applicable to the 
> > relying parties. These rules will certainly contain 
> SHALL/MUST statements, 
> > but may also include some MAY statements which may even be 
> conditional to 
> > what the CA is doing. (I let Tim/David or Russ provide the 
> MAY statement). 
> > 
> > Here is a proposal for the MUST statement, based on the 
> previous text I 
> > produced: 
> > 
> >    An application that is wishing to take advantage of delta CRLs 
> >    for a given scope, MUST first find a base CRL for that scope, 
> >    i.e. a full CRL that that contains a freshestCRL extension 
> >    (a.k.a. a Delta CRL distribution point). It may then construct 
> >    an updated CRL for that base, for a specific time T, by combining 
> >    it with a delta CRL which contains a delta CRL indicator 
> extension 
> >    with the same CRL number as the base CRL. Applications 
> that support 
> >    delta CRLs MUST ensure that time T falls between thisUpdate and 
> >    nextUpdate for both the base CRL and the delta CRL. 
> > 
> >    Note: An application could also reconstruct an updated CRL, for 
> >    a specific time T, by using a previously locally 
> reconstructed CRL 
> >    based on the current base CRL, and combining it with a 
> delta CRL which 
> >    contains a delta CRL indicator extension with the same 
> CRL number as 
> >    the base CRL. 
> > 
> > We also need to clearly separate the issuing rules 
> applicable for the CAs. 
> > These rules will certainly contain SHALL statements, but 
> could also include 
> > some MAY statements. (I let Tim/David or Russ provide the 
> MAY statement). 
> > 
> > Here is a proposal for the MUST statement, based on the 
> previous text I 
> > produced: 
> > 
> >    A CA that supports delta-CRLs, MUST issue a base CRL, i.e. a full 
> >    CRL that contains a freshestCRL extension (a.k.a. a Delta CRL 
> >    distribution point). For any time T until the nextUpdate time 
> >    indicated in a base CRL, the CA MUST provide one and only one 
> >    delta CRL that refers to that base CRL and for which time T 
> >    falls between thisUpdate and nextUpdate from the delta CRL. 
> > 
> > In his e-mail from Wednesday, May 9, David said that 
> delta-CRL processing 
> > rules could be base on time instead of CRL numbers. This is 
> a point of which 
> > I strongly agree. Let us do it! 
> > 
> > (However, there is no need to add to PKIX, as he suggested, 
> the support of 
> > the baseUpdateTime extension from X.509 which would even 
> more complicate the 
> > problem.) 
> > 
> > Regards, 
> > 
> > Denis 
> 


------_=_NextPart_001_01C0D973.34078B70
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: delta CRLs</TITLE>

<META content="MSHTML 5.00.2014.210" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=981451217-10052001>I 
agree with Sharon.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=981451217-10052001></SPAN></FONT>&nbsp;</DIV>
<DIV class=OutlookMessageHeader><FONT face="Times New Roman" 
size=2>-----Original Message-----<BR><B>From:</B> Sharon Boeyen 
[mailto:[e-mail]]<BR><B>Sent:</B> Thursday, May 10, 2001 1:04 
PM<BR><B>To:</B> 'Denis Pinkas'; Carlin Covey; Sharon Boeyen<BR><B>Cc:</B> 
[e-mail]<BR><B>Subject:</B> RE: delta CRLs<BR><BR></FONT></DIV>
<P><FONT size=2>A full CRL is a CRL that is complete for a given scope. A base 
CRL is a CRL</FONT> <BR><FONT size=2>that is the foundation for a delta CRL. I 
think the reason the wording in </FONT><BR><FONT size=2>the definitions doesn't 
tie them together any more than that is because of </FONT><BR><FONT size=2>a 
nuance where a delta CRL may reference a base CRL that was never actually 
</FONT><BR><FONT size=2>issued as a full CRL. This is the case where the delta 
provides updates </FONT><BR><FONT size=2>from a certain point in time, but it 
may be the case, in some environments, </FONT><BR><FONT size=2>that full CRLs 
are never issued and the relying parties always build their </FONT><BR><FONT 
size=2>local full CRLs from deltas. I realize that is not the case PKIX 
describes, </FONT><BR><FONT size=2>but that's at least one reason the 509 
definitions are the way they are (and</FONT> <BR><FONT size=2>yes there are 
definitions in clause 3 for both base CRL and full CRL).</FONT> <BR><FONT 
size=2>So, the term base is only relevant when used in the context of a delta 
that</FONT> <BR><FONT size=2>points to it. </FONT></P>
<P><FONT size=2>As for freshestRevocationInfo, that is not mandated by 509, in 
the same </FONT><BR><FONT size=2>way that other extensions are not. It is one 
way to indicate where to </FONT><BR><FONT size=2>go to find deltas but there can 
be others (e.g. perhaps the relying </FONT><BR><FONT size=2>parties know that 
there is one indirect CRL that provides delta info</FONT> <BR><FONT size=2>for 
all CAs inside an organization - perhaps this info is listed on </FONT><BR><FONT 
size=2>their web site). If PKIX wanted to mandate it they could, but 509 
</FONT><BR><FONT size=2>certainly does not.</FONT> </P>
<P><FONT size=2>Cheers,</FONT> <BR><FONT size=2>Sharon</FONT> </P>
<P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
From: Denis Pinkas [<A 
href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
<BR><FONT size=2>&gt; Sent: Thursday, May 10, 2001 12:30 PM</FONT> <BR><FONT 
size=2>&gt; To: Carlin Covey; Sharon Boeyen</FONT> <BR><FONT size=2>&gt; Cc: 
[e-mail]</FONT> <BR><FONT size=2>&gt; Subject: Re: delta CRLs</FONT> 
<BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
Carlin and Sharon (at the same time),</FONT> <BR><FONT size=2>&gt; 
</FONT><BR><FONT size=2>&gt; &gt; Denis,</FONT> <BR><FONT size=2>&gt;&nbsp; 
</FONT><BR><FONT size=2>&gt; &gt; Now I'm confused again (or still).&nbsp; 
</FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; :-)</FONT> <BR><FONT 
size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt; I agree that there is a 
difference</FONT> <BR><FONT size=2>&gt; &gt; between a base CRL and a full 
CRL.&nbsp; However, my </FONT><BR><FONT size=2>&gt; understanding was that a 
CRL</FONT> <BR><FONT size=2>&gt; &gt; is a "base CRL" with respect to some delta 
CRL only by </FONT><BR><FONT size=2>&gt; virtue of having been</FONT> <BR><FONT 
size=2>&gt; &gt; so identified in that delta CRL. </FONT><BR><FONT size=2>&gt; 
</FONT><BR><FONT size=2>&gt; I believe that a base CRL must include the Freshest 
CRL </FONT><BR><FONT size=2>&gt; extension (a.k.a.</FONT> <BR><FONT size=2>&gt; 
Delta CRL Distribution Point) defined in section 4.2.1.16. It </FONT><BR><FONT 
size=2>&gt; indicates both</FONT> <BR><FONT size=2>&gt; that the service exists 
and where to fetch the information. It is a</FONT> <BR><FONT size=2>&gt; 
non-critical extension so that a base CRL may also be used as </FONT><BR><FONT 
size=2>&gt; a full CL for</FONT> <BR><FONT size=2>&gt; relying parties not 
supporting delta CRLs.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
&gt; According to the PKIX profile, this base CRL must be a full CRL 
</FONT><BR><FONT size=2>&gt; &gt; (complete for the intended scope).&nbsp; 
</FONT><BR><FONT size=2>&gt; &gt; I believe that X.509 does not require that a 
base CRL be a full CRL.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
size=2>&gt; You just say above: "According to the PKIX profile, this base 
</FONT><BR><FONT size=2>&gt; CRL must be a</FONT> <BR><FONT size=2>&gt; full CRL 
(complete for the intended scope". So do you mean </FONT><BR><FONT size=2>&gt; 
that X.509 and</FONT> <BR><FONT size=2>&gt; PKIX are taking different approaches 
?</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Regards,</FONT> 
<BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Denis</FONT> <BR><FONT 
size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt; Regards,</FONT> <BR><FONT 
size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; Carlin</FONT> <BR><FONT 
size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
____________________________</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT 
size=2>&gt; &gt; -&nbsp; Carlin Covey</FONT> <BR><FONT size=2>&gt; 
&gt;&nbsp;&nbsp;&nbsp; Cylink Corporation</FONT> <BR><FONT size=2>&gt; &gt; 
</FONT><BR><FONT size=2>&gt; &gt; -----Original Message-----</FONT> <BR><FONT 
size=2>&gt; &gt; From: Denis Pinkas [<A 
href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
<BR><FONT size=2>&gt; &gt; Sent: Thursday, May 10, 2001 1:19 AM</FONT> <BR><FONT 
size=2>&gt; &gt; Cc: [e-mail]</FONT> <BR><FONT size=2>&gt; &gt; 
Subject: Re: delta CRLs</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT 
size=2>&gt; &gt; Tim, David, Russ, Santosh, Carlin, and many others ...</FONT> 
<BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; There is difference 
between a base CRL and a full CRL : a </FONT><BR><FONT size=2>&gt; base CRL 
MUST</FONT> <BR><FONT size=2>&gt; &gt; include a freshestCRL extension (a.k.a. a 
Delta CRL </FONT><BR><FONT size=2>&gt; distribution point),</FONT> <BR><FONT 
size=2>&gt; &gt; whereas a full CRL may not include that extension. In other 
</FONT><BR><FONT size=2>&gt; words, a base</FONT> <BR><FONT size=2>&gt; &gt; CRL 
is a also a full CRL, but a full CRL is not necessarily </FONT><BR><FONT 
size=2>&gt; a base CRL.</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT 
size=2>&gt; &gt; At any time a CA may issue a full CRL, whether or not a 
</FONT><BR><FONT size=2>&gt; base CRL has already</FONT> <BR><FONT size=2>&gt; 
&gt; been issued. This additional CRL SHOULD have nextUpdate equal to the</FONT> 
<BR><FONT size=2>&gt; &gt; nextUpdate of the last issued full CRL. However, 
there is </FONT><BR><FONT size=2>&gt; no guarantee that</FONT> <BR><FONT 
size=2>&gt; &gt; this additional CRL will ever be seen by the relying party 
</FONT><BR><FONT size=2>&gt; (because there</FONT> <BR><FONT size=2>&gt; &gt; 
will be two CRLs matching the thisUpdate and nextUpdate </FONT><BR><FONT 
size=2>&gt; rule and if one is</FONT> <BR><FONT size=2>&gt; &gt; deleted, this 
is not seen by a relying party).</FONT> <BR><FONT size=2>&gt; &gt; 
</FONT><BR><FONT size=2>&gt; &gt; Due to the fact that CRLs numbers are strictly 
increasing, </FONT><BR><FONT size=2>&gt; two CRLs whether</FONT> <BR><FONT 
size=2>&gt; &gt; they are a base CRL or delta CRL, CANNOT have the same CRL 
</FONT><BR><FONT size=2>&gt; number. So a</FONT> <BR><FONT size=2>&gt; &gt; 
delta CRL and a full CRL that cover the same scope and are </FONT><BR><FONT 
size=2>&gt; issued at the</FONT> <BR><FONT size=2>&gt; &gt; same time CANNOT 
have the same number. If a full CRL is </FONT><BR><FONT size=2>&gt; issued, its 
CRL</FONT> <BR><FONT size=2>&gt; &gt; number bears no relationship with the 
previous base CRL, if </FONT><BR><FONT size=2>&gt; any. The only</FONT> 
<BR><FONT size=2>&gt; &gt; relationship between the numbers is defined by the 
rule </FONT><BR><FONT size=2>&gt; that CRLs numbers</FONT> <BR><FONT size=2>&gt; 
&gt; are strictly increasing. As Santosh said : "the CRL number is unique</FONT> 
<BR><FONT size=2>&gt; &gt; whether it is a base or a delta ".</FONT> <BR><FONT 
size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; This is fairly important to 
be able to unambiguously (and </FONT><BR><FONT size=2>&gt; thus uniquely)</FONT> 
<BR><FONT size=2>&gt; &gt; refer to a CRL by only providing its CRL 
number.</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
Besides the fact that a CRL issued later MUST have a higher </FONT><BR><FONT 
size=2>&gt; CRL number, full</FONT> <BR><FONT size=2>&gt; &gt; CRLs and delta 
CRLs have independent numbering rules. As </FONT><BR><FONT size=2>&gt; noticed 
by Santosh,</FONT> <BR><FONT size=2>&gt; &gt; " if the delta thisUpdate &gt; 
base thisUpdate, delta CRL </FONT><BR><FONT size=2>&gt; number &gt; base 
CRL</FONT> <BR><FONT size=2>&gt; &gt; number (for the same or no stream 
identifier).</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
As Santosh said : "a check based on thisUpdate is more general and</FONT> 
<BR><FONT size=2>&gt; &gt; preferred [to the use of CRL numbers]. "</FONT> 
<BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; Related to the 
three rules mentioned by Russ :</FONT> <BR><FONT size=2>&gt; &gt; 
</FONT><BR><FONT size=2>&gt; &gt; 1) the first rule is not understandable to 
me.</FONT> <BR><FONT size=2>&gt; &gt; 2) the second rule does not say anything 
more than the </FONT><BR><FONT size=2>&gt; basic rule valid</FONT> <BR><FONT 
size=2>&gt; &gt;&nbsp;&nbsp;&nbsp; for any CRL (i.e. a CRL issued later MUST 
have a higher </FONT><BR><FONT size=2>&gt; CRL number).</FONT> <BR><FONT 
size=2>&gt; &gt; 3) we will debate the hold condition, once we will have 
</FONT><BR><FONT size=2>&gt; sorted the main</FONT> <BR><FONT size=2>&gt; 
&gt;&nbsp;&nbsp;&nbsp; issue.</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT 
size=2>&gt; &gt; Russ said : "If separate number sequence is used, then you 
</FONT><BR><FONT size=2>&gt; will have to</FONT> <BR><FONT size=2>&gt; &gt; 
periodically fetch base CRLs ". This is true.</FONT> <BR><FONT size=2>&gt; &gt; 
</FONT><BR><FONT size=2>&gt; &gt; Tim said that he would *not* like to be forced 
to download </FONT><BR><FONT size=2>&gt; new base CRLs.</FONT> <BR><FONT 
size=2>&gt; &gt; This is the core of the "dispute".</FONT> <BR><FONT size=2>&gt; 
&gt; </FONT><BR><FONT size=2>&gt; &gt; &gt;From the definition of what a delta 
CRL is, it is *not* possible to</FONT> <BR><FONT size=2>&gt; &gt; get rid of the 
fetching of base CRLs. Unless we add a new </FONT><BR><FONT size=2>&gt; sentence 
to</FONT> <BR><FONT size=2>&gt; &gt; expand/change that definition, base CRL 
fetching will </FONT><BR><FONT size=2>&gt; remain mandatory.</FONT> <BR><FONT 
size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; Remember that the goal of 
delta CRLs is to provide the </FONT><BR><FONT size=2>&gt; freshest 
information,</FONT> <BR><FONT size=2>&gt; &gt; and to my knowledge the goal was 
not to get rid of the </FONT><BR><FONT size=2>&gt; fetching of base CRLs</FONT> 
<BR><FONT size=2>&gt; &gt; (which may less frequent due to the support of delta 
CRLs).</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; If I 
understand correctly, Tim/David/Russ would like to </FONT><BR><FONT size=2>&gt; 
*always* achieve the</FONT> <BR><FONT size=2>&gt; &gt; following property : it 
is possible to reconstruct the </FONT><BR><FONT size=2>&gt; current CRL by 
using</FONT> <BR><FONT size=2>&gt; &gt; a base CRL from, e.g. 1990, i.e. by 
capturing every delta </FONT><BR><FONT size=2>&gt; CRL that has been</FONT> 
<BR><FONT size=2>&gt; &gt; issued at the same time a base CRL was issued and 
which </FONT><BR><FONT size=2>&gt; contains updates</FONT> <BR><FONT size=2>&gt; 
&gt; made to the *previous* base.</FONT> <BR><FONT size=2>&gt; &gt; 
</FONT><BR><FONT size=2>&gt; &gt; By this way the fetching of base CRLs could be 
avoided. </FONT><BR><FONT size=2>&gt; However, note that</FONT> <BR><FONT 
size=2>&gt; &gt; it is perfectly " legal " to stop issuing base and delta 
</FONT><BR><FONT size=2>&gt; CRLs during some</FONT> <BR><FONT size=2>&gt; &gt; 
period of time and to issue full CRLs instead (see the </FONT><BR><FONT 
size=2>&gt; difference between</FONT> <BR><FONT size=2>&gt; &gt; "full" and 
"base" at the top of this e-mail). In other </FONT><BR><FONT size=2>&gt; words 
there is no</FONT> <BR><FONT size=2>&gt; &gt; need to issue a new base CRL at 
the end of the validity </FONT><BR><FONT size=2>&gt; period of the</FONT> 
<BR><FONT size=2>&gt; &gt; previous base CRL. Doing this would mandate to 
prescribe </FONT><BR><FONT size=2>&gt; issuing rules</FONT> <BR><FONT 
size=2>&gt; &gt; for CAs that we have not prescripted.</FONT> <BR><FONT 
size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; I will now raise a series of 
questions, for which I believe we have</FONT> <BR><FONT size=2>&gt; &gt; 
different answers. Tim/David/Russ do not hesitate to correct</FONT> <BR><FONT 
size=2>&gt; &gt; if my guess is wrong. ;-)</FONT> <BR><FONT size=2>&gt; &gt; 
</FONT><BR><FONT size=2>&gt; &gt; Common point:</FONT> <BR><FONT size=2>&gt; 
&gt; </FONT><BR><FONT size=2>&gt; &gt; 1) What will be the value of the 
nextUpdate field from the </FONT><BR><FONT size=2>&gt; last issued delta</FONT> 
<BR><FONT size=2>&gt; &gt; CRL for a given base CRL ?</FONT> <BR><FONT 
size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; Denis: the nextUpdate field 
from the last issued delta CRL </FONT><BR><FONT size=2>&gt; MUST be equal 
to</FONT> <BR><FONT size=2>&gt; &gt; the value of nextUpdate from the base 
CRL.</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
Tim/David/Russ: ???</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT 
size=2>&gt; &gt; 2) Does a CA needs to issue a delta CRL at the time a full 
</FONT><BR><FONT size=2>&gt; CRL is issued ?</FONT> <BR><FONT size=2>&gt; &gt; 
</FONT><BR><FONT size=2>&gt; &gt; Denis: No.</FONT> <BR><FONT size=2>&gt; &gt; 
Tim/David/Russ : ???</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT 
size=2>&gt; &gt; 3) Does a CA needs to issue a new base CRL at the end of 
</FONT><BR><FONT size=2>&gt; the validity of a</FONT> <BR><FONT size=2>&gt; &gt; 
current base CRL ?</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT 
size=2>&gt; &gt; Denis: No.</FONT> <BR><FONT size=2>&gt; &gt; Tim/David/Russ : 
???</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 4) Does 
a CA needs to issue a delta CRL at the same time a </FONT><BR><FONT size=2>&gt; 
new base is</FONT> <BR><FONT size=2>&gt; &gt; issued ?</FONT> <BR><FONT 
size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; Denis: Yes. The delta CRL 
refers to the *new* base.</FONT> <BR><FONT size=2>&gt; &gt; Tim/David/Russ : 
Yes. The delta CRL refers to the </FONT><BR><FONT size=2>&gt; *previous* base. 
[Note</FONT> <BR><FONT size=2>&gt; &gt; that there can be no previous at all, or 
the "previous" may </FONT><BR><FONT size=2>&gt; even be three</FONT> <BR><FONT 
size=2>&gt; &gt; months old].</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT 
size=2>&gt; &gt; The last point highlights the most noticeable difference. 
</FONT><BR><FONT size=2>&gt; Other differences</FONT> <BR><FONT size=2>&gt; &gt; 
appears when considering the guaranty to get the freshest </FONT><BR><FONT 
size=2>&gt; information :</FONT> <BR><FONT size=2>&gt; &gt; using the 
traditional scheme and the thisUpdate and </FONT><BR><FONT size=2>&gt; 
nextUpdate fields the</FONT> <BR><FONT size=2>&gt; &gt; guaranty to get the 
freshest information is obtained, but </FONT><BR><FONT size=2>&gt; cannot be 
obtained</FONT> <BR><FONT size=2>&gt; &gt; using the other scheme. :-(</FONT> 
<BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; Several people are 
referring to the X.509 document for </FONT><BR><FONT size=2>&gt; arguments to 
support</FONT> <BR><FONT size=2>&gt; &gt; that discussion. However, it is 
important to remember that </FONT><BR><FONT size=2>&gt; we are defining</FONT> 
<BR><FONT size=2>&gt; &gt; PKIX, not X.509, so we DO NOT need to copy and paste 
</FONT><BR><FONT size=2>&gt; everything from X.509,</FONT> <BR><FONT size=2>&gt; 
&gt; but only what we believe is relevant.</FONT> <BR><FONT size=2>&gt; &gt; 
</FONT><BR><FONT size=2>&gt; &gt; We first need to clearly define the processing 
rules </FONT><BR><FONT size=2>&gt; applicable to the</FONT> <BR><FONT 
size=2>&gt; &gt; relying parties. These rules will certainly contain 
</FONT><BR><FONT size=2>&gt; SHALL/MUST statements,</FONT> <BR><FONT size=2>&gt; 
&gt; but may also include some MAY statements which may even be </FONT><BR><FONT 
size=2>&gt; conditional to</FONT> <BR><FONT size=2>&gt; &gt; what the CA is 
doing. (I let Tim/David or Russ provide the </FONT><BR><FONT size=2>&gt; MAY 
statement).</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
Here is a proposal for the MUST statement, based on the </FONT><BR><FONT 
size=2>&gt; previous text I</FONT> <BR><FONT size=2>&gt; &gt; produced:</FONT> 
<BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt;&nbsp;&nbsp;&nbsp; 
An application that is wishing to take advantage of delta CRLs</FONT> <BR><FONT 
size=2>&gt; &gt;&nbsp;&nbsp;&nbsp; for a given scope, MUST first find a base CRL 
for that scope,</FONT> <BR><FONT size=2>&gt; &gt;&nbsp;&nbsp;&nbsp; i.e. a full 
CRL that that contains a freshestCRL extension</FONT> <BR><FONT size=2>&gt; 
&gt;&nbsp;&nbsp;&nbsp; (a.k.a. a Delta CRL distribution point). It may then 
construct</FONT> <BR><FONT size=2>&gt; &gt;&nbsp;&nbsp;&nbsp; an updated CRL for 
that base, for a specific time T, by combining</FONT> <BR><FONT size=2>&gt; 
&gt;&nbsp;&nbsp;&nbsp; it with a delta CRL which contains a delta CRL indicator 
</FONT><BR><FONT size=2>&gt; extension</FONT> <BR><FONT size=2>&gt; 
&gt;&nbsp;&nbsp;&nbsp; with the same CRL number as the base CRL. Applications 
</FONT><BR><FONT size=2>&gt; that support</FONT> <BR><FONT size=2>&gt; 
&gt;&nbsp;&nbsp;&nbsp; delta CRLs MUST ensure that time T falls between 
thisUpdate and</FONT> <BR><FONT size=2>&gt; &gt;&nbsp;&nbsp;&nbsp; nextUpdate 
for both the base CRL and the delta CRL.</FONT> <BR><FONT size=2>&gt; &gt; 
</FONT><BR><FONT size=2>&gt; &gt;&nbsp;&nbsp;&nbsp; Note: An application could 
also reconstruct an updated CRL, for</FONT> <BR><FONT size=2>&gt; 
&gt;&nbsp;&nbsp;&nbsp; a specific time T, by using a previously locally 
</FONT><BR><FONT size=2>&gt; reconstructed CRL</FONT> <BR><FONT size=2>&gt; 
&gt;&nbsp;&nbsp;&nbsp; based on the current base CRL, and combining it with a 
</FONT><BR><FONT size=2>&gt; delta CRL which</FONT> <BR><FONT size=2>&gt; 
&gt;&nbsp;&nbsp;&nbsp; contains a delta CRL indicator extension with the same 
</FONT><BR><FONT size=2>&gt; CRL number as</FONT> <BR><FONT size=2>&gt; 
&gt;&nbsp;&nbsp;&nbsp; the base CRL.</FONT> <BR><FONT size=2>&gt; &gt; 
</FONT><BR><FONT size=2>&gt; &gt; We also need to clearly separate the issuing 
rules </FONT><BR><FONT size=2>&gt; applicable for the CAs.</FONT> <BR><FONT 
size=2>&gt; &gt; These rules will certainly contain SHALL statements, but 
</FONT><BR><FONT size=2>&gt; could also include</FONT> <BR><FONT size=2>&gt; 
&gt; some MAY statements. (I let Tim/David or Russ provide the </FONT><BR><FONT 
size=2>&gt; MAY statement).</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT 
size=2>&gt; &gt; Here is a proposal for the MUST statement, based on the 
</FONT><BR><FONT size=2>&gt; previous text I</FONT> <BR><FONT size=2>&gt; &gt; 
produced:</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; 
&gt;&nbsp;&nbsp;&nbsp; A CA that supports delta-CRLs, MUST issue a base CRL, 
i.e. a full</FONT> <BR><FONT size=2>&gt; &gt;&nbsp;&nbsp;&nbsp; CRL that 
contains a freshestCRL extension (a.k.a. a Delta CRL</FONT> <BR><FONT 
size=2>&gt; &gt;&nbsp;&nbsp;&nbsp; distribution point). For any time T until the 
nextUpdate time</FONT> <BR><FONT size=2>&gt; &gt;&nbsp;&nbsp;&nbsp; indicated in 
a base CRL, the CA MUST provide one and only one</FONT> <BR><FONT size=2>&gt; 
&gt;&nbsp;&nbsp;&nbsp; delta CRL that refers to that base CRL and for which time 
T</FONT> <BR><FONT size=2>&gt; &gt;&nbsp;&nbsp;&nbsp; falls between thisUpdate 
and nextUpdate from the delta CRL.</FONT> <BR><FONT size=2>&gt; &gt; 
</FONT><BR><FONT size=2>&gt; &gt; In his e-mail from Wednesday, May 9, David 
said that </FONT><BR><FONT size=2>&gt; delta-CRL processing</FONT> <BR><FONT 
size=2>&gt; &gt; rules could be base on time instead of CRL numbers. This is 
</FONT><BR><FONT size=2>&gt; a point of which</FONT> <BR><FONT size=2>&gt; &gt; 
I strongly agree. Let us do it!</FONT> <BR><FONT size=2>&gt; &gt; 
</FONT><BR><FONT size=2>&gt; &gt; (However, there is no need to add to PKIX, as 
he suggested, </FONT><BR><FONT size=2>&gt; the support of</FONT> <BR><FONT 
size=2>&gt; &gt; the baseUpdateTime extension from X.509 which would even 
</FONT><BR><FONT size=2>&gt; more complicate the</FONT> <BR><FONT size=2>&gt; 
&gt; problem.)</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; 
&gt; Regards,</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; 
&gt; Denis</FONT> <BR><FONT size=2>&gt; </FONT></P></BODY></HTML>

------_=_NextPart_001_01C0D973.34078B70--


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA17518 for <[e-mail]>; Thu, 10 May 2001 10:13:00 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <K4X9NKQN>; Thu, 10 May 2001 13:12:32 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Denis Pinkas <[e-mail]>, Santosh Chokhani <[e-mail]>
Cc: Carlin Covey <[e-mail]>, Sharon Boeyen <[e-mail]>, [e-mail]
Subject: RE: delta CRLs
Date: Thu, 10 May 2001 13:03:17 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D973.1BA812C0"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D973.1BA812C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Denis:

See comments in-line.

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Thursday, May 10, 2001 12:53 PM
To: Santosh Chokhani
Cc: Carlin Covey; Sharon Boeyen; [e-mail]
Subject: Re: delta CRLs


Santosh,

Let me send you a reply just before leaving my office tonight.

> Denis:
>=20
> I do not agree with you.  Any CRL that is not a delta CRL (i.e.,
> deltaCRLIndicator extension is absent), is a base CRL for some scope =
as
> defined in CRLScope extension and/or the IDP extension.

I do not agree with you either. For a CRL to be a base CRL, there needs
first to be a delta CRL for it. In a closed environment, you could say =
that
this is sufficient because there is fixed point of contact to fetch =
delta
CRLs from and that this point is known using "out-of-bansds" means. We =
all
know what this means in terms of scalability. :-(

[Santosh Says:  The above is not relevant.  If I wanted to be rude I =
would
say that it is hogwash and mumbo jumbo.  The idea is very simple.  A =
CRL
that is not a delta, is a base.  You can take a delta and apply it to a =
base
and get the current information.  That base must be issued at the time =
or
later than the referenced base (meaning simply a CRL that is not a =
delta CRL
and has the referenced CRL number, nothing more, nothing less, assuming =
no
cRLStreamIdentifier per PKIX profile).  Further more this base must be
issued earlier than the delta.  Because, if the base was issued later =
than
the delta, you might as well use the base w/o delta.]

Until the CRL distribution point is used, noone knew where to fecth =
CRLs
from. The same will apply for delta CRLs. If we want to use delta CRLs =
in an
open environment, then we need the freshest CRL extension to be =
present.

[Santosh Says: Thanks this paragraph at least makes sense, albeit it is
wrong.  But it is not Kafkaism.  You can alternatively query the =
deltaCRL
attribute for the CA entry]

There are other side advantages:

1=B0 it allows to know when delta CRLs are supported, otherwise fetches =
in the
   repository would be done for nothing. So it saves time and/or =
increases
   performances.

[Santosh Says: I agree with you.  But, this a sound engineering =
decision and
can not be made a requirement]

2=B0 it allows to make sure that a delta scheme is supported and by =
using
   additional rules, it allows to make sure to get the freshest delta =
CRL.=20

[Santosh Says: You can simply query the deltaCRL attribute for =
freshest]

I hope this clarifies the point.

[Santosh Say: I hope you see that while freshestCRL being a desirable
extension, is not a requirement to implement delta CRL.]

Regards,

Denis
=20
=20
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Thursday, May 10, 2001 12:30 PM
> To: Carlin Covey; Sharon Boeyen
> Cc: [e-mail]
> Subject: Re: delta CRLs
>=20
> Carlin and Sharon (at the same time),
>=20
> > Denis,
>=20
> > Now I'm confused again (or still).
>=20
> :-)
>=20
> > I agree that there is a difference
> > between a base CRL and a full CRL.  However, my understanding was =
that a
> CRL
> > is a "base CRL" with respect to some delta CRL only by virtue of =
having
> been
> > so identified in that delta CRL.
>=20
> I believe that a base CRL must include the Freshest CRL extension =
(a.k.a.
> Delta CRL Distribution Point) defined in section 4.2.1.16. It =
indicates
> both
> that the service exists and where to fetch the information. It is a
> non-critical extension so that a base CRL may also be used as a full =
CL
> for
> relying parties not supporting delta CRLs.
>=20
> > According to the PKIX profile, this base CRL must be a full CRL
> > (complete for the intended scope).
> > I believe that X.509 does not require that a base CRL be a full =
CRL.
>=20
> You just say above: "According to the PKIX profile, this base CRL =
must be
> a
> full CRL (complete for the intended scope". So do you mean that X.509 =
and
> PKIX are taking different approaches ?
>=20
> Regards,
>=20
> Denis
>=20
> > Regards,
> >
> > Carlin
> >
> > ____________________________
> >
> > -  Carlin Covey
> >    Cylink Corporation
> >
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Thursday, May 10, 2001 1:19 AM
> > Cc: [e-mail]
> > Subject: Re: delta CRLs
> >
> > Tim, David, Russ, Santosh, Carlin, and many others ...
> >
> > There is difference between a base CRL and a full CRL : a base CRL =
MUST
> > include a freshestCRL extension (a.k.a. a Delta CRL distribution =
point),
>=20
> > whereas a full CRL may not include that extension. In other words, =
a
> base
> > CRL is a also a full CRL, but a full CRL is not necessarily a base =
CRL.
> >
> > At any time a CA may issue a full CRL, whether or not a base CRL =
has
> already
> > been issued. This additional CRL SHOULD have nextUpdate equal to =
the
> > nextUpdate of the last issued full CRL. However, there is no =
guarantee
> that
> > this additional CRL will ever be seen by the relying party (because
> there
> > will be two CRLs matching the thisUpdate and nextUpdate rule and if =
one
> is
> > deleted, this is not seen by a relying party).
> >
> > Due to the fact that CRLs numbers are strictly increasing, two CRLs
> whether
> > they are a base CRL or delta CRL, CANNOT have the same CRL number. =
So a
> > delta CRL and a full CRL that cover the same scope and are issued =
at the
>=20
> > same time CANNOT have the same number. If a full CRL is issued, its =
CRL
> > number bears no relationship with the previous base CRL, if any. =
The
> only
> > relationship between the numbers is defined by the rule that CRLs
> numbers
> > are strictly increasing. As Santosh said : "the CRL number is =
unique
> > whether it is a base or a delta ".
> >
> > This is fairly important to be able to unambiguously (and thus =
uniquely)
>=20
> > refer to a CRL by only providing its CRL number.
> >
> > Besides the fact that a CRL issued later MUST have a higher CRL =
number,
> full
> > CRLs and delta CRLs have independent numbering rules. As noticed by
> Santosh,
> > " if the delta thisUpdate > base thisUpdate, delta CRL number > =
base CRL
>=20
> > number (for the same or no stream identifier).
> >
> > As Santosh said : "a check based on thisUpdate is more general and
> > preferred [to the use of CRL numbers]. "
> >
> > Related to the three rules mentioned by Russ :
> >
> > 1) the first rule is not understandable to me.
> > 2) the second rule does not say anything more than the basic rule =
valid
> >    for any CRL (i.e. a CRL issued later MUST have a higher CRL =
number).
> > 3) we will debate the hold condition, once we will have sorted the =
main
> >    issue.
> >
> > Russ said : "If separate number sequence is used, then you will =
have to
> > periodically fetch base CRLs ". This is true.
> >
> > Tim said that he would *not* like to be forced to download new base
> CRLs.
> > This is the core of the "dispute".
> >
> > >From the definition of what a delta CRL is, it is *not* possible =
to
> > get rid of the fetching of base CRLs. Unless we add a new sentence =
to
> > expand/change that definition, base CRL fetching will remain =
mandatory.
> >
> > Remember that the goal of delta CRLs is to provide the freshest
> information,
> > and to my knowledge the goal was not to get rid of the fetching of =
base
> CRLs
> > (which may less frequent due to the support of delta CRLs).
> >
> > If I understand correctly, Tim/David/Russ would like to *always* =
achieve
> the
> > following property : it is possible to reconstruct the current CRL =
by
> using
> > a base CRL from, e.g. 1990, i.e. by capturing every delta CRL that =
has
> been
> > issued at the same time a base CRL was issued and which contains =
updates
>=20
> > made to the *previous* base.
> >
> > By this way the fetching of base CRLs could be avoided. However, =
note
> that
> > it is perfectly " legal " to stop issuing base and delta CRLs =
during
> some
> > period of time and to issue full CRLs instead (see the difference
> between
> > "full" and "base" at the top of this e-mail). In other words there =
is no
>=20
> > need to issue a new base CRL at the end of the validity period of =
the
> > previous base CRL. Doing this would mandate to prescribe issuing =
rules
> > for CAs that we have not prescripted.
> >
> > I will now raise a series of questions, for which I believe we have
> > different answers. Tim/David/Russ do not hesitate to correct
> > if my guess is wrong. ;-)
> >
> > Common point:
> >
> > 1) What will be the value of the nextUpdate field from the last =
issued
> delta
> > CRL for a given base CRL ?
> >
> > Denis: the nextUpdate field from the last issued delta CRL MUST be =
equal
> to
> > the value of nextUpdate from the base CRL.
> >
> > Tim/David/Russ: ???
> >
> > 2) Does a CA needs to issue a delta CRL at the time a full CRL is =
issued
> ?
> >
> > Denis: No.
> > Tim/David/Russ : ???
> >
> > 3) Does a CA needs to issue a new base CRL at the end of the =
validity of
> a
> > current base CRL ?
> >
> > Denis: No.
> > Tim/David/Russ : ???
> >
> > 4) Does a CA needs to issue a delta CRL at the same time a new base =
is
> > issued ?
> >
> > Denis: Yes. The delta CRL refers to the *new* base.
> > Tim/David/Russ : Yes. The delta CRL refers to the *previous* base. =
[Note
>=20
> > that there can be no previous at all, or the "previous" may even be
> three
> > months old].
> >
> > The last point highlights the most noticeable difference. Other
> differences
> > appears when considering the guaranty to get the freshest =
information :
> > using the traditional scheme and the thisUpdate and nextUpdate =
fields
> the
> > guaranty to get the freshest information is obtained, but cannot be
> obtained
> > using the other scheme. :-(
> >
> > Several people are referring to the X.509 document for arguments to
> support
> > that discussion. However, it is important to remember that we are
> defining
> > PKIX, not X.509, so we DO NOT need to copy and paste everything =
from
> X.509,
> > but only what we believe is relevant.
> >
> > We first need to clearly define the processing rules applicable to =
the
> > relying parties. These rules will certainly contain SHALL/MUST
> statements,
> > but may also include some MAY statements which may even be =
conditional
> to
> > what the CA is doing. (I let Tim/David or Russ provide the MAY
> statement).
> >
> > Here is a proposal for the MUST statement, based on the previous =
text I
> > produced:
> >
> >    An application that is wishing to take advantage of delta CRLs
> >    for a given scope, MUST first find a base CRL for that scope,
> >    i.e. a full CRL that that contains a freshestCRL extension
> >    (a.k.a. a Delta CRL distribution point). It may then construct
> >    an updated CRL for that base, for a specific time T, by =
combining
> >    it with a delta CRL which contains a delta CRL indicator =
extension
> >    with the same CRL number as the base CRL. Applications that =
support
> >    delta CRLs MUST ensure that time T falls between thisUpdate and
> >    nextUpdate for both the base CRL and the delta CRL.
> >
> >    Note: An application could also reconstruct an updated CRL, for
> >    a specific time T, by using a previously locally reconstructed =
CRL
> >    based on the current base CRL, and combining it with a delta CRL
> which
> >    contains a delta CRL indicator extension with the same CRL =
number as
> >    the base CRL.
> >
> > We also need to clearly separate the issuing rules applicable for =
the
> CAs.
> > These rules will certainly contain SHALL statements, but could also
> include
> > some MAY statements. (I let Tim/David or Russ provide the MAY
> statement).
> >
> > Here is a proposal for the MUST statement, based on the previous =
text I
> > produced:
> >
> >    A CA that supports delta-CRLs, MUST issue a base CRL, i.e. a =
full
> >    CRL that contains a freshestCRL extension (a.k.a. a Delta CRL
> >    distribution point). For any time T until the nextUpdate time
> >    indicated in a base CRL, the CA MUST provide one and only one
> >    delta CRL that refers to that base CRL and for which time T
> >    falls between thisUpdate and nextUpdate from the delta CRL.
> >
> > In his e-mail from Wednesday, May 9, David said that delta-CRL
> processing
> > rules could be base on time instead of CRL numbers. This is a point =
of
> which
> > I strongly agree. Let us do it!
> >
> > (However, there is no need to add to PKIX, as he suggested, the =
support
> of
> > the baseUpdateTime extension from X.509 which would even more =
complicate
> the
> > problem.)
> >
> > Regards,
> >
> > Denis

------_=_NextPart_001_01C0D973.1BA812C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: delta CRLs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Denis:</FONT>
</P>

<P><FONT SIZE=3D2>See comments in-line.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Denis Pinkas [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, May 10, 2001 12:53 PM</FONT>
<BR><FONT SIZE=3D2>To: Santosh Chokhani</FONT>
<BR><FONT SIZE=3D2>Cc: Carlin Covey; Sharon Boeyen; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: delta CRLs</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Santosh,</FONT>
</P>

<P><FONT SIZE=3D2>Let me send you a reply just before leaving my office =
tonight.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Denis:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I do not agree with you.&nbsp; Any CRL that is =
not a delta CRL (i.e.,</FONT>
<BR><FONT SIZE=3D2>&gt; deltaCRLIndicator extension is absent), is a =
base CRL for some scope as</FONT>
<BR><FONT SIZE=3D2>&gt; defined in CRLScope extension and/or the IDP =
extension.</FONT>
</P>

<P><FONT SIZE=3D2>I do not agree with you either. For a CRL to be a =
base CRL, there needs</FONT>
<BR><FONT SIZE=3D2>first to be a delta CRL for it. In a closed =
environment, you could say that</FONT>
<BR><FONT SIZE=3D2>this is sufficient because there is fixed point of =
contact to fetch delta</FONT>
<BR><FONT SIZE=3D2>CRLs from and that this point is known using =
&quot;out-of-bansds&quot; means. We all</FONT>
<BR><FONT SIZE=3D2>know what this means in terms of scalability. =
:-(</FONT>
</P>

<P><FONT SIZE=3D2>[Santosh Says:&nbsp; The above is not relevant.&nbsp; =
If I wanted to be rude I would say that it is hogwash and mumbo =
jumbo.&nbsp; The idea is very simple.&nbsp; A CRL that is not a delta, =
is a base.&nbsp; You can take a delta and apply it to a base and get =
the current information.&nbsp; That base must be issued at the time or =
later than the referenced base (meaning simply a CRL that is not a =
delta CRL and has the referenced CRL number, nothing more, nothing =
less, assuming no cRLStreamIdentifier per PKIX profile).&nbsp; Further =
more this base must be issued earlier than the delta.&nbsp; Because, if =
the base was issued later than the delta, you might as well use the =
base w/o delta.]</FONT></P>

<P><FONT SIZE=3D2>Until the CRL distribution point is used, noone knew =
where to fecth CRLs</FONT>
<BR><FONT SIZE=3D2>from. The same will apply for delta CRLs. If we want =
to use delta CRLs in an</FONT>
<BR><FONT SIZE=3D2>open environment, then we need the freshest CRL =
extension to be present.</FONT>
</P>

<P><FONT SIZE=3D2>[Santosh Says: Thanks this paragraph at least makes =
sense, albeit it is wrong.&nbsp; But it is not Kafkaism.&nbsp; You can =
alternatively query the deltaCRL attribute for the CA entry]</FONT></P>

<P><FONT SIZE=3D2>There are other side advantages:</FONT>
</P>

<P><FONT SIZE=3D2>1=B0 it allows to know when delta CRLs are supported, =
otherwise fetches in the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; repository would be done for nothing. =
So it saves time and/or increases</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; performances.</FONT>
</P>

<P><FONT SIZE=3D2>[Santosh Says: I agree with you.&nbsp; But, this a =
sound engineering decision and can not be made a requirement]</FONT>
</P>

<P><FONT SIZE=3D2>2=B0 it allows to make sure that a delta scheme is =
supported and by using</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; additional rules, it allows to make =
sure to get the freshest delta CRL. </FONT>
</P>

<P><FONT SIZE=3D2>[Santosh Says: You can simply query the deltaCRL =
attribute for freshest]</FONT>
</P>

<P><FONT SIZE=3D2>I hope this clarifies the point.</FONT>
</P>

<P><FONT SIZE=3D2>[Santosh Say: I hope you see that while freshestCRL =
being a desirable extension, is not a requirement to implement delta =
CRL.]</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Denis</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Denis Pinkas [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, May 10, 2001 12:30 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Carlin Covey; Sharon Boeyen</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: delta CRLs</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Carlin and Sharon (at the same time),</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Denis,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Now I'm confused again (or still).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; :-)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I agree that there is a difference</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; between a base CRL and a full CRL.&nbsp; =
However, my understanding was that a</FONT>
<BR><FONT SIZE=3D2>&gt; CRL</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; is a &quot;base CRL&quot; with respect to =
some delta CRL only by virtue of having</FONT>
<BR><FONT SIZE=3D2>&gt; been</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; so identified in that delta CRL.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I believe that a base CRL must include the =
Freshest CRL extension (a.k.a.</FONT>
<BR><FONT SIZE=3D2>&gt; Delta CRL Distribution Point) defined in =
section 4.2.1.16. It indicates</FONT>
<BR><FONT SIZE=3D2>&gt; both</FONT>
<BR><FONT SIZE=3D2>&gt; that the service exists and where to fetch the =
information. It is a</FONT>
<BR><FONT SIZE=3D2>&gt; non-critical extension so that a base CRL may =
also be used as a full CL</FONT>
<BR><FONT SIZE=3D2>&gt; for</FONT>
<BR><FONT SIZE=3D2>&gt; relying parties not supporting delta =
CRLs.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; According to the PKIX profile, this base =
CRL must be a full CRL</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (complete for the intended scope).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I believe that X.509 does not require that =
a base CRL be a full CRL.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; You just say above: &quot;According to the PKIX =
profile, this base CRL must be</FONT>
<BR><FONT SIZE=3D2>&gt; a</FONT>
<BR><FONT SIZE=3D2>&gt; full CRL (complete for the intended =
scope&quot;. So do you mean that X.509 and</FONT>
<BR><FONT SIZE=3D2>&gt; PKIX are taking different approaches ?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Denis</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Carlin</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; ____________________________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -&nbsp; Carlin Covey</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; Cylink =
Corporation</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Denis Pinkas [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Thursday, May 10, 2001 1:19 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: Re: delta CRLs</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Tim, David, Russ, Santosh, Carlin, and =
many others ...</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; There is difference between a base CRL and =
a full CRL : a base CRL MUST</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; include a freshestCRL extension (a.k.a. a =
Delta CRL distribution point),</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; whereas a full CRL may not include that =
extension. In other words, a</FONT>
<BR><FONT SIZE=3D2>&gt; base</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; CRL is a also a full CRL, but a full CRL =
is not necessarily a base CRL.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; At any time a CA may issue a full CRL, =
whether or not a base CRL has</FONT>
<BR><FONT SIZE=3D2>&gt; already</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; been issued. This additional CRL SHOULD =
have nextUpdate equal to the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; nextUpdate of the last issued full CRL. =
However, there is no guarantee</FONT>
<BR><FONT SIZE=3D2>&gt; that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; this additional CRL will ever be seen by =
the relying party (because</FONT>
<BR><FONT SIZE=3D2>&gt; there</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; will be two CRLs matching the thisUpdate =
and nextUpdate rule and if one</FONT>
<BR><FONT SIZE=3D2>&gt; is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; deleted, this is not seen by a relying =
party).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Due to the fact that CRLs numbers are =
strictly increasing, two CRLs</FONT>
<BR><FONT SIZE=3D2>&gt; whether</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; they are a base CRL or delta CRL, CANNOT =
have the same CRL number. So a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; delta CRL and a full CRL that cover the =
same scope and are issued at the</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; same time CANNOT have the same number. If =
a full CRL is issued, its CRL</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; number bears no relationship with the =
previous base CRL, if any. The</FONT>
<BR><FONT SIZE=3D2>&gt; only</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; relationship between the numbers is =
defined by the rule that CRLs</FONT>
<BR><FONT SIZE=3D2>&gt; numbers</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; are strictly increasing. As Santosh said : =
&quot;the CRL number is unique</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; whether it is a base or a delta =
&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; This is fairly important to be able to =
unambiguously (and thus uniquely)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; refer to a CRL by only providing its CRL =
number.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Besides the fact that a CRL issued later =
MUST have a higher CRL number,</FONT>
<BR><FONT SIZE=3D2>&gt; full</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; CRLs and delta CRLs have independent =
numbering rules. As noticed by</FONT>
<BR><FONT SIZE=3D2>&gt; Santosh,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &quot; if the delta thisUpdate &gt; base =
thisUpdate, delta CRL number &gt; base CRL</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; number (for the same or no stream =
identifier).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; As Santosh said : &quot;a check based on =
thisUpdate is more general and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; preferred [to the use of CRL numbers]. =
&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Related to the three rules mentioned by =
Russ :</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 1) the first rule is not understandable to =
me.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 2) the second rule does not say anything =
more than the basic rule valid</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; for any CRL (i.e. a CRL =
issued later MUST have a higher CRL number).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 3) we will debate the hold condition, once =
we will have sorted the main</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; issue.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Russ said : &quot;If separate number =
sequence is used, then you will have to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; periodically fetch base CRLs &quot;. This =
is true.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Tim said that he would *not* like to be =
forced to download new base</FONT>
<BR><FONT SIZE=3D2>&gt; CRLs.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; This is the core of the =
&quot;dispute&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;From the definition of what a delta =
CRL is, it is *not* possible to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; get rid of the fetching of base CRLs. =
Unless we add a new sentence to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; expand/change that definition, base CRL =
fetching will remain mandatory.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Remember that the goal of delta CRLs is to =
provide the freshest</FONT>
<BR><FONT SIZE=3D2>&gt; information,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; and to my knowledge the goal was not to =
get rid of the fetching of base</FONT>
<BR><FONT SIZE=3D2>&gt; CRLs</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (which may less frequent due to the =
support of delta CRLs).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; If I understand correctly, Tim/David/Russ =
would like to *always* achieve</FONT>
<BR><FONT SIZE=3D2>&gt; the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; following property : it is possible to =
reconstruct the current CRL by</FONT>
<BR><FONT SIZE=3D2>&gt; using</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; a base CRL from, e.g. 1990, i.e. by =
capturing every delta CRL that has</FONT>
<BR><FONT SIZE=3D2>&gt; been</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; issued at the same time a base CRL was =
issued and which contains updates</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; made to the *previous* base.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; By this way the fetching of base CRLs =
could be avoided. However, note</FONT>
<BR><FONT SIZE=3D2>&gt; that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; it is perfectly &quot; legal &quot; to =
stop issuing base and delta CRLs during</FONT>
<BR><FONT SIZE=3D2>&gt; some</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; period of time and to issue full CRLs =
instead (see the difference</FONT>
<BR><FONT SIZE=3D2>&gt; between</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &quot;full&quot; and &quot;base&quot; at =
the top of this e-mail). In other words there is no</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; need to issue a new base CRL at the end of =
the validity period of the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; previous base CRL. Doing this would =
mandate to prescribe issuing rules</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; for CAs that we have not =
prescripted.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I will now raise a series of questions, =
for which I believe we have</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; different answers. Tim/David/Russ do not =
hesitate to correct</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; if my guess is wrong. ;-)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Common point:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 1) What will be the value of the =
nextUpdate field from the last issued</FONT>
<BR><FONT SIZE=3D2>&gt; delta</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; CRL for a given base CRL ?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Denis: the nextUpdate field from the last =
issued delta CRL MUST be equal</FONT>
<BR><FONT SIZE=3D2>&gt; to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the value of nextUpdate from the base =
CRL.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Tim/David/Russ: ???</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 2) Does a CA needs to issue a delta CRL at =
the time a full CRL is issued</FONT>
<BR><FONT SIZE=3D2>&gt; ?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Denis: No.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Tim/David/Russ : ???</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 3) Does a CA needs to issue a new base CRL =
at the end of the validity of</FONT>
<BR><FONT SIZE=3D2>&gt; a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; current base CRL ?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Denis: No.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Tim/David/Russ : ???</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 4) Does a CA needs to issue a delta CRL at =
the same time a new base is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; issued ?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Denis: Yes. The delta CRL refers to the =
*new* base.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Tim/David/Russ : Yes. The delta CRL refers =
to the *previous* base. [Note</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; that there can be no previous at all, or =
the &quot;previous&quot; may even be</FONT>
<BR><FONT SIZE=3D2>&gt; three</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; months old].</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; The last point highlights the most =
noticeable difference. Other</FONT>
<BR><FONT SIZE=3D2>&gt; differences</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; appears when considering the guaranty to =
get the freshest information :</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; using the traditional scheme and the =
thisUpdate and nextUpdate fields</FONT>
<BR><FONT SIZE=3D2>&gt; the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; guaranty to get the freshest information =
is obtained, but cannot be</FONT>
<BR><FONT SIZE=3D2>&gt; obtained</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; using the other scheme. :-(</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Several people are referring to the X.509 =
document for arguments to</FONT>
<BR><FONT SIZE=3D2>&gt; support</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; that discussion. However, it is important =
to remember that we are</FONT>
<BR><FONT SIZE=3D2>&gt; defining</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; PKIX, not X.509, so we DO NOT need to copy =
and paste everything from</FONT>
<BR><FONT SIZE=3D2>&gt; X.509,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; but only what we believe is =
relevant.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; We first need to clearly define the =
processing rules applicable to the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; relying parties. These rules will =
certainly contain SHALL/MUST</FONT>
<BR><FONT SIZE=3D2>&gt; statements,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; but may also include some MAY statements =
which may even be conditional</FONT>
<BR><FONT SIZE=3D2>&gt; to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; what the CA is doing. (I let Tim/David or =
Russ provide the MAY</FONT>
<BR><FONT SIZE=3D2>&gt; statement).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Here is a proposal for the MUST statement, =
based on the previous text I</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; produced:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; An application that is =
wishing to take advantage of delta CRLs</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; for a given scope, MUST =
first find a base CRL for that scope,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; i.e. a full CRL that =
that contains a freshestCRL extension</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; (a.k.a. a Delta CRL =
distribution point). It may then construct</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; an updated CRL for that =
base, for a specific time T, by combining</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; it with a delta CRL =
which contains a delta CRL indicator extension</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; with the same CRL number =
as the base CRL. Applications that support</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; delta CRLs MUST ensure =
that time T falls between thisUpdate and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; nextUpdate for both the =
base CRL and the delta CRL.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; Note: An application =
could also reconstruct an updated CRL, for</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; a specific time T, by =
using a previously locally reconstructed CRL</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; based on the current =
base CRL, and combining it with a delta CRL</FONT>
<BR><FONT SIZE=3D2>&gt; which</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; contains a delta CRL =
indicator extension with the same CRL number as</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; the base CRL.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; We also need to clearly separate the =
issuing rules applicable for the</FONT>
<BR><FONT SIZE=3D2>&gt; CAs.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; These rules will certainly contain SHALL =
statements, but could also</FONT>
<BR><FONT SIZE=3D2>&gt; include</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; some MAY statements. (I let Tim/David or =
Russ provide the MAY</FONT>
<BR><FONT SIZE=3D2>&gt; statement).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Here is a proposal for the MUST statement, =
based on the previous text I</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; produced:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; A CA that supports =
delta-CRLs, MUST issue a base CRL, i.e. a full</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; CRL that contains a =
freshestCRL extension (a.k.a. a Delta CRL</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; distribution point). For =
any time T until the nextUpdate time</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; indicated in a base CRL, =
the CA MUST provide one and only one</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; delta CRL that refers to =
that base CRL and for which time T</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; falls between thisUpdate =
and nextUpdate from the delta CRL.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; In his e-mail from Wednesday, May 9, David =
said that delta-CRL</FONT>
<BR><FONT SIZE=3D2>&gt; processing</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; rules could be base on time instead of CRL =
numbers. This is a point of</FONT>
<BR><FONT SIZE=3D2>&gt; which</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I strongly agree. Let us do it!</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (However, there is no need to add to PKIX, =
as he suggested, the support</FONT>
<BR><FONT SIZE=3D2>&gt; of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the baseUpdateTime extension from X.509 =
which would even more complicate</FONT>
<BR><FONT SIZE=3D2>&gt; the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; problem.)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Denis</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0D973.1BA812C0--


Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA16963 for <[e-mail]>; Thu, 10 May 2001 10:09:22 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f4AH8sJ15297; Thu, 10 May 2001 10:08:54 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Dr S N Henson" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Certificate Hold (was RE: delta CRLs)
Date: Thu, 10 May 2001 10:08:29 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <[e-mail]>

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:[e-mail]
w: http://www.traceroutesecurity.com



Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA16766 for <[e-mail]>; Thu, 10 May 2001 10:08:38 -0700 (PDT)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KVA79Z72; Thu, 10 May 2001 10:02:56 -0700
From: "Carlin Covey" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: delta CRLs
Date: Thu, 10 May 2001 10:07:56 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <[e-mail]>

Denis said: So do you mean that X.509 and PKIX are taking different
approaches ?

Carlin says:  Well, yes, they are taking different approaches in that PKIX
has defined a subset of certain X.509 features. As of a few weeks ago, we
added wording to the PKIX profile to mandate the deltaCRLIndicator extension
in delta CRLs.  Prior to that its usage was discussed in the profile, but
there was no text saying that this extension was the required way to
identify delta CRLs.  When the deltaCRLIndicator extension is used to
identify a CRL as a delta CRL, the base CRL must be a full CRL.  But X.509
also permits a delta CRL to be identified by a cRLScope extension, in which
case the base CRL could another delta CRL.  (Thanks, David Cooper, for
confirming my understanding.)

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Thursday, May 10, 2001 9:30 AM
To: Carlin Covey; Sharon Boeyen
Cc: [e-mail]
Subject: Re: delta CRLs


Carlin and Sharon (at the same time),

> Denis,

> Now I'm confused again (or still).

:-)

> I agree that there is a difference
> between a base CRL and a full CRL.  However, my understanding was that a
CRL
> is a "base CRL" with respect to some delta CRL only by virtue of having
been
> so identified in that delta CRL.

I believe that a base CRL must include the Freshest CRL extension (a.k.a.
Delta CRL Distribution Point) defined in section 4.2.1.16. It indicates both
that the service exists and where to fetch the information. It is a
non-critical extension so that a base CRL may also be used as a full CL for
relying parties not supporting delta CRLs.

> According to the PKIX profile, this base CRL must be a full CRL
> (complete for the intended scope).
> I believe that X.509 does not require that a base CRL be a full CRL.

You just say above: "According to the PKIX profile, this base CRL must be a
full CRL (complete for the intended scope". So do you mean that X.509 and
PKIX are taking different approaches ?

Regards,

Denis

> Regards,
>
> Carlin
>
> ____________________________
>
> -  Carlin Covey
>    Cylink Corporation
>
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Thursday, May 10, 2001 1:19 AM
> Cc: [e-mail]
> Subject: Re: delta CRLs
>
> Tim, David, Russ, Santosh, Carlin, and many others ...
>
> There is difference between a base CRL and a full CRL : a base CRL MUST
> include a freshestCRL extension (a.k.a. a Delta CRL distribution point),
> whereas a full CRL may not include that extension. In other words, a base
> CRL is a also a full CRL, but a full CRL is not necessarily a base CRL.
>
> At any time a CA may issue a full CRL, whether or not a base CRL has
already
> been issued. This additional CRL SHOULD have nextUpdate equal to the
> nextUpdate of the last issued full CRL. However, there is no guarantee
that
> this additional CRL will ever be seen by the relying party (because there
> will be two CRLs matching the thisUpdate and nextUpdate rule and if one is
> deleted, this is not seen by a relying party).
>
> Due to the fact that CRLs numbers are strictly increasing, two CRLs
whether
> they are a base CRL or delta CRL, CANNOT have the same CRL number. So a
> delta CRL and a full CRL that cover the same scope and are issued at the
> same time CANNOT have the same number. If a full CRL is issued, its CRL
> number bears no relationship with the previous base CRL, if any. The only
> relationship between the numbers is defined by the rule that CRLs numbers
> are strictly increasing. As Santosh said : "the CRL number is unique
> whether it is a base or a delta ".
>
> This is fairly important to be able to unambiguously (and thus uniquely)
> refer to a CRL by only providing its CRL number.
>
> Besides the fact that a CRL issued later MUST have a higher CRL number,
full
> CRLs and delta CRLs have independent numbering rules. As noticed by
Santosh,
> " if the delta thisUpdate > base thisUpdate, delta CRL number > base CRL
> number (for the same or no stream identifier).
>
> As Santosh said : "a check based on thisUpdate is more general and
> preferred [to the use of CRL numbers]. "
>
> Related to the three rules mentioned by Russ :
>
> 1) the first rule is not understandable to me.
> 2) the second rule does not say anything more than the basic rule valid
>    for any CRL (i.e. a CRL issued later MUST have a higher CRL number).
> 3) we will debate the hold condition, once we will have sorted the main
>    issue.
>
> Russ said : "If separate number sequence is used, then you will have to
> periodically fetch base CRLs ". This is true.
>
> Tim said that he would *not* like to be forced to download new base CRLs.
> This is the core of the "dispute".
>
> >From the definition of what a delta CRL is, it is *not* possible to
> get rid of the fetching of base CRLs. Unless we add a new sentence to
> expand/change that definition, base CRL fetching will remain mandatory.
>
> Remember that the goal of delta CRLs is to provide the freshest
information,
> and to my knowledge the goal was not to get rid of the fetching of base
CRLs
> (which may less frequent due to the support of delta CRLs).
>
> If I understand correctly, Tim/David/Russ would like to *always* achieve
the
> following property : it is possible to reconstruct the current CRL by
using
> a base CRL from, e.g. 1990, i.e. by capturing every delta CRL that has
been
> issued at the same time a base CRL was issued and which contains updates
> made to the *previous* base.
>
> By this way the fetching of base CRLs could be avoided. However, note that
> it is perfectly " legal " to stop issuing base and delta CRLs during some
> period of time and to issue full CRLs instead (see the difference between
> "full" and "base" at the top of this e-mail). In other words there is no
> need to issue a new base CRL at the end of the validity period of the
> previous base CRL. Doing this would mandate to prescribe issuing rules
> for CAs that we have not prescripted.
>
> I will now raise a series of questions, for which I believe we have
> different answers. Tim/David/Russ do not hesitate to correct
> if my guess is wrong. ;-)
>
> Common point:
>
> 1) What will be the value of the nextUpdate field from the last issued
delta
> CRL for a given base CRL ?
>
> Denis: the nextUpdate field from the last issued delta CRL MUST be equal
to
> the value of nextUpdate from the base CRL.
>
> Tim/David/Russ: ???
>
> 2) Does a CA needs to issue a delta CRL at the time a full CRL is issued ?
>
> Denis: No.
> Tim/David/Russ : ???
>
> 3) Does a CA needs to issue a new base CRL at the end of the validity of a
> current base CRL ?
>
> Denis: No.
> Tim/David/Russ : ???
>
> 4) Does a CA needs to issue a delta CRL at the same time a new base is
> issued ?
>
> Denis: Yes. The delta CRL refers to the *new* base.
> Tim/David/Russ : Yes. The delta CRL refers to the *previous* base. [Note
> that there can be no previous at all, or the "previous" may even be three
> months old].
>
> The last point highlights the most noticeable difference. Other
differences
> appears when considering the guaranty to get the freshest information :
> using the traditional scheme and the thisUpdate and nextUpdate fields the
> guaranty to get the freshest information is obtained, but cannot be
obtained
> using the other scheme. :-(
>
> Several people are referring to the X.509 document for arguments to
support
> that discussion. However, it is important to remember that we are defining
> PKIX, not X.509, so we DO NOT need to copy and paste everything from
X.509,
> but only what we believe is relevant.
>
> We first need to clearly define the processing rules applicable to the
> relying parties. These rules will certainly contain SHALL/MUST statements,
> but may also include some MAY statements which may even be conditional to
> what the CA is doing. (I let Tim/David or Russ provide the MAY statement).
>
> Here is a proposal for the MUST statement, based on the previous text I
> produced:
>
>    An application that is wishing to take advantage of delta CRLs
>    for a given scope, MUST first find a base CRL for that scope,
>    i.e. a full CRL that that contains a freshestCRL extension
>    (a.k.a. a Delta CRL distribution point). It may then construct
>    an updated CRL for that base, for a specific time T, by combining
>    it with a delta CRL which contains a delta CRL indicator extension
>    with the same CRL number as the base CRL. Applications that support
>    delta CRLs MUST ensure that time T falls between thisUpdate and
>    nextUpdate for both the base CRL and the delta CRL.
>
>    Note: An application could also reconstruct an updated CRL, for
>    a specific time T, by using a previously locally reconstructed CRL
>    based on the current base CRL, and combining it with a delta CRL which
>    contains a delta CRL indicator extension with the same CRL number as
>    the base CRL.
>
> We also need to clearly separate the issuing rules applicable for the CAs.
> These rules will certainly contain SHALL statements, but could also
include
> some MAY statements. (I let Tim/David or Russ provide the MAY statement).
>
> Here is a proposal for the MUST statement, based on the previous text I
> produced:
>
>    A CA that supports delta-CRLs, MUST issue a base CRL, i.e. a full
>    CRL that contains a freshestCRL extension (a.k.a. a Delta CRL
>    distribution point). For any time T until the nextUpdate time
>    indicated in a base CRL, the CA MUST provide one and only one
>    delta CRL that refers to that base CRL and for which time T
>    falls between thisUpdate and nextUpdate from the delta CRL.
>
> In his e-mail from Wednesday, May 9, David said that delta-CRL processing
> rules could be base on time instead of CRL numbers. This is a point of
which
> I strongly agree. Let us do it!
>
> (However, there is no need to add to PKIX, as he suggested, the support of
> the baseUpdateTime extension from X.509 which would even more complicate
the
> problem.)
>
> Regards,
>
> Denis



Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA16326 for <[e-mail]>; Thu, 10 May 2001 10:04:50 -0700 (PDT)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <J432YV3G>; Thu, 10 May 2001 13:04:21 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, Carlin Covey <[e-mail]>, Sharon Boeyen <[e-mail]>
Cc: [e-mail]
Subject: RE: delta CRLs
Date: Thu, 10 May 2001 13:04:19 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D973.40CFCAC0"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D973.40CFCAC0
Content-Type: text/plain

A full CRL is a CRL that is complete for a given scope. A base CRL is a CRL
that is the foundation for a delta CRL. I think the reason the wording in 
the definitions doesn't tie them together any more than that is because of 
a nuance where a delta CRL may reference a base CRL that was never actually 
issued as a full CRL. This is the case where the delta provides updates 
from a certain point in time, but it may be the case, in some environments, 
that full CRLs are never issued and the relying parties always build their 
local full CRLs from deltas. I realize that is not the case PKIX describes, 
but that's at least one reason the 509 definitions are the way they are (and
yes there are definitions in clause 3 for both base CRL and full CRL).
So, the term base is only relevant when used in the context of a delta that
points to it. 

As for freshestRevocationInfo, that is not mandated by 509, in the same 
way that other extensions are not. It is one way to indicate where to 
go to find deltas but there can be others (e.g. perhaps the relying 
parties know that there is one indirect CRL that provides delta info
for all CAs inside an organization - perhaps this info is listed on 
their web site). If PKIX wanted to mandate it they could, but 509 
certainly does not.

Cheers,
Sharon

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Thursday, May 10, 2001 12:30 PM
> To: Carlin Covey; Sharon Boeyen
> Cc: [e-mail]
> Subject: Re: delta CRLs
> 
> 
> Carlin and Sharon (at the same time),
> 
> > Denis,
>  
> > Now I'm confused again (or still).  
> 
> :-)
> 
> > I agree that there is a difference
> > between a base CRL and a full CRL.  However, my 
> understanding was that a CRL
> > is a "base CRL" with respect to some delta CRL only by 
> virtue of having been
> > so identified in that delta CRL. 
> 
> I believe that a base CRL must include the Freshest CRL 
> extension (a.k.a.
> Delta CRL Distribution Point) defined in section 4.2.1.16. It 
> indicates both
> that the service exists and where to fetch the information. It is a
> non-critical extension so that a base CRL may also be used as 
> a full CL for
> relying parties not supporting delta CRLs.
> 
> > According to the PKIX profile, this base CRL must be a full CRL 
> > (complete for the intended scope).  
> > I believe that X.509 does not require that a base CRL be a full CRL.
> 
> You just say above: "According to the PKIX profile, this base 
> CRL must be a
> full CRL (complete for the intended scope". So do you mean 
> that X.509 and
> PKIX are taking different approaches ?
> 
> Regards,
> 
> Denis
> 
> > Regards,
> > 
> > Carlin
> > 
> > ____________________________
> > 
> > -  Carlin Covey
> >    Cylink Corporation
> > 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Thursday, May 10, 2001 1:19 AM
> > Cc: [e-mail]
> > Subject: Re: delta CRLs
> > 
> > Tim, David, Russ, Santosh, Carlin, and many others ...
> > 
> > There is difference between a base CRL and a full CRL : a 
> base CRL MUST
> > include a freshestCRL extension (a.k.a. a Delta CRL 
> distribution point),
> > whereas a full CRL may not include that extension. In other 
> words, a base
> > CRL is a also a full CRL, but a full CRL is not necessarily 
> a base CRL.
> > 
> > At any time a CA may issue a full CRL, whether or not a 
> base CRL has already
> > been issued. This additional CRL SHOULD have nextUpdate equal to the
> > nextUpdate of the last issued full CRL. However, there is 
> no guarantee that
> > this additional CRL will ever be seen by the relying party 
> (because there
> > will be two CRLs matching the thisUpdate and nextUpdate 
> rule and if one is
> > deleted, this is not seen by a relying party).
> > 
> > Due to the fact that CRLs numbers are strictly increasing, 
> two CRLs whether
> > they are a base CRL or delta CRL, CANNOT have the same CRL 
> number. So a
> > delta CRL and a full CRL that cover the same scope and are 
> issued at the
> > same time CANNOT have the same number. If a full CRL is 
> issued, its CRL
> > number bears no relationship with the previous base CRL, if 
> any. The only
> > relationship between the numbers is defined by the rule 
> that CRLs numbers
> > are strictly increasing. As Santosh said : "the CRL number is unique
> > whether it is a base or a delta ".
> > 
> > This is fairly important to be able to unambiguously (and 
> thus uniquely)
> > refer to a CRL by only providing its CRL number.
> > 
> > Besides the fact that a CRL issued later MUST have a higher 
> CRL number, full
> > CRLs and delta CRLs have independent numbering rules. As 
> noticed by Santosh,
> > " if the delta thisUpdate > base thisUpdate, delta CRL 
> number > base CRL
> > number (for the same or no stream identifier).
> > 
> > As Santosh said : "a check based on thisUpdate is more general and
> > preferred [to the use of CRL numbers]. "
> > 
> > Related to the three rules mentioned by Russ :
> > 
> > 1) the first rule is not understandable to me.
> > 2) the second rule does not say anything more than the 
> basic rule valid
> >    for any CRL (i.e. a CRL issued later MUST have a higher 
> CRL number).
> > 3) we will debate the hold condition, once we will have 
> sorted the main
> >    issue.
> > 
> > Russ said : "If separate number sequence is used, then you 
> will have to
> > periodically fetch base CRLs ". This is true.
> > 
> > Tim said that he would *not* like to be forced to download 
> new base CRLs.
> > This is the core of the "dispute".
> > 
> > >From the definition of what a delta CRL is, it is *not* possible to
> > get rid of the fetching of base CRLs. Unless we add a new 
> sentence to
> > expand/change that definition, base CRL fetching will 
> remain mandatory.
> > 
> > Remember that the goal of delta CRLs is to provide the 
> freshest information,
> > and to my knowledge the goal was not to get rid of the 
> fetching of base CRLs
> > (which may less frequent due to the support of delta CRLs).
> > 
> > If I understand correctly, Tim/David/Russ would like to 
> *always* achieve the
> > following property : it is possible to reconstruct the 
> current CRL by using
> > a base CRL from, e.g. 1990, i.e. by capturing every delta 
> CRL that has been
> > issued at the same time a base CRL was issued and which 
> contains updates
> > made to the *previous* base.
> > 
> > By this way the fetching of base CRLs could be avoided. 
> However, note that
> > it is perfectly " legal " to stop issuing base and delta 
> CRLs during some
> > period of time and to issue full CRLs instead (see the 
> difference between
> > "full" and "base" at the top of this e-mail). In other 
> words there is no
> > need to issue a new base CRL at the end of the validity 
> period of the
> > previous base CRL. Doing this would mandate to prescribe 
> issuing rules
> > for CAs that we have not prescripted.
> > 
> > I will now raise a series of questions, for which I believe we have
> > different answers. Tim/David/Russ do not hesitate to correct
> > if my guess is wrong. ;-)
> > 
> > Common point:
> > 
> > 1) What will be the value of the nextUpdate field from the 
> last issued delta
> > CRL for a given base CRL ?
> > 
> > Denis: the nextUpdate field from the last issued delta CRL 
> MUST be equal to
> > the value of nextUpdate from the base CRL.
> > 
> > Tim/David/Russ: ???
> > 
> > 2) Does a CA needs to issue a delta CRL at the time a full 
> CRL is issued ?
> > 
> > Denis: No.
> > Tim/David/Russ : ???
> > 
> > 3) Does a CA needs to issue a new base CRL at the end of 
> the validity of a
> > current base CRL ?
> > 
> > Denis: No.
> > Tim/David/Russ : ???
> > 
> > 4) Does a CA needs to issue a delta CRL at the same time a 
> new base is
> > issued ?
> > 
> > Denis: Yes. The delta CRL refers to the *new* base.
> > Tim/David/Russ : Yes. The delta CRL refers to the 
> *previous* base. [Note
> > that there can be no previous at all, or the "previous" may 
> even be three
> > months old].
> > 
> > The last point highlights the most noticeable difference. 
> Other differences
> > appears when considering the guaranty to get the freshest 
> information :
> > using the traditional scheme and the thisUpdate and 
> nextUpdate fields the
> > guaranty to get the freshest information is obtained, but 
> cannot be obtained
> > using the other scheme. :-(
> > 
> > Several people are referring to the X.509 document for 
> arguments to support
> > that discussion. However, it is important to remember that 
> we are defining
> > PKIX, not X.509, so we DO NOT need to copy and paste 
> everything from X.509,
> > but only what we believe is relevant.
> > 
> > We first need to clearly define the processing rules 
> applicable to the
> > relying parties. These rules will certainly contain 
> SHALL/MUST statements,
> > but may also include some MAY statements which may even be 
> conditional to
> > what the CA is doing. (I let Tim/David or Russ provide the 
> MAY statement).
> > 
> > Here is a proposal for the MUST statement, based on the 
> previous text I
> > produced:
> > 
> >    An application that is wishing to take advantage of delta CRLs
> >    for a given scope, MUST first find a base CRL for that scope,
> >    i.e. a full CRL that that contains a freshestCRL extension
> >    (a.k.a. a Delta CRL distribution point). It may then construct
> >    an updated CRL for that base, for a specific time T, by combining
> >    it with a delta CRL which contains a delta CRL indicator 
> extension
> >    with the same CRL number as the base CRL. Applications 
> that support
> >    delta CRLs MUST ensure that time T falls between thisUpdate and
> >    nextUpdate for both the base CRL and the delta CRL.
> > 
> >    Note: An application could also reconstruct an updated CRL, for
> >    a specific time T, by using a previously locally 
> reconstructed CRL
> >    based on the current base CRL, and combining it with a 
> delta CRL which
> >    contains a delta CRL indicator extension with the same 
> CRL number as
> >    the base CRL.
> > 
> > We also need to clearly separate the issuing rules 
> applicable for the CAs.
> > These rules will certainly contain SHALL statements, but 
> could also include
> > some MAY statements. (I let Tim/David or Russ provide the 
> MAY statement).
> > 
> > Here is a proposal for the MUST statement, based on the 
> previous text I
> > produced:
> > 
> >    A CA that supports delta-CRLs, MUST issue a base CRL, i.e. a full
> >    CRL that contains a freshestCRL extension (a.k.a. a Delta CRL
> >    distribution point). For any time T until the nextUpdate time
> >    indicated in a base CRL, the CA MUST provide one and only one
> >    delta CRL that refers to that base CRL and for which time T
> >    falls between thisUpdate and nextUpdate from the delta CRL.
> > 
> > In his e-mail from Wednesday, May 9, David said that 
> delta-CRL processing
> > rules could be base on time instead of CRL numbers. This is 
> a point of which
> > I strongly agree. Let us do it!
> > 
> > (However, there is no need to add to PKIX, as he suggested, 
> the support of
> > the baseUpdateTime extension from X.509 which would even 
> more complicate the
> > problem.)
> > 
> > Regards,
> > 
> > Denis
> 

------_=_NextPart_001_01C0D973.40CFCAC0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: delta CRLs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>A full CRL is a CRL that is complete for a given scope. A base CRL is a CRL</FONT>
<BR><FONT SIZE=2>that is the foundation for a delta CRL. I think the reason the wording in </FONT>
<BR><FONT SIZE=2>the definitions doesn't tie them together any more than that is because of </FONT>
<BR><FONT SIZE=2>a nuance where a delta CRL may reference a base CRL that was never actually </FONT>
<BR><FONT SIZE=2>issued as a full CRL. This is the case where the delta provides updates </FONT>
<BR><FONT SIZE=2>from a certain point in time, but it may be the case, in some environments, </FONT>
<BR><FONT SIZE=2>that full CRLs are never issued and the relying parties always build their </FONT>
<BR><FONT SIZE=2>local full CRLs from deltas. I realize that is not the case PKIX describes, </FONT>
<BR><FONT SIZE=2>but that's at least one reason the 509 definitions are the way they are (and</FONT>
<BR><FONT SIZE=2>yes there are definitions in clause 3 for both base CRL and full CRL).</FONT>
<BR><FONT SIZE=2>So, the term base is only relevant when used in the context of a delta that</FONT>
<BR><FONT SIZE=2>points to it. </FONT>
</P>

<P><FONT SIZE=2>As for freshestRevocationInfo, that is not mandated by 509, in the same </FONT>
<BR><FONT SIZE=2>way that other extensions are not. It is one way to indicate where to </FONT>
<BR><FONT SIZE=2>go to find deltas but there can be others (e.g. perhaps the relying </FONT>
<BR><FONT SIZE=2>parties know that there is one indirect CRL that provides delta info</FONT>
<BR><FONT SIZE=2>for all CAs inside an organization - perhaps this info is listed on </FONT>
<BR><FONT SIZE=2>their web site). If PKIX wanted to mandate it they could, but 509 </FONT>
<BR><FONT SIZE=2>certainly does not.</FONT>
</P>

<P><FONT SIZE=2>Cheers,</FONT>
<BR><FONT SIZE=2>Sharon</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Denis Pinkas [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Thursday, May 10, 2001 12:30 PM</FONT>
<BR><FONT SIZE=2>&gt; To: Carlin Covey; Sharon Boeyen</FONT>
<BR><FONT SIZE=2>&gt; Cc: [e-mail]</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: delta CRLs</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Carlin and Sharon (at the same time),</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Denis,</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Now I'm confused again (or still).&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; :-)</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; I agree that there is a difference</FONT>
<BR><FONT SIZE=2>&gt; &gt; between a base CRL and a full CRL.&nbsp; However, my </FONT>
<BR><FONT SIZE=2>&gt; understanding was that a CRL</FONT>
<BR><FONT SIZE=2>&gt; &gt; is a &quot;base CRL&quot; with respect to some delta CRL only by </FONT>
<BR><FONT SIZE=2>&gt; virtue of having been</FONT>
<BR><FONT SIZE=2>&gt; &gt; so identified in that delta CRL. </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I believe that a base CRL must include the Freshest CRL </FONT>
<BR><FONT SIZE=2>&gt; extension (a.k.a.</FONT>
<BR><FONT SIZE=2>&gt; Delta CRL Distribution Point) defined in section 4.2.1.16. It </FONT>
<BR><FONT SIZE=2>&gt; indicates both</FONT>
<BR><FONT SIZE=2>&gt; that the service exists and where to fetch the information. It is a</FONT>
<BR><FONT SIZE=2>&gt; non-critical extension so that a base CRL may also be used as </FONT>
<BR><FONT SIZE=2>&gt; a full CL for</FONT>
<BR><FONT SIZE=2>&gt; relying parties not supporting delta CRLs.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; According to the PKIX profile, this base CRL must be a full CRL </FONT>
<BR><FONT SIZE=2>&gt; &gt; (complete for the intended scope).&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt; I believe that X.509 does not require that a base CRL be a full CRL.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; You just say above: &quot;According to the PKIX profile, this base </FONT>
<BR><FONT SIZE=2>&gt; CRL must be a</FONT>
<BR><FONT SIZE=2>&gt; full CRL (complete for the intended scope&quot;. So do you mean </FONT>
<BR><FONT SIZE=2>&gt; that X.509 and</FONT>
<BR><FONT SIZE=2>&gt; PKIX are taking different approaches ?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Regards,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Denis</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Regards,</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Carlin</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; ____________________________</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; -&nbsp; Carlin Covey</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; Cylink Corporation</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; &gt; From: Denis Pinkas [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>&gt; &gt; Sent: Thursday, May 10, 2001 1:19 AM</FONT>
<BR><FONT SIZE=2>&gt; &gt; Cc: [e-mail]</FONT>
<BR><FONT SIZE=2>&gt; &gt; Subject: Re: delta CRLs</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Tim, David, Russ, Santosh, Carlin, and many others ...</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; There is difference between a base CRL and a full CRL : a </FONT>
<BR><FONT SIZE=2>&gt; base CRL MUST</FONT>
<BR><FONT SIZE=2>&gt; &gt; include a freshestCRL extension (a.k.a. a Delta CRL </FONT>
<BR><FONT SIZE=2>&gt; distribution point),</FONT>
<BR><FONT SIZE=2>&gt; &gt; whereas a full CRL may not include that extension. In other </FONT>
<BR><FONT SIZE=2>&gt; words, a base</FONT>
<BR><FONT SIZE=2>&gt; &gt; CRL is a also a full CRL, but a full CRL is not necessarily </FONT>
<BR><FONT SIZE=2>&gt; a base CRL.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; At any time a CA may issue a full CRL, whether or not a </FONT>
<BR><FONT SIZE=2>&gt; base CRL has already</FONT>
<BR><FONT SIZE=2>&gt; &gt; been issued. This additional CRL SHOULD have nextUpdate equal to the</FONT>
<BR><FONT SIZE=2>&gt; &gt; nextUpdate of the last issued full CRL. However, there is </FONT>
<BR><FONT SIZE=2>&gt; no guarantee that</FONT>
<BR><FONT SIZE=2>&gt; &gt; this additional CRL will ever be seen by the relying party </FONT>
<BR><FONT SIZE=2>&gt; (because there</FONT>
<BR><FONT SIZE=2>&gt; &gt; will be two CRLs matching the thisUpdate and nextUpdate </FONT>
<BR><FONT SIZE=2>&gt; rule and if one is</FONT>
<BR><FONT SIZE=2>&gt; &gt; deleted, this is not seen by a relying party).</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Due to the fact that CRLs numbers are strictly increasing, </FONT>
<BR><FONT SIZE=2>&gt; two CRLs whether</FONT>
<BR><FONT SIZE=2>&gt; &gt; they are a base CRL or delta CRL, CANNOT have the same CRL </FONT>
<BR><FONT SIZE=2>&gt; number. So a</FONT>
<BR><FONT SIZE=2>&gt; &gt; delta CRL and a full CRL that cover the same scope and are </FONT>
<BR><FONT SIZE=2>&gt; issued at the</FONT>
<BR><FONT SIZE=2>&gt; &gt; same time CANNOT have the same number. If a full CRL is </FONT>
<BR><FONT SIZE=2>&gt; issued, its CRL</FONT>
<BR><FONT SIZE=2>&gt; &gt; number bears no relationship with the previous base CRL, if </FONT>
<BR><FONT SIZE=2>&gt; any. The only</FONT>
<BR><FONT SIZE=2>&gt; &gt; relationship between the numbers is defined by the rule </FONT>
<BR><FONT SIZE=2>&gt; that CRLs numbers</FONT>
<BR><FONT SIZE=2>&gt; &gt; are strictly increasing. As Santosh said : &quot;the CRL number is unique</FONT>
<BR><FONT SIZE=2>&gt; &gt; whether it is a base or a delta &quot;.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; This is fairly important to be able to unambiguously (and </FONT>
<BR><FONT SIZE=2>&gt; thus uniquely)</FONT>
<BR><FONT SIZE=2>&gt; &gt; refer to a CRL by only providing its CRL number.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Besides the fact that a CRL issued later MUST have a higher </FONT>
<BR><FONT SIZE=2>&gt; CRL number, full</FONT>
<BR><FONT SIZE=2>&gt; &gt; CRLs and delta CRLs have independent numbering rules. As </FONT>
<BR><FONT SIZE=2>&gt; noticed by Santosh,</FONT>
<BR><FONT SIZE=2>&gt; &gt; &quot; if the delta thisUpdate &gt; base thisUpdate, delta CRL </FONT>
<BR><FONT SIZE=2>&gt; number &gt; base CRL</FONT>
<BR><FONT SIZE=2>&gt; &gt; number (for the same or no stream identifier).</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; As Santosh said : &quot;a check based on thisUpdate is more general and</FONT>
<BR><FONT SIZE=2>&gt; &gt; preferred [to the use of CRL numbers]. &quot;</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Related to the three rules mentioned by Russ :</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; 1) the first rule is not understandable to me.</FONT>
<BR><FONT SIZE=2>&gt; &gt; 2) the second rule does not say anything more than the </FONT>
<BR><FONT SIZE=2>&gt; basic rule valid</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; for any CRL (i.e. a CRL issued later MUST have a higher </FONT>
<BR><FONT SIZE=2>&gt; CRL number).</FONT>
<BR><FONT SIZE=2>&gt; &gt; 3) we will debate the hold condition, once we will have </FONT>
<BR><FONT SIZE=2>&gt; sorted the main</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; issue.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Russ said : &quot;If separate number sequence is used, then you </FONT>
<BR><FONT SIZE=2>&gt; will have to</FONT>
<BR><FONT SIZE=2>&gt; &gt; periodically fetch base CRLs &quot;. This is true.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Tim said that he would *not* like to be forced to download </FONT>
<BR><FONT SIZE=2>&gt; new base CRLs.</FONT>
<BR><FONT SIZE=2>&gt; &gt; This is the core of the &quot;dispute&quot;.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;From the definition of what a delta CRL is, it is *not* possible to</FONT>
<BR><FONT SIZE=2>&gt; &gt; get rid of the fetching of base CRLs. Unless we add a new </FONT>
<BR><FONT SIZE=2>&gt; sentence to</FONT>
<BR><FONT SIZE=2>&gt; &gt; expand/change that definition, base CRL fetching will </FONT>
<BR><FONT SIZE=2>&gt; remain mandatory.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Remember that the goal of delta CRLs is to provide the </FONT>
<BR><FONT SIZE=2>&gt; freshest information,</FONT>
<BR><FONT SIZE=2>&gt; &gt; and to my knowledge the goal was not to get rid of the </FONT>
<BR><FONT SIZE=2>&gt; fetching of base CRLs</FONT>
<BR><FONT SIZE=2>&gt; &gt; (which may less frequent due to the support of delta CRLs).</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; If I understand correctly, Tim/David/Russ would like to </FONT>
<BR><FONT SIZE=2>&gt; *always* achieve the</FONT>
<BR><FONT SIZE=2>&gt; &gt; following property : it is possible to reconstruct the </FONT>
<BR><FONT SIZE=2>&gt; current CRL by using</FONT>
<BR><FONT SIZE=2>&gt; &gt; a base CRL from, e.g. 1990, i.e. by capturing every delta </FONT>
<BR><FONT SIZE=2>&gt; CRL that has been</FONT>
<BR><FONT SIZE=2>&gt; &gt; issued at the same time a base CRL was issued and which </FONT>
<BR><FONT SIZE=2>&gt; contains updates</FONT>
<BR><FONT SIZE=2>&gt; &gt; made to the *previous* base.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; By this way the fetching of base CRLs could be avoided. </FONT>
<BR><FONT SIZE=2>&gt; However, note that</FONT>
<BR><FONT SIZE=2>&gt; &gt; it is perfectly &quot; legal &quot; to stop issuing base and delta </FONT>
<BR><FONT SIZE=2>&gt; CRLs during some</FONT>
<BR><FONT SIZE=2>&gt; &gt; period of time and to issue full CRLs instead (see the </FONT>
<BR><FONT SIZE=2>&gt; difference between</FONT>
<BR><FONT SIZE=2>&gt; &gt; &quot;full&quot; and &quot;base&quot; at the top of this e-mail). In other </FONT>
<BR><FONT SIZE=2>&gt; words there is no</FONT>
<BR><FONT SIZE=2>&gt; &gt; need to issue a new base CRL at the end of the validity </FONT>
<BR><FONT SIZE=2>&gt; period of the</FONT>
<BR><FONT SIZE=2>&gt; &gt; previous base CRL. Doing this would mandate to prescribe </FONT>
<BR><FONT SIZE=2>&gt; issuing rules</FONT>
<BR><FONT SIZE=2>&gt; &gt; for CAs that we have not prescripted.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; I will now raise a series of questions, for which I believe we have</FONT>
<BR><FONT SIZE=2>&gt; &gt; different answers. Tim/David/Russ do not hesitate to correct</FONT>
<BR><FONT SIZE=2>&gt; &gt; if my guess is wrong. ;-)</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Common point:</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; 1) What will be the value of the nextUpdate field from the </FONT>
<BR><FONT SIZE=2>&gt; last issued delta</FONT>
<BR><FONT SIZE=2>&gt; &gt; CRL for a given base CRL ?</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Denis: the nextUpdate field from the last issued delta CRL </FONT>
<BR><FONT SIZE=2>&gt; MUST be equal to</FONT>
<BR><FONT SIZE=2>&gt; &gt; the value of nextUpdate from the base CRL.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Tim/David/Russ: ???</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; 2) Does a CA needs to issue a delta CRL at the time a full </FONT>
<BR><FONT SIZE=2>&gt; CRL is issued ?</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Denis: No.</FONT>
<BR><FONT SIZE=2>&gt; &gt; Tim/David/Russ : ???</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; 3) Does a CA needs to issue a new base CRL at the end of </FONT>
<BR><FONT SIZE=2>&gt; the validity of a</FONT>
<BR><FONT SIZE=2>&gt; &gt; current base CRL ?</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Denis: No.</FONT>
<BR><FONT SIZE=2>&gt; &gt; Tim/David/Russ : ???</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; 4) Does a CA needs to issue a delta CRL at the same time a </FONT>
<BR><FONT SIZE=2>&gt; new base is</FONT>
<BR><FONT SIZE=2>&gt; &gt; issued ?</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Denis: Yes. The delta CRL refers to the *new* base.</FONT>
<BR><FONT SIZE=2>&gt; &gt; Tim/David/Russ : Yes. The delta CRL refers to the </FONT>
<BR><FONT SIZE=2>&gt; *previous* base. [Note</FONT>
<BR><FONT SIZE=2>&gt; &gt; that there can be no previous at all, or the &quot;previous&quot; may </FONT>
<BR><FONT SIZE=2>&gt; even be three</FONT>
<BR><FONT SIZE=2>&gt; &gt; months old].</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; The last point highlights the most noticeable difference. </FONT>
<BR><FONT SIZE=2>&gt; Other differences</FONT>
<BR><FONT SIZE=2>&gt; &gt; appears when considering the guaranty to get the freshest </FONT>
<BR><FONT SIZE=2>&gt; information :</FONT>
<BR><FONT SIZE=2>&gt; &gt; using the traditional scheme and the thisUpdate and </FONT>
<BR><FONT SIZE=2>&gt; nextUpdate fields the</FONT>
<BR><FONT SIZE=2>&gt; &gt; guaranty to get the freshest information is obtained, but </FONT>
<BR><FONT SIZE=2>&gt; cannot be obtained</FONT>
<BR><FONT SIZE=2>&gt; &gt; using the other scheme. :-(</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Several people are referring to the X.509 document for </FONT>
<BR><FONT SIZE=2>&gt; arguments to support</FONT>
<BR><FONT SIZE=2>&gt; &gt; that discussion. However, it is important to remember that </FONT>
<BR><FONT SIZE=2>&gt; we are defining</FONT>
<BR><FONT SIZE=2>&gt; &gt; PKIX, not X.509, so we DO NOT need to copy and paste </FONT>
<BR><FONT SIZE=2>&gt; everything from X.509,</FONT>
<BR><FONT SIZE=2>&gt; &gt; but only what we believe is relevant.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; We first need to clearly define the processing rules </FONT>
<BR><FONT SIZE=2>&gt; applicable to the</FONT>
<BR><FONT SIZE=2>&gt; &gt; relying parties. These rules will certainly contain </FONT>
<BR><FONT SIZE=2>&gt; SHALL/MUST statements,</FONT>
<BR><FONT SIZE=2>&gt; &gt; but may also include some MAY statements which may even be </FONT>
<BR><FONT SIZE=2>&gt; conditional to</FONT>
<BR><FONT SIZE=2>&gt; &gt; what the CA is doing. (I let Tim/David or Russ provide the </FONT>
<BR><FONT SIZE=2>&gt; MAY statement).</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Here is a proposal for the MUST statement, based on the </FONT>
<BR><FONT SIZE=2>&gt; previous text I</FONT>
<BR><FONT SIZE=2>&gt; &gt; produced:</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; An application that is wishing to take advantage of delta CRLs</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; for a given scope, MUST first find a base CRL for that scope,</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; i.e. a full CRL that that contains a freshestCRL extension</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; (a.k.a. a Delta CRL distribution point). It may then construct</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; an updated CRL for that base, for a specific time T, by combining</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; it with a delta CRL which contains a delta CRL indicator </FONT>
<BR><FONT SIZE=2>&gt; extension</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; with the same CRL number as the base CRL. Applications </FONT>
<BR><FONT SIZE=2>&gt; that support</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; delta CRLs MUST ensure that time T falls between thisUpdate and</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; nextUpdate for both the base CRL and the delta CRL.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; Note: An application could also reconstruct an updated CRL, for</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; a specific time T, by using a previously locally </FONT>
<BR><FONT SIZE=2>&gt; reconstructed CRL</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; based on the current base CRL, and combining it with a </FONT>
<BR><FONT SIZE=2>&gt; delta CRL which</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; contains a delta CRL indicator extension with the same </FONT>
<BR><FONT SIZE=2>&gt; CRL number as</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; the base CRL.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; We also need to clearly separate the issuing rules </FONT>
<BR><FONT SIZE=2>&gt; applicable for the CAs.</FONT>
<BR><FONT SIZE=2>&gt; &gt; These rules will certainly contain SHALL statements, but </FONT>
<BR><FONT SIZE=2>&gt; could also include</FONT>
<BR><FONT SIZE=2>&gt; &gt; some MAY statements. (I let Tim/David or Russ provide the </FONT>
<BR><FONT SIZE=2>&gt; MAY statement).</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Here is a proposal for the MUST statement, based on the </FONT>
<BR><FONT SIZE=2>&gt; previous text I</FONT>
<BR><FONT SIZE=2>&gt; &gt; produced:</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; A CA that supports delta-CRLs, MUST issue a base CRL, i.e. a full</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; CRL that contains a freshestCRL extension (a.k.a. a Delta CRL</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; distribution point). For any time T until the nextUpdate time</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; indicated in a base CRL, the CA MUST provide one and only one</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; delta CRL that refers to that base CRL and for which time T</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; falls between thisUpdate and nextUpdate from the delta CRL.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; In his e-mail from Wednesday, May 9, David said that </FONT>
<BR><FONT SIZE=2>&gt; delta-CRL processing</FONT>
<BR><FONT SIZE=2>&gt; &gt; rules could be base on time instead of CRL numbers. This is </FONT>
<BR><FONT SIZE=2>&gt; a point of which</FONT>
<BR><FONT SIZE=2>&gt; &gt; I strongly agree. Let us do it!</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; (However, there is no need to add to PKIX, as he suggested, </FONT>
<BR><FONT SIZE=2>&gt; the support of</FONT>
<BR><FONT SIZE=2>&gt; &gt; the baseUpdateTime extension from X.509 which would even </FONT>
<BR><FONT SIZE=2>&gt; more complicate the</FONT>
<BR><FONT SIZE=2>&gt; &gt; problem.)</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Regards,</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Denis</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0D973.40CFCAC0--


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA15430 for <[e-mail]>; Thu, 10 May 2001 09:54:45 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA53128; Thu, 10 May 2001 18:54:46 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id SAA04174; Thu, 10 May 2001 18:54:11 +0200
Message-ID: <[e-mail]>
Date: Thu, 10 May 2001 18:52:49 +0200
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: Carlin Covey <[e-mail]>, Sharon Boeyen <[e-mail]>, [e-mail]
Subject: Re: delta CRLs
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id JAA15432

Santosh,

Let me send you a reply just before leaving my office tonight.

> Denis:
> 
> I do not agree with you.  Any CRL that is not a delta CRL (i.e.,
> deltaCRLIndicator extension is absent), is a base CRL for some scope as
> defined in CRLScope extension and/or the IDP extension.

I do not agree with you either. For a CRL to be a base CRL, there needs
first to be a delta CRL for it. In a closed environment, you could say that
this is sufficient because there is fixed point of contact to fetch delta
CRLs from and that this point is known using "out-of-bansds" means. We all
know what this means in terms of scalability. :-(

Until the CRL distribution point is used, noone knew where to fecth CRLs
from. The same will apply for delta CRLs. If we want to use delta CRLs in an
open environment, then we need the freshest CRL extension to be present.

There are other side advantages:

1° it allows to know when delta CRLs are supported, otherwise fetches in the
   repository would be done for nothing. So it saves time and/or increases
   performances.

2° it allows to make sure that a delta scheme is supported and by using
   additional rules, it allows to make sure to get the freshest delta CRL. 

I hope this clarifies the point.

Regards,

Denis
 
 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Thursday, May 10, 2001 12:30 PM
> To: Carlin Covey; Sharon Boeyen
> Cc: [e-mail]
> Subject: Re: delta CRLs
> 
> Carlin and Sharon (at the same time),
> 
> > Denis,
> 
> > Now I'm confused again (or still).
> 
> :-)
> 
> > I agree that there is a difference
> > between a base CRL and a full CRL.  However, my understanding was that a
> CRL
> > is a "base CRL" with respect to some delta CRL only by virtue of having
> been
> > so identified in that delta CRL.
> 
> I believe that a base CRL must include the Freshest CRL extension (a.k.a.
> Delta CRL Distribution Point) defined in section 4.2.1.16. It indicates
> both
> that the service exists and where to fetch the information. It is a
> non-critical extension so that a base CRL may also be used as a full CL
> for
> relying parties not supporting delta CRLs.
> 
> > According to the PKIX profile, this base CRL must be a full CRL
> > (complete for the intended scope).
> > I believe that X.509 does not require that a base CRL be a full CRL.
> 
> You just say above: "According to the PKIX profile, this base CRL must be
> a
> full CRL (complete for the intended scope". So do you mean that X.509 and
> PKIX are taking different approaches ?
> 
> Regards,
> 
> Denis
> 
> > Regards,
> >
> > Carlin
> >
> > ____________________________
> >
> > -  Carlin Covey
> >    Cylink Corporation
> >
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Thursday, May 10, 2001 1:19 AM
> > Cc: [e-mail]
> > Subject: Re: delta CRLs
> >
> > Tim, David, Russ, Santosh, Carlin, and many others ...
> >
> > There is difference between a base CRL and a full CRL : a base CRL MUST
> > include a freshestCRL extension (a.k.a. a Delta CRL distribution point),
> 
> > whereas a full CRL may not include that extension. In other words, a
> base
> > CRL is a also a full CRL, but a full CRL is not necessarily a base CRL.
> >
> > At any time a CA may issue a full CRL, whether or not a base CRL has
> already
> > been issued. This additional CRL SHOULD have nextUpdate equal to the
> > nextUpdate of the last issued full CRL. However, there is no guarantee
> that
> > this additional CRL will ever be seen by the relying party (because
> there
> > will be two CRLs matching the thisUpdate and nextUpdate rule and if one
> is
> > deleted, this is not seen by a relying party).
> >
> > Due to the fact that CRLs numbers are strictly increasing, two CRLs
> whether
> > they are a base CRL or delta CRL, CANNOT have the same CRL number. So a
> > delta CRL and a full CRL that cover the same scope and are issued at the
> 
> > same time CANNOT have the same number. If a full CRL is issued, its CRL
> > number bears no relationship with the previous base CRL, if any. The
> only
> > relationship between the numbers is defined by the rule that CRLs
> numbers
> > are strictly increasing. As Santosh said : "the CRL number is unique
> > whether it is a base or a delta ".
> >
> > This is fairly important to be able to unambiguously (and thus uniquely)
> 
> > refer to a CRL by only providing its CRL number.
> >
> > Besides the fact that a CRL issued later MUST have a higher CRL number,
> full
> > CRLs and delta CRLs have independent numbering rules. As noticed by
> Santosh,
> > " if the delta thisUpdate > base thisUpdate, delta CRL number > base CRL
> 
> > number (for the same or no stream identifier).
> >
> > As Santosh said : "a check based on thisUpdate is more general and
> > preferred [to the use of CRL numbers]. "
> >
> > Related to the three rules mentioned by Russ :
> >
> > 1) the first rule is not understandable to me.
> > 2) the second rule does not say anything more than the basic rule valid
> >    for any CRL (i.e. a CRL issued later MUST have a higher CRL number).
> > 3) we will debate the hold condition, once we will have sorted the main
> >    issue.
> >
> > Russ said : "If separate number sequence is used, then you will have to
> > periodically fetch base CRLs ". This is true.
> >
> > Tim said that he would *not* like to be forced to download new base
> CRLs.
> > This is the core of the "dispute".
> >
> > >From the definition of what a delta CRL is, it is *not* possible to
> > get rid of the fetching of base CRLs. Unless we add a new sentence to
> > expand/change that definition, base CRL fetching will remain mandatory.
> >
> > Remember that the goal of delta CRLs is to provide the freshest
> information,
> > and to my knowledge the goal was not to get rid of the fetching of base
> CRLs
> > (which may less frequent due to the support of delta CRLs).
> >
> > If I understand correctly, Tim/David/Russ would like to *always* achieve
> the
> > following property : it is possible to reconstruct the current CRL by
> using
> > a base CRL from, e.g. 1990, i.e. by capturing every delta CRL that has
> been
> > issued at the same time a base CRL was issued and which contains updates
> 
> > made to the *previous* base.
> >
> > By this way the fetching of base CRLs could be avoided. However, note
> that
> > it is perfectly " legal " to stop issuing base and delta CRLs during
> some
> > period of time and to issue full CRLs instead (see the difference
> between
> > "full" and "base" at the top of this e-mail). In other words there is no
> 
> > need to issue a new base CRL at the end of the validity period of the
> > previous base CRL. Doing this would mandate to prescribe issuing rules
> > for CAs that we have not prescripted.
> >
> > I will now raise a series of questions, for which I believe we have
> > different answers. Tim/David/Russ do not hesitate to correct
> > if my guess is wrong. ;-)
> >
> > Common point:
> >
> > 1) What will be the value of the nextUpdate field from the last issued
> delta
> > CRL for a given base CRL ?
> >
> > Denis: the nextUpdate field from the last issued delta CRL MUST be equal
> to
> > the value of nextUpdate from the base CRL.
> >
> > Tim/David/Russ: ???
> >
> > 2) Does a CA needs to issue a delta CRL at the time a full CRL is issued
> ?
> >
> > Denis: No.
> > Tim/David/Russ : ???
> >
> > 3) Does a CA needs to issue a new base CRL at the end of the validity of
> a
> > current base CRL ?
> >
> > Denis: No.
> > Tim/David/Russ : ???
> >
> > 4) Does a CA needs to issue a delta CRL at the same time a new base is
> > issued ?
> >
> > Denis: Yes. The delta CRL refers to the *new* base.
> > Tim/David/Russ : Yes. The delta CRL refers to the *previous* base. [Note
> 
> > that there can be no previous at all, or the "previous" may even be
> three
> > months old].
> >
> > The last point highlights the most noticeable difference. Other
> differences
> > appears when considering the guaranty to get the freshest information :
> > using the traditional scheme and the thisUpdate and nextUpdate fields
> the
> > guaranty to get the freshest information is obtained, but cannot be
> obtained
> > using the other scheme. :-(
> >
> > Several people are referring to the X.509 document for arguments to
> support
> > that discussion. However, it is important to remember that we are
> defining
> > PKIX, not X.509, so we DO NOT need to copy and paste everything from
> X.509,
> > but only what we believe is relevant.
> >
> > We first need to clearly define the processing rules applicable to the
> > relying parties. These rules will certainly contain SHALL/MUST
> statements,
> > but may also include some MAY statements which may even be conditional
> to
> > what the CA is doing. (I let Tim/David or Russ provide the MAY
> statement).
> >
> > Here is a proposal for the MUST statement, based on the previous text I
> > produced:
> >
> >    An application that is wishing to take advantage of delta CRLs
> >    for a given scope, MUST first find a base CRL for that scope,
> >    i.e. a full CRL that that contains a freshestCRL extension
> >    (a.k.a. a Delta CRL distribution point). It may then construct
> >    an updated CRL for that base, for a specific time T, by combining
> >    it with a delta CRL which contains a delta CRL indicator extension
> >    with the same CRL number as the base CRL. Applications that support
> >    delta CRLs MUST ensure that time T falls between thisUpdate and
> >    nextUpdate for both the base CRL and the delta CRL.
> >
> >    Note: An application could also reconstruct an updated CRL, for
> >    a specific time T, by using a previously locally reconstructed CRL
> >    based on the current base CRL, and combining it with a delta CRL
> which
> >    contains a delta CRL indicator extension with the same CRL number as
> >    the base CRL.
> >
> > We also need to clearly separate the issuing rules applicable for the
> CAs.
> > These rules will certainly contain SHALL statements, but could also
> include
> > some MAY statements. (I let Tim/David or Russ provide the MAY
> statement).
> >
> > Here is a proposal for the MUST statement, based on the previous text I
> > produced:
> >
> >    A CA that supports delta-CRLs, MUST issue a base CRL, i.e. a full
> >    CRL that contains a freshestCRL extension (a.k.a. a Delta CRL
> >    distribution point). For any time T until the nextUpdate time
> >    indicated in a base CRL, the CA MUST provide one and only one
> >    delta CRL that refers to that base CRL and for which time T
> >    falls between thisUpdate and nextUpdate from the delta CRL.
> >
> > In his e-mail from Wednesday, May 9, David said that delta-CRL
> processing
> > rules could be base on time instead of CRL numbers. This is a point of
> which
> > I strongly agree. Let us do it!
> >
> > (However, there is no need to add to PKIX, as he suggested, the support
> of
> > the baseUpdateTime extension from X.509 which would even more complicate
> the
> > problem.)
> >
> > Regards,
> >
> > Denis


Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA14931 for <[e-mail]>; Thu, 10 May 2001 09:51:44 -0700 (PDT)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KVA79ZY7; Thu, 10 May 2001 09:45:58 -0700
From: "Carlin Covey" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: delta CRLs
Date: Thu, 10 May 2001 09:50:58 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <[e-mail]>

Denis,

Now I'm confused again (or still).  I agree that there is a difference
between a base CRL and a full CRL.  However, my understanding was that a CRL
is a "base CRL" with respect to some delta CRL only by virtue of having been
so identified in that delta CRL.  According to the PKIX profile, this base
CRL must be a full CRL (complete for the intended scope).  I believe that
X.509 does not require that a base CRL be a full CRL.

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Thursday, May 10, 2001 1:19 AM
Cc: [e-mail]
Subject: Re: delta CRLs


Tim, David, Russ, Santosh, Carlin, and many others ...

There is difference between a base CRL and a full CRL : a base CRL MUST
include a freshestCRL extension (a.k.a. a Delta CRL distribution point),
whereas a full CRL may not include that extension. In other words, a base
CRL is a also a full CRL, but a full CRL is not necessarily a base CRL.

At any time a CA may issue a full CRL, whether or not a base CRL has already
been issued. This additional CRL SHOULD have nextUpdate equal to the
nextUpdate of the last issued full CRL. However, there is no guarantee that
this additional CRL will ever be seen by the relying party (because there
will be two CRLs matching the thisUpdate and nextUpdate rule and if one is
deleted, this is not seen by a relying party).

Due to the fact that CRLs numbers are strictly increasing, two CRLs whether
they are a base CRL or delta CRL, CANNOT have the same CRL number. So a
delta CRL and a full CRL that cover the same scope and are issued at the
same time CANNOT have the same number. If a full CRL is issued, its CRL
number bears no relationship with the previous base CRL, if any. The only
relationship between the numbers is defined by the rule that CRLs numbers
are strictly increasing. As Santosh said : "the CRL number is unique
whether it is a base or a delta ".

This is fairly important to be able to unambiguously (and thus uniquely)
refer to a CRL by only providing its CRL number.

Besides the fact that a CRL issued later MUST have a higher CRL number, full
CRLs and delta CRLs have independent numbering rules. As noticed by Santosh,
" if the delta thisUpdate > base thisUpdate, delta CRL number > base CRL
number (for the same or no stream identifier).

As Santosh said : "a check based on thisUpdate is more general and
preferred [to the use of CRL numbers]. "

Related to the three rules mentioned by Russ :

1) the first rule is not understandable to me.
2) the second rule does not say anything more than the basic rule valid
   for any CRL (i.e. a CRL issued later MUST have a higher CRL number).
3) we will debate the hold condition, once we will have sorted the main
   issue.

Russ said : "If separate number sequence is used, then you will have to
periodically fetch base CRLs ". This is true.

Tim said that he would *not* like to be forced to download new base CRLs.
This is the core of the "dispute".

>From the definition of what a delta CRL is, it is *not* possible to
get rid of the fetching of base CRLs. Unless we add a new sentence to
expand/change that definition, base CRL fetching will remain mandatory.

Remember that the goal of delta CRLs is to provide the freshest information,
and to my knowledge the goal was not to get rid of the fetching of base CRLs
(which may less frequent due to the support of delta CRLs).

If I understand correctly, Tim/David/Russ would like to *always* achieve the
following property : it is possible to reconstruct the current CRL by using
a base CRL from, e.g. 1990, i.e. by capturing every delta CRL that has been
issued at the same time a base CRL was issued and which contains updates
made to the *previous* base.

By this way the fetching of base CRLs could be avoided. However, note that
it is perfectly " legal " to stop issuing base and delta CRLs during some
period of time and to issue full CRLs instead (see the difference between
"full" and "base" at the top of this e-mail). In other words there is no
need to issue a new base CRL at the end of the validity period of the
previous base CRL. Doing this would mandate to prescribe issuing rules
for CAs that we have not prescripted.

I will now raise a series of questions, for which I believe we have
different answers. Tim/David/Russ do not hesitate to correct
if my guess is wrong. ;-)

Common point:

1) What will be the value of the nextUpdate field from the last issued delta
CRL for a given base CRL ?

Denis: the nextUpdate field from the last issued delta CRL MUST be equal to
the value of nextUpdate from the base CRL.

Tim/David/Russ: ???

2) Does a CA needs to issue a delta CRL at the time a full CRL is issued ?

Denis: No.
Tim/David/Russ : ???

3) Does a CA needs to issue a new base CRL at the end of the validity of a
current base CRL ?

Denis: No.
Tim/David/Russ : ???

4) Does a CA needs to issue a delta CRL at the same time a new base is
issued ?

Denis: Yes. The delta CRL refers to the *new* base.
Tim/David/Russ : Yes. The delta CRL refers to the *previous* base. [Note
that there can be no previous at all, or the "previous" may even be three
months old].

The last point highlights the most noticeable difference. Other differences
appears when considering the guaranty to get the freshest information :
using the traditional scheme and the thisUpdate and nextUpdate fields the
guaranty to get the freshest information is obtained, but cannot be obtained
using the other scheme. :-(

Several people are referring to the X.509 document for arguments to support
that discussion. However, it is important to remember that we are defining
PKIX, not X.509, so we DO NOT need to copy and paste everything from X.509,
but only what we believe is relevant.

We first need to clearly define the processing rules applicable to the
relying parties. These rules will certainly contain SHALL/MUST statements,
but may also include some MAY statements which may even be conditional to
what the CA is doing. (I let Tim/David or Russ provide the MAY statement).

Here is a proposal for the MUST statement, based on the previous text I
produced:

   An application that is wishing to take advantage of delta CRLs
   for a given scope, MUST first find a base CRL for that scope,
   i.e. a full CRL that that contains a freshestCRL extension
   (a.k.a. a Delta CRL distribution point). It may then construct
   an updated CRL for that base, for a specific time T, by combining
   it with a delta CRL which contains a delta CRL indicator extension
   with the same CRL number as the base CRL. Applications that support
   delta CRLs MUST ensure that time T falls between thisUpdate and
   nextUpdate for both the base CRL and the delta CRL.

   Note: An application could also reconstruct an updated CRL, for
   a specific time T, by using a previously locally reconstructed CRL
   based on the current base CRL, and combining it with a delta CRL which
   contains a delta CRL indicator extension with the same CRL number as
   the base CRL.

We also need to clearly separate the issuing rules applicable for the CAs.
These rules will certainly contain SHALL statements, but could also include
some MAY statements. (I let Tim/David or Russ provide the MAY statement).

Here is a proposal for the MUST statement, based on the previous text I
produced:

   A CA that supports delta-CRLs, MUST issue a base CRL, i.e. a full
   CRL that contains a freshestCRL extension (a.k.a. a Delta CRL
   distribution point). For any time T until the nextUpdate time
   indicated in a base CRL, the CA MUST provide one and only one
   delta CRL that refers to that base CRL and for which time T
   falls between thisUpdate and nextUpdate from the delta CRL.

In his e-mail from Wednesday, May 9, David said that delta-CRL processing
rules could be base on time instead of CRL numbers. This is a point of which
I strongly agree. Let us do it!

(However, there is no need to add to PKIX, as he suggested, the support of
the baseUpdateTime extension from X.509 which would even more complicate the
problem.)

Regards,

Denis



Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA14009 for <[e-mail]>; Thu, 10 May 2001 09:38:45 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <K4X9NJ6W>; Thu, 10 May 2001 12:38:14 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Denis Pinkas <[e-mail]>, Carlin Covey <[e-mail]>, Sharon Boeyen <[e-mail]>
Cc: [e-mail]
Subject: RE: delta CRLs
Date: Thu, 10 May 2001 12:28:57 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D96E.500FB310"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D96E.500FB310
Content-Type: text/plain;
	charset="iso-8859-1"

Denis:

I do not agree with you.  Any CRL that is not a delta CRL (i.e.,
deltaCRLIndicator extension is absent), is a base CRL for some scope as
defined in CRLScope extension and/or the IDP extension.

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Thursday, May 10, 2001 12:30 PM
To: Carlin Covey; Sharon Boeyen
Cc: [e-mail]
Subject: Re: delta CRLs


Carlin and Sharon (at the same time),

> Denis,
 
> Now I'm confused again (or still).  

:-)

> I agree that there is a difference
> between a base CRL and a full CRL.  However, my understanding was that a
CRL
> is a "base CRL" with respect to some delta CRL only by virtue of having
been
> so identified in that delta CRL. 

I believe that a base CRL must include the Freshest CRL extension (a.k.a.
Delta CRL Distribution Point) defined in section 4.2.1.16. It indicates both
that the service exists and where to fetch the information. It is a
non-critical extension so that a base CRL may also be used as a full CL for
relying parties not supporting delta CRLs.

> According to the PKIX profile, this base CRL must be a full CRL 
> (complete for the intended scope).  
> I believe that X.509 does not require that a base CRL be a full CRL.

You just say above: "According to the PKIX profile, this base CRL must be a
full CRL (complete for the intended scope". So do you mean that X.509 and
PKIX are taking different approaches ?

Regards,

Denis

> Regards,
> 
> Carlin
> 
> ____________________________
> 
> -  Carlin Covey
>    Cylink Corporation
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Thursday, May 10, 2001 1:19 AM
> Cc: [e-mail]
> Subject: Re: delta CRLs
> 
> Tim, David, Russ, Santosh, Carlin, and many others ...
> 
> There is difference between a base CRL and a full CRL : a base CRL MUST
> include a freshestCRL extension (a.k.a. a Delta CRL distribution point),
> whereas a full CRL may not include that extension. In other words, a base
> CRL is a also a full CRL, but a full CRL is not necessarily a base CRL.
> 
> At any time a CA may issue a full CRL, whether or not a base CRL has
already
> been issued. This additional CRL SHOULD have nextUpdate equal to the
> nextUpdate of the last issued full CRL. However, there is no guarantee
that
> this additional CRL will ever be seen by the relying party (because there
> will be two CRLs matching the thisUpdate and nextUpdate rule and if one is
> deleted, this is not seen by a relying party).
> 
> Due to the fact that CRLs numbers are strictly increasing, two CRLs
whether
> they are a base CRL or delta CRL, CANNOT have the same CRL number. So a
> delta CRL and a full CRL that cover the same scope and are issued at the
> same time CANNOT have the same number. If a full CRL is issued, its CRL
> number bears no relationship with the previous base CRL, if any. The only
> relationship between the numbers is defined by the rule that CRLs numbers
> are strictly increasing. As Santosh said : "the CRL number is unique
> whether it is a base or a delta ".
> 
> This is fairly important to be able to unambiguously (and thus uniquely)
> refer to a CRL by only providing its CRL number.
> 
> Besides the fact that a CRL issued later MUST have a higher CRL number,
full
> CRLs and delta CRLs have independent numbering rules. As noticed by
Santosh,
> " if the delta thisUpdate > base thisUpdate, delta CRL number > base CRL
> number (for the same or no stream identifier).
> 
> As Santosh said : "a check based on thisUpdate is more general and
> preferred [to the use of CRL numbers]. "
> 
> Related to the three rules mentioned by Russ :
> 
> 1) the first rule is not understandable to me.
> 2) the second rule does not say anything more than the basic rule valid
>    for any CRL (i.e. a CRL issued later MUST have a higher CRL number).
> 3) we will debate the hold condition, once we will have sorted the main
>    issue.
> 
> Russ said : "If separate number sequence is used, then you will have to
> periodically fetch base CRLs ". This is true.
> 
> Tim said that he would *not* like to be forced to download new base CRLs.
> This is the core of the "dispute".
> 
> >From the definition of what a delta CRL is, it is *not* possible to
> get rid of the fetching of base CRLs. Unless we add a new sentence to
> expand/change that definition, base CRL fetching will remain mandatory.
> 
> Remember that the goal of delta CRLs is to provide the freshest
information,
> and to my knowledge the goal was not to get rid of the fetching of base
CRLs
> (which may less frequent due to the support of delta CRLs).
> 
> If I understand correctly, Tim/David/Russ would like to *always* achieve
the
> following property : it is possible to reconstruct the current CRL by
using
> a base CRL from, e.g. 1990, i.e. by capturing every delta CRL that has
been
> issued at the same time a base CRL was issued and which contains updates
> made to the *previous* base.
> 
> By this way the fetching of base CRLs could be avoided. However, note that
> it is perfectly " legal " to stop issuing base and delta CRLs during some
> period of time and to issue full CRLs instead (see the difference between
> "full" and "base" at the top of this e-mail). In other words there is no
> need to issue a new base CRL at the end of the validity period of the
> previous base CRL. Doing this would mandate to prescribe issuing rules
> for CAs that we have not prescripted.
> 
> I will now raise a series of questions, for which I believe we have
> different answers. Tim/David/Russ do not hesitate to correct
> if my guess is wrong. ;-)
> 
> Common point:
> 
> 1) What will be the value of the nextUpdate field from the last issued
delta
> CRL for a given base CRL ?
> 
> Denis: the nextUpdate field from the last issued delta CRL MUST be equal
to
> the value of nextUpdate from the base CRL.
> 
> Tim/David/Russ: ???
> 
> 2) Does a CA needs to issue a delta CRL at the time a full CRL is issued ?
> 
> Denis: No.
> Tim/David/Russ : ???
> 
> 3) Does a CA needs to issue a new base CRL at the end of the validity of a
> current base CRL ?
> 
> Denis: No.
> Tim/David/Russ : ???
> 
> 4) Does a CA needs to issue a delta CRL at the same time a new base is
> issued ?
> 
> Denis: Yes. The delta CRL refers to the *new* base.
> Tim/David/Russ : Yes. The delta CRL refers to the *previous* base. [Note
> that there can be no previous at all, or the "previous" may even be three
> months old].
> 
> The last point highlights the most noticeable difference. Other
differences
> appears when considering the guaranty to get the freshest information :
> using the traditional scheme and the thisUpdate and nextUpdate fields the
> guaranty to get the freshest information is obtained, but cannot be
obtained
> using the other scheme. :-(
> 
> Several people are referring to the X.509 document for arguments to
support
> that discussion. However, it is important to remember that we are defining
> PKIX, not X.509, so we DO NOT need to copy and paste everything from
X.509,
> but only what we believe is relevant.
> 
> We first need to clearly define the processing rules applicable to the
> relying parties. These rules will certainly contain SHALL/MUST statements,
> but may also include some MAY statements which may even be conditional to
> what the CA is doing. (I let Tim/David or Russ provide the MAY statement).
> 
> Here is a proposal for the MUST statement, based on the previous text I
> produced:
> 
>    An application that is wishing to take advantage of delta CRLs
>    for a given scope, MUST first find a base CRL for that scope,
>    i.e. a full CRL that that contains a freshestCRL extension
>    (a.k.a. a Delta CRL distribution point). It may then construct
>    an updated CRL for that base, for a specific time T, by combining
>    it with a delta CRL which contains a delta CRL indicator extension
>    with the same CRL number as the base CRL. Applications that support
>    delta CRLs MUST ensure that time T falls between thisUpdate and
>    nextUpdate for both the base CRL and the delta CRL.
> 
>    Note: An application could also reconstruct an updated CRL, for
>    a specific time T, by using a previously locally reconstructed CRL
>    based on the current base CRL, and combining it with a delta CRL which
>    contains a delta CRL indicator extension with the same CRL number as
>    the base CRL.
> 
> We also need to clearly separate the issuing rules applicable for the CAs.
> These rules will certainly contain SHALL statements, but could also
include
> some MAY statements. (I let Tim/David or Russ provide the MAY statement).
> 
> Here is a proposal for the MUST statement, based on the previous text I
> produced:
> 
>    A CA that supports delta-CRLs, MUST issue a base CRL, i.e. a full
>    CRL that contains a freshestCRL extension (a.k.a. a Delta CRL
>    distribution point). For any time T until the nextUpdate time
>    indicated in a base CRL, the CA MUST provide one and only one
>    delta CRL that refers to that base CRL and for which time T
>    falls between thisUpdate and nextUpdate from the delta CRL.
> 
> In his e-mail from Wednesday, May 9, David said that delta-CRL processing
> rules could be base on time instead of CRL numbers. This is a point of
which
> I strongly agree. Let us do it!
> 
> (However, there is no need to add to PKIX, as he suggested, the support of
> the baseUpdateTime extension from X.509 which would even more complicate
the
> problem.)
> 
> Regards,
> 
> Denis

------_=_NextPart_001_01C0D96E.500FB310
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: delta CRLs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Denis:</FONT>
</P>

<P><FONT SIZE=3D2>I do not agree with you.&nbsp; Any CRL that is not a =
delta CRL (i.e., deltaCRLIndicator extension is absent), is a base CRL =
for some scope as defined in CRLScope extension and/or the IDP =
extension.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Denis Pinkas [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, May 10, 2001 12:30 PM</FONT>
<BR><FONT SIZE=3D2>To: Carlin Covey; Sharon Boeyen</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: delta CRLs</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Carlin and Sharon (at the same time),</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Denis,</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt; Now I'm confused again (or still).&nbsp; =
</FONT>
</P>

<P><FONT SIZE=3D2>:-)</FONT>
</P>

<P><FONT SIZE=3D2>&gt; I agree that there is a difference</FONT>
<BR><FONT SIZE=3D2>&gt; between a base CRL and a full CRL.&nbsp; =
However, my understanding was that a CRL</FONT>
<BR><FONT SIZE=3D2>&gt; is a &quot;base CRL&quot; with respect to some =
delta CRL only by virtue of having been</FONT>
<BR><FONT SIZE=3D2>&gt; so identified in that delta CRL. </FONT>
</P>

<P><FONT SIZE=3D2>I believe that a base CRL must include the Freshest =
CRL extension (a.k.a.</FONT>
<BR><FONT SIZE=3D2>Delta CRL Distribution Point) defined in section =
4.2.1.16. It indicates both</FONT>
<BR><FONT SIZE=3D2>that the service exists and where to fetch the =
information. It is a</FONT>
<BR><FONT SIZE=3D2>non-critical extension so that a base CRL may also =
be used as a full CL for</FONT>
<BR><FONT SIZE=3D2>relying parties not supporting delta CRLs.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; According to the PKIX profile, this base CRL =
must be a full CRL </FONT>
<BR><FONT SIZE=3D2>&gt; (complete for the intended scope).&nbsp; =
</FONT>
<BR><FONT SIZE=3D2>&gt; I believe that X.509 does not require that a =
base CRL be a full CRL.</FONT>
</P>

<P><FONT SIZE=3D2>You just say above: &quot;According to the PKIX =
profile, this base CRL must be a</FONT>
<BR><FONT SIZE=3D2>full CRL (complete for the intended scope&quot;. So =
do you mean that X.509 and</FONT>
<BR><FONT SIZE=3D2>PKIX are taking different approaches ?</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Denis</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Carlin</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; ____________________________</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -&nbsp; Carlin Covey</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; Cylink Corporation</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Denis Pinkas [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, May 10, 2001 1:19 AM</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: delta CRLs</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Tim, David, Russ, Santosh, Carlin, and many =
others ...</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; There is difference between a base CRL and a =
full CRL : a base CRL MUST</FONT>
<BR><FONT SIZE=3D2>&gt; include a freshestCRL extension (a.k.a. a Delta =
CRL distribution point),</FONT>
<BR><FONT SIZE=3D2>&gt; whereas a full CRL may not include that =
extension. In other words, a base</FONT>
<BR><FONT SIZE=3D2>&gt; CRL is a also a full CRL, but a full CRL is not =
necessarily a base CRL.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; At any time a CA may issue a full CRL, whether =
or not a base CRL has already</FONT>
<BR><FONT SIZE=3D2>&gt; been issued. This additional CRL SHOULD have =
nextUpdate equal to the</FONT>
<BR><FONT SIZE=3D2>&gt; nextUpdate of the last issued full CRL. =
However, there is no guarantee that</FONT>
<BR><FONT SIZE=3D2>&gt; this additional CRL will ever be seen by the =
relying party (because there</FONT>
<BR><FONT SIZE=3D2>&gt; will be two CRLs matching the thisUpdate and =
nextUpdate rule and if one is</FONT>
<BR><FONT SIZE=3D2>&gt; deleted, this is not seen by a relying =
party).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Due to the fact that CRLs numbers are strictly =
increasing, two CRLs whether</FONT>
<BR><FONT SIZE=3D2>&gt; they are a base CRL or delta CRL, CANNOT have =
the same CRL number. So a</FONT>
<BR><FONT SIZE=3D2>&gt; delta CRL and a full CRL that cover the same =
scope and are issued at the</FONT>
<BR><FONT SIZE=3D2>&gt; same time CANNOT have the same number. If a =
full CRL is issued, its CRL</FONT>
<BR><FONT SIZE=3D2>&gt; number bears no relationship with the previous =
base CRL, if any. The only</FONT>
<BR><FONT SIZE=3D2>&gt; relationship between the numbers is defined by =
the rule that CRLs numbers</FONT>
<BR><FONT SIZE=3D2>&gt; are strictly increasing. As Santosh said : =
&quot;the CRL number is unique</FONT>
<BR><FONT SIZE=3D2>&gt; whether it is a base or a delta &quot;.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; This is fairly important to be able to =
unambiguously (and thus uniquely)</FONT>
<BR><FONT SIZE=3D2>&gt; refer to a CRL by only providing its CRL =
number.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Besides the fact that a CRL issued later MUST =
have a higher CRL number, full</FONT>
<BR><FONT SIZE=3D2>&gt; CRLs and delta CRLs have independent numbering =
rules. As noticed by Santosh,</FONT>
<BR><FONT SIZE=3D2>&gt; &quot; if the delta thisUpdate &gt; base =
thisUpdate, delta CRL number &gt; base CRL</FONT>
<BR><FONT SIZE=3D2>&gt; number (for the same or no stream =
identifier).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; As Santosh said : &quot;a check based on =
thisUpdate is more general and</FONT>
<BR><FONT SIZE=3D2>&gt; preferred [to the use of CRL numbers]. =
&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Related to the three rules mentioned by Russ =
:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 1) the first rule is not understandable to =
me.</FONT>
<BR><FONT SIZE=3D2>&gt; 2) the second rule does not say anything more =
than the basic rule valid</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; for any CRL (i.e. a CRL =
issued later MUST have a higher CRL number).</FONT>
<BR><FONT SIZE=3D2>&gt; 3) we will debate the hold condition, once we =
will have sorted the main</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; issue.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Russ said : &quot;If separate number sequence =
is used, then you will have to</FONT>
<BR><FONT SIZE=3D2>&gt; periodically fetch base CRLs &quot;. This is =
true.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Tim said that he would *not* like to be forced =
to download new base CRLs.</FONT>
<BR><FONT SIZE=3D2>&gt; This is the core of the =
&quot;dispute&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;From the definition of what a delta CRL is, =
it is *not* possible to</FONT>
<BR><FONT SIZE=3D2>&gt; get rid of the fetching of base CRLs. Unless we =
add a new sentence to</FONT>
<BR><FONT SIZE=3D2>&gt; expand/change that definition, base CRL =
fetching will remain mandatory.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Remember that the goal of delta CRLs is to =
provide the freshest information,</FONT>
<BR><FONT SIZE=3D2>&gt; and to my knowledge the goal was not to get rid =
of the fetching of base CRLs</FONT>
<BR><FONT SIZE=3D2>&gt; (which may less frequent due to the support of =
delta CRLs).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If I understand correctly, Tim/David/Russ would =
like to *always* achieve the</FONT>
<BR><FONT SIZE=3D2>&gt; following property : it is possible to =
reconstruct the current CRL by using</FONT>
<BR><FONT SIZE=3D2>&gt; a base CRL from, e.g. 1990, i.e. by capturing =
every delta CRL that has been</FONT>
<BR><FONT SIZE=3D2>&gt; issued at the same time a base CRL was issued =
and which contains updates</FONT>
<BR><FONT SIZE=3D2>&gt; made to the *previous* base.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; By this way the fetching of base CRLs could be =
avoided. However, note that</FONT>
<BR><FONT SIZE=3D2>&gt; it is perfectly &quot; legal &quot; to stop =
issuing base and delta CRLs during some</FONT>
<BR><FONT SIZE=3D2>&gt; period of time and to issue full CRLs instead =
(see the difference between</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;full&quot; and &quot;base&quot; at the =
top of this e-mail). In other words there is no</FONT>
<BR><FONT SIZE=3D2>&gt; need to issue a new base CRL at the end of the =
validity period of the</FONT>
<BR><FONT SIZE=3D2>&gt; previous base CRL. Doing this would mandate to =
prescribe issuing rules</FONT>
<BR><FONT SIZE=3D2>&gt; for CAs that we have not prescripted.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I will now raise a series of questions, for =
which I believe we have</FONT>
<BR><FONT SIZE=3D2>&gt; different answers. Tim/David/Russ do not =
hesitate to correct</FONT>
<BR><FONT SIZE=3D2>&gt; if my guess is wrong. ;-)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Common point:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 1) What will be the value of the nextUpdate =
field from the last issued delta</FONT>
<BR><FONT SIZE=3D2>&gt; CRL for a given base CRL ?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Denis: the nextUpdate field from the last =
issued delta CRL MUST be equal to</FONT>
<BR><FONT SIZE=3D2>&gt; the value of nextUpdate from the base =
CRL.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Tim/David/Russ: ???</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 2) Does a CA needs to issue a delta CRL at the =
time a full CRL is issued ?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Denis: No.</FONT>
<BR><FONT SIZE=3D2>&gt; Tim/David/Russ : ???</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 3) Does a CA needs to issue a new base CRL at =
the end of the validity of a</FONT>
<BR><FONT SIZE=3D2>&gt; current base CRL ?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Denis: No.</FONT>
<BR><FONT SIZE=3D2>&gt; Tim/David/Russ : ???</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 4) Does a CA needs to issue a delta CRL at the =
same time a new base is</FONT>
<BR><FONT SIZE=3D2>&gt; issued ?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Denis: Yes. The delta CRL refers to the *new* =
base.</FONT>
<BR><FONT SIZE=3D2>&gt; Tim/David/Russ : Yes. The delta CRL refers to =
the *previous* base. [Note</FONT>
<BR><FONT SIZE=3D2>&gt; that there can be no previous at all, or the =
&quot;previous&quot; may even be three</FONT>
<BR><FONT SIZE=3D2>&gt; months old].</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The last point highlights the most noticeable =
difference. Other differences</FONT>
<BR><FONT SIZE=3D2>&gt; appears when considering the guaranty to get =
the freshest information :</FONT>
<BR><FONT SIZE=3D2>&gt; using the traditional scheme and the thisUpdate =
and nextUpdate fields the</FONT>
<BR><FONT SIZE=3D2>&gt; guaranty to get the freshest information is =
obtained, but cannot be obtained</FONT>
<BR><FONT SIZE=3D2>&gt; using the other scheme. :-(</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Several people are referring to the X.509 =
document for arguments to support</FONT>
<BR><FONT SIZE=3D2>&gt; that discussion. However, it is important to =
remember that we are defining</FONT>
<BR><FONT SIZE=3D2>&gt; PKIX, not X.509, so we DO NOT need to copy and =
paste everything from X.509,</FONT>
<BR><FONT SIZE=3D2>&gt; but only what we believe is relevant.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; We first need to clearly define the processing =
rules applicable to the</FONT>
<BR><FONT SIZE=3D2>&gt; relying parties. These rules will certainly =
contain SHALL/MUST statements,</FONT>
<BR><FONT SIZE=3D2>&gt; but may also include some MAY statements which =
may even be conditional to</FONT>
<BR><FONT SIZE=3D2>&gt; what the CA is doing. (I let Tim/David or Russ =
provide the MAY statement).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Here is a proposal for the MUST statement, =
based on the previous text I</FONT>
<BR><FONT SIZE=3D2>&gt; produced:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; An application that is =
wishing to take advantage of delta CRLs</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; for a given scope, MUST first =
find a base CRL for that scope,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; i.e. a full CRL that that =
contains a freshestCRL extension</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; (a.k.a. a Delta CRL =
distribution point). It may then construct</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; an updated CRL for that base, =
for a specific time T, by combining</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; it with a delta CRL which =
contains a delta CRL indicator extension</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; with the same CRL number as =
the base CRL. Applications that support</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; delta CRLs MUST ensure that =
time T falls between thisUpdate and</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; nextUpdate for both the base =
CRL and the delta CRL.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; Note: An application could =
also reconstruct an updated CRL, for</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; a specific time T, by using a =
previously locally reconstructed CRL</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; based on the current base =
CRL, and combining it with a delta CRL which</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; contains a delta CRL =
indicator extension with the same CRL number as</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; the base CRL.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; We also need to clearly separate the issuing =
rules applicable for the CAs.</FONT>
<BR><FONT SIZE=3D2>&gt; These rules will certainly contain SHALL =
statements, but could also include</FONT>
<BR><FONT SIZE=3D2>&gt; some MAY statements. (I let Tim/David or Russ =
provide the MAY statement).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Here is a proposal for the MUST statement, =
based on the previous text I</FONT>
<BR><FONT SIZE=3D2>&gt; produced:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; A CA that supports =
delta-CRLs, MUST issue a base CRL, i.e. a full</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; CRL that contains a =
freshestCRL extension (a.k.a. a Delta CRL</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; distribution point). For any =
time T until the nextUpdate time</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; indicated in a base CRL, the =
CA MUST provide one and only one</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; delta CRL that refers to that =
base CRL and for which time T</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; falls between thisUpdate and =
nextUpdate from the delta CRL.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In his e-mail from Wednesday, May 9, David said =
that delta-CRL processing</FONT>
<BR><FONT SIZE=3D2>&gt; rules could be base on time instead of CRL =
numbers. This is a point of which</FONT>
<BR><FONT SIZE=3D2>&gt; I strongly agree. Let us do it!</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; (However, there is no need to add to PKIX, as =
he suggested, the support of</FONT>
<BR><FONT SIZE=3D2>&gt; the baseUpdateTime extension from X.509 which =
would even more complicate the</FONT>
<BR><FONT SIZE=3D2>&gt; problem.)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Denis</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0D96E.500FB310--


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA13168 for <[e-mail]>; Thu, 10 May 2001 09:31:51 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA18774; Thu, 10 May 2001 18:31:51 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id SAA17312; Thu, 10 May 2001 18:31:17 +0200
Message-ID: <[e-mail]>
Date: Thu, 10 May 2001 18:29:58 +0200
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Carlin Covey <[e-mail]>, Sharon Boeyen <[e-mail]>
CC: [e-mail]
Subject: Re: delta CRLs
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Carlin and Sharon (at the same time),

> Denis,
 
> Now I'm confused again (or still).  

:-)

> I agree that there is a difference
> between a base CRL and a full CRL.  However, my understanding was that a CRL
> is a "base CRL" with respect to some delta CRL only by virtue of having been
> so identified in that delta CRL. 

I believe that a base CRL must include the Freshest CRL extension (a.k.a.
Delta CRL Distribution Point) defined in section 4.2.1.16. It indicates both
that the service exists and where to fetch the information. It is a
non-critical extension so that a base CRL may also be used as a full CL for
relying parties not supporting delta CRLs.

> According to the PKIX profile, this base CRL must be a full CRL 
> (complete for the intended scope).  
> I believe that X.509 does not require that a base CRL be a full CRL.

You just say above: "According to the PKIX profile, this base CRL must be a
full CRL (complete for the intended scope". So do you mean that X.509 and
PKIX are taking different approaches ?

Regards,

Denis

> Regards,
> 
> Carlin
> 
> ____________________________
> 
> -  Carlin Covey
>    Cylink Corporation
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Thursday, May 10, 2001 1:19 AM
> Cc: [e-mail]
> Subject: Re: delta CRLs
> 
> Tim, David, Russ, Santosh, Carlin, and many others ...
> 
> There is difference between a base CRL and a full CRL : a base CRL MUST
> include a freshestCRL extension (a.k.a. a Delta CRL distribution point),
> whereas a full CRL may not include that extension. In other words, a base
> CRL is a also a full CRL, but a full CRL is not necessarily a base CRL.
> 
> At any time a CA may issue a full CRL, whether or not a base CRL has already
> been issued. This additional CRL SHOULD have nextUpdate equal to the
> nextUpdate of the last issued full CRL. However, there is no guarantee that
> this additional CRL will ever be seen by the relying party (because there
> will be two CRLs matching the thisUpdate and nextUpdate rule and if one is
> deleted, this is not seen by a relying party).
> 
> Due to the fact that CRLs numbers are strictly increasing, two CRLs whether
> they are a base CRL or delta CRL, CANNOT have the same CRL number. So a
> delta CRL and a full CRL that cover the same scope and are issued at the
> same time CANNOT have the same number. If a full CRL is issued, its CRL
> number bears no relationship with the previous base CRL, if any. The only
> relationship between the numbers is defined by the rule that CRLs numbers
> are strictly increasing. As Santosh said : "the CRL number is unique
> whether it is a base or a delta ".
> 
> This is fairly important to be able to unambiguously (and thus uniquely)
> refer to a CRL by only providing its CRL number.
> 
> Besides the fact that a CRL issued later MUST have a higher CRL number, full
> CRLs and delta CRLs have independent numbering rules. As noticed by Santosh,
> " if the delta thisUpdate > base thisUpdate, delta CRL number > base CRL
> number (for the same or no stream identifier).
> 
> As Santosh said : "a check based on thisUpdate is more general and
> preferred [to the use of CRL numbers]. "
> 
> Related to the three rules mentioned by Russ :
> 
> 1) the first rule is not understandable to me.
> 2) the second rule does not say anything more than the basic rule valid
>    for any CRL (i.e. a CRL issued later MUST have a higher CRL number).
> 3) we will debate the hold condition, once we will have sorted the main
>    issue.
> 
> Russ said : "If separate number sequence is used, then you will have to
> periodically fetch base CRLs ". This is true.
> 
> Tim said that he would *not* like to be forced to download new base CRLs.
> This is the core of the "dispute".
> 
> >From the definition of what a delta CRL is, it is *not* possible to
> get rid of the fetching of base CRLs. Unless we add a new sentence to
> expand/change that definition, base CRL fetching will remain mandatory.
> 
> Remember that the goal of delta CRLs is to provide the freshest information,
> and to my knowledge the goal was not to get rid of the fetching of base CRLs
> (which may less frequent due to the support of delta CRLs).
> 
> If I understand correctly, Tim/David/Russ would like to *always* achieve the
> following property : it is possible to reconstruct the current CRL by using
> a base CRL from, e.g. 1990, i.e. by capturing every delta CRL that has been
> issued at the same time a base CRL was issued and which contains updates
> made to the *previous* base.
> 
> By this way the fetching of base CRLs could be avoided. However, note that
> it is perfectly " legal " to stop issuing base and delta CRLs during some
> period of time and to issue full CRLs instead (see the difference between
> "full" and "base" at the top of this e-mail). In other words there is no
> need to issue a new base CRL at the end of the validity period of the
> previous base CRL. Doing this would mandate to prescribe issuing rules
> for CAs that we have not prescripted.
> 
> I will now raise a series of questions, for which I believe we have
> different answers. Tim/David/Russ do not hesitate to correct
> if my guess is wrong. ;-)
> 
> Common point:
> 
> 1) What will be the value of the nextUpdate field from the last issued delta
> CRL for a given base CRL ?
> 
> Denis: the nextUpdate field from the last issued delta CRL MUST be equal to
> the value of nextUpdate from the base CRL.
> 
> Tim/David/Russ: ???
> 
> 2) Does a CA needs to issue a delta CRL at the time a full CRL is issued ?
> 
> Denis: No.
> Tim/David/Russ : ???
> 
> 3) Does a CA needs to issue a new base CRL at the end of the validity of a
> current base CRL ?
> 
> Denis: No.
> Tim/David/Russ : ???
> 
> 4) Does a CA needs to issue a delta CRL at the same time a new base is
> issued ?
> 
> Denis: Yes. The delta CRL refers to the *new* base.
> Tim/David/Russ : Yes. The delta CRL refers to the *previous* base. [Note
> that there can be no previous at all, or the "previous" may even be three
> months old].
> 
> The last point highlights the most noticeable difference. Other differences
> appears when considering the guaranty to get the freshest information :
> using the traditional scheme and the thisUpdate and nextUpdate fields the
> guaranty to get the freshest information is obtained, but cannot be obtained
> using the other scheme. :-(
> 
> Several people are referring to the X.509 document for arguments to support
> that discussion. However, it is important to remember that we are defining
> PKIX, not X.509, so we DO NOT need to copy and paste everything from X.509,
> but only what we believe is relevant.
> 
> We first need to clearly define the processing rules applicable to the
> relying parties. These rules will certainly contain SHALL/MUST statements,
> but may also include some MAY statements which may even be conditional to
> what the CA is doing. (I let Tim/David or Russ provide the MAY statement).
> 
> Here is a proposal for the MUST statement, based on the previous text I
> produced:
> 
>    An application that is wishing to take advantage of delta CRLs
>    for a given scope, MUST first find a base CRL for that scope,
>    i.e. a full CRL that that contains a freshestCRL extension
>    (a.k.a. a Delta CRL distribution point). It may then construct
>    an updated CRL for that base, for a specific time T, by combining
>    it with a delta CRL which contains a delta CRL indicator extension
>    with the same CRL number as the base CRL. Applications that support
>    delta CRLs MUST ensure that time T falls between thisUpdate and
>    nextUpdate for both the base CRL and the delta CRL.
> 
>    Note: An application could also reconstruct an updated CRL, for
>    a specific time T, by using a previously locally reconstructed CRL
>    based on the current base CRL, and combining it with a delta CRL which
>    contains a delta CRL indicator extension with the same CRL number as
>    the base CRL.
> 
> We also need to clearly separate the issuing rules applicable for the CAs.
> These rules will certainly contain SHALL statements, but could also include
> some MAY statements. (I let Tim/David or Russ provide the MAY statement).
> 
> Here is a proposal for the MUST statement, based on the previous text I
> produced:
> 
>    A CA that supports delta-CRLs, MUST issue a base CRL, i.e. a full
>    CRL that contains a freshestCRL extension (a.k.a. a Delta CRL
>    distribution point). For any time T until the nextUpdate time
>    indicated in a base CRL, the CA MUST provide one and only one
>    delta CRL that refers to that base CRL and for which time T
>    falls between thisUpdate and nextUpdate from the delta CRL.
> 
> In his e-mail from Wednesday, May 9, David said that delta-CRL processing
> rules could be base on time instead of CRL numbers. This is a point of which
> I strongly agree. Let us do it!
> 
> (However, there is no need to add to PKIX, as he suggested, the support of
> the baseUpdateTime extension from X.509 which would even more complicate the
> problem.)
> 
> Regards,
> 
> Denis


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA12720 for <[e-mail]>; Thu, 10 May 2001 09:28:53 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <K4X9NJX3>; Thu, 10 May 2001 12:28:23 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Carlin Covey <[e-mail]>, Denis Pinkas <[e-mail]>
Cc: [e-mail]
Subject: RE: delta CRLs
Date: Thu, 10 May 2001 12:19:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D96C.F12AC020"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D96C.F12AC020
Content-Type: text/plain;
	charset="iso-8859-1"

I agree with Carlin on difference between base and full.

-----Original Message-----
From: Carlin Covey [mailto:[e-mail]]
Sent: Thursday, May 10, 2001 12:08 PM
To: Denis Pinkas
Cc: [e-mail]
Subject: RE: delta CRLs


Denis,

Now I'm confused again (or still).  I agree that there is a difference
between a base CRL and a full CRL.  However, my understanding was that a CRL
is a "base CRL" with respect to some delta CRL only by virtue of having been
so identified in that delta CRL.  According to the PKIX profile, this base
CRL must be a full CRL (complete for the intended scope).  I believe that
X.509 does not require that a base CRL be a full CRL.

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Thursday, May 10, 2001 1:19 AM
Cc: [e-mail]
Subject: Re: delta CRLs


Tim, David, Russ, Santosh, Carlin, and many others ...

There is difference between a base CRL and a full CRL : a base CRL MUST
include a freshestCRL extension (a.k.a. a Delta CRL distribution point),
whereas a full CRL may not include that extension. In other words, a base
CRL is a also a full CRL, but a full CRL is not necessarily a base CRL.

At any time a CA may issue a full CRL, whether or not a base CRL has already
been issued. This additional CRL SHOULD have nextUpdate equal to the
nextUpdate of the last issued full CRL. However, there is no guarantee that
this additional CRL will ever be seen by the relying party (because there
will be two CRLs matching the thisUpdate and nextUpdate rule and if one is
deleted, this is not seen by a relying party).

Due to the fact that CRLs numbers are strictly increasing, two CRLs whether
they are a base CRL or delta CRL, CANNOT have the same CRL number. So a
delta CRL and a full CRL that cover the same scope and are issued at the
same time CANNOT have the same number. If a full CRL is issued, its CRL
number bears no relationship with the previous base CRL, if any. The only
relationship between the numbers is defined by the rule that CRLs numbers
are strictly increasing. As Santosh said : "the CRL number is unique
whether it is a base or a delta ".

This is fairly important to be able to unambiguously (and thus uniquely)
refer to a CRL by only providing its CRL number.

Besides the fact that a CRL issued later MUST have a higher CRL number, full
CRLs and delta CRLs have independent numbering rules. As noticed by Santosh,
" if the delta thisUpdate > base thisUpdate, delta CRL number > base CRL
number (for the same or no stream identifier).

As Santosh said : "a check based on thisUpdate is more general and
preferred [to the use of CRL numbers]. "

Related to the three rules mentioned by Russ :

1) the first rule is not understandable to me.
2) the second rule does not say anything more than the basic rule valid
   for any CRL (i.e. a CRL issued later MUST have a higher CRL number).
3) we will debate the hold condition, once we will have sorted the main
   issue.

Russ said : "If separate number sequence is used, then you will have to
periodically fetch base CRLs ". This is true.

Tim said that he would *not* like to be forced to download new base CRLs.
This is the core of the "dispute".

>From the definition of what a delta CRL is, it is *not* possible to
get rid of the fetching of base CRLs. Unless we add a new sentence to
expand/change that definition, base CRL fetching will remain mandatory.

Remember that the goal of delta CRLs is to provide the freshest information,
and to my knowledge the goal was not to get rid of the fetching of base CRLs
(which may less frequent due to the support of delta CRLs).

If I understand correctly, Tim/David/Russ would like to *always* achieve the
following property : it is possible to reconstruct the current CRL by using
a base CRL from, e.g. 1990, i.e. by capturing every delta CRL that has been
issued at the same time a base CRL was issued and which contains updates
made to the *previous* base.

By this way the fetching of base CRLs could be avoided. However, note that
it is perfectly " legal " to stop issuing base and delta CRLs during some
period of time and to issue full CRLs instead (see the difference between
"full" and "base" at the top of this e-mail). In other words there is no
need to issue a new base CRL at the end of the validity period of the
previous base CRL. Doing this would mandate to prescribe issuing rules
for CAs that we have not prescripted.

I will now raise a series of questions, for which I believe we have
different answers. Tim/David/Russ do not hesitate to correct
if my guess is wrong. ;-)

Common point:

1) What will be the value of the nextUpdate field from the last issued delta
CRL for a given base CRL ?

Denis: the nextUpdate field from the last issued delta CRL MUST be equal to
the value of nextUpdate from the base CRL.

Tim/David/Russ: ???

2) Does a CA needs to issue a delta CRL at the time a full CRL is issued ?

Denis: No.
Tim/David/Russ : ???

3) Does a CA needs to issue a new base CRL at the end of the validity of a
current base CRL ?

Denis: No.
Tim/David/Russ : ???

4) Does a CA needs to issue a delta CRL at the same time a new base is
issued ?

Denis: Yes. The delta CRL refers to the *new* base.
Tim/David/Russ : Yes. The delta CRL refers to the *previous* base. [Note
that there can be no previous at all, or the "previous" may even be three
months old].

The last point highlights the most noticeable difference. Other differences
appears when considering the guaranty to get the freshest information :
using the traditional scheme and the thisUpdate and nextUpdate fields the
guaranty to get the freshest information is obtained, but cannot be obtained
using the other scheme. :-(

Several people are referring to the X.509 document for arguments to support
that discussion. However, it is important to remember that we are defining
PKIX, not X.509, so we DO NOT need to copy and paste everything from X.509,
but only what we believe is relevant.

We first need to clearly define the processing rules applicable to the
relying parties. These rules will certainly contain SHALL/MUST statements,
but may also include some MAY statements which may even be conditional to
what the CA is doing. (I let Tim/David or Russ provide the MAY statement).

Here is a proposal for the MUST statement, based on the previous text I
produced:

   An application that is wishing to take advantage of delta CRLs
   for a given scope, MUST first find a base CRL for that scope,
   i.e. a full CRL that that contains a freshestCRL extension
   (a.k.a. a Delta CRL distribution point). It may then construct
   an updated CRL for that base, for a specific time T, by combining
   it with a delta CRL which contains a delta CRL indicator extension
   with the same CRL number as the base CRL. Applications that support
   delta CRLs MUST ensure that time T falls between thisUpdate and
   nextUpdate for both the base CRL and the delta CRL.

   Note: An application could also reconstruct an updated CRL, for
   a specific time T, by using a previously locally reconstructed CRL
   based on the current base CRL, and combining it with a delta CRL which
   contains a delta CRL indicator extension with the same CRL number as
   the base CRL.

We also need to clearly separate the issuing rules applicable for the CAs.
These rules will certainly contain SHALL statements, but could also include
some MAY statements. (I let Tim/David or Russ provide the MAY statement).

Here is a proposal for the MUST statement, based on the previous text I
produced:

   A CA that supports delta-CRLs, MUST issue a base CRL, i.e. a full
   CRL that contains a freshestCRL extension (a.k.a. a Delta CRL
   distribution point). For any time T until the nextUpdate time
   indicated in a base CRL, the CA MUST provide one and only one
   delta CRL that refers to that base CRL and for which time T
   falls between thisUpdate and nextUpdate from the delta CRL.

In his e-mail from Wednesday, May 9, David said that delta-CRL processing
rules could be base on time instead of CRL numbers. This is a point of which
I strongly agree. Let us do it!

(However, there is no need to add to PKIX, as he suggested, the support of
the baseUpdateTime extension from X.509 which would even more complicate the
problem.)

Regards,

Denis

------_=_NextPart_001_01C0D96C.F12AC020
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: delta CRLs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>I agree with Carlin on difference between base and full.</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Carlin Covey [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>Sent: Thursday, May 10, 2001 12:08 PM</FONT>
<BR><FONT SIZE=2>To: Denis Pinkas</FONT>
<BR><FONT SIZE=2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=2>Subject: RE: delta CRLs</FONT>
</P>
<BR>

<P><FONT SIZE=2>Denis,</FONT>
</P>

<P><FONT SIZE=2>Now I'm confused again (or still).&nbsp; I agree that there is a difference</FONT>
<BR><FONT SIZE=2>between a base CRL and a full CRL.&nbsp; However, my understanding was that a CRL</FONT>
<BR><FONT SIZE=2>is a &quot;base CRL&quot; with respect to some delta CRL only by virtue of having been</FONT>
<BR><FONT SIZE=2>so identified in that delta CRL.&nbsp; According to the PKIX profile, this base</FONT>
<BR><FONT SIZE=2>CRL must be a full CRL (complete for the intended scope).&nbsp; I believe that</FONT>
<BR><FONT SIZE=2>X.509 does not require that a base CRL be a full CRL.</FONT>
</P>

<P><FONT SIZE=2>Regards,</FONT>
</P>

<P><FONT SIZE=2>Carlin</FONT>
</P>

<P><FONT SIZE=2>____________________________</FONT>
</P>

<P><FONT SIZE=2>-&nbsp; Carlin Covey</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; Cylink Corporation</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Denis Pinkas [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>Sent: Thursday, May 10, 2001 1:19 AM</FONT>
<BR><FONT SIZE=2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=2>Subject: Re: delta CRLs</FONT>
</P>
<BR>

<P><FONT SIZE=2>Tim, David, Russ, Santosh, Carlin, and many others ...</FONT>
</P>

<P><FONT SIZE=2>There is difference between a base CRL and a full CRL : a base CRL MUST</FONT>
<BR><FONT SIZE=2>include a freshestCRL extension (a.k.a. a Delta CRL distribution point),</FONT>
<BR><FONT SIZE=2>whereas a full CRL may not include that extension. In other words, a base</FONT>
<BR><FONT SIZE=2>CRL is a also a full CRL, but a full CRL is not necessarily a base CRL.</FONT>
</P>

<P><FONT SIZE=2>At any time a CA may issue a full CRL, whether or not a base CRL has already</FONT>
<BR><FONT SIZE=2>been issued. This additional CRL SHOULD have nextUpdate equal to the</FONT>
<BR><FONT SIZE=2>nextUpdate of the last issued full CRL. However, there is no guarantee that</FONT>
<BR><FONT SIZE=2>this additional CRL will ever be seen by the relying party (because there</FONT>
<BR><FONT SIZE=2>will be two CRLs matching the thisUpdate and nextUpdate rule and if one is</FONT>
<BR><FONT SIZE=2>deleted, this is not seen by a relying party).</FONT>
</P>

<P><FONT SIZE=2>Due to the fact that CRLs numbers are strictly increasing, two CRLs whether</FONT>
<BR><FONT SIZE=2>they are a base CRL or delta CRL, CANNOT have the same CRL number. So a</FONT>
<BR><FONT SIZE=2>delta CRL and a full CRL that cover the same scope and are issued at the</FONT>
<BR><FONT SIZE=2>same time CANNOT have the same number. If a full CRL is issued, its CRL</FONT>
<BR><FONT SIZE=2>number bears no relationship with the previous base CRL, if any. The only</FONT>
<BR><FONT SIZE=2>relationship between the numbers is defined by the rule that CRLs numbers</FONT>
<BR><FONT SIZE=2>are strictly increasing. As Santosh said : &quot;the CRL number is unique</FONT>
<BR><FONT SIZE=2>whether it is a base or a delta &quot;.</FONT>
</P>

<P><FONT SIZE=2>This is fairly important to be able to unambiguously (and thus uniquely)</FONT>
<BR><FONT SIZE=2>refer to a CRL by only providing its CRL number.</FONT>
</P>

<P><FONT SIZE=2>Besides the fact that a CRL issued later MUST have a higher CRL number, full</FONT>
<BR><FONT SIZE=2>CRLs and delta CRLs have independent numbering rules. As noticed by Santosh,</FONT>
<BR><FONT SIZE=2>&quot; if the delta thisUpdate &gt; base thisUpdate, delta CRL number &gt; base CRL</FONT>
<BR><FONT SIZE=2>number (for the same or no stream identifier).</FONT>
</P>

<P><FONT SIZE=2>As Santosh said : &quot;a check based on thisUpdate is more general and</FONT>
<BR><FONT SIZE=2>preferred [to the use of CRL numbers]. &quot;</FONT>
</P>

<P><FONT SIZE=2>Related to the three rules mentioned by Russ :</FONT>
</P>

<P><FONT SIZE=2>1) the first rule is not understandable to me.</FONT>
<BR><FONT SIZE=2>2) the second rule does not say anything more than the basic rule valid</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; for any CRL (i.e. a CRL issued later MUST have a higher CRL number).</FONT>
<BR><FONT SIZE=2>3) we will debate the hold condition, once we will have sorted the main</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; issue.</FONT>
</P>

<P><FONT SIZE=2>Russ said : &quot;If separate number sequence is used, then you will have to</FONT>
<BR><FONT SIZE=2>periodically fetch base CRLs &quot;. This is true.</FONT>
</P>

<P><FONT SIZE=2>Tim said that he would *not* like to be forced to download new base CRLs.</FONT>
<BR><FONT SIZE=2>This is the core of the &quot;dispute&quot;.</FONT>
</P>

<P><FONT SIZE=2>From the definition of what a delta CRL is, it is *not* possible to</FONT>
<BR><FONT SIZE=2>get rid of the fetching of base CRLs. Unless we add a new sentence to</FONT>
<BR><FONT SIZE=2>expand/change that definition, base CRL fetching will remain mandatory.</FONT>
</P>

<P><FONT SIZE=2>Remember that the goal of delta CRLs is to provide the freshest information,</FONT>
<BR><FONT SIZE=2>and to my knowledge the goal was not to get rid of the fetching of base CRLs</FONT>
<BR><FONT SIZE=2>(which may less frequent due to the support of delta CRLs).</FONT>
</P>

<P><FONT SIZE=2>If I understand correctly, Tim/David/Russ would like to *always* achieve the</FONT>
<BR><FONT SIZE=2>following property : it is possible to reconstruct the current CRL by using</FONT>
<BR><FONT SIZE=2>a base CRL from, e.g. 1990, i.e. by capturing every delta CRL that has been</FONT>
<BR><FONT SIZE=2>issued at the same time a base CRL was issued and which contains updates</FONT>
<BR><FONT SIZE=2>made to the *previous* base.</FONT>
</P>

<P><FONT SIZE=2>By this way the fetching of base CRLs could be avoided. However, note that</FONT>
<BR><FONT SIZE=2>it is perfectly &quot; legal &quot; to stop issuing base and delta CRLs during some</FONT>
<BR><FONT SIZE=2>period of time and to issue full CRLs instead (see the difference between</FONT>
<BR><FONT SIZE=2>&quot;full&quot; and &quot;base&quot; at the top of this e-mail). In other words there is no</FONT>
<BR><FONT SIZE=2>need to issue a new base CRL at the end of the validity period of the</FONT>
<BR><FONT SIZE=2>previous base CRL. Doing this would mandate to prescribe issuing rules</FONT>
<BR><FONT SIZE=2>for CAs that we have not prescripted.</FONT>
</P>

<P><FONT SIZE=2>I will now raise a series of questions, for which I believe we have</FONT>
<BR><FONT SIZE=2>different answers. Tim/David/Russ do not hesitate to correct</FONT>
<BR><FONT SIZE=2>if my guess is wrong. ;-)</FONT>
</P>

<P><FONT SIZE=2>Common point:</FONT>
</P>

<P><FONT SIZE=2>1) What will be the value of the nextUpdate field from the last issued delta</FONT>
<BR><FONT SIZE=2>CRL for a given base CRL ?</FONT>
</P>

<P><FONT SIZE=2>Denis: the nextUpdate field from the last issued delta CRL MUST be equal to</FONT>
<BR><FONT SIZE=2>the value of nextUpdate from the base CRL.</FONT>
</P>

<P><FONT SIZE=2>Tim/David/Russ: ???</FONT>
</P>

<P><FONT SIZE=2>2) Does a CA needs to issue a delta CRL at the time a full CRL is issued ?</FONT>
</P>

<P><FONT SIZE=2>Denis: No.</FONT>
<BR><FONT SIZE=2>Tim/David/Russ : ???</FONT>
</P>

<P><FONT SIZE=2>3) Does a CA needs to issue a new base CRL at the end of the validity of a</FONT>
<BR><FONT SIZE=2>current base CRL ?</FONT>
</P>

<P><FONT SIZE=2>Denis: No.</FONT>
<BR><FONT SIZE=2>Tim/David/Russ : ???</FONT>
</P>

<P><FONT SIZE=2>4) Does a CA needs to issue a delta CRL at the same time a new base is</FONT>
<BR><FONT SIZE=2>issued ?</FONT>
</P>

<P><FONT SIZE=2>Denis: Yes. The delta CRL refers to the *new* base.</FONT>
<BR><FONT SIZE=2>Tim/David/Russ : Yes. The delta CRL refers to the *previous* base. [Note</FONT>
<BR><FONT SIZE=2>that there can be no previous at all, or the &quot;previous&quot; may even be three</FONT>
<BR><FONT SIZE=2>months old].</FONT>
</P>

<P><FONT SIZE=2>The last point highlights the most noticeable difference. Other differences</FONT>
<BR><FONT SIZE=2>appears when considering the guaranty to get the freshest information :</FONT>
<BR><FONT SIZE=2>using the traditional scheme and the thisUpdate and nextUpdate fields the</FONT>
<BR><FONT SIZE=2>guaranty to get the freshest information is obtained, but cannot be obtained</FONT>
<BR><FONT SIZE=2>using the other scheme. :-(</FONT>
</P>

<P><FONT SIZE=2>Several people are referring to the X.509 document for arguments to support</FONT>
<BR><FONT SIZE=2>that discussion. However, it is important to remember that we are defining</FONT>
<BR><FONT SIZE=2>PKIX, not X.509, so we DO NOT need to copy and paste everything from X.509,</FONT>
<BR><FONT SIZE=2>but only what we believe is relevant.</FONT>
</P>

<P><FONT SIZE=2>We first need to clearly define the processing rules applicable to the</FONT>
<BR><FONT SIZE=2>relying parties. These rules will certainly contain SHALL/MUST statements,</FONT>
<BR><FONT SIZE=2>but may also include some MAY statements which may even be conditional to</FONT>
<BR><FONT SIZE=2>what the CA is doing. (I let Tim/David or Russ provide the MAY statement).</FONT>
</P>

<P><FONT SIZE=2>Here is a proposal for the MUST statement, based on the previous text I</FONT>
<BR><FONT SIZE=2>produced:</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; An application that is wishing to take advantage of delta CRLs</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; for a given scope, MUST first find a base CRL for that scope,</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; i.e. a full CRL that that contains a freshestCRL extension</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; (a.k.a. a Delta CRL distribution point). It may then construct</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; an updated CRL for that base, for a specific time T, by combining</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; it with a delta CRL which contains a delta CRL indicator extension</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; with the same CRL number as the base CRL. Applications that support</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; delta CRLs MUST ensure that time T falls between thisUpdate and</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; nextUpdate for both the base CRL and the delta CRL.</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; Note: An application could also reconstruct an updated CRL, for</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; a specific time T, by using a previously locally reconstructed CRL</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; based on the current base CRL, and combining it with a delta CRL which</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; contains a delta CRL indicator extension with the same CRL number as</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; the base CRL.</FONT>
</P>

<P><FONT SIZE=2>We also need to clearly separate the issuing rules applicable for the CAs.</FONT>
<BR><FONT SIZE=2>These rules will certainly contain SHALL statements, but could also include</FONT>
<BR><FONT SIZE=2>some MAY statements. (I let Tim/David or Russ provide the MAY statement).</FONT>
</P>

<P><FONT SIZE=2>Here is a proposal for the MUST statement, based on the previous text I</FONT>
<BR><FONT SIZE=2>produced:</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; A CA that supports delta-CRLs, MUST issue a base CRL, i.e. a full</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; CRL that contains a freshestCRL extension (a.k.a. a Delta CRL</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; distribution point). For any time T until the nextUpdate time</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; indicated in a base CRL, the CA MUST provide one and only one</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; delta CRL that refers to that base CRL and for which time T</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; falls between thisUpdate and nextUpdate from the delta CRL.</FONT>
</P>

<P><FONT SIZE=2>In his e-mail from Wednesday, May 9, David said that delta-CRL processing</FONT>
<BR><FONT SIZE=2>rules could be base on time instead of CRL numbers. This is a point of which</FONT>
<BR><FONT SIZE=2>I strongly agree. Let us do it!</FONT>
</P>

<P><FONT SIZE=2>(However, there is no need to add to PKIX, as he suggested, the support of</FONT>
<BR><FONT SIZE=2>the baseUpdateTime extension from X.509 which would even more complicate the</FONT>
<BR><FONT SIZE=2>problem.)</FONT>
</P>

<P><FONT SIZE=2>Regards,</FONT>
</P>

<P><FONT SIZE=2>Denis</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0D96C.F12AC020--


Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA11179 for <[e-mail]>; Thu, 10 May 2001 09:08:46 -0700 (PDT)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KVA79RPM; Thu, 10 May 2001 09:02:41 -0700
From: "Carlin Covey" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: delta CRLs
Date: Thu, 10 May 2001 09:07:43 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

Denis,

Now I'm confused again (or still).  I agree that there is a difference
between a base CRL and a full CRL.  However, my understanding was that a CRL
is a "base CRL" with respect to some delta CRL only by virtue of having been
so identified in that delta CRL.  According to the PKIX profile, this base
CRL must be a full CRL (complete for the intended scope).  I believe that
X.509 does not require that a base CRL be a full CRL.

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Thursday, May 10, 2001 1:19 AM
Cc: [e-mail]
Subject: Re: delta CRLs


Tim, David, Russ, Santosh, Carlin, and many others ...

There is difference between a base CRL and a full CRL : a base CRL MUST
include a freshestCRL extension (a.k.a. a Delta CRL distribution point),
whereas a full CRL may not include that extension. In other words, a base
CRL is a also a full CRL, but a full CRL is not necessarily a base CRL.

At any time a CA may issue a full CRL, whether or not a base CRL has already
been issued. This additional CRL SHOULD have nextUpdate equal to the
nextUpdate of the last issued full CRL. However, there is no guarantee that
this additional CRL will ever be seen by the relying party (because there
will be two CRLs matching the thisUpdate and nextUpdate rule and if one is
deleted, this is not seen by a relying party).

Due to the fact that CRLs numbers are strictly increasing, two CRLs whether
they are a base CRL or delta CRL, CANNOT have the same CRL number. So a
delta CRL and a full CRL that cover the same scope and are issued at the
same time CANNOT have the same number. If a full CRL is issued, its CRL
number bears no relationship with the previous base CRL, if any. The only
relationship between the numbers is defined by the rule that CRLs numbers
are strictly increasing. As Santosh said : "the CRL number is unique
whether it is a base or a delta ".

This is fairly important to be able to unambiguously (and thus uniquely)
refer to a CRL by only providing its CRL number.

Besides the fact that a CRL issued later MUST have a higher CRL number, full
CRLs and delta CRLs have independent numbering rules. As noticed by Santosh,
" if the delta thisUpdate > base thisUpdate, delta CRL number > base CRL
number (for the same or no stream identifier).

As Santosh said : "a check based on thisUpdate is more general and
preferred [to the use of CRL numbers]. "

Related to the three rules mentioned by Russ :

1) the first rule is not understandable to me.
2) the second rule does not say anything more than the basic rule valid
   for any CRL (i.e. a CRL issued later MUST have a higher CRL number).
3) we will debate the hold condition, once we will have sorted the main
   issue.

Russ said : "If separate number sequence is used, then you will have to
periodically fetch base CRLs ". This is true.

Tim said that he would *not* like to be forced to download new base CRLs.
This is the core of the "dispute".

>From the definition of what a delta CRL is, it is *not* possible to
get rid of the fetching of base CRLs. Unless we add a new sentence to
expand/change that definition, base CRL fetching will remain mandatory.

Remember that the goal of delta CRLs is to provide the freshest information,
and to my knowledge the goal was not to get rid of the fetching of base CRLs
(which may less frequent due to the support of delta CRLs).

If I understand correctly, Tim/David/Russ would like to *always* achieve the
following property : it is possible to reconstruct the current CRL by using
a base CRL from, e.g. 1990, i.e. by capturing every delta CRL that has been
issued at the same time a base CRL was issued and which contains updates
made to the *previous* base.

By this way the fetching of base CRLs could be avoided. However, note that
it is perfectly " legal " to stop issuing base and delta CRLs during some
period of time and to issue full CRLs instead (see the difference between
"full" and "base" at the top of this e-mail). In other words there is no
need to issue a new base CRL at the end of the validity period of the
previous base CRL. Doing this would mandate to prescribe issuing rules
for CAs that we have not prescripted.

I will now raise a series of questions, for which I believe we have
different answers. Tim/David/Russ do not hesitate to correct
if my guess is wrong. ;-)

Common point:

1) What will be the value of the nextUpdate field from the last issued delta
CRL for a given base CRL ?

Denis: the nextUpdate field from the last issued delta CRL MUST be equal to
the value of nextUpdate from the base CRL.

Tim/David/Russ: ???

2) Does a CA needs to issue a delta CRL at the time a full CRL is issued ?

Denis: No.
Tim/David/Russ : ???

3) Does a CA needs to issue a new base CRL at the end of the validity of a
current base CRL ?

Denis: No.
Tim/David/Russ : ???

4) Does a CA needs to issue a delta CRL at the same time a new base is
issued ?

Denis: Yes. The delta CRL refers to the *new* base.
Tim/David/Russ : Yes. The delta CRL refers to the *previous* base. [Note
that there can be no previous at all, or the "previous" may even be three
months old].

The last point highlights the most noticeable difference. Other differences
appears when considering the guaranty to get the freshest information :
using the traditional scheme and the thisUpdate and nextUpdate fields the
guaranty to get the freshest information is obtained, but cannot be obtained
using the other scheme. :-(

Several people are referring to the X.509 document for arguments to support
that discussion. However, it is important to remember that we are defining
PKIX, not X.509, so we DO NOT need to copy and paste everything from X.509,
but only what we believe is relevant.

We first need to clearly define the processing rules applicable to the
relying parties. These rules will certainly contain SHALL/MUST statements,
but may also include some MAY statements which may even be conditional to
what the CA is doing. (I let Tim/David or Russ provide the MAY statement).

Here is a proposal for the MUST statement, based on the previous text I
produced:

   An application that is wishing to take advantage of delta CRLs
   for a given scope, MUST first find a base CRL for that scope,
   i.e. a full CRL that that contains a freshestCRL extension
   (a.k.a. a Delta CRL distribution point). It may then construct
   an updated CRL for that base, for a specific time T, by combining
   it with a delta CRL which contains a delta CRL indicator extension
   with the same CRL number as the base CRL. Applications that support
   delta CRLs MUST ensure that time T falls between thisUpdate and
   nextUpdate for both the base CRL and the delta CRL.

   Note: An application could also reconstruct an updated CRL, for
   a specific time T, by using a previously locally reconstructed CRL
   based on the current base CRL, and combining it with a delta CRL which
   contains a delta CRL indicator extension with the same CRL number as
   the base CRL.

We also need to clearly separate the issuing rules applicable for the CAs.
These rules will certainly contain SHALL statements, but could also include
some MAY statements. (I let Tim/David or Russ provide the MAY statement).

Here is a proposal for the MUST statement, based on the previous text I
produced:

   A CA that supports delta-CRLs, MUST issue a base CRL, i.e. a full
   CRL that contains a freshestCRL extension (a.k.a. a Delta CRL
   distribution point). For any time T until the nextUpdate time
   indicated in a base CRL, the CA MUST provide one and only one
   delta CRL that refers to that base CRL and for which time T
   falls between thisUpdate and nextUpdate from the delta CRL.

In his e-mail from Wednesday, May 9, David said that delta-CRL processing
rules could be base on time instead of CRL numbers. This is a point of which
I strongly agree. Let us do it!

(However, there is no need to add to PKIX, as he suggested, the support of
the baseUpdateTime extension from X.509 which would even more complicate the
problem.)

Regards,

Denis



Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA10128 for <[e-mail]>; Thu, 10 May 2001 08:59:20 -0700 (PDT)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <J432YV27>; Thu, 10 May 2001 11:58:51 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: Santosh Chokhani <[e-mail]>, Denis Pinkas <[e-mail]>
Cc: [e-mail]
Subject: RE: delta CRLs
Date: Thu, 10 May 2001 11:58:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D96A.1992B660"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D96A.1992B660
Content-Type: text/plain;
	charset="iso-8859-1"

As for 509, Santosh is correct. Freshest CRL is not required.

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Thursday, May 10, 2001 10:29 AM
To: Denis Pinkas
Cc: [e-mail]
Subject: RE: delta CRLs



Denis: 

Since you did not ask me the questions, I will NOT answer them. 

In general, my reading of the standard is that a base CRL need not have
freshest CRL extension in it. 

-----Original Message----- 
From: Denis Pinkas [ mailto:[e-mail]
<mailto:[e-mail]> ] 
Sent: Thursday, May 10, 2001 4:19 AM 
Cc: [e-mail] 
Subject: Re: delta CRLs 


Tim, David, Russ, Santosh, Carlin, and many others ... 

There is difference between a base CRL and a full CRL : a base CRL MUST 
include a freshestCRL extension (a.k.a. a Delta CRL distribution point), 
whereas a full CRL may not include that extension. In other words, a base 
CRL is a also a full CRL, but a full CRL is not necessarily a base CRL. 

At any time a CA may issue a full CRL, whether or not a base CRL has already

been issued. This additional CRL SHOULD have nextUpdate equal to the 
nextUpdate of the last issued full CRL. However, there is no guarantee that 
this additional CRL will ever be seen by the relying party (because there 
will be two CRLs matching the thisUpdate and nextUpdate rule and if one is 
deleted, this is not seen by a relying party). 

Due to the fact that CRLs numbers are strictly increasing, two CRLs whether 
they are a base CRL or delta CRL, CANNOT have the same CRL number. So a 
delta CRL and a full CRL that cover the same scope and are issued at the 
same time CANNOT have the same number. If a full CRL is issued, its CRL 
number bears no relationship with the previous base CRL, if any. The only 
relationship between the numbers is defined by the rule that CRLs numbers 
are strictly increasing. As Santosh said : "the CRL number is unique 
whether it is a base or a delta ". 

This is fairly important to be able to unambiguously (and thus uniquely) 
refer to a CRL by only providing its CRL number. 

Besides the fact that a CRL issued later MUST have a higher CRL number, full

CRLs and delta CRLs have independent numbering rules. As noticed by Santosh,

" if the delta thisUpdate > base thisUpdate, delta CRL number > base CRL 
number (for the same or no stream identifier). 

As Santosh said : "a check based on thisUpdate is more general and 
preferred [to the use of CRL numbers]. " 

Related to the three rules mentioned by Russ : 

1) the first rule is not understandable to me. 
2) the second rule does not say anything more than the basic rule valid 
   for any CRL (i.e. a CRL issued later MUST have a higher CRL number). 
3) we will debate the hold condition, once we will have sorted the main 
   issue. 

Russ said : "If separate number sequence is used, then you will have to 
periodically fetch base CRLs ". This is true. 

Tim said that he would *not* like to be forced to download new base CRLs. 
This is the core of the "dispute". 

>From the definition of what a delta CRL is, it is *not* possible to 
get rid of the fetching of base CRLs. Unless we add a new sentence to 
expand/change that definition, base CRL fetching will remain mandatory. 

Remember that the goal of delta CRLs is to provide the freshest information,

and to my knowledge the goal was not to get rid of the fetching of base CRLs

(which may less frequent due to the support of delta CRLs). 

If I understand correctly, Tim/David/Russ would like to *always* achieve the

following property : it is possible to reconstruct the current CRL by using 
a base CRL from, e.g. 1990, i.e. by capturing every delta CRL that has been 
issued at the same time a base CRL was issued and which contains updates 
made to the *previous* base. 

By this way the fetching of base CRLs could be avoided. However, note that 
it is perfectly " legal " to stop issuing base and delta CRLs during some 
period of time and to issue full CRLs instead (see the difference between 
"full" and "base" at the top of this e-mail). In other words there is no 
need to issue a new base CRL at the end of the validity period of the 
previous base CRL. Doing this would mandate to prescribe issuing rules 
for CAs that we have not prescripted. 

I will now raise a series of questions, for which I believe we have 
different answers. Tim/David/Russ do not hesitate to correct 
if my guess is wrong. ;-) 

Common point: 

1) What will be the value of the nextUpdate field from the last issued delta

CRL for a given base CRL ? 

Denis: the nextUpdate field from the last issued delta CRL MUST be equal to 
the value of nextUpdate from the base CRL. 

Tim/David/Russ: ??? 

2) Does a CA needs to issue a delta CRL at the time a full CRL is issued ? 

Denis: No. 
Tim/David/Russ : ??? 

3) Does a CA needs to issue a new base CRL at the end of the validity of a 
current base CRL ? 

Denis: No. 
Tim/David/Russ : ??? 

4) Does a CA needs to issue a delta CRL at the same time a new base is 
issued ? 

Denis: Yes. The delta CRL refers to the *new* base. 
Tim/David/Russ : Yes. The delta CRL refers to the *previous* base. [Note 
that there can be no previous at all, or the "previous" may even be three 
months old]. 

The last point highlights the most noticeable difference. Other differences 
appears when considering the guaranty to get the freshest information : 
using the traditional scheme and the thisUpdate and nextUpdate fields the 
guaranty to get the freshest information is obtained, but cannot be obtained

using the other scheme. :-( 

Several people are referring to the X.509 document for arguments to support 
that discussion. However, it is important to remember that we are defining 
PKIX, not X.509, so we DO NOT need to copy and paste everything from X.509, 
but only what we believe is relevant. 

We first need to clearly define the processing rules applicable to the 
relying parties. These rules will certainly contain SHALL/MUST statements, 
but may also include some MAY statements which may even be conditional to 
what the CA is doing. (I let Tim/David or Russ provide the MAY statement). 

Here is a proposal for the MUST statement, based on the previous text I 
produced: 

   An application that is wishing to take advantage of delta CRLs 
   for a given scope, MUST first find a base CRL for that scope, 
   i.e. a full CRL that that contains a freshestCRL extension 
   (a.k.a. a Delta CRL distribution point). It may then construct 
   an updated CRL for that base, for a specific time T, by combining 
   it with a delta CRL which contains a delta CRL indicator extension 
   with the same CRL number as the base CRL. Applications that support 
   delta CRLs MUST ensure that time T falls between thisUpdate and 
   nextUpdate for both the base CRL and the delta CRL. 

   Note: An application could also reconstruct an updated CRL, for 
   a specific time T, by using a previously locally reconstructed CRL 
   based on the current base CRL, and combining it with a delta CRL which 
   contains a delta CRL indicator extension with the same CRL number as 
   the base CRL. 

We also need to clearly separate the issuing rules applicable for the CAs. 
These rules will certainly contain SHALL statements, but could also include 
some MAY statements. (I let Tim/David or Russ provide the MAY statement). 

Here is a proposal for the MUST statement, based on the previous text I 
produced: 

   A CA that supports delta-CRLs, MUST issue a base CRL, i.e. a full 
   CRL that contains a freshestCRL extension (a.k.a. a Delta CRL 
   distribution point). For any time T until the nextUpdate time 
   indicated in a base CRL, the CA MUST provide one and only one 
   delta CRL that refers to that base CRL and for which time T 
   falls between thisUpdate and nextUpdate from the delta CRL. 

In his e-mail from Wednesday, May 9, David said that delta-CRL processing 
rules could be base on time instead of CRL numbers. This is a point of which

I strongly agree. Let us do it! 

(However, there is no need to add to PKIX, as he suggested, the support of 
the baseUpdateTime extension from X.509 which would even more complicate the

problem.) 

Regards, 

Denis 


------_=_NextPart_001_01C0D96A.1992B660
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: delta CRLs</TITLE>

<META content="MSHTML 5.50.4522.1800" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=289175815-10052001><FONT face=Arial color=#0000ff size=2>As for 
509, Santosh is correct. Freshest CRL is not required.</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Santosh Chokhani 
  [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, May 10, 2001 10:29 
  AM<BR><B>To:</B> Denis Pinkas<BR><B>Cc:</B> 
  [e-mail]<BR><B>Subject:</B> RE: delta CRLs<BR><BR></FONT></DIV>
  <P><FONT size=2>Denis:</FONT> </P>
  <P><FONT size=2>Since you did not ask me the questions, I will NOT answer 
  them.</FONT> </P>
  <P><FONT size=2>In general, my reading of the standard is that a base CRL need 
  not have freshest CRL extension in it.</FONT> </P>
  <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: Denis 
  Pinkas [<A 
  href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
  <BR><FONT size=2>Sent: Thursday, May 10, 2001 4:19 AM</FONT> <BR><FONT 
  size=2>Cc: [e-mail]</FONT> <BR><FONT size=2>Subject: Re: delta 
  CRLs</FONT> </P><BR>
  <P><FONT size=2>Tim, David, Russ, Santosh, Carlin, and many others ...</FONT> 
  </P>
  <P><FONT size=2>There is difference between a base CRL and a full CRL : a base 
  CRL MUST</FONT> <BR><FONT size=2>include a freshestCRL extension (a.k.a. a 
  Delta CRL distribution point),</FONT> <BR><FONT size=2>whereas a full CRL may 
  not include that extension. In other words, a base</FONT> <BR><FONT size=2>CRL 
  is a also a full CRL, but a full CRL is not necessarily a base CRL.</FONT> 
</P>
  <P><FONT size=2>At any time a CA may issue a full CRL, whether or not a base 
  CRL has already</FONT> <BR><FONT size=2>been issued. This additional CRL 
  SHOULD have nextUpdate equal to the</FONT> <BR><FONT size=2>nextUpdate of the 
  last issued full CRL. However, there is no guarantee that</FONT> <BR><FONT 
  size=2>this additional CRL will ever be seen by the relying party (because 
  there</FONT> <BR><FONT size=2>will be two CRLs matching the thisUpdate and 
  nextUpdate rule and if one is</FONT> <BR><FONT size=2>deleted, this is not 
  seen by a relying party).</FONT> </P>
  <P><FONT size=2>Due to the fact that CRLs numbers are strictly increasing, two 
  CRLs whether</FONT> <BR><FONT size=2>they are a base CRL or delta CRL, CANNOT 
  have the same CRL number. So a</FONT> <BR><FONT size=2>delta CRL and a full 
  CRL that cover the same scope and are issued at the</FONT> <BR><FONT 
  size=2>same time CANNOT have the same number. If a full CRL is issued, its 
  CRL</FONT> <BR><FONT size=2>number bears no relationship with the previous 
  base CRL, if any. The only</FONT> <BR><FONT size=2>relationship between the 
  numbers is defined by the rule that CRLs numbers</FONT> <BR><FONT size=2>are 
  strictly increasing. As Santosh said : "the CRL number is unique</FONT> 
  <BR><FONT size=2>whether it is a base or a delta ". </FONT></P>
  <P><FONT size=2>This is fairly important to be able to unambiguously (and thus 
  uniquely)</FONT> <BR><FONT size=2>refer to a CRL by only providing its CRL 
  number.</FONT> </P>
  <P><FONT size=2>Besides the fact that a CRL issued later MUST have a higher 
  CRL number, full</FONT> <BR><FONT size=2>CRLs and delta CRLs have independent 
  numbering rules. As noticed by Santosh,</FONT> <BR><FONT size=2>" if the delta 
  thisUpdate &gt; base thisUpdate, delta CRL number &gt; base CRL</FONT> 
  <BR><FONT size=2>number (for the same or no stream identifier).</FONT> </P>
  <P><FONT size=2>As Santosh said : "a check based on thisUpdate is more general 
  and</FONT> <BR><FONT size=2>preferred [to the use of CRL numbers]. "</FONT> 
  </P>
  <P><FONT size=2>Related to the three rules mentioned by Russ :</FONT> </P>
  <P><FONT size=2>1) the first rule is not understandable to me.</FONT> 
  <BR><FONT size=2>2) the second rule does not say anything more than the basic 
  rule valid </FONT><BR><FONT size=2>&nbsp;&nbsp; for any CRL (i.e. a CRL issued 
  later MUST have a higher CRL number).</FONT> <BR><FONT size=2>3) we will 
  debate the hold condition, once we will have sorted the main</FONT> <BR><FONT 
  size=2>&nbsp;&nbsp; issue.</FONT> </P>
  <P><FONT size=2>Russ said : "If separate number sequence is used, then you 
  will have to</FONT> <BR><FONT size=2>periodically fetch base CRLs ". This is 
  true. </FONT></P>
  <P><FONT size=2>Tim said that he would *not* like to be forced to download new 
  base CRLs.</FONT> <BR><FONT size=2>This is the core of the "dispute".</FONT> 
  </P>
  <P><FONT size=2>From the definition of what a delta CRL is, it is *not* 
  possible to</FONT> <BR><FONT size=2>get rid of the fetching of base CRLs. 
  Unless we add a new sentence to</FONT> <BR><FONT size=2>expand/change that 
  definition, base CRL fetching will remain mandatory.</FONT> </P>
  <P><FONT size=2>Remember that the goal of delta CRLs is to provide the 
  freshest information,</FONT> <BR><FONT size=2>and to my knowledge the goal was 
  not to get rid of the fetching of base CRLs</FONT> <BR><FONT size=2>(which may 
  less frequent due to the support of delta CRLs).</FONT> </P>
  <P><FONT size=2>If I understand correctly, Tim/David/Russ would like to 
  *always* achieve the</FONT> <BR><FONT size=2>following property : it is 
  possible to reconstruct the current CRL by using</FONT> <BR><FONT size=2>a 
  base CRL from, e.g. 1990, i.e. by capturing every delta CRL that has 
  been</FONT> <BR><FONT size=2>issued at the same time a base CRL was issued and 
  which contains updates</FONT> <BR><FONT size=2>made to the *previous* base. 
  </FONT></P>
  <P><FONT size=2>By this way the fetching of base CRLs could be avoided. 
  However, note that</FONT> <BR><FONT size=2>it is perfectly " legal " to stop 
  issuing base and delta CRLs during some</FONT> <BR><FONT size=2>period of time 
  and to issue full CRLs instead (see the difference between</FONT> <BR><FONT 
  size=2>"full" and "base" at the top of this e-mail). In other words there is 
  no</FONT> <BR><FONT size=2>need to issue a new base CRL at the end of the 
  validity period of the</FONT> <BR><FONT size=2>previous base CRL. Doing this 
  would mandate to prescribe issuing rules </FONT><BR><FONT size=2>for CAs that 
  we have not prescripted.</FONT> </P>
  <P><FONT size=2>I will now raise a series of questions, for which I believe we 
  have</FONT> <BR><FONT size=2>different answers. Tim/David/Russ do not hesitate 
  to correct </FONT><BR><FONT size=2>if my guess is wrong. ;-)</FONT> </P>
  <P><FONT size=2>Common point:</FONT> </P>
  <P><FONT size=2>1) What will be the value of the nextUpdate field from the 
  last issued delta</FONT> <BR><FONT size=2>CRL for a given base CRL ? 
  </FONT></P>
  <P><FONT size=2>Denis: the nextUpdate field from the last issued delta CRL 
  MUST be equal to</FONT> <BR><FONT size=2>the value of nextUpdate from the base 
  CRL.</FONT> </P>
  <P><FONT size=2>Tim/David/Russ: ???</FONT> </P>
  <P><FONT size=2>2) Does a CA needs to issue a delta CRL at the time a full CRL 
  is issued ?</FONT> </P>
  <P><FONT size=2>Denis: No.</FONT> <BR><FONT size=2>Tim/David/Russ : ???</FONT> 
  </P>
  <P><FONT size=2>3) Does a CA needs to issue a new base CRL at the end of the 
  validity of a</FONT> <BR><FONT size=2>current base CRL ?</FONT> </P>
  <P><FONT size=2>Denis: No.</FONT> <BR><FONT size=2>Tim/David/Russ : ???</FONT> 
  </P>
  <P><FONT size=2>4) Does a CA needs to issue a delta CRL at the same time a new 
  base is</FONT> <BR><FONT size=2>issued ?</FONT> </P>
  <P><FONT size=2>Denis: Yes. The delta CRL refers to the *new* base.</FONT> 
  <BR><FONT size=2>Tim/David/Russ : Yes. The delta CRL refers to the *previous* 
  base. [Note</FONT> <BR><FONT size=2>that there can be no previous at all, or 
  the "previous" may even be three</FONT> <BR><FONT size=2>months old]. 
  </FONT></P>
  <P><FONT size=2>The last point highlights the most noticeable difference. 
  Other differences</FONT> <BR><FONT size=2>appears when considering the 
  guaranty to get the freshest information :</FONT> <BR><FONT size=2>using the 
  traditional scheme and the thisUpdate and nextUpdate fields the</FONT> 
  <BR><FONT size=2>guaranty to get the freshest information is obtained, but 
  cannot be obtained</FONT> <BR><FONT size=2>using the other scheme. :-(</FONT> 
  </P>
  <P><FONT size=2>Several people are referring to the X.509 document for 
  arguments to support</FONT> <BR><FONT size=2>that discussion. However, it is 
  important to remember that we are defining</FONT> <BR><FONT size=2>PKIX, not 
  X.509, so we DO NOT need to copy and paste everything from X.509,</FONT> 
  <BR><FONT size=2>but only what we believe is relevant.</FONT> </P>
  <P><FONT size=2>We first need to clearly define the processing rules 
  applicable to the</FONT> <BR><FONT size=2>relying parties. These rules will 
  certainly contain SHALL/MUST statements,</FONT> <BR><FONT size=2>but may also 
  include some MAY statements which may even be conditional to</FONT> <BR><FONT 
  size=2>what the CA is doing. (I let Tim/David or Russ provide the MAY 
  statement).</FONT> </P>
  <P><FONT size=2>Here is a proposal for the MUST statement, based on the 
  previous text I</FONT> <BR><FONT size=2>produced:</FONT> </P>
  <P><FONT size=2>&nbsp;&nbsp; An application that is wishing to take advantage 
  of delta CRLs </FONT><BR><FONT size=2>&nbsp;&nbsp; for a given scope, MUST 
  first find a base CRL for that scope, </FONT><BR><FONT size=2>&nbsp;&nbsp; 
  i.e. a full CRL that that contains a freshestCRL extension </FONT><BR><FONT 
  size=2>&nbsp;&nbsp; (a.k.a. a Delta CRL distribution point). It may then 
  construct </FONT><BR><FONT size=2>&nbsp;&nbsp; an updated CRL for that base, 
  for a specific time T, by combining </FONT><BR><FONT size=2>&nbsp;&nbsp; it 
  with a delta CRL which contains a delta CRL indicator extension 
  </FONT><BR><FONT size=2>&nbsp;&nbsp; with the same CRL number as the base CRL. 
  Applications that support </FONT><BR><FONT size=2>&nbsp;&nbsp; delta CRLs MUST 
  ensure that time T falls between thisUpdate and </FONT><BR><FONT 
  size=2>&nbsp;&nbsp; nextUpdate for both the base CRL and the delta CRL.</FONT> 
  </P>
  <P><FONT size=2>&nbsp;&nbsp; Note: An application could also reconstruct an 
  updated CRL, for </FONT><BR><FONT size=2>&nbsp;&nbsp; a specific time T, by 
  using a previously locally reconstructed CRL </FONT><BR><FONT 
  size=2>&nbsp;&nbsp; based on the current base CRL, and combining it with a 
  delta CRL which </FONT><BR><FONT size=2>&nbsp;&nbsp; contains a delta CRL 
  indicator extension with the same CRL number as </FONT><BR><FONT 
  size=2>&nbsp;&nbsp; the base CRL.</FONT> </P>
  <P><FONT size=2>We also need to clearly separate the issuing rules applicable 
  for the CAs.</FONT> <BR><FONT size=2>These rules will certainly contain SHALL 
  statements, but could also include</FONT> <BR><FONT size=2>some MAY 
  statements. (I let Tim/David or Russ provide the MAY statement).</FONT> </P>
  <P><FONT size=2>Here is a proposal for the MUST statement, based on the 
  previous text I</FONT> <BR><FONT size=2>produced:</FONT> </P>
  <P><FONT size=2>&nbsp;&nbsp; A CA that supports delta-CRLs, MUST issue a base 
  CRL, i.e. a full </FONT><BR><FONT size=2>&nbsp;&nbsp; CRL that contains a 
  freshestCRL extension (a.k.a. a Delta CRL </FONT><BR><FONT size=2>&nbsp;&nbsp; 
  distribution point). For any time T until the nextUpdate time </FONT><BR><FONT 
  size=2>&nbsp;&nbsp; indicated in a base CRL, the CA MUST provide one and only 
  one </FONT><BR><FONT size=2>&nbsp;&nbsp; delta CRL that refers to that base 
  CRL and for which time T </FONT><BR><FONT size=2>&nbsp;&nbsp; falls between 
  thisUpdate and nextUpdate from the delta CRL.</FONT> </P>
  <P><FONT size=2>In his e-mail from Wednesday, May 9, David said that delta-CRL 
  processing</FONT> <BR><FONT size=2>rules could be base on time instead of CRL 
  numbers. This is a point of which</FONT> <BR><FONT size=2>I strongly agree. 
  Let us do it!</FONT> </P>
  <P><FONT size=2>(However, there is no need to add to PKIX, as he suggested, 
  the support of</FONT> <BR><FONT size=2>the baseUpdateTime extension from X.509 
  which would even more complicate the</FONT> <BR><FONT size=2>problem.)</FONT> 
  </P>
  <P><FONT size=2>Regards,</FONT> </P>
  <P><FONT size=2>Denis</FONT> </P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C0D96A.1992B660--


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA09383 for <[e-mail]>; Thu, 10 May 2001 08:56:27 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA28340; Thu, 10 May 2001 17:56:27 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA16822; Thu, 10 May 2001 17:55:52 +0200
Message-ID: <[e-mail]>
Date: Thu, 10 May 2001 17:54:43 +0200
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Dr S N Henson <[e-mail]>
CC: "'[e-mail] '" <[e-mail]>
Subject: Re: Certificate Hold (was RE: delta CRLs)
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id IAA09387

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

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

> 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: [e-mail]
> Senior crypto engineer, Celo Communications: http://www.celocom.com/
> Core developer of the   OpenSSL project: http://www.openssl.org/
> Business Email: [e-mail] PGP key: via homepage.


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA01614 for <[e-mail]>; Thu, 10 May 2001 07:38:28 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <K4X9NHPM>; Thu, 10 May 2001 10:37:58 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
Subject: RE: delta CRLs
Date: Thu, 10 May 2001 10:28:44 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D95D.8497A310"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D95D.8497A310
Content-Type: text/plain;
	charset="iso-8859-1"

Denis:

Since you did not ask me the questions, I will NOT answer them.

In general, my reading of the standard is that a base CRL need not have
freshest CRL extension in it.

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Thursday, May 10, 2001 4:19 AM
Cc: [e-mail]
Subject: Re: delta CRLs


Tim, David, Russ, Santosh, Carlin, and many others ...

There is difference between a base CRL and a full CRL : a base CRL MUST
include a freshestCRL extension (a.k.a. a Delta CRL distribution point),
whereas a full CRL may not include that extension. In other words, a base
CRL is a also a full CRL, but a full CRL is not necessarily a base CRL.

At any time a CA may issue a full CRL, whether or not a base CRL has already
been issued. This additional CRL SHOULD have nextUpdate equal to the
nextUpdate of the last issued full CRL. However, there is no guarantee that
this additional CRL will ever be seen by the relying party (because there
will be two CRLs matching the thisUpdate and nextUpdate rule and if one is
deleted, this is not seen by a relying party).

Due to the fact that CRLs numbers are strictly increasing, two CRLs whether
they are a base CRL or delta CRL, CANNOT have the same CRL number. So a
delta CRL and a full CRL that cover the same scope and are issued at the
same time CANNOT have the same number. If a full CRL is issued, its CRL
number bears no relationship with the previous base CRL, if any. The only
relationship between the numbers is defined by the rule that CRLs numbers
are strictly increasing. As Santosh said : "the CRL number is unique
whether it is a base or a delta ". 

This is fairly important to be able to unambiguously (and thus uniquely)
refer to a CRL by only providing its CRL number.

Besides the fact that a CRL issued later MUST have a higher CRL number, full
CRLs and delta CRLs have independent numbering rules. As noticed by Santosh,
" if the delta thisUpdate > base thisUpdate, delta CRL number > base CRL
number (for the same or no stream identifier).

As Santosh said : "a check based on thisUpdate is more general and
preferred [to the use of CRL numbers]. "

Related to the three rules mentioned by Russ :

1) the first rule is not understandable to me.
2) the second rule does not say anything more than the basic rule valid 
   for any CRL (i.e. a CRL issued later MUST have a higher CRL number).
3) we will debate the hold condition, once we will have sorted the main
   issue.

Russ said : "If separate number sequence is used, then you will have to
periodically fetch base CRLs ". This is true. 

Tim said that he would *not* like to be forced to download new base CRLs.
This is the core of the "dispute".

>From the definition of what a delta CRL is, it is *not* possible to
get rid of the fetching of base CRLs. Unless we add a new sentence to
expand/change that definition, base CRL fetching will remain mandatory.

Remember that the goal of delta CRLs is to provide the freshest information,
and to my knowledge the goal was not to get rid of the fetching of base CRLs
(which may less frequent due to the support of delta CRLs).

If I understand correctly, Tim/David/Russ would like to *always* achieve the
following property : it is possible to reconstruct the current CRL by using
a base CRL from, e.g. 1990, i.e. by capturing every delta CRL that has been
issued at the same time a base CRL was issued and which contains updates
made to the *previous* base. 

By this way the fetching of base CRLs could be avoided. However, note that
it is perfectly " legal " to stop issuing base and delta CRLs during some
period of time and to issue full CRLs instead (see the difference between
"full" and "base" at the top of this e-mail). In other words there is no
need to issue a new base CRL at the end of the validity period of the
previous base CRL. Doing this would mandate to prescribe issuing rules 
for CAs that we have not prescripted.

I will now raise a series of questions, for which I believe we have
different answers. Tim/David/Russ do not hesitate to correct 
if my guess is wrong. ;-)

Common point:

1) What will be the value of the nextUpdate field from the last issued delta
CRL for a given base CRL ? 

Denis: the nextUpdate field from the last issued delta CRL MUST be equal to
the value of nextUpdate from the base CRL.

Tim/David/Russ: ???

2) Does a CA needs to issue a delta CRL at the time a full CRL is issued ?

Denis: No.
Tim/David/Russ : ???

3) Does a CA needs to issue a new base CRL at the end of the validity of a
current base CRL ?

Denis: No.
Tim/David/Russ : ???

4) Does a CA needs to issue a delta CRL at the same time a new base is
issued ?

Denis: Yes. The delta CRL refers to the *new* base.
Tim/David/Russ : Yes. The delta CRL refers to the *previous* base. [Note
that there can be no previous at all, or the "previous" may even be three
months old]. 

The last point highlights the most noticeable difference. Other differences
appears when considering the guaranty to get the freshest information :
using the traditional scheme and the thisUpdate and nextUpdate fields the
guaranty to get the freshest information is obtained, but cannot be obtained
using the other scheme. :-(

Several people are referring to the X.509 document for arguments to support
that discussion. However, it is important to remember that we are defining
PKIX, not X.509, so we DO NOT need to copy and paste everything from X.509,
but only what we believe is relevant.

We first need to clearly define the processing rules applicable to the
relying parties. These rules will certainly contain SHALL/MUST statements,
but may also include some MAY statements which may even be conditional to
what the CA is doing. (I let Tim/David or Russ provide the MAY statement).

Here is a proposal for the MUST statement, based on the previous text I
produced:

   An application that is wishing to take advantage of delta CRLs 
   for a given scope, MUST first find a base CRL for that scope, 
   i.e. a full CRL that that contains a freshestCRL extension 
   (a.k.a. a Delta CRL distribution point). It may then construct 
   an updated CRL for that base, for a specific time T, by combining 
   it with a delta CRL which contains a delta CRL indicator extension 
   with the same CRL number as the base CRL. Applications that support 
   delta CRLs MUST ensure that time T falls between thisUpdate and 
   nextUpdate for both the base CRL and the delta CRL.

   Note: An application could also reconstruct an updated CRL, for 
   a specific time T, by using a previously locally reconstructed CRL 
   based on the current base CRL, and combining it with a delta CRL which 
   contains a delta CRL indicator extension with the same CRL number as 
   the base CRL.

We also need to clearly separate the issuing rules applicable for the CAs.
These rules will certainly contain SHALL statements, but could also include
some MAY statements. (I let Tim/David or Russ provide the MAY statement).

Here is a proposal for the MUST statement, based on the previous text I
produced:

   A CA that supports delta-CRLs, MUST issue a base CRL, i.e. a full 
   CRL that contains a freshestCRL extension (a.k.a. a Delta CRL 
   distribution point). For any time T until the nextUpdate time 
   indicated in a base CRL, the CA MUST provide one and only one 
   delta CRL that refers to that base CRL and for which time T 
   falls between thisUpdate and nextUpdate from the delta CRL.

In his e-mail from Wednesday, May 9, David said that delta-CRL processing
rules could be base on time instead of CRL numbers. This is a point of which
I strongly agree. Let us do it!

(However, there is no need to add to PKIX, as he suggested, the support of
the baseUpdateTime extension from X.509 which would even more complicate the
problem.)

Regards,

Denis

------_=_NextPart_001_01C0D95D.8497A310
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: delta CRLs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Denis:</FONT>
</P>

<P><FONT SIZE=2>Since you did not ask me the questions, I will NOT answer them.</FONT>
</P>

<P><FONT SIZE=2>In general, my reading of the standard is that a base CRL need not have freshest CRL extension in it.</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Denis Pinkas [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>Sent: Thursday, May 10, 2001 4:19 AM</FONT>
<BR><FONT SIZE=2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=2>Subject: Re: delta CRLs</FONT>
</P>
<BR>

<P><FONT SIZE=2>Tim, David, Russ, Santosh, Carlin, and many others ...</FONT>
</P>

<P><FONT SIZE=2>There is difference between a base CRL and a full CRL : a base CRL MUST</FONT>
<BR><FONT SIZE=2>include a freshestCRL extension (a.k.a. a Delta CRL distribution point),</FONT>
<BR><FONT SIZE=2>whereas a full CRL may not include that extension. In other words, a base</FONT>
<BR><FONT SIZE=2>CRL is a also a full CRL, but a full CRL is not necessarily a base CRL.</FONT>
</P>

<P><FONT SIZE=2>At any time a CA may issue a full CRL, whether or not a base CRL has already</FONT>
<BR><FONT SIZE=2>been issued. This additional CRL SHOULD have nextUpdate equal to the</FONT>
<BR><FONT SIZE=2>nextUpdate of the last issued full CRL. However, there is no guarantee that</FONT>
<BR><FONT SIZE=2>this additional CRL will ever be seen by the relying party (because there</FONT>
<BR><FONT SIZE=2>will be two CRLs matching the thisUpdate and nextUpdate rule and if one is</FONT>
<BR><FONT SIZE=2>deleted, this is not seen by a relying party).</FONT>
</P>

<P><FONT SIZE=2>Due to the fact that CRLs numbers are strictly increasing, two CRLs whether</FONT>
<BR><FONT SIZE=2>they are a base CRL or delta CRL, CANNOT have the same CRL number. So a</FONT>
<BR><FONT SIZE=2>delta CRL and a full CRL that cover the same scope and are issued at the</FONT>
<BR><FONT SIZE=2>same time CANNOT have the same number. If a full CRL is issued, its CRL</FONT>
<BR><FONT SIZE=2>number bears no relationship with the previous base CRL, if any. The only</FONT>
<BR><FONT SIZE=2>relationship between the numbers is defined by the rule that CRLs numbers</FONT>
<BR><FONT SIZE=2>are strictly increasing. As Santosh said : &quot;the CRL number is unique</FONT>
<BR><FONT SIZE=2>whether it is a base or a delta &quot;. </FONT>
</P>

<P><FONT SIZE=2>This is fairly important to be able to unambiguously (and thus uniquely)</FONT>
<BR><FONT SIZE=2>refer to a CRL by only providing its CRL number.</FONT>
</P>

<P><FONT SIZE=2>Besides the fact that a CRL issued later MUST have a higher CRL number, full</FONT>
<BR><FONT SIZE=2>CRLs and delta CRLs have independent numbering rules. As noticed by Santosh,</FONT>
<BR><FONT SIZE=2>&quot; if the delta thisUpdate &gt; base thisUpdate, delta CRL number &gt; base CRL</FONT>
<BR><FONT SIZE=2>number (for the same or no stream identifier).</FONT>
</P>

<P><FONT SIZE=2>As Santosh said : &quot;a check based on thisUpdate is more general and</FONT>
<BR><FONT SIZE=2>preferred [to the use of CRL numbers]. &quot;</FONT>
</P>

<P><FONT SIZE=2>Related to the three rules mentioned by Russ :</FONT>
</P>

<P><FONT SIZE=2>1) the first rule is not understandable to me.</FONT>
<BR><FONT SIZE=2>2) the second rule does not say anything more than the basic rule valid </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; for any CRL (i.e. a CRL issued later MUST have a higher CRL number).</FONT>
<BR><FONT SIZE=2>3) we will debate the hold condition, once we will have sorted the main</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; issue.</FONT>
</P>

<P><FONT SIZE=2>Russ said : &quot;If separate number sequence is used, then you will have to</FONT>
<BR><FONT SIZE=2>periodically fetch base CRLs &quot;. This is true. </FONT>
</P>

<P><FONT SIZE=2>Tim said that he would *not* like to be forced to download new base CRLs.</FONT>
<BR><FONT SIZE=2>This is the core of the &quot;dispute&quot;.</FONT>
</P>

<P><FONT SIZE=2>From the definition of what a delta CRL is, it is *not* possible to</FONT>
<BR><FONT SIZE=2>get rid of the fetching of base CRLs. Unless we add a new sentence to</FONT>
<BR><FONT SIZE=2>expand/change that definition, base CRL fetching will remain mandatory.</FONT>
</P>

<P><FONT SIZE=2>Remember that the goal of delta CRLs is to provide the freshest information,</FONT>
<BR><FONT SIZE=2>and to my knowledge the goal was not to get rid of the fetching of base CRLs</FONT>
<BR><FONT SIZE=2>(which may less frequent due to the support of delta CRLs).</FONT>
</P>

<P><FONT SIZE=2>If I understand correctly, Tim/David/Russ would like to *always* achieve the</FONT>
<BR><FONT SIZE=2>following property : it is possible to reconstruct the current CRL by using</FONT>
<BR><FONT SIZE=2>a base CRL from, e.g. 1990, i.e. by capturing every delta CRL that has been</FONT>
<BR><FONT SIZE=2>issued at the same time a base CRL was issued and which contains updates</FONT>
<BR><FONT SIZE=2>made to the *previous* base. </FONT>
</P>

<P><FONT SIZE=2>By this way the fetching of base CRLs could be avoided. However, note that</FONT>
<BR><FONT SIZE=2>it is perfectly &quot; legal &quot; to stop issuing base and delta CRLs during some</FONT>
<BR><FONT SIZE=2>period of time and to issue full CRLs instead (see the difference between</FONT>
<BR><FONT SIZE=2>&quot;full&quot; and &quot;base&quot; at the top of this e-mail). In other words there is no</FONT>
<BR><FONT SIZE=2>need to issue a new base CRL at the end of the validity period of the</FONT>
<BR><FONT SIZE=2>previous base CRL. Doing this would mandate to prescribe issuing rules </FONT>
<BR><FONT SIZE=2>for CAs that we have not prescripted.</FONT>
</P>

<P><FONT SIZE=2>I will now raise a series of questions, for which I believe we have</FONT>
<BR><FONT SIZE=2>different answers. Tim/David/Russ do not hesitate to correct </FONT>
<BR><FONT SIZE=2>if my guess is wrong. ;-)</FONT>
</P>

<P><FONT SIZE=2>Common point:</FONT>
</P>

<P><FONT SIZE=2>1) What will be the value of the nextUpdate field from the last issued delta</FONT>
<BR><FONT SIZE=2>CRL for a given base CRL ? </FONT>
</P>

<P><FONT SIZE=2>Denis: the nextUpdate field from the last issued delta CRL MUST be equal to</FONT>
<BR><FONT SIZE=2>the value of nextUpdate from the base CRL.</FONT>
</P>

<P><FONT SIZE=2>Tim/David/Russ: ???</FONT>
</P>

<P><FONT SIZE=2>2) Does a CA needs to issue a delta CRL at the time a full CRL is issued ?</FONT>
</P>

<P><FONT SIZE=2>Denis: No.</FONT>
<BR><FONT SIZE=2>Tim/David/Russ : ???</FONT>
</P>

<P><FONT SIZE=2>3) Does a CA needs to issue a new base CRL at the end of the validity of a</FONT>
<BR><FONT SIZE=2>current base CRL ?</FONT>
</P>

<P><FONT SIZE=2>Denis: No.</FONT>
<BR><FONT SIZE=2>Tim/David/Russ : ???</FONT>
</P>

<P><FONT SIZE=2>4) Does a CA needs to issue a delta CRL at the same time a new base is</FONT>
<BR><FONT SIZE=2>issued ?</FONT>
</P>

<P><FONT SIZE=2>Denis: Yes. The delta CRL refers to the *new* base.</FONT>
<BR><FONT SIZE=2>Tim/David/Russ : Yes. The delta CRL refers to the *previous* base. [Note</FONT>
<BR><FONT SIZE=2>that there can be no previous at all, or the &quot;previous&quot; may even be three</FONT>
<BR><FONT SIZE=2>months old]. </FONT>
</P>

<P><FONT SIZE=2>The last point highlights the most noticeable difference. Other differences</FONT>
<BR><FONT SIZE=2>appears when considering the guaranty to get the freshest information :</FONT>
<BR><FONT SIZE=2>using the traditional scheme and the thisUpdate and nextUpdate fields the</FONT>
<BR><FONT SIZE=2>guaranty to get the freshest information is obtained, but cannot be obtained</FONT>
<BR><FONT SIZE=2>using the other scheme. :-(</FONT>
</P>

<P><FONT SIZE=2>Several people are referring to the X.509 document for arguments to support</FONT>
<BR><FONT SIZE=2>that discussion. However, it is important to remember that we are defining</FONT>
<BR><FONT SIZE=2>PKIX, not X.509, so we DO NOT need to copy and paste everything from X.509,</FONT>
<BR><FONT SIZE=2>but only what we believe is relevant.</FONT>
</P>

<P><FONT SIZE=2>We first need to clearly define the processing rules applicable to the</FONT>
<BR><FONT SIZE=2>relying parties. These rules will certainly contain SHALL/MUST statements,</FONT>
<BR><FONT SIZE=2>but may also include some MAY statements which may even be conditional to</FONT>
<BR><FONT SIZE=2>what the CA is doing. (I let Tim/David or Russ provide the MAY statement).</FONT>
</P>

<P><FONT SIZE=2>Here is a proposal for the MUST statement, based on the previous text I</FONT>
<BR><FONT SIZE=2>produced:</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; An application that is wishing to take advantage of delta CRLs </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; for a given scope, MUST first find a base CRL for that scope, </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; i.e. a full CRL that that contains a freshestCRL extension </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; (a.k.a. a Delta CRL distribution point). It may then construct </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; an updated CRL for that base, for a specific time T, by combining </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; it with a delta CRL which contains a delta CRL indicator extension </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; with the same CRL number as the base CRL. Applications that support </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; delta CRLs MUST ensure that time T falls between thisUpdate and </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; nextUpdate for both the base CRL and the delta CRL.</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; Note: An application could also reconstruct an updated CRL, for </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; a specific time T, by using a previously locally reconstructed CRL </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; based on the current base CRL, and combining it with a delta CRL which </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; contains a delta CRL indicator extension with the same CRL number as </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; the base CRL.</FONT>
</P>

<P><FONT SIZE=2>We also need to clearly separate the issuing rules applicable for the CAs.</FONT>
<BR><FONT SIZE=2>These rules will certainly contain SHALL statements, but could also include</FONT>
<BR><FONT SIZE=2>some MAY statements. (I let Tim/David or Russ provide the MAY statement).</FONT>
</P>

<P><FONT SIZE=2>Here is a proposal for the MUST statement, based on the previous text I</FONT>
<BR><FONT SIZE=2>produced:</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; A CA that supports delta-CRLs, MUST issue a base CRL, i.e. a full </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; CRL that contains a freshestCRL extension (a.k.a. a Delta CRL </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; distribution point). For any time T until the nextUpdate time </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; indicated in a base CRL, the CA MUST provide one and only one </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; delta CRL that refers to that base CRL and for which time T </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; falls between thisUpdate and nextUpdate from the delta CRL.</FONT>
</P>

<P><FONT SIZE=2>In his e-mail from Wednesday, May 9, David said that delta-CRL processing</FONT>
<BR><FONT SIZE=2>rules could be base on time instead of CRL numbers. This is a point of which</FONT>
<BR><FONT SIZE=2>I strongly agree. Let us do it!</FONT>
</P>

<P><FONT SIZE=2>(However, there is no need to add to PKIX, as he suggested, the support of</FONT>
<BR><FONT SIZE=2>the baseUpdateTime extension from X.509 which would even more complicate the</FONT>
<BR><FONT SIZE=2>problem.)</FONT>
</P>

<P><FONT SIZE=2>Regards,</FONT>
</P>

<P><FONT SIZE=2>Denis</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0D95D.8497A310--


Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA00446 for <[e-mail]>; Thu, 10 May 2001 07:23:54 -0700 (PDT)
Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=celocom.com) by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1) id 14xrMA-000NPj-0A for [e-mail]; Thu, 10 May 2001 14:23:55 +0000
Message-ID: <[e-mail]>
Date: Thu, 10 May 2001 14:43:10 +0100
From: Dr S N Henson <[e-mail]>
Organization: S N Henson
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "'[e-mail] '" <[e-mail]>
Subject: Re: Certificate Hold (was RE: delta CRLs)
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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: [e-mail] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [e-mail] PGP key: via homepage.



Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA00101 for <[e-mail]>; Thu, 10 May 2001 07:21:25 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA28081 for <[e-mail]>; Thu, 10 May 2001 10:20:56 -0400 (EDT)
Message-Id: <[e-mail]>
Sender: [e-mail]
Date: Thu, 10 May 2001 10:15:25 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: delta CRLs
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Denis,

If I understand this text correctly, it would prohibit a CA from
issuing an unscheduled delta CRL (one whose thisUpdate is less than
the nextUpdate of the prior delta).  Two possible workarounds:

1) A CA that issues a delta-CRL at time T less than nextUpdate of
   a previous delta-CRL referring to the same base MUST NOT populate
   the nextUpdate field of the unscheduled delta-CRL.

or

2) A CA that issues a delta-CRL at time T less than nextUpdate of
   a previous delta-CRL referring to the same base MUST populate
   the nextUpdate field of the unscheduled delta-CRL with the
   value of nextUpdate from that previous delta-CRL.

Either of these restrictions would allow multiple deltas to exist
at a time T, but would forbid interleaved series of deltas, which
I believe is the intent of your proposal.

Dave




Denis Pinkas wrote:
> 
> Here is a proposal for the MUST statement, based on the previous text I
> produced:
> 
>    A CA that supports delta-CRLs, MUST issue a base CRL, i.e. a full
>    CRL that contains a freshestCRL extension (a.k.a. a Delta CRL
>    distribution point). For any time T until the nextUpdate time
>    indicated in a base CRL, the CA MUST provide one and only one
>    delta CRL that refers to that base CRL and for which time T
>    falls between thisUpdate and nextUpdate from the delta CRL.


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id GAA25742 for <[e-mail]>; Thu, 10 May 2001 06:24:05 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 10 May 2001 13:23:46 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA26211 for <[e-mail]>; Thu, 10 May 2001 09:24:05 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <JY8NWQZH>; Thu, 10 May 2001 09:24:04 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.48]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JY8NWQZ1; Thu, 10 May 2001 09:23:51 -0400
From: "Housley, Russ" <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 10 May 2001 09:05:56 -0400
Subject: Re: delta CRLs
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Denis:

>There is difference between a base CRL and a full CRL

You are quite right.  I, for one, will try to be more careful about the use 
of them.

>Due to the fact that CRLs numbers are strictly increasing, two CRLs whether
>they are a base CRL or delta CRL, CANNOT have the same CRL number.

I disagree.  A full CRL (that may be a base CRL for subsequent delta CRLs) 
and a delta CRL issued at the same time as that full CRL may actually 
represent the same revocation information.  In this case, they are the same 
CRL, and they should have the same number.  There have been several tables 
posted that illustrate this numbering scheme, and I do not see any text in 
X.509-200 that indicates this scheme is

>  So a
>delta CRL and a full CRL that cover the same scope and are issued at the
>same time CANNOT have the same number. If a full CRL is issued, its CRL
>number bears no relationship with the previous base CRL, if any. The only
>relationship between the numbers is defined by the rule that CRLs numbers
>are strictly increasing. As Santosh said : "the CRL number is unique
>whether it is a base or a delta ".
>
>This is fairly important to be able to unambiguously (and thus uniquely)
>refer to a CRL by only providing its CRL number.
>
>Besides the fact that a CRL issued later MUST have a higher CRL number, full
>CRLs and delta CRLs have independent numbering rules. As noticed by Santosh,
>" if the delta thisUpdate > base thisUpdate, delta CRL number > base CRL
>number (for the same or no stream identifier).
>
>As Santosh said : "a check based on thisUpdate is more general and
>preferred [to the use of CRL numbers]. "
>
>Related to the three rules mentioned by Russ :
>
>1) the first rule is not understandable to me.
>2) the second rule does not say anything more than the basic rule valid
>    for any CRL (i.e. a CRL issued later MUST have a higher CRL number).
>3) we will debate the hold condition, once we will have sorted the main
>    issue.
>
>Russ said : "If separate number sequence is used, then you will have to
>periodically fetch base CRLs ". This is true.
>
>Tim said that he would *not* like to be forced to download new base CRLs.
>This is the core of the "dispute".
>
> From the definition of what a delta CRL is, it is *not* possible to
>get rid of the fetching of base CRLs. Unless we add a new sentence to
>expand/change that definition, base CRL fetching will remain mandatory.
>
>Remember that the goal of delta CRLs is to provide the freshest information,
>and to my knowledge the goal was not to get rid of the fetching of base CRLs
>(which may less frequent due to the support of delta CRLs).
>
>If I understand correctly, Tim/David/Russ would like to *always* achieve the
>following property : it is possible to reconstruct the current CRL by using
>a base CRL from, e.g. 1990, i.e. by capturing every delta CRL that has been
>issued at the same time a base CRL was issued and which contains updates
>made to the *previous* base.
>
>By this way the fetching of base CRLs could be avoided. However, note that
>it is perfectly " legal " to stop issuing base and delta CRLs during some
>period of time and to issue full CRLs instead (see the difference between
>"full" and "base" at the top of this e-mail). In other words there is no
>need to issue a new base CRL at the end of the validity period of the
>previous base CRL. Doing this would mandate to prescribe issuing rules
>for CAs that we have not prescripted.
>
>I will now raise a series of questions, for which I believe we have
>different answers. Tim/David/Russ do not hesitate to correct
>if my guess is wrong. ;-)
>
>Common point:
>
>1) What will be the value of the nextUpdate field from the last issued delta
>CRL for a given base CRL ?
>
>Denis: the nextUpdate field from the last issued delta CRL MUST be equal to
>the value of nextUpdate from the base CRL.
>
>Tim/David/Russ: ???
>
>2) Does a CA needs to issue a delta CRL at the time a full CRL is issued ?
>
>Denis: No.
>Tim/David/Russ : ???
>
>3) Does a CA needs to issue a new base CRL at the end of the validity of a
>current base CRL ?
>
>Denis: No.
>Tim/David/Russ : ???
>
>4) Does a CA needs to issue a delta CRL at the same time a new base is
>issued ?
>
>Denis: Yes. The delta CRL refers to the *new* base.
>Tim/David/Russ : Yes. The delta CRL refers to the *previous* base. [Note
>that there can be no previous at all, or the "previous" may even be three
>months old].
>
>The last point highlights the most noticeable difference. Other differences
>appears when considering the guaranty to get the freshest information :
>using the traditional scheme and the thisUpdate and nextUpdate fields the
>guaranty to get the freshest information is obtained, but cannot be obtained
>using the other scheme. :-(
>
>Several people are referring to the X.509 document for arguments to support
>that discussion. However, it is important to remember that we are defining
>PKIX, not X.509, so we DO NOT need to copy and paste everything from X.509,
>but only what we believe is relevant.
>
>We first need to clearly define the processing rules applicable to the
>relying parties. These rules will certainly contain SHALL/MUST statements,
>but may also include some MAY statements which may even be conditional to
>what the CA is doing. (I let Tim/David or Russ provide the MAY statement).
>
>Here is a proposal for the MUST statement, based on the previous text I
>produced:
>
>    An application that is wishing to take advantage of delta CRLs
>    for a given scope, MUST first find a base CRL for that scope,
>    i.e. a full CRL that that contains a freshestCRL extension
>    (a.k.a. a Delta CRL distribution point). It may then construct
>    an updated CRL for that base, for a specific time T, by combining
>    it with a delta CRL which contains a delta CRL indicator extension
>    with the same CRL number as the base CRL. Applications that support
>    delta CRLs MUST ensure that time T falls between thisUpdate and
>    nextUpdate for both the base CRL and the delta CRL.
>
>    Note: An application could also reconstruct an updated CRL, for
>    a specific time T, by using a previously locally reconstructed CRL
>    based on the current base CRL, and combining it with a delta CRL which
>    contains a delta CRL indicator extension with the same CRL number as
>    the base CRL.
>
>We also need to clearly separate the issuing rules applicable for the CAs.
>These rules will certainly contain SHALL statements, but could also include
>some MAY statements. (I let Tim/David or Russ provide the MAY statement).
>
>Here is a proposal for the MUST statement, based on the previous text I
>produced:
>
>    A CA that supports delta-CRLs, MUST issue a base CRL, i.e. a full
>    CRL that contains a freshestCRL extension (a.k.a. a Delta CRL
>    distribution point). For any time T until the nextUpdate time
>    indicated in a base CRL, the CA MUST provide one and only one
>    delta CRL that refers to that base CRL and for which time T
>    falls between thisUpdate and nextUpdate from the delta CRL.
>
>In his e-mail from Wednesday, May 9, David said that delta-CRL processing
>rules could be base on time instead of CRL numbers. This is a point of which
>I strongly agree. Let us do it!
>
>(However, there is no need to add to PKIX, as he suggested, the support of
>the baseUpdateTime extension from X.509 which would even more complicate the
>problem.)
>
>Regards,
>
>Denis


Received: from mail.ksign.com ([211.237.33.200]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA21570 for <[e-mail]>; Thu, 10 May 2001 05:17:14 -0700 (PDT)
Received: from yskim (yskim.ksign.com [211.174.252.122]) by mail.ksign.com (8.11.1/8.11.1) with SMTP id f4ACHUq16352 for <[e-mail]>; Thu, 10 May 2001 21:17:30 +0900 (KST)
Message-ID: <00ab01c0d94b$1c440bd0$7afcaed3@yskim>
From: "Yosik Kim" <[e-mail]>
To: <[e-mail]>
Subject: print BMP string in certificate(x509)
Date: Thu, 10 May 2001 21:16:57 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A8_01C0D996.8BA23880"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

This is a multi-part message in MIME format.

------=_NextPart_000_00A8_01C0D996.8BA23880
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

SGkNCkhvdyBjYW4gaSBwcmludCBCTVAoQmFzaWMgTXVsdGlsaWd1YWwgUGxhbmUpc3RyaW5nIGlu
IGNlcnRpZmljYXRlKFg1MDkpLg0KSSBjYW4ndCBjb252ZXJ0IHRvIHByaW50YWJsZSBzdHJpbmcg
dG8gQk1QIHN0cmluZy4NCg0KZXhhbXBsZSkNCg0KT3BlblNTTD4geDUwOSAtaW5mb3JtIERFUiAt
aW4gcHBzMDc2X2Vudi5jZXIgLXN1YmplY3QNCnN1YmplY3Q9IC9DPUtSL089R292ZXJubWVudCBv
ZiBLb3JlYS9PVT1ceEM4cFx4QjJceEVDXHhDQ1x4QUQvT1U9XHhBRGxceEI5XHhFNFx4DQpBRG0v
T1U9XHhDNnhceEM3XHg5MFx4QURsXHhCOVx4RTRceEFDXHhGQy9DTj1wcHMwNzYNCg0KQk1QIHN0
cmluZyBpcyBub3QgcHJpbnQoT3BlblNTTCkuIFNvIEkgbWFkZSBmdW5jdGlvbi4gQnV0IEl0IGRv
ZXNuJ3Qgd29yay4NCg0KVGhhbmtzIGluIGFkdmFuY2UuDQoNCkRhcnJlbi4NCg0K

------=_NextPart_000_00A8_01C0D996.8BA23880
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T
SFRNTCA1LjUwLjQ1MjIuMTgwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv
SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhpPEJSPkhv
dyBjYW4gaSBwcmludCBCTVAoQmFzaWMgTXVsdGlsaWd1YWwgUGxhbmUpc3RyaW5nIGluIA0KY2Vy
dGlmaWNhdGUoWDUwOSkuPEJSPkkgY2FuJ3QgY29udmVydCB0byBwcmludGFibGUgc3RyaW5nIHRv
IEJNUCANCnN0cmluZy48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9O
VCBzaXplPTI+ZXhhbXBsZSk8L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48
Rk9OVCBzaXplPTI+T3BlblNTTCZndDsgeDUwOSAtaW5mb3JtIERFUiAtaW4gcHBzMDc2X2Vudi5j
ZXIgDQotc3ViamVjdDxCUj5zdWJqZWN0PSAvQz1LUi9PPUdvdmVybm1lbnQgb2YgDQpLb3JlYS9P
VT1ceEM4cFx4QjJceEVDXHhDQ1x4QUQvT1U9XHhBRGxceEI5XHhFNFx4PEJSPkFEbS9PVT1ceEM2
eFx4QzdceDkwXHhBRGxceEI5XHhFNFx4QUNceEZDL0NOPXBwczA3NjwvRk9OVD48L0RJVj4NCjxE
SVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5CTVAgc3RyaW5nIGlzIG5vdCBwcmlu
dChPcGVuU1NMKS4gU28gSSBtYWRlIGZ1bmN0aW9uLiBCdXQgSXQgDQpkb2Vzbid0IHdvcmsuPC9G
T05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlRoYW5rcyBp
biBhZHZhbmNlLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNp
emU9Mj5EYXJyZW4uPEJSPjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K

------=_NextPart_000_00A8_01C0D996.8BA23880--



Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA09059 for <[e-mail]>; Thu, 10 May 2001 02:34:57 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA23760; Thu, 10 May 2001 11:34:55 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id LAA12924; Thu, 10 May 2001 11:34:20 +0200
Message-ID: <[e-mail]>
Date: Thu, 10 May 2001 11:34:24 +0200
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Sharon Boeyen <[e-mail]>
CC: [e-mail]
Subject: Re: delta-CRLs
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Sharon,

I nearly missed you e-mail. Sorry about this.

> Sorry to help 'drag out' this discussion, but a couple of points:
> 
> 1) Denis, your comment about CRL numbers needing to be unique, regardless
> of the scope of the CRL is incorrect. Check the text in 509 clause 8.5.2.1
> (CRL number extension) which says "This CRL extension field conveys a
> montonically increasing sequence number for each CRL issued by a given CRL
> issuer through a given authority directory attribute or CRL distribution
> point. ..."

As it has already been responded, the delta CRL and the base CRL have the
same scope and thus must have unique numbers.

Denis

> For that reason, another extension was added (see 8.5.2.7 of 509) called
> cRLStreamIdentifier. This is used to identify the context within which the
> CRL number is unique.
> 
> Second, I want to make sure everyone understands that the quote from 97
> 509 12.6.3.3 by David is text that was replaced in the 4th edition because
> it was overly restrictive.
> 
> As for the length of messages, I know I find myself constantly quoting
> 509. Others do the same and others quote 2459. I do believe the editors
> have worked closely together to ensure that what we end up with in PKIX is
> a profile of 509 (with changes being made to both documents as required).
> However, I can't help but wonder if we could cut down on the length of
> some of these messages if everyone who cares about the topic would first
> go and read both documents before submitting messages that purport to
> state what the standards say. This discussion is taking a lot of time on
> the part of many people and perhaps we could cut down on some of that by
> going back and reading what the standards say.
> 
> (It's friday afternoon, what can I say :-)
> 
> Sharon


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA08271 for <[e-mail]>; Thu, 10 May 2001 02:31:29 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA20066; Thu, 10 May 2001 11:31:24 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id LAA12902; Thu, 10 May 2001 11:30:44 +0200
Message-ID: <[e-mail]>
Date: Thu, 10 May 2001 11:30:48 +0200
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Ambarish Malpani <[e-mail]>
CC: "'Housley, Russ '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: Re: Certificate Hold (was RE: delta CRLs)
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ambarish,
 
> Russ, while I don't object to us deprecating the use of certificate
> suspension, I don't think we should prohibit its usage.

I would object to deprecate the use of certificate suspension using CRLs.

> 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.
 
> I don't agree with us saying that PKIX supports suspension only via
> OCSP - that just sounds wrong to me.

I support the two other points.

Regards,

Denis

> Regards,
> Ambarish
> 
> -----Original Message-----
> From: Housley, Russ
> To: Tom Gindin
> Cc: [e-mail]
> Sent: 5/7/01 10:13 AM
> Subject: RE: Certificate Hold (was RE: delta CRLs)
> 
> Tom:
> 
> I have not been able to make myself clear.  Perhaps because you keep
> looking to simple authentication applications.  My hope is that the PKIX
> 
> profile will readily meet the needs of these relatively straightforward
> applications and also support the more demanding needs of applications
> where non-repudiation is needed.
> 
> All:
> 
> My view of the question is that three people have voiced a desire to see
> 
> the suspension feature removed, one is asking questions without voicing
> a
> position, and no one has asked to keep it.  People who have an opinion
> but
> have not posted it yet please do so.
> 
> Russ


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA05296 for <[e-mail]>; Thu, 10 May 2001 01:54:50 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA12320; Thu, 10 May 2001 10:54:47 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id KAA13360; Thu, 10 May 2001 10:54:13 +0200
Message-ID: <[e-mail]>
Date: Thu, 10 May 2001 10:54:16 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: "'[e-mail] '" <[e-mail]>
Subject: Re: Certificate Hold (was RE: delta CRLs)
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Santosh,

> Some times people put a certificate on hold because some one is out of
> 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
> period should be considered invalid.

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
 
> -----Original Message-----
> From: Hal Lockhart [mailto:[e-mail]]
> Sent: Tuesday, May 08, 2001 11:47 AM
> To: 'Ambarish Malpani'; 'Housley, Russ '; 'Tom Gindin '
> Cc: '[e-mail] '
> 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


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA00928 for <[e-mail]>; Thu, 10 May 2001 01:19:53 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA12620 for <[e-mail]>; Thu, 10 May 2001 10:19:51 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id KAA15138 for <[e-mail]>; Thu, 10 May 2001 10:19:17 +0200
Message-ID: <[e-mail]>
Date: Thu, 10 May 2001 10:19:21 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: delta CRLs
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tim, David, Russ, Santosh, Carlin, and many others ...

There is difference between a base CRL and a full CRL : a base CRL MUST
include a freshestCRL extension (a.k.a. a Delta CRL distribution point),
whereas a full CRL may not include that extension. In other words, a base
CRL is a also a full CRL, but a full CRL is not necessarily a base CRL.

At any time a CA may issue a full CRL, whether or not a base CRL has already
been issued. This additional CRL SHOULD have nextUpdate equal to the
nextUpdate of the last issued full CRL. However, there is no guarantee that
this additional CRL will ever be seen by the relying party (because there
will be two CRLs matching the thisUpdate and nextUpdate rule and if one is
deleted, this is not seen by a relying party).

Due to the fact that CRLs numbers are strictly increasing, two CRLs whether
they are a base CRL or delta CRL, CANNOT have the same CRL number. So a
delta CRL and a full CRL that cover the same scope and are issued at the
same time CANNOT have the same number. If a full CRL is issued, its CRL
number bears no relationship with the previous base CRL, if any. The only
relationship between the numbers is defined by the rule that CRLs numbers
are strictly increasing. As Santosh said : "the CRL number is unique
whether it is a base or a delta ". 

This is fairly important to be able to unambiguously (and thus uniquely)
refer to a CRL by only providing its CRL number.

Besides the fact that a CRL issued later MUST have a higher CRL number, full
CRLs and delta CRLs have independent numbering rules. As noticed by Santosh,
" if the delta thisUpdate > base thisUpdate, delta CRL number > base CRL
number (for the same or no stream identifier).

As Santosh said : "a check based on thisUpdate is more general and
preferred [to the use of CRL numbers]. "

Related to the three rules mentioned by Russ :

1) the first rule is not understandable to me.
2) the second rule does not say anything more than the basic rule valid 
   for any CRL (i.e. a CRL issued later MUST have a higher CRL number).
3) we will debate the hold condition, once we will have sorted the main
   issue.

Russ said : "If separate number sequence is used, then you will have to
periodically fetch base CRLs ". This is true. 

Tim said that he would *not* like to be forced to download new base CRLs.
This is the core of the "dispute".

>From the definition of what a delta CRL is, it is *not* possible to
get rid of the fetching of base CRLs. Unless we add a new sentence to
expand/change that definition, base CRL fetching will remain mandatory.

Remember that the goal of delta CRLs is to provide the freshest information,
and to my knowledge the goal was not to get rid of the fetching of base CRLs
(which may less frequent due to the support of delta CRLs).

If I understand correctly, Tim/David/Russ would like to *always* achieve the
following property : it is possible to reconstruct the current CRL by using
a base CRL from, e.g. 1990, i.e. by capturing every delta CRL that has been
issued at the same time a base CRL was issued and which contains updates
made to the *previous* base. 

By this way the fetching of base CRLs could be avoided. However, note that
it is perfectly " legal " to stop issuing base and delta CRLs during some
period of time and to issue full CRLs instead (see the difference between
"full" and "base" at the top of this e-mail). In other words there is no
need to issue a new base CRL at the end of the validity period of the
previous base CRL. Doing this would mandate to prescribe issuing rules 
for CAs that we have not prescripted.

I will now raise a series of questions, for which I believe we have
different answers. Tim/David/Russ do not hesitate to correct 
if my guess is wrong. ;-)

Common point:

1) What will be the value of the nextUpdate field from the last issued delta
CRL for a given base CRL ? 

Denis: the nextUpdate field from the last issued delta CRL MUST be equal to
the value of nextUpdate from the base CRL.

Tim/David/Russ: ???

2) Does a CA needs to issue a delta CRL at the time a full CRL is issued ?

Denis: No.
Tim/David/Russ : ???

3) Does a CA needs to issue a new base CRL at the end of the validity of a
current base CRL ?

Denis: No.
Tim/David/Russ : ???

4) Does a CA needs to issue a delta CRL at the same time a new base is
issued ?

Denis: Yes. The delta CRL refers to the *new* base.
Tim/David/Russ : Yes. The delta CRL refers to the *previous* base. [Note
that there can be no previous at all, or the "previous" may even be three
months old]. 

The last point highlights the most noticeable difference. Other differences
appears when considering the guaranty to get the freshest information :
using the traditional scheme and the thisUpdate and nextUpdate fields the
guaranty to get the freshest information is obtained, but cannot be obtained
using the other scheme. :-(

Several people are referring to the X.509 document for arguments to support
that discussion. However, it is important to remember that we are defining
PKIX, not X.509, so we DO NOT need to copy and paste everything from X.509,
but only what we believe is relevant.

We first need to clearly define the processing rules applicable to the
relying parties. These rules will certainly contain SHALL/MUST statements,
but may also include some MAY statements which may even be conditional to
what the CA is doing. (I let Tim/David or Russ provide the MAY statement).

Here is a proposal for the MUST statement, based on the previous text I
produced:

   An application that is wishing to take advantage of delta CRLs 
   for a given scope, MUST first find a base CRL for that scope, 
   i.e. a full CRL that that contains a freshestCRL extension 
   (a.k.a. a Delta CRL distribution point). It may then construct 
   an updated CRL for that base, for a specific time T, by combining 
   it with a delta CRL which contains a delta CRL indicator extension 
   with the same CRL number as the base CRL. Applications that support 
   delta CRLs MUST ensure that time T falls between thisUpdate and 
   nextUpdate for both the base CRL and the delta CRL.

   Note: An application could also reconstruct an updated CRL, for 
   a specific time T, by using a previously locally reconstructed CRL 
   based on the current base CRL, and combining it with a delta CRL which 
   contains a delta CRL indicator extension with the same CRL number as 
   the base CRL.

We also need to clearly separate the issuing rules applicable for the CAs.
These rules will certainly contain SHALL statements, but could also include
some MAY statements. (I let Tim/David or Russ provide the MAY statement).

Here is a proposal for the MUST statement, based on the previous text I
produced:

   A CA that supports delta-CRLs, MUST issue a base CRL, i.e. a full 
   CRL that contains a freshestCRL extension (a.k.a. a Delta CRL 
   distribution point). For any time T until the nextUpdate time 
   indicated in a base CRL, the CA MUST provide one and only one 
   delta CRL that refers to that base CRL and for which time T 
   falls between thisUpdate and nextUpdate from the delta CRL.

In his e-mail from Wednesday, May 9, David said that delta-CRL processing
rules could be base on time instead of CRL numbers. This is a point of which
I strongly agree. Let us do it!

(However, there is no need to add to PKIX, as he suggested, the support of
the baseUpdateTime extension from X.509 which would even more complicate the
problem.)

Regards,

Denis


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA00634 for <[e-mail]>; Thu, 10 May 2001 01:12:40 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA21042; Thu, 10 May 2001 10:12:39 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id KAA15130; Thu, 10 May 2001 10:12:05 +0200
Message-ID: <[e-mail]>
Date: Thu, 10 May 2001 10:12:08 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Carlin Covey <[e-mail]>
CC: [e-mail]
Subject: Re: delta CRLs
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Carlin,

> Having heard several persons speak for assigning the same CRL number
> to simultaneously-issued delta-CRLs and full CRLs, 
> and no one speak against, I find myself convinced that they should 
> be assigned the same CRL number.  Thanks for the convincing arguments.

Have you missed my e-mails ? I don't think you can say that "no one speak
against". I did. 

Regards,

Denis


Received: from internet.across ([213.212.5.232]) by above.proper.com (8.9.3/8.9.3) with SMTP id AAA23576 for <[e-mail]>; Thu, 10 May 2001 00:14:24 -0700 (PDT)
Received: FROM acrossw01.acrosswireless.com BY internet.across ; Thu May 10 09:19:27 2001 +0200
Received: by acrossw01.acrosswireless.com with Internet Mail Service (5.5.2650.21) id <KTJ6P5NV>; Thu, 10 May 2001 09:12:50 +0200
Message-ID: <[e-mail]>
From: Olle Larsson <[e-mail]>
To: "'Carlin Covey'" <[e-mail]>, [e-mail]
Subject: RE: delta CRLs
Date: Thu, 10 May 2001 09:12:50 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D920.9F78F860"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D920.9F78F860
Content-Type: text/plain;
	charset="iso-8859-1"

Just want to point out that it DOES matter if the delta and the full CRL
have the same number or not, when issued at the same time and reflecting the
same set of revocation information.
 
Consider a client that tries to construct the local 'virtual' base CRL that
Peter Sylvester mentioned. That virtual base CRL will then have a crlNumber
= n = that of the dCRL used to update the local repository.
 
A while later, another dCRL is fetched. If the referred base CRL number m >
n, we are in trouble. 
 
In other words, a full CRL must always have a CRL number >= the CRL number
of the delta CRL that is issued at the same time and reflecting the same set
of revocation information.
 
<academical> The thisUpdate field is of no use, as computers are fast these
days and you cannot know for a fact that another full CRL m hasn't been
issued in the very same second interval as CRL n, possibly containing more
revocation information that will be missed in the virtual base CRL.
</academical>
 
Considering this, I would second Santosh's revised wording as well.
 
/Olle
 
-----Original Message-----
From: Carlin Covey [mailto:[e-mail]]
Sent: Wednesday, May 09, 2001 9:23 PM
To: [e-mail]
Subject: RE: delta CRLs


Having heard several persons speak for assigning the same CRL number to
simultaneously-issued delta-CRLs and full CRLs, and no one speak against, I
find myself convinced that they should be assigned the same CRL number.
Thanks for the convincing arguments.
 
P.S.  I still like Santosh's revised wording:
 
----------------------
 
        Thus, if two CRLs (in the same stream identifier or when stream
identifier is absent), have numbers n and m, the following shall be true
(assuming no wrapping) 

        n = m if and only if thisUpdate of n = thisUpdate of m 

        n > m if and only if thisUpdate of n > thisUpdate of m 

        n < m if and only if thisUpdate of n < thisUpdate of m 

--------------------

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation 

-----Original Message-----
From: Carlin Covey [mailto:[e-mail]]
Sent: Wednesday, May 09, 2001 10:35 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: delta CRLs


Santosh,
 
I don't see that it matters whether the delta-CRL or the full CRL is
assigned the earlier number.  But I'm not hard over about assigning them
different numbers.  I'm still willing to be convinced that it is bad that
they have different numbers, or good that they have the same number.
Earlier today Stephen Henson presented one argument for numbering them the
same.  Perhaps that is a compelling reason.
 
Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation 

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Wednesday, May 09, 2001 10:13 AM
To: Carlin Covey; Santosh Chokhani
Cc: [e-mail]
Subject: RE: delta CRLs


Are you suggesting that when they are issued at the same time, they should
still have a different CRL number?
 
Which one should have the number n and which one n+1?
 
-----Original Message-----
From: Carlin Covey [mailto:[e-mail]]
Sent: Wednesday, May 09, 2001 1:16 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: delta CRLs


Santosh,
 
If simultaneously-issued delta-CRLs and full CRLs are to be numbered the
same, I think your wording is a significant improvement over the current
wording.  However, I'm still undecided whether they should be numbered the
same.  It seems like simultaneously-issued delta-CRLs and full CRLs (and
constructed CRLs) could be matched via the thisUpdate field without the
necessity of violating the strictly increasing provision for CRL numbers.  A
unique reference for each CRL would be useful for evidentiary purposes, and
for historical validation.  Rendering a CRL identifier unique already
requires the issuer ID, the set of reason codes, the set of certificate
types, and either the CRL number or the thisUpdate value.  I wonder if it is
necessary to add the full vs. delta status as well.
 
- Carlin
 
 -----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Wednesday, May 09, 2001 9:28 AM
To: Carlin Covey; [e-mail]; David A. Cooper; [e-mail];
Santosh Chokhani
Cc: [e-mail]
Subject: RE: delta CRLs



I am simply suggesting that the numbers be strictly increasing, but if a
base and delta are generated at the same time, they will have the same
sequence number.  Thus, if two CRLs (in the same stream identifier or when
stream identifier is absent), have numbers n and m, the following shall be
true (assuming no wrapping)

 n = m if and only if thisUpdate of n = thisUpdate of m 

 n > m if and only if thisUpdate of n > thisUpdate of m 

 n < m if and only if thisUpdate of n < thisUpdate of m 

-----Original Message----- 
From: Carlin Covey [ mailto:[e-mail] <mailto:[e-mail]> ] 
Sent: Wednesday, May 09, 2001 11:28 AM 
To: [e-mail]; David A. Cooper; [e-mail]; 
[e-mail] 
Cc: [e-mail] 
Subject: RE: delta CRLs 


David, Stephen, Ambarish, and Santosh, 

Some of us are in the business for the looooong haul.  ;>) 

Actually, I wasn't concerned about the CRL number wrapping, but that 
possibility was advanced a few days ago as an argument against the use of 
the "strictly increasing" wording.  Another email commented that PKIX did 
not permit the number to wrap, although X.509 might.  The only evidence I 
could find for X.509 permitting the number to wrap was "(0 .. MAX)".  As 
various people have pointed out, one could be drumming one's fingers for 
quite a while........ 

My real point was that the "monotonically increasing" wording permits the 
CRL number to stay the same, while "strictly increasing" forces the numbers 
to be unique (issues of wrapping aside in both cases).  Stephen Henson just 
pointed out a reason why one might want the CRL number to stay the same when

issuing a delta CRL at the same time as a full CRL.  I am not arguing either

for or against that case, but it seems desirable to force the CRL numbers to

be unique in most cases.  (Unless, the CRLs are distinguished based upon 
thisUpdate, as Santosh has suggested.) 

Regards, 

Carlin 

____________________________ 

-  Carlin Covey 
   Cylink Corporation 



-----Original Message----- 
From: David A. Cooper [ mailto:[e-mail]
<mailto:[e-mail]> ] 
Sent: Wednesday, May 09, 2001 6:03 AM 
To: '[e-mail] ' 
Subject: RE: delta CRLs 


 From a practical point of view, I don't think that we should need to worry 
about CRL numbers wrapping.  According to my calculations, if one assigns 
cRLNumber 1 to the first CRL and then numbers CRLs consecutively, one could 
issue a new CRL every second for 68 years before the cRLNumber would require

more than 4 bytes (32 bits) to encode.  On the other hand, if you're willing

to issue a new CRL only once a minute, it would take 4083 years before the 
cRLNumber would require more than 4 bytes to encode. 

BTW, I thought that the purpose of the "(0 .. MAX)" was just to prevent use 
of negative numbers. While there may, in theory be a limit to the size of an

integer that may be encoded, for all practical purposes, one can encode any 
integet. According to "A Layman's Guide to a Subset of ASN.1, BER, and DER",

a DER encoded value can have a length of up to 2 ** 1008 - 1 bytes. Thus, 
MAX = 2 ** [8 * ((2 ** 1008) - 1) - 1] - 1, which is far larger than any 
number we would ever need. 

Dave 

At 08:57 PM 5/8/01 -0700, Ambarish Malpani wrote: 
> 
>I always thought MAX for ASN.1 INTEGERs was something I would never 
>need to worry about. 
> 
>Looks like I was wrong :-) 
> 
>By the way, what is MAX? I know that we can represent numbers with 
>over 2048 bits... 
> 
>A 
> 
>-----Original Message----- 
>From: Carlin Covey 
>To: Housley, Russ; Santosh Chokhani 
>Cc: [e-mail] 
>Sent: 5/8/01 5:53 PM 
>Subject: RE: delta CRLs 
> 
>Russ, 
> 
>A week or two ago we arrived at a consensus to remove the requirement 
>that a CA issue a full CRL whenever the CA issues a Delta-CRL.  If the 
>CA chooses to issue them simultaneously, why would they need to be numbered

>the same?  If this requirement were lifted, it seems like requiring the CRL

>number to be "strictly increasing" in a sequence would be preferable to 
>"monotonically increasing".  "Monotonically increasing" allows the 
possibility 
>that the CRL number never changes, which seems undesirable.  I realize 
>that in either case the CRL number might wrap around at some point in the 
future. 
>That is inevitable, given that that CRL number is defined as INTEGER 
(0..MAX). 
>What else can a CA do when CRL number reaches MAX, stop issuing CRLs? 
> 
>"monotonically increasing" - Definition: A function from a partially 
order[ed] 
>domain to a partially ordered range such that x >= y implies f(x) >= f(y). 
> 
>- From the NIST web site: 
> http://hissa.nist.gov/dads/HTML/monotoncincr.html
<http://hissa.nist.gov/dads/HTML/monotoncincr.html>  
> 
>Regards, 
> 
>Carlin 
> 
>____________________________ 
> 
>-  Carlin Covey 
>    Cylink Corporation 
> 
>-----Original Message----- 
>From: Housley, Russ [ mailto:[e-mail]
<mailto:[e-mail]> ] 
>Sent: Monday, May 07, 2001 6:21 AM 
>To: Santosh Chokhani 
>Cc: [e-mail] 
>Subject: RE: delta CRLs 
> 
> 
>Santosh: 
> 
>X.509 may allow the CRL number to wrap around, but I do not believe that 
>PKIX does. 
> 
>     5.2.3  CRL Number 
> 
>     The CRL number is a non-critical CRL extension which conveys a 
>     monotonically increasing sequence number for each CRL issued by a CA. 
>     This extension allows users to easily determine when a particular CRL 
>     supersedes another CRL.  CAs conforming to this profile MUST include 
>     this extension in all CRLs. 
> 
>     id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 
> 
>Russ 
> 
> 
>At 10:11 PM 5/5/2001 -0400, Santosh Chokhani wrote: 
> 
> >Actually, the text allows for the wrap of the numbers.  Please see Annex 
B 
> >of X.509.  Thus, it is not strictly increasing 
> > 
> >-----Original Message----- 
> >From: Peter Sylvester 
> >[< mailto:[e-mail] <mailto:[e-mail]>
> mailto:[e-mail] <mailto:[e-mail]> ] 
> >Sent: Saturday, May 05, 2001 2:08 PM 
> >To: [e-mail]; [e-mail]; 
> >[e-mail] 
> >Cc: [e-mail] 
> >Subject: RE: delta CRLs 
> > 
> > > Trevor: 
> > > 
> > > The 2000 version of X.509 is very clear on this.  For a given CRL 
stream 
> > > identifier, the CRL number is unique whether it is base or delta. That

is 
> > > why delta number has to be greater than the base. 
> > 
> >" 8.5.2.1 CRL number extension 
> > 
> >   This CRL extension field conveys a monotonically increasing sequence 
> > number .." 
> > 
> >The text might be clearer IMHO if 'strictly increasing' would be used 
> >instead. 


------_=_NextPart_001_01C0D920.9F78F860
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: delta CRLs</TITLE>

<META content="MSHTML 5.50.4611.1300" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=064004006-10052001>Just 
want to point out that it DOES matter if the delta and the full CRL have the 
same number or not, when issued at the same time and reflecting the same set of 
revocation information.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=064004006-10052001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=064004006-10052001>Consider a client that tries to construct&nbsp;the 
local 'virtual' base CRL&nbsp;that Peter Sylvester mentioned. That&nbsp;virtual 
base CRL will then have a crlNumber =&nbsp;n = that of the dCRL used to update 
the local repository.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=064004006-10052001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=064004006-10052001>A 
while later, another dCRL is fetched. If the referred base CRL number m &gt; n, 
we are in trouble. </SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=064004006-10052001></SPAN></FONT>&nbsp;</DIV><FONT face=Arial 
color=#0000ff size=2><SPAN class=064004006-10052001>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=064004006-10052001>In 
other words, a full CRL must always have a CRL number &gt;= the CRL number of 
the delta CRL that is issued at the same time and reflecting the same set of 
revocation information.</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&lt;academical&gt; The thisUpdate field is of no use, as computers are fast 
these days and you cannot know for a fact that another full CRL m 
hasn't</SPAN></FONT><FONT face=Arial color=#0000ff size=2><SPAN 
class=064004006-10052001>&nbsp;been issued in the very same second interval as 
CRL n, possibly containing more revocation information that will be missed in 
the virtual base CRL. </SPAN></FONT><FONT face=Arial color=#0000ff size=2><SPAN 
class=064004006-10052001><SPAN 
class=064004006-10052001>&lt;/academical&gt;</SPAN></SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=064004006-10052001><SPAN 
class=064004006-10052001></SPAN></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=064004006-10052001>Considering this, I would second Santosh's revised 
wording as well.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=064004006-10052001><FONT 
face=Arial color=#0000ff size=2><SPAN 
class=064004006-10052001></SPAN></FONT>&nbsp;</DIV>
<DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=064004006-10052001>/Olle</SPAN></FONT></DIV></SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
size=2>-----Original Message-----<BR><B>From:</B> Carlin Covey 
[mailto:[e-mail]]<BR><B>Sent:</B> Wednesday, May 09, 2001 9:23 
PM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> RE: delta 
CRLs<BR><BR></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=309141619-09052001>Having 
heard several persons speak for assigning the same CRL number to 
simultaneously-issued delta-CRLs and full CRLs, and no one speak against, I find 
myself convinced that they should be assigned the same CRL number.&nbsp; Thanks 
for the convincing arguments.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=309141619-09052001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=309141619-09052001>P.S.&nbsp; I still like Santosh's revised 
wording:</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=309141619-09052001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=309141619-09052001>----------------------</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=309141619-09052001></SPAN></FONT>&nbsp;</DIV>
<DIV><SPAN class=309141619-09052001><FONT face=Arial color=#0000ff 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Thus, if two CRLs (in the same 
stream identifier or when stream identifier is absent), have numbers n and m, 
the following shall be true&nbsp;(assuming no wrapping)</FONT> 
<P><FONT color=#0000ff><FONT face=Arial size=2>&nbsp;<SPAN 
class=309141619-09052001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>n = m if 
and only if thisUpdate of n = thisUpdate of m </FONT></FONT></P>
<P><FONT face=Arial color=#0000ff size=2>&nbsp;<SPAN 
class=309141619-09052001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>n &gt; 
m if and only if thisUpdate of n &gt; thisUpdate of m </FONT></P>
<P><FONT face=Arial color=#0000ff size=2>&nbsp;<SPAN 
class=309141619-09052001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>n &lt; m if 
and only if thisUpdate of n &lt; thisUpdate of m </FONT></P>
<P><FONT face=Arial color=#0000ff size=2><SPAN 
class=309141619-09052001>--------------------</SPAN></FONT></P><FONT face=Arial 
color=#0000ff size=2><SPAN class=309141619-09052001>
<P><FONT 
size=2>Regards,<BR><BR>Carlin<BR><BR>____________________________<BR><BR>-&nbsp; 
Carlin Covey<BR>&nbsp;&nbsp; Cylink Corporation 
</FONT></P></SPAN></FONT></SPAN></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Carlin Covey 
  [mailto:[e-mail]]<BR><B>Sent:</B> Wednesday, May 09, 2001 10:35 
  AM<BR><B>To:</B> Santosh Chokhani<BR><B>Cc:</B> 
  [e-mail]<BR><B>Subject:</B> RE: delta CRLs<BR><BR></DIV></FONT>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=121152317-09052001>Santosh,</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=121152317-09052001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=121152317-09052001>I 
  don't see that it matters whether the delta-CRL or the full CRL is assigned 
  the earlier number.&nbsp; But I'm not hard over about&nbsp;assigning them 
  different numbers.&nbsp; I'm still willing to be convinced that it is bad that 
  they have different numbers, or good that they have the same number.&nbsp; 
  Earlier today Stephen Henson presented one argument for numbering them the 
  same.&nbsp; Perhaps that is a compelling reason.</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=121152317-09052001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=121152317-09052001>
  <P><FONT 
  size=2>Regards,<BR><BR>Carlin<BR><BR>____________________________<BR><BR>-&nbsp; 
  Carlin Covey<BR>&nbsp;&nbsp; Cylink Corporation 
</FONT></P></SPAN></FONT></DIV>
  <BLOCKQUOTE style="MARGIN-RIGHT: 0px">
    <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Santosh Chokhani 
    [mailto:[e-mail]]<BR><B>Sent:</B> Wednesday, May 09, 2001 10:13 
    AM<BR><B>To:</B> Carlin Covey; Santosh Chokhani<BR><B>Cc:</B> 
    [e-mail]<BR><B>Subject:</B> RE: delta CRLs<BR><BR></DIV></FONT>
    <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
    class=742462017-09052001>Are you suggesting that when they are issued at the 
    same time, they should still have a different CRL 
number?</SPAN></FONT></DIV>
    <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
    class=742462017-09052001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
    class=742462017-09052001>Which one should have the number n and which one 
    n+1?</SPAN></FONT></DIV>
    <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
    class=742462017-09052001></SPAN></FONT>&nbsp;</DIV>
    <DIV class=OutlookMessageHeader><FONT face="Times New Roman" 
    size=2>-----Original Message-----<BR><B>From:</B> Carlin Covey 
    [mailto:[e-mail]]<BR><B>Sent:</B> Wednesday, May 09, 2001 1:16 
    PM<BR><B>To:</B> Santosh Chokhani<BR><B>Cc:</B> 
    [e-mail]<BR><B>Subject:</B> RE: delta CRLs<BR><BR></FONT></DIV>
    <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
    class=523265216-09052001>Santosh,</SPAN></FONT></DIV>
    <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
    class=523265216-09052001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=523265216-09052001>If 
    simultaneously-issued delta-CRLs and full CRLs are to be numbered the same, 
    I think your wording is a significant improvement over the current 
    wording.&nbsp; However, I'm still undecided whether they should be numbered 
    the same.&nbsp; It seems like simultaneously-issued delta-CRLs and full CRLs 
    (and constructed CRLs) could be matched via the thisUpdate field without the 
    necessity of violating the strictly increasing provision for CRL 
    numbers.&nbsp; A unique reference for each CRL would be useful for 
    evidentiary purposes, and for historical validation.&nbsp;&nbsp;Rendering a 
    CRL identifier unique already requires the issuer ID, the set of 
    reason&nbsp;codes, the set of certificate types, and either the CRL number 
    or the thisUpdate value.&nbsp; I wonder if it is necessary to add the full 
    vs. delta status as well.</SPAN></FONT></DIV>
    <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
    class=523265216-09052001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=523265216-09052001>- 
    Carlin</SPAN></FONT></DIV>
    <DIV><SPAN class=523265216-09052001></SPAN><FONT face=Tahoma><FONT 
    size=2><SPAN class=523265216-09052001><FONT face=Arial 
    color=#0000ff></FONT></SPAN></FONT></FONT>&nbsp;</DIV>
    <DIV><FONT face=Tahoma><FONT size=2><SPAN 
    class=523265216-09052001>&nbsp;</SPAN>-----Original 
    Message-----<BR><B>From:</B> Santosh Chokhani 
    [mailto:[e-mail]]<BR><B>Sent:</B> Wednesday, May 09, 2001 9:28 
    AM<BR><B>To:</B> Carlin Covey; [e-mail]; David A. Cooper; 
    [e-mail]; Santosh Chokhani<BR><B>Cc:</B> 
    [e-mail]<BR><B>Subject:</B> RE: delta CRLs<BR><BR></DIV></FONT>
    <BLOCKQUOTE style="MARGIN-RIGHT: 0px"></FONT>
      <P><FONT size=2>I am simply suggesting that the numbers be strictly 
      increasing, but if a base and delta are generated at the same time, they 
      will have the same sequence number.&nbsp; Thus, if two CRLs (in the same 
      stream identifier or when stream identifier is absent), have numbers n and 
      m, the following shall be true (assuming no wrapping)</FONT></P>
      <P><FONT size=2>&nbsp;n = m if and only if thisUpdate of n = thisUpdate of 
      m</FONT> </P>
      <P><FONT size=2>&nbsp;n &gt; m if and only if thisUpdate of n &gt; 
      thisUpdate of m</FONT> </P>
      <P><FONT size=2>&nbsp;n &lt; m if and only if thisUpdate of n &lt; 
      thisUpdate of m</FONT> </P>
      <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: 
      Carlin Covey [<A 
      href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
      <BR><FONT size=2>Sent: Wednesday, May 09, 2001 11:28 AM</FONT> <BR><FONT 
      size=2>To: [e-mail]; David A. Cooper; [e-mail];</FONT> 
      <BR><FONT size=2>[e-mail]</FONT> <BR><FONT size=2>Cc: 
      [e-mail]</FONT> <BR><FONT size=2>Subject: RE: delta CRLs</FONT> 
      </P><BR>
      <P><FONT size=2>David, Stephen, Ambarish, and Santosh,</FONT> </P>
      <P><FONT size=2>Some of us are in the business for the looooong 
      haul.&nbsp; ;&gt;)</FONT> </P>
      <P><FONT size=2>Actually, I wasn't concerned about the CRL number 
      wrapping, but that</FONT> <BR><FONT size=2>possibility was advanced a few 
      days ago as an argument against the use of</FONT> <BR><FONT size=2>the 
      "strictly increasing" wording.&nbsp; Another email commented that PKIX 
      did</FONT> <BR><FONT size=2>not permit the number to wrap, although X.509 
      might.&nbsp; The only evidence I</FONT> <BR><FONT size=2>could find for 
      X.509 permitting the number to wrap was "(0 .. MAX)".&nbsp; As</FONT> 
      <BR><FONT size=2>various people have pointed out, one could be drumming 
      one's fingers for</FONT> <BR><FONT size=2>quite a while........</FONT> 
</P>
      <P><FONT size=2>My real point was that the "monotonically increasing" 
      wording permits the</FONT> <BR><FONT size=2>CRL number to stay the same, 
      while "strictly increasing" forces the numbers</FONT> <BR><FONT size=2>to 
      be unique (issues of wrapping aside in both cases).&nbsp; Stephen Henson 
      just</FONT> <BR><FONT size=2>pointed out a reason why one might want the 
      CRL number to stay the same when</FONT> <BR><FONT size=2>issuing a delta 
      CRL at the same time as a full CRL.&nbsp; I am not arguing either</FONT> 
      <BR><FONT size=2>for or against that case, but it seems desirable to force 
      the CRL numbers to</FONT> <BR><FONT size=2>be unique in most cases.&nbsp; 
      (Unless, the CRLs are distinguished based upon</FONT> <BR><FONT 
      size=2>thisUpdate, as Santosh has suggested.)</FONT> </P>
      <P><FONT size=2>Regards,</FONT> </P>
      <P><FONT size=2>Carlin</FONT> </P>
      <P><FONT size=2>____________________________</FONT> </P>
      <P><FONT size=2>-&nbsp; Carlin Covey</FONT> <BR><FONT size=2>&nbsp;&nbsp; 
      Cylink Corporation</FONT> </P><BR><BR>
      <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: 
      David A. Cooper [<A 
      href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
      <BR><FONT size=2>Sent: Wednesday, May 09, 2001 6:03 AM</FONT> <BR><FONT 
      size=2>To: '[e-mail] '</FONT> <BR><FONT size=2>Subject: RE: delta 
      CRLs</FONT> </P><BR>
      <P><FONT size=2>&nbsp;From a practical point of view, I don't think that 
      we should need to worry</FONT> <BR><FONT size=2>about CRL numbers 
      wrapping.&nbsp; According to my calculations, if one assigns</FONT> 
      <BR><FONT size=2>cRLNumber 1 to the first CRL and then numbers CRLs 
      consecutively, one could</FONT> <BR><FONT size=2>issue a new CRL every 
      second for 68 years before the cRLNumber would require</FONT> <BR><FONT 
      size=2>more than 4 bytes (32 bits) to encode.&nbsp; On the other hand, if 
      you're willing</FONT> <BR><FONT size=2>to issue a new CRL only once a 
      minute, it would take 4083 years before the</FONT> <BR><FONT 
      size=2>cRLNumber would require more than 4 bytes to encode.</FONT> </P>
      <P><FONT size=2>BTW, I thought that the purpose of the "(0 .. MAX)" was 
      just to prevent use</FONT> <BR><FONT size=2>of negative numbers. While 
      there may, in theory be a limit to the size of an</FONT> <BR><FONT 
      size=2>integer that may be encoded, for all practical purposes, one can 
      encode any</FONT> <BR><FONT size=2>integet. According to "A Layman's Guide 
      to a Subset of ASN.1, BER, and DER",</FONT> <BR><FONT size=2>a DER encoded 
      value can have a length of up to 2 ** 1008 - 1 bytes. Thus,</FONT> 
      <BR><FONT size=2>MAX = 2 ** [8 * ((2 ** 1008) - 1) - 1] - 1, which is far 
      larger than any</FONT> <BR><FONT size=2>number we would ever need.</FONT> 
      </P>
      <P><FONT size=2>Dave</FONT> </P>
      <P><FONT size=2>At 08:57 PM 5/8/01 -0700, Ambarish Malpani wrote:</FONT> 
      <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;I always thought MAX for 
      ASN.1 INTEGERs was something I would never</FONT> <BR><FONT 
      size=2>&gt;need to worry about.</FONT> <BR><FONT size=2>&gt;</FONT> 
      <BR><FONT size=2>&gt;Looks like I was wrong :-)</FONT> <BR><FONT 
      size=2>&gt;</FONT> <BR><FONT size=2>&gt;By the way, what is MAX? I know 
      that we can represent numbers with</FONT> <BR><FONT size=2>&gt;over 2048 
      bits...</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;A</FONT> 
      <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;-----Original 
      Message-----</FONT> <BR><FONT size=2>&gt;From: Carlin Covey</FONT> 
      <BR><FONT size=2>&gt;To: Housley, Russ; Santosh Chokhani</FONT> <BR><FONT 
      size=2>&gt;Cc: [e-mail]</FONT> <BR><FONT size=2>&gt;Sent: 5/8/01 
      5:53 PM</FONT> <BR><FONT size=2>&gt;Subject: RE: delta CRLs</FONT> 
      <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;Russ,</FONT> <BR><FONT 
      size=2>&gt;</FONT> <BR><FONT size=2>&gt;A week or two ago we arrived at a 
      consensus to remove the requirement</FONT> <BR><FONT size=2>&gt;that a CA 
      issue a full CRL whenever the CA issues a Delta-CRL.&nbsp; If the</FONT> 
      <BR><FONT size=2>&gt;CA chooses to issue them simultaneously, why would 
      they need to be numbered</FONT> <BR><FONT size=2>&gt;the same?&nbsp; If 
      this requirement were lifted, it seems like requiring the CRL</FONT> 
      <BR><FONT size=2>&gt;number to be "strictly increasing" in a sequence 
      would be preferable to</FONT> <BR><FONT size=2>&gt;"monotonically 
      increasing".&nbsp; "Monotonically increasing" allows the</FONT> <BR><FONT 
      size=2>possibility</FONT> <BR><FONT size=2>&gt;that the CRL number never 
      changes, which seems undesirable.&nbsp; I realize</FONT> <BR><FONT 
      size=2>&gt;that in either case the CRL number might wrap around at some 
      point in the</FONT> <BR><FONT size=2>future.</FONT> <BR><FONT 
      size=2>&gt;That is inevitable, given that that CRL number is defined as 
      INTEGER</FONT> <BR><FONT size=2>(0..MAX).</FONT> <BR><FONT size=2>&gt;What 
      else can a CA do when CRL number reaches MAX, stop issuing CRLs?</FONT> 
      <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;"monotonically 
      increasing" - Definition: A function from a partially</FONT> <BR><FONT 
      size=2>order[ed]</FONT> <BR><FONT size=2>&gt;domain to a partially ordered 
      range such that x &gt;= y implies f(x) &gt;= f(y).</FONT> <BR><FONT 
      size=2>&gt;</FONT> <BR><FONT size=2>&gt;- From the NIST web site:</FONT> 
      <BR><FONT size=2>&gt;<A target=_blank 
      href="http://hissa.nist.gov/dads/HTML/monotoncincr.html">http://hissa.nist.gov/dads/HTML/monotoncincr.html</A></FONT> 
      <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;Regards,</FONT> 
      <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;Carlin</FONT> <BR><FONT 
      size=2>&gt;</FONT> <BR><FONT 
      size=2>&gt;____________________________</FONT> <BR><FONT 
      size=2>&gt;</FONT> <BR><FONT size=2>&gt;-&nbsp; Carlin Covey</FONT> 
      <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp; Cylink Corporation</FONT> 
      <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;-----Original 
      Message-----</FONT> <BR><FONT size=2>&gt;From: Housley, Russ [<A 
      href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
      <BR><FONT size=2>&gt;Sent: Monday, May 07, 2001 6:21 AM</FONT> <BR><FONT 
      size=2>&gt;To: Santosh Chokhani</FONT> <BR><FONT size=2>&gt;Cc: 
      [e-mail]</FONT> <BR><FONT size=2>&gt;Subject: RE: delta 
      CRLs</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;</FONT> 
      <BR><FONT size=2>&gt;Santosh:</FONT> <BR><FONT size=2>&gt;</FONT> 
      <BR><FONT size=2>&gt;X.509 may allow the CRL number to wrap around, but I 
      do not believe that</FONT> <BR><FONT size=2>&gt;PKIX does.</FONT> 
      <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; 
      5.2.3&nbsp; CRL Number</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
      size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; The CRL number is a non-critical CRL 
      extension which conveys a</FONT> <BR><FONT 
      size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; monotonically increasing sequence 
      number for each CRL issued by a CA.</FONT> <BR><FONT 
      size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; This extension allows users to easily 
      determine when a particular CRL</FONT> <BR><FONT 
      size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; supersedes another CRL.&nbsp; CAs 
      conforming to this profile MUST include</FONT> <BR><FONT 
      size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; this extension in all CRLs.</FONT> 
      <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; 
      id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }</FONT> <BR><FONT 
      size=2>&gt;</FONT> <BR><FONT size=2>&gt;Russ</FONT> <BR><FONT 
      size=2>&gt;</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;At 
      10:11 PM 5/5/2001 -0400, Santosh Chokhani wrote:</FONT> <BR><FONT 
      size=2>&gt;</FONT> <BR><FONT size=2>&gt; &gt;Actually, the text allows for 
      the wrap of the numbers.&nbsp; Please see Annex</FONT> <BR><FONT 
      size=2>B</FONT> <BR><FONT size=2>&gt; &gt;of X.509.&nbsp; Thus, it is not 
      strictly increasing</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT 
      size=2>&gt; &gt;-----Original Message-----</FONT> <BR><FONT size=2>&gt; 
      &gt;From: Peter Sylvester</FONT> <BR><FONT size=2>&gt; &gt;[&lt;<A 
      href="mailto:[e-mail]">mailto:[e-mail]</A>&gt;<A 
      href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
      <BR><FONT size=2>&gt; &gt;Sent: Saturday, May 05, 2001 2:08 PM</FONT> 
      <BR><FONT size=2>&gt; &gt;To: [e-mail]; 
      [e-mail];</FONT> <BR><FONT size=2>&gt; 
      &gt;[e-mail]</FONT> <BR><FONT size=2>&gt; &gt;Cc: 
      [e-mail]</FONT> <BR><FONT size=2>&gt; &gt;Subject: RE: delta 
      CRLs</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; 
      &gt; Trevor:</FONT> <BR><FONT size=2>&gt; &gt; &gt;</FONT> <BR><FONT 
      size=2>&gt; &gt; &gt; The 2000 version of X.509 is very clear on 
      this.&nbsp; For a given CRL</FONT> <BR><FONT size=2>stream</FONT> 
      <BR><FONT size=2>&gt; &gt; &gt; identifier, the CRL number is unique 
      whether it is base or delta. That</FONT> <BR><FONT size=2>is</FONT> 
      <BR><FONT size=2>&gt; &gt; &gt; why delta number has to be greater than 
      the base.</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; 
      &gt;" 8.5.2.1 CRL number extension</FONT> <BR><FONT size=2>&gt; 
      &gt;</FONT> <BR><FONT size=2>&gt; &gt;&nbsp;&nbsp; This CRL extension 
      field conveys a monotonically increasing sequence</FONT> <BR><FONT 
      size=2>&gt; &gt; number .."</FONT> <BR><FONT size=2>&gt; &gt;</FONT> 
      <BR><FONT size=2>&gt; &gt;The text might be clearer IMHO if 'strictly 
      increasing' would be used</FONT> <BR><FONT size=2>&gt; &gt;instead.</FONT> 
      </P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C0D920.9F78F860--


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id UAA05691 for <[e-mail]>; Wed, 9 May 2001 20:08:31 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <KS8ZMS7C>; Wed, 9 May 2001 23:08:04 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Dr S N Henson <[e-mail]>, [e-mail]
Subject: RE: delta CRLs
Date: Wed, 9 May 2001 22:58:49 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D8FD.23508960"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D8FD.23508960
Content-Type: text/plain;
	charset="iso-8859-1"

Dr. Henson:

The rules for handling hold and release from hold are different when a delta
is applied to a base issued after the delta (I let you figure out the
rules).  But, if you have to know if the base was issued after the delta or
not, why apply the delta at all; just use the new base.

Thus if thisUpdate of base > = thisUpdate of delta, just use the base and do
not process the delta.

-----Original Message-----
From: Dr S N Henson [mailto:[e-mail]]
Sent: Wednesday, May 09, 2001 6:37 PM
To: [e-mail]
Subject: Re: delta CRLs




Peter Sylvester wrote:
> 
> 
> Is is necessary that the crlNumber of base URLs are strictly
> increasing? I am not convinced. The numbers are only used to
> create references to a chain of crls that can be used to create
> final 'virtual' base crl with an appropriate ThisUpdate.
> 

Well since you can combine any full CRL whose number is greater than or
equal to the base CRL number in the delta it has to be increasing.

If the full CRL has a number greater than the base CRL in the delta it
can still be combined but the delta CRL may contain some revocation data
already present in the base.

If the CRL number isn't strictly increasing then there's no way for the
CRL number of deltas to reference which full CRL the constructed CRL
represents.

This only applies if the only way to reference constructed and base CRLs
is the CRL number. If baseUpdateTime is used instead then it isn't
necessary except for the fact that some clients may not use
baseUpdateTime.

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

------_=_NextPart_001_01C0D8FD.23508960
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: delta CRLs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Dr. Henson:</FONT>
</P>

<P><FONT SIZE=3D2>The rules for handling hold and release from hold are =
different when a delta is applied to a base issued after the delta (I =
let you figure out the rules).&nbsp; But, if you have to know if the =
base was issued after the delta or not, why apply the delta at all; =
just use the new base.</FONT></P>

<P><FONT SIZE=3D2>Thus if thisUpdate of base &gt; =3D thisUpdate of =
delta, just use the base and do not process the delta.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Dr S N Henson [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, May 09, 2001 6:37 PM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: delta CRLs</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>Peter Sylvester wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Is is necessary that the crlNumber of base URLs =
are strictly</FONT>
<BR><FONT SIZE=3D2>&gt; increasing? I am not convinced. The numbers are =
only used to</FONT>
<BR><FONT SIZE=3D2>&gt; create references to a chain of crls that can =
be used to create</FONT>
<BR><FONT SIZE=3D2>&gt; final 'virtual' base crl with an appropriate =
ThisUpdate.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>Well since you can combine any full CRL whose number =
is greater than or</FONT>
<BR><FONT SIZE=3D2>equal to the base CRL number in the delta it has to =
be increasing.</FONT>
</P>

<P><FONT SIZE=3D2>If the full CRL has a number greater than the base =
CRL in the delta it</FONT>
<BR><FONT SIZE=3D2>can still be combined but the delta CRL may contain =
some revocation data</FONT>
<BR><FONT SIZE=3D2>already present in the base.</FONT>
</P>

<P><FONT SIZE=3D2>If the CRL number isn't strictly increasing then =
there's no way for the</FONT>
<BR><FONT SIZE=3D2>CRL number of deltas to reference which full CRL the =
constructed CRL</FONT>
<BR><FONT SIZE=3D2>represents.</FONT>
</P>

<P><FONT SIZE=3D2>This only applies if the only way to reference =
constructed and base CRLs</FONT>
<BR><FONT SIZE=3D2>is the CRL number. If baseUpdateTime is used instead =
then it isn't</FONT>
<BR><FONT SIZE=3D2>necessary except for the fact that some clients may =
not use</FONT>
<BR><FONT SIZE=3D2>baseUpdateTime.</FONT>
</P>

<P><FONT SIZE=3D2>Steve.</FONT>
<BR><FONT SIZE=3D2>-- </FONT>
<BR><FONT SIZE=3D2>Dr Stephen N. Henson.&nbsp;&nbsp; <A =
HREF=3D"http://www.drh-consultancy.demon.co.uk/" =
TARGET=3D"_blank">http://www.drh-consultancy.demon.co.uk/</A></FONT>
<BR><FONT SIZE=3D2>Personal Email: [e-mail] =
</FONT>
<BR><FONT SIZE=3D2>Senior crypto engineer, Celo Communications: <A =
HREF=3D"http://www.celocom.com/" =
TARGET=3D"_blank">http://www.celocom.com/</A></FONT>
<BR><FONT SIZE=3D2>Core developer of the&nbsp;&nbsp; OpenSSL project: =
<A HREF=3D"http://www.openssl.org/" =
TARGET=3D"_blank">http://www.openssl.org/</A></FONT>
<BR><FONT SIZE=3D2>Business Email: [e-mail] PGP key: via =
homepage.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0D8FD.23508960--


Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA23959 for <[e-mail]>; Wed, 9 May 2001 15:31:27 -0700 (PDT)
Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=celocom.com) by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1) id 14xcUT-0006jJ-0B for [e-mail]; Wed, 9 May 2001 22:31:29 +0000
Message-ID: <[e-mail]>
Date: Wed, 09 May 2001 23:36:43 +0100
From: Dr S N Henson <[e-mail]>
Organization: S N Henson
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: delta CRLs
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter Sylvester wrote:
> 
> 
> Is is necessary that the crlNumber of base URLs are strictly
> increasing? I am not convinced. The numbers are only used to
> create references to a chain of crls that can be used to create
> final 'virtual' base crl with an appropriate ThisUpdate.
> 

Well since you can combine any full CRL whose number is greater than or
equal to the base CRL number in the delta it has to be increasing.

If the full CRL has a number greater than the base CRL in the delta it
can still be combined but the delta CRL may contain some revocation data
already present in the base.

If the CRL number isn't strictly increasing then there's no way for the
CRL number of deltas to reference which full CRL the constructed CRL
represents.

This only applies if the only way to reference constructed and base CRLs
is the CRL number. If baseUpdateTime is used instead then it isn't
necessary except for the fact that some clients may not use
baseUpdateTime.

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


Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA18613 for <[e-mail]>; Wed, 9 May 2001 14:17:36 -0700 (PDT)
Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=celocom.com) by anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1) id 14xbL0-0000cI-0Y for [e-mail]; Wed, 9 May 2001 22:17:38 +0100
Message-ID: <[e-mail]>
Date: Wed, 09 May 2001 22:22:51 +0100
From: Dr S N Henson <[e-mail]>
Organization: S N Henson
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: delta CRLs
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Michael Myers wrote:
> 
> Just out of curiousity, has anyone actually experienced real-world (vs.
> lab-bench) collisions with this numbering issue?  I suspect not, but after
> reading through all of this thread I'm curious to know.
> 

Well speaking personally I haven't noticed collisions. However I've seen
*very* few V2 CRLs that may have something to do with them being
rejected by certain software.

I've yet to see a single example of a delta CRL. Considering some of the
confusion I suppose that's just as well :-)

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


Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA15708 for <[e-mail]>; Wed, 9 May 2001 13:38:19 -0700 (PDT)
Received: from HEATHERDALE (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f49KcJg21098; Wed, 9 May 2001 13:38:19 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Carlin Covey" <[e-mail]>, <[e-mail]>
Subject: RE: delta CRLs
Date: Wed, 9 May 2001 13:37:54 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

Just out of curiousity, has anyone actually experienced real-world (vs.
lab-bench) collisions with this numbering issue?  I suspect not, but after
reading through all of this thread I'm curious to know.

Mike



Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA10109 for <[e-mail]>; Wed, 9 May 2001 12:23:31 -0700 (PDT)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id J0AR5Y73; Wed, 9 May 2001 12:17:50 -0700
From: "Carlin Covey" <[e-mail]>
To: <[e-mail]>
Subject: RE: delta CRLs
Date: Wed, 9 May 2001 12:22:40 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0084_01C0D882.BDC9C900"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

This is a multi-part message in MIME format.

------=_NextPart_000_0084_01C0D882.BDC9C900
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

RE: delta CRLsHaving heard several persons speak for assigning the same CRL
number to simultaneously-issued delta-CRLs and full CRLs, and no one speak
against, I find myself convinced that they should be assigned the same CRL
number.  Thanks for the convincing arguments.

P.S.  I still like Santosh's revised wording:

----------------------

        Thus, if two CRLs (in the same stream identifier or when stream
identifier is absent), have numbers n and m, the following shall be true
(assuming no wrapping)
        n = m if and only if thisUpdate of n = thisUpdate of m

        n > m if and only if thisUpdate of n > thisUpdate of m

        n < m if and only if thisUpdate of n < thisUpdate of m

--------------------

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation

  -----Original Message-----
  From: Carlin Covey [mailto:[e-mail]]
  Sent: Wednesday, May 09, 2001 10:35 AM
  To: Santosh Chokhani
  Cc: [e-mail]
  Subject: RE: delta CRLs


  Santosh,

  I don't see that it matters whether the delta-CRL or the full CRL is
assigned the earlier number.  But I'm not hard over about assigning them
different numbers.  I'm still willing to be convinced that it is bad that
they have different numbers, or good that they have the same number.
Earlier today Stephen Henson presented one argument for numbering them the
same.  Perhaps that is a compelling reason.

  Regards,

  Carlin

  ____________________________

  -  Carlin Covey
     Cylink Corporation

    -----Original Message-----
    From: Santosh Chokhani [mailto:[e-mail]]
    Sent: Wednesday, May 09, 2001 10:13 AM
    To: Carlin Covey; Santosh Chokhani
    Cc: [e-mail]
    Subject: RE: delta CRLs


    Are you suggesting that when they are issued at the same time, they
should still have a different CRL number?

    Which one should have the number n and which one n+1?

    -----Original Message-----
    From: Carlin Covey [mailto:[e-mail]]
    Sent: Wednesday, May 09, 2001 1:16 PM
    To: Santosh Chokhani
    Cc: [e-mail]
    Subject: RE: delta CRLs


    Santosh,

    If simultaneously-issued delta-CRLs and full CRLs are to be numbered the
same, I think your wording is a significant improvement over the current
wording.  However, I'm still undecided whether they should be numbered the
same.  It seems like simultaneously-issued delta-CRLs and full CRLs (and
constructed CRLs) could be matched via the thisUpdate field without the
necessity of violating the strictly increasing provision for CRL numbers.  A
unique reference for each CRL would be useful for evidentiary purposes, and
for historical validation.  Rendering a CRL identifier unique already
requires the issuer ID, the set of reason codes, the set of certificate
types, and either the CRL number or the thisUpdate value.  I wonder if it is
necessary to add the full vs. delta status as well.

    - Carlin

     -----Original Message-----
    From: Santosh Chokhani [mailto:[e-mail]]
    Sent: Wednesday, May 09, 2001 9:28 AM
    To: Carlin Covey; [e-mail]; David A. Cooper;
[e-mail]; Santosh Chokhani
    Cc: [e-mail]
    Subject: RE: delta CRLs


      I am simply suggesting that the numbers be strictly increasing, but if
a base and delta are generated at the same time, they will have the same
sequence number.  Thus, if two CRLs (in the same stream identifier or when
stream identifier is absent), have numbers n and m, the following shall be
true (assuming no wrapping)

       n = m if and only if thisUpdate of n = thisUpdate of m

       n > m if and only if thisUpdate of n > thisUpdate of m

       n < m if and only if thisUpdate of n < thisUpdate of m

      -----Original Message-----
      From: Carlin Covey [mailto:[e-mail]]
      Sent: Wednesday, May 09, 2001 11:28 AM
      To: [e-mail]; David A. Cooper; [e-mail];
      [e-mail]
      Cc: [e-mail]
      Subject: RE: delta CRLs



      David, Stephen, Ambarish, and Santosh,

      Some of us are in the business for the looooong haul.  ;>)

      Actually, I wasn't concerned about the CRL number wrapping, but that
      possibility was advanced a few days ago as an argument against the use
of
      the "strictly increasing" wording.  Another email commented that PKIX
did
      not permit the number to wrap, although X.509 might.  The only
evidence I
      could find for X.509 permitting the number to wrap was "(0 .. MAX)".
As
      various people have pointed out, one could be drumming one's fingers
for
      quite a while........

      My real point was that the "monotonically increasing" wording permits
the
      CRL number to stay the same, while "strictly increasing" forces the
numbers
      to be unique (issues of wrapping aside in both cases).  Stephen Henson
just
      pointed out a reason why one might want the CRL number to stay the
same when
      issuing a delta CRL at the same time as a full CRL.  I am not arguing
either
      for or against that case, but it seems desirable to force the CRL
numbers to
      be unique in most cases.  (Unless, the CRLs are distinguished based
upon
      thisUpdate, as Santosh has suggested.)

      Regards,

      Carlin

      ____________________________

      -  Carlin Covey
         Cylink Corporation




      -----Original Message-----
      From: David A. Cooper [mailto:[e-mail]]
      Sent: Wednesday, May 09, 2001 6:03 AM
      To: '[e-mail] '
      Subject: RE: delta CRLs



       From a practical point of view, I don't think that we should need to
worry
      about CRL numbers wrapping.  According to my calculations, if one
assigns
      cRLNumber 1 to the first CRL and then numbers CRLs consecutively, one
could
      issue a new CRL every second for 68 years before the cRLNumber would
require
      more than 4 bytes (32 bits) to encode.  On the other hand, if you're
willing
      to issue a new CRL only once a minute, it would take 4083 years before
the
      cRLNumber would require more than 4 bytes to encode.

      BTW, I thought that the purpose of the "(0 .. MAX)" was just to
prevent use
      of negative numbers. While there may, in theory be a limit to the size
of an
      integer that may be encoded, for all practical purposes, one can
encode any
      integet. According to "A Layman's Guide to a Subset of ASN.1, BER, and
DER",
      a DER encoded value can have a length of up to 2 ** 1008 - 1 bytes.
Thus,
      MAX = 2 ** [8 * ((2 ** 1008) - 1) - 1] - 1, which is far larger than
any
      number we would ever need.

      Dave

      At 08:57 PM 5/8/01 -0700, Ambarish Malpani wrote:
      >
      >I always thought MAX for ASN.1 INTEGERs was something I would never
      >need to worry about.
      >
      >Looks like I was wrong :-)
      >
      >By the way, what is MAX? I know that we can represent numbers with
      >over 2048 bits...
      >
      >A
      >
      >-----Original Message-----
      >From: Carlin Covey
      >To: Housley, Russ; Santosh Chokhani
      >Cc: [e-mail]
      >Sent: 5/8/01 5:53 PM
      >Subject: RE: delta CRLs
      >
      >Russ,
      >
      >A week or two ago we arrived at a consensus to remove the requirement
      >that a CA issue a full CRL whenever the CA issues a Delta-CRL.  If
the
      >CA chooses to issue them simultaneously, why would they need to be
numbered
      >the same?  If this requirement were lifted, it seems like requiring
the CRL
      >number to be "strictly increasing" in a sequence would be preferable
to
      >"monotonically increasing".  "Monotonically increasing" allows the
      possibility
      >that the CRL number never changes, which seems undesirable.  I
realize
      >that in either case the CRL number might wrap around at some point in
the
      future.
      >That is inevitable, given that that CRL number is defined as INTEGER
      (0..MAX).
      >What else can a CA do when CRL number reaches MAX, stop issuing CRLs?
      >
      >"monotonically increasing" - Definition: A function from a partially
      order[ed]
      >domain to a partially ordered range such that x >= y implies f(x) >=
f(y).
      >
      >- From the NIST web site:
      >http://hissa.nist.gov/dads/HTML/monotoncincr.html
      >
      >Regards,
      >
      >Carlin
      >
      >____________________________
      >
      >-  Carlin Covey
      >    Cylink Corporation
      >
      >-----Original Message-----
      >From: Housley, Russ [mailto:[e-mail]]
      >Sent: Monday, May 07, 2001 6:21 AM
      >To: Santosh Chokhani
      >Cc: [e-mail]
      >Subject: RE: delta CRLs
      >
      >
      >Santosh:
      >
      >X.509 may allow the CRL number to wrap around, but I do not believe
that
      >PKIX does.
      >
      >     5.2.3  CRL Number
      >
      >     The CRL number is a non-critical CRL extension which conveys a
      >     monotonically increasing sequence number for each CRL issued by
a CA.
      >     This extension allows users to easily determine when a
particular CRL
      >     supersedes another CRL.  CAs conforming to this profile MUST
include
      >     this extension in all CRLs.
      >
      >     id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }
      >
      >Russ
      >
      >
      >At 10:11 PM 5/5/2001 -0400, Santosh Chokhani wrote:
      >
      > >Actually, the text allows for the wrap of the numbers.  Please see
Annex
      B
      > >of X.509.  Thus, it is not strictly increasing
      > >
      > >-----Original Message-----
      > >From: Peter Sylvester
      >
>[<mailto:[e-mail]>mailto:[e-mail]]
      > >Sent: Saturday, May 05, 2001 2:08 PM
      > >To: [e-mail]; [e-mail];
      > >[e-mail]
      > >Cc: [e-mail]
      > >Subject: RE: delta CRLs
      > >
      > > > Trevor:
      > > >
      > > > The 2000 version of X.509 is very clear on this.  For a given
CRL
      stream
      > > > identifier, the CRL number is unique whether it is base or
delta. That
      is
      > > > why delta number has to be greater than the base.
      > >
      > >" 8.5.2.1 CRL number extension
      > >
      > >   This CRL extension field conveys a monotonically increasing
sequence
      > > number .."
      > >
      > >The text might be clearer IMHO if 'strictly increasing' would be
used
      > >instead.


------=_NextPart_000_0084_01C0D882.BDC9C900
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: delta CRLs</TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D309141619-09052001>Having=20
heard several persons speak for assigning the same CRL number to=20
simultaneously-issued delta-CRLs and full CRLs, and no one speak =
against, I find=20
myself convinced that they should be assigned the same CRL number.&nbsp; =
Thanks=20
for the convincing arguments.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D309141619-09052001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D309141619-09052001>P.S.&nbsp; I still like Santosh's revised=20
wording:</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D309141619-09052001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D309141619-09052001>----------------------</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D309141619-09052001></SPAN></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D309141619-09052001><FONT color=3D#0000ff face=3DArial =

size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Thus, if two CRLs =
(in the same=20
stream identifier or when stream identifier is absent), have numbers n =
and m,=20
the following shall be true&nbsp;(assuming no wrapping)</FONT>
<P><FONT color=3D#0000ff><FONT face=3DArial size=3D2>&nbsp;<SPAN=20
class=3D309141619-09052001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>n =
=3D m if=20
and only if thisUpdate of n =3D thisUpdate of m </FONT></FONT></P>
<P><FONT color=3D#0000ff face=3DArial size=3D2>&nbsp;<SPAN=20
class=3D309141619-09052001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SP=
AN>n &gt;=20
m if and only if thisUpdate of n &gt; thisUpdate of m </FONT></P>
<P><FONT color=3D#0000ff face=3DArial size=3D2>&nbsp;<SPAN=20
class=3D309141619-09052001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>n =
&lt; m if=20
and only if thisUpdate of n &lt; thisUpdate of m </FONT></P>
<P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D309141619-09052001>--------------------</SPAN></FONT></P><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN class=3D309141619-09052001>
<P><FONT=20
size=3D2>Regards,<BR><BR>Carlin<BR><BR>____________________________<BR><B=
R>-&nbsp;=20
Carlin Covey<BR>&nbsp;&nbsp; Cylink Corporation=20
</FONT></P></SPAN></FONT></SPAN></DIV>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Carlin Covey=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Wednesday, May 09, 2001 =
10:35=20
  AM<BR><B>To:</B> Santosh Chokhani<BR><B>Cc:</B>=20
  [e-mail]<BR><B>Subject:</B> RE: delta =
CRLs<BR><BR></DIV></FONT>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D121152317-09052001>Santosh,</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D121152317-09052001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D121152317-09052001>I=20
  don't see that it matters whether the delta-CRL or the full CRL is =
assigned=20
  the earlier number.&nbsp; But I'm not hard over about&nbsp;assigning =
them=20
  different numbers.&nbsp; I'm still willing to be convinced that it is =
bad that=20
  they have different numbers, or good that they have the same =
number.&nbsp;=20
  Earlier today Stephen Henson presented one argument for numbering them =
the=20
  same.&nbsp; Perhaps that is a compelling reason.</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D121152317-09052001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D121152317-09052001>
  <P><FONT=20
  =
size=3D2>Regards,<BR><BR>Carlin<BR><BR>____________________________<BR><B=
R>-&nbsp;=20
  Carlin Covey<BR>&nbsp;&nbsp; Cylink Corporation=20
</FONT></P></SPAN></FONT></DIV>
  <BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
    <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Santosh Chokhani =

    [mailto:[e-mail]]<BR><B>Sent:</B> Wednesday, May 09, =
2001 10:13=20
    AM<BR><B>To:</B> Carlin Covey; Santosh Chokhani<BR><B>Cc:</B>=20
    [e-mail]<BR><B>Subject:</B> RE: delta =
CRLs<BR><BR></DIV></FONT>
    <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
    class=3D742462017-09052001>Are you suggesting that when they are =
issued at the=20
    same time, they should still have a different CRL=20
number?</SPAN></FONT></DIV>
    <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
    class=3D742462017-09052001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
    class=3D742462017-09052001>Which one should have the number n and =
which one=20
    n+1?</SPAN></FONT></DIV>
    <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
    class=3D742462017-09052001></SPAN></FONT>&nbsp;</DIV>
    <DIV class=3DOutlookMessageHeader><FONT face=3D"Times New Roman"=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Carlin Covey=20
    [mailto:[e-mail]]<BR><B>Sent:</B> Wednesday, May 09, 2001 =
1:16=20
    PM<BR><B>To:</B> Santosh Chokhani<BR><B>Cc:</B>=20
    [e-mail]<BR><B>Subject:</B> RE: delta =
CRLs<BR><BR></FONT></DIV>
    <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
    class=3D523265216-09052001>Santosh,</SPAN></FONT></DIV>
    <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
    class=3D523265216-09052001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D523265216-09052001>If=20
    simultaneously-issued delta-CRLs and full CRLs are to be numbered =
the same,=20
    I think your wording is a significant improvement over the current=20
    wording.&nbsp; However, I'm still undecided whether they should be =
numbered=20
    the same.&nbsp; It seems like simultaneously-issued delta-CRLs and =
full CRLs=20
    (and constructed CRLs) could be matched via the thisUpdate field =
without the=20
    necessity of violating the strictly increasing provision for CRL=20
    numbers.&nbsp; A unique reference for each CRL would be useful for=20
    evidentiary purposes, and for historical =
validation.&nbsp;&nbsp;Rendering a=20
    CRL identifier unique already requires the issuer ID, the set of=20
    reason&nbsp;codes, the set of certificate types, and either the CRL =
number=20
    or the thisUpdate value.&nbsp; I wonder if it is necessary to add =
the full=20
    vs. delta status as well.</SPAN></FONT></DIV>
    <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
    class=3D523265216-09052001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D523265216-09052001>-=20
    Carlin</SPAN></FONT></DIV>
    <DIV><SPAN class=3D523265216-09052001></SPAN><FONT =
face=3DTahoma><FONT=20
    size=3D2><SPAN class=3D523265216-09052001><FONT color=3D#0000ff=20
    face=3DArial>&nbsp;</FONT></SPAN></FONT></FONT></DIV>
    <DIV><FONT face=3DTahoma><FONT size=3D2><SPAN=20
    class=3D523265216-09052001>&nbsp;</SPAN>-----Original=20
    Message-----<BR><B>From:</B> Santosh Chokhani=20
    [mailto:[e-mail]]<BR><B>Sent:</B> Wednesday, May 09, =
2001 9:28=20
    AM<BR><B>To:</B> Carlin Covey; [e-mail]; David A. Cooper;=20
    [e-mail]; Santosh Chokhani<BR><B>Cc:</B>=20
    [e-mail]<BR><B>Subject:</B> RE: delta =
CRLs<BR><BR></DIV></FONT>
    <BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px"></FONT>
      <P><FONT size=3D2>I am simply suggesting that the numbers be =
strictly=20
      increasing, but if a base and delta are generated at the same =
time, they=20
      will have the same sequence number.&nbsp; Thus, if two CRLs (in =
the same=20
      stream identifier or when stream identifier is absent), have =
numbers n and=20
      m, the following shall be true (assuming no wrapping)</FONT></P>
      <P><FONT size=3D2>&nbsp;n =3D m if and only if thisUpdate of n =3D =
thisUpdate of=20
      m</FONT> </P>
      <P><FONT size=3D2>&nbsp;n &gt; m if and only if thisUpdate of n =
&gt;=20
      thisUpdate of m</FONT> </P>
      <P><FONT size=3D2>&nbsp;n &lt; m if and only if thisUpdate of n =
&lt;=20
      thisUpdate of m</FONT> </P>
      <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From:=20
      Carlin Covey [<A=20
      =
href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>=20
      <BR><FONT size=3D2>Sent: Wednesday, May 09, 2001 11:28 AM</FONT> =
<BR><FONT=20
      size=3D2>To: [e-mail]; David A. Cooper; =
[e-mail];</FONT>=20
      <BR><FONT size=3D2>[e-mail]</FONT> <BR><FONT =
size=3D2>Cc:=20
      [e-mail]</FONT> <BR><FONT size=3D2>Subject: RE: delta =
CRLs</FONT>=20
      </P><BR>
      <P><FONT size=3D2>David, Stephen, Ambarish, and Santosh,</FONT> =
</P>
      <P><FONT size=3D2>Some of us are in the business for the looooong=20
      haul.&nbsp; ;&gt;)</FONT> </P>
      <P><FONT size=3D2>Actually, I wasn't concerned about the CRL =
number=20
      wrapping, but that</FONT> <BR><FONT size=3D2>possibility was =
advanced a few=20
      days ago as an argument against the use of</FONT> <BR><FONT =
size=3D2>the=20
      "strictly increasing" wording.&nbsp; Another email commented that =
PKIX=20
      did</FONT> <BR><FONT size=3D2>not permit the number to wrap, =
although X.509=20
      might.&nbsp; The only evidence I</FONT> <BR><FONT size=3D2>could =
find for=20
      X.509 permitting the number to wrap was "(0 .. MAX)".&nbsp; =
As</FONT>=20
      <BR><FONT size=3D2>various people have pointed out, one could be =
drumming=20
      one's fingers for</FONT> <BR><FONT size=3D2>quite a =
while........</FONT>=20
</P>
      <P><FONT size=3D2>My real point was that the "monotonically =
increasing"=20
      wording permits the</FONT> <BR><FONT size=3D2>CRL number to stay =
the same,=20
      while "strictly increasing" forces the numbers</FONT> <BR><FONT =
size=3D2>to=20
      be unique (issues of wrapping aside in both cases).&nbsp; Stephen =
Henson=20
      just</FONT> <BR><FONT size=3D2>pointed out a reason why one might =
want the=20
      CRL number to stay the same when</FONT> <BR><FONT size=3D2>issuing =
a delta=20
      CRL at the same time as a full CRL.&nbsp; I am not arguing =
either</FONT>=20
      <BR><FONT size=3D2>for or against that case, but it seems =
desirable to force=20
      the CRL numbers to</FONT> <BR><FONT size=3D2>be unique in most =
cases.&nbsp;=20
      (Unless, the CRLs are distinguished based upon</FONT> <BR><FONT=20
      size=3D2>thisUpdate, as Santosh has suggested.)</FONT> </P>
      <P><FONT size=3D2>Regards,</FONT> </P>
      <P><FONT size=3D2>Carlin</FONT> </P>
      <P><FONT size=3D2>____________________________</FONT> </P>
      <P><FONT size=3D2>-&nbsp; Carlin Covey</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp;=20
      Cylink Corporation</FONT> </P><BR><BR>
      <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From:=20
      David A. Cooper [<A=20
      =
href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</=
FONT>=20
      <BR><FONT size=3D2>Sent: Wednesday, May 09, 2001 6:03 AM</FONT> =
<BR><FONT=20
      size=3D2>To: '[e-mail] '</FONT> <BR><FONT =
size=3D2>Subject: RE: delta=20
      CRLs</FONT> </P><BR>
      <P><FONT size=3D2>&nbsp;From a practical point of view, I don't =
think that=20
      we should need to worry</FONT> <BR><FONT size=3D2>about CRL =
numbers=20
      wrapping.&nbsp; According to my calculations, if one =
assigns</FONT>=20
      <BR><FONT size=3D2>cRLNumber 1 to the first CRL and then numbers =
CRLs=20
      consecutively, one could</FONT> <BR><FONT size=3D2>issue a new CRL =
every=20
      second for 68 years before the cRLNumber would require</FONT> =
<BR><FONT=20
      size=3D2>more than 4 bytes (32 bits) to encode.&nbsp; On the other =
hand, if=20
      you're willing</FONT> <BR><FONT size=3D2>to issue a new CRL only =
once a=20
      minute, it would take 4083 years before the</FONT> <BR><FONT=20
      size=3D2>cRLNumber would require more than 4 bytes to =
encode.</FONT> </P>
      <P><FONT size=3D2>BTW, I thought that the purpose of the "(0 .. =
MAX)" was=20
      just to prevent use</FONT> <BR><FONT size=3D2>of negative numbers. =
While=20
      there may, in theory be a limit to the size of an</FONT> <BR><FONT =

      size=3D2>integer that may be encoded, for all practical purposes, =
one can=20
      encode any</FONT> <BR><FONT size=3D2>integet. According to "A =
Layman's Guide=20
      to a Subset of ASN.1, BER, and DER",</FONT> <BR><FONT size=3D2>a =
DER encoded=20
      value can have a length of up to 2 ** 1008 - 1 bytes. Thus,</FONT> =

      <BR><FONT size=3D2>MAX =3D 2 ** [8 * ((2 ** 1008) - 1) - 1] - 1, =
which is far=20
      larger than any</FONT> <BR><FONT size=3D2>number we would ever =
need.</FONT>=20
      </P>
      <P><FONT size=3D2>Dave</FONT> </P>
      <P><FONT size=3D2>At 08:57 PM 5/8/01 -0700, Ambarish Malpani =
wrote:</FONT>=20
      <BR><FONT size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;I always =
thought MAX for=20
      ASN.1 INTEGERs was something I would never</FONT> <BR><FONT=20
      size=3D2>&gt;need to worry about.</FONT> <BR><FONT =
size=3D2>&gt;</FONT>=20
      <BR><FONT size=3D2>&gt;Looks like I was wrong :-)</FONT> <BR><FONT =

      size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;By the way, what is =
MAX? I know=20
      that we can represent numbers with</FONT> <BR><FONT =
size=3D2>&gt;over 2048=20
      bits...</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =
size=3D2>&gt;A</FONT>=20
      <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =
size=3D2>&gt;-----Original=20
      Message-----</FONT> <BR><FONT size=3D2>&gt;From: Carlin =
Covey</FONT>=20
      <BR><FONT size=3D2>&gt;To: Housley, Russ; Santosh Chokhani</FONT> =
<BR><FONT=20
      size=3D2>&gt;Cc: [e-mail]</FONT> <BR><FONT =
size=3D2>&gt;Sent: 5/8/01=20
      5:53 PM</FONT> <BR><FONT size=3D2>&gt;Subject: RE: delta =
CRLs</FONT>=20
      <BR><FONT size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;Russ,</FONT> =
<BR><FONT=20
      size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;A week or two ago we =
arrived at a=20
      consensus to remove the requirement</FONT> <BR><FONT =
size=3D2>&gt;that a CA=20
      issue a full CRL whenever the CA issues a Delta-CRL.&nbsp; If =
the</FONT>=20
      <BR><FONT size=3D2>&gt;CA chooses to issue them simultaneously, =
why would=20
      they need to be numbered</FONT> <BR><FONT size=3D2>&gt;the =
same?&nbsp; If=20
      this requirement were lifted, it seems like requiring the =
CRL</FONT>=20
      <BR><FONT size=3D2>&gt;number to be "strictly increasing" in a =
sequence=20
      would be preferable to</FONT> <BR><FONT =
size=3D2>&gt;"monotonically=20
      increasing".&nbsp; "Monotonically increasing" allows the</FONT> =
<BR><FONT=20
      size=3D2>possibility</FONT> <BR><FONT size=3D2>&gt;that the CRL =
number never=20
      changes, which seems undesirable.&nbsp; I realize</FONT> <BR><FONT =

      size=3D2>&gt;that in either case the CRL number might wrap around =
at some=20
      point in the</FONT> <BR><FONT size=3D2>future.</FONT> <BR><FONT=20
      size=3D2>&gt;That is inevitable, given that that CRL number is =
defined as=20
      INTEGER</FONT> <BR><FONT size=3D2>(0..MAX).</FONT> <BR><FONT =
size=3D2>&gt;What=20
      else can a CA do when CRL number reaches MAX, stop issuing =
CRLs?</FONT>=20
      <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =
size=3D2>&gt;"monotonically=20
      increasing" - Definition: A function from a partially</FONT> =
<BR><FONT=20
      size=3D2>order[ed]</FONT> <BR><FONT size=3D2>&gt;domain to a =
partially ordered=20
      range such that x &gt;=3D y implies f(x) &gt;=3D f(y).</FONT> =
<BR><FONT=20
      size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;- From the NIST web =
site:</FONT>=20
      <BR><FONT size=3D2>&gt;<A=20
      href=3D"http://hissa.nist.gov/dads/HTML/monotoncincr.html"=20
      =
target=3D_blank>http://hissa.nist.gov/dads/HTML/monotoncincr.html</A></FO=
NT>=20
      <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =
size=3D2>&gt;Regards,</FONT>=20
      <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =
size=3D2>&gt;Carlin</FONT> <BR><FONT=20
      size=3D2>&gt;</FONT> <BR><FONT=20
      size=3D2>&gt;____________________________</FONT> <BR><FONT=20
      size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;-&nbsp; Carlin =
Covey</FONT>=20
      <BR><FONT size=3D2>&gt;&nbsp;&nbsp;&nbsp; Cylink =
Corporation</FONT>=20
      <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =
size=3D2>&gt;-----Original=20
      Message-----</FONT> <BR><FONT size=3D2>&gt;From: Housley, Russ [<A =

      =
href=3D"mailto:[e-mail]">mailto:[e-mail]<=
/A>]</FONT>=20
      <BR><FONT size=3D2>&gt;Sent: Monday, May 07, 2001 6:21 AM</FONT> =
<BR><FONT=20
      size=3D2>&gt;To: Santosh Chokhani</FONT> <BR><FONT =
size=3D2>&gt;Cc:=20
      [e-mail]</FONT> <BR><FONT size=3D2>&gt;Subject: RE: delta =

      CRLs</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =
size=3D2>&gt;</FONT>=20
      <BR><FONT size=3D2>&gt;Santosh:</FONT> <BR><FONT =
size=3D2>&gt;</FONT>=20
      <BR><FONT size=3D2>&gt;X.509 may allow the CRL number to wrap =
around, but I=20
      do not believe that</FONT> <BR><FONT size=3D2>&gt;PKIX =
does.</FONT>=20
      <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;=20
      5.2.3&nbsp; CRL Number</FONT> <BR><FONT size=3D2>&gt;</FONT> =
<BR><FONT=20
      size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; The CRL number is a =
non-critical CRL=20
      extension which conveys a</FONT> <BR><FONT=20
      size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; monotonically increasing =
sequence=20
      number for each CRL issued by a CA.</FONT> <BR><FONT=20
      size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; This extension allows users =
to easily=20
      determine when a particular CRL</FONT> <BR><FONT=20
      size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; supersedes another =
CRL.&nbsp; CAs=20
      conforming to this profile MUST include</FONT> <BR><FONT=20
      size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; this extension in all =
CRLs.</FONT>=20
      <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;=20
      id-ce-cRLNumber OBJECT IDENTIFIER ::=3D { id-ce 20 }</FONT> =
<BR><FONT=20
      size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;Russ</FONT> <BR><FONT=20
      size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =
size=3D2>&gt;At=20
      10:11 PM 5/5/2001 -0400, Santosh Chokhani wrote:</FONT> <BR><FONT=20
      size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt; &gt;Actually, the =
text allows for=20
      the wrap of the numbers.&nbsp; Please see Annex</FONT> <BR><FONT=20
      size=3D2>B</FONT> <BR><FONT size=3D2>&gt; &gt;of X.509.&nbsp; =
Thus, it is not=20
      strictly increasing</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> =
<BR><FONT=20
      size=3D2>&gt; &gt;-----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt;=20
      &gt;From: Peter Sylvester</FONT> <BR><FONT size=3D2>&gt; =
&gt;[&lt;<A=20
      =
href=3D"mailto:[e-mail]">mailto:Peter.Sylvester@EdelWeb=
.fr</A>&gt;<A=20
      =
href=3D"mailto:[e-mail]">mailto:Peter.Sylvester@EdelWeb=
.fr</A>]</FONT>=20
      <BR><FONT size=3D2>&gt; &gt;Sent: Saturday, May 05, 2001 2:08 =
PM</FONT>=20
      <BR><FONT size=3D2>&gt; &gt;To: [e-mail];=20
      [e-mail];</FONT> <BR><FONT size=3D2>&gt;=20
      &gt;[e-mail]</FONT> <BR><FONT size=3D2>&gt; &gt;Cc:=20
      [e-mail]</FONT> <BR><FONT size=3D2>&gt; &gt;Subject: RE: =
delta=20
      CRLs</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
      &gt; Trevor:</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;</FONT> =
<BR><FONT=20
      size=3D2>&gt; &gt; &gt; The 2000 version of X.509 is very clear on =

      this.&nbsp; For a given CRL</FONT> <BR><FONT =
size=3D2>stream</FONT>=20
      <BR><FONT size=3D2>&gt; &gt; &gt; identifier, the CRL number is =
unique=20
      whether it is base or delta. That</FONT> <BR><FONT =
size=3D2>is</FONT>=20
      <BR><FONT size=3D2>&gt; &gt; &gt; why delta number has to be =
greater than=20
      the base.</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
      &gt;" 8.5.2.1 CRL number extension</FONT> <BR><FONT size=3D2>&gt;=20
      &gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp;&nbsp; This CRL =
extension=20
      field conveys a monotonically increasing sequence</FONT> <BR><FONT =

      size=3D2>&gt; &gt; number .."</FONT> <BR><FONT size=3D2>&gt; =
&gt;</FONT>=20
      <BR><FONT size=3D2>&gt; &gt;The text might be clearer IMHO if =
'strictly=20
      increasing' would be used</FONT> <BR><FONT size=3D2>&gt; =
&gt;instead.</FONT>=20
      </P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0084_01C0D882.BDC9C900--



Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA08039 for <[e-mail]>; Wed, 9 May 2001 11:47:56 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA09985; Wed, 9 May 2001 20:47:39 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 9 May 2001 20:47:39 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id UAA15418; Wed, 9 May 2001 20:47:37 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id UAA00350; Wed, 9 May 2001 20:47:37 +0200 (MET DST)
Date: Wed, 9 May 2001 20:47:37 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: delta CRLs
Cc: [e-mail]

The numbers can be different, but:

If numbers are identical, this means that any
of these crls (base or delta) can be used when the number
is referenced in a following deltaCRL in order to construct
a full crl. The constructed full crl, if it would be published
would have the same number as the delta crl. 


> 
> I don't see that it matters whether the delta-CRL or the full CRL is
> assigned the earlier number.  But I'm not hard over about assigning them
> different numbers.   I'm still willing to be convinced that it is bad that
> they have different numbers, or good that they have the same number.
> Earlier today Stephen Henson presented one argument for numbering them the
> same.  Perhaps that is a compelling reason.
> 
> Regards,
> 
> Carlin
> 


Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA06744 for <[e-mail]>; Wed, 9 May 2001 11:30:30 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA09914 for <[e-mail]>; Wed, 9 May 2001 20:30:31 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 9 May 2001 20:30:31 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id UAA15370 for <[e-mail]>; Wed, 9 May 2001 20:30:30 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id UAA00345 for [e-mail]; Wed, 9 May 2001 20:30:30 +0200 (MET DST)
Date: Wed, 9 May 2001 20:30:30 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RE: delta CRLs

Some thoughts

I think the examples on page 146 in annex c of the latest X509 draft 
seem to indicate that delta crls and full crls can have the same
number, and this is even necessary as drh pointed out. 

Either one can have a full crl with number n or one can construct it
by using the dCRL with the same number + the full crl indicated by
the BaseCRLNumber in the dcrl. 

The verifying party that tries to build the full CRL using a delta
has to create or get the baseCRL. It seems possible to me that in
case that the vp has a dCRL that has the value of BaseCRLNumber, the
process can be used recursively, this is the second model mentioned
in annex C.

Is is necessary that the crlNumber of base URLs are strictly
increasing? I am not convinced. The numbers are only used to
create references to a chain of crls that can be used to create 
final 'virtual' base crl with an appropriate ThisUpdate. 

If you take two base CRLs with the same crlNumber, where the
second is constructed in such a way that no data are removed then
a dCRl that refers to this number can use any of the two base CRLs
in order to construct a fresher base crl. 

And actually it seems to me that even monotonically increasing is
not really necessary since one has an order defined by thisUpdate.





Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA05419 for <[e-mail]>; Wed, 9 May 2001 10:58:34 -0700 (PDT)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id NAA11746 for <[e-mail]>; Wed, 9 May 2001 13:58:35 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Wed, 09 May 2001 13:58:00 -0400
To: [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: RE: delta CRLs
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Carlin,

If a full CRL and a delta-CRL are issued for the same scope at the same time, then the constructed CRL that results from combining the delta-CRL with an appropriate base MUST be the same as the issued full CRL. The CRL number of the constructed CRL is the CRL number of the delta-CRL. Since the issued full CRL and the constructed CRL are the same CRL, they should have the same CRL number.  To assign the full CRL and the delta-CRL different CRL numbers would be to suggest that they are not the same, and that the one with the higher CRL number contains fresher information.

BTW, to chime in on two other issues:

1) I agree that if two CRLs, CRL1 and CRL2, are issued for the same scope, and thisUpdate of CRL1 is greater than thisUpdate of CRL2, then the cRLNumber of CRL1 must be greater than the cRLNumber of CRL2. I'm sure this was always the intention of the standard, but perhaps it was not stated with sufficient mathematical precision.

2) I agree with Santosh that much of the confusion we are having could be cleared up if delta-CRLs used the thisUpate field as a reference instead of cRLNumber. X.509 has defined a non-critical baseUpdateTime extension for use in delta-CRLs that specifies the value of thisUpdate in the base CRL that is referenced using the deltaCRLIndicator. I think it would be a good idea to include this extension in PKIX and recommend its inclusion in delta-CRLs. One could then base the delta-CRL processing rules on time instead of CRL numbers (at least for those cases in which the extension was present in the delta-CRL).

Dave

At 10:15 AM 5/9/01 -0700, Carlin Covey wrote:
>Santosh,
>  
>If simultaneously-issued delta-CRLs and full CRLs are to be numbered the same, I think your wording is a significant improvement over the current wording.  However, I'm still undecided whether they should be numbered the same.  It seems like simultaneously-issued delta-CRLs and full CRLs (and constructed CRLs) could be matched via the thisUpdate field without the necessity of violating the strictly increasing provision for CRL numbers.  A unique reference for each CRL would be useful for evidentiary purposes, and for historical validation.  Rendering a CRL identifier unique already requires the issuer ID, the set of reason codes, the set of certificate types, and either the CRL number or the thisUpdate value.  I wonder if it is necessary to add the full vs. delta status as well.
>  
>- Carlin




Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA04544 for <[e-mail]>; Wed, 9 May 2001 10:35:52 -0700 (PDT)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id J0AR5YK7; Wed, 9 May 2001 10:30:12 -0700
From: "Carlin Covey" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: delta CRLs
Date: Wed, 9 May 2001 10:35:02 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0077_01C0D873.B4133450"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

This is a multi-part message in MIME format.

------=_NextPart_000_0077_01C0D873.B4133450
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

RE: delta CRLsSantosh,

I don't see that it matters whether the delta-CRL or the full CRL is
assigned the earlier number.  But I'm not hard over about assigning them
different numbers.   I'm still willing to be convinced that it is bad that
they have different numbers, or good that they have the same number.
Earlier today Stephen Henson presented one argument for numbering them the
same.  Perhaps that is a compelling reason.

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation

  -----Original Message-----
  From: Santosh Chokhani [mailto:[e-mail]]
  Sent: Wednesday, May 09, 2001 10:13 AM
  To: Carlin Covey; Santosh Chokhani
  Cc: [e-mail]
  Subject: RE: delta CRLs


  Are you suggesting that when they are issued at the same time, they should
still have a different CRL number?

  Which one should have the number n and which one n+1?

  -----Original Message-----
  From: Carlin Covey [mailto:[e-mail]]
  Sent: Wednesday, May 09, 2001 1:16 PM
  To: Santosh Chokhani
  Cc: [e-mail]
  Subject: RE: delta CRLs


  Santosh,

  If simultaneously-issued delta-CRLs and full CRLs are to be numbered the
same, I think your wording is a significant improvement over the current
wording.  However, I'm still undecided whether they should be numbered the
same.  It seems like simultaneously-issued delta-CRLs and full CRLs (and
constructed CRLs) could be matched via the thisUpdate field without the
necessity of violating the strictly increasing provision for CRL numbers.  A
unique reference for each CRL would be useful for evidentiary purposes, and
for historical validation.  Rendering a CRL identifier unique already
requires the issuer ID, the set of reason codes, the set of certificate
types, and either the CRL number or the thisUpdate value.  I wonder if it is
necessary to add the full vs. delta status as well.

  - Carlin

   -----Original Message-----
  From: Santosh Chokhani [mailto:[e-mail]]
  Sent: Wednesday, May 09, 2001 9:28 AM
  To: Carlin Covey; [e-mail]; David A. Cooper; [e-mail];
Santosh Chokhani
  Cc: [e-mail]
  Subject: RE: delta CRLs


    I am simply suggesting that the numbers be strictly increasing, but if a
base and delta are generated at the same time, they will have the same
sequence number.  Thus, if two CRLs (in the same stream identifier or when
stream identifier is absent), have numbers n and m, the following shall be
true (assuming no wrapping)

     n = m if and only if thisUpdate of n = thisUpdate of m

     n > m if and only if thisUpdate of n > thisUpdate of m

     n < m if and only if thisUpdate of n < thisUpdate of m

    -----Original Message-----
    From: Carlin Covey [mailto:[e-mail]]
    Sent: Wednesday, May 09, 2001 11:28 AM
    To: [e-mail]; David A. Cooper; [e-mail];
    [e-mail]
    Cc: [e-mail]
    Subject: RE: delta CRLs



    David, Stephen, Ambarish, and Santosh,

    Some of us are in the business for the looooong haul.  ;>)

    Actually, I wasn't concerned about the CRL number wrapping, but that
    possibility was advanced a few days ago as an argument against the use
of
    the "strictly increasing" wording.  Another email commented that PKIX
did
    not permit the number to wrap, although X.509 might.  The only evidence
I
    could find for X.509 permitting the number to wrap was "(0 .. MAX)".  As
    various people have pointed out, one could be drumming one's fingers for
    quite a while........

    My real point was that the "monotonically increasing" wording permits
the
    CRL number to stay the same, while "strictly increasing" forces the
numbers
    to be unique (issues of wrapping aside in both cases).  Stephen Henson
just
    pointed out a reason why one might want the CRL number to stay the same
when
    issuing a delta CRL at the same time as a full CRL.  I am not arguing
either
    for or against that case, but it seems desirable to force the CRL
numbers to
    be unique in most cases.  (Unless, the CRLs are distinguished based upon
    thisUpdate, as Santosh has suggested.)

    Regards,

    Carlin

    ____________________________

    -  Carlin Covey
       Cylink Corporation




    -----Original Message-----
    From: David A. Cooper [mailto:[e-mail]]
    Sent: Wednesday, May 09, 2001 6:03 AM
    To: '[e-mail] '
    Subject: RE: delta CRLs



     From a practical point of view, I don't think that we should need to
worry
    about CRL numbers wrapping.  According to my calculations, if one
assigns
    cRLNumber 1 to the first CRL and then numbers CRLs consecutively, one
could
    issue a new CRL every second for 68 years before the cRLNumber would
require
    more than 4 bytes (32 bits) to encode.  On the other hand, if you're
willing
    to issue a new CRL only once a minute, it would take 4083 years before
the
    cRLNumber would require more than 4 bytes to encode.

    BTW, I thought that the purpose of the "(0 .. MAX)" was just to prevent
use
    of negative numbers. While there may, in theory be a limit to the size
of an
    integer that may be encoded, for all practical purposes, one can encode
any
    integet. According to "A Layman's Guide to a Subset of ASN.1, BER, and
DER",
    a DER encoded value can have a length of up to 2 ** 1008 - 1 bytes.
Thus,
    MAX = 2 ** [8 * ((2 ** 1008) - 1) - 1] - 1, which is far larger than any
    number we would ever need.

    Dave

    At 08:57 PM 5/8/01 -0700, Ambarish Malpani wrote:
    >
    >I always thought MAX for ASN.1 INTEGERs was something I would never
    >need to worry about.
    >
    >Looks like I was wrong :-)
    >
    >By the way, what is MAX? I know that we can represent numbers with
    >over 2048 bits...
    >
    >A
    >
    >-----Original Message-----
    >From: Carlin Covey
    >To: Housley, Russ; Santosh Chokhani
    >Cc: [e-mail]
    >Sent: 5/8/01 5:53 PM
    >Subject: RE: delta CRLs
    >
    >Russ,
    >
    >A week or two ago we arrived at a consensus to remove the requirement
    >that a CA issue a full CRL whenever the CA issues a Delta-CRL.  If the
    >CA chooses to issue them simultaneously, why would they need to be
numbered
    >the same?  If this requirement were lifted, it seems like requiring the
CRL
    >number to be "strictly increasing" in a sequence would be preferable to
    >"monotonically increasing".  "Monotonically increasing" allows the
    possibility
    >that the CRL number never changes, which seems undesirable.  I realize
    >that in either case the CRL number might wrap around at some point in
the
    future.
    >That is inevitable, given that that CRL number is defined as INTEGER
    (0..MAX).
    >What else can a CA do when CRL number reaches MAX, stop issuing CRLs?
    >
    >"monotonically increasing" - Definition: A function from a partially
    order[ed]
    >domain to a partially ordered range such that x >= y implies f(x) >=
f(y).
    >
    >- From the NIST web site:
    >http://hissa.nist.gov/dads/HTML/monotoncincr.html
    >
    >Regards,
    >
    >Carlin
    >
    >____________________________
    >
    >-  Carlin Covey
    >    Cylink Corporation
    >
    >-----Original Message-----
    >From: Housley, Russ [mailto:[e-mail]]
    >Sent: Monday, May 07, 2001 6:21 AM
    >To: Santosh Chokhani
    >Cc: [e-mail]
    >Subject: RE: delta CRLs
    >
    >
    >Santosh:
    >
    >X.509 may allow the CRL number to wrap around, but I do not believe
that
    >PKIX does.
    >
    >     5.2.3  CRL Number
    >
    >     The CRL number is a non-critical CRL extension which conveys a
    >     monotonically increasing sequence number for each CRL issued by a
CA.
    >     This extension allows users to easily determine when a particular
CRL
    >     supersedes another CRL.  CAs conforming to this profile MUST
include
    >     this extension in all CRLs.
    >
    >     id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }
    >
    >Russ
    >
    >
    >At 10:11 PM 5/5/2001 -0400, Santosh Chokhani wrote:
    >
    > >Actually, the text allows for the wrap of the numbers.  Please see
Annex
    B
    > >of X.509.  Thus, it is not strictly increasing
    > >
    > >-----Original Message-----
    > >From: Peter Sylvester
    >
>[<mailto:[e-mail]>mailto:[e-mail]]
    > >Sent: Saturday, May 05, 2001 2:08 PM
    > >To: [e-mail]; [e-mail];
    > >[e-mail]
    > >Cc: [e-mail]
    > >Subject: RE: delta CRLs
    > >
    > > > Trevor:
    > > >
    > > > The 2000 version of X.509 is very clear on this.  For a given CRL
    stream
    > > > identifier, the CRL number is unique whether it is base or delta.
That
    is
    > > > why delta number has to be greater than the base.
    > >
    > >" 8.5.2.1 CRL number extension
    > >
    > >   This CRL extension field conveys a monotonically increasing
sequence
    > > number .."
    > >
    > >The text might be clearer IMHO if 'strictly increasing' would be used
    > >instead.


------=_NextPart_000_0077_01C0D873.B4133450
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: delta CRLs</TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D121152317-09052001>Santosh,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D121152317-09052001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D121152317-09052001>I=20
don't see that it matters whether the delta-CRL or the full CRL is =
assigned the=20
earlier number.&nbsp; But I'm not hard over about&nbsp;assigning them =
different=20
numbers.&nbsp;  I'm still willing to be convinced that it is bad that =
they have=20
different numbers, or good that they have the same number.&nbsp; Earlier =
today=20
Stephen Henson presented one argument for numbering them the same.&nbsp; =
Perhaps=20
that is a compelling reason.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D121152317-09052001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D121152317-09052001>
<P><FONT=20
size=3D2>Regards,<BR><BR>Carlin<BR><BR>____________________________<BR><B=
R>-&nbsp;=20
Carlin Covey<BR>&nbsp;&nbsp; Cylink Corporation =
</FONT></P></SPAN></FONT></DIV>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Santosh Chokhani=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Wednesday, May 09, 2001 =
10:13=20
  AM<BR><B>To:</B> Carlin Covey; Santosh Chokhani<BR><B>Cc:</B>=20
  [e-mail]<BR><B>Subject:</B> RE: delta =
CRLs<BR><BR></DIV></FONT>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D742462017-09052001>Are=20
  you suggesting that when they are issued at the same time, they should =
still=20
  have a different CRL number?</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D742462017-09052001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D742462017-09052001>Which one should have the number n and =
which one=20
  n+1?</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D742462017-09052001></SPAN></FONT>&nbsp;</DIV>
  <DIV class=3DOutlookMessageHeader><FONT face=3D"Times New Roman"=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Carlin Covey=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Wednesday, May 09, 2001 =
1:16=20
  PM<BR><B>To:</B> Santosh Chokhani<BR><B>Cc:</B>=20
  [e-mail]<BR><B>Subject:</B> RE: delta =
CRLs<BR><BR></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D523265216-09052001>Santosh,</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D523265216-09052001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D523265216-09052001>If=20
  simultaneously-issued delta-CRLs and full CRLs are to be numbered the =
same, I=20
  think your wording is a significant improvement over the current=20
  wording.&nbsp; However, I'm still undecided whether they should be =
numbered=20
  the same.&nbsp; It seems like simultaneously-issued delta-CRLs and =
full CRLs=20
  (and constructed CRLs) could be matched via the thisUpdate field =
without the=20
  necessity of violating the strictly increasing provision for CRL=20
  numbers.&nbsp; A unique reference for each CRL would be useful for =
evidentiary=20
  purposes, and for historical validation.&nbsp;&nbsp;Rendering a CRL =
identifier=20
  unique already requires the issuer ID, the set of reason&nbsp;codes, =
the set=20
  of certificate types, and either the CRL number or the thisUpdate =
value.&nbsp;=20
  I wonder if it is necessary to add the full vs. delta status as=20
  well.</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D523265216-09052001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D523265216-09052001>-=20
  Carlin</SPAN></FONT></DIV>
  <DIV><SPAN class=3D523265216-09052001></SPAN><FONT face=3DTahoma><FONT =

  size=3D2><SPAN class=3D523265216-09052001><FONT color=3D#0000ff=20
  face=3DArial>&nbsp;</FONT></SPAN></FONT></FONT></DIV>
  <DIV><FONT face=3DTahoma><FONT size=3D2><SPAN=20
  class=3D523265216-09052001>&nbsp;</SPAN>-----Original=20
  Message-----<BR><B>From:</B> Santosh Chokhani=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Wednesday, May 09, 2001 =
9:28=20
  AM<BR><B>To:</B> Carlin Covey; [e-mail]; David A. Cooper;=20
  [e-mail]; Santosh Chokhani<BR><B>Cc:</B>=20
  [e-mail]<BR><B>Subject:</B> RE: delta =
CRLs<BR><BR></DIV></FONT>
  <BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px"></FONT>
    <P><FONT size=3D2>I am simply suggesting that the numbers be =
strictly=20
    increasing, but if a base and delta are generated at the same time, =
they=20
    will have the same sequence number.&nbsp; Thus, if two CRLs (in the =
same=20
    stream identifier or when stream identifier is absent), have numbers =
n and=20
    m, the following shall be true (assuming no wrapping)</FONT></P>
    <P><FONT size=3D2>&nbsp;n =3D m if and only if thisUpdate of n =3D =
thisUpdate of=20
    m</FONT> </P>
    <P><FONT size=3D2>&nbsp;n &gt; m if and only if thisUpdate of n &gt; =

    thisUpdate of m</FONT> </P>
    <P><FONT size=3D2>&nbsp;n &lt; m if and only if thisUpdate of n &lt; =

    thisUpdate of m</FONT> </P>
    <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From:=20
    Carlin Covey [<A=20
    =
href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>=20
    <BR><FONT size=3D2>Sent: Wednesday, May 09, 2001 11:28 AM</FONT> =
<BR><FONT=20
    size=3D2>To: [e-mail]; David A. Cooper; =
[e-mail];</FONT>=20
    <BR><FONT size=3D2>[e-mail]</FONT> <BR><FONT =
size=3D2>Cc:=20
    [e-mail]</FONT> <BR><FONT size=3D2>Subject: RE: delta =
CRLs</FONT>=20
    </P><BR>
    <P><FONT size=3D2>David, Stephen, Ambarish, and Santosh,</FONT> </P>
    <P><FONT size=3D2>Some of us are in the business for the looooong =
haul.&nbsp;=20
    ;&gt;)</FONT> </P>
    <P><FONT size=3D2>Actually, I wasn't concerned about the CRL number =
wrapping,=20
    but that</FONT> <BR><FONT size=3D2>possibility was advanced a few =
days ago as=20
    an argument against the use of</FONT> <BR><FONT size=3D2>the =
"strictly=20
    increasing" wording.&nbsp; Another email commented that PKIX =
did</FONT>=20
    <BR><FONT size=3D2>not permit the number to wrap, although X.509 =
might.&nbsp;=20
    The only evidence I</FONT> <BR><FONT size=3D2>could find for X.509 =
permitting=20
    the number to wrap was "(0 .. MAX)".&nbsp; As</FONT> <BR><FONT=20
    size=3D2>various people have pointed out, one could be drumming =
one's fingers=20
    for</FONT> <BR><FONT size=3D2>quite a while........</FONT> </P>
    <P><FONT size=3D2>My real point was that the "monotonically =
increasing"=20
    wording permits the</FONT> <BR><FONT size=3D2>CRL number to stay the =
same,=20
    while "strictly increasing" forces the numbers</FONT> <BR><FONT =
size=3D2>to be=20
    unique (issues of wrapping aside in both cases).&nbsp; Stephen =
Henson=20
    just</FONT> <BR><FONT size=3D2>pointed out a reason why one might =
want the CRL=20
    number to stay the same when</FONT> <BR><FONT size=3D2>issuing a =
delta CRL at=20
    the same time as a full CRL.&nbsp; I am not arguing either</FONT> =
<BR><FONT=20
    size=3D2>for or against that case, but it seems desirable to force =
the CRL=20
    numbers to</FONT> <BR><FONT size=3D2>be unique in most cases.&nbsp; =
(Unless,=20
    the CRLs are distinguished based upon</FONT> <BR><FONT =
size=3D2>thisUpdate, as=20
    Santosh has suggested.)</FONT> </P>
    <P><FONT size=3D2>Regards,</FONT> </P>
    <P><FONT size=3D2>Carlin</FONT> </P>
    <P><FONT size=3D2>____________________________</FONT> </P>
    <P><FONT size=3D2>-&nbsp; Carlin Covey</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp;=20
    Cylink Corporation</FONT> </P><BR><BR>
    <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From:=20
    David A. Cooper [<A=20
    =
href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</=
FONT>=20
    <BR><FONT size=3D2>Sent: Wednesday, May 09, 2001 6:03 AM</FONT> =
<BR><FONT=20
    size=3D2>To: '[e-mail] '</FONT> <BR><FONT size=3D2>Subject: =
RE: delta=20
    CRLs</FONT> </P><BR>
    <P><FONT size=3D2>&nbsp;From a practical point of view, I don't =
think that we=20
    should need to worry</FONT> <BR><FONT size=3D2>about CRL numbers=20
    wrapping.&nbsp; According to my calculations, if one assigns</FONT>=20
    <BR><FONT size=3D2>cRLNumber 1 to the first CRL and then numbers =
CRLs=20
    consecutively, one could</FONT> <BR><FONT size=3D2>issue a new CRL =
every=20
    second for 68 years before the cRLNumber would require</FONT> =
<BR><FONT=20
    size=3D2>more than 4 bytes (32 bits) to encode.&nbsp; On the other =
hand, if=20
    you're willing</FONT> <BR><FONT size=3D2>to issue a new CRL only =
once a=20
    minute, it would take 4083 years before the</FONT> <BR><FONT=20
    size=3D2>cRLNumber would require more than 4 bytes to encode.</FONT> =
</P>
    <P><FONT size=3D2>BTW, I thought that the purpose of the "(0 .. =
MAX)" was just=20
    to prevent use</FONT> <BR><FONT size=3D2>of negative numbers. While =
there may,=20
    in theory be a limit to the size of an</FONT> <BR><FONT =
size=3D2>integer that=20
    may be encoded, for all practical purposes, one can encode =
any</FONT>=20
    <BR><FONT size=3D2>integet. According to "A Layman's Guide to a =
Subset of=20
    ASN.1, BER, and DER",</FONT> <BR><FONT size=3D2>a DER encoded value =
can have a=20
    length of up to 2 ** 1008 - 1 bytes. Thus,</FONT> <BR><FONT =
size=3D2>MAX =3D 2=20
    ** [8 * ((2 ** 1008) - 1) - 1] - 1, which is far larger than =
any</FONT>=20
    <BR><FONT size=3D2>number we would ever need.</FONT> </P>
    <P><FONT size=3D2>Dave</FONT> </P>
    <P><FONT size=3D2>At 08:57 PM 5/8/01 -0700, Ambarish Malpani =
wrote:</FONT>=20
    <BR><FONT size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;I always =
thought MAX for=20
    ASN.1 INTEGERs was something I would never</FONT> <BR><FONT =
size=3D2>&gt;need=20
    to worry about.</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT=20
    size=3D2>&gt;Looks like I was wrong :-)</FONT> <BR><FONT =
size=3D2>&gt;</FONT>=20
    <BR><FONT size=3D2>&gt;By the way, what is MAX? I know that we can =
represent=20
    numbers with</FONT> <BR><FONT size=3D2>&gt;over 2048 bits...</FONT> =
<BR><FONT=20
    size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;A</FONT> <BR><FONT=20
    size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;-----Original =
Message-----</FONT>=20
    <BR><FONT size=3D2>&gt;From: Carlin Covey</FONT> <BR><FONT =
size=3D2>&gt;To:=20
    Housley, Russ; Santosh Chokhani</FONT> <BR><FONT size=3D2>&gt;Cc:=20
    [e-mail]</FONT> <BR><FONT size=3D2>&gt;Sent: 5/8/01 5:53 =
PM</FONT>=20
    <BR><FONT size=3D2>&gt;Subject: RE: delta CRLs</FONT> <BR><FONT=20
    size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;Russ,</FONT> <BR><FONT=20
    size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;A week or two ago we =
arrived at a=20
    consensus to remove the requirement</FONT> <BR><FONT =
size=3D2>&gt;that a CA=20
    issue a full CRL whenever the CA issues a Delta-CRL.&nbsp; If =
the</FONT>=20
    <BR><FONT size=3D2>&gt;CA chooses to issue them simultaneously, why =
would they=20
    need to be numbered</FONT> <BR><FONT size=3D2>&gt;the same?&nbsp; If =
this=20
    requirement were lifted, it seems like requiring the CRL</FONT> =
<BR><FONT=20
    size=3D2>&gt;number to be "strictly increasing" in a sequence would =
be=20
    preferable to</FONT> <BR><FONT size=3D2>&gt;"monotonically =
increasing".&nbsp;=20
    "Monotonically increasing" allows the</FONT> <BR><FONT=20
    size=3D2>possibility</FONT> <BR><FONT size=3D2>&gt;that the CRL =
number never=20
    changes, which seems undesirable.&nbsp; I realize</FONT> <BR><FONT=20
    size=3D2>&gt;that in either case the CRL number might wrap around at =
some=20
    point in the</FONT> <BR><FONT size=3D2>future.</FONT> <BR><FONT=20
    size=3D2>&gt;That is inevitable, given that that CRL number is =
defined as=20
    INTEGER</FONT> <BR><FONT size=3D2>(0..MAX).</FONT> <BR><FONT =
size=3D2>&gt;What=20
    else can a CA do when CRL number reaches MAX, stop issuing =
CRLs?</FONT>=20
    <BR><FONT size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;"monotonically =
increasing"=20
    - Definition: A function from a partially</FONT> <BR><FONT=20
    size=3D2>order[ed]</FONT> <BR><FONT size=3D2>&gt;domain to a =
partially ordered=20
    range such that x &gt;=3D y implies f(x) &gt;=3D f(y).</FONT> =
<BR><FONT=20
    size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;- From the NIST web =
site:</FONT>=20
    <BR><FONT size=3D2>&gt;<A=20
    href=3D"http://hissa.nist.gov/dads/HTML/monotoncincr.html"=20
    =
target=3D_blank>http://hissa.nist.gov/dads/HTML/monotoncincr.html</A></FO=
NT>=20
    <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =
size=3D2>&gt;Regards,</FONT> <BR><FONT=20
    size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;Carlin</FONT> <BR><FONT=20
    size=3D2>&gt;</FONT> <BR><FONT =
size=3D2>&gt;____________________________</FONT>=20
    <BR><FONT size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;-&nbsp; Carlin =

    Covey</FONT> <BR><FONT size=3D2>&gt;&nbsp;&nbsp;&nbsp; Cylink=20
    Corporation</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT=20
    size=3D2>&gt;-----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt;From:=20
    Housley, Russ [<A=20
    =
href=3D"mailto:[e-mail]">mailto:[e-mail]<=
/A>]</FONT>=20
    <BR><FONT size=3D2>&gt;Sent: Monday, May 07, 2001 6:21 AM</FONT> =
<BR><FONT=20
    size=3D2>&gt;To: Santosh Chokhani</FONT> <BR><FONT size=3D2>&gt;Cc:=20
    [e-mail]</FONT> <BR><FONT size=3D2>&gt;Subject: RE: delta =
CRLs</FONT>=20
    <BR><FONT size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;</FONT> =
<BR><FONT=20
    size=3D2>&gt;Santosh:</FONT> <BR><FONT size=3D2>&gt;</FONT> =
<BR><FONT=20
    size=3D2>&gt;X.509 may allow the CRL number to wrap around, but I do =
not=20
    believe that</FONT> <BR><FONT size=3D2>&gt;PKIX does.</FONT> =
<BR><FONT=20
    size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; =
5.2.3&nbsp;=20
    CRL Number</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT=20
    size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; The CRL number is a =
non-critical CRL=20
    extension which conveys a</FONT> <BR><FONT=20
    size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; monotonically increasing =
sequence number=20
    for each CRL issued by a CA.</FONT> <BR><FONT=20
    size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; This extension allows users to =
easily=20
    determine when a particular CRL</FONT> <BR><FONT=20
    size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; supersedes another CRL.&nbsp; =
CAs=20
    conforming to this profile MUST include</FONT> <BR><FONT=20
    size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; this extension in all =
CRLs.</FONT>=20
    <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;=20
    id-ce-cRLNumber OBJECT IDENTIFIER ::=3D { id-ce 20 }</FONT> =
<BR><FONT=20
    size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;Russ</FONT> <BR><FONT=20
    size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =
size=3D2>&gt;At=20
    10:11 PM 5/5/2001 -0400, Santosh Chokhani wrote:</FONT> <BR><FONT=20
    size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt; &gt;Actually, the text =
allows for=20
    the wrap of the numbers.&nbsp; Please see Annex</FONT> <BR><FONT=20
    size=3D2>B</FONT> <BR><FONT size=3D2>&gt; &gt;of X.509.&nbsp; Thus, =
it is not=20
    strictly increasing</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt;-----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;From: Peter Sylvester</FONT> <BR><FONT size=3D2>&gt; &gt;[&lt;<A =

    =
href=3D"mailto:[e-mail]">mailto:Peter.Sylvester@EdelWeb=
.fr</A>&gt;<A=20
    =
href=3D"mailto:[e-mail]">mailto:Peter.Sylvester@EdelWeb=
.fr</A>]</FONT>=20
    <BR><FONT size=3D2>&gt; &gt;Sent: Saturday, May 05, 2001 2:08 =
PM</FONT>=20
    <BR><FONT size=3D2>&gt; &gt;To: [e-mail];=20
    [e-mail];</FONT> <BR><FONT size=3D2>&gt;=20
    &gt;[e-mail]</FONT> <BR><FONT size=3D2>&gt; &gt;Cc:=20
    [e-mail]</FONT> <BR><FONT size=3D2>&gt; &gt;Subject: RE: =
delta=20
    CRLs</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
    &gt; Trevor:</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt; &gt; The 2000 version of X.509 is very clear on =
this.&nbsp;=20
    For a given CRL</FONT> <BR><FONT size=3D2>stream</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt; &gt; identifier, the CRL number is unique whether it is base or =
delta.=20
    That</FONT> <BR><FONT size=3D2>is</FONT> <BR><FONT size=3D2>&gt; =
&gt; &gt; why=20
    delta number has to be greater than the base.</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;</FONT> <BR><FONT size=3D2>&gt; &gt;" 8.5.2.1 CRL number =
extension</FONT>=20
    <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt;&nbsp;&nbsp;=20
    This CRL extension field conveys a monotonically increasing =
sequence</FONT>=20
    <BR><FONT size=3D2>&gt; &gt; number .."</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;</FONT> <BR><FONT size=3D2>&gt; &gt;The text might be clearer =
IMHO if=20
    'strictly increasing' would be used</FONT> <BR><FONT size=3D2>&gt;=20
    &gt;instead.</FONT> </P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0077_01C0D873.B4133450--



Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA03801 for <[e-mail]>; Wed, 9 May 2001 10:22:56 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <KS8ZMMAX>; Wed, 9 May 2001 13:22:27 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Carlin Covey <[e-mail]>, Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Subject: RE: delta CRLs
Date: Wed, 9 May 2001 13:13:13 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D8AB.54A54B60"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D8AB.54A54B60
Content-Type: text/plain;
	charset="iso-8859-1"

Are you suggesting that when they are issued at the same time, they should
still have a different CRL number?
 
Which one should have the number n and which one n+1?
 
-----Original Message-----
From: Carlin Covey [mailto:[e-mail]]
Sent: Wednesday, May 09, 2001 1:16 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: delta CRLs


Santosh,
 
If simultaneously-issued delta-CRLs and full CRLs are to be numbered the
same, I think your wording is a significant improvement over the current
wording.  However, I'm still undecided whether they should be numbered the
same.  It seems like simultaneously-issued delta-CRLs and full CRLs (and
constructed CRLs) could be matched via the thisUpdate field without the
necessity of violating the strictly increasing provision for CRL numbers.  A
unique reference for each CRL would be useful for evidentiary purposes, and
for historical validation.  Rendering a CRL identifier unique already
requires the issuer ID, the set of reason codes, the set of certificate
types, and either the CRL number or the thisUpdate value.  I wonder if it is
necessary to add the full vs. delta status as well.
 
- Carlin
 
 -----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Wednesday, May 09, 2001 9:28 AM
To: Carlin Covey; [e-mail]; David A. Cooper; [e-mail];
Santosh Chokhani
Cc: [e-mail]
Subject: RE: delta CRLs



I am simply suggesting that the numbers be strictly increasing, but if a
base and delta are generated at the same time, they will have the same
sequence number.  Thus, if two CRLs (in the same stream identifier or when
stream identifier is absent), have numbers n and m, the following shall be
true (assuming no wrapping)

 n = m if and only if thisUpdate of n = thisUpdate of m 

 n > m if and only if thisUpdate of n > thisUpdate of m 

 n < m if and only if thisUpdate of n < thisUpdate of m 

-----Original Message----- 
From: Carlin Covey [ mailto:[e-mail] <mailto:[e-mail]> ] 
Sent: Wednesday, May 09, 2001 11:28 AM 
To: [e-mail]; David A. Cooper; [e-mail]; 
[e-mail] 
Cc: [e-mail] 
Subject: RE: delta CRLs 


David, Stephen, Ambarish, and Santosh, 

Some of us are in the business for the looooong haul.  ;>) 

Actually, I wasn't concerned about the CRL number wrapping, but that 
possibility was advanced a few days ago as an argument against the use of 
the "strictly increasing" wording.  Another email commented that PKIX did 
not permit the number to wrap, although X.509 might.  The only evidence I 
could find for X.509 permitting the number to wrap was "(0 .. MAX)".  As 
various people have pointed out, one could be drumming one's fingers for 
quite a while........ 

My real point was that the "monotonically increasing" wording permits the 
CRL number to stay the same, while "strictly increasing" forces the numbers 
to be unique (issues of wrapping aside in both cases).  Stephen Henson just 
pointed out a reason why one might want the CRL number to stay the same when

issuing a delta CRL at the same time as a full CRL.  I am not arguing either

for or against that case, but it seems desirable to force the CRL numbers to

be unique in most cases.  (Unless, the CRLs are distinguished based upon 
thisUpdate, as Santosh has suggested.) 

Regards, 

Carlin 

____________________________ 

-  Carlin Covey 
   Cylink Corporation 



-----Original Message----- 
From: David A. Cooper [ mailto:[e-mail]
<mailto:[e-mail]> ] 
Sent: Wednesday, May 09, 2001 6:03 AM 
To: '[e-mail] ' 
Subject: RE: delta CRLs 


 From a practical point of view, I don't think that we should need to worry 
about CRL numbers wrapping.  According to my calculations, if one assigns 
cRLNumber 1 to the first CRL and then numbers CRLs consecutively, one could 
issue a new CRL every second for 68 years before the cRLNumber would require

more than 4 bytes (32 bits) to encode.  On the other hand, if you're willing

to issue a new CRL only once a minute, it would take 4083 years before the 
cRLNumber would require more than 4 bytes to encode. 

BTW, I thought that the purpose of the "(0 .. MAX)" was just to prevent use 
of negative numbers. While there may, in theory be a limit to the size of an

integer that may be encoded, for all practical purposes, one can encode any 
integet. According to "A Layman's Guide to a Subset of ASN.1, BER, and DER",

a DER encoded value can have a length of up to 2 ** 1008 - 1 bytes. Thus, 
MAX = 2 ** [8 * ((2 ** 1008) - 1) - 1] - 1, which is far larger than any 
number we would ever need. 

Dave 

At 08:57 PM 5/8/01 -0700, Ambarish Malpani wrote: 
> 
>I always thought MAX for ASN.1 INTEGERs was something I would never 
>need to worry about. 
> 
>Looks like I was wrong :-) 
> 
>By the way, what is MAX? I know that we can represent numbers with 
>over 2048 bits... 
> 
>A 
> 
>-----Original Message----- 
>From: Carlin Covey 
>To: Housley, Russ; Santosh Chokhani 
>Cc: [e-mail] 
>Sent: 5/8/01 5:53 PM 
>Subject: RE: delta CRLs 
> 
>Russ, 
> 
>A week or two ago we arrived at a consensus to remove the requirement 
>that a CA issue a full CRL whenever the CA issues a Delta-CRL.  If the 
>CA chooses to issue them simultaneously, why would they need to be numbered

>the same?  If this requirement were lifted, it seems like requiring the CRL

>number to be "strictly increasing" in a sequence would be preferable to 
>"monotonically increasing".  "Monotonically increasing" allows the 
possibility 
>that the CRL number never changes, which seems undesirable.  I realize 
>that in either case the CRL number might wrap around at some point in the 
future. 
>That is inevitable, given that that CRL number is defined as INTEGER 
(0..MAX). 
>What else can a CA do when CRL number reaches MAX, stop issuing CRLs? 
> 
>"monotonically increasing" - Definition: A function from a partially 
order[ed] 
>domain to a partially ordered range such that x >= y implies f(x) >= f(y). 
> 
>- From the NIST web site: 
> http://hissa.nist.gov/dads/HTML/monotoncincr.html
<http://hissa.nist.gov/dads/HTML/monotoncincr.html>  
> 
>Regards, 
> 
>Carlin 
> 
>____________________________ 
> 
>-  Carlin Covey 
>    Cylink Corporation 
> 
>-----Original Message----- 
>From: Housley, Russ [ mailto:[e-mail]
<mailto:[e-mail]> ] 
>Sent: Monday, May 07, 2001 6:21 AM 
>To: Santosh Chokhani 
>Cc: [e-mail] 
>Subject: RE: delta CRLs 
> 
> 
>Santosh: 
> 
>X.509 may allow the CRL number to wrap around, but I do not believe that 
>PKIX does. 
> 
>     5.2.3  CRL Number 
> 
>     The CRL number is a non-critical CRL extension which conveys a 
>     monotonically increasing sequence number for each CRL issued by a CA. 
>     This extension allows users to easily determine when a particular CRL 
>     supersedes another CRL.  CAs conforming to this profile MUST include 
>     this extension in all CRLs. 
> 
>     id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 
> 
>Russ 
> 
> 
>At 10:11 PM 5/5/2001 -0400, Santosh Chokhani wrote: 
> 
> >Actually, the text allows for the wrap of the numbers.  Please see Annex 
B 
> >of X.509.  Thus, it is not strictly increasing 
> > 
> >-----Original Message----- 
> >From: Peter Sylvester 
> >[< mailto:[e-mail] <mailto:[e-mail]>
> mailto:[e-mail] <mailto:[e-mail]> ] 
> >Sent: Saturday, May 05, 2001 2:08 PM 
> >To: [e-mail]; [e-mail]; 
> >[e-mail] 
> >Cc: [e-mail] 
> >Subject: RE: delta CRLs 
> > 
> > > Trevor: 
> > > 
> > > The 2000 version of X.509 is very clear on this.  For a given CRL 
stream 
> > > identifier, the CRL number is unique whether it is base or delta. That

is 
> > > why delta number has to be greater than the base. 
> > 
> >" 8.5.2.1 CRL number extension 
> > 
> >   This CRL extension field conveys a monotonically increasing sequence 
> > number .." 
> > 
> >The text might be clearer IMHO if 'strictly increasing' would be used 
> >instead. 


------_=_NextPart_001_01C0D8AB.54A54B60
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: delta CRLs</TITLE>

<META content="MSHTML 5.00.2014.210" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=742462017-09052001>Are 
you suggesting that when they are issued at the same time, they should still 
have a different CRL number?</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=742462017-09052001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=742462017-09052001>Which 
one should have the number n and which one n+1?</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=742462017-09052001></SPAN></FONT>&nbsp;</DIV>
<DIV class=OutlookMessageHeader><FONT face="Times New Roman" 
size=2>-----Original Message-----<BR><B>From:</B> Carlin Covey 
[mailto:[e-mail]]<BR><B>Sent:</B> Wednesday, May 09, 2001 1:16 
PM<BR><B>To:</B> Santosh Chokhani<BR><B>Cc:</B> 
[e-mail]<BR><B>Subject:</B> RE: delta CRLs<BR><BR></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=523265216-09052001>Santosh,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=523265216-09052001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=523265216-09052001>If 
simultaneously-issued delta-CRLs and full CRLs are to be numbered the same, I 
think your wording is a significant improvement over the current wording.&nbsp; 
However, I'm still undecided whether they should be numbered the same.&nbsp; It 
seems like simultaneously-issued delta-CRLs and full CRLs (and constructed CRLs) 
could be matched via the thisUpdate field without the necessity of violating the 
strictly increasing provision for CRL numbers.&nbsp; A unique reference for each 
CRL would be useful for evidentiary purposes, and for historical 
validation.&nbsp;&nbsp;Rendering a CRL identifier unique already requires the 
issuer ID, the set of reason&nbsp;codes, the set of certificate types, and 
either the CRL number or the thisUpdate value.&nbsp; I wonder if it is necessary 
to add the full vs. delta status as well.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=523265216-09052001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=523265216-09052001>- 
Carlin</SPAN></FONT></DIV>
<DIV><SPAN class=523265216-09052001></SPAN><FONT face=Tahoma><FONT size=2><SPAN 
class=523265216-09052001><FONT color=#0000ff 
face=Arial>&nbsp;</FONT></SPAN></FONT></FONT></DIV>
<DIV><FONT face=Tahoma><FONT size=2><SPAN 
class=523265216-09052001>&nbsp;</SPAN>-----Original Message-----<BR><B>From:</B> 
Santosh Chokhani [mailto:[e-mail]]<BR><B>Sent:</B> Wednesday, May 
09, 2001 9:28 AM<BR><B>To:</B> Carlin Covey; [e-mail]; David A. Cooper; 
[e-mail]; Santosh Chokhani<BR><B>Cc:</B> 
[e-mail]<BR><B>Subject:</B> RE: delta CRLs<BR><BR></DIV></FONT>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px"></FONT>
  <P><FONT size=2>I am simply suggesting that the numbers be strictly 
  increasing, but if a base and delta are generated at the same time, they will 
  have the same sequence number.&nbsp; Thus, if two CRLs (in the same stream 
  identifier or when stream identifier is absent), have numbers n and m, the 
  following shall be true (assuming no wrapping)</FONT></P>
  <P><FONT size=2>&nbsp;n = m if and only if thisUpdate of n = thisUpdate of 
  m</FONT> </P>
  <P><FONT size=2>&nbsp;n &gt; m if and only if thisUpdate of n &gt; thisUpdate 
  of m</FONT> </P>
  <P><FONT size=2>&nbsp;n &lt; m if and only if thisUpdate of n &lt; thisUpdate 
  of m</FONT> </P>
  <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: 
  Carlin Covey [<A 
  href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> <BR><FONT 
  size=2>Sent: Wednesday, May 09, 2001 11:28 AM</FONT> <BR><FONT size=2>To: 
  [e-mail]; David A. Cooper; [e-mail];</FONT> <BR><FONT 
  size=2>[e-mail]</FONT> <BR><FONT size=2>Cc: 
  [e-mail]</FONT> <BR><FONT size=2>Subject: RE: delta CRLs</FONT> 
  </P><BR>
  <P><FONT size=2>David, Stephen, Ambarish, and Santosh,</FONT> </P>
  <P><FONT size=2>Some of us are in the business for the looooong haul.&nbsp; 
  ;&gt;)</FONT> </P>
  <P><FONT size=2>Actually, I wasn't concerned about the CRL number wrapping, 
  but that</FONT> <BR><FONT size=2>possibility was advanced a few days ago as an 
  argument against the use of</FONT> <BR><FONT size=2>the "strictly increasing" 
  wording.&nbsp; Another email commented that PKIX did</FONT> <BR><FONT 
  size=2>not permit the number to wrap, although X.509 might.&nbsp; The only 
  evidence I</FONT> <BR><FONT size=2>could find for X.509 permitting the number 
  to wrap was "(0 .. MAX)".&nbsp; As</FONT> <BR><FONT size=2>various people have 
  pointed out, one could be drumming one's fingers for</FONT> <BR><FONT 
  size=2>quite a while........</FONT> </P>
  <P><FONT size=2>My real point was that the "monotonically increasing" wording 
  permits the</FONT> <BR><FONT size=2>CRL number to stay the same, while 
  "strictly increasing" forces the numbers</FONT> <BR><FONT size=2>to be unique 
  (issues of wrapping aside in both cases).&nbsp; Stephen Henson just</FONT> 
  <BR><FONT size=2>pointed out a reason why one might want the CRL number to 
  stay the same when</FONT> <BR><FONT size=2>issuing a delta CRL at the same 
  time as a full CRL.&nbsp; I am not arguing either</FONT> <BR><FONT size=2>for 
  or against that case, but it seems desirable to force the CRL numbers 
  to</FONT> <BR><FONT size=2>be unique in most cases.&nbsp; (Unless, the CRLs 
  are distinguished based upon</FONT> <BR><FONT size=2>thisUpdate, as Santosh 
  has suggested.)</FONT> </P>
  <P><FONT size=2>Regards,</FONT> </P>
  <P><FONT size=2>Carlin</FONT> </P>
  <P><FONT size=2>____________________________</FONT> </P>
  <P><FONT size=2>-&nbsp; Carlin Covey</FONT> <BR><FONT size=2>&nbsp;&nbsp; 
  Cylink Corporation</FONT> </P><BR><BR>
  <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: David 
  A. Cooper [<A 
  href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
  <BR><FONT size=2>Sent: Wednesday, May 09, 2001 6:03 AM</FONT> <BR><FONT 
  size=2>To: '[e-mail] '</FONT> <BR><FONT size=2>Subject: RE: delta 
  CRLs</FONT> </P><BR>
  <P><FONT size=2>&nbsp;From a practical point of view, I don't think that we 
  should need to worry</FONT> <BR><FONT size=2>about CRL numbers wrapping.&nbsp; 
  According to my calculations, if one assigns</FONT> <BR><FONT size=2>cRLNumber 
  1 to the first CRL and then numbers CRLs consecutively, one could</FONT> 
  <BR><FONT size=2>issue a new CRL every second for 68 years before the 
  cRLNumber would require</FONT> <BR><FONT size=2>more than 4 bytes (32 bits) to 
  encode.&nbsp; On the other hand, if you're willing</FONT> <BR><FONT size=2>to 
  issue a new CRL only once a minute, it would take 4083 years before the</FONT> 
  <BR><FONT size=2>cRLNumber would require more than 4 bytes to encode.</FONT> 
  </P>
  <P><FONT size=2>BTW, I thought that the purpose of the "(0 .. MAX)" was just 
  to prevent use</FONT> <BR><FONT size=2>of negative numbers. While there may, 
  in theory be a limit to the size of an</FONT> <BR><FONT size=2>integer that 
  may be encoded, for all practical purposes, one can encode any</FONT> 
  <BR><FONT size=2>integet. According to "A Layman's Guide to a Subset of ASN.1, 
  BER, and DER",</FONT> <BR><FONT size=2>a DER encoded value can have a length 
  of up to 2 ** 1008 - 1 bytes. Thus,</FONT> <BR><FONT size=2>MAX = 2 ** [8 * 
  ((2 ** 1008) - 1) - 1] - 1, which is far larger than any</FONT> <BR><FONT 
  size=2>number we would ever need.</FONT> </P>
  <P><FONT size=2>Dave</FONT> </P>
  <P><FONT size=2>At 08:57 PM 5/8/01 -0700, Ambarish Malpani wrote:</FONT> 
  <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;I always thought MAX for 
  ASN.1 INTEGERs was something I would never</FONT> <BR><FONT size=2>&gt;need to 
  worry about.</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;Looks 
  like I was wrong :-)</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
  size=2>&gt;By the way, what is MAX? I know that we can represent numbers 
  with</FONT> <BR><FONT size=2>&gt;over 2048 bits...</FONT> <BR><FONT 
  size=2>&gt;</FONT> <BR><FONT size=2>&gt;A</FONT> <BR><FONT size=2>&gt;</FONT> 
  <BR><FONT size=2>&gt;-----Original Message-----</FONT> <BR><FONT 
  size=2>&gt;From: Carlin Covey</FONT> <BR><FONT size=2>&gt;To: Housley, Russ; 
  Santosh Chokhani</FONT> <BR><FONT size=2>&gt;Cc: [e-mail]</FONT> 
  <BR><FONT size=2>&gt;Sent: 5/8/01 5:53 PM</FONT> <BR><FONT size=2>&gt;Subject: 
  RE: delta CRLs</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
  size=2>&gt;Russ,</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;A 
  week or two ago we arrived at a consensus to remove the requirement</FONT> 
  <BR><FONT size=2>&gt;that a CA issue a full CRL whenever the CA issues a 
  Delta-CRL.&nbsp; If the</FONT> <BR><FONT size=2>&gt;CA chooses to issue them 
  simultaneously, why would they need to be numbered</FONT> <BR><FONT 
  size=2>&gt;the same?&nbsp; If this requirement were lifted, it seems like 
  requiring the CRL</FONT> <BR><FONT size=2>&gt;number to be "strictly 
  increasing" in a sequence would be preferable to</FONT> <BR><FONT 
  size=2>&gt;"monotonically increasing".&nbsp; "Monotonically increasing" allows 
  the</FONT> <BR><FONT size=2>possibility</FONT> <BR><FONT size=2>&gt;that the 
  CRL number never changes, which seems undesirable.&nbsp; I realize</FONT> 
  <BR><FONT size=2>&gt;that in either case the CRL number might wrap around at 
  some point in the</FONT> <BR><FONT size=2>future.</FONT> <BR><FONT 
  size=2>&gt;That is inevitable, given that that CRL number is defined as 
  INTEGER</FONT> <BR><FONT size=2>(0..MAX).</FONT> <BR><FONT size=2>&gt;What 
  else can a CA do when CRL number reaches MAX, stop issuing CRLs?</FONT> 
  <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;"monotonically increasing" - 
  Definition: A function from a partially</FONT> <BR><FONT 
  size=2>order[ed]</FONT> <BR><FONT size=2>&gt;domain to a partially ordered 
  range such that x &gt;= y implies f(x) &gt;= f(y).</FONT> <BR><FONT 
  size=2>&gt;</FONT> <BR><FONT size=2>&gt;- From the NIST web site:</FONT> 
  <BR><FONT size=2>&gt;<A 
  href="http://hissa.nist.gov/dads/HTML/monotoncincr.html" 
  target=_blank>http://hissa.nist.gov/dads/HTML/monotoncincr.html</A></FONT> 
  <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;Regards,</FONT> <BR><FONT 
  size=2>&gt;</FONT> <BR><FONT size=2>&gt;Carlin</FONT> <BR><FONT 
  size=2>&gt;</FONT> <BR><FONT size=2>&gt;____________________________</FONT> 
  <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;-&nbsp; Carlin Covey</FONT> 
  <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp; Cylink Corporation</FONT> <BR><FONT 
  size=2>&gt;</FONT> <BR><FONT size=2>&gt;-----Original Message-----</FONT> 
  <BR><FONT size=2>&gt;From: Housley, Russ [<A 
  href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
  <BR><FONT size=2>&gt;Sent: Monday, May 07, 2001 6:21 AM</FONT> <BR><FONT 
  size=2>&gt;To: Santosh Chokhani</FONT> <BR><FONT size=2>&gt;Cc: 
  [e-mail]</FONT> <BR><FONT size=2>&gt;Subject: RE: delta CRLs</FONT> 
  <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
  size=2>&gt;Santosh:</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
  size=2>&gt;X.509 may allow the CRL number to wrap around, but I do not believe 
  that</FONT> <BR><FONT size=2>&gt;PKIX does.</FONT> <BR><FONT 
  size=2>&gt;</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; 5.2.3&nbsp; 
  CRL Number</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; The CRL number is a non-critical CRL 
  extension which conveys a</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; 
  monotonically increasing sequence number for each CRL issued by a CA.</FONT> 
  <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; This extension allows users to 
  easily determine when a particular CRL</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; supersedes another CRL.&nbsp; CAs 
  conforming to this profile MUST include</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; this extension in all CRLs.</FONT> 
  <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; 
  id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }</FONT> <BR><FONT 
  size=2>&gt;</FONT> <BR><FONT size=2>&gt;Russ</FONT> <BR><FONT 
  size=2>&gt;</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;At 10:11 
  PM 5/5/2001 -0400, Santosh Chokhani wrote:</FONT> <BR><FONT size=2>&gt;</FONT> 
  <BR><FONT size=2>&gt; &gt;Actually, the text allows for the wrap of the 
  numbers.&nbsp; Please see Annex</FONT> <BR><FONT size=2>B</FONT> <BR><FONT 
  size=2>&gt; &gt;of X.509.&nbsp; Thus, it is not strictly increasing</FONT> 
  <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;-----Original 
  Message-----</FONT> <BR><FONT size=2>&gt; &gt;From: Peter Sylvester</FONT> 
  <BR><FONT size=2>&gt; &gt;[&lt;<A 
  href="mailto:[e-mail]">mailto:[e-mail]</A>&gt;<A 
  href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
  <BR><FONT size=2>&gt; &gt;Sent: Saturday, May 05, 2001 2:08 PM</FONT> 
  <BR><FONT size=2>&gt; &gt;To: [e-mail]; 
  [e-mail];</FONT> <BR><FONT size=2>&gt; 
  &gt;[e-mail]</FONT> <BR><FONT size=2>&gt; &gt;Cc: 
  [e-mail]</FONT> <BR><FONT size=2>&gt; &gt;Subject: RE: delta 
  CRLs</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; 
  Trevor:</FONT> <BR><FONT size=2>&gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; 
  &gt; &gt; The 2000 version of X.509 is very clear on this.&nbsp; For a given 
  CRL</FONT> <BR><FONT size=2>stream</FONT> <BR><FONT size=2>&gt; &gt; &gt; 
  identifier, the CRL number is unique whether it is base or delta. That</FONT> 
  <BR><FONT size=2>is</FONT> <BR><FONT size=2>&gt; &gt; &gt; why delta number 
  has to be greater than the base.</FONT> <BR><FONT size=2>&gt; &gt;</FONT> 
  <BR><FONT size=2>&gt; &gt;" 8.5.2.1 CRL number extension</FONT> <BR><FONT 
  size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;&nbsp;&nbsp; This CRL 
  extension field conveys a monotonically increasing sequence</FONT> <BR><FONT 
  size=2>&gt; &gt; number .."</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT 
  size=2>&gt; &gt;The text might be clearer IMHO if 'strictly increasing' would 
  be used</FONT> <BR><FONT size=2>&gt; &gt;instead.</FONT> 
</P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C0D8AB.54A54B60--


Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA03156 for <[e-mail]>; Wed, 9 May 2001 10:16:36 -0700 (PDT)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id J0AR5YG6; Wed, 9 May 2001 10:10:58 -0700
From: "Carlin Covey" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: delta CRLs
Date: Wed, 9 May 2001 10:15:51 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0054_01C0D871.0608D4C0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

This is a multi-part message in MIME format.

------=_NextPart_000_0054_01C0D871.0608D4C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

RE: delta CRLsSantosh,

If simultaneously-issued delta-CRLs and full CRLs are to be numbered the
same, I think your wording is a significant improvement over the current
wording.  However, I'm still undecided whether they should be numbered the
same.  It seems like simultaneously-issued delta-CRLs and full CRLs (and
constructed CRLs) could be matched via the thisUpdate field without the
necessity of violating the strictly increasing provision for CRL numbers.  A
unique reference for each CRL would be useful for evidentiary purposes, and
for historical validation.  Rendering a CRL identifier unique already
requires the issuer ID, the set of reason codes, the set of certificate
types, and either the CRL number or the thisUpdate value.  I wonder if it is
necessary to add the full vs. delta status as well.

- Carlin

 -----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Wednesday, May 09, 2001 9:28 AM
To: Carlin Covey; [e-mail]; David A. Cooper; [e-mail];
Santosh Chokhani
Cc: [e-mail]
Subject: RE: delta CRLs


  I am simply suggesting that the numbers be strictly increasing, but if a
base and delta are generated at the same time, they will have the same
sequence number.  Thus, if two CRLs (in the same stream identifier or when
stream identifier is absent), have numbers n and m, the following shall be
true (assuming no wrapping)

   n = m if and only if thisUpdate of n = thisUpdate of m

   n > m if and only if thisUpdate of n > thisUpdate of m

   n < m if and only if thisUpdate of n < thisUpdate of m

  -----Original Message-----
  From: Carlin Covey [mailto:[e-mail]]
  Sent: Wednesday, May 09, 2001 11:28 AM
  To: [e-mail]; David A. Cooper; [e-mail];
  [e-mail]
  Cc: [e-mail]
  Subject: RE: delta CRLs



  David, Stephen, Ambarish, and Santosh,

  Some of us are in the business for the looooong haul.  ;>)

  Actually, I wasn't concerned about the CRL number wrapping, but that
  possibility was advanced a few days ago as an argument against the use of
  the "strictly increasing" wording.  Another email commented that PKIX did
  not permit the number to wrap, although X.509 might.  The only evidence I
  could find for X.509 permitting the number to wrap was "(0 .. MAX)".  As
  various people have pointed out, one could be drumming one's fingers for
  quite a while........

  My real point was that the "monotonically increasing" wording permits the
  CRL number to stay the same, while "strictly increasing" forces the
numbers
  to be unique (issues of wrapping aside in both cases).  Stephen Henson
just
  pointed out a reason why one might want the CRL number to stay the same
when
  issuing a delta CRL at the same time as a full CRL.  I am not arguing
either
  for or against that case, but it seems desirable to force the CRL numbers
to
  be unique in most cases.  (Unless, the CRLs are distinguished based upon
  thisUpdate, as Santosh has suggested.)

  Regards,

  Carlin

  ____________________________

  -  Carlin Covey
     Cylink Corporation




  -----Original Message-----
  From: David A. Cooper [mailto:[e-mail]]
  Sent: Wednesday, May 09, 2001 6:03 AM
  To: '[e-mail] '
  Subject: RE: delta CRLs



   From a practical point of view, I don't think that we should need to
worry
  about CRL numbers wrapping.  According to my calculations, if one assigns
  cRLNumber 1 to the first CRL and then numbers CRLs consecutively, one
could
  issue a new CRL every second for 68 years before the cRLNumber would
require
  more than 4 bytes (32 bits) to encode.  On the other hand, if you're
willing
  to issue a new CRL only once a minute, it would take 4083 years before the
  cRLNumber would require more than 4 bytes to encode.

  BTW, I thought that the purpose of the "(0 .. MAX)" was just to prevent
use
  of negative numbers. While there may, in theory be a limit to the size of
an
  integer that may be encoded, for all practical purposes, one can encode
any
  integet. According to "A Layman's Guide to a Subset of ASN.1, BER, and
DER",
  a DER encoded value can have a length of up to 2 ** 1008 - 1 bytes. Thus,
  MAX = 2 ** [8 * ((2 ** 1008) - 1) - 1] - 1, which is far larger than any
  number we would ever need.

  Dave

  At 08:57 PM 5/8/01 -0700, Ambarish Malpani wrote:
  >
  >I always thought MAX for ASN.1 INTEGERs was something I would never
  >need to worry about.
  >
  >Looks like I was wrong :-)
  >
  >By the way, what is MAX? I know that we can represent numbers with
  >over 2048 bits...
  >
  >A
  >
  >-----Original Message-----
  >From: Carlin Covey
  >To: Housley, Russ; Santosh Chokhani
  >Cc: [e-mail]
  >Sent: 5/8/01 5:53 PM
  >Subject: RE: delta CRLs
  >
  >Russ,
  >
  >A week or two ago we arrived at a consensus to remove the requirement
  >that a CA issue a full CRL whenever the CA issues a Delta-CRL.  If the
  >CA chooses to issue them simultaneously, why would they need to be
numbered
  >the same?  If this requirement were lifted, it seems like requiring the
CRL
  >number to be "strictly increasing" in a sequence would be preferable to
  >"monotonically increasing".  "Monotonically increasing" allows the
  possibility
  >that the CRL number never changes, which seems undesirable.  I realize
  >that in either case the CRL number might wrap around at some point in the
  future.
  >That is inevitable, given that that CRL number is defined as INTEGER
  (0..MAX).
  >What else can a CA do when CRL number reaches MAX, stop issuing CRLs?
  >
  >"monotonically increasing" - Definition: A function from a partially
  order[ed]
  >domain to a partially ordered range such that x >= y implies f(x) >=
f(y).
  >
  >- From the NIST web site:
  >http://hissa.nist.gov/dads/HTML/monotoncincr.html
  >
  >Regards,
  >
  >Carlin
  >
  >____________________________
  >
  >-  Carlin Covey
  >    Cylink Corporation
  >
  >-----Original Message-----
  >From: Housley, Russ [mailto:[e-mail]]
  >Sent: Monday, May 07, 2001 6:21 AM
  >To: Santosh Chokhani
  >Cc: [e-mail]
  >Subject: RE: delta CRLs
  >
  >
  >Santosh:
  >
  >X.509 may allow the CRL number to wrap around, but I do not believe that
  >PKIX does.
  >
  >     5.2.3  CRL Number
  >
  >     The CRL number is a non-critical CRL extension which conveys a
  >     monotonically increasing sequence number for each CRL issued by a
CA.
  >     This extension allows users to easily determine when a particular
CRL
  >     supersedes another CRL.  CAs conforming to this profile MUST include
  >     this extension in all CRLs.
  >
  >     id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }
  >
  >Russ
  >
  >
  >At 10:11 PM 5/5/2001 -0400, Santosh Chokhani wrote:
  >
  > >Actually, the text allows for the wrap of the numbers.  Please see
Annex
  B
  > >of X.509.  Thus, it is not strictly increasing
  > >
  > >-----Original Message-----
  > >From: Peter Sylvester
  > >[<mailto:[e-mail]>mailto:[e-mail]]
  > >Sent: Saturday, May 05, 2001 2:08 PM
  > >To: [e-mail]; [e-mail];
  > >[e-mail]
  > >Cc: [e-mail]
  > >Subject: RE: delta CRLs
  > >
  > > > Trevor:
  > > >
  > > > The 2000 version of X.509 is very clear on this.  For a given CRL
  stream
  > > > identifier, the CRL number is unique whether it is base or delta.
That
  is
  > > > why delta number has to be greater than the base.
  > >
  > >" 8.5.2.1 CRL number extension
  > >
  > >   This CRL extension field conveys a monotonically increasing sequence
  > > number .."
  > >
  > >The text might be clearer IMHO if 'strictly increasing' would be used
  > >instead.


------=_NextPart_000_0054_01C0D871.0608D4C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: delta CRLs</TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D523265216-09052001>Santosh,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D523265216-09052001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D523265216-09052001>If=20
simultaneously-issued delta-CRLs and full CRLs are to be numbered the =
same, I=20
think your wording is a significant improvement over the current =
wording.&nbsp;=20
However, I'm still undecided whether they should be numbered the =
same.&nbsp; It=20
seems like simultaneously-issued delta-CRLs and full CRLs (and =
constructed CRLs)=20
could be matched via the thisUpdate field without the necessity of =
violating the=20
strictly increasing provision for CRL numbers.&nbsp; A unique reference =
for each=20
CRL would be useful for evidentiary purposes, and for historical=20
validation.&nbsp;&nbsp;Rendering a CRL identifier unique already =
requires the=20
issuer ID, the set of reason&nbsp;codes, the set of certificate types, =
and=20
either the CRL number or the thisUpdate value.&nbsp; I wonder if it is =
necessary=20
to add the full vs. delta status as well.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D523265216-09052001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D523265216-09052001>-=20
Carlin</SPAN></FONT></DIV>
<DIV><SPAN class=3D523265216-09052001></SPAN><FONT face=3DTahoma><FONT =
size=3D2><SPAN=20
class=3D523265216-09052001><FONT color=3D#0000ff=20
face=3DArial>&nbsp;</FONT></SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DTahoma><FONT size=3D2><SPAN=20
class=3D523265216-09052001>&nbsp;</SPAN>-----Original =
Message-----<BR><B>From:</B>=20
Santosh Chokhani [mailto:[e-mail]]<BR><B>Sent:</B> =
Wednesday, May=20
09, 2001 9:28 AM<BR><B>To:</B> Carlin Covey; [e-mail]; David A. =
Cooper;=20
[e-mail]; Santosh Chokhani<BR><B>Cc:</B>=20
[e-mail]<BR><B>Subject:</B> RE: delta CRLs<BR><BR></DIV></FONT>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px"></FONT>
  <P><FONT size=3D2>I am simply suggesting that the numbers be strictly=20
  increasing, but if a base and delta are generated at the same time, =
they will=20
  have the same sequence number.&nbsp; Thus, if two CRLs (in the same =
stream=20
  identifier or when stream identifier is absent), have numbers n and m, =
the=20
  following shall be true (assuming no wrapping)</FONT></P>
  <P><FONT size=3D2>&nbsp;n =3D m if and only if thisUpdate of n =3D =
thisUpdate of=20
  m</FONT> </P>
  <P><FONT size=3D2>&nbsp;n &gt; m if and only if thisUpdate of n &gt; =
thisUpdate=20
  of m</FONT> </P>
  <P><FONT size=3D2>&nbsp;n &lt; m if and only if thisUpdate of n &lt; =
thisUpdate=20
  of m</FONT> </P>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From:=20
  Carlin Covey [<A=20
  href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> =
<BR><FONT=20
  size=3D2>Sent: Wednesday, May 09, 2001 11:28 AM</FONT> <BR><FONT =
size=3D2>To:=20
  [e-mail]; David A. Cooper; [e-mail];</FONT> =
<BR><FONT=20
  size=3D2>[e-mail]</FONT> <BR><FONT size=3D2>Cc:=20
  [e-mail]</FONT> <BR><FONT size=3D2>Subject: RE: delta =
CRLs</FONT>=20
  </P><BR>
  <P><FONT size=3D2>David, Stephen, Ambarish, and Santosh,</FONT> </P>
  <P><FONT size=3D2>Some of us are in the business for the looooong =
haul.&nbsp;=20
  ;&gt;)</FONT> </P>
  <P><FONT size=3D2>Actually, I wasn't concerned about the CRL number =
wrapping,=20
  but that</FONT> <BR><FONT size=3D2>possibility was advanced a few days =
ago as an=20
  argument against the use of</FONT> <BR><FONT size=3D2>the "strictly =
increasing"=20
  wording.&nbsp; Another email commented that PKIX did</FONT> <BR><FONT=20
  size=3D2>not permit the number to wrap, although X.509 might.&nbsp; =
The only=20
  evidence I</FONT> <BR><FONT size=3D2>could find for X.509 permitting =
the number=20
  to wrap was "(0 .. MAX)".&nbsp; As</FONT> <BR><FONT size=3D2>various =
people have=20
  pointed out, one could be drumming one's fingers for</FONT> <BR><FONT=20
  size=3D2>quite a while........</FONT> </P>
  <P><FONT size=3D2>My real point was that the "monotonically =
increasing" wording=20
  permits the</FONT> <BR><FONT size=3D2>CRL number to stay the same, =
while=20
  "strictly increasing" forces the numbers</FONT> <BR><FONT size=3D2>to =
be unique=20
  (issues of wrapping aside in both cases).&nbsp; Stephen Henson =
just</FONT>=20
  <BR><FONT size=3D2>pointed out a reason why one might want the CRL =
number to=20
  stay the same when</FONT> <BR><FONT size=3D2>issuing a delta CRL at =
the same=20
  time as a full CRL.&nbsp; I am not arguing either</FONT> <BR><FONT =
size=3D2>for=20
  or against that case, but it seems desirable to force the CRL numbers=20
  to</FONT> <BR><FONT size=3D2>be unique in most cases.&nbsp; (Unless, =
the CRLs=20
  are distinguished based upon</FONT> <BR><FONT size=3D2>thisUpdate, as =
Santosh=20
  has suggested.)</FONT> </P>
  <P><FONT size=3D2>Regards,</FONT> </P>
  <P><FONT size=3D2>Carlin</FONT> </P>
  <P><FONT size=3D2>____________________________</FONT> </P>
  <P><FONT size=3D2>-&nbsp; Carlin Covey</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp;=20
  Cylink Corporation</FONT> </P><BR><BR>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From: David=20
  A. Cooper [<A=20
  =
href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</=
FONT>=20
  <BR><FONT size=3D2>Sent: Wednesday, May 09, 2001 6:03 AM</FONT> =
<BR><FONT=20
  size=3D2>To: '[e-mail] '</FONT> <BR><FONT size=3D2>Subject: =
RE: delta=20
  CRLs</FONT> </P><BR>
  <P><FONT size=3D2>&nbsp;From a practical point of view, I don't think =
that we=20
  should need to worry</FONT> <BR><FONT size=3D2>about CRL numbers =
wrapping.&nbsp;=20
  According to my calculations, if one assigns</FONT> <BR><FONT =
size=3D2>cRLNumber=20
  1 to the first CRL and then numbers CRLs consecutively, one =
could</FONT>=20
  <BR><FONT size=3D2>issue a new CRL every second for 68 years before =
the=20
  cRLNumber would require</FONT> <BR><FONT size=3D2>more than 4 bytes =
(32 bits) to=20
  encode.&nbsp; On the other hand, if you're willing</FONT> <BR><FONT =
size=3D2>to=20
  issue a new CRL only once a minute, it would take 4083 years before =
the</FONT>=20
  <BR><FONT size=3D2>cRLNumber would require more than 4 bytes to =
encode.</FONT>=20
  </P>
  <P><FONT size=3D2>BTW, I thought that the purpose of the "(0 .. MAX)" =
was just=20
  to prevent use</FONT> <BR><FONT size=3D2>of negative numbers. While =
there may,=20
  in theory be a limit to the size of an</FONT> <BR><FONT =
size=3D2>integer that=20
  may be encoded, for all practical purposes, one can encode any</FONT>=20
  <BR><FONT size=3D2>integet. According to "A Layman's Guide to a Subset =
of ASN.1,=20
  BER, and DER",</FONT> <BR><FONT size=3D2>a DER encoded value can have =
a length=20
  of up to 2 ** 1008 - 1 bytes. Thus,</FONT> <BR><FONT size=3D2>MAX =3D =
2 ** [8 *=20
  ((2 ** 1008) - 1) - 1] - 1, which is far larger than any</FONT> =
<BR><FONT=20
  size=3D2>number we would ever need.</FONT> </P>
  <P><FONT size=3D2>Dave</FONT> </P>
  <P><FONT size=3D2>At 08:57 PM 5/8/01 -0700, Ambarish Malpani =
wrote:</FONT>=20
  <BR><FONT size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;I always thought =
MAX for=20
  ASN.1 INTEGERs was something I would never</FONT> <BR><FONT =
size=3D2>&gt;need to=20
  worry about.</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =
size=3D2>&gt;Looks=20
  like I was wrong :-)</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT=20
  size=3D2>&gt;By the way, what is MAX? I know that we can represent =
numbers=20
  with</FONT> <BR><FONT size=3D2>&gt;over 2048 bits...</FONT> <BR><FONT=20
  size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;A</FONT> <BR><FONT =
size=3D2>&gt;</FONT>=20
  <BR><FONT size=3D2>&gt;-----Original Message-----</FONT> <BR><FONT=20
  size=3D2>&gt;From: Carlin Covey</FONT> <BR><FONT size=3D2>&gt;To: =
Housley, Russ;=20
  Santosh Chokhani</FONT> <BR><FONT size=3D2>&gt;Cc: =
[e-mail]</FONT>=20
  <BR><FONT size=3D2>&gt;Sent: 5/8/01 5:53 PM</FONT> <BR><FONT =
size=3D2>&gt;Subject:=20
  RE: delta CRLs</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT=20
  size=3D2>&gt;Russ,</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =
size=3D2>&gt;A=20
  week or two ago we arrived at a consensus to remove the =
requirement</FONT>=20
  <BR><FONT size=3D2>&gt;that a CA issue a full CRL whenever the CA =
issues a=20
  Delta-CRL.&nbsp; If the</FONT> <BR><FONT size=3D2>&gt;CA chooses to =
issue them=20
  simultaneously, why would they need to be numbered</FONT> <BR><FONT=20
  size=3D2>&gt;the same?&nbsp; If this requirement were lifted, it seems =
like=20
  requiring the CRL</FONT> <BR><FONT size=3D2>&gt;number to be "strictly =

  increasing" in a sequence would be preferable to</FONT> <BR><FONT=20
  size=3D2>&gt;"monotonically increasing".&nbsp; "Monotonically =
increasing" allows=20
  the</FONT> <BR><FONT size=3D2>possibility</FONT> <BR><FONT =
size=3D2>&gt;that the=20
  CRL number never changes, which seems undesirable.&nbsp; I =
realize</FONT>=20
  <BR><FONT size=3D2>&gt;that in either case the CRL number might wrap =
around at=20
  some point in the</FONT> <BR><FONT size=3D2>future.</FONT> <BR><FONT=20
  size=3D2>&gt;That is inevitable, given that that CRL number is defined =
as=20
  INTEGER</FONT> <BR><FONT size=3D2>(0..MAX).</FONT> <BR><FONT =
size=3D2>&gt;What=20
  else can a CA do when CRL number reaches MAX, stop issuing =
CRLs?</FONT>=20
  <BR><FONT size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;"monotonically =
increasing" -=20
  Definition: A function from a partially</FONT> <BR><FONT=20
  size=3D2>order[ed]</FONT> <BR><FONT size=3D2>&gt;domain to a partially =
ordered=20
  range such that x &gt;=3D y implies f(x) &gt;=3D f(y).</FONT> =
<BR><FONT=20
  size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;- From the NIST web =
site:</FONT>=20
  <BR><FONT size=3D2>&gt;<A=20
  href=3D"http://hissa.nist.gov/dads/HTML/monotoncincr.html"=20
  =
target=3D_blank>http://hissa.nist.gov/dads/HTML/monotoncincr.html</A></FO=
NT>=20
  <BR><FONT size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;Regards,</FONT> =
<BR><FONT=20
  size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;Carlin</FONT> <BR><FONT=20
  size=3D2>&gt;</FONT> <BR><FONT =
size=3D2>&gt;____________________________</FONT>=20
  <BR><FONT size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;-&nbsp; Carlin =
Covey</FONT>=20
  <BR><FONT size=3D2>&gt;&nbsp;&nbsp;&nbsp; Cylink Corporation</FONT> =
<BR><FONT=20
  size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;-----Original =
Message-----</FONT>=20
  <BR><FONT size=3D2>&gt;From: Housley, Russ [<A=20
  =
href=3D"mailto:[e-mail]">mailto:[e-mail]<=
/A>]</FONT>=20
  <BR><FONT size=3D2>&gt;Sent: Monday, May 07, 2001 6:21 AM</FONT> =
<BR><FONT=20
  size=3D2>&gt;To: Santosh Chokhani</FONT> <BR><FONT size=3D2>&gt;Cc:=20
  [e-mail]</FONT> <BR><FONT size=3D2>&gt;Subject: RE: delta =
CRLs</FONT>=20
  <BR><FONT size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;</FONT> =
<BR><FONT=20
  size=3D2>&gt;Santosh:</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT=20
  size=3D2>&gt;X.509 may allow the CRL number to wrap around, but I do =
not believe=20
  that</FONT> <BR><FONT size=3D2>&gt;PKIX does.</FONT> <BR><FONT=20
  size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; =
5.2.3&nbsp;=20
  CRL Number</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; The CRL number is a non-critical =
CRL=20
  extension which conveys a</FONT> <BR><FONT =
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;=20
  monotonically increasing sequence number for each CRL issued by a =
CA.</FONT>=20
  <BR><FONT size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; This extension allows =
users to=20
  easily determine when a particular CRL</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; supersedes another CRL.&nbsp; =
CAs=20
  conforming to this profile MUST include</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; this extension in all =
CRLs.</FONT>=20
  <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;=20
  id-ce-cRLNumber OBJECT IDENTIFIER ::=3D { id-ce 20 }</FONT> <BR><FONT=20
  size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;Russ</FONT> <BR><FONT=20
  size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =
size=3D2>&gt;At 10:11=20
  PM 5/5/2001 -0400, Santosh Chokhani wrote:</FONT> <BR><FONT =
size=3D2>&gt;</FONT>=20
  <BR><FONT size=3D2>&gt; &gt;Actually, the text allows for the wrap of =
the=20
  numbers.&nbsp; Please see Annex</FONT> <BR><FONT size=3D2>B</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;of X.509.&nbsp; Thus, it is not strictly =
increasing</FONT>=20
  <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt;-----Original=20
  Message-----</FONT> <BR><FONT size=3D2>&gt; &gt;From: Peter =
Sylvester</FONT>=20
  <BR><FONT size=3D2>&gt; &gt;[&lt;<A=20
  =
href=3D"mailto:[e-mail]">mailto:Peter.Sylvester@EdelWeb=
.fr</A>&gt;<A=20
  =
href=3D"mailto:[e-mail]">mailto:Peter.Sylvester@EdelWeb=
.fr</A>]</FONT>=20
  <BR><FONT size=3D2>&gt; &gt;Sent: Saturday, May 05, 2001 2:08 =
PM</FONT>=20
  <BR><FONT size=3D2>&gt; &gt;To: [e-mail];=20
  [e-mail];</FONT> <BR><FONT size=3D2>&gt;=20
  &gt;[e-mail]</FONT> <BR><FONT size=3D2>&gt; &gt;Cc:=20
  [e-mail]</FONT> <BR><FONT size=3D2>&gt; &gt;Subject: RE: =
delta=20
  CRLs</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT =
size=3D2>&gt; &gt; &gt;=20
  Trevor:</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; &gt; The 2000 version of X.509 is very clear on this.&nbsp; For a =
given=20
  CRL</FONT> <BR><FONT size=3D2>stream</FONT> <BR><FONT size=3D2>&gt; =
&gt; &gt;=20
  identifier, the CRL number is unique whether it is base or delta. =
That</FONT>=20
  <BR><FONT size=3D2>is</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; why =
delta number=20
  has to be greater than the base.</FONT> <BR><FONT size=3D2>&gt; =
&gt;</FONT>=20
  <BR><FONT size=3D2>&gt; &gt;" 8.5.2.1 CRL number extension</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp;&nbsp; =
This CRL=20
  extension field conveys a monotonically increasing sequence</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; number .."</FONT> <BR><FONT size=3D2>&gt; =
&gt;</FONT> <BR><FONT=20
  size=3D2>&gt; &gt;The text might be clearer IMHO if 'strictly =
increasing' would=20
  be used</FONT> <BR><FONT size=3D2>&gt; &gt;instead.</FONT>=20
</P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0054_01C0D871.0608D4C0--



Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA02323 for <[e-mail]>; Wed, 9 May 2001 10:07:16 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id FAA08266; Thu, 10 May 2001 05:07:13 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <98942803230088>; Thu, 10 May 2001 05:07:12 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: RE: delta CRLs
Cc: [e-mail]
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Thu, 10 May 2001 05:07:12 (NZST)
Message-ID: <[e-mail]>

Ambarish Malpani <[e-mail]> writes:

>By the way, what is MAX? I know that we can represent numbers with over 2048
>bits...

MAX is a symbolic, externally-specified value usually used to go with "(0..."
(one or more) or "(1..." (1 or more, or minimum length 1).

Peter.




Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA00362 for <[e-mail]>; Wed, 9 May 2001 09:37:38 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <KS8ZMLHF>; Wed, 9 May 2001 12:37:08 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Carlin Covey <[e-mail]>, [e-mail], "David A. Cooper" <[e-mail]>, [e-mail], Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Subject: RE: delta CRLs
Date: Wed, 9 May 2001 12:27:55 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D8A5.0094F760"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D8A5.0094F760
Content-Type: text/plain;
	charset="iso-8859-1"

I am simply suggesting that the numbers be strictly increasing, but if a
base and delta are generated at the same time, they will have the same
sequence number.  Thus, if two CRLs (in the same stream identifier or when
stream identifier is absent), have numbers n and m, the following shall be
true (assuming no wrapping)

 n = m if and only if thisUpdate of n = thisUpdate of m

 n > m if and only if thisUpdate of n > thisUpdate of m

 n < m if and only if thisUpdate of n < thisUpdate of m

-----Original Message-----
From: Carlin Covey [mailto:[e-mail]]
Sent: Wednesday, May 09, 2001 11:28 AM
To: [e-mail]; David A. Cooper; [e-mail];
[e-mail]
Cc: [e-mail]
Subject: RE: delta CRLs


David, Stephen, Ambarish, and Santosh,

Some of us are in the business for the looooong haul.  ;>)

Actually, I wasn't concerned about the CRL number wrapping, but that
possibility was advanced a few days ago as an argument against the use of
the "strictly increasing" wording.  Another email commented that PKIX did
not permit the number to wrap, although X.509 might.  The only evidence I
could find for X.509 permitting the number to wrap was "(0 .. MAX)".  As
various people have pointed out, one could be drumming one's fingers for
quite a while........

My real point was that the "monotonically increasing" wording permits the
CRL number to stay the same, while "strictly increasing" forces the numbers
to be unique (issues of wrapping aside in both cases).  Stephen Henson just
pointed out a reason why one might want the CRL number to stay the same when
issuing a delta CRL at the same time as a full CRL.  I am not arguing either
for or against that case, but it seems desirable to force the CRL numbers to
be unique in most cases.  (Unless, the CRLs are distinguished based upon
thisUpdate, as Santosh has suggested.)

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation



-----Original Message-----
From: David A. Cooper [mailto:[e-mail]]
Sent: Wednesday, May 09, 2001 6:03 AM
To: '[e-mail] '
Subject: RE: delta CRLs


 From a practical point of view, I don't think that we should need to worry
about CRL numbers wrapping.  According to my calculations, if one assigns
cRLNumber 1 to the first CRL and then numbers CRLs consecutively, one could
issue a new CRL every second for 68 years before the cRLNumber would require
more than 4 bytes (32 bits) to encode.  On the other hand, if you're willing
to issue a new CRL only once a minute, it would take 4083 years before the
cRLNumber would require more than 4 bytes to encode.

BTW, I thought that the purpose of the "(0 .. MAX)" was just to prevent use
of negative numbers. While there may, in theory be a limit to the size of an
integer that may be encoded, for all practical purposes, one can encode any
integet. According to "A Layman's Guide to a Subset of ASN.1, BER, and DER",
a DER encoded value can have a length of up to 2 ** 1008 - 1 bytes. Thus,
MAX = 2 ** [8 * ((2 ** 1008) - 1) - 1] - 1, which is far larger than any
number we would ever need.

Dave

At 08:57 PM 5/8/01 -0700, Ambarish Malpani wrote:
>
>I always thought MAX for ASN.1 INTEGERs was something I would never
>need to worry about.
>
>Looks like I was wrong :-)
>
>By the way, what is MAX? I know that we can represent numbers with
>over 2048 bits...
>
>A
>
>-----Original Message-----
>From: Carlin Covey
>To: Housley, Russ; Santosh Chokhani
>Cc: [e-mail]
>Sent: 5/8/01 5:53 PM
>Subject: RE: delta CRLs
>
>Russ,
>
>A week or two ago we arrived at a consensus to remove the requirement
>that a CA issue a full CRL whenever the CA issues a Delta-CRL.  If the
>CA chooses to issue them simultaneously, why would they need to be numbered
>the same?  If this requirement were lifted, it seems like requiring the CRL
>number to be "strictly increasing" in a sequence would be preferable to
>"monotonically increasing".  "Monotonically increasing" allows the
possibility
>that the CRL number never changes, which seems undesirable.  I realize
>that in either case the CRL number might wrap around at some point in the
future.
>That is inevitable, given that that CRL number is defined as INTEGER
(0..MAX).
>What else can a CA do when CRL number reaches MAX, stop issuing CRLs?
>
>"monotonically increasing" - Definition: A function from a partially
order[ed]
>domain to a partially ordered range such that x >= y implies f(x) >= f(y).
>
>- From the NIST web site:
>http://hissa.nist.gov/dads/HTML/monotoncincr.html
>
>Regards,
>
>Carlin
>
>____________________________
>
>-  Carlin Covey
>    Cylink Corporation
>
>-----Original Message-----
>From: Housley, Russ [mailto:[e-mail]]
>Sent: Monday, May 07, 2001 6:21 AM
>To: Santosh Chokhani
>Cc: [e-mail]
>Subject: RE: delta CRLs
>
>
>Santosh:
>
>X.509 may allow the CRL number to wrap around, but I do not believe that
>PKIX does.
>
>     5.2.3  CRL Number
>
>     The CRL number is a non-critical CRL extension which conveys a
>     monotonically increasing sequence number for each CRL issued by a CA.
>     This extension allows users to easily determine when a particular CRL
>     supersedes another CRL.  CAs conforming to this profile MUST include
>     this extension in all CRLs.
>
>     id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }
>
>Russ
>
>
>At 10:11 PM 5/5/2001 -0400, Santosh Chokhani wrote:
>
> >Actually, the text allows for the wrap of the numbers.  Please see Annex
B
> >of X.509.  Thus, it is not strictly increasing
> >
> >-----Original Message-----
> >From: Peter Sylvester
> >[<mailto:[e-mail]>mailto:[e-mail]]
> >Sent: Saturday, May 05, 2001 2:08 PM
> >To: [e-mail]; [e-mail];
> >[e-mail]
> >Cc: [e-mail]
> >Subject: RE: delta CRLs
> >
> > > Trevor:
> > >
> > > The 2000 version of X.509 is very clear on this.  For a given CRL
stream
> > > identifier, the CRL number is unique whether it is base or delta. That
is
> > > why delta number has to be greater than the base.
> >
> >" 8.5.2.1 CRL number extension
> >
> >   This CRL extension field conveys a monotonically increasing sequence
> > number .."
> >
> >The text might be clearer IMHO if 'strictly increasing' would be used
> >instead.


------_=_NextPart_001_01C0D8A5.0094F760
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: delta CRLs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I am simply suggesting that the numbers be strictly =
increasing, but if a base and delta are generated at the same time, =
they will have the same sequence number.&nbsp; Thus, if two CRLs (in =
the same stream identifier or when stream identifier is absent), have =
numbers n and m, the following shall be true (assuming no =
wrapping)</FONT></P>

<P><FONT SIZE=3D2>&nbsp;n =3D m if and only if thisUpdate of n =3D =
thisUpdate of m</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;n &gt; m if and only if thisUpdate of n &gt; =
thisUpdate of m</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;n &lt; m if and only if thisUpdate of n &lt; =
thisUpdate of m</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Carlin Covey [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, May 09, 2001 11:28 AM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]; David A. Cooper; =
[e-mail];</FONT>
<BR><FONT SIZE=3D2>[e-mail]</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: delta CRLs</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>David, Stephen, Ambarish, and Santosh,</FONT>
</P>

<P><FONT SIZE=3D2>Some of us are in the business for the looooong =
haul.&nbsp; ;&gt;)</FONT>
</P>

<P><FONT SIZE=3D2>Actually, I wasn't concerned about the CRL number =
wrapping, but that</FONT>
<BR><FONT SIZE=3D2>possibility was advanced a few days ago as an =
argument against the use of</FONT>
<BR><FONT SIZE=3D2>the &quot;strictly increasing&quot; wording.&nbsp; =
Another email commented that PKIX did</FONT>
<BR><FONT SIZE=3D2>not permit the number to wrap, although X.509 =
might.&nbsp; The only evidence I</FONT>
<BR><FONT SIZE=3D2>could find for X.509 permitting the number to wrap =
was &quot;(0 .. MAX)&quot;.&nbsp; As</FONT>
<BR><FONT SIZE=3D2>various people have pointed out, one could be =
drumming one's fingers for</FONT>
<BR><FONT SIZE=3D2>quite a while........</FONT>
</P>

<P><FONT SIZE=3D2>My real point was that the &quot;monotonically =
increasing&quot; wording permits the</FONT>
<BR><FONT SIZE=3D2>CRL number to stay the same, while &quot;strictly =
increasing&quot; forces the numbers</FONT>
<BR><FONT SIZE=3D2>to be unique (issues of wrapping aside in both =
cases).&nbsp; Stephen Henson just</FONT>
<BR><FONT SIZE=3D2>pointed out a reason why one might want the CRL =
number to stay the same when</FONT>
<BR><FONT SIZE=3D2>issuing a delta CRL at the same time as a full =
CRL.&nbsp; I am not arguing either</FONT>
<BR><FONT SIZE=3D2>for or against that case, but it seems desirable to =
force the CRL numbers to</FONT>
<BR><FONT SIZE=3D2>be unique in most cases.&nbsp; (Unless, the CRLs are =
distinguished based upon</FONT>
<BR><FONT SIZE=3D2>thisUpdate, as Santosh has suggested.)</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Carlin</FONT>
</P>

<P><FONT SIZE=3D2>____________________________</FONT>
</P>

<P><FONT SIZE=3D2>-&nbsp; Carlin Covey</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; Cylink Corporation</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: David A. Cooper [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, May 09, 2001 6:03 AM</FONT>
<BR><FONT SIZE=3D2>To: '[e-mail] '</FONT>
<BR><FONT SIZE=3D2>Subject: RE: delta CRLs</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&nbsp;From a practical point of view, I don't think =
that we should need to worry</FONT>
<BR><FONT SIZE=3D2>about CRL numbers wrapping.&nbsp; According to my =
calculations, if one assigns</FONT>
<BR><FONT SIZE=3D2>cRLNumber 1 to the first CRL and then numbers CRLs =
consecutively, one could</FONT>
<BR><FONT SIZE=3D2>issue a new CRL every second for 68 years before the =
cRLNumber would require</FONT>
<BR><FONT SIZE=3D2>more than 4 bytes (32 bits) to encode.&nbsp; On the =
other hand, if you're willing</FONT>
<BR><FONT SIZE=3D2>to issue a new CRL only once a minute, it would take =
4083 years before the</FONT>
<BR><FONT SIZE=3D2>cRLNumber would require more than 4 bytes to =
encode.</FONT>
</P>

<P><FONT SIZE=3D2>BTW, I thought that the purpose of the &quot;(0 .. =
MAX)&quot; was just to prevent use</FONT>
<BR><FONT SIZE=3D2>of negative numbers. While there may, in theory be a =
limit to the size of an</FONT>
<BR><FONT SIZE=3D2>integer that may be encoded, for all practical =
purposes, one can encode any</FONT>
<BR><FONT SIZE=3D2>integet. According to &quot;A Layman's Guide to a =
Subset of ASN.1, BER, and DER&quot;,</FONT>
<BR><FONT SIZE=3D2>a DER encoded value can have a length of up to 2 ** =
1008 - 1 bytes. Thus,</FONT>
<BR><FONT SIZE=3D2>MAX =3D 2 ** [8 * ((2 ** 1008) - 1) - 1] - 1, which =
is far larger than any</FONT>
<BR><FONT SIZE=3D2>number we would ever need.</FONT>
</P>

<P><FONT SIZE=3D2>Dave</FONT>
</P>

<P><FONT SIZE=3D2>At 08:57 PM 5/8/01 -0700, Ambarish Malpani =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;I always thought MAX for ASN.1 INTEGERs was =
something I would never</FONT>
<BR><FONT SIZE=3D2>&gt;need to worry about.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Looks like I was wrong :-)</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;By the way, what is MAX? I know that we can =
represent numbers with</FONT>
<BR><FONT SIZE=3D2>&gt;over 2048 bits...</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;A</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;From: Carlin Covey</FONT>
<BR><FONT SIZE=3D2>&gt;To: Housley, Russ; Santosh Chokhani</FONT>
<BR><FONT SIZE=3D2>&gt;Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt;Sent: 5/8/01 5:53 PM</FONT>
<BR><FONT SIZE=3D2>&gt;Subject: RE: delta CRLs</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Russ,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;A week or two ago we arrived at a consensus to =
remove the requirement</FONT>
<BR><FONT SIZE=3D2>&gt;that a CA issue a full CRL whenever the CA =
issues a Delta-CRL.&nbsp; If the</FONT>
<BR><FONT SIZE=3D2>&gt;CA chooses to issue them simultaneously, why =
would they need to be numbered</FONT>
<BR><FONT SIZE=3D2>&gt;the same?&nbsp; If this requirement were lifted, =
it seems like requiring the CRL</FONT>
<BR><FONT SIZE=3D2>&gt;number to be &quot;strictly increasing&quot; in =
a sequence would be preferable to</FONT>
<BR><FONT SIZE=3D2>&gt;&quot;monotonically increasing&quot;.&nbsp; =
&quot;Monotonically increasing&quot; allows the</FONT>
<BR><FONT SIZE=3D2>possibility</FONT>
<BR><FONT SIZE=3D2>&gt;that the CRL number never changes, which seems =
undesirable.&nbsp; I realize</FONT>
<BR><FONT SIZE=3D2>&gt;that in either case the CRL number might wrap =
around at some point in the</FONT>
<BR><FONT SIZE=3D2>future.</FONT>
<BR><FONT SIZE=3D2>&gt;That is inevitable, given that that CRL number =
is defined as INTEGER</FONT>
<BR><FONT SIZE=3D2>(0..MAX).</FONT>
<BR><FONT SIZE=3D2>&gt;What else can a CA do when CRL number reaches =
MAX, stop issuing CRLs?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&quot;monotonically increasing&quot; - =
Definition: A function from a partially</FONT>
<BR><FONT SIZE=3D2>order[ed]</FONT>
<BR><FONT SIZE=3D2>&gt;domain to a partially ordered range such that x =
&gt;=3D y implies f(x) &gt;=3D f(y).</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;- From the NIST web site:</FONT>
<BR><FONT SIZE=3D2>&gt;<A =
HREF=3D"http://hissa.nist.gov/dads/HTML/monotoncincr.html" =
TARGET=3D"_blank">http://hissa.nist.gov/dads/HTML/monotoncincr.html</A><=
/FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Regards,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Carlin</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;____________________________</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;-&nbsp; Carlin Covey</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; Cylink Corporation</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;From: Housley, Russ [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>]</FONT>
<BR><FONT SIZE=3D2>&gt;Sent: Monday, May 07, 2001 6:21 AM</FONT>
<BR><FONT SIZE=3D2>&gt;To: Santosh Chokhani</FONT>
<BR><FONT SIZE=3D2>&gt;Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt;Subject: RE: delta CRLs</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Santosh:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;X.509 may allow the CRL number to wrap around, =
but I do not believe that</FONT>
<BR><FONT SIZE=3D2>&gt;PKIX does.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; 5.2.3&nbsp; CRL =
Number</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; The CRL number is a =
non-critical CRL extension which conveys a</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; monotonically =
increasing sequence number for each CRL issued by a CA.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; This extension allows =
users to easily determine when a particular CRL</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; supersedes another =
CRL.&nbsp; CAs conforming to this profile MUST include</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; this extension in all =
CRLs.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; id-ce-cRLNumber OBJECT =
IDENTIFIER ::=3D { id-ce 20 }</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Russ</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;At 10:11 PM 5/5/2001 -0400, Santosh Chokhani =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Actually, the text allows for the wrap of =
the numbers.&nbsp; Please see Annex</FONT>
<BR><FONT SIZE=3D2>B</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;of X.509.&nbsp; Thus, it is not strictly =
increasing</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;From: Peter Sylvester</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;[&lt;<A =
HREF=3D"mailto:[e-mail]">mailto:Peter.Sylvester@EdelWe=
b.fr</A>&gt;<A =
HREF=3D"mailto:[e-mail]">mailto:Peter.Sylvester@EdelWe=
b.fr</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Sent: Saturday, May 05, 2001 2:08 PM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;To: [e-mail]; =
[e-mail];</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;[e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Subject: RE: delta CRLs</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Trevor:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; The 2000 version of X.509 is very =
clear on this.&nbsp; For a given CRL</FONT>
<BR><FONT SIZE=3D2>stream</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; identifier, the CRL number is unique =
whether it is base or delta. That</FONT>
<BR><FONT SIZE=3D2>is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; why delta number has to be greater =
than the base.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&quot; 8.5.2.1 CRL number extension</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; This CRL extension field =
conveys a monotonically increasing sequence</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; number ..&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;The text might be clearer IMHO if 'strictly =
increasing' would be used</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;instead.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0D8A5.0094F760--


Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA21653 for <[e-mail]>; Wed, 9 May 2001 08:29:13 -0700 (PDT)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id J0AR5XZV; Wed, 9 May 2001 08:23:35 -0700
From: "Carlin Covey" <[e-mail]>
To: <[e-mail]>, "David A. Cooper" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: delta CRLs
Date: Wed, 9 May 2001 08:28:26 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

David, Stephen, Ambarish, and Santosh,

Some of us are in the business for the looooong haul.  ;>)

Actually, I wasn't concerned about the CRL number wrapping, but that
possibility was advanced a few days ago as an argument against the use of
the "strictly increasing" wording.  Another email commented that PKIX did
not permit the number to wrap, although X.509 might.  The only evidence I
could find for X.509 permitting the number to wrap was "(0 .. MAX)".  As
various people have pointed out, one could be drumming one's fingers for
quite a while........

My real point was that the "monotonically increasing" wording permits the
CRL number to stay the same, while "strictly increasing" forces the numbers
to be unique (issues of wrapping aside in both cases).  Stephen Henson just
pointed out a reason why one might want the CRL number to stay the same when
issuing a delta CRL at the same time as a full CRL.  I am not arguing either
for or against that case, but it seems desirable to force the CRL numbers to
be unique in most cases.  (Unless, the CRLs are distinguished based upon
thisUpdate, as Santosh has suggested.)

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation



-----Original Message-----
From: David A. Cooper [mailto:[e-mail]]
Sent: Wednesday, May 09, 2001 6:03 AM
To: '[e-mail] '
Subject: RE: delta CRLs


 From a practical point of view, I don't think that we should need to worry
about CRL numbers wrapping.  According to my calculations, if one assigns
cRLNumber 1 to the first CRL and then numbers CRLs consecutively, one could
issue a new CRL every second for 68 years before the cRLNumber would require
more than 4 bytes (32 bits) to encode.  On the other hand, if you're willing
to issue a new CRL only once a minute, it would take 4083 years before the
cRLNumber would require more than 4 bytes to encode.

BTW, I thought that the purpose of the "(0 .. MAX)" was just to prevent use
of negative numbers. While there may, in theory be a limit to the size of an
integer that may be encoded, for all practical purposes, one can encode any
integet. According to "A Layman's Guide to a Subset of ASN.1, BER, and DER",
a DER encoded value can have a length of up to 2 ** 1008 - 1 bytes. Thus,
MAX = 2 ** [8 * ((2 ** 1008) - 1) - 1] - 1, which is far larger than any
number we would ever need.

Dave

At 08:57 PM 5/8/01 -0700, Ambarish Malpani wrote:
>
>I always thought MAX for ASN.1 INTEGERs was something I would never
>need to worry about.
>
>Looks like I was wrong :-)
>
>By the way, what is MAX? I know that we can represent numbers with
>over 2048 bits...
>
>A
>
>-----Original Message-----
>From: Carlin Covey
>To: Housley, Russ; Santosh Chokhani
>Cc: [e-mail]
>Sent: 5/8/01 5:53 PM
>Subject: RE: delta CRLs
>
>Russ,
>
>A week or two ago we arrived at a consensus to remove the requirement
>that a CA issue a full CRL whenever the CA issues a Delta-CRL.  If the
>CA chooses to issue them simultaneously, why would they need to be numbered
>the same?  If this requirement were lifted, it seems like requiring the CRL
>number to be "strictly increasing" in a sequence would be preferable to
>"monotonically increasing".  "Monotonically increasing" allows the
possibility
>that the CRL number never changes, which seems undesirable.  I realize
>that in either case the CRL number might wrap around at some point in the
future.
>That is inevitable, given that that CRL number is defined as INTEGER
(0..MAX).
>What else can a CA do when CRL number reaches MAX, stop issuing CRLs?
>
>"monotonically increasing" - Definition: A function from a partially
order[ed]
>domain to a partially ordered range such that x >= y implies f(x) >= f(y).
>
>- From the NIST web site:
>http://hissa.nist.gov/dads/HTML/monotoncincr.html
>
>Regards,
>
>Carlin
>
>____________________________
>
>-  Carlin Covey
>    Cylink Corporation
>
>-----Original Message-----
>From: Housley, Russ [mailto:[e-mail]]
>Sent: Monday, May 07, 2001 6:21 AM
>To: Santosh Chokhani
>Cc: [e-mail]
>Subject: RE: delta CRLs
>
>
>Santosh:
>
>X.509 may allow the CRL number to wrap around, but I do not believe that
>PKIX does.
>
>     5.2.3  CRL Number
>
>     The CRL number is a non-critical CRL extension which conveys a
>     monotonically increasing sequence number for each CRL issued by a CA.
>     This extension allows users to easily determine when a particular CRL
>     supersedes another CRL.  CAs conforming to this profile MUST include
>     this extension in all CRLs.
>
>     id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }
>
>Russ
>
>
>At 10:11 PM 5/5/2001 -0400, Santosh Chokhani wrote:
>
> >Actually, the text allows for the wrap of the numbers.  Please see Annex
B
> >of X.509.  Thus, it is not strictly increasing
> >
> >-----Original Message-----
> >From: Peter Sylvester
> >[<mailto:[e-mail]>mailto:[e-mail]]
> >Sent: Saturday, May 05, 2001 2:08 PM
> >To: [e-mail]; [e-mail];
> >[e-mail]
> >Cc: [e-mail]
> >Subject: RE: delta CRLs
> >
> > > Trevor:
> > >
> > > The 2000 version of X.509 is very clear on this.  For a given CRL
stream
> > > identifier, the CRL number is unique whether it is base or delta. That
is
> > > why delta number has to be greater than the base.
> >
> >" 8.5.2.1 CRL number extension
> >
> >   This CRL extension field conveys a monotonically increasing sequence
> > number .."
> >
> >The text might be clearer IMHO if 'strictly increasing' would be used
> >instead.




Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id GAA13017 for <[e-mail]>; Wed, 9 May 2001 06:16:14 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 9 May 2001 13:15:56 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA20996 for <[e-mail]>; Wed, 9 May 2001 09:16:14 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <JY8NV797>; Wed, 9 May 2001 09:16:14 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.52]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JY8NV79Z; Wed, 9 May 2001 09:16:05 -0400
From: "Housley, Russ" <[e-mail]>
To: Hal Lockhart <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 09 May 2001 09:12:39 -0400
Subject: RE: Certificate Hold (was RE: delta CRLs)
In-Reply-To: <[e-mail] m>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

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


Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net [194.217.242.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA12568 for <[e-mail]>; Wed, 9 May 2001 06:11:34 -0700 (PDT)
Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=celocom.com) by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2) id 14xTkc-000L7t-0K for [e-mail]; Wed, 9 May 2001 13:11:34 +0000
Message-ID: <[e-mail]>
Date: Wed, 09 May 2001 14:14:48 +0100
From: Dr S N Henson <[e-mail]>
Organization: S N Henson
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: delta CRLs
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Carlin Covey wrote:
> 
> 
> A week or two ago we arrived at a consensus to remove the requirement
> that a CA issue a full CRL whenever the CA issues a Delta-CRL.  If the
> CA chooses to issue them simultaneously, why would they need to be numbered
> the same?  

Its my understanding that the CRL number of the delta CRL serves an
additional purpose: it gives the CRL number of the equivalent full CRL
(which may not have been issued with the new rule) which can be
constructed by combining rhe delta with the base CRL (or a later CRL).
They have to be the same to convey this information.

See 5.2.4:

>    The constructed CRL has the CRL number specified in the CRL number
>    extension found in the delta CRL used in its construction.
> 

Another consequence of this appears to be that if a CA sometimes issues
deltas with no corresponding full CRLs then there will be gaps in the
numbering scheme of the full CRLs.

> If this requirement were lifted, it seems like requiring the CRL
> number to be "strictly increasing" in a sequence would be preferable to
> "monotonically increasing".  "Monotonically increasing" allows the
> possibility
> that the CRL number never changes, which seems undesirable.  

I'd say its not only undesirable but it also makes handling delta CRLs
difficult if not impossible.

> I realize
> that in either case the CRL number might wrap around at some point in the
> future.
> That is inevitable, given that that CRL number is defined as INTEGER
> (0..MAX).
> What else can a CA do when CRL number reaches MAX, stop issuing CRLs?
> 

Well depends on the value of MAX I suppose. 

Something like 32 bits and assuming the CA issues a CRL every second
would mean that it wouldn't wrap around for 136 years or so, which is
hopfully tolerable.

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



Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA11726 for <[e-mail]>; Wed, 9 May 2001 06:03:39 -0700 (PDT)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id JAA19089 for <[e-mail]>; Wed, 9 May 2001 09:03:35 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Wed, 09 May 2001 09:03:04 -0400
To: "'[e-mail] '" <[e-mail]>
From: "David A. Cooper" <[e-mail]>
Subject: RE: delta CRLs
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

 From a practical point of view, I don't think that we should need to worry about CRL numbers wrapping.  According to my calculations, if one assigns cRLNumber 1 to the first CRL and then numbers CRLs consecutively, one could issue a new CRL every second for 68 years before the cRLNumber would require more than 4 bytes (32 bits) to encode.  On the other hand, if you're willing to issue a new CRL only once a minute, it would take 4083 years before the cRLNumber would require more than 4 bytes to encode.

BTW, I thought that the purpose of the "(0 .. MAX)" was just to prevent use of negative numbers. While there may, in theory be a limit to the size of an integer that may be encoded, for all practical purposes, one can encode any integet. According to "A Layman's Guide to a Subset of ASN.1, BER, and DER", a DER encoded value can have a length of up to 2 ** 1008 - 1 bytes. Thus, MAX = 2 ** [8 * ((2 ** 1008) - 1) - 1] - 1, which is far larger than any number we would ever need.

Dave 

At 08:57 PM 5/8/01 -0700, Ambarish Malpani wrote:
>  
>I always thought MAX for ASN.1 INTEGERs was something I would never
>need to worry about.
>
>Looks like I was wrong :-)
>
>By the way, what is MAX? I know that we can represent numbers with
>over 2048 bits...
>
>A
>
>-----Original Message-----
>From: Carlin Covey
>To: Housley, Russ; Santosh Chokhani
>Cc: [e-mail]
>Sent: 5/8/01 5:53 PM
>Subject: RE: delta CRLs
>
>Russ,
>
>A week or two ago we arrived at a consensus to remove the requirement
>that a CA issue a full CRL whenever the CA issues a Delta-CRL.  If the
>CA chooses to issue them simultaneously, why would they need to be numbered
>the same?  If this requirement were lifted, it seems like requiring the CRL
>number to be "strictly increasing" in a sequence would be preferable to
>"monotonically increasing".  "Monotonically increasing" allows the possibility
>that the CRL number never changes, which seems undesirable.  I realize
>that in either case the CRL number might wrap around at some point in the future.
>That is inevitable, given that that CRL number is defined as INTEGER (0..MAX).
>What else can a CA do when CRL number reaches MAX, stop issuing CRLs?
>
>"monotonically increasing" - Definition: A function from a partially order[ed]
>domain to a partially ordered range such that x >= y implies f(x) >= f(y).
>
>- From the NIST web site:
>http://hissa.nist.gov/dads/HTML/monotoncincr.html
>
>Regards,
>
>Carlin
>
>____________________________
>
>-  Carlin Covey
>    Cylink Corporation
>
>-----Original Message-----
>From: Housley, Russ [mailto:[e-mail]]
>Sent: Monday, May 07, 2001 6:21 AM
>To: Santosh Chokhani
>Cc: [e-mail]
>Subject: RE: delta CRLs
>
>
>Santosh:
>
>X.509 may allow the CRL number to wrap around, but I do not believe that
>PKIX does.
>
>     5.2.3  CRL Number
>
>     The CRL number is a non-critical CRL extension which conveys a
>     monotonically increasing sequence number for each CRL issued by a CA.
>     This extension allows users to easily determine when a particular CRL
>     supersedes another CRL.  CAs conforming to this profile MUST include
>     this extension in all CRLs.
>
>     id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }
>
>Russ
>
>
>At 10:11 PM 5/5/2001 -0400, Santosh Chokhani wrote:
>
> >Actually, the text allows for the wrap of the numbers.  Please see Annex B
> >of X.509.  Thus, it is not strictly increasing
> >
> >-----Original Message-----
> >From: Peter Sylvester
> >[<mailto:[e-mail]>mailto:[e-mail]]
> >Sent: Saturday, May 05, 2001 2:08 PM
> >To: [e-mail]; [e-mail];
> >[e-mail]
> >Cc: [e-mail]
> >Subject: RE: delta CRLs
> >
> > > Trevor:
> > >
> > > The 2000 version of X.509 is very clear on this.  For a given CRL stream
> > > identifier, the CRL number is unique whether it is base or delta. That is
> > > why delta number has to be greater than the base.
> >
> >" 8.5.2.1 CRL number extension
> >
> >   This CRL extension field conveys a monotonically increasing sequence
> > number .."
> >
> >The text might be clearer IMHO if 'strictly increasing' would be used
> >instead.




Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA05733 for <[e-mail]>; Wed, 9 May 2001 04:54:37 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <KSWBCZPZ>; Wed, 9 May 2001 07:54:07 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Carlin Covey <[e-mail]>, "Housley, Russ" <[e-mail]>, Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Subject: RE: delta CRLs
Date: Wed, 9 May 2001 07:44:55 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D87D.778DFEC0"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D87D.778DFEC0
Content-Type: text/plain;
	charset="iso-8859-1"

I think if thisUpdate is the same, it is ok to give the same number.

By the way, when you think about it, CRL Number is not such a great idea.
The delta CRL extension (in my mind) should have been based on thisUpdate of
the base.  I made the suggestion at ISO meeting in 1998.  While every one
agreed, that omnipresent "backward compatibility" won out.

-----Original Message-----
From: Carlin Covey [mailto:[e-mail]]
Sent: Tuesday, May 08, 2001 8:54 PM
To: Housley, Russ; Santosh Chokhani
Cc: [e-mail]
Subject: RE: delta CRLs


Russ,

A week or two ago we arrived at a consensus to remove the requirement
that a CA issue a full CRL whenever the CA issues a Delta-CRL.  If the
CA chooses to issue them simultaneously, why would they need to be numbered
the same?  If this requirement were lifted, it seems like requiring the CRL
number to be "strictly increasing" in a sequence would be preferable to
"monotonically increasing".  "Monotonically increasing" allows the
possibility
that the CRL number never changes, which seems undesirable.  I realize
that in either case the CRL number might wrap around at some point in the
future.
That is inevitable, given that that CRL number is defined as INTEGER
(0..MAX).
What else can a CA do when CRL number reaches MAX, stop issuing CRLs?

"monotonically increasing" - Definition: A function from a partially
order[ed]
domain to a partially ordered range such that x >= y implies f(x) >= f(y).

- From the NIST web site: http://hissa.nist.gov/dads/HTML/monotoncincr.html

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Monday, May 07, 2001 6:21 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: delta CRLs


Santosh:

X.509 may allow the CRL number to wrap around, but I do not believe that
PKIX does.

    5.2.3  CRL Number

    The CRL number is a non-critical CRL extension which conveys a
    monotonically increasing sequence number for each CRL issued by a CA.
    This extension allows users to easily determine when a particular CRL
    supersedes another CRL.  CAs conforming to this profile MUST include
    this extension in all CRLs.

    id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }

Russ


At 10:11 PM 5/5/2001 -0400, Santosh Chokhani wrote:

>Actually, the text allows for the wrap of the numbers.  Please see Annex B
>of X.509.  Thus, it is not strictly increasing
>
>-----Original Message-----
>From: Peter Sylvester
>[<mailto:[e-mail]>mailto:[e-mail]]
>Sent: Saturday, May 05, 2001 2:08 PM
>To: [e-mail]; [e-mail];
>[e-mail]
>Cc: [e-mail]
>Subject: RE: delta CRLs
>
> > Trevor:
> >
> > The 2000 version of X.509 is very clear on this.  For a given CRL stream
> > identifier, the CRL number is unique whether it is base or delta.  That
is
> > why delta number has to be greater than the base.
>
>" 8.5.2.1 CRL number extension
>
>   This CRL extension field conveys a monotonically increasing sequence
> number .."
>
>The text might be clearer IMHO if 'strictly increasing' would be used
>instead.

------_=_NextPart_001_01C0D87D.778DFEC0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: delta CRLs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I think if thisUpdate is the same, it is ok to give =
the same number.</FONT>
</P>

<P><FONT SIZE=3D2>By the way, when you think about it, CRL Number is =
not such a great idea.&nbsp; The delta CRL extension (in my mind) =
should have been based on thisUpdate of the base.&nbsp; I made the =
suggestion at ISO meeting in 1998.&nbsp; While every one agreed, that =
omnipresent &quot;backward compatibility&quot; won out.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Carlin Covey [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, May 08, 2001 8:54 PM</FONT>
<BR><FONT SIZE=3D2>To: Housley, Russ; Santosh Chokhani</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: delta CRLs</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Russ,</FONT>
</P>

<P><FONT SIZE=3D2>A week or two ago we arrived at a consensus to remove =
the requirement</FONT>
<BR><FONT SIZE=3D2>that a CA issue a full CRL whenever the CA issues a =
Delta-CRL.&nbsp; If the</FONT>
<BR><FONT SIZE=3D2>CA chooses to issue them simultaneously, why would =
they need to be numbered</FONT>
<BR><FONT SIZE=3D2>the same?&nbsp; If this requirement were lifted, it =
seems like requiring the CRL</FONT>
<BR><FONT SIZE=3D2>number to be &quot;strictly increasing&quot; in a =
sequence would be preferable to</FONT>
<BR><FONT SIZE=3D2>&quot;monotonically increasing&quot;.&nbsp; =
&quot;Monotonically increasing&quot; allows the</FONT>
<BR><FONT SIZE=3D2>possibility</FONT>
<BR><FONT SIZE=3D2>that the CRL number never changes, which seems =
undesirable.&nbsp; I realize</FONT>
<BR><FONT SIZE=3D2>that in either case the CRL number might wrap around =
at some point in the</FONT>
<BR><FONT SIZE=3D2>future.</FONT>
<BR><FONT SIZE=3D2>That is inevitable, given that that CRL number is =
defined as INTEGER</FONT>
<BR><FONT SIZE=3D2>(0..MAX).</FONT>
<BR><FONT SIZE=3D2>What else can a CA do when CRL number reaches MAX, =
stop issuing CRLs?</FONT>
</P>

<P><FONT SIZE=3D2>&quot;monotonically increasing&quot; - Definition: A =
function from a partially</FONT>
<BR><FONT SIZE=3D2>order[ed]</FONT>
<BR><FONT SIZE=3D2>domain to a partially ordered range such that x =
&gt;=3D y implies f(x) &gt;=3D f(y).</FONT>
</P>

<P><FONT SIZE=3D2>- From the NIST web site: <A =
HREF=3D"http://hissa.nist.gov/dads/HTML/monotoncincr.html" =
TARGET=3D"_blank">http://hissa.nist.gov/dads/HTML/monotoncincr.html</A><=
/FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Carlin</FONT>
</P>

<P><FONT SIZE=3D2>____________________________</FONT>
</P>

<P><FONT SIZE=3D2>-&nbsp; Carlin Covey</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; Cylink Corporation</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Housley, Russ [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, May 07, 2001 6:21 AM</FONT>
<BR><FONT SIZE=3D2>To: Santosh Chokhani</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: delta CRLs</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Santosh:</FONT>
</P>

<P><FONT SIZE=3D2>X.509 may allow the CRL number to wrap around, but I =
do not believe that</FONT>
<BR><FONT SIZE=3D2>PKIX does.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; 5.2.3&nbsp; CRL Number</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; The CRL number is a non-critical =
CRL extension which conveys a</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; monotonically increasing sequence =
number for each CRL issued by a CA.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; This extension allows users to =
easily determine when a particular CRL</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; supersedes another CRL.&nbsp; CAs =
conforming to this profile MUST include</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; this extension in all =
CRLs.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; id-ce-cRLNumber OBJECT IDENTIFIER =
::=3D { id-ce 20 }</FONT>
</P>

<P><FONT SIZE=3D2>Russ</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>At 10:11 PM 5/5/2001 -0400, Santosh Chokhani =
wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt;Actually, the text allows for the wrap of the =
numbers.&nbsp; Please see Annex B</FONT>
<BR><FONT SIZE=3D2>&gt;of X.509.&nbsp; Thus, it is not strictly =
increasing</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;From: Peter Sylvester</FONT>
<BR><FONT SIZE=3D2>&gt;[&lt;<A =
HREF=3D"mailto:[e-mail]">mailto:Peter.Sylvester@EdelWe=
b.fr</A>&gt;<A =
HREF=3D"mailto:[e-mail]">mailto:Peter.Sylvester@EdelWe=
b.fr</A>]</FONT>
<BR><FONT SIZE=3D2>&gt;Sent: Saturday, May 05, 2001 2:08 PM</FONT>
<BR><FONT SIZE=3D2>&gt;To: [e-mail]; =
[e-mail];</FONT>
<BR><FONT SIZE=3D2>&gt;[e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt;Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt;Subject: RE: delta CRLs</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Trevor:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; The 2000 version of X.509 is very clear on =
this.&nbsp; For a given CRL stream</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; identifier, the CRL number is unique =
whether it is base or delta.&nbsp; That</FONT>
<BR><FONT SIZE=3D2>is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; why delta number has to be greater than =
the base.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&quot; 8.5.2.1 CRL number extension</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; This CRL extension field conveys a =
monotonically increasing sequence</FONT>
<BR><FONT SIZE=3D2>&gt; number ..&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;The text might be clearer IMHO if 'strictly =
increasing' would be used</FONT>
<BR><FONT SIZE=3D2>&gt;instead.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0D87D.778DFEC0--


Received: from pavilion (a24b31n80client230.hawaii.rr.com [24.31.80.230]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA23405 for <[e-mail]>; Wed, 9 May 2001 02:55:12 -0700 (PDT)
Message-ID: <955820015399477910@pavilion>
X-EM-Version: 5, 0, 0, 19
X-EM-Registration: #01B0530810E603002D00
X-Priority: 3
X-MSMail-Priority: Normal
From: "Mitchell" <[e-mail]>
To: [e-mail]
Subject: Business/Employment Opportunity
Date: Tue, 8 May 2001 23:47:07 -1000
MIME-Version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id CAA23406

Dear Friend:

"Making over half million dollars every 4 to 5 months from your
home for an investment of only $25 U.S. Dollars expense one
time"

THANKS TO THE COMPUTER AGE AND THE INTERNET!
===============================================

BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR !!

Before you say "Bull" , please read the following. This is the
letter you have been hearing about on the news lately. Due to the
popularity of this letter on the internet, a national weekly news
program recently devoted an entire show to the investigation of
this program described below , to see if it really can make people
money.

The show also investigated whether or not the program was legal.
Their findings proved once and for all that there are "absolutely
no laws prohibiting the participation in the program and if people
can follow the simple instructions, they are bound to make
some mega bucks with only $25 out of pocket cost".

DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT
THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING
BETTER THAN EVER.

This is what one had to say:

"Thanks to this profitable opportunity. I was approached
many times before but each time I passed on it. I am so glad
I finally joined just to see what one could expect in return
for the minimal effort and money required. To my astonishment, I
received total $ 610,470.00 in 21 weeks, with money still
coming in".
Pam Hedland, Fort Lee, New Jersey.

-------------------------------------------------------------------------

Here is another testimonial:

"This program has been around for a long time but I never
believed in it. But one day when I received this again in
the mail I decided to gamble my $25 on it. I followed thesimple instructions and walaa ..... 3 weeks later the money
started to come in. First month I only made $240.00 but
the next 2 months after that I made a total of $290,000.00.
So far, in the past 8 months by re-entering the program,I
have made over $710,000.00 and I am playing it again.
The key to success in this program is to follow the simple
steps and NOT change anything ."

More testimonials later but first,

****** PRINT THIS NOW FOR YOUR FUTURE REFERENCE *******

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
If you would like to make at least $500,000 every 4 to 5 months
easily and comfortably, please read the following...THEN READ
IT AGAIN and AGAIN !!!
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR
FINANCIAL DREAMS WILL COME TRUE, GUARANTEED!

INSTRUCTIONS:

**** Order all 5 reports shown on the list below.

**** For each report, send $5 CASH, THE NAME & NUMBER OF THE
REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS
to the person whose name appears ON THAT LIST next to the report.
MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE
TOP LEFT CORNER in case of any mail problems.

**** When you place your order, make sure you order each of the 5
reports. You will need all 5 reports so that you can save them on your 
computer and resell them. YOUR TOTAL COST $5 X 5 = $25.00.

**** Within a few days you will receive, via e-mail, each of the 5
reports from these 5 different individuals. Save them on your computer
so they will be accessible for you to send to the 1,000's of people
who will order them from you. Also make a floppy of these
reports and keep it on your desk in case something happen to your
computer.

****.IMPORTANT - DO NOT alter the names of the people who are
listed next to each report, or their sequence on the list, in
any way other than what is instructed below in steps 1 through6 or you will loose out on majority of your profits. Once you
understand the way this works, you will also see how it does not work if you 
change it.

Remember, this method has been tested, and if you alter, it
will NOT work!!! People have tried to put their friends/relatives names
on all five thinking they could get all the money. But it does not work this 
way. Believe us, we all have tried to be greedy and then nothing happened. 
So Do Not try to change anything other than what is instructed. Because if 
you do, it will not work for you. Remember, honesty reaps the reward!!!

1.. After you have ordered all 5 reports, take this advertisement
and REMOVE the name & address of the person in REPORT # 5. This
person has made it through the cycle and is no doubt counting
their fortune.

2.... Move the name & address in REPORT # 4 down TO REPORT # 5.

3.... Move the name & address in REPORT # 3 down TO REPORT # 4.

4.... Move the name & address in REPORT # 2 down TO REPORT # 3.

5.... Move the name & address in REPORT # 1 down TO REPORT # 2

6.... Insert YOUR name & address in the REPORT # 1 Position.

PLEASE MAKE SURE you copy every name & address ACCURATELY !
=========================================================

Take this entire letter, with the modified list of names, and save
it on your computer. DO NOT MAKE ANY OTHER CHANGES.
Save this on a disk as well just in case if you loose any data.

To assist you with marketing your business on the internet, the
5 reports you purchase will provide you with invaluable
marketing information which includes how to send bulk e-mails legally,
where to find thousands of free classified ads and much more.

There are 2 Primary methods to get this venture going:

METHOD # 1 : BY SENDING BULK E-MAIL LEGALLY
============================================
let's say that you decide to start small, just to see how it
goes, and we will assume You and those involved send out only
5,000 e-mails each. Let's also assume that the mailing receive only a0.2% response (the response could be much better but lets just
say it is only 0.2% . Also many people will send out hundreds of
thousands e-mails instead of only 5,000 each).

Continuing with this example, you send out only 5,000 e-mails.
With a 0.2% response, that is only 10 orders for report # 1.
Those 10 people responded by sending out 5,000 e-mail
each for a total of 50,000. Out of those 50,000 e-mails only
0.2% responded with orders. That's = 100 people responded
and ordered Report # 2. Those 100 people mail out 5,000
e-mails each for a total of 500,000 e-mails. The 0.2% response
to that is 1000 orders for Report # 3. Those 1000 people send
out 5,000 e-mails each for a total of 5 million e-mails sent out.
The 0.2% response to that is 10,000 orders for Report # 4.
Those 10,000 people send out 5,000 e-mails each for a total of
50,000,000 (50 million) e-mails. The 0.2% response to that is
100,000 orders for Report # 5.

THAT'S 100,000 ORDERS TIMES $5 EACH = $500,000.00 (half million).

Your total income in this example is:
1..... $50 +
2..... $500 +
3..... $5,000 +
4..... $50,000 +
5..... $500,000 ......... Grand Total = $555,550.00

NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE
OUT THE WORST POSSIBLE RESPONSES AND NO MATTER
HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF
MONEY !

------------------------------------------------------------------------------

REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE
ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for
a moment what would happen if everyone, or half or even one 4th
of those people mailed 100,000 e-mails each or more? There are
over 250 million people on the internet worldwide and counting.
Believe me, many people will do just that, and more!

METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET
===================================================
Advertising on the net is very very inexpensive and there are
hundreds of FREE places to advertise. Placing a lot of free adson the internet will easily get a larger response. We strongly
suggest you start with Method # 1 and add METHOD # 2 as you go
along.

For every $5 you receive, all you must do is e-mail them the Report
they ordered. That's it . Always provide same day service on all
orders. This will guarantee that the e-mail they send out, with your
name and address on it, will be prompt because they can not advertise until 
they receive the report.

_____________________ AVAILABLE REPORTS_____________________

ORDER EACH REPORT BY ITS NUMBER & NAME ONLY.

Notes: Always send $5 cash (U.S. CURRENCY) for each Report.
Checks NOT accepted. Make sure the cash is concealed by wrapping
it in at least 2 sheets of paper. On one of those sheets of paper,
Write the NUMBER & the NAME of the Report you are ordering, YOUR
E-MAIL ADDRESS and your name and postal address.

PLACE YOUR ORDER FOR THESE REPORTS NOW :
==============================================
REPORT #1, "The Insider's Guide to Sending
Bulk E-mail on the Internet"

ORDER REPORT #1 FROM:

G. Donaldson
P.O. Box 25884
Honolulu, Hawaii 96825-0884


don't forget to provide a permanent e-mail address in clear writing (better 
typed) to receive the reports. We had problems in delivery e-mails before!!!

==============================================
REPORT #2 "The Insider's Guide to Advertising for Free on the
Internet"
ORDER REPORT #2 FROM:

Vijay Paul
C-291, Second Floor
Defence Colony
New Delhi - 110024
INDIA

==============================================
REPORT #3 "The Secrets to Multilevel Marketing on the Internet"
ORDER REPORT #3 FROM:

JD
P.O.Box 1114
Des Plaines, IL 60017
USA

==============================================
REPORT #4 "How to become a Millionaire utilizing the Power of
Multilevel Marketing and the Internet"
ORDER REPORT #4 FROM:

J Santi
833 Walter Ave
Des Plaines, IL 60016
USA

==============================================
REPORT #5 "How to SEND 1,000,000 e-mails for FREE"
ORDER REPORT #5 FROM:

Elaine Rix
138 Dundas Street, West, #243
Toronto, Ontario
Canada M5G 1C3

==============================================
There are currently more than 250,000,000 people online
worldwide!

$$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$

Follow these guidelines to guarantee your success:

If you do not receive at least 10 orders for Report #1 within 2
weeks, continue sending e-mails until you do.

After you have received 10 orders, 2 to 3 weeks after that
you should receive 100 orders or more for REPORT # 2.
If you did not, continue advertising or sending e-mails until
you do.
Once you have received 100 or more orders for Report # 2,
YOU CAN RELAX, because the system is already working for
you , and the cash will continue to roll in !

THIS IS IMPORTANT TO REMEMBER : Every time your name is
moved down on the list, you are placed in front of a different report.
You can KEEP TRACK of your PROGRESS by watching which
report people are ordering from you. IF YOU WANT TO GENERATE
MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND
START THE WHOLE PROCESS AGAIN. There is NO LIMIT to
the income you can generate from this business !!!
____________________________________________________

FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS
PROGRAM:

You have just received information that can give you financial
freedom for the rest of your life, with NO RISK and JUST A
LITTLE BIT OF EFFORT. You can make more money in the
next few weeks and months than you have ever imagined.

Follow the program EXACTLY AS INSTRUCTED. Do Not change
it in any way. It works exceedingly well as it is now.
Remember to e-mail a copy of this exciting report after you
have put your name and address in Report #1 and moved others to
#2...........# 5 as instructed above. One of the people you send this to may 
send out 100,000 or more e-mails and your name will be on everyone of them. 
Remember though, the more you send out the more potential customers you will 
reach.

So my friend, I have given you the ideas, information,
materials and opportunity to become financially independent. IT IS UP TO YOU 
NOW !

************** MORE TESTIMONIALS ****************

"My name is Mitchell. My wife , Jody and I live in Chicago.
I am an accountant with a major U.S. Corporation and I
make pretty good money. When I received this program I grumbled
to Jody about receiving ''junk mail''. I made fun of the
whole thing, spouting my knowledge of the population and
percentages involved. I ''knew'' it wouldn't work. Jody
totally ignored my supposed intelligence and few days later she jumped in 
with both feet. I made merciless fun of her, and was ready to
lay the old ''I told you so'' on her when the thing didn'twork. Well, the laugh was on me! Within 3 weeks she had received
50 responses. Within the next 45 days she had received a
total of $ 147,200.00 all cash! I was shocked. I have
joined Jody in her ''hobby''."
Mitchell Wolf,
Chicago, Illinois

------------------------------------------------------------

"Not being the gambling type, it took me several weeks to
make up my mind to participate in this plan. But conservative that
I am, I decided that the initial investment was so little
that there was just no way that I wouldn't get enough orders to at
least get my money back.

I was surprised when I found my medium size post office box
crammed with orders. I made $319,210.00 in the first 12
weeks. The nice thing about this deal is that it does not matter
where people live. There simply isn't a better investment
with a faster return and so big."
Dan Sondstrom, Alberta,
Canada

-----------------------------------------------------------

"I had received this program before. I deleted it, but
later I wondered if I should have given it a try. Of course, I had
no idea who to contact to get another copy, so I had to wait
until I was e-mailed again by someone else.........11 months
passed then it luckily came again...... I did not delete this
one! I made more than $490,000 on my first try and all the
money came within 22 weeks".
Susan De Suza,
New York, N.Y.

----------------------------------------------------

"It really is a great opportunity to make relatively easy
money with little cost to you. I followed the simple
instructions carefully and within 10 days the money
started to come in. My first month I made $ 20,560.00
and by the end of third month my total cash count was
$ 362,840.00. Life is beautiful, Thanx to internet".
Fred Dellaca, Westport,
New Zealand
------------------------------------------------------------


ORDER YOUR REPORTS TODAY AND GET STARTED ON
YOUR ROAD TO FINANCIAL FREEDOM !

=======================================================

If you have any questions of the legality of this program, contact the
Office of Associate Director for Marketing Practices, Federal Trade
Commission, Bureau of Consumer Protection, Washington, D.C.


Under Bill s.1618 TITLE III passed by the 105th US Congress this
letter cannot be considered spam as long as the sender includes
contact information and a method of removal.
This is one time e-mail transmission. No request for removal is
necessary.

------------------------------------------------------------
This message is sent in compliance of the new email
Bill HR 1910. Under Bill HR 1910 passed by the 106th
US Congress on May 24, 1999, this message cannot be
considered Spam as long as we include the way to be
removed. Per Section HR 1910, Please type "REMOVE" in
the subject line and reply to this email. All removal
requests are handled personally an immediately once
received.









Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA23370 for <[e-mail]>; Wed, 9 May 2001 02:54:45 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA23504; Wed, 9 May 2001 11:54:42 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id LAA18324; Wed, 9 May 2001 11:54:11 +0200
Message-ID: <[e-mail]>
Date: Wed, 09 May 2001 11:54:25 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Carlin Covey <[e-mail]>
CC: [e-mail]
Subject: Re: delta CRLs
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Carlin,

I agree. This is the point that Peter Sylvester mentionned. Taking the
definition of monotonically increasing, we do not expect CRLs to bear the
same number ! On the contrary we expect that using that number we can
uniquely identify a CRL. 

We need to fix of the text, as you point it out again, and change
"monotonically increasing" by "strictly increasing".

Denis


> Russ,
> 
> A week or two ago we arrived at a consensus to remove the requirement
> that a CA issue a full CRL whenever the CA issues a Delta-CRL.  If the
> CA chooses to issue them simultaneously, why would they need to be numbered
> the same?  If this requirement were lifted, it seems like requiring the CRL
> number to be "strictly increasing" in a sequence would be preferable to
> "monotonically increasing".  "Monotonically increasing" allows the
> possibility
> that the CRL number never changes, which seems undesirable.  I realize
> that in either case the CRL number might wrap around at some point in the
> future.
> That is inevitable, given that that CRL number is defined as INTEGER
> (0..MAX).
> What else can a CA do when CRL number reaches MAX, stop issuing CRLs?
> 
> "monotonically increasing" - Definition: A function from a partially
> order[ed]
> domain to a partially ordered range such that x >= y implies f(x) >= f(y).
> 
> - From the NIST web site: http://hissa.nist.gov/dads/HTML/monotoncincr.html
> 
> Regards,
> 
> Carlin
> 
> ____________________________
> 
> -  Carlin Covey
>    Cylink Corporation
> 
> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
> Sent: Monday, May 07, 2001 6:21 AM
> To: Santosh Chokhani
> Cc: [e-mail]
> Subject: RE: delta CRLs
> 
> Santosh:
> 
> X.509 may allow the CRL number to wrap around, but I do not believe that
> PKIX does.
> 
>     5.2.3  CRL Number
> 
>     The CRL number is a non-critical CRL extension which conveys a
>     monotonically increasing sequence number for each CRL issued by a CA.
>     This extension allows users to easily determine when a particular CRL
>     supersedes another CRL.  CAs conforming to this profile MUST include
>     this extension in all CRLs.
> 
>     id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }
> 
> Russ
> 
> At 10:11 PM 5/5/2001 -0400, Santosh Chokhani wrote:
> 
> >Actually, the text allows for the wrap of the numbers.  Please see Annex B
> >of X.509.  Thus, it is not strictly increasing
> >
> >-----Original Message-----
> >From: Peter Sylvester
> >[<mailto:[e-mail]>mailto:[e-mail]]
> >Sent: Saturday, May 05, 2001 2:08 PM
> >To: [e-mail]; [e-mail];
> >[e-mail]
> >Cc: [e-mail]
> >Subject: RE: delta CRLs
> >
> > > Trevor:
> > >
> > > The 2000 version of X.509 is very clear on this.  For a given CRL stream
> > > identifier, the CRL number is unique whether it is base or delta.  That
> is
> > > why delta number has to be greater than the base.
> >
> >" 8.5.2.1 CRL number extension
> >
> >   This CRL extension field conveys a monotonically increasing sequence
> > number .."
> >
> >The text might be clearer IMHO if 'strictly increasing' would be used
> >instead.


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id UAA15315 for <[e-mail]>; Tue, 8 May 2001 20:58:50 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Tue, 8 May 2001 20:59:06 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Tue, 08 May 2001 20:59:06 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <HR26RP62>; Tue, 08 May 2001 20:57:08 -0700
Content-return: allowed
Date: Tue, 08 May 2001 20:57:07 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: delta CRLs
To: "'Carlin Covey '" <[e-mail]>, "'Housley, Russ '" <[e-mail]>, "'Santosh Chokhani '" <[e-mail]>
Cc: "'[e-mail] '" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe

 
I always thought MAX for ASN.1 INTEGERs was something I would never
need to worry about.

Looks like I was wrong :-)

By the way, what is MAX? I know that we can represent numbers with
over 2048 bits...

A

-----Original Message-----
From: Carlin Covey
To: Housley, Russ; Santosh Chokhani
Cc: [e-mail]
Sent: 5/8/01 5:53 PM
Subject: RE: delta CRLs

Russ,

A week or two ago we arrived at a consensus to remove the requirement
that a CA issue a full CRL whenever the CA issues a Delta-CRL.  If the
CA chooses to issue them simultaneously, why would they need to be
numbered
the same?  If this requirement were lifted, it seems like requiring the
CRL
number to be "strictly increasing" in a sequence would be preferable to
"monotonically increasing".  "Monotonically increasing" allows the
possibility
that the CRL number never changes, which seems undesirable.  I realize
that in either case the CRL number might wrap around at some point in
the
future.
That is inevitable, given that that CRL number is defined as INTEGER
(0..MAX).
What else can a CA do when CRL number reaches MAX, stop issuing CRLs?

"monotonically increasing" - Definition: A function from a partially
order[ed]
domain to a partially ordered range such that x >= y implies f(x) >=
f(y).

- From the NIST web site:
http://hissa.nist.gov/dads/HTML/monotoncincr.html

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Monday, May 07, 2001 6:21 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: delta CRLs


Santosh:

X.509 may allow the CRL number to wrap around, but I do not believe that
PKIX does.

    5.2.3  CRL Number

    The CRL number is a non-critical CRL extension which conveys a
    monotonically increasing sequence number for each CRL issued by a
CA.
    This extension allows users to easily determine when a particular
CRL
    supersedes another CRL.  CAs conforming to this profile MUST include
    this extension in all CRLs.

    id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }

Russ


At 10:11 PM 5/5/2001 -0400, Santosh Chokhani wrote:

>Actually, the text allows for the wrap of the numbers.  Please see
Annex B
>of X.509.  Thus, it is not strictly increasing
>
>-----Original Message-----
>From: Peter Sylvester
>[<mailto:[e-mail]>mailto:[e-mail]]
>Sent: Saturday, May 05, 2001 2:08 PM
>To: [e-mail]; [e-mail];
>[e-mail]
>Cc: [e-mail]
>Subject: RE: delta CRLs
>
> > Trevor:
> >
> > The 2000 version of X.509 is very clear on this.  For a given CRL
stream
> > identifier, the CRL number is unique whether it is base or delta.
That
is
> > why delta number has to be greater than the base.
>
>" 8.5.2.1 CRL number extension
>
>   This CRL extension field conveys a monotonically increasing sequence
> number .."
>
>The text might be clearer IMHO if 'strictly increasing' would be used
>instead.


Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA09785 for <[e-mail]>; Tue, 8 May 2001 17:52:41 -0700 (PDT)
Received: from COVEY (cpe-24-221-22-72.az.sprintbbd.net [24.221.22.72]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id J0AR5V6X; Tue, 8 May 2001 17:47:07 -0700
From: "Carlin Covey" <[e-mail]>
To: "Housley, Russ" <[e-mail]>, "Santosh Chokhani" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: delta CRLs
Date: Tue, 8 May 2001 17:53:31 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

Russ,

A week or two ago we arrived at a consensus to remove the requirement
that a CA issue a full CRL whenever the CA issues a Delta-CRL.  If the
CA chooses to issue them simultaneously, why would they need to be numbered
the same?  If this requirement were lifted, it seems like requiring the CRL
number to be "strictly increasing" in a sequence would be preferable to
"monotonically increasing".  "Monotonically increasing" allows the
possibility
that the CRL number never changes, which seems undesirable.  I realize
that in either case the CRL number might wrap around at some point in the
future.
That is inevitable, given that that CRL number is defined as INTEGER
(0..MAX).
What else can a CA do when CRL number reaches MAX, stop issuing CRLs?

"monotonically increasing" - Definition: A function from a partially
order[ed]
domain to a partially ordered range such that x >= y implies f(x) >= f(y).

- From the NIST web site: http://hissa.nist.gov/dads/HTML/monotoncincr.html

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Monday, May 07, 2001 6:21 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: delta CRLs


Santosh:

X.509 may allow the CRL number to wrap around, but I do not believe that
PKIX does.

    5.2.3  CRL Number

    The CRL number is a non-critical CRL extension which conveys a
    monotonically increasing sequence number for each CRL issued by a CA.
    This extension allows users to easily determine when a particular CRL
    supersedes another CRL.  CAs conforming to this profile MUST include
    this extension in all CRLs.

    id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }

Russ


At 10:11 PM 5/5/2001 -0400, Santosh Chokhani wrote:

>Actually, the text allows for the wrap of the numbers.  Please see Annex B
>of X.509.  Thus, it is not strictly increasing
>
>-----Original Message-----
>From: Peter Sylvester
>[<mailto:[e-mail]>mailto:[e-mail]]
>Sent: Saturday, May 05, 2001 2:08 PM
>To: [e-mail]; [e-mail];
>[e-mail]
>Cc: [e-mail]
>Subject: RE: delta CRLs
>
> > Trevor:
> >
> > The 2000 version of X.509 is very clear on this.  For a given CRL stream
> > identifier, the CRL number is unique whether it is base or delta.  That
is
> > why delta number has to be greater than the base.
>
>" 8.5.2.1 CRL number extension
>
>   This CRL extension field conveys a monotonically increasing sequence
> number .."
>
>The text might be clearer IMHO if 'strictly increasing' would be used
>instead.



Received: from smtp-2.llnl.gov (smtp-2.llnl.gov [128.115.250.82]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA17544 for <[e-mail]>; Tue, 8 May 2001 11:34:50 -0700 (PDT)
Received: from poptop.llnl.gov (localhost [127.0.0.1]) by smtp-2.llnl.gov (8.9.3/8.9.3/LLNL-gateway-1.0) with ESMTP id LAA08463; Tue, 8 May 2001 11:34:21 -0700 (PDT)
Received: from catalyst.llnl.gov (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id LAA22807; Tue, 8 May 2001 11:34:16 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 08 May 2001 11:39:50 -0700
To: Santosh Chokhani <[e-mail]>, Peter Sylvester <[e-mail]>, [e-mail], [e-mail], Santosh Chokhani <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: RE: delta CRLs
Cc: [e-mail]
In-Reply-To: <[e-mail]. com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

If wrapping is allowed (reasonable), then the sequence is neither strictly 
nor monotonically increasing.  I have once offered the definition 
"unitarily increasing" to mean "each new issue increases by one", but that 
is an invented term, and one still needs to specify either the number of 
digits or the maximal value if wrapping is an expectation.  Technically, 
"0,1,0,1,..." would qualify in Z2.

___tony___

At 10:11 PM 5/5/01 -0400, Santosh Chokhani wrote:

>Actually, the text allows for the wrap of the numbers.  Please see Annex B 
>of X.509.  Thus, it is not strictly increasing
>
>-----Original Message-----
>From: Peter Sylvester 
>[<mailto:[e-mail]>mailto:[e-mail]]
>Sent: Saturday, May 05, 2001 2:08 PM
>To: [e-mail]; [e-mail];
>[e-mail]
>Cc: [e-mail]
>Subject: RE: delta CRLs
>
> > Trevor:
> >
> > The 2000 version of X.509 is very clear on this.  For a given CRL stream
> > identifier, the CRL number is unique whether it is base or delta.  That is
> > why delta number has to be greater than the base.
>
>" 8.5.2.1 CRL number extension
>
>   This CRL extension field conveys a monotonically increasing sequence 
> number .."
>
>The text might be clearer IMHO if 'strictly increasing' would be used 
>instead.

Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900






Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA10234 for <[e-mail]>; Tue, 8 May 2001 08:57:52 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <KRCMM7KH>; Tue, 8 May 2001 11:57:20 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Hal Lockhart <[e-mail]>, "'Ambarish Malpani'" <[e-mail]>, "'Housley, Russ '" <[e-mail]>, "'Tom Gindin '" <[e-mail]>
Cc: "'[e-mail] '" <[e-mail]>
Subject: RE: Certificate Hold (was RE: delta CRLs)
Date: Tue, 8 May 2001 11:48:08 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D7D6.47205B90"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D7D6.47205B90
Content-Type: text/plain;
	charset="iso-8859-1"

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:[e-mail]]
Sent: Tuesday, May 08, 2001 11:47 AM
To: 'Ambarish Malpani'; 'Housley, Russ '; 'Tom Gindin '
Cc: '[e-mail] '
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

------_=_NextPart_001_01C0D7D6.47205B90
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Certificate Hold (was RE: delta CRLs)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Some times people put a certificate on hold because =
some one is out of pocket for a while.&nbsp; In that case, the =
signatures made during the hold period should be considered =
invalid.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Hal Lockhart [<A =
HREF=3D"mailto:[e-mail]">mailto:hal.lockhart@entegrity=
.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, May 08, 2001 11:47 AM</FONT>
<BR><FONT SIZE=3D2>To: 'Ambarish Malpani'; 'Housley, Russ '; 'Tom =
Gindin '</FONT>
<BR><FONT SIZE=3D2>Cc: '[e-mail] '</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Certificate Hold (was RE: delta =
CRLs)</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&nbsp;Ambarish Malpani wrote: </FONT>
<BR><FONT SIZE=3D2>&gt; Certificate suspension is a useful mechanism to =
prevent the usage of</FONT>
<BR><FONT SIZE=3D2>&gt; a certificate while you figure out whether it =
should actually be</FONT>
<BR><FONT SIZE=3D2>&gt; revoked or not. </FONT>
</P>

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

<P><FONT SIZE=3D2>Hal</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0D7D6.47205B90--


Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA09690 for <[e-mail]>; Tue, 8 May 2001 08:56:08 -0700 (PDT)
Received: from HEATHERDALE (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f48Ftcg17527; Tue, 8 May 2001 08:55:39 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Hal Lockhart" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Certificate Hold (was RE: delta CRLs)
Date: Tue, 8 May 2001 08:55:16 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>
Importance: Normal

Hal,

Among the effects of hold is the potential to collaterally suspend a
transaction secured by the subject certificate, so it's not just NR.

Mike


> -----Original Message-----
> From: Hal Lockhart [mailto:[e-mail]]
> Sent: Tuesday, May 08, 2001 8:47 AM
> To: 'Ambarish Malpani'; 'Housley, Russ '; 'Tom Gindin '
> Cc: '[e-mail] '
> 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
>



Received: from indy.gradient.com ([e-mail] [192.92.110.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA06752 for <[e-mail]>; Tue, 8 May 2001 08:42:42 -0700 (PDT)
Received: from bigbird.gradient.com (bigbird.gradient.com [192.92.110.50]) by indy.gradient.com (8.9.1a/8.9.1) with ESMTP id LAA06004; Tue, 8 May 2001 11:42:41 -0400 (EDT)
Received: by bigbird.gradient.com with Internet Mail Service (5.5.2650.10) id <2YBR6XB5>; Tue, 8 May 2001 11:47:53 -0400
Message-ID: <[e-mail]>
From: Hal Lockhart <[e-mail]>
To: "'Ambarish Malpani'" <[e-mail]>, "'Housley, Russ '" <[e-mail]>, "'Tom Gindin '" <[e-mail]>
Cc: "'[e-mail] '" <[e-mail]>
Subject: RE: Certificate Hold (was RE: delta CRLs)
Date: Tue, 8 May 2001 11:47:15 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain; charset="iso-8859-1"

 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


Received: from exchsvr1.entegrity.com (exchsvr1.entegrity.com [207.215.19.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA04260 for <[e-mail]>; Tue, 8 May 2001 08:31:27 -0700 (PDT)
Received: from HEMLOCK ([10.10.3.101]) by exchsvr1.entegrity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GFR1DCV3; Tue, 8 May 2001 08:32:12 -0700
Message-ID: <009a01c0d7d3$cbf116a0$[e-mail]>
Reply-To: "Steve Wang" <[e-mail]>
From: "Steve Wang" <[e-mail]>
To: "Erica Yang" <[e-mail]>, <[e-mail]>
References: <00ae01c0d7c8$eb222b50$[e-mail]>
Subject: Re: Secret Sharing Scheme and Threshold Cryptography 
Date: Tue, 8 May 2001 11:30:14 -0400
Organization: Entegrity Solutions
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

There are several applications of Threshold Cryptography,
checking the following URLs:

http://crypto.stanford.edu/~dabo/abstracts/ittc.html
http://www.hrl.il.ibm.com/Proactive/index.html
http://www.cs.gmu.edu/~xwang4/acsac00.ps (used to enable secure DNS dynamic
update)

AT&T also has an implementation but I do not
have the URL at hand.

Regards,

Steve

----- Original Message -----
From: "Erica Yang" <[e-mail]>
To: <[e-mail]>
Sent: Tuesday, May 08, 2001 10:12 AM
Subject: Secret Sharing Scheme and Threshold Cryptography


> hi, all
>
> I am currently looking for working and practical systems that implement
the
> secret sharing scheme and/or threshold cryptography. If you have any
> information about that, could you please let me know?
>
> I can see there are lots of theoretical results available, but so far I
can
> rarely find any practical systems (either from academics or from industry)
> that implement them! Why? Am I missing something?
>
> Are there any survey papers about the state of the practice of threshold
> cryptography?
>
> Any pointers are welcome. I will be grateful for any suggestions from you!
>
> Thanks for your time and patience.
>
> Regards,
>
> Erica



Received: from hermes.dur.ac.uk (hermes.dur.ac.uk [129.234.4.9]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA28419 for <[e-mail]>; Tue, 8 May 2001 07:08:51 -0700 (PDT)
Received: from mercury.dur.ac.uk (mercury.dur.ac.uk [129.234.4.40]) by hermes.dur.ac.uk (8.11.1/8.11.1) with ESMTP id f48E8pl12872 for <[e-mail]>; Tue, 8 May 2001 15:08:52 +0100 (BST)
Received: from cs154 (cs-154.dur.ac.uk [129.234.200.154]) by mercury.dur.ac.uk (8.11.1/8.11.1) with SMTP id f48E8oZ04402 for <[e-mail]>; Tue, 8 May 2001 15:08:51 +0100 (BST)
Message-ID: <00ae01c0d7c8$eb222b50$[e-mail]>
Reply-To: "Erica Yang" <[e-mail]>
From: "Erica Yang" <[e-mail]>
To: <[e-mail]>
Subject: Secret Sharing Scheme and Threshold Cryptography
Date: Tue, 8 May 2001 15:12:29 +0100
Organization: Computer Science, University of Durham
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

hi, all

I am currently looking for working and practical systems that implement the
secret sharing scheme and/or threshold cryptography. If you have any
information about that, could you please let me know?

I can see there are lots of theoretical results available, but so far I can
rarely find any practical systems (either from academics or from industry)
that implement them! Why? Am I missing something?

Are there any survey papers about the state of the practice of threshold
cryptography?

Any pointers are welcome. I will be grateful for any suggestions from you!

Thanks for your time and patience.

Regards,

Erica



Received: from VOLTAIRE.stic.net (mail.stic.net [216.198.0.5] (may be forged)) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA25508 for <[e-mail]>; Tue, 8 May 2001 06:51:44 -0700 (PDT)
Received: from b6o1x7 ([216.198.62.19]) by VOLTAIRE.stic.net (Post.Office MTA v3.5.3 release 223 ID# 0-70040U18500L11000S0V35) with SMTP id net for <[e-mail]>; Tue, 8 May 2001 08:51:33 -0500
Message-ID: <000d01c0d7c6$b8df1ce0$133ec6d8@b6o1x7>
From: "Bob & Pat Smith" <[e-mail]>
To: <[e-mail]>
Subject: unsubscribe
Date: Tue, 8 May 2001 08:56:46 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C0D79C.CF613C20"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200

This is a multi-part message in MIME format.

------=_NextPart_000_000A_01C0D79C.CF613C20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Please unsubscribe us from this program immediately. Thank you

------=_NextPart_000_000A_01C0D79C.CF613C20
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Please unsubscribe us from this program =

immediately. Thank you</FONT></DIV></BODY></HTML>

------=_NextPart_000_000A_01C0D79C.CF613C20--



Received: from zolera.com (IDENT:root@[63.142.188.177]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA24849 for <[e-mail]>; Tue, 8 May 2001 06:49:31 -0700 (PDT)
Received: from zolera.com (os390.zolera.com [10.0.1.9]) by zolera.com (8.11.0/8.11.0) with ESMTP id f48DnTf22372; Tue, 8 May 2001 09:49:29 -0400
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 08 May 2001 09:49:31 -0400
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail]
Subject: Re: Certificate Hold (was RE: delta CRLs)
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> Many OCSP responders get their revocation information bay way of a
> CRL, so this would seem to be a good reason to not prohibit the use of the
> feature.

The problem I've always had with hold is that it introduces state across
CRL's.  Still and all, I agree deprecation is the way to go.
	/r$


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id GAA23034 for <[e-mail]>; Tue, 8 May 2001 06:07:13 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 8 May 2001 13:06:57 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA29144 for <[e-mail]>; Tue, 8 May 2001 09:07:08 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <JY8NVNVT>; Tue, 8 May 2001 09:07:08 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.68]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JY8NVNVQ; Tue, 8 May 2001 09:07:05 -0400
From: "Housley, Russ" <[e-mail]>
To: Ambarish Malpani <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 08 May 2001 08:42:04 -0400
Subject: RE: Certificate Hold (was RE: delta CRLs)
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Ambarish:

Thanks.  Many OCSP responders get their revocation information bay way of a 
CRL, so this would seem to be a good reason to not prohibit the use of the 
feature.

Russ

At 09:54 PM 5/7/2001 -0700, Ambarish Malpani wrote:
>
>Russ, while I don't object to us deprecating the use of certificate
>suspension, I don't think we should prohibit its usage.
>
>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.
>
>I don't agree with us saying that PKIX supports suspension only via
>OCSP - that just sounds wrong to me.
>
>Regards,
>Ambarish
>
>-----Original Message-----
>From: Housley, Russ
>To: Tom Gindin
>Cc: [e-mail]
>Sent: 5/7/01 10:13 AM
>Subject: RE: Certificate Hold (was RE: delta CRLs)
>
>Tom:
>
>I have not been able to make myself clear.  Perhaps because you keep
>looking to simple authentication applications.  My hope is that the PKIX
>
>profile will readily meet the needs of these relatively straightforward
>applications and also support the more demanding needs of applications
>where non-repudiation is needed.
>
>All:
>
>My view of the question is that three people have voiced a desire to see
>
>the suspension feature removed, one is asking questions without voicing
>a
>position, and no one has asked to keep it.  People who have an opinion
>but
>have not posted it yet please do so.
>
>Russ


Received: from www.aptvs.org ([63.143.30.140]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA19954 for <[e-mail]>; Tue, 8 May 2001 05:29:20 -0700 (PDT)
Received: from c4.com ([64.3.195.251]) by www.aptvs.org (Lotus Domino Release 5.0.6a) with SMTP id 2001050806240515:21059 ; Tue, 8 May 2001 06:24:05 -0400 
From: <[e-mail]>
To: [e-mail]
Subject: toner supplies
Date: Tue, 8 May 2001 06:14:06
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on NotesAPT/American Public Television(Release 5.0.6a |January 17, 2001) at 05/08/2001 06:24:19 AM, Serialize by Router on NotesAPT/American Public Television(Release 5.0.6a |January 17, 2001) at 05/08/2001 08:37:53 AM, Serialize complete at 05/08/2001 08:37:53 AM
Content-Type: text/plain; charset="us-ascii"

PLEASE FORWARD TO THE PERSON
RESPONSIBLE FOR PURCHASING
YOUR LASER PRINTER SUPPLIES

**** VORTEX  SUPPLIES ****


-SPECIALS OF THE DAY ON LASER TONER SUPPLIES AT DISCOUNT PRICES--


LASER PRINTER TONER CARTRIDGES
COPIER AND FAX CARTRIDGES


WE ARE -->THE<-- PLACE TO BUY YOUR TONER CARTRIDGES BECAUSE YOU
SAVE UP TO 30% FROM OFFICE DEPOT'S, QUILL'S OR OFFICE MAX'S EVERY DAY LOW PRICES


ORDER BY PHONE:[phone]
ORDER BY FAX: [phone]
CUSTOMER SERVICE: 1-888-248-2015
E-MAIL REMOVAL LINE: 1-888-248-4930 

UNIVERSITY AND/OR SCHOOL PURCHASE ORDERS WELCOME. (NO CREDIT APPROVAL REQUIRED)
ALL OTHER PURCHASE ORDER REQUESTS REQUIRE CREDIT APPROVAL.
PAY BY CHECK (C.O.D), CREDIT CARD OR PURCHASE ORDER (NET 30 DAYS).

IF YOUR ORDER IS BY CREDIT CARD PLEASE LEAVE YOUR CREDIT CARD # PLUS EXPIRATION DATE. 
IF YOUR ORDER IS BY PURCHASE ORDER LEAVE YOUR SHIPPING/BILLING ADDRESSES AND YOUR P.O. NUMBER
C.O.D. ORDERS ADD $4.5 TO SHIPPING CHARGES.

FOR THOSE OF YOU WHO REQUIRE MORE INFORMATION ABOUT OUR COMPANY
INCUDING FEDERAL TAX ID NUMBER, CLOSEST SHIPPING OR CORPORATE ADDRESS IN THE CONTINENTAL 
U.S. OR  FOR CATALOG  REQUESTS PLEASE CALL OUR CUSTOMER SERVICE LINE  1-888-248-2015 
 

OUR NEW , LASER PRINTER TONER CARTRIDGE, PRICES ARE  AS FOLLOWS: 
(PLEASE ORDER BY PAGE NUMBER AND/OR ITEM NUMBER)

HEWLETT PACKARD: (ON PAGE 2)

ITEM #1  LASERJET SERIES  4L,4P (74A)------------------------$44
ITEM #2  LASERJET SERIES  1100 (92A)-------------------------$44
ITEM #3  LASERJET SERIES  2 (95A)-------------------------------$39
ITEM #4  LASERJET SERIES  2P (75A)-----------------------------$54 
ITEM #5  LASERJET SERIES  5P,6P,5MP, 6MP (3903A)--$44
ITEM #6  LASERJET SERIES  5SI, 8000 (09A)------------------$95
ITEM #7  LASERJET SERIES  2100 (96A)-------------------------$74
ITEM #8  LASERJET SERIES  8100 (82X)-----------------------$145
ITEM #9  LASERJET SERIES  5L/6L (3906A)------------------$35
ITEM #10 LASERJET SERIES  4V-------------------------------------$95
ITEM #11 LASERJET SERIES 4000 (27X)-------------------------$72
ITEM #12 LASERJET SERIES 3SI/4SI (91A)--------------------$54
ITEM #13 LASERJET SERIES 4, 4M, 5,5M-----------------------$49
ITEM #13A LASERJET SERIES 5000 (29X)---------------------$95

HEWLETT PACKARD FAX (ON PAGE 2)

ITEM #14 LASERFAX 500, 700 (FX1)----------$49
ITEM #15  LASERFAX 5000,7000 (FX2)------$54
ITEM #16  LASERFAX (FX3)------------------------$59
ITEM #17  LASERFAX (FX4)------------------------$54


LEXMARK/IBM (ON PAGE 3)

OPTRA 4019, 4029 HIGH YIELD---------------$89
OPTRA R, 4039, 4049 HIGH YIELD---------$105

OPTRA E----------------------------------------------------$59
OPTRA N--------------------------------------------------$115
OPTRA S--------------------------------------------------$165


EPSON (ON PAGE 4)

ACTION LASER 7000,7500,8000,9000-------$105
ACTION LASER 1000,1500-------------------------$105


CANON PRINTERS (ON PAGE 5)

PLEASE CALL FOR MODELS AND UPDATED PRICES
FOR CANON PRINTER CARTRIDGES

PANASONIC (0N PAGE 7)

NEC SERIES 2 MODELS 90 AND 95----------$105

APPLE (0N PAGE 8)

LASER WRITER PRO 600 or 16/600------------$49 
LASER WRITER SELECT 300,320,360---------$74
LASER WRITER 300 AND 320----------------------$54
LASER WRITER NT, 2NT------------------------------$54
LASER WRITER 12/640--------------------------------$79

CANON FAX (ON PAGE 9)

LASERCLASS 4000 (FX3)---------------------------$59
LASERCLASS 5000,6000,7000 (FX2)---------$54
LASERFAX 5000,7000 (FX2)----------------------$54
LASERFAX 8500,9000 (FX4)----------------------$54

CANON COPIERS (PAGE 10)

PC 3, 6RE, 7 AND 11 (A30)---------------------$69
PC 300,320,700,720 and 760 (E-40)--------$89

IF YOUR CARTRIDGE IS NOT LISTED CALL CUSTOMER SERVICE AT 1-888-248-2015 

90 DAY UNLIMITED WARRANTY INCLUDED ON ALL PRODUCTS.

ALL TRADEMARKS AND BRAND NAMES LISTED ABOVE ARE PROPERTY OF THE 
RESPECTIVE HOLDERS AND USED FOR DESCRIPTIVE PURPOSES ONLY.






Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id FAA18947 for <[e-mail]>; Tue, 8 May 2001 05:20:00 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 8 May 2001 12:19:44 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA25981 for <[e-mail]>; Tue, 8 May 2001 08:19:57 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <JY8NVNCY>; Tue, 8 May 2001 08:19:56 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.42]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JY8NVNCS; Tue, 8 May 2001 08:19:52 -0400
From: "Housley, Russ" <[e-mail]>
To: "David A. Cooper" <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 07 May 2001 19:41:32 -0400
Subject: RE: delta CRLs
In-Reply-To: <[e-mail]>
References: <[e-mail]. com> <[e-mail]. com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

David:

>>I have read section 9 of X.509-2000 (4th Edition v7) three times 
>>today.  I cannot find the requirement there.  Where is it hidden?
>
>There used to be a requirement in X.509 that whenever a full CRL is issued 
>a delta-CRL must also be issued (if delta-CRLs are being used) and that 
>the full and the delta must have the same CRL number. I don't know why 
>that text was removed. However, there is the requirement that the CRL 
>numbers for a sequence of CRLs issued for a given scope must increase 
>monotonically. The fact that some of the CRLs in the sequence contain the 
>deltaCRLIndicator extension and some do not is irrelevant (just as the 
>presence or absence of the orderedList extension or the 
>authorityKeyIdentifier extension has no affect on the CRL number).

Two independent sequence number streams can meet the remaining 
requirements.  Sounds like the revisions have removed the only sentence 
that was crystal clear on this point.

>There is also the following text in X.509 (2000):
>
>         A CRL that is complete for a given scope, at the current time, 
> can be constructed
>         locally in either of the following ways:
>
>                 by retrieving the current dCRL for that scope, and 
> combining it with an issued
>                 CRL that is complete for that scope and that has a 
> cRLNumber greater than or
>                 equal to the cRLNumber of the base CRL referenced in the 
> dCRL; or
>
>                 by retrieving the current dCRL for that scope and 
> combining it with a locally
>                 constructed CRL that is complete for that scope and that 
> was constructed with
>                 a dCRL that has a cRLNumber greater than or equal to the 
> cRLNumber of the
>                 base CRLreferenced in the current dCRL.
>
>
>If full CRLs and delta-CRLs were independently numbered, then one could 
>not apply delta-CRLs to locally constructed delta-CRLs as described above.

I agree that it could not be done in all cases.  Perhaps this is where 
Denis gets the idea that there are circumstances where the full CRL must be 
fetched periodically.

>To demonstrate the problem, I will the example that you provided (see 
>below). In this example, 144 hours (48 x 3) after delta-CRL number 49 was 
>issued, delta-CRL number 193 will be issued. Delta-CRL number 193 will 
>have a BaseCRLNumber of 49. The intention of this would be to specify that 
>delta-CRL number 193 may be combined with full CRL number 49 (which was 
>issued 143 hours after delta-CRL number 49 was issued).
>
>Suppose, however, that a relying party constructed a CRL locally using 
>full CRL number 1 and delta-CRL number 49. According to the above text 
>from X.509, that relying party could combine delta-CRL number 193 with the 
>CRL locally generated using delta-CRL number 49. The results of combining 
>delta-CRL number 193 with the locally generated CRL would clearly be 
>incorrect. Worse, it would not be obvious to the relying party that the 
>CRL numbers in the delta-CRLs were incorrect and so it would be very 
>difficult for the relying party to determine that the constructed CRL was 
>incorrect.
>
>The only way that one can safely combine a delta-CRL with a locally 
>generated CRL as specified above is if full CRLs and delta-CRLs are 
>numbered consistently. So, while one may argue that the requirement has 
>not been stated with sufficient clarity, it is there.

As I have said, I am quite comfortable with imposing a single sequence 
number stream as a PKIX profile requirement.  And, so far, I have not heard 
anyone argue that we should not have a single sequence number stream.

Russ


Received: from femail15.sdc1.sfba.home.com (femail15.sdc1.sfba.home.com [24.0.95.142]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA14919 for <[e-mail]>; Tue, 8 May 2001 04:44:37 -0700 (PDT)
Received: from cc787228a ([24.180.131.6]) by femail15.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010508114432.ISQC20722.femail15.sdc1.sfba.home.com@cc787228a>; Tue, 8 May 2001 04:44:32 -0700
Message-ID: <002401c0d7b4$a5af7b40$[e-mail]>
From: "Al Arsenault" <[e-mail]>
To: "Carlin Covey" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Certificate Hold (was RE: delta CRLs)
Date: Tue, 8 May 2001 07:47:23 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

I cast a vote identical to Carlin's.

        Al Arsenault
        Chief Security Architect
        Diversinet Corp.

----- Original Message -----
From: "Carlin Covey" <[e-mail]>
To: <[e-mail]>
Sent: Monday, May 07, 2001 7:14 PM
Subject: RE: Certificate Hold (was RE: delta CRLs)


> I cast a vote for altering the wording of the PKIX profile
> to deprecate the use of certificate suspension via CRLs.
>
> -  Carlin Covey
>    Cylink Corporation
>
> -----Original Message-----
> From: Michael Myers [mailto:[e-mail]]
> Sent: Monday, May 07, 2001 3:42 PM
> To: [e-mail]
> Subject: RE: Certificate Hold (was RE: delta CRLs)
>
>
> > From: Housley, Russ [mailto:[e-mail]]
> > On Monday, May 07, 2001 10:14 AM, Russ asked:
> >
> > . . .
> >
> > All:
> >
> > My view of the question is that three people have voiced a desire to see
> > the suspension feature removed, one is asking questions without voicing
a
> > position, and no one has asked to keep it.  People who have an
> > opinion but have not posted it yet please do so.
>
>
> Towards consensus, I agree to the removal of the CRL-based suspension
> feature.  Suspension requirements are still important but PKIX has devised
a
> means via OCSP of more effectively addressing this need.
>
> Mike
>



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA26512 for <[e-mail]>; Mon, 7 May 2001 21:56:34 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Mon, 7 May 2001 21:56:50 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Mon, 07 May 2001 21:56:50 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <HR26RL4L>; Mon, 07 May 2001 21:54:55 -0700
Content-return: allowed
Date: Mon, 07 May 2001 21:54:54 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: Certificate Hold (was RE: delta CRLs)
To: "'Housley, Russ '" <[e-mail]>, "'Tom Gindin '" <[e-mail]>
Cc: "'[e-mail] '" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe

 
Russ, while I don't object to us deprecating the use of certificate
suspension, I don't think we should prohibit its usage.

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.

I don't agree with us saying that PKIX supports suspension only via
OCSP - that just sounds wrong to me.

Regards,
Ambarish

-----Original Message-----
From: Housley, Russ
To: Tom Gindin
Cc: [e-mail]
Sent: 5/7/01 10:13 AM
Subject: RE: Certificate Hold (was RE: delta CRLs)

Tom:

I have not been able to make myself clear.  Perhaps because you keep 
looking to simple authentication applications.  My hope is that the PKIX

profile will readily meet the needs of these relatively straightforward 
applications and also support the more demanding needs of applications 
where non-repudiation is needed.

All:

My view of the question is that three people have voiced a desire to see

the suspension feature removed, one is asking questions without voicing
a 
position, and no one has asked to keep it.  People who have an opinion
but 
have not posted it yet please do so.

Russ



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA19085 for <[e-mail]>; Mon, 7 May 2001 18:02:36 -0700 (PDT)
Received: from [128.33.238.50] (TC050.BBN.COM [128.33.238.50]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id VAA11413; Mon, 7 May 2001 21:02:36 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010402b710c404b898@[128.33.238.42]>
In-Reply-To: <2B55DABB95C4D4119C1300508BD953F11442D5@BLUE01>
References: <2B55DABB95C4D4119C1300508BD953F11442D5@BLUE01>
Date: Sat, 28 Apr 2001 15:03:04 -0400
To: Dave Oshman <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: keyCertSign and cRLSign Key Usage Bits
Cc: [e-mail]
Content-Type: multipart/alternative; boundary="============_-1222838761==_ma============"

--============_-1222838761==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 8:46 PM -0400 4/25/01, Dave Oshman wrote:
>Steve--
>2459 does not seem to disallow this now. It is simply not clear on 
>it. I agree that the standard needs to be unambiguous. We need to 
>clearly define what CA=true means. If it means the PK in this cert 
>is used to verify signatures on certificates, then this means that 
>the CA flag should not be set for a CRL Signing certificate.
>Regards,
>Dave

Dave,

Neither X.509 not 2459 name any entity other than a CA than can sign 
CRLs and both refer to CAs or to "authorities" extensively in their 
discussion of CRLs and mandated requirements re CRL issuance. So, 
while I agree that there is some syntactic ambiguity here, there has 
not been semantic ambiguity.

Steve
--============_-1222838761==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { margin-top: 0 ; margin-bottom: 0 }
 --></style><title>RE: keyCertSign and cRLSign Key Usage
Bits</title></head><body>
<div>At 8:46 PM -0400 4/25/01, Dave Oshman wrote:</div>
<blockquote type="cite" cite><font face="Arial" size="-1"
color="#0000FF">Steve--</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1"
color="#0000FF">2459 does not seem to disallow this now. It is simply
not clear on it. I agree that the standard needs to be unambiguous. We
need to clearly define what CA=true means. If it means the PK in this
cert is used to verify signatures on certificates, then this means
that the CA flag should not be set for a CRL Signing
certificate.</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1"
color="#0000FF">Regards,</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1"
color="#0000FF">Dave</font></blockquote>
<div><br></div>
<div>Dave,</div>
<div><br></div>
<div>Neither X.509 not 2459 name any entity other than a CA than can
sign CRLs and both refer to CAs or to &quot;authorities&quot;
extensively in their discussion of CRLs and mandated requirements re
CRL issuance. So, while I agree that there is some syntactic ambiguity
here, there has not been semantic ambiguity.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1222838761==_ma============--


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA19069 for <[e-mail]>; Mon, 7 May 2001 18:02:33 -0700 (PDT)
Received: from [128.33.238.50] (TC050.BBN.COM [128.33.238.50]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id VAA11408; Mon, 7 May 2001 21:02:33 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010401b710bf7aa776@[128.33.238.42]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <000801c0c6a7$60e9d870$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sat, 28 Apr 2001 17:31:08 -0400
To: "David A. Cooper" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: cA flag and CRL issuers (was Re: Last Call:     draft-ietf-pkix-new-part1-06.txt comments)
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

David,

>Steve,
>
>If we are going to change PKIX to require the cA bit in 
>basicConstraints to be set even when the subject public key can only 
>be used to verify signatures on CRLs, then we need to be sure that 
>the text clearly explains to readers when the cA bit should or 
>should not be set. Currently new-part1-06 states that "[t]he cA bit 
>indicates if the certified public key may be used to verify 
>signatures on other certificates." The clearly is not accurate, 
>since if the cA bit is set one still does not know whether the 
>subject public key may be used to verify signatures on certificates. 
>One must look at the keyUsage extension to make that determination.
>
>I think it would be helpful to the discussion that we are having if 
>you would clearly state your interpretation of the meaning of the cA 
>bit in basicConstraints.

First, it's not an issue of "my interpretation."  As I noted earlier, 
prior to v3 certs and v2 CRLs, there was no way that anyone could 
interpret the text to suggest that a non-CA entity could issue a CRL. 
V3 certs and v2 CRLs might admit this possibility, syntactically, but 
no text in X.509 nor 2459 identifies a new entity type that could 
issue CRLs, and thus the syntactic ambiguity is not supported by the 
semantics expressed by the rest of the text that describes PKI 
components and responsibilities. So, the status quo is that only CAs 
sign CRLs.  The suggestion is to change this. I am comfortable if we 
do that, but only if we go back and introduce a new entity that can 
sign a CRL and not be a CA. So, my "interpretation" of the CA bit is 
simple; it identifies a cert as belonging to a CA and used to 
validate certs or CRLs. This is consistent with the notion that the 
bit needs to be set whenever the processing of the object using the 
public key from the cert is constrained by the presence or absence of 
that bit.

>  From what I have read so far, it appears that you believe that the 
>cA bit should be used to indicate if the subject of the certificate 
>is a CA. But, if this is the case, then new-part1-06 still does not 
>accurately reflect your notion of the cA bit. Currently the text 
>states that the cA bit may only be set if the keyCertSign bit or the 
>cRLSign bit in keyUsage is set. However, a CA does more than just 
>issue certificates and CRLs. A CA may have a private key dedicated 
>to signing PKI transaction messages (e.g., certification response, 
>revocation response, proof-of-possession challenge). If a 
>certificate were issued to a CA with its PKI transaction message 
>verification key as the subject public key, neither the keyCertSign 
>nor the cRLSign bit in KeyUsage would be set, but the subject of the 
>certificate would still be a CA.

This is an example where the processing of the signature on the 
signed object is not constrained by the presence or absence of the CA 
bit. I think the text you cite about setting the CA bit ONLY when 
other bits are set should be reviewed; it may be fine as is, but we 
need to decide whether we backed into this characterization or 
whether we mean exactly what it says.


>So, should the cA bit be used to indicate if the certificate subject 
>is a CA or to indicate that the subject public key may be used to 
>verify signatures on certificates and/or CRLs? If the latter, then 
>not all certificates issued to CAs will have the cA bit set.

A fair question. My answer above would say that not all certs 
employed by a CA would have to have the bit set, e.g., because some 
objects signed using a key associated with a CA are employed in 
protocols that do not mandate checking the CA flag.

Steve


Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA13144 for <[e-mail]>; Mon, 7 May 2001 16:13:48 -0700 (PDT)
Received: from COVEY (cpe-24-221-22-72.az.sprintbbd.net [24.221.22.72]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id J0AR5QM7; Mon, 7 May 2001 16:08:17 -0700
From: "Carlin Covey" <[e-mail]>
To: <[e-mail]>
Subject: RE: Certificate Hold (was RE: delta CRLs)
Date: Mon, 7 May 2001 16:14:29 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

I cast a vote for altering the wording of the PKIX profile
to deprecate the use of certificate suspension via CRLs.

-  Carlin Covey
   Cylink Corporation

-----Original Message-----
From: Michael Myers [mailto:[e-mail]]
Sent: Monday, May 07, 2001 3:42 PM
To: [e-mail]
Subject: RE: Certificate Hold (was RE: delta CRLs)


> From: Housley, Russ [mailto:[e-mail]]
> On Monday, May 07, 2001 10:14 AM, Russ asked:
>
> . . .
>
> All:
>
> My view of the question is that three people have voiced a desire to see
> the suspension feature removed, one is asking questions without voicing a
> position, and no one has asked to keep it.  People who have an
> opinion but have not posted it yet please do so.


Towards consensus, I agree to the removal of the CRL-based suspension
feature.  Suspension requirements are still important but PKIX has devised a
means via OCSP of more effectively addressing this need.

Mike



Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA11281 for <[e-mail]>; Mon, 7 May 2001 15:49:54 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <K3SGK5J6>; Mon, 7 May 2001 18:49:26 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Trevor Freeman <[e-mail]>, "David A. Cooper" <[e-mail]>, [e-mail]
Subject: RE: delta CRLs
Date: Mon, 7 May 2001 18:40:16 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D746.B0136EC0"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D746.B0136EC0
Content-Type: text/plain;
	charset="iso-8859-1"

Trevor:

A CA does not use a CRL.  CRL is used by relying party.  A CA can publish
the base based on its policy, e.g., nextUpdate.

All we are saying is that when the delta that says removeFrom CRL is issued,
any base issued at that time or after that time need not have the
certificateHold entry.

-----Original Message-----
From: Trevor Freeman [mailto:[e-mail]]
Sent: Monday, May 07, 2001 2:45 PM
To: David A. Cooper; [e-mail]
Subject: RE: delta CRLs


I Guess I need to clarify my question a little.
I accept that the standard is clear that the remove from CRL must apply
as long as the referenced base had the revocation entry. What is not
clear is when can a CA switch the base no it uses with the delta CRL
safely. Now you could leave that to local policy - which is to say we
give no guidance, or we can clarify a rule at which time a CA must
discontinue use of a base CRL. 

-----Original Message-----
From: David A. Cooper [mailto:[e-mail]] 
Sent: Monday, May 07, 2001 10:57 AM
To: [e-mail]
Subject: RE: delta CRLs

At 04:00 PM 5/4/01 -0700, Trevor Freeman wrote:
>To clarify point three, the delta CRL must include "remove from"
entries
>until the nextupdate time in the referenced base. A CA does not know if
>clients have picked up the base or knot, and to assume they have would
>introduce an error.

Trevor,

new-part1-06 is very clear on when removeFromCRL must appear on a
delta-CRL. A delta-CRL must state "removeFromCRL" for a certificate as
long as the base CRL referenced by the delta was issued before the hold
was removed. The nextUpdate time in the referenced base is irrelevant.
The reason is that there is no requirement that a delta-CRL be applied
to the most recently issued base CRL. Any full CRL whose cRLNumber is
greater than or equal to the BaseCRLNumber specified in the delta-CRL
can be used. The relevant text from new-part1-06 is as follows:

   If a CA supports the certificateHold revocation reason the following
rules must be applied when generating delta CRLs:

         (a) If a certificate was listed as revoked with revocation
reason
         certificateHold on a CRL (either a delta CRL or a CRL that is
         complete for a given scope), whose cRLNumber is n, and the hold
is
         subsequently released, the certificate must be included in all
         delta CRLs issued after the hold is released where the
cRLNumber
         of the referenced base CRL is less than or equal to n. The
         certificate must be listed with revocation reason removeFromCRL
         unless the certificate is subsequently revoked again for one of
         the revocation reasons covered by the delta CRL, in which case
the
         certificate must be listed with the revocation reason
appropriate
         for the subsequent revocation.

         (b) If the certificate was not removed from hold, but was
         permanently revoked, then it must be listed on all subsequent
         delta CRLs where the cRLNumber of the referenced base CRL is
less
         than the cRLNumber of the CRL (either a delta CRL or a CRL that
is
         complete for the given scope) on which the permanent revocation
         notice first appeared.



------_=_NextPart_001_01C0D746.B0136EC0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: delta CRLs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Trevor:</FONT>
</P>

<P><FONT SIZE=3D2>A CA does not use a CRL.&nbsp; CRL is used by relying =
party.&nbsp; A CA can publish the base based on its policy, e.g., =
nextUpdate.</FONT></P>

<P><FONT SIZE=3D2>All we are saying is that when the delta that says =
removeFrom CRL is issued, any base issued at that time or after that =
time need not have the certificateHold entry.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Trevor Freeman [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
rosoft.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, May 07, 2001 2:45 PM</FONT>
<BR><FONT SIZE=3D2>To: David A. Cooper; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: delta CRLs</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>I Guess I need to clarify my question a =
little.</FONT>
<BR><FONT SIZE=3D2>I accept that the standard is clear that the remove =
from CRL must apply</FONT>
<BR><FONT SIZE=3D2>as long as the referenced base had the revocation =
entry. What is not</FONT>
<BR><FONT SIZE=3D2>clear is when can a CA switch the base no it uses =
with the delta CRL</FONT>
<BR><FONT SIZE=3D2>safely. Now you could leave that to local policy - =
which is to say we</FONT>
<BR><FONT SIZE=3D2>give no guidance, or we can clarify a rule at which =
time a CA must</FONT>
<BR><FONT SIZE=3D2>discontinue use of a base CRL. </FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: David A. Cooper [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>] =
</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, May 07, 2001 10:57 AM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: delta CRLs</FONT>
</P>

<P><FONT SIZE=3D2>At 04:00 PM 5/4/01 -0700, Trevor Freeman =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;To clarify point three, the delta CRL must =
include &quot;remove from&quot;</FONT>
<BR><FONT SIZE=3D2>entries</FONT>
<BR><FONT SIZE=3D2>&gt;until the nextupdate time in the referenced =
base. A CA does not know if</FONT>
<BR><FONT SIZE=3D2>&gt;clients have picked up the base or knot, and to =
assume they have would</FONT>
<BR><FONT SIZE=3D2>&gt;introduce an error.</FONT>
</P>

<P><FONT SIZE=3D2>Trevor,</FONT>
</P>

<P><FONT SIZE=3D2>new-part1-06 is very clear on when removeFromCRL must =
appear on a</FONT>
<BR><FONT SIZE=3D2>delta-CRL. A delta-CRL must state =
&quot;removeFromCRL&quot; for a certificate as</FONT>
<BR><FONT SIZE=3D2>long as the base CRL referenced by the delta was =
issued before the hold</FONT>
<BR><FONT SIZE=3D2>was removed. The nextUpdate time in the referenced =
base is irrelevant.</FONT>
<BR><FONT SIZE=3D2>The reason is that there is no requirement that a =
delta-CRL be applied</FONT>
<BR><FONT SIZE=3D2>to the most recently issued base CRL. Any full CRL =
whose cRLNumber is</FONT>
<BR><FONT SIZE=3D2>greater than or equal to the BaseCRLNumber specified =
in the delta-CRL</FONT>
<BR><FONT SIZE=3D2>can be used. The relevant text from new-part1-06 is =
as follows:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; If a CA supports the certificateHold =
revocation reason the following</FONT>
<BR><FONT SIZE=3D2>rules must be applied when generating delta =
CRLs:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (a) =
If a certificate was listed as revoked with revocation</FONT>
<BR><FONT SIZE=3D2>reason</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
certificateHold on a CRL (either a delta CRL or a CRL that is</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
complete for a given scope), whose cRLNumber is n, and the hold</FONT>
<BR><FONT SIZE=3D2>is</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
subsequently released, the certificate must be included in all</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
delta CRLs issued after the hold is released where the</FONT>
<BR><FONT SIZE=3D2>cRLNumber</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of =
the referenced base CRL is less than or equal to n. The</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
certificate must be listed with revocation reason removeFromCRL</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
unless the certificate is subsequently revoked again for one of</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the =
revocation reasons covered by the delta CRL, in which case</FONT>
<BR><FONT SIZE=3D2>the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
certificate must be listed with the revocation reason</FONT>
<BR><FONT SIZE=3D2>appropriate</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for =
the subsequent revocation.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (b) =
If the certificate was not removed from hold, but was</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
permanently revoked, then it must be listed on all subsequent</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
delta CRLs where the cRLNumber of the referenced base CRL is</FONT>
<BR><FONT SIZE=3D2>less</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
than the cRLNumber of the CRL (either a delta CRL or a CRL that</FONT>
<BR><FONT SIZE=3D2>is</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
complete for the given scope) on which the permanent revocation</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
notice first appeared.</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C0D746.B0136EC0--


Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA10650 for <[e-mail]>; Mon, 7 May 2001 15:42:09 -0700 (PDT)
Received: from HEATHERDALE (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f47MgBg11372 for <[e-mail]>; Mon, 7 May 2001 15:42:11 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: RE: Certificate Hold (was RE: delta CRLs)
Date: Mon, 7 May 2001 15:41:49 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-reply-to: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

> From: Housley, Russ [mailto:[e-mail]]
> On Monday, May 07, 2001 10:14 AM, Russ asked:
>
> . . .
>
> All:
>
> My view of the question is that three people have voiced a desire to see
> the suspension feature removed, one is asking questions without voicing a
> position, and no one has asked to keep it.  People who have an
> opinion but have not posted it yet please do so.


Towards consensus, I agree to the removal of the CRL-based suspension
feature.  Suspension requirements are still important but PKIX has devised a
means via OCSP of more effectively addressing this need.

Mike



Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.9.3/8.9.3) with SMTP id NAA01970 for <[e-mail]>; Mon, 7 May 2001 13:48:06 -0700 (PDT)
Received: from 157.54.9.108 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 07 May 2001 11:45:49 -0700 (Pacific Daylight Time)
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 7 May 2001 11:45:27 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 7 May 2001 11:45:26 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 7 May 2001 11:45:07 -0700
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: delta CRLs
X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65
Date: Mon, 7 May 2001 11:45:06 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: delta CRLs
Thread-Index: AcDXH4olws4kV18bThyw356uNfSk0gABZ62A
From: "Trevor Freeman" <[e-mail]>
To: "David A. Cooper" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 07 May 2001 18:45:07.0523 (UTC) FILETIME=[D648C930:01C0D725]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id NAA01971

I Guess I need to clarify my question a little.
I accept that the standard is clear that the remove from CRL must apply
as long as the referenced base had the revocation entry. What is not
clear is when can a CA switch the base no it uses with the delta CRL
safely. Now you could leave that to local policy - which is to say we
give no guidance, or we can clarify a rule at which time a CA must
discontinue use of a base CRL. 

-----Original Message-----
From: David A. Cooper [mailto:[e-mail]] 
Sent: Monday, May 07, 2001 10:57 AM
To: [e-mail]
Subject: RE: delta CRLs

At 04:00 PM 5/4/01 -0700, Trevor Freeman wrote:
>To clarify point three, the delta CRL must include "remove from"
entries
>until the nextupdate time in the referenced base. A CA does not know if
>clients have picked up the base or knot, and to assume they have would
>introduce an error.

Trevor,

new-part1-06 is very clear on when removeFromCRL must appear on a
delta-CRL. A delta-CRL must state "removeFromCRL" for a certificate as
long as the base CRL referenced by the delta was issued before the hold
was removed. The nextUpdate time in the referenced base is irrelevant.
The reason is that there is no requirement that a delta-CRL be applied
to the most recently issued base CRL. Any full CRL whose cRLNumber is
greater than or equal to the BaseCRLNumber specified in the delta-CRL
can be used. The relevant text from new-part1-06 is as follows:

   If a CA supports the certificateHold revocation reason the following
rules must be applied when generating delta CRLs:

         (a) If a certificate was listed as revoked with revocation
reason
         certificateHold on a CRL (either a delta CRL or a CRL that is
         complete for a given scope), whose cRLNumber is n, and the hold
is
         subsequently released, the certificate must be included in all
         delta CRLs issued after the hold is released where the
cRLNumber
         of the referenced base CRL is less than or equal to n. The
         certificate must be listed with revocation reason removeFromCRL
         unless the certificate is subsequently revoked again for one of
         the revocation reasons covered by the delta CRL, in which case
the
         certificate must be listed with the revocation reason
appropriate
         for the subsequent revocation.

         (b) If the certificate was not removed from hold, but was
         permanently revoked, then it must be listed on all subsequent
         delta CRLs where the cRLNumber of the referenced base CRL is
less
         than the cRLNumber of the CRL (either a delta CRL or a CRL that
is
         complete for the given scope) on which the permanent revocation
         notice first appeared.





Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA27162 for <[e-mail]>; Mon, 7 May 2001 12:43:54 -0700 (PDT)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id PAA29959 for <[e-mail]>; Mon, 7 May 2001 15:43:55 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Mon, 07 May 2001 15:43:27 -0400
To: [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: RE: delta CRLs
In-Reply-To: <[e-mail] .windeploy.ntdev.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Trevor,

PKIX states that the CRL referenced as the base CRL must have been issued as a full CRL. One could always use the most recently issued full CRL as the base CRL, but this is not required. In my paper on delta-CRLs (http://csrc.nist.gov/pki/documents/sliding_window.pdf), I argue that a scheme that does not use the most recently issued full CRL as the base is more efficient.

So, a CRL issuer can safely switch the base that it uses whenever it issues a full CRL. However, to be efficient, one should take into account the usage patterns of the relying parties to determine which base should be used for a delta. Since such usage patterns are a local matter, we should leave it to local policy to determine the relationship between full CRLs and delta-CRLs.

Tim Polk has suggested writing a short informational RFC about delta-CRLs. This document could include some sample delta-CRL issuing scenarios that would help to clarify the connections between base CRLs and delta-CRLs.

Dave

At 11:45 AM 5/7/01 -0700, Trevor Freeman wrote:
>I Guess I need to clarify my question a little.
>I accept that the standard is clear that the remove from CRL must apply
>as long as the referenced base had the revocation entry. What is not
>clear is when can a CA switch the base no it uses with the delta CRL
>safely. Now you could leave that to local policy - which is to say we
>give no guidance, or we can clarify a rule at which time a CA must
>discontinue use of a base CRL. 




Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA26244 for <[e-mail]>; Mon, 7 May 2001 12:24:28 -0700 (PDT)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id PAA13284 for <[e-mail]>; Mon, 7 May 2001 15:24:28 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Mon, 07 May 2001 15:03:30 -0400
To: [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: RE: delta CRLs
In-Reply-To: <[e-mail]. com>
References: <[e-mail]. com>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_12064353==_.ALT"

--=====================_12064353==_.ALT
Content-Type: text/plain; charset="us-ascii"

At 01:41 PM 5/7/01 -0400, Housley, Russ wrote:
>I have read section 9 of X.509-2000 (4th Edition v7) three times today.  I cannot find the requirement there.  Where is it hidden?

Russ,

There used to be a requirement in X.509 that whenever a full CRL is issued a delta-CRL must also be issued (if delta-CRLs are being used) and that the full and the delta must have the same CRL number. I don't know why that text was removed. However, there is the requirement that the CRL numbers for a sequence of CRLs issued for a given scope must increase monotonically. The fact that some of the CRLs in the sequence contain the deltaCRLIndicator extension and some do not is irrelevant (just as the presence or absence of the orderedList extension or the authorityKeyIdentifier extension has no affect on the CRL number). There is also the following text in X.509 (2000):

         A CRL that is complete for a given scope, at the current time, can be constructed
         locally in either of the following ways:

                 by retrieving the current dCRL for that scope, and combining it with an issued
                 CRL that is complete for that scope and that has a cRLNumber greater than or
                 equal to the cRLNumber of the base CRL referenced in the dCRL; or

                 by retrieving the current dCRL for that scope and combining it with a locally
                 constructed CRL that is complete for that scope and that was constructed with
                 a dCRL that has a cRLNumber greater than or equal to the cRLNumber of the
                 base CRLreferenced in the current dCRL.


If full CRLs and delta-CRLs were independently numbered, then one could not apply delta-CRLs to locally constructed delta-CRLs as described above.

To demonstrate the problem, I will the example that you provided (see below). In this example, 144 hours (48 x 3) after delta-CRL number 49 was issued, delta-CRL number 193 will be issued. Delta-CRL number 193 will have a BaseCRLNumber of 49. The intention of this would be to specify that delta-CRL number 193 may be combined with full CRL number 49 (which was issued 143 hours after delta-CRL number 49 was issued). 

Suppose, however, that a relying party constructed a CRL locally using full CRL number 1 and delta-CRL number 49. According to the above text from X.509, that relying party could combine delta-CRL number 193 with the CRL locally generated using delta-CRL number 49. The results of combining delta-CRL number 193 with the locally generated CRL would clearly be incorrect. Worse, it would not be obvious to the relying party that the CRL numbers in the delta-CRLs were incorrect and so it would be very difficult for the relying party to determine that the constructed CRL was incorrect.

The only way that one can safely combine a delta-CRL with a locally generated CRL as specified above is if full CRLs and delta-CRLs are numbered consistently. So, while one may argue that the requirement has not been stated with sufficient clarity, it is there.

Dave

  
>>current   revoked
>>time       certificates full CRL                                delta CRL
>>------------------------------------------------------------------------------------------------------------------
>>12:00   {14}            cRLNumber = 1                   cRLNumber = 48
>>                                 thisUpdate = 12:00              thisUpdate = 12:00
>>                                 nextUpdate = 15:00              nextUpdate = 13:00
>>                                                                 BaseCRLNumber = 1
>>                                 CertificateList = {14}          CertificateList = {}
>>
>>
>>13:00   {14, 124}                                       cRLNumber = 49
>>                                                                 thisUpdate = 13:00
>>                                                                 nextUpdate = 14:00
>>                                                                 BaseCRLNumber = 1
>>                                                                 CertificateList = {124}
>>
>>
>>14:00   {14, 124}                                       cRLNumber = 50
>>                                                                 thisUpdate = 14:00
>>                                                                 nextUpdate = 15:00
>>                                                                 BaseCRLNumber = 1
>>                                                                 CertificateList = {124}
>>
>>
>>15:00   {14, 124, 39}   cRLNumber = 2                   cRLNumber = 51
>>                                 thisUpdate = 15:00              thisUpdate = 15:00
>>                                 nextUpdate = 18:00              nextUpdate = 16:00
>>                                                                 BaseCRLNumber = 1
>>                                 CertificateList = {14, 124, 39} CertificateList = {124, 39}
>>
>>
>>16:00   {14, 124, 39,                                   cRLNumber = 52
>>                 67}                                             thisUpdate = 16:00
>>                                                                 nextUpdate = 17:00
>>                                                                 BaseCRLNumber = 2
>>                                                                 CertificateList = {67}
>>
>>
>>17:00   {14, 124, 39,                                   cRLNumber = 53
>>                  67}                                            thisUpdate = 17:00
>>                                                                 nextUpdate = 18:00
>>                                                                 BaseCRLNumber = 2
>>                                                                 CertificateList = {67}
>>
>>
>>18:00   {14, 124, 39,   cRLNumber = 3                   cRLNumber = 54
>>                  67}            thisUpdate = 18:00              thisUpdate = 18:00
>>                                 nextUpdate = 21:00              nextUpdate = 19:00
>>                                                                 BaseCRLNumber = 2
>>                                 CertificateList = {14, 124, 39, CertificateList = {67}
>>                                                  21}
>>
>>
>>19:00   {14, 124, 39,                                   cRLNumber = 55
>>                  67}                                            thisUpdate = 19:00
>>                                                                 nextUpdate = 20:00
>>                                                                 BaseCRLNumber = 3
>>                                                                 CertificateList = {}


--=====================_12064353==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
At 01:41 PM 5/7/01 -0400, Housley, Russ wrote:<br>
<blockquote type=cite cite>I have read section 9 of X.509-2000 (4th
Edition v7) three times today.&nbsp; I cannot find the requirement
there.&nbsp; Where is it hidden?</blockquote><br>
Russ,<br>
<br>
There used to be a requirement in X.509 that whenever a full CRL is
issued a delta-CRL must also be issued (if delta-CRLs are being used) and
that the full and the delta must have the same CRL number. I don't know
why that text was removed. However, there is the requirement that the CRL
numbers for a sequence of CRLs issued for a given scope must increase
monotonically. The fact that some of the CRLs in the sequence contain the
deltaCRLIndicator extension and some do not is irrelevant (just as the
presence or absence of the orderedList extension or the
authorityKeyIdentifier extension has no affect on the CRL number). There
is also the following text in X.509 (2000):<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>A CRL that
is complete for a given scope, at the current time, can be
constructed<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>locally in
either of the following ways:<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>by
retrieving the current dCRL for that scope, and combining it with an
issued<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>CRL
that is complete for that scope and that has a
<font size=2>cRLNumber</font> greater than or<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>equal
to the <font size=2>cRLNumber</font> of the base CRL referenced in the
dCRL; or<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>by
retrieving the current dCRL for that scope and combining it with a
locally<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>constructed
CRL that is complete for that scope and that was constructed with<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>a
dCRL that has a <font size=2>cRLNumber</font> greater than or equal to
the <font size=2>cRLNumber</font> of the<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>base
CRLreferenced in the current dCRL.<br>
<br>
<br>
If full CRLs and delta-CRLs were independently numbered, then one could
not apply delta-CRLs to locally constructed delta-CRLs as described
above.<br>
<br>
To demonstrate the problem, I will the example that you provided (see
below). In this example, 144 hours (48 x 3) after delta-CRL number 49 was
issued, delta-CRL number 193 will be issued. Delta-CRL number 193 will
have a BaseCRLNumber of 49. The intention of this would be to specify
that delta-CRL number 193 may be combined with full CRL number 49 (which
was issued 143 hours after delta-CRL number 49 was issued). <br>
<br>
Suppose, however, that a relying party constructed a CRL locally using
full CRL number 1 and delta-CRL number 49. According to the above text
from X.509, that relying party could combine delta-CRL number 193 with
the CRL locally generated using delta-CRL number 49. The results of
combining delta-CRL number 193 with the locally generated CRL would
clearly be incorrect. Worse, it would not be obvious to the relying party
that the CRL numbers in the delta-CRLs were incorrect and so it would be
very difficult for the relying party to determine that the constructed
CRL was incorrect.<br>
<br>
The only way that one can safely combine a delta-CRL with a locally
generated CRL as specified above is if full CRLs and delta-CRLs are
numbered consistently. So, while one may argue that the requirement has
not been stated with sufficient clarity, it is there.<br>
<br>
Dave<br>
<br>
&nbsp;<br>
<blockquote type=cite cite><blockquote type=cite cite>current&nbsp;&nbsp;
revoked<br>
time&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
certificates<x-tab>&nbsp;</x-tab>full
CRL<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>delta
CRL<br>
------------------------------------------------------------------------------------------------------------------<br>
12:00<x-tab>&nbsp;&nbsp;&nbsp;</x-tab>{14}<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLNumber
=
1<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLNumber
= 48<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>thisUpdate
=
12:00<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>thisUpdate
= 12:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>nextUpdate
=
15:00<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>nextUpdate
= 13:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>BaseCRLNumber
= 1<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>CertificateList
=
{14}<x-tab>&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>CertificateList
= {}<br>
<br>
<br>
13:00<x-tab>&nbsp;&nbsp;&nbsp;</x-tab>{14,
124}<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLNumber
= 49<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>thisUpdate
= 13:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>nextUpdate
= 14:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>BaseCRLNumber
= 1<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>CertificateList
= {124}<br>
<br>
<br>
14:00<x-tab>&nbsp;&nbsp;&nbsp;</x-tab>{14,
124}<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLNumber
= 50<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>thisUpdate
= 14:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>nextUpdate
= 15:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>BaseCRLNumber
= 1<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>CertificateList
= {124}<br>
<br>
<br>
15:00<x-tab>&nbsp;&nbsp;&nbsp;</x-tab>{14, 124,
39}<x-tab>&nbsp;&nbsp;&nbsp;</x-tab>cRLNumber =
2<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLNumber
= 51<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>thisUpdate
=
15:00<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>thisUpdate
= 15:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>nextUpdate
=
18:00<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>nextUpdate
= 16:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>BaseCRLNumber
= 1<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>CertificateList
= {14, 124, 39}<x-tab>&nbsp;</x-tab>CertificateList = {124, 39}<br>
<br>
<br>
16:00<x-tab>&nbsp;&nbsp;&nbsp;</x-tab>{14, 124,
39,<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLNumber
= 52<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>67}<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>thisUpdate
= 16:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>nextUpdate
= 17:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>BaseCRLNumber
= 2<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>CertificateList
= {67}<br>
<br>
<br>
17:00<x-tab>&nbsp;&nbsp;&nbsp;</x-tab>{14, 124,
39,<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLNumber
= 53<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>
67}<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>thisUpdate = 17:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>nextUpdate = 18:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>BaseCRLNumber = 2<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>CertificateList = {67}<br>
<br>
<br>
18:00<x-tab>&nbsp;&nbsp;&nbsp;</x-tab>{14, 124, 39,<x-tab>&nbsp;&nbsp;&nbsp;</x-tab>cRLNumber = 3<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLNumber = 54<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab> 67}<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>thisUpdate = 18:00<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>thisUpdate = 18:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>nextUpdate = 21:00<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>nextUpdate = 19:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>BaseCRLNumber = 2<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>CertificateList = {14, 124, 39,<x-tab>&nbsp;</x-tab>CertificateList = {67}<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab> 21}<br>
<br>
<br>
19:00<x-tab>&nbsp;&nbsp;&nbsp;</x-tab>{14, 124, 39,<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLNumber = 55<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab> 67}<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>thisUpdate = 19:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>nextUpdate = 20:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>BaseCRLNumber = 3<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>CertificateList = {}<br>
</blockquote></blockquote><br>
</html>

--=====================_12064353==_.ALT--



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA22617 for <[e-mail]>; Mon, 7 May 2001 11:19:33 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Mon, 7 May 2001 11:19:41 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Mon, 07 May 2001 11:19:41 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <HR26RJRC>; Mon, 07 May 2001 11:17:47 -0700
Content-return: allowed
Date: Mon, 07 May 2001 11:17:46 -0700
From: Peter Williams <[e-mail]>
Subject: RE: Certificate Hold (was RE: delta CRLs)
To: Tom Gindin <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"

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:[e-mail]]
Sent: Monday, May 07, 2001 5:36 AM
To: Tom Gindin
Cc: [e-mail]
Subject: RE: Certificate Hold (was RE: delta CRLs)


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

At 06:50 PM 5/4/2001 -0400, Tom Gindin wrote:

>      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 <[e-mail]> on 05/04/2001 02:42:33 PM
>
>To:   "Housley, Russ" <[e-mail]>
>cc:   [e-mail]
>Subject:  RE: Certificate Hold  (was RE: delta CRLs)
>
>
>At 1:30 PM -0400 5/4/01, Housley, Russ wrote:
> >Carlin:
> >
> >>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?
> >
> >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


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id LAA21650 for <[e-mail]>; Mon, 7 May 2001 11:09:03 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 7 May 2001 18:08:48 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA09450 for <[e-mail]>; Mon, 7 May 2001 14:09:04 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <JY8NVFCX>; Mon, 7 May 2001 14:09:04 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.20]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JY8NVFCT; Mon, 7 May 2001 14:09:01 -0400
From: "Housley, Russ" <[e-mail]>
To: Tim Polk <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 07 May 2001 13:38:00 -0400
Subject: RE: delta CRLs
In-Reply-To: <[e-mail]>
References: <[e-mail]. com> <[e-mail] .windeploy.ntdev.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Tim:

>>I have updated the figure that David Cooper posted last week.  I think 
>>that the update illustrates Trevor's point.  The full CRL and the delta 
>>CRL can have two independent monotonically increasing sequence of 
>>integers and still meet all of the PKIX and X.509-2000 requirements.
>
>I expect you are correct; the description of CRL numbering currently in 
>PKIX may permit this scheme.  However, I think we should tighten the wording.
>
>>The numbering scheme that David proposed seems much easier to implement, 
>>but I cannot find any text that the scheme below violates.
>>
>>I do not know what to call the full CRL at 13:00 that is generated by 
>>merging base CRL 1 and delta CRL 49...
>
>I believe that is the problem with Trevor's proposal.  The CRL number of 
>the constructed CRL does not help you determine whether or not a future 
>delta can be applied safely to the constructed CRL.
>
>The most glaring example of this is the delta CRL number 51.  When it is 
>combined with full CRL number 1, you actually obtain full CRL number 
>2.  However, at 16:00 the CA issues delta 52, which points to full CRL 2 
>as a base.  Using Trevor's numbering scheme, there is no way to be sure 
>that CRL 1 and delta 51 are the same CRL as the full CRL with CRL number 
>2.  As a result, at 16:00 the relying party must download both full CRL 
>number 2 and delta number 52.
>
>That is the sort of behavior we want to avoid.

If a common number sequence is used, then you can avoid ever fetching 
another base CRL.

If separate number sequence is used, then you will have to periodically 
fetch base CRLs.

To avoid this behavior, PKIX would have to mandate the use of a single CRL 
sequence number space for the full CRLs and delta CRLs that cover the same 
scope.  This seems like a very reasonable thing for the PKIX profile to do.

Do we have consensus on this idea?

Russ


Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA20491 for <[e-mail]>; Mon, 7 May 2001 10:57:49 -0700 (PDT)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id NAA01066 for <[e-mail]>; Mon, 7 May 2001 13:57:50 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Mon, 07 May 2001 13:57:22 -0400
To: [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: RE: delta CRLs
In-Reply-To: <[e-mail] .windeploy.ntdev.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 04:00 PM 5/4/01 -0700, Trevor Freeman wrote:
>To clarify point three, the delta CRL must include "remove from" entries
>until the nextupdate time in the referenced base. A CA does not know if
>clients have picked up the base or knot, and to assume they have would
>introduce an error.

Trevor,

new-part1-06 is very clear on when removeFromCRL must appear on a delta-CRL. A delta-CRL must state "removeFromCRL" for a certificate as long as the base CRL referenced by the delta was issued before the hold was removed. The nextUpdate time in the referenced base is irrelevant. The reason is that there is no requirement that a delta-CRL be applied to the most recently issued base CRL. Any full CRL whose cRLNumber is greater than or equal to the BaseCRLNumber specified in the delta-CRL can be used. The relevant text from new-part1-06 is as follows:

   If a CA supports the certificateHold revocation reason the following rules must be applied when generating delta CRLs:

         (a) If a certificate was listed as revoked with revocation reason
         certificateHold on a CRL (either a delta CRL or a CRL that is
         complete for a given scope), whose cRLNumber is n, and the hold is
         subsequently released, the certificate must be included in all
         delta CRLs issued after the hold is released where the cRLNumber
         of the referenced base CRL is less than or equal to n. The
         certificate must be listed with revocation reason removeFromCRL
         unless the certificate is subsequently revoked again for one of
         the revocation reasons covered by the delta CRL, in which case the
         certificate must be listed with the revocation reason appropriate
         for the subsequent revocation.

         (b) If the certificate was not removed from hold, but was
         permanently revoked, then it must be listed on all subsequent
         delta CRLs where the cRLNumber of the referenced base CRL is less
         than the cRLNumber of the CRL (either a delta CRL or a CRL that is
         complete for the given scope) on which the permanent revocation
         notice first appeared.





Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA18293 for <[e-mail]>; Mon, 7 May 2001 10:33:35 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <K3SGKVZB>; Mon, 7 May 2001 13:33:06 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: [e-mail]
Subject: RE: delta CRLs
Date: Mon, 7 May 2001 13:23:56 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D71A.7EA618F0"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D71A.7EA618F0
Content-Type: text/plain;
	charset="iso-8859-1"

I agree with Dave Cooper.

I have the same understanding of how X.509 is supposed to work.

-----Original Message-----
From: David A. Cooper [mailto:[e-mail]]
Sent: Monday, May 07, 2001 1:26 PM
To: [e-mail]
Subject: RE: delta CRLs


Russ, Trevor,

The CRL numbers of full CRLs and delta-CRLs are not independent. The only
differences between a full CRL and a delta-CRL are the inclusion or
exclusion of the deltaCRLIndicator extension and the contents of
revokedCertificates. Otherwise, there should be no difference between a
delta-CRL and a full CRL issued for the same scope. The cRLNumber for a
delta-CRL should be the same as the cRLNumber that would have been assigned
to a full CRL issued at the same time. In fact, new-part1-06 states:

         When a conforming CA issues a delta CRL, the CA MUST also issue a
CRL
         that is complete for the given scope.  Both the delta CRL and the
         complete CRL MUST include the CRL number extension (see sec.
5.2.3).
         The CRL number extension in the delta CRL and the complete CRL MUST
         contain the same value.  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.

The text explicitly states that when a delta-CRL and full CRL are issued at
the same time, the CRL numbers of both CRLs MUST be the same. The text also
states that a locally constructed CRL takes on the CRL number of the
delta-CRL used in its construction and that this constructed CRL may be used
in place of an issued CRL :

         An application can construct a CRL that is complete for a given
         scope, at the current time, in either of the following ways:

                 (a) by retrieving the current delta CRL for that scope, and
                 combining it with an issued CRL that is complete for that
scope
                 and that has a cRLNumber greater than or equal to the
cRLNumber of
                 the base CRL referenced in the delta CRL; or

                 (b) by retrieving the current delta CRL for that scope and
                 combining it with a locally constructed CRL whose cRLNumber
is
                 greater than or equal to the cRLNumber of the base CRL
referenced
                 in the current delta CRL.

         The constructed CRL has the CRL number specified in the CRL number
         extension found in the delta CRL used in its construction.

If the CRL number of the delta-CRLs and full CRLs were independent, one
could not apply a delta-CRL to a locally constructed CRL as is described in
(b) above. Perhaps the requirement to coordinate CRL numbers between full
and delta-CRLs is not as clear now that the requirement to issue a full CRL
with every delta has been deleted. If that is the case, then some text
should be added to make sure that this point is clear.

Dave

At 11:59 AM 5/7/01 -0400, Housley, Russ wrote:
>I have updated the figure that David Cooper posted last week.  I think that
the update illustrates Trevor's point.  The full CRL and the delta CRL can
have two independent monotonically increasing sequence of integers and still
meet all of the PKIX and X.509-2000 requirements.


------_=_NextPart_001_01C0D71A.7EA618F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: delta CRLs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I agree with Dave Cooper.</FONT>
</P>

<P><FONT SIZE=3D2>I have the same understanding of how X.509 is =
supposed to work.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: David A. Cooper [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Monday, May 07, 2001 1:26 PM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: delta CRLs</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Russ, Trevor,</FONT>
</P>

<P><FONT SIZE=3D2>The CRL numbers of full CRLs and delta-CRLs are not =
independent. The only differences between a full CRL and a delta-CRL =
are the inclusion or exclusion of the deltaCRLIndicator extension and =
the contents of revokedCertificates. Otherwise, there should be no =
difference between a delta-CRL and a full CRL issued for the same =
scope. The cRLNumber for a delta-CRL should be the same as the =
cRLNumber that would have been assigned to a full CRL issued at the =
same time. In fact, new-part1-06 states:</FONT></P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; When =
a conforming CA issues a delta CRL, the CA MUST also issue a CRL</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
that is complete for the given scope.&nbsp; Both the delta CRL and =
the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
complete CRL MUST include the CRL number extension (see sec. =
5.2.3).</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The =
CRL number extension in the delta CRL and the complete CRL MUST</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
contain the same value.&nbsp; When a delta CRL is issued, it MUST =
cover</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the =
same set of reasons and same set of certificates that were</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
covered by the base CRL it references.</FONT>
</P>

<P><FONT SIZE=3D2>The text explicitly states that when a delta-CRL and =
full CRL are issued at the same time, the CRL numbers of both CRLs MUST =
be the same. The text also states that a locally constructed CRL takes =
on the CRL number of the delta-CRL used in its construction and that =
this constructed CRL may be used in place of an issued CRL :</FONT></P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; An =
application can construct a CRL that is complete for a given</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
scope, at the current time, in either of the following ways:</FONT>
</P>

<P><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (a) by retrieving the current delta =
CRL for that scope, and</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; combining it with an issued CRL that =
is complete for that scope</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and that has a cRLNumber greater than =
or equal to the cRLNumber of</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the base CRL referenced in the delta =
CRL; or</FONT>
</P>

<P><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (b) by retrieving the current delta =
CRL for that scope and</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; combining it with a locally =
constructed CRL whose cRLNumber is</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; greater than or equal to the =
cRLNumber of the base CRL referenced</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in the current delta CRL.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The =
constructed CRL has the CRL number specified in the CRL number</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
extension found in the delta CRL used in its construction.</FONT>
</P>

<P><FONT SIZE=3D2>If the CRL number of the delta-CRLs and full CRLs =
were independent, one could not apply a delta-CRL to a locally =
constructed CRL as is described in (b) above. Perhaps the requirement =
to coordinate CRL numbers between full and delta-CRLs is not as clear =
now that the requirement to issue a full CRL with every delta has been =
deleted. If that is the case, then some text should be added to make =
sure that this point is clear.</FONT></P>

<P><FONT SIZE=3D2>Dave</FONT>
</P>

<P><FONT SIZE=3D2>At 11:59 AM 5/7/01 -0400, Housley, Russ wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;I have updated the figure that David Cooper =
posted last week.&nbsp; I think that the update illustrates Trevor's =
point.&nbsp; The full CRL and the delta CRL can have two independent =
monotonically increasing sequence of integers and still meet all of the =
PKIX and X.509-2000 requirements.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01C0D71A.7EA618F0--


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id KAA17645 for <[e-mail]>; Mon, 7 May 2001 10:28:27 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 7 May 2001 17:28:12 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id NAA06100 for <[e-mail]>; Mon, 7 May 2001 13:28:28 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <JY8NV1KX>; Mon, 7 May 2001 13:28:28 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.113]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JY8NV1KW; Mon, 7 May 2001 13:28:26 -0400
From: "Housley, Russ" <[e-mail]>
To: Tom Gindin <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 07 May 2001 13:13:39 -0400
Subject: RE: Certificate Hold (was RE: delta CRLs)
In-Reply-To: <[e-mail] m.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Tom:

I have not been able to make myself clear.  Perhaps because you keep 
looking to simple authentication applications.  My hope is that the PKIX 
profile will readily meet the needs of these relatively straightforward 
applications and also support the more demanding needs of applications 
where non-repudiation is needed.

All:

My view of the question is that three people have voiced a desire to see 
the suspension feature removed, one is asking questions without voicing a 
position, and no one has asked to keep it.  People who have an opinion but 
have not posted it yet please do so.

Russ

At 11:32 AM 5/7/2001 -0400, Tom Gindin wrote:

>      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 <[e-mail]> on 05/05/2001 07:58:09 AM
>
>To:   Tom Gindin/Watson/IBM@IBMUS, Stephen Kent <[e-mail]>
>cc:   "Housley, Russ" <[e-mail]>, [e-mail]
>Subject:  RE: Certificate Hold (was RE: delta CRLs)
>
>
>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:[e-mail]]
>Sent: Friday, May 04, 2001 6:50 PM
>To: Stephen Kent
>Cc: Housley, Russ; [e-mail]
>Subject: RE: Certificate Hold (was RE: delta CRLs)
>
>
>
>
>
>
>      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 <[e-mail]> on 05/04/2001 02:42:33 PM
>
>
>To:   "Housley, Russ" <[e-mail]>
>cc:   [e-mail]
>Subject:  RE: Certificate Hold  (was RE: delta CRLs)
>
>
>
>
>
>At 1:30 PM -0400 5/4/01, Housley, Russ wrote:
> >Carlin:
> >
> >>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?
> >
> >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


Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA17365 for <[e-mail]>; Mon, 7 May 2001 10:27:30 -0700 (PDT)
Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id f47HR1v06392 for <[e-mail]>; Mon, 7 May 2001 10:27:01 -0700 (PDT)
Received: from netscape.com ([192.18.121.215]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GCZ75103.CCD; Mon, 7 May 2001 10:27:01 -0700 
Message-ID: <[e-mail]>
Date: Mon, 07 May 2001 10:26:58 -0700
From: [e-mail] (Terry Hayes)
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9+) Gecko/20010326
X-Accept-Language: en
MIME-Version: 1.0
To: Tim Polk <[e-mail]>
CC: "Housley Russ" <[e-mail]>, [e-mail]
Subject: Re: delta CRLs
References: <[e-mail] .windeploy.ntdev.microsoft.com> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

I agree with Tim on all points.  He points out exactly the example to 
show why this numbering scheme is wrong.  The numbering of the deltas 
*must* correspond with the numbering of the base CRLs.

Terry

Tim Polk wrote:

> Russ,
>
> At 11:59 AM 5/7/01 -0400, you wrote:
>
>> I have updated the figure that David Cooper posted last week.  I 
>> think that the update illustrates Trevor's point.  The full CRL and 
>> the delta CRL can have two independent monotonically increasing 
>> sequence of integers and still meet all of the PKIX and X.509-2000 
>> requirements.
>
>
> I expect you are correct; the description of CRL numbering currently 
> in PKIX may permit this scheme.  However, I think we should tighten 
> the wording.
>
>> The numbering scheme that David proposed seems much easier to 
>> implement, but I cannot find any text that the scheme below violates.
>>
>> I do not know what to call the full CRL at 13:00 that is generated by 
>> merging base CRL 1 and delta CRL 49...
>
>
> I believe that is the problem with Trevor's proposal.  The CRL number 
> of the constructed CRL does not help you determine whether or not a 
> future delta can be applied safely to the constructed CRL.
>
> The most glaring example of this is the delta CRL number 51.  When it 
> is combined with full CRL number 1, you actually obtain full CRL 
> number 2.  However, at 16:00 the CA issues delta 52, which points to 
> full CRL 2 as a base.  Using Trevor's numbering scheme, there is no 
> way to be sure that CRL 1 and delta 51 are the same CRL as the full 
> CRL with CRL number 2.  As a result, at 16:00 the relying party must 
> download both full CRL number 2 and delta number 52.
>
> That is the sort of behavior we want to avoid.
>
> Tim
>
>> Russ
>>
>>
>> = = = = = = = = = =
>>
>>
>> current   revoked
>> time       certificates full CRL                        delta CRL
>> ------------------------------------------------------------
>> 12:00           {14}            cRLNumber = 1                   
>> cRLNumber = 48
>>                                 thisUpdate = 12:00              
>> thisUpdate = 12:00
>>                                 nextUpdate = 15:00              
>> nextUpdate = 13:00
>>
>> BaseCRLNumber = 1
>>                                 CertificateList = {14}          
>> CertificateList = {}
>>
>>
>> 13:00           {14, 124}                                       
>> cRLNumber = 49
>>
>> thisUpdate = 13:00
>>
>> nextUpdate = 14:00
>>
>> BaseCRLNumber = 1
>>
>> CertificateList = {124}
>>
>>
>> 14:00           {14, 124}                                       
>> cRLNumber = 50
>>
>> thisUpdate = 14:00
>>
>> nextUpdate = 15:00
>>
>> BaseCRLNumber = 1
>>
>> CertificateList = {124}
>>
>>
>> 15:00           {14, 124, 39}   cRLNumber = 2                   
>> cRLNumber = 51
>>                                 thisUpdate = 15:00              
>> thisUpdate = 15:00
>>                                 nextUpdate = 18:00              
>> nextUpdate = 16:00
>>
>> BaseCRLNumber = 1
>>                                 CertificateList = {14, 124, 39} 
>> CertificateList = {124, 39}
>>
>>
>> 16:00           {14, 124, 39,                                   
>> cRLNumber = 52
>>                 67} thisUpdate = 16:00
>>
>> nextUpdate = 17:00
>>
>> BaseCRLNumber = 2
>>
>> CertificateList = {67}
>>
>>
>> 17:00           {14, 124, 39,                                   
>> cRLNumber = 53
>>                 67} thisUpdate = 17:00
>>
>> nextUpdate = 18:00
>>
>> BaseCRLNumber = 2
>>
>> CertificateList = {67}
>>
>>
>> 18:00           {14, 124, 39,   cRLNumber = 3                   
>> cRLNumber = 54
>>                 67}             thisUpdate = 18:00              
>> thisUpdate = 18:00
>>                                 nextUpdate = 21:00              
>> nextUpdate = 19:00
>>
>> BaseCRLNumber = 2
>>                                 CertificateList = {14, 124, 39, 
>> CertificateList = {67}
>>                                                          21}
>>
>>
>> 19:00           {14, 124, 39,                                   
>> cRLNumber = 55
>>                 67} thisUpdate = 19:00
>>
>> nextUpdate = 20:00
>>
>> BaseCRLNumber = 3
>>
>> CertificateList = {}
>>
>





Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA17063 for <[e-mail]>; Mon, 7 May 2001 10:26:23 -0700 (PDT)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id NAA05496 for <[e-mail]>; Mon, 7 May 2001 13:26:23 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Mon, 07 May 2001 13:25:54 -0400
To: [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: RE: delta CRLs
In-Reply-To: <[e-mail]. com>
References: <[e-mail] .windeploy.ntdev.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Russ, Trevor,

The CRL numbers of full CRLs and delta-CRLs are not independent. The only differences between a full CRL and a delta-CRL are the inclusion or exclusion of the deltaCRLIndicator extension and the contents of revokedCertificates. Otherwise, there should be no difference between a delta-CRL and a full CRL issued for the same scope. The cRLNumber for a delta-CRL should be the same as the cRLNumber that would have been assigned to a full CRL issued at the same time. In fact, new-part1-06 states:

         When a conforming CA issues a delta CRL, the CA MUST also issue a CRL
         that is complete for the given scope.  Both the delta CRL and the
         complete CRL MUST include the CRL number extension (see sec. 5.2.3).
         The CRL number extension in the delta CRL and the complete CRL MUST
         contain the same value.  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.

The text explicitly states that when a delta-CRL and full CRL are issued at the same time, the CRL numbers of both CRLs MUST be the same. The text also states that a locally constructed CRL takes on the CRL number of the delta-CRL used in its construction and that this constructed CRL may be used in place of an issued CRL :

         An application can construct a CRL that is complete for a given
         scope, at the current time, in either of the following ways:

                 (a) by retrieving the current delta CRL for that scope, and
                 combining it with an issued CRL that is complete for that scope
                 and that has a cRLNumber greater than or equal to the cRLNumber of
                 the base CRL referenced in the delta CRL; or

                 (b) by retrieving the current delta CRL for that scope and
                 combining it with a locally constructed CRL whose cRLNumber is
                 greater than or equal to the cRLNumber of the base CRL referenced
                 in the current delta CRL.

         The constructed CRL has the CRL number specified in the CRL number
         extension found in the delta CRL used in its construction.

If the CRL number of the delta-CRLs and full CRLs were independent, one could not apply a delta-CRL to a locally constructed CRL as is described in (b) above. Perhaps the requirement to coordinate CRL numbers between full and delta-CRLs is not as clear now that the requirement to issue a full CRL with every delta has been deleted. If that is the case, then some text should be added to make sure that this point is clear.

Dave

At 11:59 AM 5/7/01 -0400, Housley, Russ wrote:
>I have updated the figure that David Cooper posted last week.  I think that the update illustrates Trevor's point.  The full CRL and the delta CRL can have two independent monotonically increasing sequence of integers and still meet all of the PKIX and X.509-2000 requirements.




Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA16154 for <[e-mail]>; Mon, 7 May 2001 10:18:45 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <K3SGKVPW>; Mon, 7 May 2001 13:18:16 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Tim Polk <[e-mail]>, "Housley, Russ" <[e-mail]>, [e-mail]
Subject: RE: delta CRLs
Date: Mon, 7 May 2001 13:09:05 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D718.6C04BA50"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D718.6C04BA50
Content-Type: text/plain;
	charset="iso-8859-1"

Tim and Russ:

The base and delta share the SAME NUMBER SPACE.  Your example is like a work
of art that is not REALIZABLE in real word.

-----Original Message-----
From: Tim Polk [mailto:[e-mail]]
Sent: Monday, May 07, 2001 1:06 PM
To: Housley, Russ; [e-mail]
Subject: RE: delta CRLs


Russ,

At 11:59 AM 5/7/01 -0400, you wrote:
>I have updated the figure that David Cooper posted last week.  I think 
>that the update illustrates Trevor's point.  The full CRL and the delta 
>CRL can have two independent monotonically increasing sequence of integers 
>and still meet all of the PKIX and X.509-2000 requirements.

I expect you are correct; the description of CRL numbering currently in 
PKIX may permit this scheme.  However, I think we should tighten the
wording.

>The numbering scheme that David proposed seems much easier to implement, 
>but I cannot find any text that the scheme below violates.
>
>I do not know what to call the full CRL at 13:00 that is generated by 
>merging base CRL 1 and delta CRL 49...

I believe that is the problem with Trevor's proposal.  The CRL number of 
the constructed CRL does not help you determine whether or not a future 
delta can be applied safely to the constructed CRL.

The most glaring example of this is the delta CRL number 51.  When it is 
combined with full CRL number 1, you actually obtain full CRL number 
2.  However, at 16:00 the CA issues delta 52, which points to full CRL 2 as 
a base.  Using Trevor's numbering scheme, there is no way to be sure that 
CRL 1 and delta 51 are the same CRL as the full CRL with CRL number 2.  As 
a result, at 16:00 the relying party must download both full CRL number 2 
and delta number 52.

That is the sort of behavior we want to avoid.

Tim

>Russ
>
>
>= = = = = = = = = =
>
>
>current   revoked
>time       certificates full CRL                        delta CRL
>------------------------------------------------------------
>12:00           {14}            cRLNumber = 1                   cRLNumber =
48
>                                 thisUpdate = 
> 12:00              thisUpdate = 12:00
>                                 nextUpdate = 
> 15:00              nextUpdate = 13:00
> 
>BaseCRLNumber = 1
>                                 CertificateList = 
> {14}          CertificateList = {}
>
>
>13:00           {14, 124}                                       cRLNumber =
49
> 
>thisUpdate = 13:00
> 
>nextUpdate = 14:00
> 
>BaseCRLNumber = 1
> 
>CertificateList = {124}
>
>
>14:00           {14, 124}                                       cRLNumber =
50
> 
>thisUpdate = 14:00
> 
>nextUpdate = 15:00
> 
>BaseCRLNumber = 1
> 
>CertificateList = {124}
>
>
>15:00           {14, 124, 39}   cRLNumber = 2                   cRLNumber =
51
>                                 thisUpdate = 
> 15:00              thisUpdate = 15:00
>                                 nextUpdate = 
> 18:00              nextUpdate = 16:00
> 
>BaseCRLNumber = 1
>                                 CertificateList = {14, 124, 39} 
> CertificateList = {124, 39}
>
>
>16:00           {14, 124, 39,                                   cRLNumber =
52
>                 67} 
> thisUpdate = 16:00
> 
>nextUpdate = 17:00
> 
>BaseCRLNumber = 2
> 
>CertificateList = {67}
>
>
>17:00           {14, 124, 39,                                   cRLNumber =
53
>                 67} 
> thisUpdate = 17:00
> 
>nextUpdate = 18:00
> 
>BaseCRLNumber = 2
> 
>CertificateList = {67}
>
>
>18:00           {14, 124, 39,   cRLNumber = 3                   cRLNumber =
54
>                 67}             thisUpdate = 
> 18:00              thisUpdate = 18:00
>                                 nextUpdate = 
> 21:00              nextUpdate = 19:00
> 
>BaseCRLNumber = 2
>                                 CertificateList = {14, 124, 39, 
> CertificateList = {67}
>                                                          21}
>
>
>19:00           {14, 124, 39,                                   cRLNumber =
55
>                 67} 
> thisUpdate = 19:00
> 
>nextUpdate = 20:00
> 
>BaseCRLNumber = 3
> 
>CertificateList = {}
>

------_=_NextPart_001_01C0D718.6C04BA50
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: delta CRLs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Tim and Russ:</FONT>
</P>

<P><FONT SIZE=3D2>The base and delta share the SAME NUMBER SPACE.&nbsp; =
Your example is like a work of art that is not REALIZABLE in real =
word.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Tim Polk [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, May 07, 2001 1:06 PM</FONT>
<BR><FONT SIZE=3D2>To: Housley, Russ; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: delta CRLs</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Russ,</FONT>
</P>

<P><FONT SIZE=3D2>At 11:59 AM 5/7/01 -0400, you wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;I have updated the figure that David Cooper =
posted last week.&nbsp; I think </FONT>
<BR><FONT SIZE=3D2>&gt;that the update illustrates Trevor's =
point.&nbsp; The full CRL and the delta </FONT>
<BR><FONT SIZE=3D2>&gt;CRL can have two independent monotonically =
increasing sequence of integers </FONT>
<BR><FONT SIZE=3D2>&gt;and still meet all of the PKIX and X.509-2000 =
requirements.</FONT>
</P>

<P><FONT SIZE=3D2>I expect you are correct; the description of CRL =
numbering currently in </FONT>
<BR><FONT SIZE=3D2>PKIX may permit this scheme.&nbsp; However, I think =
we should tighten the wording.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;The numbering scheme that David proposed seems =
much easier to implement, </FONT>
<BR><FONT SIZE=3D2>&gt;but I cannot find any text that the scheme below =
violates.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;I do not know what to call the full CRL at 13:00 =
that is generated by </FONT>
<BR><FONT SIZE=3D2>&gt;merging base CRL 1 and delta CRL 49...</FONT>
</P>

<P><FONT SIZE=3D2>I believe that is the problem with Trevor's =
proposal.&nbsp; The CRL number of </FONT>
<BR><FONT SIZE=3D2>the constructed CRL does not help you determine =
whether or not a future </FONT>
<BR><FONT SIZE=3D2>delta can be applied safely to the constructed =
CRL.</FONT>
</P>

<P><FONT SIZE=3D2>The most glaring example of this is the delta CRL =
number 51.&nbsp; When it is </FONT>
<BR><FONT SIZE=3D2>combined with full CRL number 1, you actually obtain =
full CRL number </FONT>
<BR><FONT SIZE=3D2>2.&nbsp; However, at 16:00 the CA issues delta 52, =
which points to full CRL 2 as </FONT>
<BR><FONT SIZE=3D2>a base.&nbsp; Using Trevor's numbering scheme, there =
is no way to be sure that </FONT>
<BR><FONT SIZE=3D2>CRL 1 and delta 51 are the same CRL as the full CRL =
with CRL number 2.&nbsp; As </FONT>
<BR><FONT SIZE=3D2>a result, at 16:00 the relying party must download =
both full CRL number 2 </FONT>
<BR><FONT SIZE=3D2>and delta number 52.</FONT>
</P>

<P><FONT SIZE=3D2>That is the sort of behavior we want to avoid.</FONT>
</P>

<P><FONT SIZE=3D2>Tim</FONT>
</P>

<P><FONT SIZE=3D2>&gt;Russ</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;=3D =3D =3D =3D =3D =3D =3D =3D =3D =3D</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;current&nbsp;&nbsp; revoked</FONT>
<BR><FONT SIZE=3D2>&gt;time&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
certificates full =
CRL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
delta CRL</FONT>
<BR><FONT =
SIZE=3D2>&gt;-----------------------------------------------------------=
-</FONT>
<BR><FONT =
SIZE=3D2>&gt;12:00&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; =
{14}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
cRLNumber =3D =
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cRLNumber =3D 48</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
thisUpdate =3D </FONT>
<BR><FONT SIZE=3D2>&gt; =
12:00&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp; thisUpdate =3D 12:00</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
nextUpdate =3D </FONT>
<BR><FONT SIZE=3D2>&gt; =
15:00&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp; nextUpdate =3D 13:00</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;BaseCRLNumber =3D 1</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
CertificateList =3D </FONT>
<BR><FONT SIZE=3D2>&gt; =
{14}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
CertificateList =3D {}</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT =
SIZE=3D2>&gt;13:00&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; {14, =
124}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; cRLNumber =3D 49</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;thisUpdate =3D 13:00</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;nextUpdate =3D 14:00</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;BaseCRLNumber =3D 1</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;CertificateList =3D {124}</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT =
SIZE=3D2>&gt;14:00&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; {14, =
124}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; cRLNumber =3D 50</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;thisUpdate =3D 14:00</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;nextUpdate =3D 15:00</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;BaseCRLNumber =3D 1</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;CertificateList =3D {124}</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT =
SIZE=3D2>&gt;15:00&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; {14, 124, 39}&nbsp;&nbsp; cRLNumber =3D =
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cRLNumber =3D 51</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
thisUpdate =3D </FONT>
<BR><FONT SIZE=3D2>&gt; =
15:00&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp; thisUpdate =3D 15:00</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
nextUpdate =3D </FONT>
<BR><FONT SIZE=3D2>&gt; =
18:00&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp; nextUpdate =3D 16:00</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;BaseCRLNumber =3D 1</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
CertificateList =3D {14, 124, 39} </FONT>
<BR><FONT SIZE=3D2>&gt; CertificateList =3D {124, 39}</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT =
SIZE=3D2>&gt;16:00&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; {14, 124, =
39,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
cRLNumber =3D 52</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 67} </FONT>
<BR><FONT SIZE=3D2>&gt; thisUpdate =3D 16:00</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;nextUpdate =3D 17:00</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;BaseCRLNumber =3D 2</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;CertificateList =3D {67}</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT =
SIZE=3D2>&gt;17:00&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; {14, 124, =
39,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
cRLNumber =3D 53</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 67} </FONT>
<BR><FONT SIZE=3D2>&gt; thisUpdate =3D 17:00</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;nextUpdate =3D 18:00</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;BaseCRLNumber =3D 2</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;CertificateList =3D {67}</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT =
SIZE=3D2>&gt;18:00&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; {14, 124, 39,&nbsp;&nbsp; cRLNumber =3D =
3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cRLNumber =3D 54</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
67}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; thisUpdate =3D </FONT>
<BR><FONT SIZE=3D2>&gt; =
18:00&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp; thisUpdate =3D 18:00</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
nextUpdate =3D </FONT>
<BR><FONT SIZE=3D2>&gt; =
21:00&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp; nextUpdate =3D 19:00</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;BaseCRLNumber =3D 2</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
CertificateList =3D {14, 124, 39, </FONT>
<BR><FONT SIZE=3D2>&gt; CertificateList =3D {67}</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
21}</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT =
SIZE=3D2>&gt;19:00&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; {14, 124, =
39,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
cRLNumber =3D 55</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 67} </FONT>
<BR><FONT SIZE=3D2>&gt; thisUpdate =3D 19:00</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;nextUpdate =3D 20:00</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;BaseCRLNumber =3D 3</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;CertificateList =3D {}</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0D718.6C04BA50--


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA15743 for <[e-mail]>; Mon, 7 May 2001 10:16:30 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <K3SGKV3G>; Mon, 7 May 2001 13:16:01 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: "Housley, Russ" <[e-mail]>, [e-mail]
Subject: RE: delta CRLs
Date: Mon, 7 May 2001 13:06:50 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D718.1B758F10"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D718.1B758F10
Content-Type: text/plain;
	charset="iso-8859-1"

Russ:
 
What is stated below in your e-mail is INCORRECT.  I just spoke with David
Cooper.  He is going to make a posting again.  What I have said on this list
happens to be (by accident) correct.  And that is the base CRL and delta CRL
share the number from the same space and the number is monotonically
increasing.
 
We have added Stream Identifier feature to allow to differentiate (only if
the CA wishes) among indirect CRL, partitioned CRL etc.
 
Thus, a base and delta must have the same stream identifier in order to be
merged.  If the delta thisUpdate > base thisUpdate, delta CRL Number > base
CRL Number (for the same or no stream identifier).  This rule is invariant
except for number wrapping.
 
 
-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Monday, May 07, 2001 12:00 PM
To: [e-mail]
Subject: RE: delta CRLs


I have updated the figure that David Cooper posted last week.  I think that
the update illustrates Trevor's point.  The full CRL and the delta CRL can
have two independent monotonically increasing sequence of integers and still
meet all of the PKIX and X.509-2000 requirements.

The numbering scheme that David proposed seems much easier to implement, but
I cannot find any text that the scheme below violates.

I do not know what to call the full CRL at 13:00 that is generated by
merging base CRL 1 and delta CRL 49...

Russ


= = = = = = = = = = 


current   revoked
time       certificates full CRL                        delta CRL
------------------------------------------------------------
12:00           {14}            cRLNumber = 1                   cRLNumber =
48
                                thisUpdate = 12:00              thisUpdate =
12:00
                                nextUpdate = 15:00              nextUpdate =
13:00
 
BaseCRLNumber = 1
                                CertificateList = {14}
CertificateList = {}


13:00           {14, 124}                                       cRLNumber =
49
                                                                thisUpdate =
13:00
                                                                nextUpdate =
14:00
 
BaseCRLNumber = 1
 
CertificateList = {124}


14:00           {14, 124}                                       cRLNumber =
50
                                                                thisUpdate =
14:00
                                                                nextUpdate =
15:00
 
BaseCRLNumber = 1
 
CertificateList = {124}


15:00           {14, 124, 39}   cRLNumber = 2                   cRLNumber =
51
                                thisUpdate = 15:00              thisUpdate =
15:00
                                nextUpdate = 18:00              nextUpdate =
16:00
 
BaseCRLNumber = 1
                                CertificateList = {14, 124, 39}
CertificateList = {124, 39}


16:00           {14, 124, 39,                                   cRLNumber =
52
                67}                                             thisUpdate =
16:00
                                                                nextUpdate =
17:00
 
BaseCRLNumber = 2
 
CertificateList = {67}


17:00           {14, 124, 39,                                   cRLNumber =
53
                67}                                             thisUpdate =
17:00
                                                                nextUpdate =
18:00
 
BaseCRLNumber = 2
 
CertificateList = {67}


18:00           {14, 124, 39,   cRLNumber = 3                   cRLNumber =
54
                67}             thisUpdate = 18:00              thisUpdate =
18:00
                                nextUpdate = 21:00              nextUpdate =
19:00
 
BaseCRLNumber = 2
                                CertificateList = {14, 124, 39,
CertificateList = {67}
                                                         21}


19:00           {14, 124, 39,                                   cRLNumber =
55
                67}                                             thisUpdate =
19:00
                                                                nextUpdate =
20:00
 
BaseCRLNumber = 3
 
CertificateList = {}




------_=_NextPart_001_01C0D718.1B758F10
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 5.00.2014.210" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D109370817-07052001>Russ:</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D109370817-07052001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D109370817-07052001>What=20
is stated below in your e-mail is INCORRECT.&nbsp; I just spoke with =
David=20
Cooper.&nbsp; He is going to make a posting again.&nbsp; What I have =
said on=20
this list happens to be (by accident) correct.&nbsp; And that is the =
base CRL=20
and delta CRL share the number from the same space and the number is=20
monotonically increasing.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D109370817-07052001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D109370817-07052001>We=20
have added Stream Identifier feature to allow to differentiate (only if =
the CA=20
wishes) among indirect CRL, partitioned CRL etc.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D109370817-07052001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D109370817-07052001>Thus,=20
a base and delta must have the same stream identifier in order to be=20
merged.&nbsp; If the delta thisUpdate &gt; base thisUpdate, delta CRL =
Number=20
&gt; base CRL Number (for the same or no stream identifier).&nbsp; This =
rule is=20
invariant except for number wrapping.</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV class=3DOutlookMessageHeader><FONT face=3D"Times New Roman"=20
size=3D2>-----Original Message-----<BR><B>From:</B> Housley, Russ=20
[mailto:[e-mail]]<BR><B>Sent:</B> Monday, May 07, 2001 =
12:00=20
PM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> RE: delta=20
CRLs<BR><BR></FONT></DIV>I have updated the figure that David Cooper =
posted last=20
week.&nbsp; I think that the update illustrates Trevor's point.&nbsp; =
The full=20
CRL and the delta CRL can have two independent monotonically increasing =
sequence=20
of integers and still meet all of the PKIX and X.509-2000=20
requirements.<BR><BR>The numbering scheme that David proposed seems =
much easier=20
to implement, but I cannot find any text that the scheme below=20
violates.<BR><BR>I do not know what to call the full CRL at 13:00 that =
is=20
generated by merging base CRL 1 and delta CRL =
49...<BR><BR>Russ<BR><BR><BR>=3D =3D =3D=20
=3D =3D =3D =3D =3D =3D =3D <BR><BR><BR><FONT face=3D"Courier New, =
Courier">current&nbsp;&nbsp;=20
revoked<BR>time<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>&nbsp;&nbsp;=20
certificates<X-TAB>&nbsp;</X-TAB>full=20
CRL<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB=
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>delta=20
CRL<BR>------------------------------------------------------------<BR><=
/FONT>12:00<X-TAB>&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>{14}<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;</=
X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>cRL=
Number=20
=3D=20
1<X-TAB>&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;</X-TAB>cRLNumber=20
=3D=20
48<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-=
TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>thisUpdate=20
=3D=20
12:00<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>thisUpdate=20
=3D=20
12:00<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>=
<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>nextUpdate=20
=3D=20
15:00<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>nextUpdate=20
=3D=20
13:00<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>=
<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;</X-TAB>BaseCRLNumber=20
=3D=20
1<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-T=
AB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>CertificateList=20
=3D=20
{14}<X-TAB>&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;</X-TAB>CertificateList=20
=3D=20
{}<BR><BR><BR>13:00<X-TAB>&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>{14,=20
124}<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;</X-TAB>cRLNumber=20
=3D=20
49<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-=
TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</=
X-TAB>thisUpdate=20
=3D=20
13:00<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>=
<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;</X-TAB>nextUpdate=20
=3D=20
14:00<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>=
<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;</X-TAB>BaseCRLNumber=20
=3D=20
1<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-T=
AB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X=
-TAB>CertificateList=20
=3D=20
{124}<BR><BR><BR>14:00<X-TAB>&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>{14,=20
124}<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;</X-TAB>cRLNumber=20
=3D=20
50<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-=
TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</=
X-TAB>thisUpdate=20
=3D=20
14:00<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>=
<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;</X-TAB>nextUpdate=20
=3D=20
15:00<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>=
<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;</X-TAB>BaseCRLNumber=20
=3D=20
1<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-T=
AB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X=
-TAB>CertificateList=20
=3D=20
{124}<BR><BR><BR>15:00<X-TAB>&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>{14,=20
124, 39}<X-TAB>&nbsp;&nbsp;&nbsp;</X-TAB>cRLNumber =3D=20
2<X-TAB>&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;</X-TAB>cRLNumber=20
=3D=20
51<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-=
TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>thisUpdate=20
=3D=20
15:00<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>thisUpdate=20
=3D=20
15:00<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>=
<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>nextUpdate=20
=3D=20
18:00<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>nextUpdate=20
=3D=20
16:00<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>=
<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;</X-TAB>BaseCRLNumber=20
=3D=20
1<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-T=
AB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>CertificateList=20
=3D {14, 124, 39}<X-TAB>&nbsp;</X-TAB>CertificateList =3D {124,=20
39}<BR><BR><BR>16:00<X-TAB>&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>{14,=20
124,=20
39,<X-TAB>&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>=
cRLNumber=20
=3D=20
52<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-=
TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>67}<X-TAB>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>=
<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>thisUpdat=
e=20
=3D=20
16:00<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>=
<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;</X-TAB>nextUpdate=20
=3D=20
17:00<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>=
<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;</X-TAB>BaseCRLNumber=20
=3D=20
2<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-T=
AB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X=
-TAB>CertificateList=20
=3D=20
{67}<BR><BR><BR>17:00<X-TAB>&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>{14,=20
124,=20
39,<X-TAB>&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>=
cRLNumber=20
=3D=20
53<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-=
TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>67}<X-TAB>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>=
<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>thisUpdat=
e=20
=3D=20
17:00<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>=
<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;</X-TAB>nextUpdate=20
=3D=20
18:00<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>=
<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;</X-TAB>BaseCRLNumber=20
=3D=20
2<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-T=
AB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X=
-TAB>CertificateList=20
=3D=20
{67}<BR><BR><BR>18:00<X-TAB>&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>{14,=20
124, 39,<X-TAB>&nbsp;&nbsp;&nbsp;</X-TAB>cRLNumber =3D=20
3<X-TAB>&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;</X-TAB>cRLNumber=20
=3D=20
54<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-=
TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>67}<X-TAB>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;</X-TAB>thisUpdate=20
=3D=20
18:00<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>thisUpdate=20
=3D=20
18:00<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>=
<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>nextUpdate=20
=3D=20
21:00<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>nextUpdate=20
=3D=20
19:00<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>=
<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;</X-TAB>BaseCRLNumber=20
=3D=20
2<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-T=
AB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>CertificateList=20
=3D {14, 124, 39,<X-TAB>&nbsp;</X-TAB>CertificateList =3D=20
{67}<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><=
X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
21}<BR><BR><BR>19:00<X-TAB>&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>{14,=20
124,=20
39,<X-TAB>&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>=
cRLNumber=20
=3D=20
55<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-=
TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>67}<X-TAB>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>=
<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>thisUpdat=
e=20
=3D=20
19:00<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>=
<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;</X-TAB>nextUpdate=20
=3D=20
20:00<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>=
<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;</X-TAB>BaseCRLNumber=20
=3D=20
3<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-T=
AB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;</X-TAB><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X=
-TAB>CertificateList=20
=3D {}<BR><BR><BR></BODY></HTML>

------_=_NextPart_001_01C0D718.1B758F10--


Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA14954 for <[e-mail]>; Mon, 7 May 2001 10:08:08 -0700 (PDT)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id NAA21045; Mon, 7 May 2001 13:08:08 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 07 May 2001 13:05:52 -0400
To: "Housley, Russ" <[e-mail]>, [e-mail]
From: Tim Polk <[e-mail]>
Subject: RE: delta CRLs
In-Reply-To: <[e-mail]. com>
References: <[e-mail] .windeploy.ntdev.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Russ,

At 11:59 AM 5/7/01 -0400, you wrote:
>I have updated the figure that David Cooper posted last week.  I think 
>that the update illustrates Trevor's point.  The full CRL and the delta 
>CRL can have two independent monotonically increasing sequence of integers 
>and still meet all of the PKIX and X.509-2000 requirements.

I expect you are correct; the description of CRL numbering currently in 
PKIX may permit this scheme.  However, I think we should tighten the wording.

>The numbering scheme that David proposed seems much easier to implement, 
>but I cannot find any text that the scheme below violates.
>
>I do not know what to call the full CRL at 13:00 that is generated by 
>merging base CRL 1 and delta CRL 49...

I believe that is the problem with Trevor's proposal.  The CRL number of 
the constructed CRL does not help you determine whether or not a future 
delta can be applied safely to the constructed CRL.

The most glaring example of this is the delta CRL number 51.  When it is 
combined with full CRL number 1, you actually obtain full CRL number 
2.  However, at 16:00 the CA issues delta 52, which points to full CRL 2 as 
a base.  Using Trevor's numbering scheme, there is no way to be sure that 
CRL 1 and delta 51 are the same CRL as the full CRL with CRL number 2.  As 
a result, at 16:00 the relying party must download both full CRL number 2 
and delta number 52.

That is the sort of behavior we want to avoid.

Tim

>Russ
>
>
>= = = = = = = = = =
>
>
>current   revoked
>time       certificates full CRL                        delta CRL
>------------------------------------------------------------
>12:00           {14}            cRLNumber = 1                   cRLNumber = 48
>                                 thisUpdate = 
> 12:00              thisUpdate = 12:00
>                                 nextUpdate = 
> 15:00              nextUpdate = 13:00
> 
>BaseCRLNumber = 1
>                                 CertificateList = 
> {14}          CertificateList = {}
>
>
>13:00           {14, 124}                                       cRLNumber = 49
> 
>thisUpdate = 13:00
> 
>nextUpdate = 14:00
> 
>BaseCRLNumber = 1
> 
>CertificateList = {124}
>
>
>14:00           {14, 124}                                       cRLNumber = 50
> 
>thisUpdate = 14:00
> 
>nextUpdate = 15:00
> 
>BaseCRLNumber = 1
> 
>CertificateList = {124}
>
>
>15:00           {14, 124, 39}   cRLNumber = 2                   cRLNumber = 51
>                                 thisUpdate = 
> 15:00              thisUpdate = 15:00
>                                 nextUpdate = 
> 18:00              nextUpdate = 16:00
> 
>BaseCRLNumber = 1
>                                 CertificateList = {14, 124, 39} 
> CertificateList = {124, 39}
>
>
>16:00           {14, 124, 39,                                   cRLNumber = 52
>                 67} 
> thisUpdate = 16:00
> 
>nextUpdate = 17:00
> 
>BaseCRLNumber = 2
> 
>CertificateList = {67}
>
>
>17:00           {14, 124, 39,                                   cRLNumber = 53
>                 67} 
> thisUpdate = 17:00
> 
>nextUpdate = 18:00
> 
>BaseCRLNumber = 2
> 
>CertificateList = {67}
>
>
>18:00           {14, 124, 39,   cRLNumber = 3                   cRLNumber = 54
>                 67}             thisUpdate = 
> 18:00              thisUpdate = 18:00
>                                 nextUpdate = 
> 21:00              nextUpdate = 19:00
> 
>BaseCRLNumber = 2
>                                 CertificateList = {14, 124, 39, 
> CertificateList = {67}
>                                                          21}
>
>
>19:00           {14, 124, 39,                                   cRLNumber = 55
>                 67} 
> thisUpdate = 19:00
> 
>nextUpdate = 20:00
> 
>BaseCRLNumber = 3
> 
>CertificateList = {}
>



Received: from e1.ny.us.ibm.com ([32.97.182.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA12105 for <[e-mail]>; Mon, 7 May 2001 09:24:14 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA317196; Mon, 7 May 2001 12:21:52 -0400
Received: from d02ml237.somers.hqregion.ibm.com (d02ml237.sby.ibm.com [9.45.4.171]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id MAA47550; Mon, 7 May 2001 12:18:07 -0400
Importance: Normal
Subject: RE: Certificate Hold (was RE: delta CRLs)
To: Santosh Chokhani <[e-mail]>
Cc: Stephen Kent <[e-mail]>, "Housley, Russ" <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Mon, 7 May 2001 11:32:49 -0400
X-MIMETrack: Serialize by Router on D02ML237/02/M/IBM(Release 5.0.7 |March 21, 2001) at 05/07/2001 12:23:22 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

     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 <[e-mail]> on 05/05/2001 07:58:09 AM

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


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:[e-mail]]
Sent: Friday, May 04, 2001 6:50 PM
To: Stephen Kent
Cc: Housley, Russ; [e-mail]
Subject: RE: Certificate Hold (was RE: delta CRLs)






     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 <[e-mail]> on 05/04/2001 02:42:33 PM


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





At 1:30 PM -0400 5/4/01, Housley, Russ wrote:
>Carlin:
>
>>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?
>
>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





Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id JAA10046 for <[e-mail]>; Mon, 7 May 2001 09:02:31 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 7 May 2001 16:02:17 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA29987 for <[e-mail]>; Mon, 7 May 2001 12:02:30 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <JY8NVDAB>; Mon, 7 May 2001 12:02:29 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.115]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JY8NVC99; Mon, 7 May 2001 12:00:05 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 07 May 2001 11:59:58 -0400
Subject: RE: delta CRLs
In-Reply-To: <[e-mail] .windeploy.ntdev.microsoft.com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"

<html>
I have updated the figure that David Cooper posted last week.&nbsp; I
think that the update illustrates Trevor's point.&nbsp; The full CRL and
the delta CRL can have two independent monotonically increasing sequence
of integers and still meet all of the PKIX and X.509-2000
requirements.<br>
<br>
The numbering scheme that David proposed seems much easier to implement,
but I cannot find any text that the scheme below violates.<br>
<br>
I do not know what to call the full CRL at 13:00 that is generated by
merging base CRL 1 and delta CRL 49...<br>
<br>
Russ<br>
<br>
<br>
= = = = = = = = = = <br>
<br>
<br>
<font face="Courier New, Courier">current&nbsp;&nbsp; revoked<br>
time<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;
certificates<x-tab>&nbsp;</x-tab>full
CRL<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>delta
CRL<br>
------------------------------------------------------------<br>
</font>12:00<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>{14}<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLNumber
=
1<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLNumber
= 48<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>thisUpdate
=
12:00<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>thisUpdate
= 12:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>nextUpdate
=
15:00<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>nextUpdate
= 13:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>BaseCRLNumber
= 1<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>CertificateList
=
{14}<x-tab>&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>CertificateList
= {}<br>
<br>
<br>
13:00<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>{14,
124}<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLNumber
= 49<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>thisUpdate
= 13:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>nextUpdate
= 14:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>BaseCRLNumber
= 1<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>CertificateList
= {124}<br>
<br>
<br>
14:00<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>{14,
124}<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLNumber
= 50<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>thisUpdate
= 14:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>nextUpdate
= 15:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>BaseCRLNumber
= 1<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>CertificateList
= {124}<br>
<br>
<br>
15:00<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>{14,
124, 39}<x-tab>&nbsp;&nbsp;&nbsp;</x-tab>cRLNumber =
2<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLNumber
= 51<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>thisUpdate
=
15:00<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>thisUpdate
= 15:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>nextUpdate
=
18:00<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>nextUpdate
= 16:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>BaseCRLNumber
= 1<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>CertificateList
= {14, 124, 39}<x-tab>&nbsp;</x-tab>CertificateList = {124, 39}<br>
<br>
<br>
16:00<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>{14,
124,
39,<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLNumber
= 52<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>67}<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>thisUpdate
= 16:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>nextUpdate
= 17:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>BaseCRLNumber
= 2<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>CertificateList
= {67}<br>
<br>
<br>
17:00<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>{14,
124,
39,<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLNumber
= 53<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>67}<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>thisUpdate
= 17:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>nextUpdate
= 18:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>BaseCRLNumber
= 2<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>CertificateList
= {67}<br>
<br>
<br>
18:00<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>{14,
124, 39,<x-tab>&nbsp;&nbsp;&nbsp;</x-tab>cRLNumber =
3<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLNumber
= 54<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>67}<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>thisUpdate
=
18:00<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>thisUpdate
= 18:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>nextUpdate
=
21:00<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>nextUpdate
= 19:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>BaseCRLNumber
= 2<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>CertificateList
= {14, 124, 39,<x-tab>&nbsp;</x-tab>CertificateList = {67}<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
21}<br>
<br>
<br>
19:00<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>{14,
124,
39,<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLNumber
= 55<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>67}<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>thisUpdate
= 19:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>nextUpdate
= 20:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>BaseCRLNumber
= 3<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>CertificateList
= {}<br>
<br>
<br>
</html>


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id GAA26253 for <[e-mail]>; Mon, 7 May 2001 06:43:00 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 7 May 2001 13:42:45 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA18789 for <[e-mail]>; Mon, 7 May 2001 09:43:01 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <JY8NVAND>; Mon, 7 May 2001 09:43:00 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.21]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JY8NVAM0; Mon, 7 May 2001 09:42:56 -0400
From: "Housley, Russ" <[e-mail]>
To: Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 07 May 2001 09:21:08 -0400
Subject: RE: delta CRLs
In-Reply-To: <[e-mail]. com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Santosh:

X.509 may allow the CRL number to wrap around, but I do not believe that 
PKIX does.

    5.2.3  CRL Number

    The CRL number is a non-critical CRL extension which conveys a
    monotonically increasing sequence number for each CRL issued by a CA.
    This extension allows users to easily determine when a particular CRL
    supersedes another CRL.  CAs conforming to this profile MUST include
    this extension in all CRLs.

    id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }

Russ


At 10:11 PM 5/5/2001 -0400, Santosh Chokhani wrote:

>Actually, the text allows for the wrap of the numbers.  Please see Annex B 
>of X.509.  Thus, it is not strictly increasing
>
>-----Original Message-----
>From: Peter Sylvester 
>[<mailto:[e-mail]>mailto:[e-mail]]
>Sent: Saturday, May 05, 2001 2:08 PM
>To: [e-mail]; [e-mail];
>[e-mail]
>Cc: [e-mail]
>Subject: RE: delta CRLs
>
> > Trevor:
> >
> > The 2000 version of X.509 is very clear on this.  For a given CRL stream
> > identifier, the CRL number is unique whether it is base or delta.  That is
> > why delta number has to be greater than the base.
>
>" 8.5.2.1 CRL number extension
>
>   This CRL extension field conveys a monotonically increasing sequence 
> number .."
>
>The text might be clearer IMHO if 'strictly increasing' would be used 
>instead.


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id GAA26238 for <[e-mail]>; Mon, 7 May 2001 06:42:57 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 7 May 2001 13:42:42 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA18783 for <[e-mail]>; Mon, 7 May 2001 09:42:58 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <JY8NVANB>; Mon, 7 May 2001 09:42:57 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.21]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JY8NVAM5; Mon, 7 May 2001 09:42:53 -0400
From: "Housley, Russ" <[e-mail]>
To: Tom Gindin <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 07 May 2001 08:36:04 -0400
Subject: RE: Certificate Hold (was RE: delta CRLs)
In-Reply-To: <[e-mail] m.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

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

At 06:50 PM 5/4/2001 -0400, Tom Gindin wrote:

>      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 <[e-mail]> on 05/04/2001 02:42:33 PM
>
>To:   "Housley, Russ" <[e-mail]>
>cc:   [e-mail]
>Subject:  RE: Certificate Hold  (was RE: delta CRLs)
>
>
>At 1:30 PM -0400 5/4/01, Housley, Russ wrote:
> >Carlin:
> >
> >>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?
> >
> >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


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA18099 for <[e-mail]>; Mon, 7 May 2001 04:55:50 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <K3SGKP00>; Mon, 7 May 2001 07:55:20 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Trevor Freeman <[e-mail]>, Santosh Chokhani <[e-mail]>, "Housley, Russ" <[e-mail]>
Cc: [e-mail]
Subject: RE: delta CRLs
Date: Mon, 7 May 2001 07:46:10 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D6EB.4FA584C0"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D6EB.4FA584C0
Content-Type: text/plain;
	charset="iso-8859-1"

Trevor:

One more time, there is a relationship between the two CRL numbers.  The
number is monotonically increasing and shared.  Thus, if a base number n is
issued and a later delta to that or any other base is issued (with the same
CRL Stream Identifier, if implemented), the delta's number m and n have the
following relationship: m > n.

Again that persistence rule is also a generation rule and not processing
rule and hence belongs in the CA side.  That said, the removeFromCRL will be
present in a delta CRL until a base is issued that does NOT contain that
entry and the delta refers to that or later base.

-----Original Message-----
From: Trevor Freeman [mailto:[e-mail]]
Sent: Monday, May 07, 2001 1:35 AM
To: Santosh Chokhani; Housley, Russ
Cc: [e-mail]
Subject: RE: delta CRLs


Santosh,
I agree that the Delta CRL indicator extension which identifies the CRL
as a delta CRL, contains a number, and that number refers to the CRL
Number extension in the base CRL, and the client must have a base CRL
which contains a CRL number equal to or grater than the number in the
Delta CRL indicator.
That is not what I am taking about. 
The way I read Russ's rule 2 is that he inferring a relationship between
the CRL number extension in the delta CRL and the CRL number extension
in the base. I am pointing out that there is no relationship between
these two numbers. 
THE point I am trying to clarify in rule three is how long to persist
the "remove from CRL" entry in the delta. We have a rule when to purge
expired revoked certificates from a full CRLs. What we need is an
equally precise rule when to purge remove from CRL entries from a base
CRL.
Trevor
 
-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]] 
Sent: Saturday, May 05, 2001 4:58 AM
To: Trevor Freeman; Housley, Russ; Santosh Chokhani
Cc: [e-mail]
Subject: RE: delta CRLs
 
Trevor: 
The 2000 version of X.509 is very clear on this.  For a given CRL stream
identifier, the CRL number is unique whether it is base or delta.  That
is why delta number has to be greater than the base.
However, since the CRL number is not a mandatory extension (although
PKIX profile requires it), a check based on thisUpdate is more general
and preferred.
As for rule 3, I did not mention it, but this is a CRL generation rule
and applicable to the CA, where as first two rules are CRL processing
rule and hence applicable to relying parties.  I hope the revision will
put these rules in different places for processing and generation.
The processing rule should be that if the removeFromCRL is on delta,
then the entry (if present in the base) should be deleted.
-----Original Message----- 
From: Trevor Freeman [mailto:[e-mail]
<mailto:[e-mail]> ] 
Sent: Friday, May 04, 2001 7:01 PM 
To: Housley, Russ; Santosh Chokhani 
Cc: [e-mail] 
Subject: RE: delta CRLs 
 
I am not sure about rule 2. Surly the CRL number of the base and delta 
are orthogonal. The delta indicator binds the delta to a specific base 
in the base CRL sequence, but the absolute value of the two sequences 
are independent. A CA may have been issuing base CRLs for some time, 
before it gets into the business of using delta CRLs and it does not 
really matter it the delta CRL number starts at 1 or the current number 
of the base. 
To clarify point three, the delta CRL must include "remove from" entries

until the nextupdate time in the referenced base. A CA does not know if 
clients have picked up the base or knot, and to assume they have would 
introduce an error. 
  
Trevor 
  
-----Original Message----- 
From: Housley, Russ [mailto:[e-mail]
<mailto:[e-mail]> ] 
Sent: Friday, May 04, 2001 1:32 PM 
To: Santosh Chokhani 
Cc: [e-mail] 
Subject: RE: delta CRLs 
  
Santosh: 
I see your point. 
There are three rules that interact to make it all work, and I think 
that we are only clear about two of the rules. 
1.  The base CRL referenced by the delta CRL MUST be less than or equal 
to the base CRL to which the updates will be applied. 
2.  The CRL number in the delta CRL MUST be greater than or equal to the

CRL number of the base (otherwise the entries are already accommodated 
by the base). 
3.  Delta CRLs MUST continue to include removeFromCRL entries even if 
they are not otherwise needed to update the referenced base.  David's 
posting provided the rules to describe when they are not longer 
necessary. 
Russ 

------_=_NextPart_001_01C0D6EB.4FA584C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: delta CRLs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Trevor:</FONT>
</P>

<P><FONT SIZE=3D2>One more time, there is a relationship between the =
two CRL numbers.&nbsp; The number is monotonically increasing and =
shared.&nbsp; Thus, if a base number n is issued and a later delta to =
that or any other base is issued (with the same CRL Stream Identifier, =
if implemented), the delta's number m and n have the following =
relationship: m &gt; n.</FONT></P>

<P><FONT SIZE=3D2>Again that persistence rule is also a generation rule =
and not processing rule and hence belongs in the CA side.&nbsp; That =
said, the removeFromCRL will be present in a delta CRL until a base is =
issued that does NOT contain that entry and the delta refers to that or =
later base.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Trevor Freeman [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
rosoft.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, May 07, 2001 1:35 AM</FONT>
<BR><FONT SIZE=3D2>To: Santosh Chokhani; Housley, Russ</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: delta CRLs</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Santosh,</FONT>
<BR><FONT SIZE=3D2>I agree that the Delta CRL indicator extension which =
identifies the CRL</FONT>
<BR><FONT SIZE=3D2>as a delta CRL, contains a number, and that number =
refers to the CRL</FONT>
<BR><FONT SIZE=3D2>Number extension in the base CRL, and the client =
must have a base CRL</FONT>
<BR><FONT SIZE=3D2>which contains a CRL number equal to or grater than =
the number in the</FONT>
<BR><FONT SIZE=3D2>Delta CRL indicator.</FONT>
<BR><FONT SIZE=3D2>That is not what I am taking about. </FONT>
<BR><FONT SIZE=3D2>The way I read Russ's rule 2 is that he inferring a =
relationship between</FONT>
<BR><FONT SIZE=3D2>the CRL number extension in the delta CRL and the =
CRL number extension</FONT>
<BR><FONT SIZE=3D2>in the base. I am pointing out that there is no =
relationship between</FONT>
<BR><FONT SIZE=3D2>these two numbers. </FONT>
<BR><FONT SIZE=3D2>THE point I am trying to clarify in rule three is =
how long to persist</FONT>
<BR><FONT SIZE=3D2>the &quot;remove from CRL&quot; entry in the delta. =
We have a rule when to purge</FONT>
<BR><FONT SIZE=3D2>expired revoked certificates from a full CRLs. What =
we need is an</FONT>
<BR><FONT SIZE=3D2>equally precise rule when to purge remove from CRL =
entries from a base</FONT>
<BR><FONT SIZE=3D2>CRL.</FONT>
<BR><FONT SIZE=3D2>Trevor</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Santosh Chokhani [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>] =
</FONT>
<BR><FONT SIZE=3D2>Sent: Saturday, May 05, 2001 4:58 AM</FONT>
<BR><FONT SIZE=3D2>To: Trevor Freeman; Housley, Russ; Santosh =
Chokhani</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: delta CRLs</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>Trevor: </FONT>
<BR><FONT SIZE=3D2>The 2000 version of X.509 is very clear on =
this.&nbsp; For a given CRL stream</FONT>
<BR><FONT SIZE=3D2>identifier, the CRL number is unique whether it is =
base or delta.&nbsp; That</FONT>
<BR><FONT SIZE=3D2>is why delta number has to be greater than the =
base.</FONT>
<BR><FONT SIZE=3D2>However, since the CRL number is not a mandatory =
extension (although</FONT>
<BR><FONT SIZE=3D2>PKIX profile requires it), a check based on =
thisUpdate is more general</FONT>
<BR><FONT SIZE=3D2>and preferred.</FONT>
<BR><FONT SIZE=3D2>As for rule 3, I did not mention it, but this is a =
CRL generation rule</FONT>
<BR><FONT SIZE=3D2>and applicable to the CA, where as first two rules =
are CRL processing</FONT>
<BR><FONT SIZE=3D2>rule and hence applicable to relying parties.&nbsp; =
I hope the revision will</FONT>
<BR><FONT SIZE=3D2>put these rules in different places for processing =
and generation.</FONT>
<BR><FONT SIZE=3D2>The processing rule should be that if the =
removeFromCRL is on delta,</FONT>
<BR><FONT SIZE=3D2>then the entry (if present in the base) should be =
deleted.</FONT>
<BR><FONT SIZE=3D2>-----Original Message----- </FONT>
<BR><FONT SIZE=3D2>From: Trevor Freeman [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
rosoft.com</A></FONT>
<BR><FONT SIZE=3D2>&lt;<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
rosoft.com</A>&gt; ] </FONT>
<BR><FONT SIZE=3D2>Sent: Friday, May 04, 2001 7:01 PM </FONT>
<BR><FONT SIZE=3D2>To: Housley, Russ; Santosh Chokhani </FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail] </FONT>
<BR><FONT SIZE=3D2>Subject: RE: delta CRLs </FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>I am not sure about rule 2. Surly the CRL number of =
the base and delta </FONT>
<BR><FONT SIZE=3D2>are orthogonal. The delta indicator binds the delta =
to a specific base </FONT>
<BR><FONT SIZE=3D2>in the base CRL sequence, but the absolute value of =
the two sequences </FONT>
<BR><FONT SIZE=3D2>are independent. A CA may have been issuing base =
CRLs for some time, </FONT>
<BR><FONT SIZE=3D2>before it gets into the business of using delta CRLs =
and it does not </FONT>
<BR><FONT SIZE=3D2>really matter it the delta CRL number starts at 1 or =
the current number </FONT>
<BR><FONT SIZE=3D2>of the base. </FONT>
<BR><FONT SIZE=3D2>To clarify point three, the delta CRL must include =
&quot;remove from&quot; entries</FONT>
</P>

<P><FONT SIZE=3D2>until the nextupdate time in the referenced base. A =
CA does not know if </FONT>
<BR><FONT SIZE=3D2>clients have picked up the base or knot, and to =
assume they have would </FONT>
<BR><FONT SIZE=3D2>introduce an error. </FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>Trevor </FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>-----Original Message----- </FONT>
<BR><FONT SIZE=3D2>From: Housley, Russ [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A></FONT>
<BR><FONT SIZE=3D2>&lt;<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>&gt; ] </FONT>
<BR><FONT SIZE=3D2>Sent: Friday, May 04, 2001 1:32 PM </FONT>
<BR><FONT SIZE=3D2>To: Santosh Chokhani </FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail] </FONT>
<BR><FONT SIZE=3D2>Subject: RE: delta CRLs </FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>Santosh: </FONT>
<BR><FONT SIZE=3D2>I see your point. </FONT>
<BR><FONT SIZE=3D2>There are three rules that interact to make it all =
work, and I think </FONT>
<BR><FONT SIZE=3D2>that we are only clear about two of the rules. =
</FONT>
<BR><FONT SIZE=3D2>1.&nbsp; The base CRL referenced by the delta CRL =
MUST be less than or equal </FONT>
<BR><FONT SIZE=3D2>to the base CRL to which the updates will be =
applied. </FONT>
<BR><FONT SIZE=3D2>2.&nbsp; The CRL number in the delta CRL MUST be =
greater than or equal to the</FONT>
</P>

<P><FONT SIZE=3D2>CRL number of the base (otherwise the entries are =
already accommodated </FONT>
<BR><FONT SIZE=3D2>by the base). </FONT>
<BR><FONT SIZE=3D2>3.&nbsp; Delta CRLs MUST continue to include =
removeFromCRL entries even if </FONT>
<BR><FONT SIZE=3D2>they are not otherwise needed to update the =
referenced base.&nbsp; David's </FONT>
<BR><FONT SIZE=3D2>posting provided the rules to describe when they are =
not longer </FONT>
<BR><FONT SIZE=3D2>necessary. </FONT>
<BR><FONT SIZE=3D2>Russ </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0D6EB.4FA584C0--


Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.9.3/8.9.3) with SMTP id WAA05685 for <[e-mail]>; Sun, 6 May 2001 22:59:14 -0700 (PDT)
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 06 May 2001 22:33:09 -0700 (Pacific Daylight Time)
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Sun, 6 May 2001 22:35:16 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Sun, 6 May 2001 22:35:15 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Sun, 6 May 2001 22:34:57 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: delta CRLs
Date: Sun, 6 May 2001 22:34:56 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: delta CRLs
Thread-Index: AcDVW+6sDu0uLYyJQtuAMV4kKvifPwBWKO6g
From: "Trevor Freeman" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, "Housley, Russ" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 07 May 2001 05:34:57.0437 (UTC) FILETIME=[73ABC4D0:01C0D6B7]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id WAA05686

Santosh,
I agree that the Delta CRL indicator extension which identifies the CRL
as a delta CRL, contains a number, and that number refers to the CRL
Number extension in the base CRL, and the client must have a base CRL
which contains a CRL number equal to or grater than the number in the
Delta CRL indicator.
That is not what I am taking about. 
The way I read Russ's rule 2 is that he inferring a relationship between
the CRL number extension in the delta CRL and the CRL number extension
in the base. I am pointing out that there is no relationship between
these two numbers. 
THE point I am trying to clarify in rule three is how long to persist
the "remove from CRL" entry in the delta. We have a rule when to purge
expired revoked certificates from a full CRLs. What we need is an
equally precise rule when to purge remove from CRL entries from a base
CRL.
Trevor
 
-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]] 
Sent: Saturday, May 05, 2001 4:58 AM
To: Trevor Freeman; Housley, Russ; Santosh Chokhani
Cc: [e-mail]
Subject: RE: delta CRLs
 
Trevor: 
The 2000 version of X.509 is very clear on this.  For a given CRL stream
identifier, the CRL number is unique whether it is base or delta.  That
is why delta number has to be greater than the base.
However, since the CRL number is not a mandatory extension (although
PKIX profile requires it), a check based on thisUpdate is more general
and preferred.
As for rule 3, I did not mention it, but this is a CRL generation rule
and applicable to the CA, where as first two rules are CRL processing
rule and hence applicable to relying parties.  I hope the revision will
put these rules in different places for processing and generation.
The processing rule should be that if the removeFromCRL is on delta,
then the entry (if present in the base) should be deleted.
-----Original Message----- 
From: Trevor Freeman [mailto:[e-mail]
<mailto:[e-mail]> ] 
Sent: Friday, May 04, 2001 7:01 PM 
To: Housley, Russ; Santosh Chokhani 
Cc: [e-mail] 
Subject: RE: delta CRLs 
 
I am not sure about rule 2. Surly the CRL number of the base and delta 
are orthogonal. The delta indicator binds the delta to a specific base 
in the base CRL sequence, but the absolute value of the two sequences 
are independent. A CA may have been issuing base CRLs for some time, 
before it gets into the business of using delta CRLs and it does not 
really matter it the delta CRL number starts at 1 or the current number 
of the base. 
To clarify point three, the delta CRL must include "remove from" entries

until the nextupdate time in the referenced base. A CA does not know if 
clients have picked up the base or knot, and to assume they have would 
introduce an error. 
  
Trevor 
  
-----Original Message----- 
From: Housley, Russ [mailto:[e-mail]
<mailto:[e-mail]> ] 
Sent: Friday, May 04, 2001 1:32 PM 
To: Santosh Chokhani 
Cc: [e-mail] 
Subject: RE: delta CRLs 
  
Santosh: 
I see your point. 
There are three rules that interact to make it all work, and I think 
that we are only clear about two of the rules. 
1.  The base CRL referenced by the delta CRL MUST be less than or equal 
to the base CRL to which the updates will be applied. 
2.  The CRL number in the delta CRL MUST be greater than or equal to the

CRL number of the base (otherwise the entries are already accommodated 
by the base). 
3.  Delta CRLs MUST continue to include removeFromCRL entries even if 
they are not otherwise needed to update the referenced base.  David's 
posting provided the rules to describe when they are not longer 
necessary. 
Russ 


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA14533 for <[e-mail]>; Sat, 5 May 2001 19:21:30 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <KKT63FSC>; Sat, 5 May 2001 22:21:04 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Peter Sylvester <[e-mail]>, [e-mail], [e-mail], Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Subject: RE: delta CRLs
Date: Sat, 5 May 2001 22:11:57 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D5D1.ED350550"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D5D1.ED350550
Content-Type: text/plain;
	charset="iso-8859-1"

Actually, the text allows for the wrap of the numbers.  Please see Annex B
of X.509.  Thus, it is not strictly increasing

-----Original Message-----
From: Peter Sylvester [mailto:[e-mail]]
Sent: Saturday, May 05, 2001 2:08 PM
To: [e-mail]; [e-mail];
[e-mail]
Cc: [e-mail]
Subject: RE: delta CRLs


> Trevor:
> 
> The 2000 version of X.509 is very clear on this.  For a given CRL stream
> identifier, the CRL number is unique whether it is base or delta.  That is
> why delta number has to be greater than the base.

" 8.5.2.1 CRL number extension

  This CRL extension field conveys a monotonically increasing sequence
number .."

The text might be clearer IMHO if 'strictly increasing' would be used
instead.

------_=_NextPart_001_01C0D5D1.ED350550
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: delta CRLs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Actually, the text allows for the wrap of the =
numbers.&nbsp; Please see Annex B of X.509.&nbsp; Thus, it is not =
strictly increasing</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Peter Sylvester [<A =
HREF=3D"mailto:[e-mail]">mailto:Peter.Sylvester@EdelWe=
b.fr</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Saturday, May 05, 2001 2:08 PM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]; =
[e-mail];</FONT>
<BR><FONT SIZE=3D2>[e-mail]</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: delta CRLs</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; Trevor:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The 2000 version of X.509 is very clear on =
this.&nbsp; For a given CRL stream</FONT>
<BR><FONT SIZE=3D2>&gt; identifier, the CRL number is unique whether it =
is base or delta.&nbsp; That is</FONT>
<BR><FONT SIZE=3D2>&gt; why delta number has to be greater than the =
base.</FONT>
</P>

<P><FONT SIZE=3D2>&quot; 8.5.2.1 CRL number extension</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; This CRL extension field conveys a =
monotonically increasing sequence number ..&quot;</FONT>
</P>

<P><FONT SIZE=3D2>The text might be clearer IMHO if 'strictly =
increasing' would be used instead.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0D5D1.ED350550--


Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA12316 for <[e-mail]>; Sat, 5 May 2001 11:07:57 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA22621; Sat, 5 May 2001 20:07:50 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Sat, 5 May 2001 20:07:50 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id UAA03572; Sat, 5 May 2001 20:07:48 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id UAA28918; Sat, 5 May 2001 20:07:48 +0200 (MET DST)
Date: Sat, 5 May 2001 20:07:48 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: RE: delta CRLs
Cc: [e-mail]

> Trevor:
> 
> The 2000 version of X.509 is very clear on this.  For a given CRL stream
> identifier, the CRL number is unique whether it is base or delta.  That is
> why delta number has to be greater than the base.

" 8.5.2.1 CRL number extension

  This CRL extension field conveys a monotonically increasing sequence number .."

The text might be clearer IMHO if 'strictly increasing' would be used instead.



Received: from cmps1.collectivemind.com.pe ([200.60.29.181]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA10061 for <[e-mail]>; Sat, 5 May 2001 10:29:53 -0700 (PDT)
Received: from mail pickup service by cmps1.collectivemind.com.pe with Microsoft SMTPSVC; Sat, 5 May 2001 12:09:58 -0500
From: "=?iso-8859-1?Q?CLUB_CUSQUE=D1A?=" <[e-mail]>
To: <[e-mail]>
Subject: =?iso-8859-1?Q?Promoci=F3n_Chopp_Cusque=F1a?=
Date: Sat, 5 May 2001 12:09:16 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_15798_01C0D55C.3487DAC0"
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
Message-ID: <[e-mail]>

This is a multi-part message in MIME format.

------=_NextPart_000_15798_01C0D55C.3487DAC0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<http://www.cusquena.com.pe/chopp/CH_pedido.asp?IdCliente=3Dx&Idcliente2=3D=
x
> =20
..P=EDdelo=20
   AQU=CD

      =20

<http://www.cusquena.com.pe/chopp/CH_ordenchopp.asp?IdCliente=3Dx&Idclien=
t
e2=3Dx> =20
<http://www.cusquena.com.pe/chopp/ch_recomendar.asp> =20
<http://www.cusquena.com.pe/chopp/ch_sugerencia.asp> =20
Como hacer el pedido?=20
Solo necesitas llenar tus datos en el=20
formulario de pedidos de CHOPP...=20
y LISTO!!!=20

RD: 152-2001-IN-1501=20


Visita el Web site de Cerveza Cusque=F1a en:=20
http://www.cusquena.com.pe=20


Si quieres entrar al Chat Cusque=F1a haz click Aqu=ED
<http://www.cusquena.com.pe/chat.asp>=20


Recibes este e-mail porque estas suscrito al CLUB CUSQUE=D1A o un amigo
tuyo te ha recomendado.
Para cancelar el env=EDo de este email, reenv=EDanos este email con el
t=EDtulo: QUITARME DE LA LISTA=20

------=_NextPart_000_15798_01C0D55C.3487DAC0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<head><title>www.cusquena.com.pe - Chopp</title></head>
<body bgcolor=3D#808080 marginheight=3D0 topmargin=3D0 vlink=3Dffffff =
alink=3Dffffff, link=3Dffffff>
<table WIDTH=3D642 BORDER=3D0 CELLSPACING=3D0 CELLPADDING=3D0 =
ALIGN=3DCENTER>
<tr BGCOLOR=3D#000000 ALIGN=3DCENTER VALIGN=3DMIDDLE>
<td HEIGHT=3D610>
<table WIDTH=3D680 BORDER=3D0 CELLPADDING=3D0 CELLSPACING=3D0 =
ALIGN=3DCENTER>
<tr>
<td BGCOLOR=3D#FFFFFF ALIGN=3DRIGHT VALIGN=3DBOTTOM WIDTH=3D191><p =
align=3Dcenter>
<img border=3D0 =
src=3Dhttp://www.cusquena.com.pe/chopp/mail/images/logo1.GIF width=3D112 =
height=3D47 vspace=3D3></td>
<td WIDTH=3D445 VALIGN=3DMIDDLE ALIGN=3DCENTER BGCOLOR=3D#000000>
<a =
href=3Dhttp://www.cusquena.com.pe/chopp/CH_pedido.asp?IdCliente=3Dx&Idcli=
ente2=3Dx>
<img border=3D0 =
src=3Dhttp://www.cusquena.com.pe/chopp/mail/images/bannerchopp1.gif =
width=3D468 height=3D60>
</a>
</td>
</tr>
<tr>
<td WIDTH=3D193 BGCOLOR=3D#FECD0A VALIGN=3Dtop>
<table border=3D0 width=3D100&#37; height=3D187>
<tr>
<td width=3D190 height=3D250 valign=3Dmiddle>
<img src=3Dhttp://www.cusquena.com.pe/chopp/mail/images/animchopp.gif =
width=3D190 height=3D181 hspace=3D7></td>
</tr>
<tr>
<td width=3D190 height=3D100>
<p align=3Dright><b><font size=3D7><font face=3DArial =
Color=3DBlack>...P=EDdelo</font>
<font face=3DArial><br>&nbsp;&nbsp; </font><font face=3DArial =
Color=3DBlack>AQU=CD<br>
</font></font></b>
</td>
</tr>
<tr>
<td width=3D190 height=3D50 valign=3Dmiddle>
<p align=3Dcenter>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <img border=3D0 =
src=3Dhttp://www.cusquena.com.pe/chopp/mail/images/flechitaroja.gif =
width=3D35 height=3D25><br>
</td>
</tr>
<tr>
<td bgcolor=3D#FF0000>
<p align=3Dcenter>
<a =
href=3Dhttp://www.cusquena.com.pe/chopp/CH_ordenchopp.asp?IdCliente=3Dx&I=
dcliente2=3Dx>
<img border=3D0 =
src=3Dhttp://www.cusquena.com.pe/chopp/mail/images/pedido.gif>
</a>
</td>
</tr>
<tr>
<td height=3D180 bgcolor=3D#FECD0A>
<p align=3Dcenter>
<img border=3D0 =
src=3Dhttp://www.cusquena.com.pe/chopp/mail/images/cano.gif =
align=3Dright>
</td>
</tr>
<tr>
<td bgcolor=3D#FF0000>
<p align=3Dcenter>
<a href=3Dhttp://www.cusquena.com.pe/chopp/ch_recomendar.asp>
<img border=3D0 =
src=3Dhttp://www.cusquena.com.pe/chopp/mail/images/recomienda.gif></a></t=
d>
</tr>
<tr>
<td bgcolor=3D#FF0000>
<p align=3Dcenter>
<a href=3Dhttp://www.cusquena.com.pe/chopp/ch_sugerencia.asp>
<img border=3D0 =
src=3Dhttp://www.cusquena.com.pe/chopp/mail/images/sugerencias.gif></a></=
td>
</tr>
</table>
</td>
<td WIDTH=3D445 VALIGN=3DTOP ALIGN=3DLEFT><table WIDTH=3D406&#37; =
BORDER=3D0 CELLSPACING=3D0 CELLPADDING=3D0>
<tr VALIGN=3DTOP>
<td WIDTH=3D445 BGCOLOR=3D#000000 align=3Dcenter height=3D52>
<table border=3D0 width=3D468>
<tr>
<td width=3D20&#37;></td>
<td width=3D220&#37; height=3D250>
<p style=3Dline-height: 200&#37;><b>
<font color=3D#FFFFFF face=3DArial size=3D6>Como hacer el pedido?</font>
<font color=3D#FFFFFF face=3DArial size=3D5><br></font></b>
<font color=3D#FFFFFF face=3DArial size=3D5>Solo necesitas llenar tus =
datos en el <br>
formulario de pedidos de CHOPP... <br>
y LISTO!!!</font></td>
<td width=3D5&#37;></td>
</tr><tr>
<td width=3D230&#37; bgcolor=3D#FF8000 colspan=3D3><img border=3D0 =
src=3Dhttp://www.cusquena.com.pe/chopp/mail/images/sol.gif width=3D453 =
height=3D416></td>
</tr></table><font face=3Dverdana size=3D2 color=3Dffffff>
<br><b>RD: 152-2001-IN-1501</b>
</font></td></tr></table></td></tr>
</table></td></tr>
</table>
<br><br><font face=3Darial size=3D2 color=3D000000>
<b>Visita el Web site de Cerveza Cusque=F1a en: </b><br>
<a href=3Dhttp://www.cusquena.com.pe =
target=3D_blank>http://www.cusquena.com.pe</a><br>
<br><br>
<b>Si quieres entrar al Chat Cusque=F1a haz click </b>
<a href=3Dhttp://www.cusquena.com.pe/chat.asp =
target=3D_blank>Aqu=ED</a><br>
<br><br>
<b>Recibes este e-mail porque estas suscrito al CLUB CUSQUE=D1A
 o un amigo tuyo te ha recomendado.<br>
Para cancelar el env=EDo de este email, reenv=EDanos este
email con el t=EDtulo: QUITARME DE LA LISTA</b>
</font></body></html>

------=_NextPart_000_15798_01C0D55C.3487DAC0--


Received: from femail19.sdc1.sfba.home.com (femail19.sdc1.sfba.home.com [24.0.95.128]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA07068 for <[e-mail]>; Sat, 5 May 2001 09:29:09 -0700 (PDT)
From: [e-mail]
Received: from [192.168.0.2] ([24.19.110.53]) by femail19.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010505162905.WMYC98.femail19.sdc1.sfba.home.com@[192.168.0.2]>; Sat, 5 May 2001 09:29:05 -0700
Reply-To: Timothy Fisher <[e-mail]>
To: "Housley, Russ" <[e-mail]>, Santosh Chokhani <[e-mail]>
CC: [e-mail]
Subject: 
Date: 05 May 2001 12:30:10 -0500
X-Mailer: NeoPlanet Version: 5.2.0.1603
X-ID: 93E8EAD00D1711D58181005004D47171
X-Brand: NeoPlanet
X-Build: 1603
Message-Id: <20010505162905.WMYC98.femail19.sdc1.sfba.home.com@[192.168.0.2]>

unsubscribe






Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA16396 for <[e-mail]>; Sat, 5 May 2001 05:07:55 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <KKT631AP>; Sat, 5 May 2001 08:07:25 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Trevor Freeman <[e-mail]>, "Housley, Russ" <[e-mail]>, Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Subject: RE: delta CRLs
Date: Sat, 5 May 2001 07:58:18 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D55A.AC5EA2B0"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D55A.AC5EA2B0
Content-Type: text/plain;
	charset="iso-8859-1"

Trevor:

The 2000 version of X.509 is very clear on this.  For a given CRL stream
identifier, the CRL number is unique whether it is base or delta.  That is
why delta number has to be greater than the base.

However, since the CRL number is not a mandatory extension (although PKIX
profile requires it), a check based on thisUpdate is more general and
preferred.

As for rule 3, I did not mention it, but this is a CRL generation rule and
applicable to the CA, where as first two rules are CRL processing rule and
hence applicable to relying parties.  I hope the revision will put these
rules in different places for processing and generation.

The processing rule should be that if the removeFromCRL is on delta, then
the entry (if present in the base) should be deleted.

-----Original Message-----
From: Trevor Freeman [mailto:[e-mail]]
Sent: Friday, May 04, 2001 7:01 PM
To: Housley, Russ; Santosh Chokhani
Cc: [e-mail]
Subject: RE: delta CRLs


I am not sure about rule 2. Surly the CRL number of the base and delta
are orthogonal. The delta indicator binds the delta to a specific base
in the base CRL sequence, but the absolute value of the two sequences
are independent. A CA may have been issuing base CRLs for some time,
before it gets into the business of using delta CRLs and it does not
really matter it the delta CRL number starts at 1 or the current number
of the base.
To clarify point three, the delta CRL must include "remove from" entries
until the nextupdate time in the referenced base. A CA does not know if
clients have picked up the base or knot, and to assume they have would
introduce an error.
 
Trevor 
 
-----Original Message-----
From: Housley, Russ [mailto:[e-mail]] 
Sent: Friday, May 04, 2001 1:32 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: delta CRLs
 
Santosh:

I see your point.

There are three rules that interact to make it all work, and I think
that we are only clear about two of the rules.

1.  The base CRL referenced by the delta CRL MUST be less than or equal
to the base CRL to which the updates will be applied.

2.  The CRL number in the delta CRL MUST be greater than or equal to the
CRL number of the base (otherwise the entries are already accommodated
by the base).

3.  Delta CRLs MUST continue to include removeFromCRL entries even if
they are not otherwise needed to update the referenced base.  David's
posting provided the rules to describe when they are not longer
necessary.

Russ

------_=_NextPart_001_01C0D55A.AC5EA2B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: delta CRLs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Trevor:</FONT>
</P>

<P><FONT SIZE=3D2>The 2000 version of X.509 is very clear on =
this.&nbsp; For a given CRL stream identifier, the CRL number is unique =
whether it is base or delta.&nbsp; That is why delta number has to be =
greater than the base.</FONT></P>

<P><FONT SIZE=3D2>However, since the CRL number is not a mandatory =
extension (although PKIX profile requires it), a check based on =
thisUpdate is more general and preferred.</FONT></P>

<P><FONT SIZE=3D2>As for rule 3, I did not mention it, but this is a =
CRL generation rule and applicable to the CA, where as first two rules =
are CRL processing rule and hence applicable to relying parties.&nbsp; =
I hope the revision will put these rules in different places for =
processing and generation.</FONT></P>

<P><FONT SIZE=3D2>The processing rule should be that if the =
removeFromCRL is on delta, then the entry (if present in the base) =
should be deleted.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Trevor Freeman [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
rosoft.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, May 04, 2001 7:01 PM</FONT>
<BR><FONT SIZE=3D2>To: Housley, Russ; Santosh Chokhani</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: delta CRLs</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>I am not sure about rule 2. Surly the CRL number of =
the base and delta</FONT>
<BR><FONT SIZE=3D2>are orthogonal. The delta indicator binds the delta =
to a specific base</FONT>
<BR><FONT SIZE=3D2>in the base CRL sequence, but the absolute value of =
the two sequences</FONT>
<BR><FONT SIZE=3D2>are independent. A CA may have been issuing base =
CRLs for some time,</FONT>
<BR><FONT SIZE=3D2>before it gets into the business of using delta CRLs =
and it does not</FONT>
<BR><FONT SIZE=3D2>really matter it the delta CRL number starts at 1 or =
the current number</FONT>
<BR><FONT SIZE=3D2>of the base.</FONT>
<BR><FONT SIZE=3D2>To clarify point three, the delta CRL must include =
&quot;remove from&quot; entries</FONT>
<BR><FONT SIZE=3D2>until the nextupdate time in the referenced base. A =
CA does not know if</FONT>
<BR><FONT SIZE=3D2>clients have picked up the base or knot, and to =
assume they have would</FONT>
<BR><FONT SIZE=3D2>introduce an error.</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>Trevor </FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Housley, Russ [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Friday, May 04, 2001 1:32 PM</FONT>
<BR><FONT SIZE=3D2>To: Santosh Chokhani</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: delta CRLs</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>Santosh:</FONT>
</P>

<P><FONT SIZE=3D2>I see your point.</FONT>
</P>

<P><FONT SIZE=3D2>There are three rules that interact to make it all =
work, and I think</FONT>
<BR><FONT SIZE=3D2>that we are only clear about two of the =
rules.</FONT>
</P>

<P><FONT SIZE=3D2>1.&nbsp; The base CRL referenced by the delta CRL =
MUST be less than or equal</FONT>
<BR><FONT SIZE=3D2>to the base CRL to which the updates will be =
applied.</FONT>
</P>

<P><FONT SIZE=3D2>2.&nbsp; The CRL number in the delta CRL MUST be =
greater than or equal to the</FONT>
<BR><FONT SIZE=3D2>CRL number of the base (otherwise the entries are =
already accommodated</FONT>
<BR><FONT SIZE=3D2>by the base).</FONT>
</P>

<P><FONT SIZE=3D2>3.&nbsp; Delta CRLs MUST continue to include =
removeFromCRL entries even if</FONT>
<BR><FONT SIZE=3D2>they are not otherwise needed to update the =
referenced base.&nbsp; David's</FONT>
<BR><FONT SIZE=3D2>posting provided the rules to describe when they are =
not longer</FONT>
<BR><FONT SIZE=3D2>necessary.</FONT>
</P>

<P><FONT SIZE=3D2>Russ</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0D55A.AC5EA2B0--


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA16371 for <[e-mail]>; Sat, 5 May 2001 05:07:45 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <KKT631AN>; Sat, 5 May 2001 08:07:15 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Tom Gindin <[e-mail]>, Stephen Kent <[e-mail]>
Cc: "Housley, Russ" <[e-mail]>, [e-mail]
Subject: RE: Certificate Hold (was RE: delta CRLs)
Date: Sat, 5 May 2001 07:58:09 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D55A.A7015830"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D55A.A7015830
Content-Type: text/plain;
	charset="iso-8859-1"

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:[e-mail]]
Sent: Friday, May 04, 2001 6:50 PM
To: Stephen Kent
Cc: Housley, Russ; [e-mail]
Subject: RE: Certificate Hold (was RE: delta CRLs)



     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 <[e-mail]> on 05/04/2001 02:42:33 PM

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


At 1:30 PM -0400 5/4/01, Housley, Russ wrote:
>Carlin:
>
>>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?
>
>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


------_=_NextPart_001_01C0D55A.A7015830
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Certificate Hold (was RE: delta CRLs)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Tom:</FONT>
</P>

<P><FONT SIZE=3D2>I also am not a fan of &quot;hold: feature.&nbsp; =
But, I fail to see why &quot;removeFromHold&quot; is in delta CRL is =
unduly complex.&nbsp; I would say either not have the &quot;hold&quot; =
feature or require &quot;hold' and &quot;release&quot; irrespective of =
delta.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Tom Gindin [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>=

<BR><FONT SIZE=3D2>Sent: Friday, May 04, 2001 6:50 PM</FONT>
<BR><FONT SIZE=3D2>To: Stephen Kent</FONT>
<BR><FONT SIZE=3D2>Cc: Housley, Russ; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Certificate Hold (was RE: delta =
CRLs)</FONT>
</P>
<BR>
<BR>

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

<P><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tom =
Gindin</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Stephen Kent &lt;[e-mail]&gt; on 05/04/2001 =
02:42:33 PM</FONT>
</P>

<P><FONT SIZE=3D2>To:&nbsp;&nbsp; &quot;Housley, Russ&quot; =
&lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2>cc:&nbsp;&nbsp; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp; RE: Certificate Hold&nbsp; (was RE: =
delta CRLs)</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>At 1:30 PM -0400 5/4/01, Housley, Russ wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;Carlin:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;Russ, it appears from your comment:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&quot;Fair reply.&nbsp; And, unless there is =
a ground swell of</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;support, I will drop it.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;that you have interpreted Denis as =
meaning</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&quot;I have withdrawn my support for =
'hold'.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;Russ, is that correct?</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;And Russ, I am further confused by &quot;... =
I will drop it.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;Did you mean that you will add text to =
prohibit compliant</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;CA's from issuing delta CRL's that include =
&quot;hold&quot; and</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&quot;removeFromCRL&quot; reason codes or =
text that will prohibit</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;this for full CRL's as well as delta-CRLs, =
or did you</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;mean something else entirely?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;I have NEVER liked the on-hold feature.&nbsp; I =
still do not like the</FONT>
<BR><FONT SIZE=3D2>&gt;on-hold feature.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;I will not delay the Last Call process on =
son-of-rfc 2459 to debate</FONT>
<BR><FONT SIZE=3D2>&gt;the issue unless I see that there are others =
that support my view.</FONT>
</P>

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

<P><FONT SIZE=3D2>Steve</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0D55A.A7015830--


Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.9.3/8.9.3) with SMTP id RAA06638 for <[e-mail]>; Fri, 4 May 2001 17:48:07 -0700 (PDT)
Received: from 157.54.1.52 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 04 May 2001 16:00:01 -0700 (Pacific Daylight Time)
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 4 May 2001 16:01:11 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 4 May 2001 16:01:10 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 4 May 2001 16:00:58 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: delta CRLs
Date: Fri, 4 May 2001 16:00:57 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: delta CRLs
Thread-Index: AcDU2j10YP9yZkGkTyKgECKYwysatwAEyCjw
From: "Trevor Freeman" <[e-mail]>
To: "Housley, Russ" <[e-mail]>, "Santosh Chokhani" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 04 May 2001 23:00:58.0059 (UTC) FILETIME=[14AD71B0:01C0D4EE]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id RAA06639

I am not sure about rule 2. Surly the CRL number of the base and delta
are orthogonal. The delta indicator binds the delta to a specific base
in the base CRL sequence, but the absolute value of the two sequences
are independent. A CA may have been issuing base CRLs for some time,
before it gets into the business of using delta CRLs and it does not
really matter it the delta CRL number starts at 1 or the current number
of the base.
To clarify point three, the delta CRL must include "remove from" entries
until the nextupdate time in the referenced base. A CA does not know if
clients have picked up the base or knot, and to assume they have would
introduce an error.
 
Trevor 
 
-----Original Message-----
From: Housley, Russ [mailto:[e-mail]] 
Sent: Friday, May 04, 2001 1:32 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: delta CRLs
 
Santosh:

I see your point.

There are three rules that interact to make it all work, and I think
that we are only clear about two of the rules.

1.  The base CRL referenced by the delta CRL MUST be less than or equal
to the base CRL to which the updates will be applied.

2.  The CRL number in the delta CRL MUST be greater than or equal to the
CRL number of the base (otherwise the entries are already accommodated
by the base).

3.  Delta CRLs MUST continue to include removeFromCRL entries even if
they are not otherwise needed to update the referenced base.  David's
posting provided the rules to describe when they are not longer
necessary.

Russ


Received: from e1.ny.us.ibm.com ([32.97.182.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA29618 for <[e-mail]>; Fri, 4 May 2001 15:51:14 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA261576; Fri, 4 May 2001 18:48:40 -0400
Received: from d02ml237.somers.hqregion.ibm.com (d02ml237.sby.ibm.com [9.45.4.171]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id SAA49046; Fri, 4 May 2001 18:44:57 -0400
Importance: Normal
Subject: RE: Certificate Hold (was RE: delta CRLs)
To: Stephen Kent <[e-mail]>
Cc: "Housley, Russ" <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Fri, 4 May 2001 18:50:08 -0400
X-MIMETrack: Serialize by Router on D02ML237/02/M/IBM(Release 5.0.7 |March 21, 2001) at 05/04/2001 06:50:11 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

     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 <[e-mail]> on 05/04/2001 02:42:33 PM

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


At 1:30 PM -0400 5/4/01, Housley, Russ wrote:
>Carlin:
>
>>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?
>
>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




Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id OAA24517 for <[e-mail]>; Fri, 4 May 2001 14:31:21 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 4 May 2001 21:31:11 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id RAA21587 for <[e-mail]>; Fri, 4 May 2001 17:31:24 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <JY8N4WRM>; Fri, 4 May 2001 17:31:23 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.41]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JY8N4WRK; Fri, 4 May 2001 17:31:14 -0400
From: "Housley, Russ" <[e-mail]>
To: Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Fri, 04 May 2001 17:30:56 -0400
Subject: RE: delta CRLs
In-Reply-To: <[e-mail]. com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Santosh:

You are correct, there are two equivalent checks for rule 2.

I do not think that the proposed text makes all three rules 
clear.  Obviously, this thread will lead to better text.

Russ


At 04:43 PM 5/4/2001 -0400, Santosh Chokhani wrote:
>Russ:
>
>In lieu of 2, you can also compare thisUpdate field of the base and delta 
>and make sure that a delta is applied to only an earlier (and not the same 
>time issued or later issued base).
>
>I did not understand from your message, which of the three rules was not 
>clear to you.  Or may be you meant the PKIX RFC is not clear on the three 
>rules.
>
>-----Original Message-----
>From: Housley, Russ [mailto:[e-mail]]
>Sent: Friday, May 04, 2001 4:32 PM
>To: Santosh Chokhani
>Cc: [e-mail]
>Subject: RE: delta CRLs
>
>Santosh:
>
>I see your point.
>
>There are three rules that interact to make it all work, and I think that 
>we are only clear about two of the rules.
>
>1.  The base CRL referenced by the delta CRL MUST be less than or equal to 
>the base CRL to which the updates will be applied.
>
>2.  The CRL number in the delta CRL MUST be greater than or equal to the 
>CRL number of the base (otherwise the entries are already accommodated by 
>the base).
>
>3.  Delta CRLs MUST continue to include removeFromCRL entries even if they 
>are not otherwise needed to update the referenced base.  David's posting 
>provided the rules to describe when they are not longer necessary.
>
>Russ


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA20610 for <[e-mail]>; Fri, 4 May 2001 13:52:54 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <K2M3JJ9N>; Fri, 4 May 2001 16:52:26 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: "Housley, Russ" <[e-mail]>, Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Subject: RE: delta CRLs
Date: Fri, 4 May 2001 16:43:21 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D4DA.DB3EAA10"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D4DA.DB3EAA10
Content-Type: text/plain;
	charset="iso-8859-1"

Russ:
 
In lieu of 2, you can also compare thisUpdate field of the base and delta
and make sure that a delta is applied to only an earlier (and not the same
time issued or later issued base).
 
I did not understand from your message, which of the three rules was not
clear to you.  Or may be you meant the PKIX RFC is not clear on the three
rules.
 
-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Friday, May 04, 2001 4:32 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: delta CRLs


Santosh:

I see your point.

There are three rules that interact to make it all work, and I think that we
are only clear about two of the rules.

1.  The base CRL referenced by the delta CRL MUST be less than or equal to
the base CRL to which the updates will be applied.

2.  The CRL number in the delta CRL MUST be greater than or equal to the CRL
number of the base (otherwise the entries are already accommodated by the
base).

3.  Delta CRLs MUST continue to include removeFromCRL entries even if they
are not otherwise needed to update the referenced base.  David's posting
provided the rules to describe when they are not longer necessary.

Russ


------_=_NextPart_001_01C0D4DA.DB3EAA10
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.2014.210" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=866045020-04052001>Russ:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=866045020-04052001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=866045020-04052001>In 
lieu of 2, you can also compare thisUpdate field of the base and delta and make 
sure that a delta is applied to only an earlier (and not the same time issued or 
later issued base).</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=866045020-04052001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=866045020-04052001>I did 
not understand from your message, which of the three rules was not clear to 
you.&nbsp; Or may be you meant the PKIX RFC is not clear on the three 
rules.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=866045020-04052001></SPAN></FONT>&nbsp;</DIV>
<DIV class=OutlookMessageHeader><FONT face="Times New Roman" 
size=2>-----Original Message-----<BR><B>From:</B> Housley, Russ 
[mailto:[e-mail]]<BR><B>Sent:</B> Friday, May 04, 2001 4:32 
PM<BR><B>To:</B> Santosh Chokhani<BR><B>Cc:</B> 
[e-mail]<BR><B>Subject:</B> RE: delta CRLs<BR><BR></FONT></DIV><FONT 
size=2>Santosh:<BR><BR>I see your point.<BR><BR>There are three rules that 
interact to make it all work, and I think that we are only clear about two of 
the rules.<BR><BR>1.&nbsp; The base CRL referenced by the delta CRL MUST be less 
than or equal to the base CRL to which the updates will be 
applied.<BR><BR>2.&nbsp; The CRL number in the delta CRL MUST be greater than or 
equal to the CRL number of the base (otherwise the entries are already 
accommodated by the base).<BR><BR>3.&nbsp; Delta CRLs MUST continue to include 
removeFromCRL entries even if they are not otherwise needed to update the 
referenced base.&nbsp; David's posting provided the rules to describe when they 
are not longer necessary.<BR><BR>Russ<BR></FONT></BODY></HTML>

------_=_NextPart_001_01C0D4DA.DB3EAA10--


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA19404 for <[e-mail]>; Fri, 4 May 2001 13:39:19 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <K2M3JJXH>; Fri, 4 May 2001 16:38:51 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: "Housley, Russ" <[e-mail]>, Denis Pinkas <[e-mail]>
Cc: [e-mail]
Subject: RE: delta-CRLs
Date: Fri, 4 May 2001 16:29:46 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D4D8.F5A01F30"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D4D8.F5A01F30
Content-Type: text/plain;
	charset="iso-8859-1"

Russ and Denis:

With all due respect, that is a limited view of delta CRL (forcing to use
the base CRL that is referenced).

I am very disappointed with the PKIX process of writing these profiles and
rewording and mutating the concepts from X.509 to the point that introduce
limitations and errors.  Recall the buggy path validation procedure in 2459.

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Friday, May 04, 2001 2:16 PM
To: Denis Pinkas
Cc: [e-mail]
Subject: Re: delta-CRLs


Denis:

I can live with these.

>Taking into account the last proposal from Russ, this would
>lead to the two following paragraphs:
>
>    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. Applications that support
>    delta CRLs MUST ensure that time T falls between thisUpdate and
>    nextUpdate for both the base CRL and the delta CRL.
>
>    Note: An application could also reconstruct an updated CRL, for
>    a specific time T, by using a previously locally reconstructed CRL
>    based on a given base CRL, and combining it with a delta CRL which
>    contains a delta CRL indicator extension with the same CRL number as
>    the base CRL.

Russ

------_=_NextPart_001_01C0D4D8.F5A01F30
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: delta-CRLs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Russ and Denis:</FONT>
</P>

<P><FONT SIZE=3D2>With all due respect, that is a limited view of delta =
CRL (forcing to use the base CRL that is referenced).</FONT>
</P>

<P><FONT SIZE=3D2>I am very disappointed with the PKIX process of =
writing these profiles and rewording and mutating the concepts from =
X.509 to the point that introduce limitations and errors.&nbsp; Recall =
the buggy path validation procedure in 2459.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Housley, Russ [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, May 04, 2001 2:16 PM</FONT>
<BR><FONT SIZE=3D2>To: Denis Pinkas</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: delta-CRLs</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Denis:</FONT>
</P>

<P><FONT SIZE=3D2>I can live with these.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;Taking into account the last proposal from Russ, =
this would</FONT>
<BR><FONT SIZE=3D2>&gt;lead to the two following paragraphs:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; An application can construct =
an updated CRL, for a specific time T,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; by retrieving the appropriate =
base CRL for that scope, and combining</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; it with a delta CRL which =
contains a delta CRL indicator extension</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; with the same CRL number as =
the base CRL. Applications that support</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; delta CRLs MUST ensure that =
time T falls between thisUpdate and</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; nextUpdate for both the base =
CRL and the delta CRL.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; Note: An application could =
also reconstruct an updated CRL, for</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; a specific time T, by using a =
previously locally reconstructed CRL</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; based on a given base CRL, =
and combining it with a delta CRL which</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; contains a delta CRL =
indicator extension with the same CRL number as</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; the base CRL.</FONT>
</P>

<P><FONT SIZE=3D2>Russ</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0D4D8.F5A01F30--


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id NAA18731 for <[e-mail]>; Fri, 4 May 2001 13:33:24 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 4 May 2001 20:33:13 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA18535 for <[e-mail]>; Fri, 4 May 2001 16:33:26 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <JY8N4V79>; Fri, 4 May 2001 16:33:25 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.119]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JY8N4V7Z; Fri, 4 May 2001 16:33:18 -0400
From: "Housley, Russ" <[e-mail]>
To: Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Fri, 04 May 2001 16:31:51 -0400
Subject: RE: delta CRLs
In-Reply-To: <[e-mail]. com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"

<html>
<font size=2>Santosh:<br>
<br>
I see your point.<br>
<br>
There are three rules that interact to make it all work, and I think that
we are only clear about two of the rules.<br>
<br>
1.&nbsp; The base CRL referenced by the delta CRL MUST be less than or
equal to the base CRL to which the updates will be applied.<br>
<br>
2.&nbsp; The CRL number in the delta CRL MUST be greater than or equal to
the CRL number of the base (otherwise the entries are already
accommodated by the base).<br>
<br>
3.&nbsp; Delta CRLs MUST continue to include removeFromCRL entries even
if they are not otherwise needed to update the referenced base.&nbsp;
David's posting provided the rules to describe when they are not longer
necessary.<br>
<br>
Russ<br>
</font></html>


Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA15663 for <[e-mail]>; Fri, 4 May 2001 12:56:10 -0700 (PDT)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA28819; Fri, 4 May 2001 12:56:11 -0700 (PDT)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA09947; Fri, 4 May 2001 15:56:08 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 04 May 2001 15:51:51 -0400
From: Steve Hanna <[e-mail]>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Sharon Boeyen <[e-mail]>
CC: "'Tim Polk'" <[e-mail]>, PKIX List <[e-mail]>
Subject: Re: Ignoring name constraints with self-issued certs
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Sharon Boeyen wrote:
> Yep, I see that. Now would name constraints actually be a problem in
> that type of environment. With name chaining the subject of the
> previous cert would have the same value as the issuer and subject of
> the self-issued cert. As long as name-constraints on that previous
> cert succeeded, there isn't a problem is there? It's only in the case
> where the cert that contains the name constraint is the one that is
> the direct neighbour to the self issued cert.  I guess I agree with 
> Steve then, (at least this time I don't need to make any changes to
> 509 right??)

A more serious problem is that a self-issued cert might have subject
alternative names. These names will not be constrained by any name
constraints or by name chaining. If the cert is not the last cert in the
path, these subject alternative names are not dangerous. If the cert is
the last cert in the path, they may cause client software to establish
an incorrect <name,key> binding. That's why we need to apply name
constraints to a self-issued certificate if it is the last cert in the
path.

-Steve


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id MAA14075 for <[e-mail]>; Fri, 4 May 2001 12:06:48 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 4 May 2001 19:06:37 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA13641 for <[e-mail]>; Fri, 4 May 2001 15:06:50 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <JY8N44WC>; Fri, 4 May 2001 15:06:49 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.29]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JY8N44V0; Fri, 4 May 2001 15:06:34 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Fri, 04 May 2001 15:06:18 -0400
Subject: Fwd: Re: How to get Base and Delta CRLs for a particular end entity certif icate...
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Opps.  I should have said: "See draft-ietf-pkix-new-part1-06.txt."  Excuse 
the typo.

>Date: Fri, 04 May 2001 14:06:31 -0400
>To: Aslam <[e-mail]>
>From: "Housley, Russ" <[e-mail]>
>Subject: Re: How to get Base and Delta CRLs for a particular end entity 
>certif icate...
>Cc: "'[e-mail]'" <[e-mail]>
>
>Aslam:
>
>See draft-ietf-pkix-new-part1-07.txt.
>
>Section 4.2.1.16 describes an extension in the certificate that points to 
>the delta CRL, and section 5.2.6 describes an extension in the base CRL 
>that points to the delta CRL.  CAs may use either technique.
>
>Russ
>
>At 05:27 PM 5/3/2001 -0400, Aslam wrote:
>>Hi,
>>
>>  I'm working on CRL stuff, I have a question regarding Delta CRL, in
>>  following senario:
>>  I get  a certificate from somewhere, whose validity I have to
>>  check against the CRL mechanism. For this I obtain the CRL Distribution
>>Point extension from
>>  the cert and download the CRL from that location, then I check for
>>  extension and finds that its a base crl, so every thing work good. Now from
>>where
>>  I should get the Delta CRL, if the answer is that these can be obtained
>>  fron the same CRL distribution point then if my first is a delta crl then
>>how
>>  to get the base crl corresponding to a delta crl.
>>
>>  Any help is much more appriciated..
>>
>>  Thanks
>>  Aslam


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id MAA13654 for <[e-mail]>; Fri, 4 May 2001 12:02:16 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 4 May 2001 19:02:05 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA13235 for <[e-mail]>; Fri, 4 May 2001 15:02:17 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <JY8N44T2>; Fri, 4 May 2001 15:02:17 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.29]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JY8N44TG; Fri, 4 May 2001 15:02:11 -0400
From: "Housley, Russ" <[e-mail]>
To: Carlin Covey <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Fri, 04 May 2001 14:58:58 -0400
Subject: RE: Certificate Hold  (was RE: delta CRLs)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Carlin:

>Russ, your feelings on the hold feature were, and are, quite clear.
>I am not advocating inclusion of the hold feature in son-of-rec-2459,
>nor am I proposing that we should delay progress by debating the issue.
>But given that son-of-rfc-2459 contains language related to the hold
>feature, I was wondering what your words "... I will drop it." meant
>with respect to this existing language.  Or perhaps I have not applied
>the "delta emails" correctly and this text has already been dropped?

My "drop it" referred to the discussion on the mail list.

Russ



Received: from netgate.csoft.bg ([e-mail] [193.68.210.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA13307 for <[e-mail]>; Fri, 4 May 2001 11:53:22 -0700 (PDT)
Received: from darkstar (darkstar.csoft.bg [193.68.210.11]) by netgate.csoft.bg (8.12.0.Beta7/8.10.0) with SMTP id f44IrKNA014513 for <[e-mail]>; Fri, 4 May 2001 21:53:20 +0300
Message-ID: <0d8801c0d4cb$9f01d180$[e-mail]>
From: "Nedelcho Stanev" <[e-mail]>
To: <[e-mail]>
References:  <[e-mail]> <[e-mail]> <p05010410b718a7bb95c8@[128.33.4.39]>
Subject: unsubscribe
Date: Fri, 4 May 2001 21:54:17 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2462.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000

unsubscribe



Received: from netgate.csoft.bg ([e-mail] [193.68.210.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA13260 for <[e-mail]>; Fri, 4 May 2001 11:52:54 -0700 (PDT)
Received: from darkstar (darkstar.csoft.bg [193.68.210.11]) by netgate.csoft.bg (8.12.0.Beta7/8.10.0) with SMTP id f44IqoNA014501 for <[e-mail]>; Fri, 4 May 2001 21:52:50 +0300
Message-ID: <0d8201c0d4cb$8d45def0$[e-mail]>
From: "Nedelcho Stanev" <[e-mail]>
To: "PKIX List" <[e-mail]>
References: <[e-mail]>
Subject: unsubscribe
Date: Fri, 4 May 2001 21:53:47 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset="koi8-r"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2462.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000

unsubscribe



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA12660 for <[e-mail]>; Fri, 4 May 2001 11:48:33 -0700 (PDT)
Received: from [128.33.4.39] (comsec.bbn.com [128.33.4.39]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA08202; Fri, 4 May 2001 14:48:17 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010410b718a7bb95c8@[128.33.4.39]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]> <[e-mail]>
Date: Fri, 4 May 2001 14:42:33 -0400
To: "Housley, Russ" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Certificate Hold  (was RE: delta CRLs)
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 1:30 PM -0400 5/4/01, Housley, Russ wrote:
>Carlin:
>
>>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?
>
>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


Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA12505 for <[e-mail]>; Fri, 4 May 2001 11:48:01 -0700 (PDT)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <J432YLB8>; Fri, 4 May 2001 14:47:32 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Tim Polk'" <[e-mail]>, "'Steve Hanna'" <[e-mail]>, PKIX List <[e-mail]>
Subject: RE: Ignoring name constraints with self-issued certs
Date: Fri, 4 May 2001 14:41:05 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D4C9.C6AD1200"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D4C9.C6AD1200
Content-Type: text/plain

Yep, I see that. Now would name constraints actually be a problem in that
type of environment. With name chaining the subject of the previous cert
would have the same value as the issuer and subject of the self-issued cert.
As long as name-constraints on that previous cert succeeded, there isn't a
problem is there? It's only in the case where the cert that contains the
name constraint is the one that is the direct neighbour to the self issued
cert.  I guess I agree with 
Steve then, (at least this time I don't need to make any changes to 509
right??)
 
Sharon
 
 From: Tim Polk [mailto:[e-mail]]
Sent: Friday, May 04, 2001 2:35 PM
To: Sharon Boeyen; 'Steve Hanna'; PKIX List
Subject: RE: Ignoring name constraints with self-issued certs



Sharon,

I can think of one scenario where the end certificate is legitimately
self-issued.  (There may be others.)

Consider a CA that uses separate keys for CRL signing or certificate
management operations.  If that CA issues certificates to itself for those
keys, a PKI client that verifies a signature on a CRL or a message needs to
validate the certificate containing that public key.  In that case, the end
certificate will be self-issued.

Thanks,

Tim

At 02:08 PM 5/4/01 -0400, Sharon Boeyen wrote:



Hi Steve, 

In discussion with PKIX folks when we were working on the defect report 
for name constraints, I don't recall any specific discussion of that type 
of a path (with a self issued cert at the end). The defect report doesn't 
change that particular text that you mention, but I suspect that the fact 
that it catches this 'hole' is probably more coincidental that deliberate. 

I'm curious whether you think there are legitimate situations where the 
final cert would be a self issued one, or whether you are suggesting that 
the fact that it could happen is a threat. Not that it would change the 
outcome, I'm just wondering which perspective you're coming from so that 
I can understand the issue better. 

Thanks 
Sharon  



------_=_NextPart_001_01C0D4C9.C6AD1200
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">


<META content="MSHTML 5.50.4522.1800" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=645123918-04052001><FONT face=Arial color=#0000ff size=2>Yep, I 
see that. Now would name constraints actually be a problem in that type of 
environment. With name chaining the subject of the previous cert would have the 
same value as the issuer and subject of the self-issued cert. As long as 
name-constraints on that previous cert succeeded, there isn't a problem is 
there? It's only in the case where the cert that contains the name constraint is 
the one that is the direct neighbour to the self issued cert.&nbsp; I guess I 
agree with </FONT></SPAN></DIV>
<DIV><SPAN class=645123918-04052001><FONT face=Arial color=#0000ff size=2>Steve 
then, (at least this time I don't need to make any changes to 509 
right??)</FONT></SPAN></DIV>
<DIV><SPAN class=645123918-04052001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=645123918-04052001><FONT face=Arial color=#0000ff 
size=2>Sharon</FONT></SPAN></DIV>
<DIV><FONT face=Tahoma><FONT size=2><SPAN class=645123918-04052001><FONT 
face=Arial color=#0000ff></FONT></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=Tahoma><FONT size=2><SPAN 
class=645123918-04052001>&nbsp;</SPAN><STRONG>From:</STRONG> Tim Polk 
[mailto:[e-mail]]<BR><B>Sent:</B> Friday, May 04, 2001 2:35 
PM<BR><B>To:</B> Sharon Boeyen; 'Steve Hanna'; PKIX List<BR><B>Subject:</B> RE: 
Ignoring name constraints with self-issued certs<BR><BR></DIV></FONT></FONT>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">Sharon,<BR><BR>I 
  can think of one scenario where the end certificate is legitimately 
  self-issued.&nbsp; (There may be others.)<BR><BR>Consider a CA that uses 
  separate keys for CRL signing or certificate management operations.&nbsp; If 
  that CA issues certificates to itself for those keys, a PKI client that 
  verifies a signature on a CRL or a message needs to validate the certificate 
  containing that public key.&nbsp; In that case, the end certificate will be 
  self-issued.<BR><BR>Thanks,<BR><BR>Tim<BR><BR>At 02:08 PM 5/4/01 -0400, Sharon 
  Boeyen wrote:<BR><BR><FONT size=2>
  <BLOCKQUOTE cite type="cite">Hi Steve, <BR></FONT><BR>In discussion with 
    PKIX folks when we were working on the defect report <BR>for name 
    constraints, I don't recall any specific discussion of that type <BR>of a 
    path (with a self issued cert at the end). The defect report doesn't 
    <BR>change that particular text that you mention, but I suspect that the 
    fact <BR>that it catches this 'hole' is probably more coincidental that 
    deliberate. <BR><BR><FONT size=2>I'm curious whether you think there are 
    legitimate situations where the </FONT><BR>final cert would be a self issued 
    one, or whether you are suggesting that <BR>the fact that it could happen is 
    a threat. Not that it would change the <BR>outcome, I'm just wondering which 
    perspective you're coming from so that <BR>I can understand the issue 
    better. <BR><BR><FONT size=2>Thanks</FONT> <BR><FONT size=2>Sharon&nbsp; 
    <BR></FONT></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C0D4C9.C6AD1200--


Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA11559 for <[e-mail]>; Fri, 4 May 2001 11:37:39 -0700 (PDT)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id OAA12446; Fri, 4 May 2001 14:37:31 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 04 May 2001 14:35:23 -0400
To: Sharon Boeyen <[e-mail]>, "'Steve Hanna'" <[e-mail]>, PKIX List <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: RE: Ignoring name constraints with self-issued certs
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"

<html>
Sharon,<br>
<br>
I can think of one scenario where the end certificate is legitimately
self-issued.&nbsp; (There may be others.)<br>
<br>
Consider a CA that uses separate keys for CRL signing or certificate
management operations.&nbsp; If that CA issues certificates to itself for
those keys, a PKI client that verifies a signature on a CRL or a message
needs to validate the certificate containing that public key.&nbsp; In
that case, the end certificate will be self-issued.<br>
<br>
Thanks,<br>
<br>
Tim<br>
<br>
At 02:08 PM 5/4/01 -0400, Sharon Boeyen wrote:<br>
<br>
<font size=2><blockquote type=cite cite>Hi Steve, <br>
</font><br>
In discussion with PKIX folks when we were working on the defect report
<br>
for name constraints, I don't recall any specific discussion of that type
<br>
of a path (with a self issued cert at the end). The defect report doesn't
<br>
change that particular text that you mention, but I suspect that the fact
<br>
that it catches this 'hole' is probably more coincidental that
deliberate. <br>
<br>
<font size=2>I'm curious whether you think there are legitimate
situations where the </font><br>
final cert would be a self issued one, or whether you are suggesting that
<br>
the fact that it could happen is a threat. Not that it would change the
<br>
outcome, I'm just wondering which perspective you're coming from so that
<br>
I can understand the issue better. <br>
<br>
<font size=2>Thanks</font> <br>
<font size=2>Sharon&nbsp; <br>
</font></blockquote></html>



Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA11124 for <[e-mail]>; Fri, 4 May 2001 11:34:47 -0700 (PDT)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id J0AR52QM; Fri, 4 May 2001 11:29:25 -0700
From: "Carlin Covey" <[e-mail]>
To: "Housley, Russ" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Certificate Hold  (was RE: delta CRLs)
Date: Fri, 4 May 2001 11:34:31 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

Russ, your feelings on the hold feature were, and are, quite clear.
I am not advocating inclusion of the hold feature in son-of-rec-2459,
nor am I proposing that we should delay progress by debating the issue.
But given that son-of-rfc-2459 contains language related to the hold
feature, I was wondering what your words "... I will drop it." meant
with respect to this existing language.  Or perhaps I have not applied
the "delta emails" correctly and this text has already been dropped?

>From draft-ietf-pkix-new-part1-05.txt, section 5.2.4 :

     If a CA supports the certificateHold revocation reason the
     following rules must be applied when generating delta CRLs:
     (a) If a certificate was listed as revoked with revocation
         reason certificateHold on a CRL (either a delta CRL or
         a CRL that is complete for a given scope), whose cRLNumber
         is n, and the hold is subsequently released, the certificate
         must be included in all delta CRLs issued after the hold is
         released where the cRLNumber of the referenced base CRL is
         less than or equal to n. The certificate must be listed with
         revocation reason removeFromCRL unless the certificate is
         subsequently revoked again for one of the revocation reasons
         covered by the delta CRL, in which case the certificate must
         be listed with the revocation reason appropriate for the subsequent
         revocation.
     (b) If the certificate was not removed from hold, but was permanently
         revoked, then it must be listed on all subsequent delta CRLs
         where the cRLNumber of the referenced base CRL is less than the
         cRLNumber of the CRL (either a delta CRL or a CRL that is complete
         for the given scope) on which the permanent revocation notice first
         appeared.

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Friday, May 04, 2001 10:30 AM
To: Carlin Covey
Cc: [e-mail]
Subject: RE: Certificate Hold (was RE: delta CRLs)


Carlin:

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

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.

Clear?

Russ



Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id LAA09825 for <[e-mail]>; Fri, 4 May 2001 11:17:53 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 4 May 2001 18:17:42 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA09895 for <[e-mail]>; Fri, 4 May 2001 14:17:51 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <JY8N4TX8>; Fri, 4 May 2001 14:17:50 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.116]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JY8N4TXZ; Fri, 4 May 2001 14:17:36 -0400
From: "Housley, Russ" <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Fri, 04 May 2001 14:16:22 -0400
Subject: Re: delta-CRLs
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Denis:

I can live with these.

>Taking into account the last proposal from Russ, this would
>lead to the two following paragraphs:
>
>    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. Applications that support
>    delta CRLs MUST ensure that time T falls between thisUpdate and
>    nextUpdate for both the base CRL and the delta CRL.
>
>    Note: An application could also reconstruct an updated CRL, for
>    a specific time T, by using a previously locally reconstructed CRL
>    based on a given base CRL, and combining it with a delta CRL which
>    contains a delta CRL indicator extension with the same CRL number as
>    the base CRL.

Russ


Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA09423 for <[e-mail]>; Fri, 4 May 2001 11:15:37 -0700 (PDT)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <J432YK9W>; Fri, 4 May 2001 14:15:07 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Steve Hanna'" <[e-mail]>, PKIX List <[e-mail]>
Subject: RE: Ignoring name constraints with self-issued certs
Date: Fri, 4 May 2001 14:08:43 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D4C5.4105F850"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D4C5.4105F850
Content-Type: text/plain

Hi Steve, 

In discussion with PKIX folks when we were working on the defect report 
for name constraints, I don't recall any specific discussion of that type 
of a path (with a self issued cert at the end). The defect report doesn't 
change that particular text that you mention, but I suspect that the fact 
that it catches this 'hole' is probably more coincidental that deliberate.

I'm curious whether you think there are legitimate situations where the 
final cert would be a self issued one, or whether you are suggesting that 
the fact that it could happen is a threat. Not that it would change the 
outcome, I'm just wondering which perspective you're coming from so that 
I can understand the issue better.

Thanks
Sharon  



------_=_NextPart_001_01C0D4C5.4105F850
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: Ignoring name constraints with self-issued certs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hi Steve, </FONT>
</P>

<P><FONT SIZE=2>In discussion with PKIX folks when we were working on the defect report </FONT>
<BR><FONT SIZE=2>for name constraints, I don't recall any specific discussion of that type </FONT>
<BR><FONT SIZE=2>of a path (with a self issued cert at the end). The defect report doesn't </FONT>
<BR><FONT SIZE=2>change that particular text that you mention, but I suspect that the fact </FONT>
<BR><FONT SIZE=2>that it catches this 'hole' is probably more coincidental that deliberate.</FONT>
</P>

<P><FONT SIZE=2>I'm curious whether you think there are legitimate situations where the </FONT>
<BR><FONT SIZE=2>final cert would be a self issued one, or whether you are suggesting that </FONT>
<BR><FONT SIZE=2>the fact that it could happen is a threat. Not that it would change the </FONT>
<BR><FONT SIZE=2>outcome, I'm just wondering which perspective you're coming from so that </FONT>
<BR><FONT SIZE=2>I can understand the issue better.</FONT>
</P>

<P><FONT SIZE=2>Thanks</FONT>
<BR><FONT SIZE=2>Sharon&nbsp; </FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C0D4C5.4105F850--


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id LAA08629 for <[e-mail]>; Fri, 4 May 2001 11:06:52 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 4 May 2001 18:06:41 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA08900 for <[e-mail]>; Fri, 4 May 2001 14:06:53 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <JY8N4TQW>; Fri, 4 May 2001 14:06:53 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.116]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JY8N4TQS; Fri, 4 May 2001 14:06:45 -0400
From: "Housley, Russ" <[e-mail]>
To: Aslam <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Fri, 04 May 2001 14:06:31 -0400
Subject: Re: How to get Base and Delta CRLs for a particular end entity certif icate...
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Aslam:

See draft-ietf-pkix-new-part1-07.txt.

Section 4.2.1.16 describes an extension in the certificate that points to 
the delta CRL, and section 5.2.6 describes an extension in the base CRL 
that points to the delta CRL.  CAs may use either technique.

Russ

At 05:27 PM 5/3/2001 -0400, Aslam wrote:
>Hi,
>
>  I'm working on CRL stuff, I have a question regarding Delta CRL, in
>  following senario:
>  I get  a certificate from somewhere, whose validity I have to
>  check against the CRL mechanism. For this I obtain the CRL Distribution
>Point extension from
>  the cert and download the CRL from that location, then I check for
>  extension and finds that its a base crl, so every thing work good. Now from
>where
>  I should get the Delta CRL, if the answer is that these can be obtained
>  fron the same CRL distribution point then if my first is a delta crl then
>how
>  to get the base crl corresponding to a delta crl.
>
>  Any help is much more appriciated..
>
>  Thanks
>  Aslam



Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id LAA08141 for <[e-mail]>; Fri, 4 May 2001 11:03:58 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 4 May 2001 18:03:47 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA08694 for <[e-mail]>; Fri, 4 May 2001 14:04:00 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <JY8N4T36>; Fri, 4 May 2001 14:03:59 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.116]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JY8N4T3W; Fri, 4 May 2001 14:03:48 -0400
From: "Housley, Russ" <[e-mail]>
To: Carlin Covey <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Fri, 04 May 2001 13:30:14 -0400
Subject: RE: Certificate Hold  (was RE: delta CRLs)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Carlin:

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

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.

Clear?

Russ


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA05111 for <[e-mail]>; Fri, 4 May 2001 10:15:21 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <K2M3JGPR>; Fri, 4 May 2001 13:14:49 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Tim Polk'" <[e-mail]>, Denis Pinkas <[e-mail]>, "David A. Cooper" <[e-mail]>
Cc: [e-mail]
Subject: RE: delta-CRLs
Date: Fri, 4 May 2001 13:08:31 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D4BC.D898DA10"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D4BC.D898DA10
Content-Type: text/plain

Sorry to help 'drag out' this discussion, but a couple of points:

1) Denis, your comment about CRL numbers needing to be unique, regardless of
the scope of the CRL is incorrect. Check the text in 509 clause 8.5.2.1 (CRL
number extension) which says "This CRL extension field conveys a
montonically increasing sequence number for each CRL issued by a given CRL
issuer through a given authority directory attribute or CRL distribution
point. ..."  

For that reason, another extension was added (see 8.5.2.7 of 509) called
cRLStreamIdentifier. This is used to identify the context within which the
CRL number is unique. 

Second, I want to make sure everyone understands that the quote from 97 509
12.6.3.3 by David is text that was replaced in the 4th edition because it
was overly restrictive. 

As for the length of messages, I know I find myself constantly quoting 509.
Others do the same and others quote 2459. I do believe the editors have
worked closely together to ensure that what we end up with in PKIX is a
profile of 509 (with changes being made to both documents as required).
However, I can't help but wonder if we could cut down on the length of some
of these messages if everyone who cares about the topic would first go and
read both documents before submitting messages that purport to state what
the standards say. This discussion is taking a lot of time on the part of
many people and perhaps we could cut down on some of that by going back and
reading what the standards say. 

(It's friday afternoon, what can I say :-)

Sharon

------_=_NextPart_001_01C0D4BC.D898DA10
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: delta-CRLs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Sorry to help 'drag out' this discussion, but a =
couple of points:</FONT>
</P>

<P><FONT SIZE=3D2>1) Denis, your comment about CRL numbers needing to =
be unique, regardless of the scope of the CRL is incorrect. Check the =
text in 509 clause 8.5.2.1 (CRL number extension) which says &quot;This =
CRL extension field conveys a montonically increasing sequence number =
for each CRL issued by a given CRL issuer through a given authority =
directory attribute or CRL distribution point. ...&quot;&nbsp; =
</FONT></P>

<P><FONT SIZE=3D2>For that reason, another extension was added (see =
8.5.2.7 of 509) called cRLStreamIdentifier. This is used to identify =
the context within which the CRL number is unique. </FONT></P>

<P><FONT SIZE=3D2>Second, I want to make sure everyone understands that =
the quote from 97 509 12.6.3.3 by David is text that was replaced in =
the 4th edition because it was overly restrictive. </FONT></P>

<P><FONT SIZE=3D2>As for the length of messages, I know I find myself =
constantly quoting 509. Others do the same and others quote 2459. I do =
believe the editors have worked closely together to ensure that what we =
end up with in PKIX is a profile of 509 (with changes being made to =
both documents as required). However, I can't help but wonder if we =
could cut down on the length of some of these messages if everyone who =
cares about the topic would first go and read both documents before =
submitting messages that purport to state what the standards say. This =
discussion is taking a lot of time on the part of many people and =
perhaps we could cut down on some of that by going back and reading =
what the standards say. </FONT></P>

<P><FONT SIZE=3D2>(It's friday afternoon, what can I say :-)</FONT>
</P>

<P><FONT SIZE=3D2>Sharon</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0D4BC.D898DA10--


Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA03325 for <[e-mail]>; Fri, 4 May 2001 09:48:53 -0700 (PDT)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10131 for <[e-mail]>; Fri, 4 May 2001 09:48:54 -0700 (PDT)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28341 for <[e-mail]>; Fri, 4 May 2001 12:48:53 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 04 May 2001 12:44:34 -0400
From: Steve Hanna <[e-mail]>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: PKIX List <[e-mail]>
Subject: Ignoring name constraints with self-issued certs
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Regretfully, I must raise another issue with son-of-2459. In section
4.2.1.11 of draft-ietf-pkix-new-part1-06.txt, it says:

   Name constraints are not applied to certificates whose issuer and
   subject are identical.  (This could prevent CAs that use name
   constraints from issuing self-signed certificates to implement key
   rollover.)

This statement is consistent with the validation algorithm in section
6.1, which says:

   A certificate is termed self-issued if the DNs that appear in the
   subject and issuer fields are identical and are not empty.  In
   general, the issuer and subject of the certificates that make up a
   path are different for each certificate.  However, a CA may issue a
   certificate to itself to support key rollover or changes in
   certificate policies.  These self-issued certificates are not
   counted when evaluating path length or name constraints.

However, these statements (and the corresponding text in the validation
algorithm, steps (b) and (c) of section 6.1.3) are not consistent with
the text in X.509(2000), which says (in step g of section 10.5.1) "If
the certificate is not an intermediate self-issued certificate, check
that the subject name is within the name-space given by the value of
permitted-subtrees and is not within the name-space given by the value
of excluded-subtrees."

Note the word *intermediate* in X.509(2000). If a self-issued
certificate is the last certificate in the path, the name constraints
check MUST be performed. Otherwise, a security hole is opened up.
Consider the following chain of 2 certificates:

Certificate 1:
 Issuer:  o=trusty, c=us
 Subject: o=shady, c=us
 Basic Constraints:
  cA=true
 Name Constraints:
  Permitted:
   directoryName: o=shady, c=us
   rfc822Name: .shady.com

Certificate 2:
 Issuer:  o=shady, c=us
 Subject: o=shady, c=us
 SubjectAltNames:
  rfc822Name: [e-mail]

If o=trusty, c=us is one of the trust anchors (and the certificate
signatures verify), this chain is valid according to son-of-2459. It is
not valid according to X.509(2000). I think you will agree that the
behavior described in X.509(2000) is correct. Otherwise, self-issued
certificates can be used to completely bypass the effects of name
constraints.

Therefore, I suggest that section 4.2.1.11 of
draft-ietf-pkix-new-part1-06.txt be modified to say:

   Name constraints are not applied to certificates whose issuer and
   subject are identical (unless the certificate is the final
   certificate in the path).  (This could prevent CAs that use name
   constraints from issuing self-signed certificates to implement key
   rollover.)

We should also modify the last sentence of the paragraph in section 6.1
that begins "A certificate is termed self-issued ..." (listed in full
above) to "These self-issued certificates are not counted when
evaluating path length. Name constraints are only applied to a
self-issued certificate if it is the final certificate in the path."

I also suggest that the start of steps (b) and (c) in section 6.1.3 be
changed to read:

      (b) If certificate i is self-issued and it is not the final
      certificate in the path, skip this step for certificate i.
      Otherwise, verify that the subject name is within one of the
      permitted_subtrees for X.500 distinguished names, and verify
      that each of the alternative names in the subjectAltName
      extension (critical or non-critical) is within one of the
      permitted_subtrees for that name type.

      (c) If certificate i is self-issued and it is not the final
      certificate in the path, skip this step for certificate i.
      Otherwise, verify that the subject name is not within one of the
      excluded_subtrees for X.500 distinguished names, and verify that
      each of the alternative names in the subjectAltName extension
      (critical or non-critical) is not within one of the
      excluded_subtrees for that name type.

Comments?

Steve


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA29997 for <[e-mail]>; Fri, 4 May 2001 08:58:33 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA13642; Fri, 4 May 2001 17:58:27 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA09178; Fri, 4 May 2001 17:57:59 +0200
Message-ID: <[e-mail]>
Date: Fri, 04 May 2001 17:57:58 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "David A. Cooper" <[e-mail]>
CC: [e-mail]
Subject: Re: delta-CRLs
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

David,

As I just said in the e-mail I sent to Tim, I would appreciate that you
coordinate your responses with Tim.

I cannot sustain any more so long e-mails.

I believe that we have now a private conference call on next Wednesday on
this topic.

Please read carefully the e-mails sent to Tim.

Regards,

Denis

> At 02:22 PM 5/4/01 +0200, Denis Pinkas wrote:
> 
> > David,
> >
> > This thread is now taking me (too) much time for my processing power.
> > :-(
> >
> > > At 06:05 PM 5/2/01 +0200, Denis Pinkas wrote:
> > >
> > > >> The current is wrong on two major aspects:
> > > >>
> > > >> a) the numbering of the delta CRLs
> > > >
> > >
> > > Since you claim to want to support "traditional" delta-CRLs, I will
> > quote
> > > the text on delta-CRLs from section 12.6.3.3 of X.509 3rd edition
> > (1997):
> > >
> > > a delta-CRL shall not be issued without a corresponding complete
> > > CRL being issued at the same time. The value of the CRL number,
> > > as conveyed in the CRL number extension field (if present), shall
> > > be identical for both the delta-CRL and the corresponding complete CRL
> > >
> > > Similar text was included in one of the old proposed draft amendments
> > to
> > > the 1997 standard:
> > >
> > > At reset time, concurrent with publication of a new base CRL is
> > > publication of the final delta-CRL for the old base CRL. Both CRLs
> > > published concurrently (new base and final delta for old base) shall
> > > contain identical values of the cRLNumber extension as well as
> > > identical values of thisUpdate time. The values of nextUpdate time
> > > will be different in each.
> > >
> > > Both texts are quite clear that when a complete CRL and a delta-CRL
> > are
> > > issued at the same time, and the two CRLs provide the same
> > information,
> > > they must have the same cRLnumber. This is because the are effectively
> > two
> > > instantiations of the same CRL.
> >
> > The ISO text has two major problems:
> >
> > 1) It makes a major assumption, ... which is wrong: once a CA has
> > started to
> > issue a base CRL (and hence it will issue delta-CRLs) then it must do it
> > for
> > ever. A CA can issue a base CRL and then delta CRLs but then simply
> > issue
> > complete CRL (i.e. full CRLs that do not support the delta mechanism)
> > and
> > later one can start to issue a base a delta CRLs again.
> 
> I not sure why you think the text is making an assumption, but there seems
> to be a misunderstanding here. There is nothing special about a base CRL.
> There are no flags that are placed in a CRL to indicate that it is a base
> CRL. A base CRL is simply "[a] CRL that is used as the foundation in the
> generation of a dCRL" [X.509 4th ed.] Thus, any CRL that is referenced in
> the BaseCRLNumber field of a delta-CRL is a base CRL. The
> deltaCRLIndicator extension imposes a requirement that only CRLs that were
> issued as complete for scope CRLs can be used as base CRLs, but this is
> beside the point. One does not issue a "base CRL" to advertise that
> delta-CRLs will be issued in the future. One issues full CRLs. If, at some
> point in the future, a delta-CRL species a full CRL as its base, then that
> full CRL is a base CRL.
> 
> > 2)  RFC 2459 in section 5.2.3 (CRL Number) says:
> >
> >    The CRL number is a non-critical CRL extension which conveys a
> >    monotonically increasing sequence number for each CRL issued by a CA.
> >
> > Since two CRLs (whether they are base, delta, complete, whatever) cannot
> > have the same number, this means that the following sentence extracted
> > from
> > the ISO text is wrong: "The value of the CRL number, as conveyed in the
> > CRL
> > number extension field (if present), shall be identical for both the
> > delta-CRL and the corresponding complete CRL".
> 
> 
> Again, you are misinterpreting this text. If a full CRL and a delta-CRL
> cover the set of certificates and revocation reasons (i.e., scope) and are
> issued at the same time, then they are effectively two instantiations of
> the same CRL. They must then (as the standard requires) have the same
> cRLNumber.
> 
> > > Notice also that the requirement is that when a new base is issued,
> > the
> > > delta that is issued at the same time provides changes since the
> > previous
> > > base.
> >
> > This is wrong as well because there is not necessarilly this previous
> > base
> > (see the first major problem).
> >
> > > One does not issue an empty delta. If one did, then every relying
> > > party would be forced to download every base CRL.
> >
> > This is the intent, otherwise delta CRLs would grow for ever.
> 
> This is not true. I have constructed an example below (hopefully it is
> well formatted so that it is readable). The example below shows the
> "traditional" method of issuing delta-CRLs. In this example, full CRLs are
> issued once every 3 hours and deltas are issued once an hour. As you have
> stated, if one wishes to begin issuing deltas at the same time that the
> very first full CRL, the delta must use the concurrently issued full CRL
> as its base. After that, however, a delta can always use a previously
> issued full CRL as its base. Notice that starting with cRLNumber 4, the
> delta CRL issued at the same time as a full CRL uses the previously issued
> full CRL as its base. However, the delta-CRLs never provide more than 3
> hours of history. They do not grow forever.
> 
> current   revoked
> time       certificates full CRL                        delta-CRL
> ------------------------------------------------------------
> 12:00           {14}            cRLNumber = 1                   cRLNumber
> = 1
>                                 thisUpdate = 12:00              thisUpdate
> = 12:00
>                                 nextUpdate = 15:00              nextUpdate
> = 13:00
>                                                                 BaseCRLNumber
> = 1
>                                 CertificateList =
> {14}          CertificateList = {}
> 
> 13:00           {14, 124}                                       cRLNumber
> = 2
>                                                                 thisUpdate
> = 13:00
>                                                                 nextUpdate
> = 14:00
>                                                                 BaseCRLNumber
> = 1
>                                                                 CertificateList
> = {124}
> 
> 14:00           {14, 124}                                       cRLNumber
> = 3
>                                                                 thisUpdate
> = 14:00
>                                                                 nextUpdate
> = 15:00
>                                                                 BaseCRLNumber
> = 1
>                                                                 CertificateList
> = {124}
> 
> 15:00           {14, 124, 39}   cRLNumber = 4                   cRLNumber
> = 4
>                                 thisUpdate = 15:00              thisUpdate
> = 15:00
>                                 nextUpdate = 18:00              nextUpdate
> = 16:00
>                                                                 BaseCRLNumber
> = 1
>                                 CertificateList = {14, 124,
> 39} CertificateList = {124, 39}
> 
> 16:00           {14, 124, 39,                                   cRLNumber
> = 5
>                  67}                                            thisUpdate
> = 16:00
>                                                                 nextUpdate
> = 17:00
>                                                                 BaseCRLNumber
> = 4
>                                                                 CertificateList
> = {67}
> 
> 17:00           {14, 124, 39,                                   cRLNumber
> = 6
>                  67}                                            thisUpdate
> = 17:00
>                                                                 nextUpdate
> = 18:00
>                                                                 BaseCRLNumber
> = 4
>                                                                 CertificateList
> = {67}
> 
> 18:00           {14, 124, 39,   cRLNumber = 7                   cRLNumber
> = 7
>                  67}            thisUpdate = 18:00              thisUpdate
> = 18:00
>                                 nextUpdate = 21:00              nextUpdate
> = 19:00
>                                                                 BaseCRLNumber
> = 4
>                                 CertificateList = {14, 124,
> 39, CertificateList = {67}
>                                                          21}
> 
> 19:00           {14, 124, 39,                                   cRLNumber
> = 8
>                  67}                                            thisUpdate
> = 19:00
>                                                                 nextUpdate
> = 20:00
>                                                                 BaseCRLNumber
> = 7
>                                                                 CertificateList
> = {}
> 
> > > >> b) the lack of use of the fields thisUpdate and nextUpdate in the
> > > >> delta-CRLs.
> >
> > > As I stated before, the thisUpdate field specifies the time at which
> > the
> > > CRL was issued. There is absolutely no reason to check that the
> > current
> > > time is after thisUpdate.
> >
> > There is no notion of current time. The evaluation is made at time T,
> > which
> > may be the current time or a time in the past.
> 
> In the note to which I was responding, you had proposed the following
> text:
> 
> > > > > An application can construct a CRL that is the most current for
> > > > > a given scope, at the current time, by retrieving the current
> > > > > 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 current date from that delta-CRL is between
> > > > > thisUpdate and nextUpdate;
> 
> In the proposed text, you specifically stated that the goal was to
> construct a CRL that is most current *at the current time*. If the text is
> changed to also describe how to determine the status of a certificate at
> some point in the past, then the situation becomes more complicated.
> 
> > > The nextUpdate field in a delta-CRL has the same meaning an in any
> > other
> > > type of CRL, so there is no reason to discuss it here. As I said
> > before,
> > > though, one can not say that any CRL whose nextUpdate time has not
> > passed
> > > is the most current. There may have been an "emergency" CRL issued
> > since
> > > that one was issued. If nextUpdate has passed, then you know the CRL
> > is
> > > not the most current. If nextUpdate has not passed, then the CRL MAY
> > be
> > > the most current, but there is no way to know for certain.
> >
> > See my response to Tim on that topic.
> 
> I saw your response. X.509 states: "nextUpdate, if present, indicates the
> date/time by which the next revocation list in this series will be issued.
> The next revocation list could be issued before the indicated date, but it
> will not be issued any later than the indicated time." While the term
> "emergency CRL" is not in the text, it does state that a new CRL may be
> issued before the date indicated in nextUpdate. Can you find anywhere in
> the text that suggests that this does not apply to delta-CRLs?
> 
> > > >> > They seem to depart from the traditional
> > > >> > deltas in certain details,
> > > >>
> > > >> They certainly do not.
> >
> > > As I stated above, you state that whenever a base CRL is issued, an
> > empty
> > > delta-CRL should be issued at the same time, with the delta-CRL using
> > the
> > > concurrently issued base CRL as its base. This is not how traditional
> > > delta-CRLs work.
> >
> > Think about it. To do that you have to take an example: a *first* base
> > CRL
> > is issued at midnight (no base CRL *ever* exists before). A delta is
> > supposed to be issued every hour. Think first about the processing done
> > by a
> > relying party at 3:30 a.m. Then think about the processing that will be
> > done
> > at 0:30 a.m. You will then come to the same conclusion. Now if a base
> > existed before, then the proposal would not be consistant with the
> > definition of the construction of the updated CRL which is:
> >
> >    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.
> >
> > Futhermore, the size of the delta CRLs would grow for ever.
> 
> Not true. See the example above.
> 
> > > >> > but prevent use of sliding window deltas.
> > > >>
> > > >> Maybe. However, if you really want them to be part of this
> > document,
> > > >> then
> > > >> they MUST *not* be mandatory. So the only way would be to add
> > > >> additional
> > > >> text that would explain how this can be done as an option. However
> > I
> > > >> got the
> > > >> fealing that the traditional method may be in some way incompatible
> > > >> with the
> > > >> sliding window deltas, i.e. if the sliding method is chosen by the
> > CRL
> > > >> Issuer relying parties may have difficulties to use the traditional
> > > >> method.
> > > >> But, maybe, you have the right text just ready to explain how this
> > can
> > > >> be
> > > >> done. :-)
> >
> > > When I referred to the "traditional" method in my paper, I was
> > referring
> > > to the way delta-CRLs are issued, not how they are processed by
> > relying
> > > parties. Notice, however, that the deltaCRLIndicator requires that
> > "[t]he
> > > base CRL referenced by a deltaCRLIndicator extension shall be a CRL
> > that
> > > is issued as complete for its scope (i.e. it is not itself a dCRL)."
> > If by
> > > "relying parties using the traditional method" you mean always
> > applying
> > > the delta-CRL to a full CRL whose cRLNumber is equal to the value in
> > > BaseCRLNumber, this requirement on the deltaCRLIndicator extension
> > ensures
> > > that this can be done no matter how delta-CRLs are issued (traditional
> > > method, sliding window, or other). I don't think that anyone ever
> > intended
> > > for this to be way that delta-CRLs are processed, but you can do it if
> > you
> > > want.
> >
> > I undersand clearly that you would like relying parties to take
> > advantage of
> > sliding windows, by the "algorithm" that you proposed, which is based on
> > the
> > ISO text, has flaws in it. See above.
> 
> Your belief that there are flaws in the ISO text is based on a
> misinterpretation of the cRLNumber field. Since this field is vital to the
> efficient use of delta-CRLs, this misinterpretation may be the reason for
> your confusion.
> 
> > > Even if delta-CRLs are issued using the "traditional" method, relying
> > > parties may choose to maintain a locally generated revocation list
> > which
> > > they update which each successive delta-CRL that they download.
> >
> > I have addressed that point in details in my response to Tim. I think we
> > agree on this point.
> 
> The text on delta-CRLs has two basic parts. One part, which is normative,
> describes what information a CRL issuer needs to place in a delta-CRL. The
> other part, which is informative, describes what information relying
> parties need to make use of delta-CRLs. If we use your text (below), then
> we are being less informative than we could be.
> 
>         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.
> 
> The text hides from implementers the fact that a delta-CRL may be used in
> conjunction with a full CRL that was issued after the referenced base CRL
> was issued. The follow-up text ("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.") is only a source of confusion. The text above does not
> describe an algorithm, it merely states what information is required to
> construct an updated CRL using base CRLs and delta-CRLs. An algorithm
> would state how to construct an updated CRL.
> 
> > > >> > >[David] A delta-CRL is nearly the same as a full CRL. It has a
> > > >> thisUpdate,
> > > >> > >nextUpdate, cRLNumber, etc. just as a full CRL. It just has an
> > > >> incomplete
> > > >> > >list of revoked certificates.
> > > >> > >
> > > >> > >[Denis] Yes, but you have to explain detail how a relying party
> > > >> will use
> > > >> > >thisUpdate, nextUpdate for a base CRL and thisUpdate, nextUpdate
> > > >> for a delta
> > > >> > >to make sure that in both cases he got the freshest information.
> > > >
> >
> > > There is no way, using CRLs, to ensure that you have the freshest
> > > information.
> >
> > True. But if you are using both base CRLs and delta-CRLs then you have
> > that
> > guaranty up to the period of refresh of the delta-CRL (which is of
> > course
> > much better than the period of refresh from the base CRL).
> 
> At time T, you know that the information in a CRL (any type of CRL) is no
> older than T - thisUpdate. There is no guarantee that another CRL was not
> issued after thisUpdate, even if  T < nextUpdate (see above).
> 
> > > >> > >[Denis]
> > > >> > >
> > > >> > >As said later, your paper provides the right answer (on page 1):
> > "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 text says " *a* specific, previously issued CRL", it
> > does NOT say
> > > >> > >"or any, more recently, issued CRL".
> >
> > > You are misinterpreting the quote. The sentence states what
> > information is
> > > provided in a delta-CRL. It does not say anything about how the
> > delta-CRL
> > > can be used. A delta-CRL provides information about certificates whose
> > > statuses have changed since the issuance of a specific, previously
> > issued
> > > CRL. The delta-CRL may, however, be applied to more recently issued
> > CRLs.
> >
> > In the same spirit as you did, I could say that we would need a machine
> > that
> > allows people to travel in the future. However, delta-CRLs cannot be
> > applied
> > to more recently issued CRLs, unless you provide a clear example of how
> > this
> > can be done.
> 
> OK. Here is an example. Suppose that you have a delta-CRL with a cRLNumber
> of 8 and a BaseCRLNumber of 5. You also have a full CRL with a cRLNumber
> of 6. The following algorithm can then be used to determine the status of
> a certificate that is covered by the CRL at the time that the delta-CRL
> was issued (assume the certificate in question has serial number 153):
> 
> 1) If 153 is listed on full CRL number 6, but not the delta-CRL, then it
> is revoked with the revocation reason stated in full CRL number 6.
> 
> 2) If 153 is listed on the delta-CRL with a revocation reason of
> removeFromCRL, then it would not be found on a full CRL issued at the time
> the delta-CRL was issued. In this case it does not matter whether 153 was
> listed on full CRL number 6. The reason that it would not be on the full
> CRL (number 8) is unknown. It could either be that the certificate was
> removed from hold or that the certificate expired.
> 
> 3) If 153 is listed on the delta-CRL with a revocation reason other than
> removeFromCRL, then it is revoked with the revocation reason stated in the
> delta-CRL. Again, in this case, it does not matter whether 153 was listed
> on full CRL number 6.
> 
> 4) If 153 is not listed on either full CRL number 6 or the delta-CRL, then
> it is not revoked (or it expired before CRL number 6 was issued).
> 
> I created this algorithm on the fly, so it may not be perfect, but it
> should be sufficiently close to correct to be understandable. Notice,
> however, that the cRLNumber field is very important here. In order for
> this algorithm to work you must ensure that cRLNumber of the full CRL you
> use is greater than or equal to the BaseCRLNumber in the delta-CRL and
> less than the cRLNumber in the delta-CRL. One must be able to compare the
> CRL numbers in order to check that the delta-CRL and full CRL can be
> combined.
> 
> > > >> > > > >This paper is proposing a method for over-issuing the CRLs.
> > It omits to take
> > > >> > > > >into consideration that in PKIX-1 we mandate the CRL number
> > extension
> > > >> > > > >(section 5.2.3) so we need to advertise the nextUpdate. If
> > you issue a CRL
> > > >> > > > >before the next update you have no more way to know which
> > base CRL is the
> > > >> > > > >freshest CRL. I believe this is a major security weakness
> > and for that
> > > >> > > > >reason this mechanism should be deprecated.
> >
> > > Over-issuing is really out-of-scope for this discussion. However,
> > > over-issuing is merely one way to distribute revocation information
> > more
> > > efficiently. If you issue CRLs once every 4 hours and I issue CRLs
> > once an
> > > hour, but with a nextUpdate time 4 hours in the future, the
> > information
> > > relying parties get from me will be no more stale than the information
> > > they get from you. If there is any "security weakness" it is from the
> > > delay in distributing revocation information, not from over-issuing.
> >
> > Over-issuing of full CRLs provides a guaranty up to (usually less than)
> > the
> > period of validity of the full CRL. A base CRL followed by delta-CRLs
> > provides a guaranty up to the period of validity of the delta CRLs
> > (which is
> > indeed better). If mis-used, over-issuing of full CRLs provides could
> > provide a guaranty *equal* to the period of validity of the full CRL
> > (which
> > is indeed worse).
> 
> What guaranty are you talking about? You can compare the current time (or
> some other time T) to the time in thisUpdate to determine how fresh the
> revocation information is. What other guarantees do you think are
> provided?
> 
> > > You replace this with:
> > >
> > > CAs must ensure that application of a delta CRL to the referenced
> > > 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:
> > >
> > > (a) If a certificate was listed as revoked with revocation reason
> > > certificateHold on a CRL (either a delta CRL or a CRL that is
> > > complete for a given scope), and the hold is subsequently
> > > released, the certificate must be listed with revocation reason
> > > removeFromCRL until the next base CRL is issued.
> > >
> > > Note: Should the certificate be subsequently revoked again for
> > > one of the revocation reasons covered by the delta CRL,
> > > then the certificate must be listed with the revocation
> > > reason appropriate for the subsequent revocation.
> > >
> > > (b) If the certificate was not removed from hold, but was
> > > permanently revoked, then it must be listed as such on all
> > subsequent delta CRLs until the next base CRL is issued .
> > >
> > > This text presents the biggest problems of all. The text describes
> *what*
> > > needs to be listed on *which* delta CRLs. By limiting this text to one
> 
> > > very narrow scenario, you increase the likeliehood that delta CRL
> issuers
> > > that wish to do something efficient will get it wrong. That will
> result
> > > in bad information from the relying party.
> >
> > This text has be simply adapted to remove the semantics that existed on
> the
> > CRL number from delta-CRLs. It describes what a CA does, not what a
> relying
> > party does. I do not believe that there is the limitation as you
> mention. If
> > you really think that the text needs to be changed, please make a
> proposal
> > on it, but without adding any new seamntics to the CRL number. :-)
> 
> It may have been your intention to simply re-word the text without
> changing the semantics, but this was not the result. The new text
> describes a different set of semantics and these new semantics prevent CRL
> issuers from issuing delta-CRLs in any way except one very inefficient
> manner. Without reference to CRL numbers, it is not possible to properly
> describe the rules for constructing delta-CRLs.
> 
> Dave


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA22787 for <[e-mail]>; Fri, 4 May 2001 08:29:10 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA16168; Fri, 4 May 2001 17:28:59 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA16940; Fri, 4 May 2001 17:28:31 +0200
Message-ID: <[e-mail]>
Date: Fri, 04 May 2001 17:28:31 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Tim Polk <[e-mail]>
CC: "David A. Cooper" <[e-mail]>, [e-mail]
Subject: Re: delta-CRLs
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tim,

I would have no problem to continue the discussion with one of you and this
would have the benefit to cut down the number of exchanges by a factor of
two. I sent an e-mail to *you* and you answer to the e-mail sent to David.
:-(

I did answer the main point of your e-mail. I would appreciate your feeback.

I will nevertheless answer to the two comments you made on the e-mail sent
to David and delete the rest of the e-mail for readability for the moment. 
I guess you hit the "send" key too early since your third comment is
incomplete.

> >The ISO text has two major problems:

> >1) It makes a major assumption, ... which is wrong: once a CA has started to
> >issue a base CRL (and hence it will issue delta-CRLs) then it must do it for
> >ever. A CA can issue a base CRL and then delta CRLs but then simply issue
> >complete CRL (i.e. full CRLs that do not support the delta mechanism) and
> >later one can start to issue a base a delta CRLs again.
 
> I would agree that a CA is not required to issue deltas forever.  A CA
> could issue a complete CRL (call it CRL-1), a series of deltas fusing CRL-1
> as a base base, then a new complete CRL (CRL-2), then more deltas using
> CRL-2 as a base.  I do not believe the ISO text precludes this scenario.

The ISO text is implicitly saying that using a base CRL issued on January 1,
2001, and by applying all issued delta CRLs since then, you can get the
current CRL from May 4, 2001. The first problem is that base CRLs are not
necessarilly continously issued. The second problem is that all delta CRLs
would have to be obtained. The third problem is the way the cross the
border: when the new base CRL is issued the delta shall refer to the new
base CRL, not the previous base CRL (which does not necessarily exist).
 
> >2)  RFC 2459 in section 5.2.3 (CRL Number) says:

> >    The CRL number is a non-critical CRL extension which conveys a
> >    monotonically increasing sequence number for each CRL issued by a CA.

> >Since two CRLs (whether they are base, delta, complete, whatever) cannot
> >have the same number, this means that the following sentence extracted from
> >the ISO text is wrong: "The value of the CRL number, as conveyed in the CRL
> >number extension field (if present), shall be identical for both the
> >delta-CRL and the corresponding complete CRL".
 
> Denis, a delta CRL may only be used in combination with a base CRL,
> right?  

Yes. More precisely *ONE* base CRL. Right ?

> The CRL number in the delta is the CRL number of the *constructed*
> CRL.  

No. The *constructed* CRL is local one, which has no number assigned by the
CA. You can locally give it a reference, but this is a local matter. 

> When the delta and base combine to form *the same* CRL as a complete
> CRL, the complete CRL will have the same CRL number.

Do you mean that the complete CRL is issued by the CA or is it a locally
reconstructed one ?

Is, what you call, a "complete CRL", a new base CRL or the locally
reconstructed one ?

> Since the delta and *any legal base CRL* will combine to form 
> *the same* CRL, the complete CRL and the delta MUST have the same 
> CRL number.

Certainly not. Either this would infringe the text from RFC 2459:

   The CRL number is a non-critical CRL extension which conveys a
   monotonically increasing sequence number for each CRL issued by a CA.

or this numbering is a local matter, and thus that is a local implementation
detail.
 
> Note that this is *crucial* if we intend to use the constructed CRL as a
> base CRL in the future.  If you cannot assign a CRL number to the
> constructed CRL you cannot use it as a base.

Of course you can without using this numbering. You only need to know, as I
already said, that this is the CRL consructed from the base CRL numbered
XXXX, by adding the delta CRL which has the next update scheduled at YY:YY.

Regards,

Denis


Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA21735 for <[e-mail]>; Fri, 4 May 2001 08:23:36 -0700 (PDT)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id LAA11375; Fri, 4 May 2001 11:23:27 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Fri, 04 May 2001 11:23:02 -0400
To: Denis Pinkas <[e-mail]>
From: "David A. Cooper" <[e-mail]>
Subject: Re: delta-CRLs
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"

<html>
<br>
At 02:22 PM 5/4/01 +0200, Denis Pinkas wrote:<br>
<blockquote type=cite cite>David,<br>
<br>
This thread is now taking me (too) much time for my processing power.
:-(<br>
<br>
&gt; At 06:05 PM 5/2/01 +0200, Denis Pinkas wrote:<br>
&gt; <br>
&gt; &gt;&gt; The current is wrong on two major aspects:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; a) the numbering of the delta CRLs<br>
&gt; &gt;<br>
&gt; <br>
&gt; Since you claim to want to support &quot;traditional&quot;
delta-CRLs, I will quote<br>
&gt; the text on delta-CRLs from section 12.6.3.3 of X.509 3rd edition
(1997):<br>
&gt; <br>
&gt; a delta-CRL shall not be issued without a corresponding
complete<br>
&gt; CRL being issued at the same time. The value of the CRL number,
<br>
&gt; as conveyed in the CRL number extension field (if present), shall
<br>
&gt; be identical for both the delta-CRL and the corresponding complete
CRL<br>
&gt; <br>
&gt; Similar text was included in one of the old proposed draft
amendments to<br>
&gt; the 1997 standard:<br>
&gt; <br>
&gt; At reset time, concurrent with publication of a new base CRL 
is<br>
&gt; publication of the final delta-CRL for the old base CRL. Both CRLs
<br>
&gt; published concurrently (new base and final delta for old base) shall
<br>
&gt; contain identical values of the cRLNumber extension as well as<br>
&gt; identical values of thisUpdate time. The values of nextUpdate
time<br>
&gt; will be different in each.<br>
&gt; <br>
&gt; Both texts are quite clear that when a complete CRL and a delta-CRL
are<br>
&gt; issued at the same time, and the two CRLs provide the same
information,<br>
&gt; they must have the same cRLnumber. This is because the are
effectively two<br>
&gt; instantiations of the same CRL.<br>
<br>
The ISO text has two major problems:<br>
<br>
1) It makes a major assumption, ... which is wrong: once a CA has started
to<br>
issue a base CRL (and hence it will issue delta-CRLs) then it must do it
for<br>
ever. A CA can issue a base CRL and then delta CRLs but then simply
issue<br>
complete CRL (i.e. full CRLs that do not support the delta mechanism)
and<br>
later one can start to issue a base a delta CRLs 
again.</blockquote><br>
I not sure why you think the text is making an assumption, but there
seems to be a misunderstanding here. There is nothing special about a
base CRL. There are no flags that are placed in a CRL to indicate that it
is a base CRL. A base CRL is simply &quot;[a] CRL that is used as the
foundation in the generation of a dCRL&quot; [X.509 4th ed.] Thus, any
CRL that is referenced in the BaseCRLNumber field of a delta-CRL is a
base CRL. The deltaCRLIndicator extension imposes a requirement that only
CRLs that were issued as complete for scope CRLs can be used as base
CRLs, but this is beside the point. One does not issue a &quot;base
CRL&quot; to advertise that delta-CRLs will be issued in the future. One
issues full CRLs. If, at some point in the future, a delta-CRL species a
full CRL as its base, then that full CRL is a base CRL.<br>
<br>
<blockquote type=cite cite>2)&nbsp; RFC 2459 in section 5.2.3 (CRL
Number) says: <br>
<br>
&nbsp;&nbsp; The CRL number is a non-critical CRL extension which conveys
a<br>
&nbsp;&nbsp; monotonically increasing sequence number for each CRL issued
by a CA.<br>
<br>
Since two CRLs (whether they are base, delta, complete, whatever)
cannot<br>
have the same number, this means that the following sentence extracted
from<br>
the ISO text is wrong: &quot;The value of the CRL number, as conveyed in
the CRL<br>
number extension field (if present), shall be identical for both 
the<br>
delta-CRL and the corresponding complete CRL&quot;.
</blockquote>&nbsp;<br>
Again, you are misinterpreting this text. If a full CRL and a delta-CRL
cover the set of certificates and revocation reasons (i.e., scope) and
are issued at the same time, then they are effectively two instantiations
of the same CRL. They must then (as the standard requires) have the same
cRLNumber. <br>
<br>
<blockquote type=cite cite>&gt; Notice also that the requirement is that
when a new base is issued, the<br>
&gt; delta that is issued at the same time provides changes since the
previous<br>
&gt; base. <br>
<br>
This is wrong as well because there is not necessarilly this previous
base<br>
(see the first major problem).<br>
<br>
&gt; One does not issue an empty delta. If one did, then every
relying<br>
&gt; party would be forced to download every base CRL.<br>
<br>
This is the intent, otherwise delta CRLs would grow for
ever.</blockquote><br>
This is not true. I have constructed an example below (hopefully it is
well formatted so that it is readable). The example below shows the
&quot;traditional&quot; method of issuing delta-CRLs. In this example,
full CRLs are issued once every 3 hours and deltas are issued once an
hour. As you have stated, if one wishes to begin issuing deltas at the
same time that the very first full CRL, the delta must use the
concurrently issued full CRL as its base. After that, however, a delta
can always use a previously issued full CRL as its base. Notice that
starting with cRLNumber 4, the delta CRL issued at the same time as a
full CRL uses the previously issued full CRL as its base. However, the
delta-CRLs never provide more than 3 hours of history. They do not grow
forever.<br>
<br>
<br>
<tt>current&nbsp;&nbsp; revoked<br>
time<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;
certificates<x-tab>&nbsp;</x-tab>full
CRL<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>delta-CRL<br>
------------------------------------------------------------<br>
</tt>12:00<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>{14}<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLNumber
=
1<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLNumber
= 1<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>thisUpdate
=
12:00<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>thisUpdate
= 12:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>nextUpdate
=
15:00<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>nextUpdate
= 13:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>BaseCRLNumber
= 1<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>CertificateList
=
{14}<x-tab>&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>CertificateList
= {}<br>
<br>
<br>
13:00<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>{14,
124}<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLNumber
= 2<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>thisUpdate
= 13:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>nextUpdate
= 14:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>BaseCRLNumber
= 1<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>CertificateList
= {124}<br>
<br>
<br>
14:00<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>{14,
124}<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLNumber
= 3<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>thisUpdate
= 14:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>nextUpdate
= 15:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>BaseCRLNumber
= 1<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>CertificateList
= {124}<br>
<br>
<br>
15:00<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>{14,
124, 39}<x-tab>&nbsp;&nbsp;&nbsp;</x-tab>cRLNumber =
4<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLNumber
= 4<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>thisUpdate
=
15:00<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>thisUpdate
= 15:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>nextUpdate
=
18:00<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>nextUpdate
= 16:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>BaseCRLNumber
= 1<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>CertificateList
= {14, 124, 39}<x-tab>&nbsp;</x-tab>CertificateList = {124, 39}<br>
<br>
<br>
16:00<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>{14,
124,
39,<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLNumber
= 5<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>
67}<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>thisUpdate = 16:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>nextUpdate = 17:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>BaseCRLNumber = 4<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>CertificateList = {67}<br>
<br>
<br>
17:00<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>{14, 124, 39,<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLNumber = 6<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab> 67}<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>thisUpdate = 17:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>nextUpdate = 18:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>BaseCRLNumber = 4<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>CertificateList = {67}<br>
<br>
<br>
18:00<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>{14, 124, 39,<x-tab>&nbsp;&nbsp;&nbsp;</x-tab>cRLNumber = 7<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLNumber = 7<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab> 67}<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>thisUpdate = 18:00<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>thisUpdate = 18:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>nextUpdate = 21:00<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>nextUpdate = 19:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>BaseCRLNumber = 4<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>CertificateList = {14, 124, 39,<x-tab>&nbsp;</x-tab>CertificateList = {67}<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 21}<br>
<br>
<br>
19:00<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>{14, 124, 39,<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLNumber = 8<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab> 67}<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>thisUpdate = 19:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>nextUpdate = 20:00<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>BaseCRLNumber = 7<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>CertificateList = {}<br>
<br>
<br>
<blockquote type=cite cite>&gt; &gt;&gt; b) the lack of use of the fields thisUpdate and nextUpdate in the<br>
&gt; &gt;&gt; delta-CRLs.<br>
<br>
&gt; As I stated before, the thisUpdate field specifies the time at which the<br>
&gt; CRL was issued. There is absolutely no reason to check that the current<br>
&gt; time is after thisUpdate. <br>
<br>
There is no notion of current time. The evaluation is made at time T, which<br>
may be the current time or a time in the past.</blockquote><br>
In the note to which I was responding, you had proposed the following text:<br>
<br>
&gt; &gt; &gt; &gt; An application can construct a CRL that is the most current for <br>
&gt; &gt; &gt; &gt; a given scope, at the current time, by retrieving the current <br>
&gt; &gt; &gt; &gt; base CRL for that scope, and combining it with a delta-CRL which <br>
&gt; &gt; &gt; &gt; contains a Delta CRL Indicator equal to the cRLNumber of the base <br>
&gt; &gt; &gt; &gt; CRL and where the current date from that delta-CRL is between <br>
&gt; &gt; &gt; &gt; thisUpdate and nextUpdate;<br>
<br>
In the proposed text, you specifically stated that the goal was to construct a CRL that is most current *at the current time*. If the text is changed to also describe how to determine the status of a certificate at some point in the past, then the situation becomes more complicated.<br>
<br>
<blockquote type=cite cite>&gt; The nextUpdate field in a delta-CRL has the same meaning an in any other<br>
&gt; type of CRL, so there is no reason to discuss it here. As I said before,<br>
&gt; though, one can not say that any CRL whose nextUpdate time has not passed<br>
&gt; is the most current. There may have been an &quot;emergency&quot; CRL issued since<br>
&gt; that one was issued. If nextUpdate has passed, then you know the CRL is<br>
&gt; not the most current. If nextUpdate has not passed, then the CRL MAY be<br>
&gt; the most current, but there is no way to know for certain.<br>
<br>
See my response to Tim on that topic.</blockquote><br>
I saw your response. X.509 states: &quot;<font size=2>nextUpdate</font>, if present, indicates the date/time by which the next revocation list in this series will be issued. The next revocation list could be issued before the indicated date, but it will not be issued any later than the indicated time.&quot; While the term &quot;emergency CRL&quot; is not in the text, it does state that a new CRL may be issued before the date indicated in nextUpdate. Can you find anywhere in the text that suggests that this does not apply to delta-CRLs?<br>
<br>
<br>
<blockquote type=cite cite>&gt; &gt;&gt; &gt; They seem to depart from the traditional<br>
&gt; &gt;&gt; &gt; deltas in certain details,<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; They certainly do not.<br>
&nbsp;<br>
&gt; As I stated above, you state that whenever a base CRL is issued, an empty<br>
&gt; delta-CRL should be issued at the same time, with the delta-CRL using the<br>
&gt; concurrently issued base CRL as its base. This is not how traditional<br>
&gt; delta-CRLs work.<br>
<br>
Think about it. To do that you have to take an example: a *first* base CRL<br>
is issued at midnight (no base CRL *ever* exists before). A delta is<br>
supposed to be issued every hour. Think first about the processing done by a<br>
relying party at 3:30 a.m. Then think about the processing that will be done<br>
at 0:30 a.m. You will then come to the same conclusion. Now if a base<br>
existed before, then the proposal would not be consistant with the<br>
definition of the construction of the updated CRL which is: <br>
<br>
&nbsp;&nbsp; An application can construct an updated CRL, for a specific time T, <br>
&nbsp;&nbsp; by retrieving the appropriate base CRL for that scope, and combining <br>
&nbsp;&nbsp; it with a delta CRL which contains a delta CRL indicator extension <br>
&nbsp;&nbsp; with the same CRL number as the base CRL.<br>
<br>
Futhermore, the size of the delta CRLs would grow for ever.</blockquote><br>
Not true. See the example above.<br>
<br>
<blockquote type=cite cite>&gt; &gt;&gt; &gt; but prevent use of sliding window deltas.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Maybe. However, if you really want them to be part of this document,<br>
&gt; &gt;&gt; then<br>
&gt; &gt;&gt; they MUST *not* be mandatory. So the only way would be to add<br>
&gt; &gt;&gt; additional<br>
&gt; &gt;&gt; text that would explain how this can be done as an option. However I<br>
&gt; &gt;&gt; got the<br>
&gt; &gt;&gt; fealing that the traditional method may be in some way incompatible<br>
&gt; &gt;&gt; with the<br>
&gt; &gt;&gt; sliding window deltas, i.e. if the sliding method is chosen by the CRL<br>
&gt; &gt;&gt; Issuer relying parties may have difficulties to use the traditional<br>
&gt; &gt;&gt; method.<br>
&gt; &gt;&gt; But, maybe, you have the right text just ready to explain how this can<br>
&gt; &gt;&gt; be<br>
&gt; &gt;&gt; done. :-)<br>
&nbsp;<br>
&gt; When I referred to the &quot;traditional&quot; method in my paper, I was referring<br>
&gt; to the way delta-CRLs are issued, not how they are processed by relying<br>
&gt; parties. Notice, however, that the deltaCRLIndicator requires that &quot;[t]he<br>
&gt; base CRL referenced by a deltaCRLIndicator extension shall be a CRL that<br>
&gt; is issued as complete for its scope (i.e. it is not itself a dCRL).&quot; If by<br>
&gt; &quot;relying parties using the traditional method&quot; you mean always applying<br>
&gt; the delta-CRL to a full CRL whose cRLNumber is equal to the value in<br>
&gt; BaseCRLNumber, this requirement on the deltaCRLIndicator extension ensures<br>
&gt; that this can be done no matter how delta-CRLs are issued (traditional<br>
&gt; method, sliding window, or other). I don't think that anyone ever intended<br>
&gt; for this to be way that delta-CRLs are processed, but you can do it if you<br>
&gt; want.<br>
<br>
I undersand clearly that you would like relying parties to take advantage of<br>
sliding windows, by the &quot;algorithm&quot; that you proposed, which is based on the<br>
ISO text, has flaws in it. See above.</blockquote><br>
Your belief that there are flaws in the ISO text is based on a misinterpretation of the cRLNumber field. Since this field is vital to the efficient use of delta-CRLs, this misinterpretation may be the reason for your confusion.<br>
<br>
<blockquote type=cite cite>&gt; Even if delta-CRLs are issued using the &quot;traditional&quot; method, relying<br>
&gt; parties may choose to maintain a locally generated revocation list which<br>
&gt; they update which each successive delta-CRL that they download. <br>
<br>
I have addressed that point in details in my response to Tim. I think we<br>
agree on this point.</blockquote><br>
The text on delta-CRLs has two basic parts. One part, which is normative, describes what information a CRL issuer needs to place in a delta-CRL. The other part, which is informative, describes what information relying parties need to make use of delta-CRLs. If we use your text (below), then we are being less informative than we could be.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>An application can construct an updated CRL, for a specific time T, <br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>by retrieving the appropriate base CRL for that scope, and combining <br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>it with a delta CRL which contains a delta CRL indicator extension <br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>with the same CRL number as the base CRL. <br>
<br>
The text hides from implementers the fact that a delta-CRL may be used in conjunction with a full CRL that was issued after the referenced base CRL was issued. The follow-up text (&quot;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.&quot;) is only a source of confusion. The text above does not describe an algorithm, it merely states what information is required to construct an updated CRL using base CRLs and delta-CRLs. An algorithm would state how to construct an updated CRL.<br>
<br>
<br>
<blockquote type=cite cite>&gt; &gt;&gt; &gt; &gt;[David] A delta-CRL is nearly the same as a full CRL. It has a<br>
&gt; &gt;&gt; thisUpdate,<br>
&gt; &gt;&gt; &gt; &gt;nextUpdate, cRLNumber, etc. just as a full CRL. It just has an<br>
&gt; &gt;&gt; incomplete<br>
&gt; &gt;&gt; &gt; &gt;list of revoked certificates.<br>
&gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt;&gt; &gt; &gt;[Denis] Yes, but you have to explain detail how a relying party<br>
&gt; &gt;&gt; will use<br>
&gt; &gt;&gt; &gt; &gt;thisUpdate, nextUpdate for a base CRL and thisUpdate, nextUpdate<br>
&gt; &gt;&gt; for a delta<br>
&gt; &gt;&gt; &gt; &gt;to make sure that in both cases he got the freshest information.<br>
&gt; &gt;<br>
&nbsp;<br>
&gt; There is no way, using CRLs, to ensure that you have the freshest<br>
&gt; information. <br>
<br>
True. But if you are using both base CRLs and delta-CRLs then you have that<br>
guaranty up to the period of refresh of the delta-CRL (which is of course<br>
much better than the period of refresh from the base CRL).</blockquote><br>
At time T, you know that the information in a CRL (any type of CRL) is no older than T - thisUpdate. There is no guarantee that another CRL was not issued after thisUpdate, even if&nbsp; T &lt; nextUpdate (see above).<br>
<br>
<blockquote type=cite cite>&gt; &gt;&gt; &gt; &gt;[Denis]<br>
&gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt;&gt; &gt; &gt;As said later, your paper provides the right answer (on page 1): &quot;A<br>
&gt; &gt;&gt; &gt; &gt;delta-CRL is a CRL that only provides information about certificates who<br>
&gt; &gt;&gt; &gt; &gt;statuses have changed since the issuance of a specific, previously issued<br>
&gt; &gt;&gt; &gt; &gt;CRL&quot;. The text says &quot; *a* specific, previously issued CRL&quot;, it does NOT say<br>
&gt; &gt;&gt; &gt; &gt;&quot;or any, more recently, issued CRL&quot;.<br>
&nbsp;<br>
&gt; You are misinterpreting the quote. The sentence states what information is<br>
&gt; provided in a delta-CRL. It does not say anything about how the delta-CRL<br>
&gt; can be used. A delta-CRL provides information about certificates whose<br>
&gt; statuses have changed since the issuance of a specific, previously issued<br>
&gt; CRL. The delta-CRL may, however, be applied to more recently issued CRLs.<br>
<br>
In the same spirit as you did, I could say that we would need a machine that<br>
allows people to travel in the future. However, delta-CRLs cannot be applied<br>
to more recently issued CRLs, unless you provide a clear example of how this<br>
can be done.</blockquote><br>
OK. Here is an example. Suppose that you have a delta-CRL with a cRLNumber of 8 and a BaseCRLNumber of 5. You also have a full CRL with a cRLNumber of 6. The following algorithm can then be used to determine the status of a certificate that is covered by the CRL at the time that the delta-CRL was issued (assume the certificate in question has serial number 153):<br>
<br>
1) If 153 is listed on full CRL number 6, but not the delta-CRL, then it is revoked with the revocation reason stated in full CRL number 6.<br>
<br>
2) If 153 is listed on the delta-CRL with a revocation reason of removeFromCRL, then it would not be found on a full CRL issued at the time the delta-CRL was issued. In this case it does not matter whether 153 was listed on full CRL number 6. The reason that it would not be on the full CRL (number 8) is unknown. It could either be that the certificate was removed from hold or that the certificate expired.<br>
<br>
3) If 153 is listed on the delta-CRL with a revocation reason other than removeFromCRL, then it is revoked with the revocation reason stated in the delta-CRL. Again, in this case, it does not matter whether 153 was listed on full CRL number 6.<br>
<br>
4) If 153 is not listed on either full CRL number 6 or the delta-CRL, then it is not revoked (or it expired before CRL number 6 was issued).<br>
<br>
<br>
I created this algorithm on the fly, so it may not be perfect, but it should be sufficiently close to correct to be understandable. Notice, however, that the cRLNumber field is very important here. In order for this algorithm to work you must ensure that cRLNumber of the full CRL you use is greater than or equal to the BaseCRLNumber in the delta-CRL and less than the cRLNumber in the delta-CRL. One must be able to compare the CRL numbers in order to check that the delta-CRL and full CRL can be combined. <br>
<br>
<blockquote type=cite cite>&gt; &gt;&gt; &gt; &gt; &gt; &gt;This paper is proposing a method for over-issuing the CRLs. It omits to take<br>
&gt; &gt;&gt; &gt; &gt; &gt; &gt;into consideration that in PKIX-1 we mandate the CRL number extension<br>
&gt; &gt;&gt; &gt; &gt; &gt; &gt;(section 5.2.3) so we need to advertise the nextUpdate. If you issue a CRL<br>
&gt; &gt;&gt; &gt; &gt; &gt; &gt;before the next update you have no more way to know which base CRL is the<br>
&gt; &gt;&gt; &gt; &gt; &gt; &gt;freshest CRL. I believe this is a major security weakness and for that<br>
&gt; &gt;&gt; &gt; &gt; &gt; &gt;reason this mechanism should be deprecated.<br>
<br>
&gt; Over-issuing is really out-of-scope for this discussion. However,<br>
&gt; over-issuing is merely one way to distribute revocation information more<br>
&gt; efficiently. If you issue CRLs once every 4 hours and I issue CRLs once an<br>
&gt; hour, but with a nextUpdate time 4 hours in the future, the information<br>
&gt; relying parties get from me will be no more stale than the information<br>
&gt; they get from you. If there is any &quot;security weakness&quot; it is from the<br>
&gt; delay in distributing revocation information, not from over-issuing.<br>
<br>
Over-issuing of full CRLs provides a guaranty up to (usually less than) the<br>
period of validity of the full CRL. A base CRL followed by delta-CRLs<br>
provides a guaranty up to the period of validity of the delta CRLs (which is<br>
indeed better). If mis-used, over-issuing of full CRLs provides could<br>
provide a guaranty *equal* to the period of validity of the full CRL (which<br>
is indeed worse).</blockquote><br>
What guaranty are you talking about? You can compare the current time (or some other time T) to the time in thisUpdate to determine how fresh the revocation information is. What other guarantees do you think are provided? <br>
<br>
<br>
&gt; &gt; You replace this with: <br>
&gt; &gt; <br>
&gt; &gt; CAs must ensure that application of a delta CRL to the referenced <br>
&gt; &gt; base revocation information accurately reflects the current status of <br>
&gt; &gt; revocation. If a CA supports the certificateHold revocation reason <br>
&gt; &gt; the following rules must be applied when generating delta CRLs: <br>
&gt; &gt; <br>
&gt; &gt; (a) If a certificate was listed as revoked with revocation reason <br>
&gt; &gt; certificateHold on a CRL (either a delta CRL or a CRL that is <br>
&gt; &gt; complete for a given scope), and the hold is subsequently <br>
&gt; &gt; released, the certificate must be listed with revocation reason <br>
&gt; &gt; removeFromCRL until the next base CRL is issued. <br>
&gt; &gt; <br>
&gt; &gt; Note: Should the certificate be subsequently revoked again for <br>
&gt; &gt; one of the revocation reasons covered by the delta CRL, <br>
&gt; &gt; then the certificate must be listed with the revocation <br>
&gt; &gt; reason appropriate for the subsequent revocation. <br>
&gt; &gt; <br>
&gt; &gt; (b) If the certificate was not removed from hold, but was <br>
&gt; &gt; permanently revoked, then it must be listed as such on all <br>
&gt; subsequent delta CRLs until the next base CRL is issued . <br>
&gt; &gt; <br>
&gt; &gt; This text presents the biggest problems of all. The text describes *what* <br>
&gt; &gt; needs to be listed on *which* delta CRLs. By limiting this text to one <br>
&gt; &gt; very narrow scenario, you increase the likeliehood that delta CRL issuers <br>
&gt; &gt; that wish to do something efficient will get it wrong. That will result <br>
&gt; &gt; in bad information from the relying party.<br>
&gt;<br>
&gt; This text has be simply adapted to remove the semantics that existed on the <br>
&gt; CRL number from delta-CRLs. It describes what a CA does, not what a relying <br>
&gt; party does. I do not believe that there is the limitation as you mention. If <br>
&gt; you really think that the text needs to be changed, please make a proposal <br>
&gt; on it, but without adding any new seamntics to the CRL number. :-)<br>
<br>
It may have been your intention to simply re-word the text without changing the semantics, but this was not the result. The new text describes a different set of semantics and these new semantics prevent CRL issuers from issuing delta-CRLs in any way except one very inefficient manner. Without reference to CRL numbers, it is not possible to properly describe the rules for constructing delta-CRLs.<br>
<br>
<br>
Dave<br>
</html>



Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA19663 for <[e-mail]>; Fri, 4 May 2001 07:30:42 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA03827 for <[e-mail]>; Fri, 4 May 2001 10:30:13 -0400 (EDT)
Message-Id: <[e-mail]>
Sender: [e-mail]
Date: Fri, 04 May 2001 10:27:55 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Basic constraints, key usage, and LDAP schema
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tim Polk wrote:
> 
> However, I think that PKI clients need to be able to confirm that the CPS was
> signed by a CA, not just some random certificate subject.  They need to be
> able to determine that the entity generating their key management key pair is
> in fact the CA, not some random certificate subject.
> 
> I don't know how we convey this information if we don't use the basic
> constraints extension.  Since we have key usage to refine the meaning of basic
> constraints we should be able to say "the subject is a CA and the public key
> may be used to [one or more of the following: validate signatures on
> certificates; validate signatures on CRLs; key encipherment; etc. etc.]"

The counter-argument is that you need to know that the entity
generating the key management keypair is in fact the CA that will
be signing your certificate, not some random CA.  So checking the
name and the signature chaining of the transaction certificate is
necessary and sufficient, whereas checking the cA flag is neither
necessary nor sufficient.  The X.509 term "self-issued" covers the
case of a CA issuing transaction, web server, and CRL-signing
certificates to itself; the criterion for determining
self-issued-ness is subject/issuer name equality, not key usage
or basic constraints.



> You are correct, it would be dangerous to assert cA=TRUE without specifying a
> critical key usage extension.  I guess the question is, what would a client do
> if it encountered an intermediate certificate where basic constraints
> indicated it was a CA certificate and the key usage extension appeared but
> keyCertSign was not asserted?
> 
> On the other hand, the subject is trusted to issue certificates or CRLs
> anyway.  If the subject wants to perform mischief, it can do so with the
> appropriate key pair. Right?

I'm more concerned about an adversary's mischief than the CA's.
Certificate signing keys are the most powerful and should be
the best protected.  Web server and CRL signing private keys are
more exposed, but compromising them causes less damage than
compromise of a cert signing key.  If an adversary has a
compromised private key and a corresponding valid certificate
with cA=true, then any application which would accept that
certificate as part of a path would allow the adversary to
escalate his privileges from impersonating a web server to
creating bogus certificates.

Setting the cA flag on non-certificate-signing certificates
is not necessary. And it is potentially dangerous because even
if we make a critical key usage extension a MUST in the profile,
we can't guarantee that every CA in the world will be
PKIX-compliant.

I oppose re-defining the cA flag in this manner.  I believe we
should continue to treat the cA flag as having semantics
identical to the keyCertSign bit.

Dave


Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA18120 for <[e-mail]>; Fri, 4 May 2001 07:14:47 -0700 (PDT)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id KAA10263; Fri, 4 May 2001 10:14:44 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 04 May 2001 10:12:40 -0400
To: Denis Pinkas <[e-mail]>, "David A. Cooper" <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: Re: delta-CRLs
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Denis,

Yes, I would agree.  This thread is consuming far too much time for all of 
us.  As we have diametrically opposed views, that cannot be helped.  I will 
try to be brief, though....

At 02:22 PM 5/4/01 +0200, Denis Pinkas wrote:
>David,
>
>This thread is now taking me (too) much time for my processing power. :-(
>
> > At 06:05 PM 5/2/01 +0200, Denis Pinkas wrote:
> >
> > >> The current is wrong on two major aspects:
> > >>
> > >> a) the numbering of the delta CRLs
> > >
> >
> > Since you claim to want to support "traditional" delta-CRLs, I will quote
> > the text on delta-CRLs from section 12.6.3.3 of X.509 3rd edition (1997):
> >
> > a delta-CRL shall not be issued without a corresponding complete
> > CRL being issued at the same time. The value of the CRL number,
> > as conveyed in the CRL number extension field (if present), shall
> > be identical for both the delta-CRL and the corresponding complete CRL
> >
> > Similar text was included in one of the old proposed draft amendments to
> > the 1997 standard:
> >
> > At reset time, concurrent with publication of a new base CRL is
> > publication of the final delta-CRL for the old base CRL. Both CRLs
> > published concurrently (new base and final delta for old base) shall
> > contain identical values of the cRLNumber extension as well as
> > identical values of thisUpdate time. The values of nextUpdate time
> > will be different in each.
> >
> > Both texts are quite clear that when a complete CRL and a delta-CRL are
> > issued at the same time, and the two CRLs provide the same information,
> > they must have the same cRLnumber. This is because the are effectively two
> > instantiations of the same CRL.
>
>The ISO text has two major problems:
>
>1) It makes a major assumption, ... which is wrong: once a CA has started to
>issue a base CRL (and hence it will issue delta-CRLs) then it must do it for
>ever. A CA can issue a base CRL and then delta CRLs but then simply issue
>complete CRL (i.e. full CRLs that do not support the delta mechanism) and
>later one can start to issue a base a delta CRLs again.

I would agree that a CA is not required to issue deltas forever.  A CA 
could issue a complete CRL (call it CRL-1), a series of deltas fusing CRL-1 
as a base base, then a new complete CRL (CRL-2), then more deltas using 
CRL-2 as a base.  I do not believe the ISO text precludes this scenario.

>2)  RFC 2459 in section 5.2.3 (CRL Number) says:
>
>    The CRL number is a non-critical CRL extension which conveys a
>    monotonically increasing sequence number for each CRL issued by a CA.
>
>Since two CRLs (whether they are base, delta, complete, whatever) cannot
>have the same number, this means that the following sentence extracted from
>the ISO text is wrong: "The value of the CRL number, as conveyed in the CRL
>number extension field (if present), shall be identical for both the
>delta-CRL and the corresponding complete CRL".

Denis, a delta CRL may only be used in combination with a base CRL, 
right?  The CRL number in the delta is the CRL number of the *constructed* 
CRL.  When the delta and base combine to form *the same* CRL as a complete 
CRL, the complete CRL will have the same CRL number.  Since the delta and 
*any legal base CRL* will combine to form *the same* CRL, the complete CRL 
and the delta MUST have the same CRL number.

Note that this is *crucial* if we intend to use the constructed CRL as a 
base CRL in the future.  If you cannot assign a CRL number to the 
constructed CRL you cannot use it as a base.

> > Notice also that the requirement is that when a new base is issued, the
> > delta that is issued at the same time provides changes since the previous
> > base.
>
>This is wrong as well because there is not necessarilly this previous base
>(see the first major problem).
>
> > One does not issue an empty delta. If one did, then every relying
> > party would be forced to download every base CRL.
>
>This is the intent, otherwise delta CRLs would grow for ever.
>
> > >> b) the lack of use of the fields thisUpdate and nextUpdate in the
> > >> delta-CRLs.
>
> > As I stated before, the thisUpdate field specifies the time at which the
> > CRL was issued. There is absolutely no reason to check that the current
> > time is after thisUpdate.
>
>There is no notion of current time. The evaluation is made at time T, which
>may be the current time or a time in the past.
>
> > We can re-visit this issue, if necessary, once
> > you have built a machine that allows people to travel back in time while
> > simultaneously validating an X.509 certificate. Until then, we can assume
> > that time increases monotonically and that the current time is always
> > after thisUpdate.
>
>No need to invent such a machine, but I appreciate your sense of humor.
>Please keep flames away. See the previous comment.
>
> > The nextUpdate field in a delta-CRL has the same meaning an in any other
> > type of CRL, so there is no reason to discuss it here. As I said before,
> > though, one can not say that any CRL whose nextUpdate time has not passed
> > is the most current. There may have been an "emergency" CRL issued since
> > that one was issued. If nextUpdate has passed, then you know the CRL is
> > not the most current. If nextUpdate has not passed, then the CRL MAY be
> > the most current, but there is no way to know for certain.
>
>See my response to Tim on that topic.
>
> > >> > They seem to depart from the traditional
> > >> > deltas in certain details,
> > >>
> > >> They certainly do not.
>
> > As I stated above, you state that whenever a base CRL is issued, an empty
> > delta-CRL should be issued at the same time, with the delta-CRL using the
> > concurrently issued base CRL as its base. This is not how traditional
> > delta-CRLs work.
>
>Think about it. To do that you have to take an example: a *first* base CRL
>is issued at midnight (no base CRL *ever* exists before). A delta is
>supposed to be issued every hour. Think first about the processing done by a
>relying party at 3:30 a.m. Then think about the processing that will be done
>at 0:30 a.m. You will then come to the same conclusion. Now if a base
>existed before, then the proposal would not be consistant with the
>definition of the construction of the updated CRL which is:
>
>    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.
>
>Futhermore, the size of the delta CRLs would grow for ever.
>

If you issue one complete CRL and only issue deltas in the future, all of 
which refer to the one complete CRL as a base, the delta will grow 
forever.  I am certain *no one* has suggested that scenario, though.  It

> > >> > but prevent use of sliding window deltas.
> > >>
> > >> Maybe. However, if you really want them to be part of this document,
> > >> then
> > >> they MUST *not* be mandatory. So the only way would be to add
> > >> additional
> > >> text that would explain how this can be done as an option. However I
> > >> got the
> > >> fealing that the traditional method may be in some way incompatible
> > >> with the
> > >> sliding window deltas, i.e. if the sliding method is chosen by the CRL
> > >> Issuer relying parties may have difficulties to use the traditional
> > >> method.
> > >> But, maybe, you have the right text just ready to explain how this can
> > >> be
> > >> done. :-)
>
> > When I referred to the "traditional" method in my paper, I was referring
> > to the way delta-CRLs are issued, not how they are processed by relying
> > parties. Notice, however, that the deltaCRLIndicator requires that "[t]he
> > base CRL referenced by a deltaCRLIndicator extension shall be a CRL that
> > is issued as complete for its scope (i.e. it is not itself a dCRL)." If by
> > "relying parties using the traditional method" you mean always applying
> > the delta-CRL to a full CRL whose cRLNumber is equal to the value in
> > BaseCRLNumber, this requirement on the deltaCRLIndicator extension ensures
> > that this can be done no matter how delta-CRLs are issued (traditional
> > method, sliding window, or other). I don't think that anyone ever intended
> > for this to be way that delta-CRLs are processed, but you can do it if you
> > want.
>
>I undersand clearly that you would like relying parties to take advantage of
>sliding windows, by the "algorithm" that you proposed, which is based on the
>ISO text, has flaws in it. See above.
>
> > Even if delta-CRLs are issued using the "traditional" method, relying
> > parties may choose to maintain a locally generated revocation list which
> > they update which each successive delta-CRL that they download.
>
>I have addressed that point in details in my response to Tim. I think we
>agree on this point.
>
> > Remember that RFC 2459 stated:
> >
> > The use of delta-CRLs can significantly improve processing time
> > for applications
> > which store revocation information in a format other than the CRL
> > structure.  This
> > allows changes to be added to the local database while ignoring
> > unchanged information that is already in the local database.
> >
> > We should not write text that seems to preclude this option.
> >
> > The text that is in the document now was painstakingly crafted by the ISO
> > Directory group and was carefully profiled by PKIX. The text does not
> > mandate sliding window delta-CRLs, nor does it specify a particular way
> > that relying parties must use delta-CRLs. It provides options to both CRL
> > issuers and relying parties, but does not impose requirements on either.
> > Please do not suggest that we change the text to preclude useful options
> > when doing so would provide no benefits.
>
>The ISO text has problems, so the text based on it has problems too.
>
> > >> > >[David] A delta-CRL is nearly the same as a full CRL. It has a
> > >> thisUpdate,
> > >> > >nextUpdate, cRLNumber, etc. just as a full CRL. It just has an
> > >> incomplete
> > >> > >list of revoked certificates.
> > >> > >
> > >> > >[Denis] Yes, but you have to explain detail how a relying party
> > >> will use
> > >> > >thisUpdate, nextUpdate for a base CRL and thisUpdate, nextUpdate
> > >> for a delta
> > >> > >to make sure that in both cases he got the freshest information.
> > >
>
> > There is no way, using CRLs, to ensure that you have the freshest
> > information.
>
>True. But if you are using both base CRLs and delta-CRLs then you have that
>guaranty up to the period of refresh of the delta-CRL (which is of course
>much better than the period of refresh from the base CRL).

> > If nextUpdate has passed, then you know that fresher
> > information is available. If nextUpdate has not passed, then you do not
> > know whether you have the freshest information or not. This is true for
> > full CRLs, delta-CRLs, indirect CRLs, and any other type of CRL. If more
> > text is needed to explain the use of the nextUpdate field then it should
> > go in section 5.1.2.5 on the nextUpdate field, since it would apply to all
> > CRLs, not just delta-CRLs.
> >
> > >> > >[Denis]
> > >> > >
> > >> > >As said later, your paper provides the right answer (on page 1): "
> > >> 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 text says " *a* specific, previously issued CRL", it does
> > >> NOT say
> > >> > >"or any, more recently, issued CRL".
>
> > You are misinterpreting the quote. The sentence states what information is
> > provided in a delta-CRL. It does not say anything about how the delta-CRL
> > can be used. A delta-CRL provides information about certificates whose
> > statuses have changed since the issuance of a specific, previously issued
> > CRL. The delta-CRL may, however, be applied to more recently issued CRLs.
>
>In the same spirit as you did, I could say that we would need a machine that
>allows people to travel in the future. However, delta-CRLs cannot be applied
>to more recently issued CRLs, unless you provide a clear example of how this
>can be done.
>
> > >> > > > >This paper is proposing a method for over-issuing the CRLs. It
> > >> omits to take
> > >> > > > >into consideration that in PKIX-1 we mandate the CRL number
> > >> extension
> > >> > > > >(section 5.2.3) so we need to advertise the nextUpdate. If you
> > >> issue a CRL
> > >> > > > >before the next update you have no more way to know which base
> > >> CRL is the
> > >> > > > >freshest CRL. I believe this is a major security weakness and
> > >> for that
> > >> > > > >reason this mechanism should be deprecated.
>
> > Over-issuing is really out-of-scope for this discussion. However,
> > over-issuing is merely one way to distribute revocation information more
> > efficiently. If you issue CRLs once every 4 hours and I issue CRLs once an
> > hour, but with a nextUpdate time 4 hours in the future, the information
> > relying parties get from me will be no more stale than the information
> > they get from you. If there is any "security weakness" it is from the
> > delay in distributing revocation information, not from over-issuing.
>
>Over-issuing of full CRLs provides a guaranty up to (usually less than) the
>period of validity of the full CRL. A base CRL followed by delta-CRLs
>provides a guaranty up to the period of validity of the delta CRLs (which is
>indeed better). If mis-used, over-issuing of full CRLs provides could
>provide a guaranty *equal* to the period of validity of the full CRL (which
>is indeed worse).
>
> > >> > >[David]  Finally, since a CRL issuer may issue "emergency"
> > >> delta-CRLs, there
> > >> > >is no guarantee that any delta-CRL whose nextUpdate time is later
> > >> than the
> > >> > >current time is the most current delta-CRL.
> > >> > >
> > >> > >[Denis] If you issue such "emergency" delta-CRLs then once again
> > >> there is no
> > >> > >guarantee that they will ever be seen. The "most recent delta-CRL"
> > >> is any
> > >> > >delta CRL which satisfies the following condition :
> > >> > >
> > >> > >" A delta-CRL which contains a Delta CRL Indicator equal to the
> > >> cRLNumber of
> > >> > >the base CRL and where the validation date (which may be the
> > >> current time)
> > >> > >is between thisUpdate and nextUpdate from that delta-CRL;"
>
> > This seems to be a semantic problem. There can only be one "most recent
> > CRL". You seem to want to mandate that people always use the "most recent
> > CRL", but there is no way guarantee that you have the most recent CRL.
>
>See the response above and my response to Tim.
>
> > >> > > > >Any other method would first need to be proven to be secure
> > >> (over-issuing
> > >> > > > >CRLs and sliding window delta-CRLs have security problems)
> > >>
> > >> > >[Denis] There ARE security problems with sliding window delta-CRLs.
> > >> I have
> > >> > >descibed at length what the problems are. However, this does not
> > >> mean that
> > >> > >this technique cannot be supported as an OPTIO and IF we indicate
> > >> in the
> > >> > >text what are their security problems. The current text places the
> > >> two
> > >> > >techniques at the same level. The traditional way offers a
> > >> guarantee while
> > >> > >the other does not. There is indedd added complexity for building
> > >> the
> > >> > >software from the relying party.
>
> > You have not described any security problems with sliding window
> > delta-CRLs. You suggest that sliding window delta-CRLs should not be used
> > until they have been proven secure. What type of proof are you looking
> > for? Where are the proofs that CRLs of any type are secure? Where is the
> > proof that X.509 certificates are secure? Once you provide me with the
> > proofs that everything else in X.509 is secure, I'll try to find time to
> > write a similar proof to show that sliding window delta-CRLs are secure.
> > Until then, any suggestion that sliding window delta-CRLs need to be
> > proven to be secure before they can be used is nothing but a red herring.
>
>No comment.
>
>Denis
>
> > Dave



Received: from e1.ny.us.ibm.com ([32.97.182.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA17823 for <[e-mail]>; Fri, 4 May 2001 07:12:22 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA104038; Fri, 4 May 2001 10:10:20 -0400
Received: from d02ml237.somers.hqregion.ibm.com (d02ml237.sby.ibm.com [9.45.4.171]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id KAA11170; Fri, 4 May 2001 10:06:41 -0400
Importance: Normal
Subject: RE: Basic constraints, key usage, and LDAP schema
To: Sharon Boeyen <[e-mail]>
Cc: Santosh Chokhani <[e-mail]>, "'Tim Polk'" <[e-mail]>, "'Denis Pinkas'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Fri, 4 May 2001 10:11:40 -0400
X-MIMETrack: Serialize by Router on D02ML237/02/M/IBM(Release 5.0.7 |March 21, 2001) at 05/04/2001 10:11:50 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

     Just BTW, my reasoning is similar to Santosh's.  I would like to
mention that the reasons for issuing a distinct CMP certificate for a CA
are even stronger than those for a distinct CRL certificate.  However, it
is not obvious whether this should be classed as a CA certificate since a
certificate to be used with CMP looks more like a standard server
certificate.

          Tom Gindin


Sharon Boeyen <[e-mail]> on 05/03/2001 12:52:30 PM

To:   Santosh Chokhani <[e-mail]>, Tom Gindin/Watson/IBM@IBMUS
cc:   "'Tim Polk'" <[e-mail]>, "'Denis Pinkas'"
      <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject:  RE: Basic constraints, key usage, and LDAP schema


Thanks, I understand now.
 -----Original Message-----
 From: Santosh Chokhani
 Sent: Thursday, May 03, 2001 12:32 PM
 To: Sharon Boeyen; 'Tom Gindin'
 Cc: 'Tim Polk'; Denis Pinkas; [e-mail]
 Subject: RE: Basic constraints, key usage, and LDAP schema

 Sharon:

 One reason a CA may issue itself a CRL signing certificate is the scenario
 as follows:

 1.  The CA is a trust anchor for some relying parties, and

 2.  The CA wants to use different key for CRL signing for operational
 security, and

 3.  The CA wants to only provide one trust anchor (i.e., the certificate
 signature verification public key).

 In that scenario, the CA will issue itself a certificate for the CRL
 signature verification public key.

 -----Original Message-----
 From: Sharon Boeyen [mailto:[e-mail]]
 Sent: Thursday, May 03, 2001 10:35 AM
 To: 'Tom Gindin'; Sharon Boeyen
 Cc: 'Tim Polk'; Denis Pinkas; [e-mail]
 Subject: RE: Basic constraints, key usage, and LDAP schema



 I see your point - I was missing the point that they are self-issued and
 was
 thinking of the case where you are delegating authority to an indirect
 issuer. In the indirect case the cert would need to be in the cross-cert
 pairs
 attribute and may also appear in the caCerts attribute.


 On the self issued ones, why are they needed at all? Why would a CA issue
 a cert to itself indicating that it can sign CRLs? Why do we need that?


 Sharon


 > -----Original Message-----
 > From: Tom Gindin [mailto:[e-mail]]
 > Sent: Wednesday, May 02, 2001 5:43 PM
 > To: Sharon Boeyen
 > Cc: 'Tim Polk'; Denis Pinkas; [e-mail]
 > Subject: RE: Basic constraints, key usage, and LDAP schema
 >
 >
 >
 >      In the current draft of X.509v4, "self-issued" means something
 > different than "self-signed".  "self-issued" appears to be
 > the condition
 > "the certificate's subject name can be matched to its own issuer name,
 > which is that of a CA", while "self-signed" is that with the added
 > condition "the certificate signature is verifiable with the public key
 > contained in the message".  Most of these CRL signing certificates are
 > "self-issued" in this sense, although not "self-signed".
 >      One other reason why such CRL signing certificates would
 > legitimately
 > not go into the CC Pair attribute would be that there is no
 > other directory
 > entry where the CA certificate to verify the signature on
 > this certificate
 > could be found, unlike any other certificates in CC Pair.
 >      Lastly, if a CRL signing certificate were issued by a CA
 > certificate
 > with the same DN, it would certainly belong in the same realm, if that
 > concept has any meaning at all.
 >
 >           Tom Gindin
 >
 >
 (snip)




Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA10273 for <[e-mail]>; Fri, 4 May 2001 05:22:38 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA15502; Fri, 4 May 2001 14:22:27 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id OAA18700; Fri, 4 May 2001 14:21:59 +0200
Message-ID: <[e-mail]>
Date: Fri, 04 May 2001 14:22:02 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "David A. Cooper" <[e-mail]>
CC: [e-mail]
Subject: Re: delta-CRLs
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

David,

This thread is now taking me (too) much time for my processing power. :-(

> At 06:05 PM 5/2/01 +0200, Denis Pinkas wrote:
> 
> >> The current is wrong on two major aspects:
> >>
> >> a) the numbering of the delta CRLs
> >
> 
> Since you claim to want to support "traditional" delta-CRLs, I will quote
> the text on delta-CRLs from section 12.6.3.3 of X.509 3rd edition (1997):
> 
> a delta-CRL shall not be issued without a corresponding complete
> CRL being issued at the same time. The value of the CRL number, 
> as conveyed in the CRL number extension field (if present), shall 
> be identical for both the delta-CRL and the corresponding complete CRL
> 
> Similar text was included in one of the old proposed draft amendments to
> the 1997 standard:
> 
> At reset time, concurrent with publication of a new base CRL is
> publication of the final delta-CRL for the old base CRL. Both CRLs 
> published concurrently (new base and final delta for old base) shall 
> contain identical values of the cRLNumber extension as well as
> identical values of thisUpdate time. The values of nextUpdate time
> will be different in each.
> 
> Both texts are quite clear that when a complete CRL and a delta-CRL are
> issued at the same time, and the two CRLs provide the same information,
> they must have the same cRLnumber. This is because the are effectively two
> instantiations of the same CRL.

The ISO text has two major problems:

1) It makes a major assumption, ... which is wrong: once a CA has started to
issue a base CRL (and hence it will issue delta-CRLs) then it must do it for
ever. A CA can issue a base CRL and then delta CRLs but then simply issue
complete CRL (i.e. full CRLs that do not support the delta mechanism) and
later one can start to issue a base a delta CRLs again.

2)  RFC 2459 in section 5.2.3 (CRL Number) says: 

   The CRL number is a non-critical CRL extension which conveys a
   monotonically increasing sequence number for each CRL issued by a CA.

Since two CRLs (whether they are base, delta, complete, whatever) cannot
have the same number, this means that the following sentence extracted from
the ISO text is wrong: "The value of the CRL number, as conveyed in the CRL
number extension field (if present), shall be identical for both the
delta-CRL and the corresponding complete CRL". 

> Notice also that the requirement is that when a new base is issued, the
> delta that is issued at the same time provides changes since the previous
> base. 

This is wrong as well because there is not necessarilly this previous base
(see the first major problem).

> One does not issue an empty delta. If one did, then every relying
> party would be forced to download every base CRL.

This is the intent, otherwise delta CRLs would grow for ever.

> >> b) the lack of use of the fields thisUpdate and nextUpdate in the
> >> delta-CRLs.

> As I stated before, the thisUpdate field specifies the time at which the
> CRL was issued. There is absolutely no reason to check that the current
> time is after thisUpdate. 

There is no notion of current time. The evaluation is made at time T, which
may be the current time or a time in the past.

> We can re-visit this issue, if necessary, once
> you have built a machine that allows people to travel back in time while
> simultaneously validating an X.509 certificate. Until then, we can assume
> that time increases monotonically and that the current time is always
> after thisUpdate.

No need to invent such a machine, but I appreciate your sense of humor.
Please keep flames away. See the previous comment.

> The nextUpdate field in a delta-CRL has the same meaning an in any other
> type of CRL, so there is no reason to discuss it here. As I said before,
> though, one can not say that any CRL whose nextUpdate time has not passed
> is the most current. There may have been an "emergency" CRL issued since
> that one was issued. If nextUpdate has passed, then you know the CRL is
> not the most current. If nextUpdate has not passed, then the CRL MAY be
> the most current, but there is no way to know for certain.

See my response to Tim on that topic.

> >> > They seem to depart from the traditional
> >> > deltas in certain details,
> >>
> >> They certainly do not.
 
> As I stated above, you state that whenever a base CRL is issued, an empty
> delta-CRL should be issued at the same time, with the delta-CRL using the
> concurrently issued base CRL as its base. This is not how traditional
> delta-CRLs work.

Think about it. To do that you have to take an example: a *first* base CRL
is issued at midnight (no base CRL *ever* exists before). A delta is
supposed to be issued every hour. Think first about the processing done by a
relying party at 3:30 a.m. Then think about the processing that will be done
at 0:30 a.m. You will then come to the same conclusion. Now if a base
existed before, then the proposal would not be consistant with the
definition of the construction of the updated CRL which is: 

   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.

Futhermore, the size of the delta CRLs would grow for ever.
 
> >> > but prevent use of sliding window deltas.
> >>
> >> Maybe. However, if you really want them to be part of this document,
> >> then
> >> they MUST *not* be mandatory. So the only way would be to add
> >> additional
> >> text that would explain how this can be done as an option. However I
> >> got the
> >> fealing that the traditional method may be in some way incompatible
> >> with the
> >> sliding window deltas, i.e. if the sliding method is chosen by the CRL
> >> Issuer relying parties may have difficulties to use the traditional
> >> method.
> >> But, maybe, you have the right text just ready to explain how this can
> >> be
> >> done. :-)
 
> When I referred to the "traditional" method in my paper, I was referring
> to the way delta-CRLs are issued, not how they are processed by relying
> parties. Notice, however, that the deltaCRLIndicator requires that "[t]he
> base CRL referenced by a deltaCRLIndicator extension shall be a CRL that
> is issued as complete for its scope (i.e. it is not itself a dCRL)." If by
> "relying parties using the traditional method" you mean always applying
> the delta-CRL to a full CRL whose cRLNumber is equal to the value in
> BaseCRLNumber, this requirement on the deltaCRLIndicator extension ensures
> that this can be done no matter how delta-CRLs are issued (traditional
> method, sliding window, or other). I don't think that anyone ever intended
> for this to be way that delta-CRLs are processed, but you can do it if you
> want.

I undersand clearly that you would like relying parties to take advantage of
sliding windows, by the "algorithm" that you proposed, which is based on the
ISO text, has flaws in it. See above.

> Even if delta-CRLs are issued using the "traditional" method, relying
> parties may choose to maintain a locally generated revocation list which
> they update which each successive delta-CRL that they download. 

I have addressed that point in details in my response to Tim. I think we
agree on this point.

> Remember that RFC 2459 stated:
> 
> The use of delta-CRLs can significantly improve processing time
> for applications
> which store revocation information in a format other than the CRL
> structure.  This
> allows changes to be added to the local database while ignoring
> unchanged information that is already in the local database.
> 
> We should not write text that seems to preclude this option.
> 
> The text that is in the document now was painstakingly crafted by the ISO
> Directory group and was carefully profiled by PKIX. The text does not
> mandate sliding window delta-CRLs, nor does it specify a particular way
> that relying parties must use delta-CRLs. It provides options to both CRL
> issuers and relying parties, but does not impose requirements on either.
> Please do not suggest that we change the text to preclude useful options
> when doing so would provide no benefits.

The ISO text has problems, so the text based on it has problems too. 

> >> > >[David] A delta-CRL is nearly the same as a full CRL. It has a
> >> thisUpdate,
> >> > >nextUpdate, cRLNumber, etc. just as a full CRL. It just has an
> >> incomplete
> >> > >list of revoked certificates.
> >> > >
> >> > >[Denis] Yes, but you have to explain detail how a relying party
> >> will use
> >> > >thisUpdate, nextUpdate for a base CRL and thisUpdate, nextUpdate
> >> for a delta
> >> > >to make sure that in both cases he got the freshest information.
> >
 
> There is no way, using CRLs, to ensure that you have the freshest
> information. 

True. But if you are using both base CRLs and delta-CRLs then you have that
guaranty up to the period of refresh of the delta-CRL (which is of course
much better than the period of refresh from the base CRL).

> If nextUpdate has passed, then you know that fresher
> information is available. If nextUpdate has not passed, then you do not
> know whether you have the freshest information or not. This is true for
> full CRLs, delta-CRLs, indirect CRLs, and any other type of CRL. If more
> text is needed to explain the use of the nextUpdate field then it should
> go in section 5.1.2.5 on the nextUpdate field, since it would apply to all
> CRLs, not just delta-CRLs.
> 
> >> > >[Denis]
> >> > >
> >> > >As said later, your paper provides the right answer (on page 1): "
> >> 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 text says " *a* specific, previously issued CRL", it does
> >> NOT say
> >> > >"or any, more recently, issued CRL".
 
> You are misinterpreting the quote. The sentence states what information is
> provided in a delta-CRL. It does not say anything about how the delta-CRL
> can be used. A delta-CRL provides information about certificates whose
> statuses have changed since the issuance of a specific, previously issued
> CRL. The delta-CRL may, however, be applied to more recently issued CRLs.

In the same spirit as you did, I could say that we would need a machine that
allows people to travel in the future. However, delta-CRLs cannot be applied
to more recently issued CRLs, unless you provide a clear example of how this
can be done.

> >> > > > >This paper is proposing a method for over-issuing the CRLs. It
> >> omits to take
> >> > > > >into consideration that in PKIX-1 we mandate the CRL number
> >> extension
> >> > > > >(section 5.2.3) so we need to advertise the nextUpdate. If you
> >> issue a CRL
> >> > > > >before the next update you have no more way to know which base
> >> CRL is the
> >> > > > >freshest CRL. I believe this is a major security weakness and
> >> for that
> >> > > > >reason this mechanism should be deprecated.

> Over-issuing is really out-of-scope for this discussion. However,
> over-issuing is merely one way to distribute revocation information more
> efficiently. If you issue CRLs once every 4 hours and I issue CRLs once an
> hour, but with a nextUpdate time 4 hours in the future, the information
> relying parties get from me will be no more stale than the information
> they get from you. If there is any "security weakness" it is from the
> delay in distributing revocation information, not from over-issuing.

Over-issuing of full CRLs provides a guaranty up to (usually less than) the
period of validity of the full CRL. A base CRL followed by delta-CRLs
provides a guaranty up to the period of validity of the delta CRLs (which is
indeed better). If mis-used, over-issuing of full CRLs provides could
provide a guaranty *equal* to the period of validity of the full CRL (which
is indeed worse).
 
> >> > >[David]  Finally, since a CRL issuer may issue "emergency"
> >> delta-CRLs, there
> >> > >is no guarantee that any delta-CRL whose nextUpdate time is later
> >> than the
> >> > >current time is the most current delta-CRL.
> >> > >
> >> > >[Denis] If you issue such "emergency" delta-CRLs then once again
> >> there is no
> >> > >guarantee that they will ever be seen. The "most recent delta-CRL"
> >> is any
> >> > >delta CRL which satisfies the following condition :
> >> > >
> >> > >" A delta-CRL which contains a Delta CRL Indicator equal to the
> >> cRLNumber of
> >> > >the base CRL and where the validation date (which may be the
> >> current time)
> >> > >is between thisUpdate and nextUpdate from that delta-CRL;"
 
> This seems to be a semantic problem. There can only be one "most recent
> CRL". You seem to want to mandate that people always use the "most recent
> CRL", but there is no way guarantee that you have the most recent CRL.

See the response above and my response to Tim.

> >> > > > >Any other method would first need to be proven to be secure
> >> (over-issuing
> >> > > > >CRLs and sliding window delta-CRLs have security problems)
> >>
> >> > >[Denis] There ARE security problems with sliding window delta-CRLs.
> >> I have
> >> > >descibed at length what the problems are. However, this does not
> >> mean that
> >> > >this technique cannot be supported as an OPTIO and IF we indicate
> >> in the
> >> > >text what are their security problems. The current text places the
> >> two
> >> > >techniques at the same level. The traditional way offers a
> >> guarantee while
> >> > >the other does not. There is indedd added complexity for building
> >> the
> >> > >software from the relying party.
 
> You have not described any security problems with sliding window
> delta-CRLs. You suggest that sliding window delta-CRLs should not be used
> until they have been proven secure. What type of proof are you looking
> for? Where are the proofs that CRLs of any type are secure? Where is the
> proof that X.509 certificates are secure? Once you provide me with the
> proofs that everything else in X.509 is secure, I'll try to find time to
> write a similar proof to show that sliding window delta-CRLs are secure.
> Until then, any suggestion that sliding window delta-CRLs need to be
> proven to be secure before they can be used is nothing but a red herring.

No comment.

Denis

> Dave


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA08791 for <[e-mail]>; Fri, 4 May 2001 05:01:50 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA14588; Fri, 4 May 2001 14:01:42 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id OAA08798; Fri, 4 May 2001 14:01:13 +0200
Message-ID: <[e-mail]>
Date: Fri, 04 May 2001 14:01:17 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Tim Polk <[e-mail]>
CC: "David A. Cooper" <[e-mail]>, pkix <[e-mail]>
Subject: Re: delta-CRLs
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tim,

I think we can solve the main problem you mention rather easily. Several
people, including Russ, had difficulties to understand the wording -and the
reason- of the following paragraph:

   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.

The reason of that paragraph was to say that if you have a different
technique to reconstruct the CRL, but if you get the same result, this is
equally acceptable. That paragraph was especially there to cover the case
you mention. You get the same result if you use a previously locally
reconstructed CRL. Now that you know the intent, I would propose to change
that paragraph. Taking into account the last proposal from Russ, this would
lead to the two following paragraphs:

   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. Applications that support 
   delta CRLs MUST ensure that time T falls between thisUpdate and 
   nextUpdate for both the base CRL and the delta CRL.

   Note: An application could also reconstruct an updated CRL, for 
   a specific time T, by using a previously locally reconstructed CRL 
   based on a given base CRL, and combining it with a delta CRL which 
   contains a delta CRL indicator extension with the same CRL number as 
   the base CRL.
 
I think this closes the issue.

People not interrested in the details do not need to look any further down
into this e-mail. However, I will nevertheless comment briefly for those
interrested in the details the remaining of that e-mail.

> Denis,
> 
> You seem to be advocating one *extremely* limited scenario for the use of
> delta CRLs.  Under your text, deltas may only be used with a specifically
> issued base CRLs.  That is, the application of delta CRLs to constructed
> CRLs seems to be forbidden.  We believe this scenario is inefficient and
> reduces or cancels completely the benefits of delta CRLs.

See the response above.

> Simple processing of the CRL number extension can support more efficient
> delta CRL processing.  These techniques permit an application to store
> revocation information in more efficient formats (e.g., a local database)
> and apply updates to that information.  I do not understand the problems
> you have with using the CRL number extension in deltas; the concepts in
> son-of-2459 are aligned with the requirements stated in X.509.  You have
> also deleted important points in the processing of certificate hold, as
> those points do not apply in your very limited scenario.
> 
> The current text was very carefully crafted to be correct, complete, and
> aligned with the X.509 standard.  I believe that the current text is
> correct, and should be maintained.

I do *not* believe that the current text is correct, and thus it should
*not* be maintained.

> I will compare the two sets of text, and describe the rationale for the
> original text.
> 
> First paragraphs are nearly identical.  You have replaced the second
> sentence and deleted the last sentence.  You replaced:
> 
>      Delta CRLs contain updates to revocation information previously
>      distributed, rather than all the information that would appear in a
>      complete CRL.
> 
> with:
> 
>      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.
> 
> That change is fine.  However, you delete the final sentence:
> 
>      Applications which store revocation information in a format other
>      than the CRL structure can add new revocation information to the
>      local database without reprocessing information.
> 
> I believe that is appropriate for your text, since the algorithm seems to
> *require* reprocessing a base whenever a delta is processed.
> Unfortunately, adding new revocation information without reprocessing
> information is an important benefit of delta CRLs.  I suspect that is why
> we disagree so vehemently.

We do not. See the explanations on top of this e-mail.

> In the second paragraph, you again deleted the last sentence:
> 
>      The combination of a CRL containing the delta CRL indicator extension
>      plus the CRL referenced in the BaseCRLNumber component of this
>      extension is equivalent to a full CRL, for the applicable scope, at
>      the time of publication of the  delta CRL.
> 
> Why was this text deleted?  By deleting this text, you impose unnecessary
> limitations on the use of deltas.  This seems to force the delta CRL user
> to obtain new base CRLs rather than use constructed CRLs.

Same. See the explanations on top of this e-mail.

> The third paragraph needed to be revised anyway, since it incorporates the
> old constraints that full CRLs and deltas be issued together.  However,
> you deleted all the information regarding the use of the CRL number
> extension in delta CRLs.  This is important information:
> 
> Current text:
> 
>    When a conforming CA issues a delta CRL, the CA MUST also issue a CRL
>    that is complete for the given scope.  Both the delta CRL and the
>    complete CRL MUST include the CRL number extension (see sec. 5.2.3).
>    The CRL number extension in the delta CRL and the complete CRL MUST
>    contain the same value.  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.
> 
> You deleted all but the last sentence.  The CRL number extension is
> required in delta CRLs so that future delta CRLs can be applied to the new
> constructed base CRL.

Certainly there is a CRL number extension in a delta CRL, but this is no
need to use it in the "algorithm" to reconstruct the "full" CRL. So there is
no need to add any *new* or additioal semantics to it. Your proposal would
add such a new semantics. In other words, this new semantics is NOT
required.

> You have inserted a new paragraph four:
> 
>      When a conforming CA issues a delta CRL, the delta CRL MUST include
>      a critical delta CRL indicator extension.
> 
> I am surprised we missed this one.  We should keep this text.

:-)

> Current text for paragraphs four and five are:
> 
>    An application can construct a CRL that is complete for a given
>    scope, at the current time, in either of the following ways:
> 
>       (a) by retrieving the current delta CRL for that scope, and
>       combining it with an issued CRL that is complete for that scope
>       and that has a cRLNumber greater than or equal to the cRLNumber of
>       the base CRL referenced in the delta CRL; or
> 
>       (b) by retrieving the current delta CRL for that scope and
>       combining it with a locally constructed CRL whose cRLNumber is
>       greater than or equal to the cRLNumber of the base CRL referenced
>       in the current delta CRL.
> 
>    The constructed CRL has the CRL number specified in the CRL number
>    extension found in the delta CRL used in its construction.
> 
> You've replaced this with:
> 
>      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.
> 
> First, the CRL that is constructed (in either text) may be complete for a
> given scope and time, but there is no way to demonstrate that the
> constructed CRL is "the most current".   We can never be sure that we
> haven't missed an emergency CRL (or delta CRL.)  We can only be sure that
> we haven't reached the next scheduled CRL publication date.

This is exactly where you missed the point.

Remember the second sentence of the "algorithm": "Applications that support
delta CRLs MUST ensure that time T falls between thisUpdate and nextUpdate
for both the base CRL and the delta CRL."

With this sentence you can be sure that either you have the latest or you
missed it. I can give you further details. If the CA issues a base CRL then,
it will issue delta CRLs. Every delta CRL will contain the most recent
information. There is no concept of emergency delta CRL. So for relying
parties taking advantage of delta CRLs they cannot miss something or they
will discover that they indeed missed something.

 
> In addition, you have deleted the semantics of the CRL number extension in
> delta CRLs.  

Certainly. I explained that the right "algorithm" makes use of nextUpdate
and thisUpdate and thus does need to care about the numbering of delta CRLs.
So no extra semantics is needed.

> Instead, you substitute text on nextUpdate and thisUpdate,
> which are independent extensions and have been covered elsewhere.

They were not covered at all.

> You have inserted a new paragraph:
> 
> 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.
> 
> First, I don't really see an algorithm.  Second, as Russ has pointed out,
> we don't require processing of deltas at all.

See the explanations on top of this e-mail.

> The current text closes with:
> 
>    CAs must ensure that application of a delta CRL to the referenced
>    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:
> 
>       (a) If a certificate was listed as revoked with revocation reason
>       certificateHold on a CRL (either a delta CRL or a CRL that is
>       complete for a given scope), whose cRLNumber is n, and the hold is
>       subsequently released, the certificate must be included in all
>       delta CRLs issued after the hold is released where the cRLNumber
>       of the referenced base CRL is less than or equal to n. The
>       certificate must be listed with revocation reason removeFromCRL
>       unless the certificate is subsequently revoked again for one of
>       the revocation reasons covered by the delta CRL, in which case the
>       certificate must be listed with the revocation reason appropriate
>       for the subsequent revocation.
> 
>       (b) If the certificate was not removed from hold, but was
>       permanently revoked, then it must be listed on all subsequent
>       delta CRLs where the cRLNumber of the referenced base CRL is less
>       than the cRLNumber of the CRL (either a delta CRL or a CRL that is
>       complete for the given scope) on which the permanent revocation
>       notice first appeared.
> 
> You replace this with:
> 
> CAs must ensure that application of a delta CRL to the referenced
> 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:
> 
>      (a) If a certificate was listed as revoked with revocation reason
>      certificateHold on a CRL (either a delta CRL or a CRL that is
>      complete for a given scope), and the hold is subsequently
>      released, the certificate must be listed with revocation reason
>      removeFromCRL until the next base CRL is issued.
> 
>      Note: Should the certificate be subsequently revoked again for
>      one of the revocation reasons covered by the delta CRL,
>      then the certificate must be listed with the revocation
>      reason appropriate for the subsequent revocation.
> 
>      (b) If the certificate was not removed from hold, but was
>      permanently revoked, then it must be listed as such on all
>      subsequent delta CRLs until the next base CRL is issued .
> 
> This text presents the biggest problems of all.  The text describes *what*
> needs to be listed on *which* delta CRLs.  By limiting this text to one
> very narrow scenario, you increase the likeliehood that delta CRL issuers
> that wish to do something efficient will get it wrong.  That will result
> in bad information from the relying party.

This text has be simply adapted to remove the semantics that existed on the
CRL number from delta-CRLs. It describes what a CA does, not what a relying
party does. I do not believe that there is the limitation as you mention. If
you really think that the text needs to be changed, please make a proposal
on it, but without adding any new seamntics to the CRL number. :-)

> The current text was very carefully crafted to ensure that it was
> consistent with X.509 and supported the general case.  I do not see the
> need to hamstring delta CRL implementers by limiting support to one
> narrowly defined scenario.

The revised text has been very carefully crafted to ensure that no new
semantics was introduced and that a simple scheme can be implemented so that
interoperability can be easily obtained.

Denis 

> Tim Polk


Received: from localhost (213.237.12.37.adsl.ynoe.worldonline.dk [213.237.12.37]) by above.proper.com (8.9.3/8.9.3) with SMTP id DAA04405 for <[e-mail]>; Fri, 4 May 2001 03:52:21 -0700 (PDT)
Message-Id: <[e-mail]>
Content-Type: text/html
X-Source: web mail
X-Form: AdrMsg.html
From: Gridcomp <[e-mail]>
To: [e-mail]
Date: Fri, 14 Apr 2000 00:07:30
Subject: Reduce your Software Development Cost

					
				<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
				<HTML>
				<HEAD>
				</HEAD>
				<body topmargin="0" leftmargin="0" bgcolor="#DDDDDD">
				
				<table border="0" cellPadding="0" cellSpacing="0" height="101" width="100%">
				  <tbody>
				    <tr>
				      <td bgColor="#dddddd" height="111" width="165">
				        <p align="center"><a href="http://www.gridcompintl.com"><img border="0" src="http://www.gridcompintl.com/logogrid.gif" width="163" height="101"></a></p>
				      </td>
				      <td bgColor="#dddddd" height="111" width="693">
				        <p align="right"> 
				        <p align="right"><a href="http://www.gridcompintl.com"><img border="0" src="http://www.gridcompintl.com/grid.gif" width="420" height="43"></a>
				        <p align="center"> </p>
				      </td>
				    </tr>
				    <tr>
				      <td bgColor="#264a6f" height="810" vAlign="top" width="165">
				        <p align="center"> 
				        <p align="center"> </p>
				        <p align="center"><br>
				        </p>
				        <p align="center"> 
				        </p>
				        <p align="center"> </p>
				        <table border="0" width="100%">
				          <tr>
				            <td align="center"><b><a href="http://www.gridcompintl.com"><font color="#DDDDDD" face="Verdana" size="2">Is
				              time running out for your  software development project?</font>
				              </a></b>
				              <p> </td>
				          </tr>
				          <tr>
				            <td width="100%" align="center"><b><a href="http://www.gridcompintl.com/offshore.htm"><font color="#DDDDDD" face="Verdana" size="2">Are
				              you looking for Off shore project development?</font>
				              </a></b>
				              <p><span style="mso-color-alt: windowtext"><b><font color="#DDDDDD" face="Verdana" size="2"><o:p>
				              </o:p>
				              </font>
				              </b></span></td>
				          </tr>
				          <tr>
				            <td width="100%" align="center">
				              <p class="MsoCommentText"><b><a href="http://www.gridcompintl.com/offshore.htm"><font color="#DDDDDD" face="Verdana" size="2">Do
				              you have to cut cost?</font></a></b></p>
				              <p class="MsoCommentText"><b><span style="mso-spacerun: yes"><font color="#DDDDDD" face="Verdana" size="2"> </font></span><a href="http://www.gridcompintl.com/offshore.htm"><font color="#DDDDDD" face="Verdana" size="2">But
				              you must continue innovating?</font></a><font color="#DDDDDD" face="Verdana" size="2"> </font></b></p>
				              <p><span style="mso-fareast-font-family: Times New Roman; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><b><a href="http://www.gridcompintl.com/offshore.htm"><font color="#DDDDDD" face="Verdana" size="2">Must
				              design and develop new products?</font></a></b></span></p>
				              <p> </td>
				          </tr>
				          <tr>
				            <td width="100%" align="center">
				            </td>
				          </tr>
				        </table>
				      </td>
				      <td bgColor="#dddddd" borderColor="#264a6f" height="810" style="border-top-style: solid; border-bottom-style: solid" width="695">
				       
				        
				
				              <img border="0" src="http://www.gridcompintl.com/curve.gif" width="110" height="107">
				
				          <table border="0" width="100%">
				            <tr>
				              <td width="18%"></td>
				              <td width="82%" align="center"><b><font color="#000080" face="Verdana" size="2"><a href="http://www.gridcompintl.com/">Is
				              time running out for your  software development project?</a></font>
				                </b></td>
				            </tr>
				            <tr>
				              <td width="18%"></td>
				              <td width="82%" align="center"><b><font color="#000080" face="Verdana" size="2"><a href="http://www.gridcompintl.com/offshore.htm">Are
				              you looking for Off shore project development?</a></font>
				                </b></td>
				            </tr>
				            <tr>
				              <td width="18%"></td>
				              <td width="82%" align="center"><font color="#000080"><b><font color="#000080" face="Verdana" size="2"><a href="http://www.gridcompintl.com/offshore.htm">Do
				              you have to cut cost? </a></font></b></font></td>
				            </tr>
				            <tr>
				              <td width="18%"></td>
				              <td width="82%" align="center"><font color="#000080" face="Verdana" size="2"><b><a href="http://www.gridcompintl.com/offshore.htm">But
				              you must continue innovating? </a></b></font></td>
				            </tr>
				            <tr>
				              <td width="18%"></td>
				              <td width="82%" align="center"><font color="#000080"><span style="mso-fareast-font-family: Times New Roman; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><font color="#000080" face="Verdana" size="2"><b><a href="http://www.gridcompintl.com/offshore.htm">Must
				              design and develop new products?</a></b></font></span></font></td>
				            </tr>
				          </table>
				          <blockquote>
				<p style="text-align: justify; "><br>
				<font face="Verdana" size="2"><b>Gridcomp</b>
				is
				on-site consulting and offshore development company. We design, develop,
				implement
				and support E-Business Solutions. Practically right from the start of IT
				boom, software development companies from USA, have used off-shore development
				company resources from other countries. We created Gridcomp Inc. exactly for
				the companies interested in <a href="http://www.gridcompintl.com/offshore.htm">
				offshore</a> development. We believe in providing high quality yet inexpensive
				offshore development services with qualified on-site consultants for deployment
				of technology solutions for our clients in USA, enhancing their competitiveness.
				</font></p>
				<p style="text-align: justify; "><font face="Verdana" size="2">Gridcomp is
				one of the fast growing software services and product Development Company
				specializing in leading technologies.</font></p>
				<hr>  
				<p align="Left"><font face="Verdana" size="2"><b> <a href="http://www.gridcompintl.com">Gridcomp International, Inc.</a></b></font></p>
				          <table border="0" width="100%">
				            <tr>
				              <td width="6%" align="center"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="94%"><b><font face="Verdana" size="2">Enterprise Application
				Integration</font></b>  </td>
				            </tr>
				            <tr>
				              <td width="6%" align="center"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="94%"><font face="Verdana" size="2"><b>Distributed Business Computing   </b></font>  </td>
				            </tr>
				            <tr>
				              <td width="6%" align="center"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="94%"><font face="Verdana" size="2"><b>Business Intelligence
				  </b></font>  </td>
				            </tr>
				            <tr>
				              <td width="6%" align="center"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="94%"><font face="Verdana" size="2"><b>E-Commerce  </b></font>
				              </td>
				            </tr>
				          </table>
				<hr>
				<p><font face="Verdana" size="2">Why Gridcomp International Inc. is suitable
				for your software development requirement? </font></p>
				<p class="MsoNormal" align="justify"><font face="Verdana" size="2"><span style="mso-bidi-font-size: 12.0pt">
				High reliability, High service level, Moderate prices, Wide range of services,
				Speedy project implementation, High degree of confidentiality, Very simple
				scheme for customer interaction, Constant working resource availability</span></font></p>
				<p class="MsoNormal"><font face="Verdana" size="2"><span style="mso-bidi-font-size: 12.0pt">
				For more information visit our web page: <a href="http://www.gridcompintl.com/whyg2.htm">
				Click here</a></span></font></p>
				          <table border="0" width="80%">
				            <tr>
				              <td width="6%" align="center" valign="top"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="94%" align="justify"><font face="Verdana" size="2"><span style="mso-bidi-font-size: 12.0pt">
				Our    distinctive competence lies in the focused range of services we provide.<o:p>
				                     </span></font></td>
				            </tr>
				            <tr>
				              <td width="6%" align="center" valign="top"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="94%" align="justify"><font face="Verdana" size="2"><span style="mso-bidi-font-size: 12.0pt">
				We    believe that our thrust should be in specific areas where we can add
				    significant value.<o:p>         </span></font></td>
				            </tr>
				            <tr>
				              <td width="6%" align="center" valign="top"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="94%" align="justify"><font face="Verdana" size="2"><span style="mso-bidi-font-size: 12.0pt">
				We    created Gridcomp Inc. exactly for the companies interested in offshore
				    development.<o:p>         </span></font></td>
				            </tr>
				            <tr>
				              <td width="6%" align="center" valign="top"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="94%" align="justify"><font face="Verdana" size="2"><span style="mso-bidi-font-size: 12.0pt">
				The    Gridcomp business model adopts a true software factory approach.<o:p>
				     </span></font></td>
				            </tr>
				            <tr>
				              <td width="6%" align="center" valign="top"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="94%" align="justify"><font face="Verdana" size="2"><span style="mso-bidi-font-size: 12.0pt">
				Our    pool of on-site consultants is in turn backed by the offshore development
				    center that executes offshore projects and also provides a 24/7 technical
				    support desk.    </span></font></td>
				            </tr>
				            <tr>
				              <td width="6%" align="center" valign="top"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="94%" align="justify"><font face="Verdana" size="2"><span style="mso-bidi-font-size: 12.0pt">Our
				                India Development Centers are located at Ahmedabad, India.
				                Gridcomp plans to leverage the Software Park to provide
				                dedicated development centers for clients worldwide. </span></font></td>
				            </tr>
				          </table>
				<hr>
				<p><font face="Verdana" size="2" color="#800000"><b><a href="http://www.gridcompintl.com/product.htm">
				Our Services are divided into this areas</a></b></font></p>
				          <table border="0" width="80%">
				            <tr>
				              <td width="30" align="center" valign="top"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="429" colspan="2"><font face="Verdana" size="2"><a href="http://www.gridcompintl.com/offshores.htm">
				Off-Shore Software Development </a></font></td>
				            </tr>
				            <tr>
				              <td width="30" align="center" valign="top"></td>
				              <td width="12">
				                <p align="center"><font size="2" face="Verdana"><b><span style="font-size: 8pt; font-family: Symbol">></span></b></font></td>
				              <td width="411"><font face="Verdana" size="2"><a href="http://www.gridcompintl.com/offshore.htm"> Why    Offshore?
				    </a></font></td>
				            </tr>
				            <tr>
				              <td width="30" align="center" valign="top"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="429" colspan="2"><font face="Verdana" size="2"><a href="http://www.gridcompintl.com/consulting.htm">
				On-site consulting </a></font></td>
				            </tr>
				            <tr>
				              <td width="30" align="center" valign="top"></td>
				              <td width="12">
				                <p align="center"><font size="2" face="Verdana"><b><span style="font-size: 8pt; font-family: Symbol">></span></b></font></td>
				              <td width="411"><font face="Verdana" size="2"><a href="http://www.gridcompintl.com/consulting.htm"> Why    On-site?
				    </a></font></td>
				            </tr>
				            <tr>
				              <td width="30" align="center" valign="top"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="429" colspan="2"><font face="Verdana" size="2"><a href="http://www.gridcompintl.com/technology.htm">
				 Technology Solutions</a></font></td>
				            </tr>
				            <tr>
				              <td width="30" align="center" valign="top"></td>
				              <td width="12" align="center"><font size="2" face="Verdana"><b><span style="font-size: 8pt; font-family: Symbol">></span></b></font></td>
				              <td width="413"><font face="Verdana" size="2"> <span style="mso-bidi-font-size: 12.0pt">Enterprise
				                Application Integration
				    </span></font></td>
				            </tr>
				            <tr>
				              <td width="30" align="center" valign="top"></td>
				              <td width="12" align="center"><font size="2" face="Verdana"><b><span style="font-size: 8pt; font-family: Symbol">></span></b></font></td>
				              <td width="413"><font face="Verdana" size="2"><span style="mso-bidi-font-size: 12.0pt">Mobile
				                Integration Solutions
				    </span></font></td>
				            </tr>
				            <tr>
				              <td width="30" align="center" valign="top"></td>
				              <td width="12" align="center"><font size="2" face="Verdana"><b><span style="font-size: 8pt; font-family: Symbol">></span></b></font></td>
				              <td width="413"><font face="Verdana" size="2"><span style="mso-bidi-font-size: 12.0pt">CAD
				                / CAM Engineering Solutions
				    </span></font></td>
				            </tr>
				            <tr>
				              <td width="30" align="center" valign="top"></td>
				              <td width="12" align="center"><font size="2" face="Verdana"><b><span style="font-size: 8pt; font-family: Symbol">></span></b></font></td>
				              <td width="413"><font face="Verdana" size="2"><span style="mso-bidi-font-size: 12.0pt">E-Commerce
				    </span></font></td>
				            </tr>
				            <tr>
				              <td width="30" align="center" valign="top"></td>
				              <td width="12" align="center"><font size="2" face="Verdana"><b><span style="font-size: 8pt; font-family: Symbol">></span></b></font></td>
				              <td width="413"><font face="Verdana" size="2"><span style="mso-bidi-font-size: 12.0pt">ASIC
				                / FPGA design
				    </span></font></td>
				            </tr>
				            <tr>
				              <td width="30" align="center" valign="top"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="427" colspan="2"><font face="Verdana" size="2"><a href="http://www.gridcompintl.com/technical.htm">
				Technology Marketing</a>
				    </font></td>
				            </tr>
				            <tr>
				              <td width="30" align="center" valign="top"></td>
				              <td width="12" align="center"><font size="2" face="Verdana"><b><span style="font-size: 8pt; font-family: Symbol">></span></b></font></td>
				              <td width="413"><font face="Verdana" size="2"><span style="mso-bidi-font-size: 10.0pt">Marketing    Collateral Services </span>
				    </font></td>
				            </tr>
				            <tr>
				              <td width="30" align="center" valign="top"></td>
				              <td width="12" align="center"><font size="2" face="Verdana"><b><span style="font-size: 8pt; font-family: Symbol">></span></b></font></td>
				              <td width="413"><font face="Verdana" size="2"><span style="mso-bidi-font-size: 10.0pt">
				   Preparing marketing presentations Preparing technical presentations</span></font></td>
				            </tr>
				            <tr>
				              <td width="30" align="center" valign="top"></td>
				              <td width="12" align="center"><font size="2" face="Verdana"><b><span style="font-size: 8pt; font-family: Symbol">></span></b></font></td>
				              <td width="413"><font face="Verdana" size="2"><span style="mso-bidi-font-size: 12.0pt">
				   Technical Marketing Collateral </span><span style="mso-bidi-font-size: 10.0pt">
				Product    Training manuals 
				 </span>
				    </font></td>
				            </tr>
				            <tr>
				              <td width="30" align="center" valign="top"></td>
				              <td width="12" align="center"><font size="2" face="Verdana"><b><span style="font-size: 8pt; font-family: Symbol">></span></b></font></td>
				              <td width="413"><span style="mso-bidi-font-size: 10.0pt"><font face="Verdana" size="2">
				Competitive analysis for products Design</font> </span></td>
				            </tr>
				            <tr>
				              <td width="30" align="center" valign="top"></td>
				              <td width="12" align="center"><font size="2" face="Verdana"><b><span style="font-size: 8pt; font-family: Symbol">></span></b></font></td>
				              <td width="413"><span style="mso-bidi-font-size: 10.0pt"><font face="Verdana" size="2">Development    of   product demo (Hardware & Software) </font> </span></td>
				            </tr>
				            <tr>
				              <td width="30" align="center" valign="top"></td>
				              <td width="12" align="center"><font size="2" face="Verdana"><b><span style="font-size: 8pt; font-family: Symbol">></span></b></font></td>
				              <td width="413"><span style="mso-bidi-font-size: 10.0pt"><font face="Verdana" size="2"> Technical
				    support</font> </span></td>
				            </tr>
				            <tr>
				              <td width="30" align="center" valign="top"></td>
				              <td width="12" align="center"><font size="2" face="Verdana"><b><span style="font-size: 8pt; font-family: Symbol">></span></b></font></td>
				              <td width="413"><span style="mso-bidi-font-size: 10.0pt"><font face="Verdana" size="2"> Analysis
				and    summary data of customer inquiries</font></span></td>
				            </tr>
				          </table>
				<hr>
				<p class="MsoNormal"><b><font face="Verdana" size="2"><span style="mso-bidi-font-size: 12.0pt"><font color="#800000">
				Strategic advantages of software development in India</font></span></font></b></p>
				          <table border="0" width="80%">
				            <tr>
				              <td width="7%" align="center" valign="top"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="190%"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2">Significant  reduction in costs  </font> </span></font></td>
				            </tr>
				            <tr>
				              <td width="7%" align="center" valign="top"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="190%"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2">Competitive rates for contracting charges that are less than 50% of USA rates! </font></span>  </font></td>
				            </tr>
				            <tr>
				              <td width="7%" align="center" valign="top"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="190%"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2">
				No overheads. </font> </span> </font></td>
				            </tr>
				            <tr>
				              <td width="7%" align="center" valign="top"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="190%"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2">
				No general and administrative costs. </font> </span>  </font></td>
				            </tr>
				            <tr>
				              <td width="7%" align="center" valign="top"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="190%"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2">
				No space requirements.  </font> </span> </font></td>
				            </tr>
				            <tr>
				              <td width="7%" align="center" valign="top"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="190%"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2">
				No facilities costs (such as rent, utilities, maintenance) </font></span></font></td>
				            </tr>
				            <tr>
				              <td width="7%" align="center" valign="top"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="190%"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2">
				No recruiting or human resources costs.  </font> </span> </font></td>
				            </tr>
				            <tr>
				              <td width="7%" align="center" valign="top"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="190%"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2">
				Availability of highly educated and skilled professionals </font></span></font></td>
				            </tr>
				            <tr>
				              <td width="7%" align="center" valign="top"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="190%"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2">
				India has the second largest pool of English-speaking technical talent. </font></span>
				  </font></td>
				            </tr>
				            <tr>
				              <td width="7%" align="center" valign="top"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="190%"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2">
				  Shortened development time frames.  </font> </span> </font></td>
				            </tr>
				            <tr>
				              <td width="7%" align="center" valign="top"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="190%"><span style="mso-bidi-font-size: 12.0pt"><font face="Verdana" size="2">
				Strong work ethics.</font> </span></td>
				            </tr>
				            <tr>
				              <td width="7%" align="center" valign="top"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="190%"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2">
				Scope for development to take place 24 hours a day because of the different
				time zones.</font></span></font></td>
				            </tr>
				            <tr>
				              <td width="7%" align="center" valign="top"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="190%"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2">
				Full control over the project being developed in India by keeping in touch with the development team
				                through high-speed communication links. </font></span>
				  </font></td>
				            </tr>
				            <tr>
				              <td width="7%" align="center" valign="top"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="190%"><span style="mso-bidi-font-size: 12.0pt"><font face="Verdana" size="2">Easier procedure for movement of hardware and software</font> </span></td>
				            </tr>
				            <tr>
				              <td width="7%" align="center" valign="top"></td>
				              <td width="190%"></td>
				            </tr>
				          </table>
				<p class="MsoNormal"><font face="Verdana" size="2"><span style="mso-bidi-font-size: 12.0pt">
				For more details log on to our web page: <a href="http://www.gridcompintl.com/benefito.htm">
				Click here</a></span></font></p>
				<hr>
				<p class="MsoNormal" align="Left"><span style="mso-bidi-font-size: 12.0pt"><b><span style="mso-bidi-font-size: 12.0pt; mso-tab-count: 1"><font face="Verdana" color="#800000" size="2">
				Our interaction model are as follows</font></span></b></span></p>
				          <table border="0" width="80%">
				            <tr>
				              <td width="33%" align="center"><font size="2" face="Verdana"><b><a href="http://www.gridcompintl.com/product.htm#plan">
				Via Local Manager </a>
				                </b></font></td>
				              <td width="8%" align="center" rowspan="2"><font size="2" face="Verdana"><b><span style="font-size: 8pt; font-family: Symbol"><</span></b></font></td>
				              <td width="9%" align="center" rowspan="2"><font size="2" face="Verdana"><b><font color="#336600">Client</font></b></font></td>
				              <td width="9%" align="center" rowspan="2"><font size="2" face="Verdana"><b><span style="font-size: 8pt; font-family: Symbol">></span></b></font></td>
				              <td width="43%" align="center"><font size="2" face="Verdana"><b><a href="http://www.gridcompintl.com/product.htm#plan">Via Off-shore Manager </a></b></font></td>
				            </tr>
				            <tr>
				              <td width="33%" align="center"><font size="2" face="Verdana"><b>(USA office)</b></font></td>
				              <td width="43%" align="center"><font size="2" face="Verdana"><b> (India Development Center)</b></font></td>
				            </tr>
				          </table>
				<hr>
				<p class="MsoNormal" align="Left"><b><font face="Verdana" size="2" color="#800000"><span style="mso-bidi-font-size: 12.0pt">
				Goals of our Company</span></font><u><span style="font-size: 8pt; "><o:p></o:p>
				</span></u></b></p>
				<p style="text-align: justify; "><font face="Verdana" size="2"><span style="mso-bidi-font-size: 12.0pt">
				One of the most important goals of our Company is to create the most comfortable
				conditions for customers. We have developed <a href="http://www.gridcompintl.com/product.htm#plan">
				plans</a> that are most convenient for our clients (the details about the
				customized plans log on our <a href="http://www.gridcompintl.com/product.htm">web-page</a>.</span><span style="color: rgb(38,74,111); ">
				 <br>
				</span></font></p>
				<p style="text-align: justify; "><font face="Verdana" size="2"><span style="color: black; ">We offer also a wide selection of planning
				and budgeting models for our services. The most widely used models are as
				follows: <a href="http://www.gridcompintl.com/product.htm#Project_based">Project-Based
				Plan</a> & <a href="http://www.gridcompintl.com/product.htm#Time_based">Time-Based Plan</a>.<o:p></o:p></span></font></p>
				<p class="MsoNormal" style="MsoNormaltext-align: justify; " align="justify"><font face="Verdana" size="2"><span style="mso-bidi-font-size: 12.0pt">
				Nevertheless, if your company requires other operating rules, we would be
				glad to oblige.<o:p></o:p></span></font></p>
				<p class="MsoNormal" style="MsoNormaltext-align: justify; " align="justify"><font face="Verdana" size="2"><span style="mso-bidi-font-size: 12.0pt">
				Our main goal is to make a client's life easier. We solve most of the technical
				problems internally within our Company, so a client is usually only informed
				that the project is implemented. When necessary, however, our specialists are
				ready to supply technical consulting of any depth concerning the project; this
				approach allows a client to be aware of as many project implementation
				details.<o:p> </span></font></p>
				<hr>
				<p class="MsoNormal" style="tab-stops: 115.0pt" align="Left"><b><font face="Verdana" size="2" color="#800000"><span style="mso-bidi-font-size: 12.0pt">Our
				Strengths</span></font></b></p>
				<p class="MsoNormal" style="tab-stops: 115.0pt" align="Left"><font face="Verdana" size="2">Our core competency is software / hardware engineers with these skills: </font></p>
				          <table border="0" width="80%">
				            <tr>
				              <td width="5%" align="center" valign="top"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="95%"><font face="Verdana" size="2">Software programming skills:
				    Java, J2EE, <span style="font-size: 10.0pt; mso-fareast-font-family: Times New Roman; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Java
				    Beans, EJB, JSP, JINI, XML, WAP, WML, J2ME, UML-Rational Rose,<span style="mso-spacerun: yes">
				    </span></span>C, C++, VC++, C # and Visual basic.</font></td>
				            </tr>
				            <tr>
				              <td width="5%" align="center" valign="top"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="95%"><font size="2" face="Verdana"><span style="mso-spacerun: yes; font-size: 10.0pt; mso-fareast-font-family: Times New Roman; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Application
				    Servers: </span><span style="font-size: 10.0pt; mso-fareast-font-family: Times New Roman; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><span style="mso-spacerun: yes">BEA
				    </span>Web Logic, IBM Web Sphere, Sun Java Web server, Apache, Oracle 9i
				    Application Server.</span></font></td>
				            </tr>
				            <tr>
				              <td width="5%" align="center" valign="top"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="95%"><font face="Verdana" size="2">Client
				    / Server and Data Base technology – CORBA, Oracle, Sybase, SQL server, Power Builder.</font></td>
				            </tr>
				            <tr>
				              <td width="5%" align="center" valign="top"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="95%"><font face="Verdana" size="2">Web Based Technology – Java, COM,
				                DCOM, Perl, CGI, HTML, XML.</font></td>
				            </tr>
				            <tr>
				              <td width="5%" align="center" valign="top"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="95%"><font face="Verdana" size="2">Operating system internals – UNIX, Solaris, NT, Windows 95</font></td>
				            </tr>
				            <tr>
				              <td width="5%" align="center" valign="top"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="95%"><font face="Verdana" size="2">Network management/administration –
				                SNMP, Routers, switches, bridges, DSL, Frame relay, ATM</font></td>
				            </tr>
				            <tr>
				              <td width="5%" align="center" valign="top"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="95%"><font face="Verdana" size="2">System administration – Unix, NT,
				    Win 2000, Solaris, Linux</font></td>
				            </tr>
				            <tr>
				              <td width="5%" align="center" valign="top"><font face="Verdana"><span style="mso-bidi-font-size: 12.0pt"><font size="2"><b>»</b> </font> </span></font></td>
				              <td width="95%"><font face="Verdana" size="2">Networking / Telecommunication software – TCP/IP protocol suite, ISDN,
				                xDSL, ATM, Frame relay, SNMP, LAN, WAN protocols</font></td>
				            </tr>
				          </table>
				<hr>
				<p class="MsoNormal" style="tab-stops: 115.0pt" align="Left"><font face="Verdana" size="2"><span style="mso-bidi-font-size: 12.0pt"><font color="#800000"><b>
				For further information please contact at</b></font></span><span style="color: black; "><o:p>
				</o:p></span></font></p>
				<p class="MsoNormal" align="Center"><b><font face="Verdana" size="2" color="#283043"><span style="mso-bidi-font-size: 12.0pt">
				 </span><span style="color: black; ">706 Colorado Ave, Suite C11, Palo
				Alto, CA 94303, USA<br>
				         Telephone: [phone]
				<br>
				       Fax:+01-</span><span style="color: black; " class="emailstyle17">240-</span><span style="color: black; ">
				371-0543<o:p></o:p></span></font></b></p>
				<p class="MsoNormal" align="left"><font face="Verdana" size="2" color="#283043"><b><span style="mso-bidi-font-size: 10.0pt">e-mail:</span><span style="color: black; "><a href="mailto:[e-mail]">
				[e-mail]</a>  <br>
				e-mail: <a href="mailto:[e-mail]">
				[e-mail]</a></span></b></font></p>
				        </blockquote>
				        <p><img border="0" src="http://www.gridcompintl.com/curve2.gif" width="107" height="110"></p>
				      </td>
				    </tr>
				  </tbody>
				
				  </table>
				
				
				<p align="center"><b><font face="Verdana" size="2">This
				is not meant to be an unsolicited email.....<br>
				Under Bills 1618
				Title III passed by the 105th US Congress this mail cannot be considered spam as long as <br>
				 we include contact information and
				a method to be removed from our mailing list.</font></b></p>
				
				<p align="center"><b><font face="Verdana" size="2">If
				you like an email or list of email address(es) to be removed from the mailing list, <br>
				 please
				reply to this e-mail with a subject REMOVE and list
				the email address(es) <br>
				 in the body of your reply message. We
				will make sure that you do not receive further messages.<br>
				We sincerely apologize for any inconvenience caused
				to you.</font></b></p>
				</BODY>
				</HTML>			
			


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA11164 for <[e-mail]>; Thu, 3 May 2001 14:39:25 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <KGKQ8LVQ>; Thu, 3 May 2001 17:38:57 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: "Housley, Russ" <[e-mail]>
Cc: [e-mail]
Subject: RE: delta CRLs
Date: Thu, 3 May 2001 17:29:52 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D418.30B6BDC0"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D418.30B6BDC0
Content-Type: text/plain;
	charset="iso-8859-1"

Russ:

Please comments in-line


>Russ: Please note minor word smithing for grammar and for technical 
>accuracy.  The sentences should read as follows.
>
>"A delta CRL provides an update to a previously issued complete CRL.  A 
>delta CRL only includes entries for certificates that have changed status 
>since the complete CRL referenced in the delta CRL extension was issued."

No problem.

[Santosh Says: Per other e-mails, also replace "complete" with "base")

>Also a minor technical change to your other sentence:
>
>"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 or lower number 
>as the base CRL."

The most recent X.509 says:

    the combination of a CRL containing the delta CRL indicator extension
    plus the CRL referenced in the BaseCRLNumber component of this
    extension is equivalent to a full CRL, for the applicable scope, at the
    time of publication of the dCRL.

So, the appropriate thing to do seems to be dropping the phrase:

    An application can construct an updated CRL by combining a base CRL and
    a delta CRL which contains a delta CRL indicator extension with the same
    CRL number as the base CRL.

>Please note that the delta CRL can always be applied to a higher base than 
>the one referenced in the delta CRL extension.

This will result in collisions.  The later CRL and delta CRL may both 
contain the same additions.  However, with on-hold, a certificate that was 
removeFromCRL could be put back on hold.

[Santosh Says: The collisions are not a problem.  You may need to apply a
later CRL because other bases may have been issued and the referenced base
may have been deleted from the directory.  The basic approach is to apply a
delta to a base only of the delta is issued to a base whose thisUpdate is
prior to thisUpdate field of the delta.  Thus, what you are suggesting
regarding hold can never occur.  All of these rules are spelled out in Annex
B of the X.509]

>I also agree with Russ that PKIX need not include the "hold" feature.

Cool.

Russ

------_=_NextPart_001_01C0D418.30B6BDC0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: delta CRLs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Russ:</FONT>
</P>

<P><FONT SIZE=3D2>Please comments in-line</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;Russ: Please note minor word smithing for grammar =
and for technical </FONT>
<BR><FONT SIZE=3D2>&gt;accuracy.&nbsp; The sentences should read as =
follows.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&quot;A delta CRL provides an update to a =
previously issued complete CRL.&nbsp; A </FONT>
<BR><FONT SIZE=3D2>&gt;delta CRL only includes entries for certificates =
that have changed status </FONT>
<BR><FONT SIZE=3D2>&gt;since the complete CRL referenced in the delta =
CRL extension was issued.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>No problem.</FONT>
</P>

<P><FONT SIZE=3D2>[Santosh Says: Per other e-mails, also replace =
&quot;complete&quot; with &quot;base&quot;)</FONT>
</P>

<P><FONT SIZE=3D2>&gt;Also a minor technical change to your other =
sentence:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&quot;An application can construct an updated =
CRL by retrieving the appropriate </FONT>
<BR><FONT SIZE=3D2>&gt;base CRL for that scope, and combining it with a =
delta CRL which contains </FONT>
<BR><FONT SIZE=3D2>&gt;a delta CRL indicator extension with the same =
CRL number or lower number </FONT>
<BR><FONT SIZE=3D2>&gt;as the base CRL.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>The most recent X.509 says:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; the combination of a CRL =
containing the delta CRL indicator extension</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; plus the CRL referenced in the =
BaseCRLNumber component of this</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; extension is equivalent to a full =
CRL, for the applicable scope, at the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; time of publication of the =
dCRL.</FONT>
</P>

<P><FONT SIZE=3D2>So, the appropriate thing to do seems to be dropping =
the phrase:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; An application can construct an =
updated CRL by combining a base CRL and</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; a delta CRL which contains a =
delta CRL indicator extension with the same</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; CRL number as the base =
CRL.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;Please note that the delta CRL can always be =
applied to a higher base than </FONT>
<BR><FONT SIZE=3D2>&gt;the one referenced in the delta CRL =
extension.</FONT>
</P>

<P><FONT SIZE=3D2>This will result in collisions.&nbsp; The later CRL =
and delta CRL may both </FONT>
<BR><FONT SIZE=3D2>contain the same additions.&nbsp; However, with =
on-hold, a certificate that was </FONT>
<BR><FONT SIZE=3D2>removeFromCRL could be put back on hold.</FONT>
</P>

<P><FONT SIZE=3D2>[Santosh Says: The collisions are not a =
problem.&nbsp; You may need to apply a later CRL because other bases =
may have been issued and the referenced base may have been deleted from =
the directory.&nbsp; The basic approach is to apply a delta to a base =
only of the delta is issued to a base whose thisUpdate is prior to =
thisUpdate field of the delta.&nbsp; Thus, what you are suggesting =
regarding hold can never occur.&nbsp; All of these rules are spelled =
out in Annex B of the X.509]</FONT></P>

<P><FONT SIZE=3D2>&gt;I also agree with Russ that PKIX need not include =
the &quot;hold&quot; feature.</FONT>
</P>

<P><FONT SIZE=3D2>Cool.</FONT>
</P>

<P><FONT SIZE=3D2>Russ</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0D418.30B6BDC0--


Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA10778 for <[e-mail]>; Thu, 3 May 2001 14:37:27 -0700 (PDT)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id J0AR5FQ7; Thu, 3 May 2001 14:32:08 -0700
From: "Carlin Covey" <[e-mail]>
To: "Tim Polk" <[e-mail]>, "pkix" <[e-mail]>
Subject: RE: delta-CRLs
Date: Thu, 3 May 2001 14:38:12 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C0D3DE.AE2DC710"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>

This is a multi-part message in MIME format.

------=_NextPart_000_0002_01C0D3DE.AE2DC710
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Tim,

Just to set the record straight, Russ Housley proposed the "new paragraph
four"
in an email on 4/26.  See below.

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation


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



  -----Original Message-----
  From: Tim Polk [mailto:[e-mail]]
  Sent: Thursday, May 03, 2001 12:30 PM
  To: Denis Pinkas; David A. Cooper; pkix
  Subject: Re: delta-CRLs


 <snip>


   You have inserted a new paragraph four:

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


  I am surprised we missed this one.  We should keep this text.


 <snip>

------=_NextPart_000_0002_01C0D3DE.AE2DC710
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dus-ascii" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D630353121-03052001>Tim,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D630353121-03052001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D630353121-03052001>Just=20
to set the record straight, Russ Housley proposed the "new paragraph =
four"=20
</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D630353121-03052001>in an=20
email on 4/26.&nbsp; See below.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D630353121-03052001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D630353121-03052001>
<P><FONT=20
size=3D2>Regards,<BR><BR>Carlin<BR><BR>____________________________<BR><B=
R>-&nbsp;=20
Carlin Covey<BR>&nbsp;&nbsp; Cylink Corporation =
</FONT></P></SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D630353121-03052001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D630353121-03052001>----------------------------------------------=
-------------------------------------------------------------------</SPAN=
></FONT><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D630353121-03052001></SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D630353121-03052001><FONT=20
size=3D2>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
  <BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
    <P>Carlin:</P>
    <P>I would prefer to leave the first sentence alone. I think that it =
is </P>
    <P>explanation of delta CRLs. However, I like your point, and =
suggest the=20
    </P>
    <P>addition of the following paragraph:</P>
    <P>When a conforming CA issues a delta CRL, the delta CRL MUST =
include a</P>
    <P>critical delta CRL indicator extension.</P>
    <P>Russ</P></BLOCKQUOTE></BLOCKQUOTE>
<P>&nbsp;</P></FONT></SPAN></FONT></DIV>
<BLOCKQUOTE>
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma><FONT=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Tim Polk=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, May 03, 2001 =
12:30=20
  PM<BR><B>To:</B> Denis Pinkas; David A. Cooper; =
pkix<BR><B>Subject:</B> Re:=20
  delta-CRLs<BR><BR></FONT></FONT></DIV></BLOCKQUOTE>
<DIV><FONT color=3D#0000ff><SPAN class=3D630353121-03052001><FONT =
face=3DArial=20
size=3D2>&nbsp;<FONT =
face=3DTahoma>&lt;snip&gt;</FONT></FONT></SPAN></FONT></DIV>
<DIV><SPAN class=3D630353121-03052001></SPAN>&nbsp;</DIV>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
  <DIV><SPAN class=3D630353121-03052001><FONT color=3D#0000ff =
face=3DArial=20
  size=3D2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=3D630353121-03052001>&nbsp;</SPAN>You have inserted a =
new=20
  paragraph four:<BR></DIV>
  <DL>
    <DD>When a conforming CA issues a delta CRL, the delta CRL MUST =
include=20
    <DD>a critical delta CRL indicator extension.<BR><BR></DD></DL>
  <DIV>I am surprised we missed this one.&nbsp; We should keep this=20
  text.<BR><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN =

  =
class=3D630353121-03052001>&nbsp;</SPAN></FONT></FONT></FONT></DIV></BLOC=
KQUOTE>
<DIV><FONT color=3D#0000ff><FONT size=3D2><FONT face=3DArial><SPAN=20
class=3D630353121-03052001>&nbsp;</SPAN><BR><SPAN=20
class=3D630353121-03052001>&nbsp;&lt;snip&gt;&nbsp;</SPAN></FONT></FONT><=
/FONT></DIV></BODY></HTML>

------=_NextPart_000_0002_01C0D3DE.AE2DC710--



Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA09632 for <[e-mail]>; Thu, 3 May 2001 14:27:02 -0700 (PDT)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id RAA14280; Thu, 3 May 2001 17:27:03 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 03 May 2001 17:24:51 -0400
To: "David P. Kemp" <[e-mail]>, [e-mail]
From: Tim Polk <[e-mail]>
Subject: Re: Basic constraints, key usage, and LDAP schema
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"

<html>
Dave,<br>
<br>
My comments are in-line.<br>
<br>
At 02:37 PM 5/3/01 -0400, David P. Kemp wrote:<br>
<blockquote type=cite cite>Tim,<br>
<br>
Does this mean that if a user wanted to send an S/MIME request<br>
for information to a CA, the user agent should look for the CA's<br>
email certificate in the cACertificate or crossCertficatePair<br>
attribute?&nbsp; Similarly for a CMC certificate signing request<br>
encrypted for the CA?&nbsp; And for the TLS server certificate for<br>
the CA's web site?&nbsp; And for the signature certificate used to<br>
validate the CA's published CPS?</blockquote><br>
Yes, that is what it would mean.&nbsp; (Actually, I don't think the TLS
server certificate would necessarily have the same name; in that case, it
wouldn't be a CA certificate.&nbsp; I would consider that an RA.&nbsp;
I'm splitting hairs, though.)<br>
<br>
When a client needs a CA's public key, it would be advantageous if the
client could guess which attribute the certificate might be found
in.&nbsp; However, a client has no way to guess the full range of uses
for the key used to sign a CRL, or used to sign the published CPS.&nbsp;
If the same private key is used to sign certs, the certificate will
appear in either the caCertificate attribute, crossCertificatePair
attribute, or both.&nbsp; [Note we are already checking two
locations!]&nbsp; On the other hand, if this private key is not used to
sign certificates the corresponding certificate would have to be stored
in the userCertificate attribute.&nbsp; [That is three locations]<br>
<br>
The client doesn't want a user's public key.&nbsp; It wants a public key
associated with a CA for some purpose other than validating a
certificate.&nbsp; Why shouldn't it look for a cA certificate?<br>
<br>
<blockquote type=cite cite>I believe that the original intent of the cA
flag in basicConstraints<br>
was that it be an indicator that the certificate can be used in<br>
path validation, not that it should be set in in every certificate<br>
belonging to a CA.&nbsp; With this interpretation, the cA flag is
synonymous<br>
with, and MUST always have the same value as, the keyCertSign bit
whenever<br>
both basic constraints and key usage are present in a
certificate.</blockquote><br>
That may in fact have been the intent.&nbsp; X.509 states
<dl>
<dd>The <font size=2>cA</font> component indicates if the certified
public key may be used to verify certificate signatures. 
</dl>I wasn't around in those meetings, so I am not sure if this was the
*original* intent.<br>
<br>
However, I think that PKI clients need to be able to confirm that the CPS
was signed by a CA, not just some random certificate subject.&nbsp; They
need to be able to determine that the entity generating their key
management key pair is in fact the CA, not some random certificate
subject.<br>
<br>
I don't know how we convey this information if we don't use the basic
constraints extension.&nbsp; Since we have key usage to refine the
meaning of basic constraints we should be able to say &quot;the subject
is a CA and the public key may be used to [one or more of the following:
validate signatures on certificates; validate signatures on CRLs; key
encipherment; etc. etc.]&quot;<br>
<br>
<blockquote type=cite cite>Mandating cA=keyCertSign is a much cleaner
solution than expecting<br>
clients to reject a path containing a CA's web server certificate<br>
which has cA=true and key usage not present.&nbsp; Are you proposing
that<br>
PKIX-conforming CAs MUST populate a critical key usage extension in
all<br>
certificates used to sign certificates AND all end-entity
certificates<br>
belonging to a CA?&nbsp; And that all PKIX-conforming applications MUST
reject<br>
a path unless a critical key usage extension is present with
keyCertSign<br>
asserted in every certificate but the last?</blockquote><br>
That's pretty much what I'm proposing, although the criticality is a
requirement imposed on generation, not processing.&nbsp; PKIX conforming
implementations require that basic constraints assert cA=TRUE *OR** the
client must have out-of-band information that the subject is a CA for
each intermediate certificate (6.1.4.step (k)).&nbsp; If key usage
appears, it must assert keyCertSign.&nbsp; The path validation algorithm
does not check the criticality of these extensions.<br>
<br>
<blockquote type=cite cite>I'd heartily agree with that generation
requirement, but I don't think<br>
the application requirement is practical. And without the
application<br>
requirement, it would be dangerous to assert the cA flag in CA<br>
certificates not intended for use in validating signatures on<br>
certificates.</blockquote><br>
You are correct, it would be dangerous to assert cA=TRUE without
specifying a critical key usage extension.&nbsp; I guess the question is,
what would a client do if it encountered an intermediate certificate
where basic constraints indicated it was a CA certificate and the key
usage extension appeared but keyCertSign was not asserted?&nbsp; <br>
<br>
On the other hand, the subject is trusted to issue certificates or CRLs
anyway.&nbsp; If the subject wants to perform mischief, it can do so with
the appropriate key pair.  Right?<br>
<br>
<blockquote type=cite cite>Regards,<br>
Dave<br>
<br>
<br>
<br>
<br>
Tim Polk wrote:<br>
&gt; <br>
&gt; Folks,<br>
&gt; <br>
&gt; I have been reading the email messages on the list about the
relationships<br>
&gt; between basic constraints, key usage, and the schema.&nbsp; After
mulling over<br>
&gt; the problem.&nbsp; I would like to propose a solution - the only
solution, as<br>
&gt; far as I can tell...<br>
&gt; <br>
&gt; The solution is to simplify and separate the semantics of the
basic<br>
&gt; constraints and key usage extension.&nbsp; This has positive
implications for<br>
&gt; the PKIX LDAP schema as well.<br>
&gt; <br>
&gt; Basic Constraints<br>
&gt; <br>
&gt; As stated in the current text for Basic Constraints (in 2459):&nbsp;
&quot;The basic<br>
&gt; constraints extension identifies whether the subject of the
certificate is<br>
&gt; a CA and how deep a certification path may exist through that
CA.&quot;<br>
&gt; <br>
&gt; I believe this is the right semantics, and that basic constraints
should be<br>
&gt; included and cA should be asserted in *any* certificate issued to a
CA,<br>
&gt; regardless of the type or role associated with the public key in
the<br>
&gt; certificate.<br>
&gt; <br>
&gt; Key Usage<br>
&gt; <br>
&gt; The issuer should use the Key Usage extension to disambiguate the
subject's<br>
&gt; key pairs:<br>
&gt; (a) The issuer indicates this public key may be used to verify
the<br>
&gt; signature on a public key certificate by asserting
keyCertSign.&nbsp; (b) The<br>
&gt; issuer indicates this public key may be used to verify the signature
on<br>
&gt; CRLs by asserting cRLSign.&nbsp; (c) The issuer indicates that this
public key<br>
&gt; may be used to establish symmetric keys with the subject by
asserting<br>
&gt; either keyEncipherment or keyAgreement.&nbsp; (d) The issuer
indicates that this<br>
&gt; public key may be used to verify signatures on objects other than
public<br>
&gt; key certificates and CRLs by asserting nonRerpuidation or
digitalSignature.<br>
&gt; <br>
&gt; Of course, if a key pair is used for multiple purposes, multiple key
usages<br>
&gt; may be asserted.<br>
&gt; <br>
&gt; In each of these cases, the basic constraints extension also appears
in the<br>
&gt; certificate and asserts that the subject is a CA.<br>
&gt; <br>
&gt; LDAP Schema<br>
&gt; <br>
&gt; All certificates issued to CAs would be considered CA certificates
since<br>
&gt; the basic constraints extension is present and asserts that the
subject is<br>
&gt; a CA.&nbsp; As a result, each of these could appear in the
cACertificate<br>
&gt; attribute or crossCertificatePair attribute.&nbsp; They would *not*
appear in<br>
&gt; the userCertificate attribute.&nbsp; (That would include all types
(a) through<br>
&gt; (d) above).<br>
&gt; <br>
&gt; ------------------<br>
&gt; <br>
&gt; The implications of this strategy are as follows: (1) when a client
is<br>
&gt; searching for a CA certificate, they will not have to check 
the<br>
&gt; userCertificate attribute; (2) the issuer can indicate that the
subject is<br>
&gt; a CA regardless of the key usage; and (3) minimal changes to the
text (my<br>
&gt; favorite!).<br>
&gt; <br>
&gt; What do you think?<br>
&gt; <br>
&gt; Thanks,<br>
&gt; <br>
&gt; Tim Polk</blockquote></html>



Received: from mail.funk.com (mail.funk.com [198.186.160.22]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA09568 for <[e-mail]>; Thu, 3 May 2001 14:26:09 -0700 (PDT)
Received: by mail.funk.com with Internet Mail Service (5.5.2653.19) id <J9V08ZJQ>; Thu, 3 May 2001 17:27:52 -0400
Message-ID: <[e-mail]>
From: Aslam <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: How to get Base and Delta CRLs for a particular end entity certif icate...
Date: Thu, 3 May 2001 17:27:43 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"

Hi,
 
 I'm working on CRL stuff, I have a question regarding Delta CRL, in
 following senario:
 I get  a certificate from somewhere, whose validity I have to 
 check against the CRL mechanism. For this I obtain the CRL Distribution
Point extension from 
 the cert and download the CRL from that location, then I check for 
 extension and finds that its a base crl, so every thing work good. Now from
where 
 I should get the Delta CRL, if the answer is that these can be obtained 
 fron the same CRL distribution point then if my first is a delta crl then
how 
 to get the base crl corresponding to a delta crl.
 
 Any help is much more appriciated..
 
 Thanks
 Aslam



Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA04439 for <[e-mail]>; Thu, 3 May 2001 13:27:01 -0700 (PDT)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id QAA20388; Thu, 3 May 2001 16:27:00 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Thu, 03 May 2001 16:26:35 -0400
To: Denis Pinkas <[e-mail]>
From: "David A. Cooper" <[e-mail]>
Subject: Re: delta-CRLs
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"

<html>
At 06:05 PM 5/2/01 +0200, Denis Pinkas wrote:<br>
<blockquote type=cite cite><blockquote type=cite cite>The current is
wrong on two major aspects:<br>
<br>
a) the numbering of the delta CRLs</blockquote></blockquote><br>
Since you claim to want to support &quot;traditional&quot; delta-CRLs, I
will quote the text on delta-CRLs from section 12.6.3.3 of X.509 3rd
edition (1997):<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>a
delta-CRL shall not be issued without a corresponding complete CRL being
issued<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>at the
same time. The value of the CRL number, as conveyed in the CRL number
extension<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>field (if
present), shall be identical for both the delta-CRL and the corresponding
complete CRL<br>
<br>
Similar text was included in one of the old proposed draft amendments to
the 1997 standard:<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>At reset
time, concurrent with publication of a new base CRL is publication of the
final<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>delta-CRL
for the old base CRL. Both CRLs published concurrently (new base and
final<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>delta for
old base) shall contain identical values of the
<font size=2>cRLNumber</font> extension as well as<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>identical
values of <font size=2>thisUpdate</font> time. The values of
<font size=2>nextUpdate</font> time will be different in each.<br>
<br>
Both texts are quite clear that when a complete CRL and a delta-CRL are
issued at the same time, and the two CRLs provide the same information,
they must have the same cRLnumber. This is because the are effectively
two instantiations of the same CRL.<br>
<br>
Notice also that the requirement is that when a new base is issued, the
delta that is issued at the same time provides changes since the previous
base. One does not issue an empty delta. If one did, then every relying
party would be forced to download every base CRL.<br>
<br>
<blockquote type=cite cite><blockquote type=cite cite>b) the lack of use
of the fields thisUpdate and nextUpdate in the
delta-CRLs.</blockquote></blockquote><br>
As I stated before, the thisUpdate field specifies the time at which the
CRL was issued. There is absolutely no reason to check that the current
time is after thisUpdate. We can re-visit this issue, if necessary, once
you have built a machine that allows people to travel back in time while
simultaneously validating an X.509 certificate. Until then, we can assume
that time increases monotonically and that the current time is always
after thisUpdate.<br>
<br>
The nextUpdate field in a delta-CRL has the same meaning an in any other
type of CRL, so there is no reason to discuss it here. As I said before,
though, one can not say that any CRL whose nextUpdate time has not passed
is the most current. There may have been an &quot;emergency&quot; CRL
issued since that one was issued. If nextUpdate has passed, then you know
the CRL is not the most current. If nextUpdate has not passed, then the
CRL MAY be the most current, but there is no way to know for
certain.<br>
<br>
<blockquote type=cite cite><blockquote type=cite cite>&gt; They seem to
depart from the traditional<br>
&gt; deltas in certain details,<br>
<br>
They certainly do not.</blockquote></blockquote><br>
As I stated above, you state that whenever a base CRL is issued, an empty
delta-CRL should be issued at the same time, with the delta-CRL using the
concurrently issued base CRL as its base. This is not how traditional
delta-CRLs work.<br>
<br>
<blockquote type=cite cite><blockquote type=cite cite>&gt; but prevent
use of sliding window deltas.<br>
<br>
Maybe. However, if you really want them to be part of this document,
then<br>
they MUST *not* be mandatory. So the only way would be to add
additional<br>
text that would explain how this can be done as an option. However I got
the<br>
fealing that the traditional method may be in some way incompatible with
the<br>
sliding window deltas, i.e. if the sliding method is chosen by the
CRL<br>
Issuer relying parties may have difficulties to use the traditional
method.<br>
But, maybe, you have the right text just ready to explain how this can
be<br>
done. :-)</blockquote></blockquote><br>
When I referred to the &quot;traditional&quot; method in my paper, I was
referring to the way delta-CRLs are issued, not how they are processed by
relying parties. Notice, however, that the deltaCRLIndicator requires
that &quot;[t]he base CRL referenced by a
<font size=2>deltaCRLIndicator</font> extension shall be a CRL that is
issued as complete for its scope (i.e. it is not itself a dCRL).&quot; If
by &quot;relying parties using the traditional method&quot; you mean
always applying the delta-CRL to a full CRL whose cRLNumber is equal to
the value in BaseCRLNumber, this requirement on the deltaCRLIndicator
extension ensures that this can be done no matter how delta-CRLs are
issued (traditional method, sliding window, or other). I don't think that
anyone ever intended for this to be way that delta-CRLs are processed,
but you can do it if you want.<br>
<br>
Even if delta-CRLs are issued using the &quot;traditional&quot; method,
relying parties may choose to maintain a locally generated revocation
list which they update which each successive delta-CRL that they
download. Remember that RFC 2459 stated:<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>The use of
delta-CRLs can significantly improve processing time for
applications<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>which
store revocation information in a format other than the CRL
structure.&nbsp; This<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>allows
changes to be added to the local database while ignoring unchanged<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>information
that is already in the local database.<br>
<br>
We should not write text that seems to preclude this option.<br>
<br>
The text that is in the document now was painstakingly crafted by the ISO
Directory group and was carefully profiled by PKIX. The text does not
mandate sliding window delta-CRLs, nor does it specify a particular way
that relying parties must use delta-CRLs. It provides options to both CRL
issuers and relying parties, but does not impose requirements on either.
Please do not suggest that we change the text to preclude useful options
when doing so would provide no benefits.<br>
<br>
<blockquote type=cite cite><blockquote type=cite cite>&gt; &gt;[David] A
delta-CRL is nearly the same as a full CRL. It has a thisUpdate,<br>
&gt; &gt;nextUpdate, cRLNumber, etc. just as a full CRL. It just has an
incomplete<br>
&gt; &gt;list of revoked certificates.<br>
&gt; &gt;<br>
&gt; &gt;[Denis] Yes, but you have to explain detail how a relying party
will use<br>
&gt; &gt;thisUpdate, nextUpdate for a base CRL and thisUpdate, nextUpdate
for a delta<br>
&gt; &gt;to make sure that in both cases he got the freshest
information.</blockquote></blockquote><br>
There is no way, using CRLs, to ensure that you have the freshest
information. If nextUpdate has passed, then you know that fresher
information is available. If nextUpdate has not passed, then you do not
know whether you have the freshest information or not. This is true for
full CRLs, delta-CRLs, indirect CRLs, and any other type of CRL. If more
text is needed to explain the use of the nextUpdate field then it should
go in section 5.1.2.5 on the nextUpdate field, since it would apply to
all CRLs, not just delta-CRLs.<br>
<br>
<blockquote type=cite cite><blockquote type=cite cite>&gt;
&gt;[Denis]<br>
&gt; &gt;<br>
&gt; &gt;As said later, your paper provides the right answer (on page 1):
&quot; A<br>
&gt; &gt;delta-CRL is a CRL that only provides information about
certificates who<br>
&gt; &gt;statuses have changed since the issuance of a specific,
previously issued<br>
&gt; &gt;CRL&quot;. The text says &quot; *a* specific, previously issued
CRL&quot;, it does NOT say<br>
&gt; &gt;&quot;or any, more recently, issued
CRL&quot;.</blockquote></blockquote><br>
You are misinterpreting the quote. The sentence states what information
is provided in a delta-CRL. It does not say anything about how the
delta-CRL can be used. A delta-CRL provides information about
certificates whose statuses have changed since the issuance of a
specific, previously issued CRL. The delta-CRL may, however, be applied
to more recently issued CRLs. <br>
<br>
<br>
<blockquote type=cite cite><blockquote type=cite cite>&gt; &gt; &gt;
&gt;This paper is proposing a method for over-issuing the CRLs. It omits
to take<br>
&gt; &gt; &gt; &gt;into consideration that in PKIX-1 we mandate the CRL
number extension<br>
&gt; &gt; &gt; &gt;(section 5.2.3) so we need to advertise the
nextUpdate. If you issue a CRL<br>
&gt; &gt; &gt; &gt;before the next update you have no more way to know
which base CRL is the<br>
&gt; &gt; &gt; &gt;freshest CRL. I believe this is a major security
weakness and for that<br>
&gt; &gt; &gt; &gt;reason this mechanism should be
deprecated.</blockquote></blockquote><br>
Over-issuing is really out-of-scope for this discussion. However,
over-issuing is merely one way to distribute revocation information more
efficiently. If you issue CRLs once every 4 hours and I issue CRLs once
an hour, but with a nextUpdate time 4 hours in the future, the
information relying parties get from me will be no more stale than the
information they get from you. If there is any &quot;security
weakness&quot; it is from the delay in distributing revocation
information, not from over-issuing.<br>
<br>
<blockquote type=cite cite><blockquote type=cite cite>&gt;
&gt;[David]&nbsp; Finally, since a CRL issuer may issue
&quot;emergency&quot; delta-CRLs, there<br>
&gt; &gt;is no guarantee that any delta-CRL whose nextUpdate time is
later than the<br>
&gt; &gt;current time is the most current delta-CRL.<br>
&gt; &gt;<br>
&gt; &gt;[Denis] If you issue such &quot;emergency&quot; delta-CRLs then
once again there is no<br>
&gt; &gt;guarantee that they will ever be seen. The &quot;most recent
delta-CRL&quot; is any<br>
&gt; &gt;delta CRL which satisfies the following condition :<br>
&gt; &gt;<br>
&gt; &gt;&quot; A delta-CRL which contains a Delta CRL Indicator equal to
the cRLNumber of<br>
&gt; &gt;the base CRL and where the validation date (which may be the
current time)<br>
&gt; &gt;is between thisUpdate and nextUpdate from that
delta-CRL;&quot;</blockquote></blockquote><br>
This seems to be a semantic problem. There can only be one &quot;most
recent CRL&quot;. You seem to want to mandate that people always use the
&quot;most recent CRL&quot;, but there is no way guarantee that you have
the most recent CRL.<br>
<br>
<blockquote type=cite cite><blockquote type=cite cite>&gt; &gt; &gt;
&gt;Any other method would first need to be proven to be secure
(over-issuing<br>
&gt; &gt; &gt; &gt;CRLs and sliding window delta-CRLs have security
problems) <br>
<br>
&gt; &gt;[Denis] There ARE security problems with sliding window
delta-CRLs. I have<br>
&gt; &gt;descibed at length what the problems are. However, this does not
mean that<br>
&gt; &gt;this technique cannot be supported as an OPTIO and IF we
indicate in the<br>
&gt; &gt;text what are their security problems. The current text places
the two<br>
&gt; &gt;techniques at the same level. The traditional way offers a
guarantee while<br>
&gt; &gt;the other does not. There is indedd added complexity for
building the<br>
&gt; &gt;software from the relying party.</blockquote></blockquote><br>
You have not described any security problems with sliding window
delta-CRLs. You suggest that sliding window delta-CRLs should not be used
until they have been proven secure. What type of proof are you looking
for? Where are the proofs that CRLs of any type are secure? Where is the
proof that X.509 certificates are secure? Once you provide me with the
proofs that everything else in X.509 is secure, I'll try to find time to
write a similar proof to show that sliding window delta-CRLs are secure.
Until then, any suggestion that sliding window delta-CRLs need to be
proven to be secure before they can be used is nothing but a red
herring.<br>
<br>
Dave<br>
<br>
<br>
</html>



Received: from mtiwmhc23.worldnet.att.net (mtiwmhc23.worldnet.att.net [204.127.131.48]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA03380 for <[e-mail]>; Thu, 3 May 2001 13:16:16 -0700 (PDT)
From: [e-mail]
Received: from webmail.worldnet.att.net ([204.127.135.41]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <[e-mail]>; Thu, 3 May 2001 20:15:51 +0000
Received: from [161.215.27.211] by webmail.worldnet.att.net; Thu, 03 May 2001 20:15:50 +0000
To: "Carlin Covey" <[e-mail]>
Cc: "Housley, Russ" <[e-mail]>, "Denis Pinkas" <[e-mail]>, <[e-mail]>
Subject: RE: Certificate Hold  (was RE: delta CRLs)
Date: Thu, 03 May 2001 20:15:50 +0000
X-Mailer: AT&T Message Center Version 1 (May  2 2001)
Message-Id: <[e-mail]>

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:[e-mail]]
> Sent: Thursday, May 03, 2001 10:17 AM
> To: Denis Pinkas
> Cc: [e-mail]
> 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
> 


Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA00923 for <[e-mail]>; Thu, 3 May 2001 12:32:03 -0700 (PDT)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id PAA06664; Thu, 3 May 2001 15:32:03 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 03 May 2001 15:29:56 -0400
To: Denis Pinkas <[e-mail]>, "David A. Cooper" <[e-mail]>, pkix <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: Re: delta-CRLs
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"

<html>
Denis,<br>
<br>
You seem to be advocating one *extremely* limited scenario for the use of
delta CRLs.&nbsp; Under your text, deltas may only be used with a
specifically issued base CRLs.&nbsp; That is, the application of delta
CRLs to constructed CRLs seems to be forbidden.&nbsp; We believe this
scenario is inefficient and reduces or cancels completely the benefits of
delta CRLs.<br>
<br>
Simple processing of the CRL number extension can support more efficient
delta CRL processing.&nbsp; These techniques permit an application to
store revocation information in more efficient formats (e.g., a local
database) and apply updates to that information.&nbsp; I do not
understand the problems you have with using the CRL number extension in
deltas; the concepts in son-of-2459 are aligned with the requirements
stated in X.509.&nbsp; You have also deleted important points in the
processing of certificate hold, as those points do not apply in your very
limited scenario.<br>
<br>
The current text was very carefully crafted to be correct, complete, and
aligned with the X.509 standard.&nbsp; I believe that the current text is
correct, and should be maintained.<br>
<br>
I will compare the two sets of text, and describe the rationale for the
original text.<br>
<br>
First paragraphs are nearly identical.&nbsp; You have replaced the second
sentence and deleted the last sentence.&nbsp; You replaced:<br>

<dl>
<dd>Delta CRLs contain updates to revocation information previously
distributed, rather than all the information that would appear in a
complete CRL.<br>
<br>

</dl>with:<br>

<dl>
<dd>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.<br>
<br>

</dl>That change is fine.&nbsp; However, you delete the final
sentence:<br>

<dl>
<dd>Applications which store revocation information in a format other
than the CRL structure can add new revocation information to the local
database without reprocessing information.<br>
<br>

</dl>I believe that is appropriate for your text, since the algorithm
seems to *require* reprocessing a base whenever a delta is
processed.&nbsp; Unfortunately, adding new revocation information without
reprocessing information is an important benefit of delta CRLs.&nbsp; I
suspect that is why we disagree so vehemently.<br>
<br>
In the second paragraph, you again deleted the last sentence:<br>

<dl>
<dd>The combination of a CRL containing the delta CRL indicator extension
plus the CRL referenced in the BaseCRLNumber component of this extension
is equivalent to a full CRL, for the applicable scope, at the time of
publication of the&nbsp; delta CRL.<br>
<br>

</dl>Why was this text deleted?&nbsp; By deleting this text, you impose
unnecessary limitations on the use of deltas.&nbsp; This seems to force
the delta CRL user to obtain new base CRLs rather than use constructed
CRLs.<br>
<br>
The third paragraph needed to be revised anyway, since it incorporates
the old constraints that full CRLs and deltas be issued together.&nbsp;
However, you deleted all the information regarding the use of the CRL
number extension in delta CRLs.&nbsp; This is important 
information:<br>
<br>
Current text:<br>
<br>
&nbsp;&nbsp; When a conforming CA issues a delta CRL, the CA MUST also
issue a CRL<br>
&nbsp;&nbsp; that is complete for the given scope.&nbsp; Both the delta
CRL and the<br>
&nbsp;&nbsp; complete CRL MUST include the CRL number extension (see sec.
5.2.3).<br>
&nbsp;&nbsp; The CRL number extension in the delta CRL and the complete
CRL MUST<br>
&nbsp;&nbsp; contain the same value.&nbsp; When a delta CRL is issued, it
MUST cover<br>
&nbsp;&nbsp; the same set of reasons and same set of certificates that
were<br>
&nbsp;&nbsp; covered by the base CRL it references.<br>
<br>
You deleted all but the last sentence.&nbsp; The CRL number extension is
required in delta CRLs so that future delta CRLs can be applied to the
new constructed base CRL.&nbsp; <br>
<br>
You have inserted a new paragraph four:<br>

<dl>
<dd>When a conforming CA issues a delta CRL, the delta CRL MUST include 
<dd>a critical delta CRL indicator extension.<br>
<br>

</dl>I am surprised we missed this one.&nbsp; We should keep this
text.<br>
<br>
Current text for paragraphs four and five are:<br>
<br>
&nbsp;&nbsp; An application can construct a CRL that is complete for a
given<br>
&nbsp;&nbsp; scope, at the current time, in either of the following
ways:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (a) by retrieving the current delta CRL
for that scope, and<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; combining it with an issued CRL that is
complete for that scope<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and that has a cRLNumber greater than or
equal to the cRLNumber of<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the base CRL referenced in the delta CRL;
or<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (b) by retrieving the current delta CRL
for that scope and<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; combining it with a locally constructed
CRL whose cRLNumber is<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; greater than or equal to the cRLNumber of
the base CRL referenced<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in the current delta CRL.<br>
<br>
&nbsp;&nbsp; The constructed CRL has the CRL number specified in the CRL
number<br>
&nbsp;&nbsp; extension found in the delta CRL used in its
construction.<br>
<br>
You've replaced this with:<br>

<dl>
<dd>An application can construct a CRL that is the most current for 
<dd>a given scope, for a specific date, by retrieving the appropriate 
<dd>base CRL for that scope, and combining it with a delta-CRL which 
<dd>contains a Delta CRL Indicator equal to the cRLNumber of the base 
<dd>CRL and where the date for which the construction is being made is 
<dd>between thisUpdate and nextUpdate as indicated the delta CRL.<br>
<br>

</dl>First, the CRL that is constructed (in either text) may be complete
for a given scope and time, but there is no way to demonstrate that the
constructed CRL is &quot;the most current&quot;.&nbsp;&nbsp; We can never
be sure that we haven't missed an emergency CRL (or delta CRL.)&nbsp; We
can only be sure that we haven't reached the next scheduled CRL
publication date.<br>
<br>
In addition, you have deleted the semantics of the CRL number extension
in delta CRLs.&nbsp; Instead, you substitute text on nextUpdate and
thisUpdate, which are independent extensions and have been covered
elsewhere.<br>
<br>
You have inserted a new paragraph:<br>
<br>
Conforming implementations of this specification are not required <br>
to implement the above algorithm, but MUST provide functionality <br>
equivalent to the external behavior resulting from this procedure.<br>
<br>
First, I don't really see an algorithm.&nbsp; Second, as Russ has pointed
out, we don't require processing of deltas at all.<br>
<br>
The current text closes with:<br>
<br>
&nbsp;&nbsp; CAs must ensure that application of a delta CRL to the
referenced<br>
&nbsp;&nbsp; base revocation information accurately reflects the current
status of<br>
&nbsp;&nbsp; revocation.&nbsp; If a CA supports the certificateHold
revocation reason<br>
&nbsp;&nbsp; the following rules must be applied when generating delta
CRLs:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (a) If a certificate was listed as revoked
with revocation reason<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; certificateHold on a CRL (either a delta
CRL or a CRL that is<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; complete for a given scope), whose
cRLNumber is n, and the hold is<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; subsequently released, the certificate
must be included in all<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; delta CRLs issued after the hold is
released where the cRLNumber<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of the referenced base CRL is less than or
equal to n. The<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; certificate must be listed with revocation
reason removeFromCRL<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; unless the certificate is subsequently
revoked again for one of<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the revocation reasons covered by the
delta CRL, in which case the<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; certificate must be listed with the
revocation reason appropriate<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for the subsequent revocation.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (b) If the certificate was not removed
from hold, but was<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; permanently revoked, then it must be
listed on all subsequent<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; delta CRLs where the cRLNumber of the
referenced base CRL is less<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; than the cRLNumber of the CRL (either a
delta CRL or a CRL that is<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; complete for the given scope) on which the
permanent revocation<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; notice first appeared.<br>
<br>
You replace this with:<br>
<br>
CAs must ensure that application of a delta CRL to the referenced <br>
base revocation information accurately reflects the current status of
<br>
revocation. If a CA supports the certificateHold revocation reason <br>
the following rules must be applied when generating delta CRLs:<br>

<dl>
<dd>(a) If a certificate was listed as revoked with revocation reason 
<dd>certificateHold on a CRL (either a delta CRL or a CRL that is 
<dd>complete for a given scope), and the hold is subsequently 
<dd>released, the certificate must be listed with revocation reason 
<dd>removeFromCRL until the next base CRL is issued.<br>
<br>

<dd>Note: Should the certificate be subsequently revoked again for 
<dd>one of the revocation reasons covered by the delta CRL, 
<dd>then the certificate must be listed with the revocation 
<dd>reason appropriate for the subsequent revocation.<br>
<br>

<dd>(b) If the certificate was not removed from hold, but was 
<dd>permanently revoked, then it must be listed as such on all 
<dd>subsequent delta CRLs until the next base CRL is issued .<br>
<br>

</dl>This text presents the biggest problems of all.&nbsp; The text
describes *what* needs to be listed on *which* delta CRLs.&nbsp; By
limiting this text to one very narrow scenario, you increase the
likeliehood that delta CRL issuers that wish to do something efficient
will get it wrong.&nbsp; That will result in bad information fro the
relying party.<br>
<br>
The current text was very carefully crafted to ensure that it was
consistent with X.509 and supported the general case.&nbsp; I do not see
the need to hamstring delta CRL implementers by limiting support to one
narrowly defined scenario.<br>
<br>
Tim Polk<br>
</html>



Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA28932 for <[e-mail]>; Thu, 3 May 2001 11:40:35 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id OAA09703 for <[e-mail]>; Thu, 3 May 2001 14:40:07 -0400 (EDT)
Message-Id: <[e-mail]>
Sender: [e-mail]
Date: Thu, 03 May 2001 14:37:54 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Basic constraints, key usage, and LDAP schema
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tim,

Does this mean that if a user wanted to send an S/MIME request
for information to a CA, the user agent should look for the CA's
email certificate in the cACertificate or crossCertficatePair
attribute?  Similarly for a CMC certificate signing request
encrypted for the CA?  And for the TLS server certificate for
the CA's web site?  And for the signature certificate used to
validate the CA's published CPS?

I believe that the original intent of the cA flag in basicConstraints
was that it be an indicator that the certificate can be used in
path validation, not that it should be set in in every certificate
belonging to a CA.  With this interpretation, the cA flag is synonymous
with, and MUST always have the same value as, the keyCertSign bit whenever
both basic constraints and key usage are present in a certificate.

Mandating cA=keyCertSign is a much cleaner solution than expecting
clients to reject a path containing a CA's web server certificate
which has cA=true and key usage not present.  Are you proposing that
PKIX-conforming CAs MUST populate a critical key usage extension in all
certificates used to sign certificates AND all end-entity certificates
belonging to a CA?  And that all PKIX-conforming applications MUST reject
a path unless a critical key usage extension is present with keyCertSign
asserted in every certificate but the last?

I'd heartily agree with that generation requirement, but I don't think
the application requirement is practical. And without the application
requirement, it would be dangerous to assert the cA flag in CA
certificates not intended for use in validating signatures on
certificates.

Regards,
Dave




Tim Polk wrote:
> 
> Folks,
> 
> I have been reading the email messages on the list about the relationships
> between basic constraints, key usage, and the schema.  After mulling over
> the problem.  I would like to propose a solution - the only solution, as
> far as I can tell...
> 
> The solution is to simplify and separate the semantics of the basic
> constraints and key usage extension.  This has positive implications for
> the PKIX LDAP schema as well.
> 
> Basic Constraints
> 
> As stated in the current text for Basic Constraints (in 2459):  "The basic
> constraints extension identifies whether the subject of the certificate is
> a CA and how deep a certification path may exist through that CA."
> 
> I believe this is the right semantics, and that basic constraints should be
> included and cA should be asserted in *any* certificate issued to a CA,
> regardless of the type or role associated with the public key in the
> certificate.
> 
> Key Usage
> 
> The issuer should use the Key Usage extension to disambiguate the subject's
> key pairs:
> (a) The issuer indicates this public key may be used to verify the
> signature on a public key certificate by asserting keyCertSign.  (b) The
> issuer indicates this public key may be used to verify the signature on
> CRLs by asserting cRLSign.  (c) The issuer indicates that this public key
> may be used to establish symmetric keys with the subject by asserting
> either keyEncipherment or keyAgreement.  (d) The issuer indicates that this
> public key may be used to verify signatures on objects other than public
> key certificates and CRLs by asserting nonRerpuidation or digitalSignature.
> 
> Of course, if a key pair is used for multiple purposes, multiple key usages
> may be asserted.
> 
> In each of these cases, the basic constraints extension also appears in the
> certificate and asserts that the subject is a CA.
> 
> LDAP Schema
> 
> All certificates issued to CAs would be considered CA certificates since
> the basic constraints extension is present and asserts that the subject is
> a CA.  As a result, each of these could appear in the cACertificate
> attribute or crossCertificatePair attribute.  They would *not* appear in
> the userCertificate attribute.  (That would include all types (a) through
> (d) above).
> 
> ------------------
> 
> The implications of this strategy are as follows: (1) when a client is
> searching for a CA certificate, they will not have to check the
> userCertificate attribute; (2) the issuer can indicate that the subject is
> a CA regardless of the key usage; and (3) minimal changes to the text (my
> favorite!).
> 
> What do you think?
> 
> Thanks,
> 
> Tim Polk


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id LAA28919 for <[e-mail]>; Thu, 3 May 2001 11:40:33 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 3 May 2001 18:40:23 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA00659 for <[e-mail]>; Thu, 3 May 2001 14:40:35 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <JY8N4G2B>; Thu, 3 May 2001 14:40:34 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (housley-lap.securitydynamics.com [10.100.142.235]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JY8N4GH9; Thu, 3 May 2001 14:40:30 -0400
From: "Housley, Russ" <[e-mail]>
To: Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 03 May 2001 14:40:25 -0400
Subject: RE: delta CRLs
In-Reply-To: <[e-mail]. com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Santosh:

>Russ: Please note minor word smithing for grammar and for technical 
>accuracy.  The sentences should read as follows.
>
>"A delta CRL provides an update to a previously issued complete CRL.  A 
>delta CRL only includes entries for certificates that have changed status 
>since the complete CRL referenced in the delta CRL extension was issued."

No problem.

>Also a minor technical change to your other sentence:
>
>"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 or lower number 
>as the base CRL."

The most recent X.509 says:

    the combination of a CRL containing the delta CRL indicator extension
    plus the CRL referenced in the BaseCRLNumber component of this
    extension is equivalent to a full CRL, for the applicable scope, at the
    time of publication of the dCRL.

So, the appropriate thing to do seems to be dropping the phrase:

    An application can construct an updated CRL by combining a base CRL and
    a delta CRL which contains a delta CRL indicator extension with the same
    CRL number as the base CRL.

>Please note that the delta CRL can always be applied to a higher base than 
>the one referenced in the delta CRL extension.

This will result in collisions.  The later CRL and delta CRL may both 
contain the same additions.  However, with on-hold, a certificate that was 
removeFromCRL could be put back on hold.

>I also agree with Russ that PKIX need not include the "hold" feature.

Cool.

Russ


Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA25623 for <[e-mail]>; Thu, 3 May 2001 10:44:56 -0700 (PDT)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id J0AR5145; Thu, 3 May 2001 10:39:05 -0700
From: "Carlin Covey" <[e-mail]>
To: "Housley, Russ" <[e-mail]>, "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Certificate Hold  (was RE: delta CRLs)
Date: Thu, 3 May 2001 10:44:10 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>

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:[e-mail]]
Sent: Thursday, May 03, 2001 10:17 AM
To: Denis Pinkas
Cc: [e-mail]
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



Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id KAA23390 for <[e-mail]>; Thu, 3 May 2001 10:17:25 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 3 May 2001 17:17:15 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id NAA23482 for <[e-mail]>; Thu, 3 May 2001 13:17:27 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <JY8N41XP>; Thu, 3 May 2001 13:17:26 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (housley-lap.securitydynamics.com [10.100.142.235]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JY8N41X2; Thu, 3 May 2001 13:17:19 -0400
From: "Housley, Russ" <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 03 May 2001 13:17:08 -0400
Subject: Re: delta CRLs
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

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


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA21754 for <[e-mail]>; Thu, 3 May 2001 09:59:23 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <KGKQ8G82>; Thu, 3 May 2001 12:58:51 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Denis Pinkas <[e-mail]>, Santosh Chokhani <[e-mail]>
Cc: "Housley, Russ" <[e-mail]>, [e-mail]
Subject: RE: delta CRLs
Date: Thu, 3 May 2001 12:49:48 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D3F1.104FD3E0"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D3F1.104FD3E0
Content-Type: text/plain;
	charset="iso-8859-1"

Please see comments in-line.

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Thursday, May 03, 2001 10:49 AM
To: Santosh Chokhani
Cc: Housley, Russ; [e-mail]
Subject: Re: delta CRLs


Santosh,

Mails are crossing around, and are not necessarilly received in the same
order. :-)

You indicated "Also a minor technical change to your other sentence" in your
response to Russ:

 "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 or lower number
 as the base CRL."

What is a "delta CRL which contains a delta CRL indicator extension with
(...) lower number as the base CRL." If you pick this delta CRL then it is
missing some of the information. Unless you speak of the time T and compare
it with thisUpdate and nextUpdate this does not work.

[Santosh says: Denis, the language is a bit awkward.  Let us take an
example, a delta is issued reference base 20, i.e., delta CRL indicator =
20.  Now, let us say base 21 and 22 are also issued prior to delta.  You may
be able to use any one of the three bases: 20, 21, and 22 in conjunction
with the delta to create a "current" revocation picture at the relying
party.]

You also said: " Please note that the delta CRL can always be applied to a
higher base than the one referenced in the delta CRL extension."

You now say "higher" in that sentence. This is even more confusing.

[Santosh Says: That is because in one case I am saying that you can use any
base with a delta referencing lower base.  In the other case I am saying
that a delta or referenced or higher base together can be used.  I WANTED TO
MAKE LEAST AMOUNT TO CHANGES TO RUSS'S ORIGINAL SENTENCE.]

Please take note that the intent is to describe what is necessary to support
the "traditional scheme" and I got the feeling that you would like this
sentence to support a different scheme. On April 19, David Cooper provided
some explanations making some confusing between the numering of delta-CRLs
and the numbering of base CRLs. Thay have no relationships besides that the
numbers should always increase.

If I just re-use the text from David, then you get the effect he wanted
without the need to take advantage of any new sequential numbering. Here is
the corrected text:

" Suppose that delta-CRLs are issued once an hour. For example, suppose that
a base CRL, CRL number 5, was issued at midnight and that every hour for the
next 24 hours, delta-CRLs were issued with a BaseCRLNumber of 5. If a
relying party performs its first validation at 3:10am, it would the base CRL
issued at midnight and the delta-CRL issued at 3:00am (e.g. CRL number 28).
It would combine these to construct the freshest CRL.

A few hours later, at 6:30am, the relying party performs another validation.
The relying party has, in its local cache, the CRL which it constructed at
3:10am. It wants to update the information in its local case to based on the
newly available revocation information. So, it obtains the latest delta-CRL.
This delta-CRL has a CRL number of 42 and a BaseCRLnumber of 5. Since
it has a BaseCRLNumber of 5, the delta-CRL provides status information for
all certificates whose status has changed since CRL number 5 was issued
(midnight). So, clearly the delta-CRL provides status information for all
certificates whose status has changed since 3:00am when CRL number 28 was
issued. Thus, the relying party can combine the delta-CRL with its locally
cached version of the CRL which it constructed at 3:10am to obtain the
freshest CRL."

So the addition you were proposing is not adequate. If we were going to
support variations beyond the traditional scheme, this should be in a
separate sentence.

Regards,

Denis

------_=_NextPart_001_01C0D3F1.104FD3E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: delta CRLs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Please see comments in-line.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Denis Pinkas [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, May 03, 2001 10:49 AM</FONT>
<BR><FONT SIZE=3D2>To: Santosh Chokhani</FONT>
<BR><FONT SIZE=3D2>Cc: Housley, Russ; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: delta CRLs</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Santosh,</FONT>
</P>

<P><FONT SIZE=3D2>Mails are crossing around, and are not necessarilly =
received in the same</FONT>
<BR><FONT SIZE=3D2>order. :-)</FONT>
</P>

<P><FONT SIZE=3D2>You indicated &quot;Also a minor technical change to =
your other sentence&quot; in your</FONT>
<BR><FONT SIZE=3D2>response to Russ:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&quot;An application can construct an updated =
CRL by retrieving the appropriate</FONT>
<BR><FONT SIZE=3D2>&nbsp;base CRL for that scope, and combining it with =
a delta CRL which contains</FONT>
<BR><FONT SIZE=3D2>&nbsp;a delta CRL indicator extension with the same =
CRL number or lower number</FONT>
<BR><FONT SIZE=3D2>&nbsp;as the base CRL.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>What is a &quot;delta CRL which contains a delta CRL =
indicator extension with</FONT>
<BR><FONT SIZE=3D2>(...) lower number as the base CRL.&quot; If you =
pick this delta CRL then it is</FONT>
<BR><FONT SIZE=3D2>missing some of the information. Unless you speak of =
the time T and compare</FONT>
<BR><FONT SIZE=3D2>it with thisUpdate and nextUpdate this does not =
work.</FONT>
</P>

<P><FONT SIZE=3D2>[Santosh says: Denis, the language is a bit =
awkward.&nbsp; Let us take an example, a delta is issued reference base =
20, i.e., delta CRL indicator =3D 20.&nbsp; Now, let us say base 21 and =
22 are also issued prior to delta.&nbsp; You may be able to use any one =
of the three bases: 20, 21, and 22 in conjunction with the delta to =
create a &quot;current&quot; revocation picture at the relying =
party.]</FONT></P>

<P><FONT SIZE=3D2>You also said: &quot; Please note that the delta CRL =
can always be applied to a</FONT>
<BR><FONT SIZE=3D2>higher base than the one referenced in the delta CRL =
extension.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>You now say &quot;higher&quot; in that sentence. This =
is even more confusing.</FONT>
</P>

<P><FONT SIZE=3D2>[Santosh Says: That is because in one case I am =
saying that you can use any base with a delta referencing lower =
base.&nbsp; In the other case I am saying that a delta or referenced or =
higher base together can be used.&nbsp; I WANTED TO MAKE LEAST AMOUNT =
TO CHANGES TO RUSS'S ORIGINAL SENTENCE.]</FONT></P>

<P><FONT SIZE=3D2>Please take note that the intent is to describe what =
is necessary to support</FONT>
<BR><FONT SIZE=3D2>the &quot;traditional scheme&quot; and I got the =
feeling that you would like this</FONT>
<BR><FONT SIZE=3D2>sentence to support a different scheme. On April 19, =
David Cooper provided</FONT>
<BR><FONT SIZE=3D2>some explanations making some confusing between the =
numering of delta-CRLs</FONT>
<BR><FONT SIZE=3D2>and the numbering of base CRLs. Thay have no =
relationships besides that the</FONT>
<BR><FONT SIZE=3D2>numbers should always increase.</FONT>
</P>

<P><FONT SIZE=3D2>If I just re-use the text from David, then you get =
the effect he wanted</FONT>
<BR><FONT SIZE=3D2>without the need to take advantage of any new =
sequential numbering. Here is</FONT>
<BR><FONT SIZE=3D2>the corrected text:</FONT>
</P>

<P><FONT SIZE=3D2>&quot; Suppose that delta-CRLs are issued once an =
hour. For example, suppose that</FONT>
<BR><FONT SIZE=3D2>a base CRL, CRL number 5, was issued at midnight and =
that every hour for the</FONT>
<BR><FONT SIZE=3D2>next 24 hours, delta-CRLs were issued with a =
BaseCRLNumber of 5. If a</FONT>
<BR><FONT SIZE=3D2>relying party performs its first validation at =
3:10am, it would the base CRL</FONT>
<BR><FONT SIZE=3D2>issued at midnight and the delta-CRL issued at =
3:00am (e.g. CRL number 28).</FONT>
<BR><FONT SIZE=3D2>It would combine these to construct the freshest =
CRL.</FONT>
</P>

<P><FONT SIZE=3D2>A few hours later, at 6:30am, the relying party =
performs another validation.</FONT>
<BR><FONT SIZE=3D2>The relying party has, in its local cache, the CRL =
which it constructed at</FONT>
<BR><FONT SIZE=3D2>3:10am. It wants to update the information in its =
local case to based on the</FONT>
<BR><FONT SIZE=3D2>newly available revocation information. So, it =
obtains the latest delta-CRL.</FONT>
<BR><FONT SIZE=3D2>This delta-CRL has a CRL number of 42 and a =
BaseCRLnumber of 5. Since</FONT>
<BR><FONT SIZE=3D2>it has a BaseCRLNumber of 5, the delta-CRL provides =
status information for</FONT>
<BR><FONT SIZE=3D2>all certificates whose status has changed since CRL =
number 5 was issued</FONT>
<BR><FONT SIZE=3D2>(midnight). So, clearly the delta-CRL provides =
status information for all</FONT>
<BR><FONT SIZE=3D2>certificates whose status has changed since 3:00am =
when CRL number 28 was</FONT>
<BR><FONT SIZE=3D2>issued. Thus, the relying party can combine the =
delta-CRL with its locally</FONT>
<BR><FONT SIZE=3D2>cached version of the CRL which it constructed at =
3:10am to obtain the</FONT>
<BR><FONT SIZE=3D2>freshest CRL.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>So the addition you were proposing is not adequate. =
If we were going to</FONT>
<BR><FONT SIZE=3D2>support variations beyond the traditional scheme, =
this should be in a</FONT>
<BR><FONT SIZE=3D2>separate sentence.</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Denis</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0D3F1.104FD3E0--


Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA21717 for <[e-mail]>; Thu, 3 May 2001 09:59:14 -0700 (PDT)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <J432Y23T>; Thu, 3 May 2001 12:58:44 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: Santosh Chokhani <[e-mail]>, "'Tom Gindin'" <[e-mail]>
Cc: "'Tim Polk'" <[e-mail]>, "'Denis Pinkas'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Basic constraints, key usage, and LDAP schema
Date: Thu, 3 May 2001 12:52:30 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D3F1.710ED370"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D3F1.710ED370
Content-Type: text/plain;
	charset="iso-8859-1"

Thanks, I understand now.

-----Original Message-----
From: Santosh Chokhani 
Sent: Thursday, May 03, 2001 12:32 PM
To: Sharon Boeyen; 'Tom Gindin'
Cc: 'Tim Polk'; Denis Pinkas; [e-mail]
Subject: RE: Basic constraints, key usage, and LDAP schema


Sharon:
 
One reason a CA may issue itself a CRL signing certificate is the scenario
as follows:
 
1.  The CA is a trust anchor for some relying parties, and
 
2.  The CA wants to use different key for CRL signing for operational
security, and
 
3.  The CA wants to only provide one trust anchor (i.e., the certificate
signature verification public key).
 
In that scenario, the CA will issue itself a certificate for the CRL
signature verification public key.
 
-----Original Message-----
From: Sharon Boeyen [mailto:[e-mail]]
Sent: Thursday, May 03, 2001 10:35 AM
To: 'Tom Gindin'; Sharon Boeyen
Cc: 'Tim Polk'; Denis Pinkas; [e-mail]
Subject: RE: Basic constraints, key usage, and LDAP schema



I see your point - I was missing the point that they are self-issued and was

thinking of the case where you are delegating authority to an indirect 
issuer. In the indirect case the cert would need to be in the cross-cert
pairs 
attribute and may also appear in the caCerts attribute. 

On the self issued ones, why are they needed at all? Why would a CA issue 
a cert to itself indicating that it can sign CRLs? Why do we need that? 

Sharon 

> -----Original Message----- 
> From: Tom Gindin [ mailto:[e-mail] <mailto:[e-mail]> ]

> Sent: Wednesday, May 02, 2001 5:43 PM 
> To: Sharon Boeyen 
> Cc: 'Tim Polk'; Denis Pinkas; [e-mail] 
> Subject: RE: Basic constraints, key usage, and LDAP schema 
> 
> 
> 
>      In the current draft of X.509v4, "self-issued" means something 
> different than "self-signed".  "self-issued" appears to be 
> the condition 
> "the certificate's subject name can be matched to its own issuer name, 
> which is that of a CA", while "self-signed" is that with the added 
> condition "the certificate signature is verifiable with the public key 
> contained in the message".  Most of these CRL signing certificates are 
> "self-issued" in this sense, although not "self-signed". 
>      One other reason why such CRL signing certificates would 
> legitimately 
> not go into the CC Pair attribute would be that there is no 
> other directory 
> entry where the CA certificate to verify the signature on 
> this certificate 
> could be found, unlike any other certificates in CC Pair. 
>      Lastly, if a CRL signing certificate were issued by a CA 
> certificate 
> with the same DN, it would certainly belong in the same realm, if that 
> concept has any meaning at all. 
> 
>           Tom Gindin 
> 
> 
> Sharon Boeyen <[e-mail]> on 05/02/2001 04:05:54 PM 
> 
> To:   "'Tim Polk'" <[e-mail]>, Denis Pinkas 
>       <[e-mail]> 
> cc:   [e-mail] 
> Subject:  RE: Basic constraints, key usage, and LDAP schema 
> 
> 
> Hi Tim, 
> 
> 
> I just want to clarify the directory attributes. All certs 
> that are not 
> self issued must go in the cross certificates attribute. All 
> self issued 
> certs must go in the caCertificates attribute. A subset of 
> the certificates 
> in the cross certificate pairs attributes may also be present in the 
> caCertificates attribute (those issued within the same realm, 
> a term left 
> undefined). Lets not go back down that rathole :-) The two 
> attributes are 
> not interchangeable. Given that the certs you are talking 
> about are not 
> self issued then they must go in the cross certificate pairs 
> attribute and 
> may also be placed in the caCertificate attribute if issued 
> within the same 
> realm. 
> 
> 
> Sharon 
> 
> 
> > -----Original Message----- 
> > From: Tim Polk [ mailto:[e-mail] <mailto:[e-mail]> ] 
> > Sent: Wednesday, May 02, 2001 10:43 AM 
> > To: Denis Pinkas 
> > Cc: [e-mail] 
> > Subject: Re: Basic constraints, key usage, and LDAP schema 
> > 
> > 
> > Denis, 
> > 
> > These messages have been flying fast and furious under several topic 
> > lines.  I don't believe I caught them all either!  As they 
> > are all related, 
> > it is difficult to resolve the issues one-by-one.  The 
> > separate solutions 
> > may combine to present new problems.  That was the rationale 
> > for the single 
> > comprehensive posting. 
> > 
> > The real problems, in my opinion, are as follows: 
> > 
> > (1) Consider a PKIX client, searching for a certificate to 
> validate a 
> > particular CRL.  Under 2459, the client cannot guess whether 
> > the basic 
> > constraints extension will be present with the CA bit asserted. 
> > 
> > If the key used to validate the CRL is also used to validate 
> > certificates, 
> > it will have basic constraints and assert cA is TRUE.  In 
> > this case, the 
> > certificate should be in the ca certificate attribute (or 
> > perhaps the cross 
> > certificate pairs). 
> > 
> > If the key is not used to validate certificates, basic 
> > constraints will be 
> > omitted and the certificate will be stored in the user 
> > certificate attribute. 
> > 
> > (2) If a PKIX client wishes to communicate with a CA for certificate 
> > management purposes (e.g., to request a new certificate, request 
> > revocation, or perhaps centralized key generation for key 
> > escrow scenarios) 
> > the client will need to validate the CA's signature and 
> > perhaps make use of 
> > the CA's key management key.  If the keys used for these 
> > transactions are 
> > also used to sign PKCs, the certs will be in the CA certificate 
> > attribute.  If the keys used for these purposes are not used 
> > to sign PKCs, 
> > there will be no indication that this entity is a CA and the 
> > certs will be 
> > stored in the user certificate attribute. 
> > 
> > As above, the PKIX client does not know where to look for these 
> > certificates.  Where they are not used to sign PKCs, there 
> will be no 
> > indication in the certificate that this entity is a CA at all. 
> > 
> > (3) The attribute certificate profile is very clear regarding 
> > AC issuers 
> > versus PKC issuers. Section 4.5 states "the AC issuer's PKC 
> > MUST NOT have a 
> > basicConstraints extension with the cA BOOLEAN set to TRUE." 
> > 
> > However, the combination of RFC 2459 and the attribute 
> > certificate profile 
> > does not permit an issuer to specify whether a subject can 
> issue CRLs 
> > for  PKCs, ACs, or both.  This would provide us with an 
> > analogous solution: 
> > if the CA bit is not asserted, but the cRLSign bit is set in 
> > key usage, the 
> > subject is only permitted to issue CRLs for ACs. 
> > 
> > To be honest, (3) is the least compelling problem.  The CA 
> > must explicitly 
> > name an indirect CRL issuer in PKCs it issues *anyway*, so 
> > the CA bit isn't 
> > a big security issue.  Still, I think it is nice to supply 
> > clients with 
> > this information. 
> > 
> > Anyway, I hope this clarifies things a bit.  My goal was to 
> > resolve all 
> > three problems simultaneously and consistently. 
> > 
> > Thanks, 
> > 
> > Tim Polk 
> > 
> > At 03:14 PM 5/2/01 +0200, Denis Pinkas wrote: 
> > >Tim, 
> > > 
> > >I stayed silent on that topic and it is quite hard to catch 
> > all the e-mails 
> > >related to it. I certainly missed or skipped missed some of them. 
> > > 
> > > > Terry, 
> > > > 
> > > > I think it would be best if the client did not need to check the 
> > > > userCertificate attribute to validate CRLs.  This adds 
> > complexity without 
> > > > any real benefit (in my opinion.)  I have included some 
> > proposed text for 
> > > > the first paragraph of section 4.2.1.10 (basic 
> > constraints) that would 
> > > > clarify the issue. 
> > > > 
> > > > ----------------proposed text for first paragraph of 
> > > 4.2.1.10---------------- 
> > > > 
> > > > The basic constraints extension identifies whether the 
> > subject of the 
> > > > certificate is a CA and the maximum depth of valid 
> > certification paths that 
> > > > include this certificate.  A subject is considered a CA 
> > if it issues public 
> > > > key certificates or CRLs that describe the revocation 
> > status of public key 
> > > > certificates. 
> > > > 
> > > > ----------------------end proposed text 
> > > > What do you think? 
> > > 
> > >RFC 2459 only said: 
> > > 
> > >    The basic constraints extension identifies whether the 
> > subject of the 
> > >    certificate is a CA and how deep a certification path may exist 
> > >    through that CA. 
> > > 
> > >However, according to the new text a "CRL Issuer" is now 
> > also a "CA": " A 
> > >subject is considered a CA if it issues public key 
> > certificates or CRLs that 
> > >describe the revocation status of public key certificates." 
> > > 
> > >The current text of new-part1-06 also goes in the same direction. 
> > > 
> > >    The cA bit indicates if the certified public key may be used to 
> > >    verify signatures on other certificates.  If the cA bit 
> > is asserted, 
> > >    then either the keyCertSign bit or the cRLSign bit in 
> > the key usage 
> > >    extension (see 4.2.1.3) MUST also be asserted. If the cA 
> > bit is not 
> > >    asserted, then both the keyCertSign bit and the cRLSign 
> > in the key 
> > >    usage extension MUST NOT be asserted. 
> > > 
> > >This seems quite strange. A CRL issuer is just one way to 
> > make available 
> > >revocation status information. OCSP is another way. RFC 2560 says: 
> > > 
> > >    OCSP signing delegation SHALL be designated by the 
> > >    inclusion of id-kp-OCSPSigning in an extendedKeyUsage 
> certificate 
> > >    extension included in the OCSP response signer's 
> > certificate.  This 
> > >    certificate MUST be issued directly by the CA that issued the 
> > >    certificate in question. 
> > > 
> > >If a "CRL issuer" is a "CA", why should an OCSP responder 
> > designated by a CA 
> > >not also be a "CA" ? 
> > > 
> > >As far as I remember, originally the cA boolean in the basic 
> > constraints 
> > >extension only allowed to make the difference between leaf 
> > certificates and 
> > >CA certificates. This boolean now seems to be be used with a 
> > different 
> > >meaning (and, maybe, we should change its meaning - not 
> the syntax). 
> > > 
> > >Could someone say again, why that change was requested and 
> > what are the real 
> > >benefits of that change ? 
> > > 
> > >In other words, could someone say again what the problem was ? :-) 
> > > 
> > >Thanks, 
> > > 
> > >Denis 
> > > 
> > > > Thanks, 
> > > > 
> > > > Tim Polk 
> > > > 
> > > > At 01:41 PM 5/1/01 -0700, Terry Hayes wrote: 
> > > > >Tim, 
> > > > > 
> > > > >I agree with your proposed solution.  As you have said, 
> > it separates the 
> > > > >semantics of the two extensions, and simplifies the 
> > rules for the LDAP 
> > > schema. 
> > > > > 
> > > > >There is one remaining point to address, and I believe 
> > it may be the main 
> > > > >point of discussion in the current thread. 
> > > > > 
> > > > >When a CA uses the CRLDP extension to designate another 
> > entity to be the 
> > > > >source for revocation information about some of its 
> > certificates, should 
> > > > >that entity  have a "CA" certificate (with appropriate 
> > basicConstraints 
> > > > >extension)?  I'm *not* suggesting that a 
> > basicConstraints extension is 
> > > > >necessary for the entity to be authorized to sign the 
> > CRL.  Instead, the 
> > > > >problem is that clients that are trying to locate the 
> > certificate will not 
> > > > >know whether they should look in the cACertificate 
> > attribute or the 
> > > > >userCertificate attribute to find the appropriate certificate. 
> > > > > 
> > > > >To solve this, we can suggest that cACertificate be 
> > searched first, 
> > > > >followed by userCertificate, or we can require that 
> > designated entities 
> > > > >must always be a "CA", and the client can safely skip 
> > the userCertificate 
> > > > >attribute.  This is a question of searching the 
> > directory only, and does 
> > > > >not suggest changing your assertion that any set of bits 
> > may be set in the 
> > > > >keyUsage extension of "CA" certificates. 
> > > > > 
> > > > >Terry 
> > > > > 
> > > > >Tim Polk wrote: 
> > > > > 
> > > > >>Folks, 
> > > > >> 
> > > > >>I have been reading the email messages on the list about the 
> > > > >>relationships between basic constraints, key usage, and 
> > the schema. 
> > > > >>After mulling over the problem.  I would like to 
> > propose a solution - the 
> > > > >>only solution, as far as I can tell... 
> > > > >> 
> > > > >>The solution is to simplify and separate the semantics 
> > of the basic 
> > > > >>constraints and key usage extension.  This has positive 
> > implications for 
> > > > >>the PKIX LDAP schema as well. 
> > > > >> 
> > > > >>Basic Constraints 
> > > > >> 
> > > > >>As stated in the current text for Basic Constraints (in 
> > 2459):  "The 
> > > > >>basic constraints extension identifies whether the 
> > subject of the 
> > > > >>certificate is a CA and how deep a certification path 
> > may exist through 
> > > > >>that CA." 
> > > > >> 
> > > > >>I believe this is the right semantics, and that basic 
> > constraints should 
> > > > >>be included and cA should be asserted in *any* 
> > certificate issued to a 
> > > > >>CA, regardless of the type or role associated with the 
> > public key in the 
> > > > >>certificate. 
> > > > >> 
> > > > >>Key Usage 
> > > > >> 
> > > > >>The issuer should use the Key Usage extension to 
> > disambiguate the 
> > > > >>subject's key pairs: 
> > > > >>(a) The issuer indicates this public key may be used to 
> > verify the 
> > > > >>signature on a public key certificate by asserting 
> > keyCertSign.  (b) The 
> > > > >>issuer indicates this public key may be used to verify 
> > the signature on 
> > > > >>CRLs by asserting cRLSign.  (c) The issuer indicates 
> > that this public key 
> > > > >>may be used to establish symmetric keys with the 
> > subject by asserting 
> > > > >>either keyEncipherment or keyAgreement.  (d) The issuer 
> > indicates that 
> > > > >>this public key may be used to verify signatures on 
> > objects other than 
> > > > >>public key certificates and CRLs by asserting 
> nonRerpuidation or 
> > > > >>digitalSignature. 
> > > > >> 
> > > > >>Of course, if a key pair is used for multiple purposes, 
> > multiple key 
> > > > >>usages may be asserted. 
> > > > >> 
> > > > >>In each of these cases, the basic constraints extension 
> > also appears in 
> > > > >>the certificate and asserts that the subject is a CA. 
> > > > >> 
> > > > >>LDAP Schema 
> > > > >> 
> > > > >>All certificates issued to CAs would be considered CA 
> > certificates since 
> > > > >>the basic constraints extension is present and asserts 
> > that the subject 
> > > > >>is a CA.  As a result, each of these could appear in 
> > the cACertificate 
> > > > >>attribute or crossCertificatePair attribute.  They 
> > would *not* appear in 
> > > > >>the userCertificate attribute.  (That would include all 
> > types (a) through 
> > > > >>(d) above). 
> > > > >> 
> > > > >>------------------ 
> > > > >> 
> > > > >>The implications of this strategy are as follows: (1) 
> > when a client is 
> > > > >>searching for a CA certificate, they will not have to 
> check the 
> > > > >>userCertificate attribute; (2) the issuer can indicate 
> > that the subject 
> > > > >>is a CA regardless of the key usage; and (3) minimal 
> > changes to the text 
> > > > >>(my favorite!). 
> > > > >> 
> > > > >>What do you think? 
> > > > >> 
> > > > >>Thanks, 
> > > > >> 
> > > > >>Tim Polk 
> > > > >> 
> > > > >> 
> > > > > 
> > > > > 
> > 
> 
> 
> 


------_=_NextPart_001_01C0D3F1.710ED370
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: Basic constraints, key usage, and LDAP schema</TITLE>

<META content="MSHTML 5.50.4522.1800" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=784215816-03052001><FONT face=Arial color=#0000ff 
size=2>Thanks, I understand now.</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Santosh Chokhani 
  <BR><B>Sent:</B> Thursday, May 03, 2001 12:32 PM<BR><B>To:</B> Sharon Boeyen; 
  'Tom Gindin'<BR><B>Cc:</B> 'Tim Polk'; Denis Pinkas; 
  [e-mail]<BR><B>Subject:</B> RE: Basic constraints, key usage, and 
  LDAP schema<BR><BR></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=485393616-03052001>Sharon:</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=485393616-03052001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=485393616-03052001>One 
  reason a CA may issue itself a CRL signing certificate is the scenario as 
  follows:</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=485393616-03052001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=485393616-03052001>1.&nbsp; The CA is a trust anchor for some relying 
  parties, and</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=485393616-03052001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=485393616-03052001>2.&nbsp; The CA wants to use different key for CRL 
  signing for operational security, and</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=485393616-03052001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=485393616-03052001>3.&nbsp; The CA wants to only provide one trust 
  anchor (i.e., the certificate signature verification public 
  key).</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=485393616-03052001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=485393616-03052001>In 
  that scenario, the CA will issue itself a certificate for the CRL signature 
  verification public key.</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=485393616-03052001></SPAN></FONT>&nbsp;</DIV>
  <DIV class=OutlookMessageHeader><FONT face="Times New Roman" 
  size=2>-----Original Message-----<BR><B>From:</B> Sharon Boeyen 
  [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, May 03, 2001 
  10:35 AM<BR><B>To:</B> 'Tom Gindin'; Sharon Boeyen<BR><B>Cc:</B> 'Tim Polk'; 
  Denis Pinkas; [e-mail]<BR><B>Subject:</B> RE: Basic constraints, key 
  usage, and LDAP schema<BR><BR></FONT></DIV>
  <P><FONT size=2>I see your point - I was missing the point that they are 
  self-issued and was </FONT><BR><FONT size=2>thinking of the case where you are 
  delegating authority to an indirect </FONT><BR><FONT size=2>issuer. In the 
  indirect case the cert would need to be in the cross-cert pairs</FONT> 
  <BR><FONT size=2>attribute and may also appear in the caCerts 
  attribute.</FONT> </P>
  <P><FONT size=2>On the self issued ones, why are they needed at all? Why would 
  a CA issue </FONT><BR><FONT size=2>a cert to itself indicating that it can 
  sign CRLs? Why do we need that?</FONT> </P>
  <P><FONT size=2>Sharon</FONT> </P>
  <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
  From: Tom Gindin [<A 
  href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
  <BR><FONT size=2>&gt; Sent: Wednesday, May 02, 2001 5:43 PM</FONT> <BR><FONT 
  size=2>&gt; To: Sharon Boeyen</FONT> <BR><FONT size=2>&gt; Cc: 'Tim Polk'; 
  Denis Pinkas; [e-mail]</FONT> <BR><FONT size=2>&gt; Subject: RE: 
  Basic constraints, key usage, and LDAP schema</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In the current draft of X.509v4, 
  "self-issued" means something</FONT> <BR><FONT size=2>&gt; different than 
  "self-signed".&nbsp; "self-issued" appears to be </FONT><BR><FONT size=2>&gt; 
  the condition</FONT> <BR><FONT size=2>&gt; "the certificate's subject name can 
  be matched to its own issuer name,</FONT> <BR><FONT size=2>&gt; which is that 
  of a CA", while "self-signed" is that with the added</FONT> <BR><FONT 
  size=2>&gt; condition "the certificate signature is verifiable with the public 
  key</FONT> <BR><FONT size=2>&gt; contained in the message".&nbsp; Most of 
  these CRL signing certificates are</FONT> <BR><FONT size=2>&gt; "self-issued" 
  in this sense, although not "self-signed".</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; One other reason why such CRL 
  signing certificates would </FONT><BR><FONT size=2>&gt; legitimately</FONT> 
  <BR><FONT size=2>&gt; not go into the CC Pair attribute would be that there is 
  no </FONT><BR><FONT size=2>&gt; other directory</FONT> <BR><FONT size=2>&gt; 
  entry where the CA certificate to verify the signature on </FONT><BR><FONT 
  size=2>&gt; this certificate</FONT> <BR><FONT size=2>&gt; could be found, 
  unlike any other certificates in CC Pair.</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Lastly, if a CRL signing certificate 
  were issued by a CA </FONT><BR><FONT size=2>&gt; certificate</FONT> <BR><FONT 
  size=2>&gt; with the same DN, it would certainly belong in the same realm, if 
  that</FONT> <BR><FONT size=2>&gt; concept has any meaning at all.</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tom 
  Gindin</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; Sharon Boeyen &lt;[e-mail]&gt; 
  on 05/02/2001 04:05:54 PM</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; To:&nbsp;&nbsp; "'Tim Polk'" &lt;[e-mail]&gt;, Denis 
  Pinkas</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &lt;[e-mail]&gt;</FONT> <BR><FONT size=2>&gt; cc:&nbsp;&nbsp; 
  [e-mail]</FONT> <BR><FONT size=2>&gt; Subject:&nbsp; RE: Basic 
  constraints, key usage, and LDAP schema</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Hi Tim,</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; I just want to clarify the directory attributes. All certs 
  </FONT><BR><FONT size=2>&gt; that are not</FONT> <BR><FONT size=2>&gt; self 
  issued must go in the cross certificates attribute. All </FONT><BR><FONT 
  size=2>&gt; self issued</FONT> <BR><FONT size=2>&gt; certs must go in the 
  caCertificates attribute. A subset of </FONT><BR><FONT size=2>&gt; the 
  certificates</FONT> <BR><FONT size=2>&gt; in the cross certificate pairs 
  attributes may also be present in the</FONT> <BR><FONT size=2>&gt; 
  caCertificates attribute (those issued within the same realm, </FONT><BR><FONT 
  size=2>&gt; a term left</FONT> <BR><FONT size=2>&gt; undefined). Lets not go 
  back down that rathole :-) The two </FONT><BR><FONT size=2>&gt; attributes 
  are</FONT> <BR><FONT size=2>&gt; not interchangeable. Given that the certs you 
  are talking </FONT><BR><FONT size=2>&gt; about are not</FONT> <BR><FONT 
  size=2>&gt; self issued then they must go in the cross certificate pairs 
  </FONT><BR><FONT size=2>&gt; attribute and</FONT> <BR><FONT size=2>&gt; may 
  also be placed in the caCertificate attribute if issued </FONT><BR><FONT 
  size=2>&gt; within the same</FONT> <BR><FONT size=2>&gt; realm.</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; Sharon</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; &gt; -----Original Message-----</FONT> <BR><FONT 
  size=2>&gt; &gt; From: Tim Polk [<A 
  href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> <BR><FONT 
  size=2>&gt; &gt; Sent: Wednesday, May 02, 2001 10:43 AM</FONT> <BR><FONT 
  size=2>&gt; &gt; To: Denis Pinkas</FONT> <BR><FONT size=2>&gt; &gt; Cc: 
  [e-mail]</FONT> <BR><FONT size=2>&gt; &gt; Subject: Re: Basic 
  constraints, key usage, and LDAP schema</FONT> <BR><FONT size=2>&gt; 
  &gt;</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; 
  Denis,</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; 
  These messages have been flying fast and furious under several topic</FONT> 
  <BR><FONT size=2>&gt; &gt; lines.&nbsp; I don't believe I caught them all 
  either!&nbsp; As they</FONT> <BR><FONT size=2>&gt; &gt; are all 
  related,</FONT> <BR><FONT size=2>&gt; &gt; it is difficult to resolve the 
  issues one-by-one.&nbsp; The</FONT> <BR><FONT size=2>&gt; &gt; separate 
  solutions</FONT> <BR><FONT size=2>&gt; &gt; may combine to present new 
  problems.&nbsp; That was the rationale</FONT> <BR><FONT size=2>&gt; &gt; for 
  the single</FONT> <BR><FONT size=2>&gt; &gt; comprehensive posting.</FONT> 
  <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; The real 
  problems, in my opinion, are as follows:</FONT> <BR><FONT size=2>&gt; 
  &gt;</FONT> <BR><FONT size=2>&gt; &gt; (1) Consider a PKIX client, searching 
  for a certificate to </FONT><BR><FONT size=2>&gt; validate a</FONT> <BR><FONT 
  size=2>&gt; &gt; particular CRL.&nbsp; Under 2459, the client cannot guess 
  whether</FONT> <BR><FONT size=2>&gt; &gt; the basic</FONT> <BR><FONT 
  size=2>&gt; &gt; constraints extension will be present with the CA bit 
  asserted.</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; 
  If the key used to validate the CRL is also used to validate</FONT> <BR><FONT 
  size=2>&gt; &gt; certificates,</FONT> <BR><FONT size=2>&gt; &gt; it will have 
  basic constraints and assert cA is TRUE.&nbsp; In</FONT> <BR><FONT size=2>&gt; 
  &gt; this case, the</FONT> <BR><FONT size=2>&gt; &gt; certificate should be in 
  the ca certificate attribute (or</FONT> <BR><FONT size=2>&gt; &gt; perhaps the 
  cross</FONT> <BR><FONT size=2>&gt; &gt; certificate pairs).</FONT> <BR><FONT 
  size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; If the key is not used to 
  validate certificates, basic</FONT> <BR><FONT size=2>&gt; &gt; constraints 
  will be</FONT> <BR><FONT size=2>&gt; &gt; omitted and the certificate will be 
  stored in the user</FONT> <BR><FONT size=2>&gt; &gt; certificate 
  attribute.</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; 
  (2) If a PKIX client wishes to communicate with a CA for certificate</FONT> 
  <BR><FONT size=2>&gt; &gt; management purposes (e.g., to request a new 
  certificate, request</FONT> <BR><FONT size=2>&gt; &gt; revocation, or perhaps 
  centralized key generation for key</FONT> <BR><FONT size=2>&gt; &gt; escrow 
  scenarios)</FONT> <BR><FONT size=2>&gt; &gt; the client will need to validate 
  the CA's signature and</FONT> <BR><FONT size=2>&gt; &gt; perhaps make use 
  of</FONT> <BR><FONT size=2>&gt; &gt; the CA's key management key.&nbsp; If the 
  keys used for these</FONT> <BR><FONT size=2>&gt; &gt; transactions are</FONT> 
  <BR><FONT size=2>&gt; &gt; also used to sign PKCs, the certs will be in the CA 
  certificate</FONT> <BR><FONT size=2>&gt; &gt; attribute.&nbsp; If the keys 
  used for these purposes are not used</FONT> <BR><FONT size=2>&gt; &gt; to sign 
  PKCs,</FONT> <BR><FONT size=2>&gt; &gt; there will be no indication that this 
  entity is a CA and the</FONT> <BR><FONT size=2>&gt; &gt; certs will be</FONT> 
  <BR><FONT size=2>&gt; &gt; stored in the user certificate attribute.</FONT> 
  <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; As above, the 
  PKIX client does not know where to look for these</FONT> <BR><FONT size=2>&gt; 
  &gt; certificates.&nbsp; Where they are not used to sign PKCs, there 
  </FONT><BR><FONT size=2>&gt; will be no</FONT> <BR><FONT size=2>&gt; &gt; 
  indication in the certificate that this entity is a CA at all.</FONT> 
  <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; (3) The attribute 
  certificate profile is very clear regarding</FONT> <BR><FONT size=2>&gt; &gt; 
  AC issuers</FONT> <BR><FONT size=2>&gt; &gt; versus PKC issuers. Section 4.5 
  states "the AC issuer's PKC</FONT> <BR><FONT size=2>&gt; &gt; MUST NOT have 
  a</FONT> <BR><FONT size=2>&gt; &gt; basicConstraints extension with the cA 
  BOOLEAN set to TRUE."</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT 
  size=2>&gt; &gt; However, the combination of RFC 2459 and the attribute</FONT> 
  <BR><FONT size=2>&gt; &gt; certificate profile</FONT> <BR><FONT size=2>&gt; 
  &gt; does not permit an issuer to specify whether a subject can 
  </FONT><BR><FONT size=2>&gt; issue CRLs</FONT> <BR><FONT size=2>&gt; &gt; 
  for&nbsp; PKCs, ACs, or both.&nbsp; This would provide us with an</FONT> 
  <BR><FONT size=2>&gt; &gt; analogous solution:</FONT> <BR><FONT size=2>&gt; 
  &gt; if the CA bit is not asserted, but the cRLSign bit is set in</FONT> 
  <BR><FONT size=2>&gt; &gt; key usage, the</FONT> <BR><FONT size=2>&gt; &gt; 
  subject is only permitted to issue CRLs for ACs.</FONT> <BR><FONT size=2>&gt; 
  &gt;</FONT> <BR><FONT size=2>&gt; &gt; To be honest, (3) is the least 
  compelling problem.&nbsp; The CA</FONT> <BR><FONT size=2>&gt; &gt; must 
  explicitly</FONT> <BR><FONT size=2>&gt; &gt; name an indirect CRL issuer in 
  PKCs it issues *anyway*, so</FONT> <BR><FONT size=2>&gt; &gt; the CA bit 
  isn't</FONT> <BR><FONT size=2>&gt; &gt; a big security issue.&nbsp; Still, I 
  think it is nice to supply</FONT> <BR><FONT size=2>&gt; &gt; clients 
  with</FONT> <BR><FONT size=2>&gt; &gt; this information.</FONT> <BR><FONT 
  size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; Anyway, I hope this 
  clarifies things a bit.&nbsp; My goal was to</FONT> <BR><FONT size=2>&gt; &gt; 
  resolve all</FONT> <BR><FONT size=2>&gt; &gt; three problems simultaneously 
  and consistently.</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT 
  size=2>&gt; &gt; Thanks,</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT 
  size=2>&gt; &gt; Tim Polk</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT 
  size=2>&gt; &gt; At 03:14 PM 5/2/01 +0200, Denis Pinkas wrote:</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt;Tim,</FONT> <BR><FONT size=2>&gt; &gt; 
  &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;I stayed silent on that topic and 
  it is quite hard to catch</FONT> <BR><FONT size=2>&gt; &gt; all the 
  e-mails</FONT> <BR><FONT size=2>&gt; &gt; &gt;related to it. I certainly 
  missed or skipped missed some of them.</FONT> <BR><FONT size=2>&gt; &gt; 
  &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; Terry,</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; I think 
  it would be best if the client did not need to check the</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; &gt; userCertificate attribute to validate CRLs.&nbsp; 
  This adds</FONT> <BR><FONT size=2>&gt; &gt; complexity without</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; &gt; any real benefit (in my opinion.)&nbsp; I 
  have included some</FONT> <BR><FONT size=2>&gt; &gt; proposed text for</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; &gt; the first paragraph of section 4.2.1.10 
  (basic</FONT> <BR><FONT size=2>&gt; &gt; constraints) that would</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; &gt; clarify the issue.</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
  ----------------proposed text for first paragraph of</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; 4.2.1.10----------------</FONT> <BR><FONT size=2>&gt; 
  &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; The basic 
  constraints extension identifies whether the</FONT> <BR><FONT size=2>&gt; &gt; 
  subject of the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; certificate is a CA 
  and the maximum depth of valid</FONT> <BR><FONT size=2>&gt; &gt; certification 
  paths that</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; include this 
  certificate.&nbsp; A subject is considered a CA</FONT> <BR><FONT size=2>&gt; 
  &gt; if it issues public</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; key 
  certificates or CRLs that describe the revocation</FONT> <BR><FONT size=2>&gt; 
  &gt; status of public key</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
  certificates.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; &gt; ----------------------end proposed text</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; &gt; What do you think?</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;RFC 2459 only 
  said:</FONT> <BR><FONT size=2>&gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; 
  &gt;&nbsp;&nbsp;&nbsp; The basic constraints extension identifies whether 
  the</FONT> <BR><FONT size=2>&gt; &gt; subject of the</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; certificate is a CA and how deep a 
  certification path may exist</FONT> <BR><FONT size=2>&gt; &gt; 
  &gt;&nbsp;&nbsp;&nbsp; through that CA.</FONT> <BR><FONT size=2>&gt; &gt; 
  &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;However, according to the new text 
  a "CRL Issuer" is now</FONT> <BR><FONT size=2>&gt; &gt; also a "CA": " 
  A</FONT> <BR><FONT size=2>&gt; &gt; &gt;subject is considered a CA if it 
  issues public key</FONT> <BR><FONT size=2>&gt; &gt; certificates or CRLs 
  that</FONT> <BR><FONT size=2>&gt; &gt; &gt;describe the revocation status of 
  public key certificates."</FONT> <BR><FONT size=2>&gt; &gt; &gt;</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt;The current text of new-part1-06 also goes in 
  the same direction.</FONT> <BR><FONT size=2>&gt; &gt; &gt;</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; The cA bit indicates if the certified 
  public key may be used to</FONT> <BR><FONT size=2>&gt; &gt; 
  &gt;&nbsp;&nbsp;&nbsp; verify signatures on other certificates.&nbsp; If the 
  cA bit</FONT> <BR><FONT size=2>&gt; &gt; is asserted,</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; then either the keyCertSign bit or the 
  cRLSign bit in</FONT> <BR><FONT size=2>&gt; &gt; the key usage</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; extension (see 4.2.1.3) MUST 
  also be asserted. If the cA</FONT> <BR><FONT size=2>&gt; &gt; bit is 
  not</FONT> <BR><FONT size=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; asserted, then 
  both the keyCertSign bit and the cRLSign</FONT> <BR><FONT size=2>&gt; &gt; in 
  the key</FONT> <BR><FONT size=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; usage 
  extension MUST NOT be asserted.</FONT> <BR><FONT size=2>&gt; &gt; &gt;</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt;This seems quite strange. A CRL issuer is just 
  one way to</FONT> <BR><FONT size=2>&gt; &gt; make available</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt;revocation status information. OCSP is another way. RFC 
  2560 says:</FONT> <BR><FONT size=2>&gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; 
  &gt; &gt;&nbsp;&nbsp;&nbsp; OCSP signing delegation SHALL be designated by 
  the</FONT> <BR><FONT size=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; inclusion of 
  id-kp-OCSPSigning in an extendedKeyUsage </FONT><BR><FONT size=2>&gt; 
  certificate</FONT> <BR><FONT size=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; extension 
  included in the OCSP response signer's</FONT> <BR><FONT size=2>&gt; &gt; 
  certificate.&nbsp; This</FONT> <BR><FONT size=2>&gt; &gt; 
  &gt;&nbsp;&nbsp;&nbsp; certificate MUST be issued directly by the CA that 
  issued the</FONT> <BR><FONT size=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; 
  certificate in question.</FONT> <BR><FONT size=2>&gt; &gt; &gt;</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt;If a "CRL issuer" is a "CA", why should an OCSP 
  responder</FONT> <BR><FONT size=2>&gt; &gt; designated by a CA</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt;not also be a "CA" ?</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;As far as I 
  remember, originally the cA boolean in the basic</FONT> <BR><FONT size=2>&gt; 
  &gt; constraints</FONT> <BR><FONT size=2>&gt; &gt; &gt;extension only allowed 
  to make the difference between leaf</FONT> <BR><FONT size=2>&gt; &gt; 
  certificates and</FONT> <BR><FONT size=2>&gt; &gt; &gt;CA certificates. This 
  boolean now seems to be be used with a</FONT> <BR><FONT size=2>&gt; &gt; 
  different</FONT> <BR><FONT size=2>&gt; &gt; &gt;meaning (and, maybe, we should 
  change its meaning - not </FONT><BR><FONT size=2>&gt; the syntax).</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;Could 
  someone say again, why that change was requested and</FONT> <BR><FONT 
  size=2>&gt; &gt; what are the real</FONT> <BR><FONT size=2>&gt; &gt; 
  &gt;benefits of that change ?</FONT> <BR><FONT size=2>&gt; &gt; &gt;</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt;In other words, could someone say again what 
  the problem was ? :-)</FONT> <BR><FONT size=2>&gt; &gt; &gt;</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt;Thanks,</FONT> <BR><FONT size=2>&gt; &gt; &gt;</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt;Denis</FONT> <BR><FONT size=2>&gt; &gt; 
  &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; Thanks,</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; Tim 
  Polk</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; 
  &gt; &gt; &gt; At 01:41 PM 5/1/01 -0700, Terry Hayes wrote:</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; &gt; &gt;Tim,</FONT> <BR><FONT size=2>&gt; &gt; &gt; 
  &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;I agree with your 
  proposed solution.&nbsp; As you have said,</FONT> <BR><FONT size=2>&gt; &gt; 
  it separates the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;semantics of 
  the two extensions, and simplifies the</FONT> <BR><FONT size=2>&gt; &gt; rules 
  for the LDAP</FONT> <BR><FONT size=2>&gt; &gt; &gt; schema.</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
  &gt;There is one remaining point to address, and I believe</FONT> <BR><FONT 
  size=2>&gt; &gt; it may be the main</FONT> <BR><FONT size=2>&gt; &gt; &gt; 
  &gt; &gt;point of discussion in the current thread.</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
  &gt;When a CA uses the CRLDP extension to designate another</FONT> <BR><FONT 
  size=2>&gt; &gt; entity to be the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
  &gt;source for revocation information about some of its</FONT> <BR><FONT 
  size=2>&gt; &gt; certificates, should</FONT> <BR><FONT size=2>&gt; &gt; &gt; 
  &gt; &gt;that entity&nbsp; have a "CA" certificate (with appropriate</FONT> 
  <BR><FONT size=2>&gt; &gt; basicConstraints</FONT> <BR><FONT size=2>&gt; &gt; 
  &gt; &gt; &gt;extension)?&nbsp; I'm *not* suggesting that a</FONT> <BR><FONT 
  size=2>&gt; &gt; basicConstraints extension is</FONT> <BR><FONT size=2>&gt; 
  &gt; &gt; &gt; &gt;necessary for the entity to be authorized to sign 
  the</FONT> <BR><FONT size=2>&gt; &gt; CRL.&nbsp; Instead, the</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; &gt; &gt;problem is that clients that are trying to 
  locate the</FONT> <BR><FONT size=2>&gt; &gt; certificate will not</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;know whether they should look in the 
  cACertificate</FONT> <BR><FONT size=2>&gt; &gt; attribute or the</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;userCertificate attribute to find the 
  appropriate certificate.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
  &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;To solve this, we can 
  suggest that cACertificate be</FONT> <BR><FONT size=2>&gt; &gt; searched 
  first,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;followed by 
  userCertificate, or we can require that</FONT> <BR><FONT size=2>&gt; &gt; 
  designated entities</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;must 
  always be a "CA", and the client can safely skip</FONT> <BR><FONT size=2>&gt; 
  &gt; the userCertificate</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
  &gt;attribute.&nbsp; This is a question of searching the</FONT> <BR><FONT 
  size=2>&gt; &gt; directory only, and does</FONT> <BR><FONT size=2>&gt; &gt; 
  &gt; &gt; &gt;not suggest changing your assertion that any set of bits</FONT> 
  <BR><FONT size=2>&gt; &gt; may be set in the</FONT> <BR><FONT size=2>&gt; &gt; 
  &gt; &gt; &gt;keyUsage extension of "CA" certificates.</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
  &gt;Terry</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; &gt; &gt;Tim Polk wrote:</FONT> <BR><FONT size=2>&gt; 
  &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
  &gt;&gt;Folks,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;I have been reading the email 
  messages on the list about the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
  &gt;&gt;relationships between basic constraints, key usage, and</FONT> 
  <BR><FONT size=2>&gt; &gt; the schema.</FONT> <BR><FONT size=2>&gt; &gt; &gt; 
  &gt; &gt;&gt;After mulling over the problem.&nbsp; I would like to</FONT> 
  <BR><FONT size=2>&gt; &gt; propose a solution - the</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; &gt; &gt;&gt;only solution, as far as I can 
  tell...</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; &gt; &gt;&gt;The solution is to simplify and separate 
  the semantics</FONT> <BR><FONT size=2>&gt; &gt; of the basic</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; &gt; &gt;&gt;constraints and key usage extension.&nbsp; 
  This has positive</FONT> <BR><FONT size=2>&gt; &gt; implications for</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;the PKIX LDAP schema as 
  well.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; &gt; &gt;&gt;Basic Constraints</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; 
  &gt; &gt;&gt;As stated in the current text for Basic Constraints (in</FONT> 
  <BR><FONT size=2>&gt; &gt; 2459):&nbsp; "The</FONT> <BR><FONT size=2>&gt; &gt; 
  &gt; &gt; &gt;&gt;basic constraints extension identifies whether the</FONT> 
  <BR><FONT size=2>&gt; &gt; subject of the</FONT> <BR><FONT size=2>&gt; &gt; 
  &gt; &gt; &gt;&gt;certificate is a CA and how deep a certification path</FONT> 
  <BR><FONT size=2>&gt; &gt; may exist through</FONT> <BR><FONT size=2>&gt; &gt; 
  &gt; &gt; &gt;&gt;that CA."</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
  &gt;&gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;I believe this is 
  the right semantics, and that basic</FONT> <BR><FONT size=2>&gt; &gt; 
  constraints should</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;be 
  included and cA should be asserted in *any*</FONT> <BR><FONT size=2>&gt; &gt; 
  certificate issued to a</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
  &gt;&gt;CA, regardless of the type or role associated with the</FONT> 
  <BR><FONT size=2>&gt; &gt; public key in the</FONT> <BR><FONT size=2>&gt; &gt; 
  &gt; &gt; &gt;&gt;certificate.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
  &gt;&gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;Key Usage</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT> <BR><FONT size=2>&gt; 
  &gt; &gt; &gt; &gt;&gt;The issuer should use the Key Usage extension to</FONT> 
  <BR><FONT size=2>&gt; &gt; disambiguate the</FONT> <BR><FONT size=2>&gt; &gt; 
  &gt; &gt; &gt;&gt;subject's key pairs:</FONT> <BR><FONT size=2>&gt; &gt; &gt; 
  &gt; &gt;&gt;(a) The issuer indicates this public key may be used to</FONT> 
  <BR><FONT size=2>&gt; &gt; verify the</FONT> <BR><FONT size=2>&gt; &gt; &gt; 
  &gt; &gt;&gt;signature on a public key certificate by asserting</FONT> 
  <BR><FONT size=2>&gt; &gt; keyCertSign.&nbsp; (b) The</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; &gt; &gt;&gt;issuer indicates this public key may be 
  used to verify</FONT> <BR><FONT size=2>&gt; &gt; the signature on</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;CRLs by asserting cRLSign.&nbsp; 
  (c) The issuer indicates</FONT> <BR><FONT size=2>&gt; &gt; that this public 
  key</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;may be used to 
  establish symmetric keys with the</FONT> <BR><FONT size=2>&gt; &gt; subject by 
  asserting</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;either 
  keyEncipherment or keyAgreement.&nbsp; (d) The issuer</FONT> <BR><FONT 
  size=2>&gt; &gt; indicates that</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
  &gt;&gt;this public key may be used to verify signatures on</FONT> <BR><FONT 
  size=2>&gt; &gt; objects other than</FONT> <BR><FONT size=2>&gt; &gt; &gt; 
  &gt; &gt;&gt;public key certificates and CRLs by asserting </FONT><BR><FONT 
  size=2>&gt; nonRerpuidation or</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
  &gt;&gt;digitalSignature.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
  &gt;&gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;Of course, if a 
  key pair is used for multiple purposes,</FONT> <BR><FONT size=2>&gt; &gt; 
  multiple key</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;usages may be 
  asserted.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;In each of these cases, the basic 
  constraints extension</FONT> <BR><FONT size=2>&gt; &gt; also appears in</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;the certificate and asserts that 
  the subject is a CA.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
  &gt;&gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;LDAP 
  Schema</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; &gt; &gt;&gt;All certificates issued to CAs would be 
  considered CA</FONT> <BR><FONT size=2>&gt; &gt; certificates since</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;the basic constraints extension 
  is present and asserts</FONT> <BR><FONT size=2>&gt; &gt; that the 
  subject</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;is a CA.&nbsp; As 
  a result, each of these could appear in</FONT> <BR><FONT size=2>&gt; &gt; the 
  cACertificate</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;attribute or 
  crossCertificatePair attribute.&nbsp; They</FONT> <BR><FONT size=2>&gt; &gt; 
  would *not* appear in</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;the 
  userCertificate attribute.&nbsp; (That would include all</FONT> <BR><FONT 
  size=2>&gt; &gt; types (a) through</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
  &gt;&gt;(d) above).</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
  &gt;&gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
  &gt;&gt;------------------</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
  &gt;&gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;The implications 
  of this strategy are as follows: (1)</FONT> <BR><FONT size=2>&gt; &gt; when a 
  client is</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;searching for a 
  CA certificate, they will not have to </FONT><BR><FONT size=2>&gt; check 
  the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;userCertificate 
  attribute; (2) the issuer can indicate</FONT> <BR><FONT size=2>&gt; &gt; that 
  the subject</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;is a CA 
  regardless of the key usage; and (3) minimal</FONT> <BR><FONT size=2>&gt; &gt; 
  changes to the text</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;(my 
  favorite!).</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;What do you think?</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT> <BR><FONT size=2>&gt; 
  &gt; &gt; &gt; &gt;&gt;Thanks,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
  &gt;&gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;Tim Polk</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT> <BR><FONT size=2>&gt; 
  &gt; &gt; &gt; &gt;&gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
  &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT 
  size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; </FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C0D3F1.710ED370--


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA20469 for <[e-mail]>; Thu, 3 May 2001 09:42:04 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <KGKQ8GVK>; Thu, 3 May 2001 12:41:34 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Sharon Boeyen <[e-mail]>, "'Tom Gindin'" <[e-mail]>
Cc: "'Tim Polk'" <[e-mail]>, Denis Pinkas <[e-mail]>, [e-mail]
Subject: RE: Basic constraints, key usage, and LDAP schema
Date: Thu, 3 May 2001 12:32:29 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D3EE.A5514DA0"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D3EE.A5514DA0
Content-Type: text/plain;
	charset="iso-8859-1"

Sharon:
 
One reason a CA may issue itself a CRL signing certificate is the scenario
as follows:
 
1.  The CA is a trust anchor for some relying parties, and
 
2.  The CA wants to use different key for CRL signing for operational
security, and
 
3.  The CA wants to only provide one trust anchor (i.e., the certificate
signature verification public key).
 
In that scenario, the CA will issue itself a certificate for the CRL
signature verification public key.
 
-----Original Message-----
From: Sharon Boeyen [mailto:[e-mail]]
Sent: Thursday, May 03, 2001 10:35 AM
To: 'Tom Gindin'; Sharon Boeyen
Cc: 'Tim Polk'; Denis Pinkas; [e-mail]
Subject: RE: Basic constraints, key usage, and LDAP schema



I see your point - I was missing the point that they are self-issued and was

thinking of the case where you are delegating authority to an indirect 
issuer. In the indirect case the cert would need to be in the cross-cert
pairs 
attribute and may also appear in the caCerts attribute. 

On the self issued ones, why are they needed at all? Why would a CA issue 
a cert to itself indicating that it can sign CRLs? Why do we need that? 

Sharon 

> -----Original Message----- 
> From: Tom Gindin [ mailto:[e-mail] <mailto:[e-mail]> ]

> Sent: Wednesday, May 02, 2001 5:43 PM 
> To: Sharon Boeyen 
> Cc: 'Tim Polk'; Denis Pinkas; [e-mail] 
> Subject: RE: Basic constraints, key usage, and LDAP schema 
> 
> 
> 
>      In the current draft of X.509v4, "self-issued" means something 
> different than "self-signed".  "self-issued" appears to be 
> the condition 
> "the certificate's subject name can be matched to its own issuer name, 
> which is that of a CA", while "self-signed" is that with the added 
> condition "the certificate signature is verifiable with the public key 
> contained in the message".  Most of these CRL signing certificates are 
> "self-issued" in this sense, although not "self-signed". 
>      One other reason why such CRL signing certificates would 
> legitimately 
> not go into the CC Pair attribute would be that there is no 
> other directory 
> entry where the CA certificate to verify the signature on 
> this certificate 
> could be found, unlike any other certificates in CC Pair. 
>      Lastly, if a CRL signing certificate were issued by a CA 
> certificate 
> with the same DN, it would certainly belong in the same realm, if that 
> concept has any meaning at all. 
> 
>           Tom Gindin 
> 
> 
> Sharon Boeyen <[e-mail]> on 05/02/2001 04:05:54 PM 
> 
> To:   "'Tim Polk'" <[e-mail]>, Denis Pinkas 
>       <[e-mail]> 
> cc:   [e-mail] 
> Subject:  RE: Basic constraints, key usage, and LDAP schema 
> 
> 
> Hi Tim, 
> 
> 
> I just want to clarify the directory attributes. All certs 
> that are not 
> self issued must go in the cross certificates attribute. All 
> self issued 
> certs must go in the caCertificates attribute. A subset of 
> the certificates 
> in the cross certificate pairs attributes may also be present in the 
> caCertificates attribute (those issued within the same realm, 
> a term left 
> undefined). Lets not go back down that rathole :-) The two 
> attributes are 
> not interchangeable. Given that the certs you are talking 
> about are not 
> self issued then they must go in the cross certificate pairs 
> attribute and 
> may also be placed in the caCertificate attribute if issued 
> within the same 
> realm. 
> 
> 
> Sharon 
> 
> 
> > -----Original Message----- 
> > From: Tim Polk [ mailto:[e-mail] <mailto:[e-mail]> ] 
> > Sent: Wednesday, May 02, 2001 10:43 AM 
> > To: Denis Pinkas 
> > Cc: [e-mail] 
> > Subject: Re: Basic constraints, key usage, and LDAP schema 
> > 
> > 
> > Denis, 
> > 
> > These messages have been flying fast and furious under several topic 
> > lines.  I don't believe I caught them all either!  As they 
> > are all related, 
> > it is difficult to resolve the issues one-by-one.  The 
> > separate solutions 
> > may combine to present new problems.  That was the rationale 
> > for the single 
> > comprehensive posting. 
> > 
> > The real problems, in my opinion, are as follows: 
> > 
> > (1) Consider a PKIX client, searching for a certificate to 
> validate a 
> > particular CRL.  Under 2459, the client cannot guess whether 
> > the basic 
> > constraints extension will be present with the CA bit asserted. 
> > 
> > If the key used to validate the CRL is also used to validate 
> > certificates, 
> > it will have basic constraints and assert cA is TRUE.  In 
> > this case, the 
> > certificate should be in the ca certificate attribute (or 
> > perhaps the cross 
> > certificate pairs). 
> > 
> > If the key is not used to validate certificates, basic 
> > constraints will be 
> > omitted and the certificate will be stored in the user 
> > certificate attribute. 
> > 
> > (2) If a PKIX client wishes to communicate with a CA for certificate 
> > management purposes (e.g., to request a new certificate, request 
> > revocation, or perhaps centralized key generation for key 
> > escrow scenarios) 
> > the client will need to validate the CA's signature and 
> > perhaps make use of 
> > the CA's key management key.  If the keys used for these 
> > transactions are 
> > also used to sign PKCs, the certs will be in the CA certificate 
> > attribute.  If the keys used for these purposes are not used 
> > to sign PKCs, 
> > there will be no indication that this entity is a CA and the 
> > certs will be 
> > stored in the user certificate attribute. 
> > 
> > As above, the PKIX client does not know where to look for these 
> > certificates.  Where they are not used to sign PKCs, there 
> will be no 
> > indication in the certificate that this entity is a CA at all. 
> > 
> > (3) The attribute certificate profile is very clear regarding 
> > AC issuers 
> > versus PKC issuers. Section 4.5 states "the AC issuer's PKC 
> > MUST NOT have a 
> > basicConstraints extension with the cA BOOLEAN set to TRUE." 
> > 
> > However, the combination of RFC 2459 and the attribute 
> > certificate profile 
> > does not permit an issuer to specify whether a subject can 
> issue CRLs 
> > for  PKCs, ACs, or both.  This would provide us with an 
> > analogous solution: 
> > if the CA bit is not asserted, but the cRLSign bit is set in 
> > key usage, the 
> > subject is only permitted to issue CRLs for ACs. 
> > 
> > To be honest, (3) is the least compelling problem.  The CA 
> > must explicitly 
> > name an indirect CRL issuer in PKCs it issues *anyway*, so 
> > the CA bit isn't 
> > a big security issue.  Still, I think it is nice to supply 
> > clients with 
> > this information. 
> > 
> > Anyway, I hope this clarifies things a bit.  My goal was to 
> > resolve all 
> > three problems simultaneously and consistently. 
> > 
> > Thanks, 
> > 
> > Tim Polk 
> > 
> > At 03:14 PM 5/2/01 +0200, Denis Pinkas wrote: 
> > >Tim, 
> > > 
> > >I stayed silent on that topic and it is quite hard to catch 
> > all the e-mails 
> > >related to it. I certainly missed or skipped missed some of them. 
> > > 
> > > > Terry, 
> > > > 
> > > > I think it would be best if the client did not need to check the 
> > > > userCertificate attribute to validate CRLs.  This adds 
> > complexity without 
> > > > any real benefit (in my opinion.)  I have included some 
> > proposed text for 
> > > > the first paragraph of section 4.2.1.10 (basic 
> > constraints) that would 
> > > > clarify the issue. 
> > > > 
> > > > ----------------proposed text for first paragraph of 
> > > 4.2.1.10---------------- 
> > > > 
> > > > The basic constraints extension identifies whether the 
> > subject of the 
> > > > certificate is a CA and the maximum depth of valid 
> > certification paths that 
> > > > include this certificate.  A subject is considered a CA 
> > if it issues public 
> > > > key certificates or CRLs that describe the revocation 
> > status of public key 
> > > > certificates. 
> > > > 
> > > > ----------------------end proposed text 
> > > > What do you think? 
> > > 
> > >RFC 2459 only said: 
> > > 
> > >    The basic constraints extension identifies whether the 
> > subject of the 
> > >    certificate is a CA and how deep a certification path may exist 
> > >    through that CA. 
> > > 
> > >However, according to the new text a "CRL Issuer" is now 
> > also a "CA": " A 
> > >subject is considered a CA if it issues public key 
> > certificates or CRLs that 
> > >describe the revocation status of public key certificates." 
> > > 
> > >The current text of new-part1-06 also goes in the same direction. 
> > > 
> > >    The cA bit indicates if the certified public key may be used to 
> > >    verify signatures on other certificates.  If the cA bit 
> > is asserted, 
> > >    then either the keyCertSign bit or the cRLSign bit in 
> > the key usage 
> > >    extension (see 4.2.1.3) MUST also be asserted. If the cA 
> > bit is not 
> > >    asserted, then both the keyCertSign bit and the cRLSign 
> > in the key 
> > >    usage extension MUST NOT be asserted. 
> > > 
> > >This seems quite strange. A CRL issuer is just one way to 
> > make available 
> > >revocation status information. OCSP is another way. RFC 2560 says: 
> > > 
> > >    OCSP signing delegation SHALL be designated by the 
> > >    inclusion of id-kp-OCSPSigning in an extendedKeyUsage 
> certificate 
> > >    extension included in the OCSP response signer's 
> > certificate.  This 
> > >    certificate MUST be issued directly by the CA that issued the 
> > >    certificate in question. 
> > > 
> > >If a "CRL issuer" is a "CA", why should an OCSP responder 
> > designated by a CA 
> > >not also be a "CA" ? 
> > > 
> > >As far as I remember, originally the cA boolean in the basic 
> > constraints 
> > >extension only allowed to make the difference between leaf 
> > certificates and 
> > >CA certificates. This boolean now seems to be be used with a 
> > different 
> > >meaning (and, maybe, we should change its meaning - not 
> the syntax). 
> > > 
> > >Could someone say again, why that change was requested and 
> > what are the real 
> > >benefits of that change ? 
> > > 
> > >In other words, could someone say again what the problem was ? :-) 
> > > 
> > >Thanks, 
> > > 
> > >Denis 
> > > 
> > > > Thanks, 
> > > > 
> > > > Tim Polk 
> > > > 
> > > > At 01:41 PM 5/1/01 -0700, Terry Hayes wrote: 
> > > > >Tim, 
> > > > > 
> > > > >I agree with your proposed solution.  As you have said, 
> > it separates the 
> > > > >semantics of the two extensions, and simplifies the 
> > rules for the LDAP 
> > > schema. 
> > > > > 
> > > > >There is one remaining point to address, and I believe 
> > it may be the main 
> > > > >point of discussion in the current thread. 
> > > > > 
> > > > >When a CA uses the CRLDP extension to designate another 
> > entity to be the 
> > > > >source for revocation information about some of its 
> > certificates, should 
> > > > >that entity  have a "CA" certificate (with appropriate 
> > basicConstraints 
> > > > >extension)?  I'm *not* suggesting that a 
> > basicConstraints extension is 
> > > > >necessary for the entity to be authorized to sign the 
> > CRL.  Instead, the 
> > > > >problem is that clients that are trying to locate the 
> > certificate will not 
> > > > >know whether they should look in the cACertificate 
> > attribute or the 
> > > > >userCertificate attribute to find the appropriate certificate. 
> > > > > 
> > > > >To solve this, we can suggest that cACertificate be 
> > searched first, 
> > > > >followed by userCertificate, or we can require that 
> > designated entities 
> > > > >must always be a "CA", and the client can safely skip 
> > the userCertificate 
> > > > >attribute.  This is a question of searching the 
> > directory only, and does 
> > > > >not suggest changing your assertion that any set of bits 
> > may be set in the 
> > > > >keyUsage extension of "CA" certificates. 
> > > > > 
> > > > >Terry 
> > > > > 
> > > > >Tim Polk wrote: 
> > > > > 
> > > > >>Folks, 
> > > > >> 
> > > > >>I have been reading the email messages on the list about the 
> > > > >>relationships between basic constraints, key usage, and 
> > the schema. 
> > > > >>After mulling over the problem.  I would like to 
> > propose a solution - the 
> > > > >>only solution, as far as I can tell... 
> > > > >> 
> > > > >>The solution is to simplify and separate the semantics 
> > of the basic 
> > > > >>constraints and key usage extension.  This has positive 
> > implications for 
> > > > >>the PKIX LDAP schema as well. 
> > > > >> 
> > > > >>Basic Constraints 
> > > > >> 
> > > > >>As stated in the current text for Basic Constraints (in 
> > 2459):  "The 
> > > > >>basic constraints extension identifies whether the 
> > subject of the 
> > > > >>certificate is a CA and how deep a certification path 
> > may exist through 
> > > > >>that CA." 
> > > > >> 
> > > > >>I believe this is the right semantics, and that basic 
> > constraints should 
> > > > >>be included and cA should be asserted in *any* 
> > certificate issued to a 
> > > > >>CA, regardless of the type or role associated with the 
> > public key in the 
> > > > >>certificate. 
> > > > >> 
> > > > >>Key Usage 
> > > > >> 
> > > > >>The issuer should use the Key Usage extension to 
> > disambiguate the 
> > > > >>subject's key pairs: 
> > > > >>(a) The issuer indicates this public key may be used to 
> > verify the 
> > > > >>signature on a public key certificate by asserting 
> > keyCertSign.  (b) The 
> > > > >>issuer indicates this public key may be used to verify 
> > the signature on 
> > > > >>CRLs by asserting cRLSign.  (c) The issuer indicates 
> > that this public key 
> > > > >>may be used to establish symmetric keys with the 
> > subject by asserting 
> > > > >>either keyEncipherment or keyAgreement.  (d) The issuer 
> > indicates that 
> > > > >>this public key may be used to verify signatures on 
> > objects other than 
> > > > >>public key certificates and CRLs by asserting 
> nonRerpuidation or 
> > > > >>digitalSignature. 
> > > > >> 
> > > > >>Of course, if a key pair is used for multiple purposes, 
> > multiple key 
> > > > >>usages may be asserted. 
> > > > >> 
> > > > >>In each of these cases, the basic constraints extension 
> > also appears in 
> > > > >>the certificate and asserts that the subject is a CA. 
> > > > >> 
> > > > >>LDAP Schema 
> > > > >> 
> > > > >>All certificates issued to CAs would be considered CA 
> > certificates since 
> > > > >>the basic constraints extension is present and asserts 
> > that the subject 
> > > > >>is a CA.  As a result, each of these could appear in 
> > the cACertificate 
> > > > >>attribute or crossCertificatePair attribute.  They 
> > would *not* appear in 
> > > > >>the userCertificate attribute.  (That would include all 
> > types (a) through 
> > > > >>(d) above). 
> > > > >> 
> > > > >>------------------ 
> > > > >> 
> > > > >>The implications of this strategy are as follows: (1) 
> > when a client is 
> > > > >>searching for a CA certificate, they will not have to 
> check the 
> > > > >>userCertificate attribute; (2) the issuer can indicate 
> > that the subject 
> > > > >>is a CA regardless of the key usage; and (3) minimal 
> > changes to the text 
> > > > >>(my favorite!). 
> > > > >> 
> > > > >>What do you think? 
> > > > >> 
> > > > >>Thanks, 
> > > > >> 
> > > > >>Tim Polk 
> > > > >> 
> > > > >> 
> > > > > 
> > > > > 
> > 
> 
> 
> 


------_=_NextPart_001_01C0D3EE.A5514DA0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: Basic constraints, key usage, and LDAP schema</TITLE>

<META content="MSHTML 5.00.2014.210" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=485393616-03052001>Sharon:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=485393616-03052001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=485393616-03052001>One 
reason a CA may issue itself a CRL signing certificate is the scenario as 
follows:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=485393616-03052001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=485393616-03052001>1.&nbsp; The CA is a trust anchor for some relying 
parties, and</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=485393616-03052001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=485393616-03052001>2.&nbsp; The CA wants to use different key for CRL 
signing for operational security, and</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=485393616-03052001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=485393616-03052001>3.&nbsp; The CA wants to only provide one trust anchor 
(i.e., the certificate signature verification public key).</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=485393616-03052001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=485393616-03052001>In 
that scenario, the CA will issue itself a certificate for the CRL signature 
verification public key.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=485393616-03052001></SPAN></FONT>&nbsp;</DIV>
<DIV class=OutlookMessageHeader><FONT face="Times New Roman" 
size=2>-----Original Message-----<BR><B>From:</B> Sharon Boeyen 
[mailto:[e-mail]]<BR><B>Sent:</B> Thursday, May 03, 2001 10:35 
AM<BR><B>To:</B> 'Tom Gindin'; Sharon Boeyen<BR><B>Cc:</B> 'Tim Polk'; Denis 
Pinkas; [e-mail]<BR><B>Subject:</B> RE: Basic constraints, key usage, 
and LDAP schema<BR><BR></FONT></DIV>
<P><FONT size=2>I see your point - I was missing the point that they are 
self-issued and was </FONT><BR><FONT size=2>thinking of the case where you are 
delegating authority to an indirect </FONT><BR><FONT size=2>issuer. In the 
indirect case the cert would need to be in the cross-cert pairs</FONT> <BR><FONT 
size=2>attribute and may also appear in the caCerts attribute.</FONT> </P>
<P><FONT size=2>On the self issued ones, why are they needed at all? Why would a 
CA issue </FONT><BR><FONT size=2>a cert to itself indicating that it can sign 
CRLs? Why do we need that?</FONT> </P>
<P><FONT size=2>Sharon</FONT> </P>
<P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
From: Tom Gindin [<A 
href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> <BR><FONT 
size=2>&gt; Sent: Wednesday, May 02, 2001 5:43 PM</FONT> <BR><FONT size=2>&gt; 
To: Sharon Boeyen</FONT> <BR><FONT size=2>&gt; Cc: 'Tim Polk'; Denis Pinkas; 
[e-mail]</FONT> <BR><FONT size=2>&gt; Subject: RE: Basic constraints, 
key usage, and LDAP schema</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In the current draft of X.509v4, 
"self-issued" means something</FONT> <BR><FONT size=2>&gt; different than 
"self-signed".&nbsp; "self-issued" appears to be </FONT><BR><FONT size=2>&gt; 
the condition</FONT> <BR><FONT size=2>&gt; "the certificate's subject name can 
be matched to its own issuer name,</FONT> <BR><FONT size=2>&gt; which is that of 
a CA", while "self-signed" is that with the added</FONT> <BR><FONT size=2>&gt; 
condition "the certificate signature is verifiable with the public key</FONT> 
<BR><FONT size=2>&gt; contained in the message".&nbsp; Most of these CRL signing 
certificates are</FONT> <BR><FONT size=2>&gt; "self-issued" in this sense, 
although not "self-signed".</FONT> <BR><FONT 
size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; One other reason why such CRL signing 
certificates would </FONT><BR><FONT size=2>&gt; legitimately</FONT> <BR><FONT 
size=2>&gt; not go into the CC Pair attribute would be that there is no 
</FONT><BR><FONT size=2>&gt; other directory</FONT> <BR><FONT size=2>&gt; entry 
where the CA certificate to verify the signature on </FONT><BR><FONT size=2>&gt; 
this certificate</FONT> <BR><FONT size=2>&gt; could be found, unlike any other 
certificates in CC Pair.</FONT> <BR><FONT 
size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Lastly, if a CRL signing certificate 
were issued by a CA </FONT><BR><FONT size=2>&gt; certificate</FONT> <BR><FONT 
size=2>&gt; with the same DN, it would certainly belong in the same realm, if 
that</FONT> <BR><FONT size=2>&gt; concept has any meaning at all.</FONT> 
<BR><FONT size=2>&gt; </FONT><BR><FONT 
size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tom 
Gindin</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
</FONT><BR><FONT size=2>&gt; Sharon Boeyen &lt;[e-mail]&gt; on 
05/02/2001 04:05:54 PM</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
To:&nbsp;&nbsp; "'Tim Polk'" &lt;[e-mail]&gt;, Denis Pinkas</FONT> 
<BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
&lt;[e-mail]&gt;</FONT> <BR><FONT size=2>&gt; cc:&nbsp;&nbsp; 
[e-mail]</FONT> <BR><FONT size=2>&gt; Subject:&nbsp; RE: Basic 
constraints, key usage, and LDAP schema</FONT> <BR><FONT size=2>&gt; 
</FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Hi Tim,</FONT> 
<BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
I just want to clarify the directory attributes. All certs </FONT><BR><FONT 
size=2>&gt; that are not</FONT> <BR><FONT size=2>&gt; self issued must go in the 
cross certificates attribute. All </FONT><BR><FONT size=2>&gt; self 
issued</FONT> <BR><FONT size=2>&gt; certs must go in the caCertificates 
attribute. A subset of </FONT><BR><FONT size=2>&gt; the certificates</FONT> 
<BR><FONT size=2>&gt; in the cross certificate pairs attributes may also be 
present in the</FONT> <BR><FONT size=2>&gt; caCertificates attribute (those 
issued within the same realm, </FONT><BR><FONT size=2>&gt; a term left</FONT> 
<BR><FONT size=2>&gt; undefined). Lets not go back down that rathole :-) The two 
</FONT><BR><FONT size=2>&gt; attributes are</FONT> <BR><FONT size=2>&gt; not 
interchangeable. Given that the certs you are talking </FONT><BR><FONT 
size=2>&gt; about are not</FONT> <BR><FONT size=2>&gt; self issued then they 
must go in the cross certificate pairs </FONT><BR><FONT size=2>&gt; attribute 
and</FONT> <BR><FONT size=2>&gt; may also be placed in the caCertificate 
attribute if issued </FONT><BR><FONT size=2>&gt; within the same</FONT> 
<BR><FONT size=2>&gt; realm.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
size=2>&gt; </FONT><BR><FONT size=2>&gt; Sharon</FONT> <BR><FONT size=2>&gt; 
</FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt; -----Original 
Message-----</FONT> <BR><FONT size=2>&gt; &gt; From: Tim Polk [<A 
href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> <BR><FONT 
size=2>&gt; &gt; Sent: Wednesday, May 02, 2001 10:43 AM</FONT> <BR><FONT 
size=2>&gt; &gt; To: Denis Pinkas</FONT> <BR><FONT size=2>&gt; &gt; Cc: 
[e-mail]</FONT> <BR><FONT size=2>&gt; &gt; Subject: Re: Basic 
constraints, key usage, and LDAP schema</FONT> <BR><FONT size=2>&gt; &gt;</FONT> 
<BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; Denis,</FONT> 
<BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; These messages have 
been flying fast and furious under several topic</FONT> <BR><FONT size=2>&gt; 
&gt; lines.&nbsp; I don't believe I caught them all either!&nbsp; As they</FONT> 
<BR><FONT size=2>&gt; &gt; are all related,</FONT> <BR><FONT size=2>&gt; &gt; it 
is difficult to resolve the issues one-by-one.&nbsp; The</FONT> <BR><FONT 
size=2>&gt; &gt; separate solutions</FONT> <BR><FONT size=2>&gt; &gt; may 
combine to present new problems.&nbsp; That was the rationale</FONT> <BR><FONT 
size=2>&gt; &gt; for the single</FONT> <BR><FONT size=2>&gt; &gt; comprehensive 
posting.</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; The 
real problems, in my opinion, are as follows:</FONT> <BR><FONT size=2>&gt; 
&gt;</FONT> <BR><FONT size=2>&gt; &gt; (1) Consider a PKIX client, searching for 
a certificate to </FONT><BR><FONT size=2>&gt; validate a</FONT> <BR><FONT 
size=2>&gt; &gt; particular CRL.&nbsp; Under 2459, the client cannot guess 
whether</FONT> <BR><FONT size=2>&gt; &gt; the basic</FONT> <BR><FONT size=2>&gt; 
&gt; constraints extension will be present with the CA bit asserted.</FONT> 
<BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; If the key used to 
validate the CRL is also used to validate</FONT> <BR><FONT size=2>&gt; &gt; 
certificates,</FONT> <BR><FONT size=2>&gt; &gt; it will have basic constraints 
and assert cA is TRUE.&nbsp; In</FONT> <BR><FONT size=2>&gt; &gt; this case, 
the</FONT> <BR><FONT size=2>&gt; &gt; certificate should be in the ca 
certificate attribute (or</FONT> <BR><FONT size=2>&gt; &gt; perhaps the 
cross</FONT> <BR><FONT size=2>&gt; &gt; certificate pairs).</FONT> <BR><FONT 
size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; If the key is not used to 
validate certificates, basic</FONT> <BR><FONT size=2>&gt; &gt; constraints will 
be</FONT> <BR><FONT size=2>&gt; &gt; omitted and the certificate will be stored 
in the user</FONT> <BR><FONT size=2>&gt; &gt; certificate attribute.</FONT> 
<BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; (2) If a PKIX 
client wishes to communicate with a CA for certificate</FONT> <BR><FONT 
size=2>&gt; &gt; management purposes (e.g., to request a new certificate, 
request</FONT> <BR><FONT size=2>&gt; &gt; revocation, or perhaps centralized key 
generation for key</FONT> <BR><FONT size=2>&gt; &gt; escrow scenarios)</FONT> 
<BR><FONT size=2>&gt; &gt; the client will need to validate the CA's signature 
and</FONT> <BR><FONT size=2>&gt; &gt; perhaps make use of</FONT> <BR><FONT 
size=2>&gt; &gt; the CA's key management key.&nbsp; If the keys used for 
these</FONT> <BR><FONT size=2>&gt; &gt; transactions are</FONT> <BR><FONT 
size=2>&gt; &gt; also used to sign PKCs, the certs will be in the CA 
certificate</FONT> <BR><FONT size=2>&gt; &gt; attribute.&nbsp; If the keys used 
for these purposes are not used</FONT> <BR><FONT size=2>&gt; &gt; to sign 
PKCs,</FONT> <BR><FONT size=2>&gt; &gt; there will be no indication that this 
entity is a CA and the</FONT> <BR><FONT size=2>&gt; &gt; certs will be</FONT> 
<BR><FONT size=2>&gt; &gt; stored in the user certificate attribute.</FONT> 
<BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; As above, the PKIX 
client does not know where to look for these</FONT> <BR><FONT size=2>&gt; &gt; 
certificates.&nbsp; Where they are not used to sign PKCs, there </FONT><BR><FONT 
size=2>&gt; will be no</FONT> <BR><FONT size=2>&gt; &gt; indication in the 
certificate that this entity is a CA at all.</FONT> <BR><FONT size=2>&gt; 
&gt;</FONT> <BR><FONT size=2>&gt; &gt; (3) The attribute certificate profile is 
very clear regarding</FONT> <BR><FONT size=2>&gt; &gt; AC issuers</FONT> 
<BR><FONT size=2>&gt; &gt; versus PKC issuers. Section 4.5 states "the AC 
issuer's PKC</FONT> <BR><FONT size=2>&gt; &gt; MUST NOT have a</FONT> <BR><FONT 
size=2>&gt; &gt; basicConstraints extension with the cA BOOLEAN set to 
TRUE."</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; 
However, the combination of RFC 2459 and the attribute</FONT> <BR><FONT 
size=2>&gt; &gt; certificate profile</FONT> <BR><FONT size=2>&gt; &gt; does not 
permit an issuer to specify whether a subject can </FONT><BR><FONT size=2>&gt; 
issue CRLs</FONT> <BR><FONT size=2>&gt; &gt; for&nbsp; PKCs, ACs, or both.&nbsp; 
This would provide us with an</FONT> <BR><FONT size=2>&gt; &gt; analogous 
solution:</FONT> <BR><FONT size=2>&gt; &gt; if the CA bit is not asserted, but 
the cRLSign bit is set in</FONT> <BR><FONT size=2>&gt; &gt; key usage, 
the</FONT> <BR><FONT size=2>&gt; &gt; subject is only permitted to issue CRLs 
for ACs.</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; To 
be honest, (3) is the least compelling problem.&nbsp; The CA</FONT> <BR><FONT 
size=2>&gt; &gt; must explicitly</FONT> <BR><FONT size=2>&gt; &gt; name an 
indirect CRL issuer in PKCs it issues *anyway*, so</FONT> <BR><FONT size=2>&gt; 
&gt; the CA bit isn't</FONT> <BR><FONT size=2>&gt; &gt; a big security 
issue.&nbsp; Still, I think it is nice to supply</FONT> <BR><FONT size=2>&gt; 
&gt; clients with</FONT> <BR><FONT size=2>&gt; &gt; this information.</FONT> 
<BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; Anyway, I hope this 
clarifies things a bit.&nbsp; My goal was to</FONT> <BR><FONT size=2>&gt; &gt; 
resolve all</FONT> <BR><FONT size=2>&gt; &gt; three problems simultaneously and 
consistently.</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; 
&gt; Thanks,</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; 
Tim Polk</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; At 
03:14 PM 5/2/01 +0200, Denis Pinkas wrote:</FONT> <BR><FONT size=2>&gt; &gt; 
&gt;Tim,</FONT> <BR><FONT size=2>&gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; 
&gt; &gt;I stayed silent on that topic and it is quite hard to catch</FONT> 
<BR><FONT size=2>&gt; &gt; all the e-mails</FONT> <BR><FONT size=2>&gt; &gt; 
&gt;related to it. I certainly missed or skipped missed some of them.</FONT> 
<BR><FONT size=2>&gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
Terry,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; 
&gt; &gt; &gt; I think it would be best if the client did not need to check 
the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; userCertificate attribute to 
validate CRLs.&nbsp; This adds</FONT> <BR><FONT size=2>&gt; &gt; complexity 
without</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; any real benefit (in my 
opinion.)&nbsp; I have included some</FONT> <BR><FONT size=2>&gt; &gt; proposed 
text for</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; the first paragraph of 
section 4.2.1.10 (basic</FONT> <BR><FONT size=2>&gt; &gt; constraints) that 
would</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; clarify the issue.</FONT> 
<BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
----------------proposed text for first paragraph of</FONT> <BR><FONT 
size=2>&gt; &gt; &gt; 4.2.1.10----------------</FONT> <BR><FONT size=2>&gt; &gt; 
&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; The basic constraints 
extension identifies whether the</FONT> <BR><FONT size=2>&gt; &gt; subject of 
the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; certificate is a CA and the 
maximum depth of valid</FONT> <BR><FONT size=2>&gt; &gt; certification paths 
that</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; include this certificate.&nbsp; 
A subject is considered a CA</FONT> <BR><FONT size=2>&gt; &gt; if it issues 
public</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; key certificates or CRLs that 
describe the revocation</FONT> <BR><FONT size=2>&gt; &gt; status of public 
key</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; certificates.</FONT> <BR><FONT 
size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
----------------------end proposed text</FONT> <BR><FONT size=2>&gt; &gt; &gt; 
&gt; What do you think?</FONT> <BR><FONT size=2>&gt; &gt; &gt;</FONT> <BR><FONT 
size=2>&gt; &gt; &gt;RFC 2459 only said:</FONT> <BR><FONT size=2>&gt; &gt; 
&gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; The basic 
constraints extension identifies whether the</FONT> <BR><FONT size=2>&gt; &gt; 
subject of the</FONT> <BR><FONT size=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; 
certificate is a CA and how deep a certification path may exist</FONT> <BR><FONT 
size=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; through that CA.</FONT> <BR><FONT 
size=2>&gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;However, according 
to the new text a "CRL Issuer" is now</FONT> <BR><FONT size=2>&gt; &gt; also a 
"CA": " A</FONT> <BR><FONT size=2>&gt; &gt; &gt;subject is considered a CA if it 
issues public key</FONT> <BR><FONT size=2>&gt; &gt; certificates or CRLs 
that</FONT> <BR><FONT size=2>&gt; &gt; &gt;describe the revocation status of 
public key certificates."</FONT> <BR><FONT size=2>&gt; &gt; &gt;</FONT> 
<BR><FONT size=2>&gt; &gt; &gt;The current text of new-part1-06 also goes in the 
same direction.</FONT> <BR><FONT size=2>&gt; &gt; &gt;</FONT> <BR><FONT 
size=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; The cA bit indicates if the certified 
public key may be used to</FONT> <BR><FONT size=2>&gt; &gt; 
&gt;&nbsp;&nbsp;&nbsp; verify signatures on other certificates.&nbsp; If the cA 
bit</FONT> <BR><FONT size=2>&gt; &gt; is asserted,</FONT> <BR><FONT size=2>&gt; 
&gt; &gt;&nbsp;&nbsp;&nbsp; then either the keyCertSign bit or the cRLSign bit 
in</FONT> <BR><FONT size=2>&gt; &gt; the key usage</FONT> <BR><FONT size=2>&gt; 
&gt; &gt;&nbsp;&nbsp;&nbsp; extension (see 4.2.1.3) MUST also be asserted. If 
the cA</FONT> <BR><FONT size=2>&gt; &gt; bit is not</FONT> <BR><FONT size=2>&gt; 
&gt; &gt;&nbsp;&nbsp;&nbsp; asserted, then both the keyCertSign bit and the 
cRLSign</FONT> <BR><FONT size=2>&gt; &gt; in the key</FONT> <BR><FONT 
size=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; usage extension MUST NOT be 
asserted.</FONT> <BR><FONT size=2>&gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; 
&gt; &gt;This seems quite strange. A CRL issuer is just one way to</FONT> 
<BR><FONT size=2>&gt; &gt; make available</FONT> <BR><FONT size=2>&gt; &gt; 
&gt;revocation status information. OCSP is another way. RFC 2560 says:</FONT> 
<BR><FONT size=2>&gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; 
&gt;&nbsp;&nbsp;&nbsp; OCSP signing delegation SHALL be designated by the</FONT> 
<BR><FONT size=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; inclusion of id-kp-OCSPSigning 
in an extendedKeyUsage </FONT><BR><FONT size=2>&gt; certificate</FONT> <BR><FONT 
size=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; extension included in the OCSP response 
signer's</FONT> <BR><FONT size=2>&gt; &gt; certificate.&nbsp; This</FONT> 
<BR><FONT size=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; certificate MUST be issued 
directly by the CA that issued the</FONT> <BR><FONT size=2>&gt; &gt; 
&gt;&nbsp;&nbsp;&nbsp; certificate in question.</FONT> <BR><FONT size=2>&gt; 
&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;If a "CRL issuer" is a "CA", why 
should an OCSP responder</FONT> <BR><FONT size=2>&gt; &gt; designated by a 
CA</FONT> <BR><FONT size=2>&gt; &gt; &gt;not also be a "CA" ?</FONT> <BR><FONT 
size=2>&gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;As far as I 
remember, originally the cA boolean in the basic</FONT> <BR><FONT size=2>&gt; 
&gt; constraints</FONT> <BR><FONT size=2>&gt; &gt; &gt;extension only allowed to 
make the difference between leaf</FONT> <BR><FONT size=2>&gt; &gt; certificates 
and</FONT> <BR><FONT size=2>&gt; &gt; &gt;CA certificates. This boolean now 
seems to be be used with a</FONT> <BR><FONT size=2>&gt; &gt; different</FONT> 
<BR><FONT size=2>&gt; &gt; &gt;meaning (and, maybe, we should change its meaning 
- not </FONT><BR><FONT size=2>&gt; the syntax).</FONT> <BR><FONT size=2>&gt; 
&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;Could someone say again, why 
that change was requested and</FONT> <BR><FONT size=2>&gt; &gt; what are the 
real</FONT> <BR><FONT size=2>&gt; &gt; &gt;benefits of that change ?</FONT> 
<BR><FONT size=2>&gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;In other 
words, could someone say again what the problem was ? :-)</FONT> <BR><FONT 
size=2>&gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;Thanks,</FONT> 
<BR><FONT size=2>&gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; 
&gt;Denis</FONT> <BR><FONT size=2>&gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; 
&gt; &gt; &gt; Thanks,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT> 
<BR><FONT size=2>&gt; &gt; &gt; &gt; Tim Polk</FONT> <BR><FONT size=2>&gt; &gt; 
&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; At 01:41 PM 5/1/01 -0700, 
Terry Hayes wrote:</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;Tim,</FONT> 
<BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; 
&gt; &gt;I agree with your proposed solution.&nbsp; As you have said,</FONT> 
<BR><FONT size=2>&gt; &gt; it separates the</FONT> <BR><FONT size=2>&gt; &gt; 
&gt; &gt; &gt;semantics of the two extensions, and simplifies the</FONT> 
<BR><FONT size=2>&gt; &gt; rules for the LDAP</FONT> <BR><FONT size=2>&gt; &gt; 
&gt; schema.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT 
size=2>&gt; &gt; &gt; &gt; &gt;There is one remaining point to address, and I 
believe</FONT> <BR><FONT size=2>&gt; &gt; it may be the main</FONT> <BR><FONT 
size=2>&gt; &gt; &gt; &gt; &gt;point of discussion in the current thread.</FONT> 
<BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; 
&gt; &gt;When a CA uses the CRLDP extension to designate another</FONT> 
<BR><FONT size=2>&gt; &gt; entity to be the</FONT> <BR><FONT size=2>&gt; &gt; 
&gt; &gt; &gt;source for revocation information about some of its</FONT> 
<BR><FONT size=2>&gt; &gt; certificates, should</FONT> <BR><FONT size=2>&gt; 
&gt; &gt; &gt; &gt;that entity&nbsp; have a "CA" certificate (with 
appropriate</FONT> <BR><FONT size=2>&gt; &gt; basicConstraints</FONT> <BR><FONT 
size=2>&gt; &gt; &gt; &gt; &gt;extension)?&nbsp; I'm *not* suggesting that 
a</FONT> <BR><FONT size=2>&gt; &gt; basicConstraints extension is</FONT> 
<BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;necessary for the entity to be 
authorized to sign the</FONT> <BR><FONT size=2>&gt; &gt; CRL.&nbsp; Instead, 
the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;problem is that clients that 
are trying to locate the</FONT> <BR><FONT size=2>&gt; &gt; certificate will 
not</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;know whether they should 
look in the cACertificate</FONT> <BR><FONT size=2>&gt; &gt; attribute or 
the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;userCertificate attribute to 
find the appropriate certificate.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
&gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;To solve this, we can 
suggest that cACertificate be</FONT> <BR><FONT size=2>&gt; &gt; searched 
first,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;followed by 
userCertificate, or we can require that</FONT> <BR><FONT size=2>&gt; &gt; 
designated entities</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;must always 
be a "CA", and the client can safely skip</FONT> <BR><FONT size=2>&gt; &gt; the 
userCertificate</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;attribute.&nbsp; 
This is a question of searching the</FONT> <BR><FONT size=2>&gt; &gt; directory 
only, and does</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;not suggest 
changing your assertion that any set of bits</FONT> <BR><FONT size=2>&gt; &gt; 
may be set in the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;keyUsage 
extension of "CA" certificates.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
&gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;Terry</FONT> <BR><FONT 
size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
&gt;Tim Polk wrote:</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT> 
<BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;Folks,</FONT> <BR><FONT size=2>&gt; 
&gt; &gt; &gt; &gt;&gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;I 
have been reading the email messages on the list about the</FONT> <BR><FONT 
size=2>&gt; &gt; &gt; &gt; &gt;&gt;relationships between basic constraints, key 
usage, and</FONT> <BR><FONT size=2>&gt; &gt; the schema.</FONT> <BR><FONT 
size=2>&gt; &gt; &gt; &gt; &gt;&gt;After mulling over the problem.&nbsp; I would 
like to</FONT> <BR><FONT size=2>&gt; &gt; propose a solution - the</FONT> 
<BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;only solution, as far as I can 
tell...</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT> <BR><FONT 
size=2>&gt; &gt; &gt; &gt; &gt;&gt;The solution is to simplify and separate the 
semantics</FONT> <BR><FONT size=2>&gt; &gt; of the basic</FONT> <BR><FONT 
size=2>&gt; &gt; &gt; &gt; &gt;&gt;constraints and key usage extension.&nbsp; 
This has positive</FONT> <BR><FONT size=2>&gt; &gt; implications for</FONT> 
<BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;the PKIX LDAP schema as 
well.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT> <BR><FONT 
size=2>&gt; &gt; &gt; &gt; &gt;&gt;Basic Constraints</FONT> <BR><FONT 
size=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
&gt;&gt;As stated in the current text for Basic Constraints (in</FONT> <BR><FONT 
size=2>&gt; &gt; 2459):&nbsp; "The</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
&gt;&gt;basic constraints extension identifies whether the</FONT> <BR><FONT 
size=2>&gt; &gt; subject of the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
&gt;&gt;certificate is a CA and how deep a certification path</FONT> <BR><FONT 
size=2>&gt; &gt; may exist through</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
&gt;&gt;that CA."</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT> 
<BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;I believe this is the right 
semantics, and that basic</FONT> <BR><FONT size=2>&gt; &gt; constraints 
should</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;be included and cA 
should be asserted in *any*</FONT> <BR><FONT size=2>&gt; &gt; certificate issued 
to a</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;CA, regardless of the 
type or role associated with the</FONT> <BR><FONT size=2>&gt; &gt; public key in 
the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;certificate.</FONT> 
<BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT> <BR><FONT size=2>&gt; &gt; 
&gt; &gt; &gt;&gt;Key Usage</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
&gt;&gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;The issuer should 
use the Key Usage extension to</FONT> <BR><FONT size=2>&gt; &gt; disambiguate 
the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;subject's key 
pairs:</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;(a) The issuer 
indicates this public key may be used to</FONT> <BR><FONT size=2>&gt; &gt; 
verify the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;signature on a 
public key certificate by asserting</FONT> <BR><FONT size=2>&gt; &gt; 
keyCertSign.&nbsp; (b) The</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
&gt;&gt;issuer indicates this public key may be used to verify</FONT> <BR><FONT 
size=2>&gt; &gt; the signature on</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
&gt;&gt;CRLs by asserting cRLSign.&nbsp; (c) The issuer indicates</FONT> 
<BR><FONT size=2>&gt; &gt; that this public key</FONT> <BR><FONT size=2>&gt; 
&gt; &gt; &gt; &gt;&gt;may be used to establish symmetric keys with the</FONT> 
<BR><FONT size=2>&gt; &gt; subject by asserting</FONT> <BR><FONT size=2>&gt; 
&gt; &gt; &gt; &gt;&gt;either keyEncipherment or keyAgreement.&nbsp; (d) The 
issuer</FONT> <BR><FONT size=2>&gt; &gt; indicates that</FONT> <BR><FONT 
size=2>&gt; &gt; &gt; &gt; &gt;&gt;this public key may be used to verify 
signatures on</FONT> <BR><FONT size=2>&gt; &gt; objects other than</FONT> 
<BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;public key certificates and CRLs by 
asserting </FONT><BR><FONT size=2>&gt; nonRerpuidation or</FONT> <BR><FONT 
size=2>&gt; &gt; &gt; &gt; &gt;&gt;digitalSignature.</FONT> <BR><FONT 
size=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
&gt;&gt;Of course, if a key pair is used for multiple purposes,</FONT> <BR><FONT 
size=2>&gt; &gt; multiple key</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
&gt;&gt;usages may be asserted.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
&gt;&gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;In each of these 
cases, the basic constraints extension</FONT> <BR><FONT size=2>&gt; &gt; also 
appears in</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;the certificate 
and asserts that the subject is a CA.</FONT> <BR><FONT size=2>&gt; &gt; &gt; 
&gt; &gt;&gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;LDAP 
Schema</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT> <BR><FONT 
size=2>&gt; &gt; &gt; &gt; &gt;&gt;All certificates issued to CAs would be 
considered CA</FONT> <BR><FONT size=2>&gt; &gt; certificates since</FONT> 
<BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;the basic constraints extension is 
present and asserts</FONT> <BR><FONT size=2>&gt; &gt; that the subject</FONT> 
<BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;is a CA.&nbsp; As a result, each of 
these could appear in</FONT> <BR><FONT size=2>&gt; &gt; the cACertificate</FONT> 
<BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;attribute or crossCertificatePair 
attribute.&nbsp; They</FONT> <BR><FONT size=2>&gt; &gt; would *not* appear 
in</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;the userCertificate 
attribute.&nbsp; (That would include all</FONT> <BR><FONT size=2>&gt; &gt; types 
(a) through</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;(d) 
above).</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT> <BR><FONT 
size=2>&gt; &gt; &gt; &gt; &gt;&gt;------------------</FONT> <BR><FONT 
size=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
&gt;&gt;The implications of this strategy are as follows: (1)</FONT> <BR><FONT 
size=2>&gt; &gt; when a client is</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
&gt;&gt;searching for a CA certificate, they will not have to </FONT><BR><FONT 
size=2>&gt; check the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
&gt;&gt;userCertificate attribute; (2) the issuer can indicate</FONT> <BR><FONT 
size=2>&gt; &gt; that the subject</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
&gt;&gt;is a CA regardless of the key usage; and (3) minimal</FONT> <BR><FONT 
size=2>&gt; &gt; changes to the text</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
&gt;&gt;(my favorite!).</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
&gt;&gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;What do you 
think?</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT> <BR><FONT 
size=2>&gt; &gt; &gt; &gt; &gt;&gt;Thanks,</FONT> <BR><FONT size=2>&gt; &gt; 
&gt; &gt; &gt;&gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;Tim 
Polk</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT> <BR><FONT 
size=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
&gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT 
size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
</FONT><BR><FONT size=2>&gt; </FONT></P></BODY></HTML>

------_=_NextPart_001_01C0D3EE.A5514DA0--


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA08847 for <[e-mail]>; Thu, 3 May 2001 07:49:39 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA16986; Thu, 3 May 2001 16:49:28 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id QAA17254; Thu, 3 May 2001 16:49:01 +0200
Message-ID: <[e-mail]>
Date: Thu, 03 May 2001 16:49:04 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: "Housley, Russ" <[e-mail]>, [e-mail]
Subject: Re: delta CRLs
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Santosh,

Mails are crossing around, and are not necessarilly received in the same
order. :-)

You indicated "Also a minor technical change to your other sentence" in your
response to Russ:

 "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 or lower number
 as the base CRL."

What is a "delta CRL which contains a delta CRL indicator extension with
(...) lower number as the base CRL." If you pick this delta CRL then it is
missing some of the information. Unless you speak of the time T and compare
it with thisUpdate and nextUpdate this does not work.

You also said: " Please note that the delta CRL can always be applied to a
higher base than the one referenced in the delta CRL extension."

You now say "higher" in that sentence. This is even more confusing.

Please take note that the intent is to describe what is necessary to support
the "traditional scheme" and I got the feeling that you would like this
sentence to support a different scheme. On April 19, David Cooper provided
some explanations making some confusing between the numering of delta-CRLs
and the numbering of base CRLs. Thay have no relationships besides that the
numbers should always increase.

If I just re-use the text from David, then you get the effect he wanted
without the need to take advantage of any new sequential numbering. Here is
the corrected text:

" Suppose that delta-CRLs are issued once an hour. For example, suppose that
a base CRL, CRL number 5, was issued at midnight and that every hour for the
next 24 hours, delta-CRLs were issued with a BaseCRLNumber of 5. If a
relying party performs its first validation at 3:10am, it would the base CRL
issued at midnight and the delta-CRL issued at 3:00am (e.g. CRL number 28).
It would combine these to construct the freshest CRL.

A few hours later, at 6:30am, the relying party performs another validation.
The relying party has, in its local cache, the CRL which it constructed at
3:10am. It wants to update the information in its local case to based on the
newly available revocation information. So, it obtains the latest delta-CRL.
This delta-CRL has a CRL number of 42 and a BaseCRLnumber of 5. Since
it has a BaseCRLNumber of 5, the delta-CRL provides status information for
all certificates whose status has changed since CRL number 5 was issued
(midnight). So, clearly the delta-CRL provides status information for all
certificates whose status has changed since 3:00am when CRL number 28 was
issued. Thus, the relying party can combine the delta-CRL with its locally
cached version of the CRL which it constructed at 3:10am to obtain the
freshest CRL."

So the addition you were proposing is not adequate. If we were going to
support variations beyond the traditional scheme, this should be in a
separate sentence.

Regards,

Denis


Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA08342 for <[e-mail]>; Thu, 3 May 2001 07:41:28 -0700 (PDT)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <J432Y2B4>; Thu, 3 May 2001 10:40:57 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Tom Gindin'" <[e-mail]>, Sharon Boeyen <[e-mail]>
Cc: "'Tim Polk'" <[e-mail]>, Denis Pinkas <[e-mail]>, [e-mail]
Subject: RE: Basic constraints, key usage, and LDAP schema
Date: Thu, 3 May 2001 10:34:42 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D3DE.30CBFFD0"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D3DE.30CBFFD0
Content-Type: text/plain

I see your point - I was missing the point that they are self-issued and was

thinking of the case where you are delegating authority to an indirect 
issuer. In the indirect case the cert would need to be in the cross-cert
pairs
attribute and may also appear in the caCerts attribute.

On the self issued ones, why are they needed at all? Why would a CA issue 
a cert to itself indicating that it can sign CRLs? Why do we need that?

Sharon

> -----Original Message-----
> From: Tom Gindin [mailto:[e-mail]]
> Sent: Wednesday, May 02, 2001 5:43 PM
> To: Sharon Boeyen
> Cc: 'Tim Polk'; Denis Pinkas; [e-mail]
> Subject: RE: Basic constraints, key usage, and LDAP schema
> 
> 
> 
>      In the current draft of X.509v4, "self-issued" means something
> different than "self-signed".  "self-issued" appears to be 
> the condition
> "the certificate's subject name can be matched to its own issuer name,
> which is that of a CA", while "self-signed" is that with the added
> condition "the certificate signature is verifiable with the public key
> contained in the message".  Most of these CRL signing certificates are
> "self-issued" in this sense, although not "self-signed".
>      One other reason why such CRL signing certificates would 
> legitimately
> not go into the CC Pair attribute would be that there is no 
> other directory
> entry where the CA certificate to verify the signature on 
> this certificate
> could be found, unlike any other certificates in CC Pair.
>      Lastly, if a CRL signing certificate were issued by a CA 
> certificate
> with the same DN, it would certainly belong in the same realm, if that
> concept has any meaning at all.
> 
>           Tom Gindin
> 
> 
> Sharon Boeyen <[e-mail]> on 05/02/2001 04:05:54 PM
> 
> To:   "'Tim Polk'" <[e-mail]>, Denis Pinkas
>       <[e-mail]>
> cc:   [e-mail]
> Subject:  RE: Basic constraints, key usage, and LDAP schema
> 
> 
> Hi Tim,
> 
> 
> I just want to clarify the directory attributes. All certs 
> that are not
> self issued must go in the cross certificates attribute. All 
> self issued
> certs must go in the caCertificates attribute. A subset of 
> the certificates
> in the cross certificate pairs attributes may also be present in the
> caCertificates attribute (those issued within the same realm, 
> a term left
> undefined). Lets not go back down that rathole :-) The two 
> attributes are
> not interchangeable. Given that the certs you are talking 
> about are not
> self issued then they must go in the cross certificate pairs 
> attribute and
> may also be placed in the caCertificate attribute if issued 
> within the same
> realm.
> 
> 
> Sharon
> 
> 
> > -----Original Message-----
> > From: Tim Polk [mailto:[e-mail]]
> > Sent: Wednesday, May 02, 2001 10:43 AM
> > To: Denis Pinkas
> > Cc: [e-mail]
> > Subject: Re: Basic constraints, key usage, and LDAP schema
> >
> >
> > Denis,
> >
> > These messages have been flying fast and furious under several topic
> > lines.  I don't believe I caught them all either!  As they
> > are all related,
> > it is difficult to resolve the issues one-by-one.  The
> > separate solutions
> > may combine to present new problems.  That was the rationale
> > for the single
> > comprehensive posting.
> >
> > The real problems, in my opinion, are as follows:
> >
> > (1) Consider a PKIX client, searching for a certificate to 
> validate a
> > particular CRL.  Under 2459, the client cannot guess whether
> > the basic
> > constraints extension will be present with the CA bit asserted.
> >
> > If the key used to validate the CRL is also used to validate
> > certificates,
> > it will have basic constraints and assert cA is TRUE.  In
> > this case, the
> > certificate should be in the ca certificate attribute (or
> > perhaps the cross
> > certificate pairs).
> >
> > If the key is not used to validate certificates, basic
> > constraints will be
> > omitted and the certificate will be stored in the user
> > certificate attribute.
> >
> > (2) If a PKIX client wishes to communicate with a CA for certificate
> > management purposes (e.g., to request a new certificate, request
> > revocation, or perhaps centralized key generation for key
> > escrow scenarios)
> > the client will need to validate the CA's signature and
> > perhaps make use of
> > the CA's key management key.  If the keys used for these
> > transactions are
> > also used to sign PKCs, the certs will be in the CA certificate
> > attribute.  If the keys used for these purposes are not used
> > to sign PKCs,
> > there will be no indication that this entity is a CA and the
> > certs will be
> > stored in the user certificate attribute.
> >
> > As above, the PKIX client does not know where to look for these
> > certificates.  Where they are not used to sign PKCs, there 
> will be no
> > indication in the certificate that this entity is a CA at all.
> >
> > (3) The attribute certificate profile is very clear regarding
> > AC issuers
> > versus PKC issuers. Section 4.5 states "the AC issuer's PKC
> > MUST NOT have a
> > basicConstraints extension with the cA BOOLEAN set to TRUE."
> >
> > However, the combination of RFC 2459 and the attribute
> > certificate profile
> > does not permit an issuer to specify whether a subject can 
> issue CRLs
> > for  PKCs, ACs, or both.  This would provide us with an
> > analogous solution:
> > if the CA bit is not asserted, but the cRLSign bit is set in
> > key usage, the
> > subject is only permitted to issue CRLs for ACs.
> >
> > To be honest, (3) is the least compelling problem.  The CA
> > must explicitly
> > name an indirect CRL issuer in PKCs it issues *anyway*, so
> > the CA bit isn't
> > a big security issue.  Still, I think it is nice to supply
> > clients with
> > this information.
> >
> > Anyway, I hope this clarifies things a bit.  My goal was to
> > resolve all
> > three problems simultaneously and consistently.
> >
> > Thanks,
> >
> > Tim Polk
> >
> > At 03:14 PM 5/2/01 +0200, Denis Pinkas wrote:
> > >Tim,
> > >
> > >I stayed silent on that topic and it is quite hard to catch
> > all the e-mails
> > >related to it. I certainly missed or skipped missed some of them.
> > >
> > > > Terry,
> > > >
> > > > I think it would be best if the client did not need to check the
> > > > userCertificate attribute to validate CRLs.  This adds
> > complexity without
> > > > any real benefit (in my opinion.)  I have included some
> > proposed text for
> > > > the first paragraph of section 4.2.1.10 (basic
> > constraints) that would
> > > > clarify the issue.
> > > >
> > > > ----------------proposed text for first paragraph of
> > > 4.2.1.10----------------
> > > >
> > > > The basic constraints extension identifies whether the
> > subject of the
> > > > certificate is a CA and the maximum depth of valid
> > certification paths that
> > > > include this certificate.  A subject is considered a CA
> > if it issues public
> > > > key certificates or CRLs that describe the revocation
> > status of public key
> > > > certificates.
> > > >
> > > > ----------------------end proposed text
> > > > What do you think?
> > >
> > >RFC 2459 only said:
> > >
> > >    The basic constraints extension identifies whether the
> > subject of the
> > >    certificate is a CA and how deep a certification path may exist
> > >    through that CA.
> > >
> > >However, according to the new text a "CRL Issuer" is now
> > also a "CA": " A
> > >subject is considered a CA if it issues public key
> > certificates or CRLs that
> > >describe the revocation status of public key certificates."
> > >
> > >The current text of new-part1-06 also goes in the same direction.
> > >
> > >    The cA bit indicates if the certified public key may be used to
> > >    verify signatures on other certificates.  If the cA bit
> > is asserted,
> > >    then either the keyCertSign bit or the cRLSign bit in
> > the key usage
> > >    extension (see 4.2.1.3) MUST also be asserted. If the cA
> > bit is not
> > >    asserted, then both the keyCertSign bit and the cRLSign
> > in the key
> > >    usage extension MUST NOT be asserted.
> > >
> > >This seems quite strange. A CRL issuer is just one way to
> > make available
> > >revocation status information. OCSP is another way. RFC 2560 says:
> > >
> > >    OCSP signing delegation SHALL be designated by the
> > >    inclusion of id-kp-OCSPSigning in an extendedKeyUsage 
> certificate
> > >    extension included in the OCSP response signer's
> > certificate.  This
> > >    certificate MUST be issued directly by the CA that issued the
> > >    certificate in question.
> > >
> > >If a "CRL issuer" is a "CA", why should an OCSP responder
> > designated by a CA
> > >not also be a "CA" ?
> > >
> > >As far as I remember, originally the cA boolean in the basic
> > constraints
> > >extension only allowed to make the difference between leaf
> > certificates and
> > >CA certificates. This boolean now seems to be be used with a
> > different
> > >meaning (and, maybe, we should change its meaning - not 
> the syntax).
> > >
> > >Could someone say again, why that change was requested and
> > what are the real
> > >benefits of that change ?
> > >
> > >In other words, could someone say again what the problem was ? :-)
> > >
> > >Thanks,
> > >
> > >Denis
> > >
> > > > Thanks,
> > > >
> > > > Tim Polk
> > > >
> > > > At 01:41 PM 5/1/01 -0700, Terry Hayes wrote:
> > > > >Tim,
> > > > >
> > > > >I agree with your proposed solution.  As you have said,
> > it separates the
> > > > >semantics of the two extensions, and simplifies the
> > rules for the LDAP
> > > schema.
> > > > >
> > > > >There is one remaining point to address, and I believe
> > it may be the main
> > > > >point of discussion in the current thread.
> > > > >
> > > > >When a CA uses the CRLDP extension to designate another
> > entity to be the
> > > > >source for revocation information about some of its
> > certificates, should
> > > > >that entity  have a "CA" certificate (with appropriate
> > basicConstraints
> > > > >extension)?  I'm *not* suggesting that a
> > basicConstraints extension is
> > > > >necessary for the entity to be authorized to sign the
> > CRL.  Instead, the
> > > > >problem is that clients that are trying to locate the
> > certificate will not
> > > > >know whether they should look in the cACertificate
> > attribute or the
> > > > >userCertificate attribute to find the appropriate certificate.
> > > > >
> > > > >To solve this, we can suggest that cACertificate be
> > searched first,
> > > > >followed by userCertificate, or we can require that
> > designated entities
> > > > >must always be a "CA", and the client can safely skip
> > the userCertificate
> > > > >attribute.  This is a question of searching the
> > directory only, and does
> > > > >not suggest changing your assertion that any set of bits
> > may be set in the
> > > > >keyUsage extension of "CA" certificates.
> > > > >
> > > > >Terry
> > > > >
> > > > >Tim Polk wrote:
> > > > >
> > > > >>Folks,
> > > > >>
> > > > >>I have been reading the email messages on the list about the
> > > > >>relationships between basic constraints, key usage, and
> > the schema.
> > > > >>After mulling over the problem.  I would like to
> > propose a solution - the
> > > > >>only solution, as far as I can tell...
> > > > >>
> > > > >>The solution is to simplify and separate the semantics
> > of the basic
> > > > >>constraints and key usage extension.  This has positive
> > implications for
> > > > >>the PKIX LDAP schema as well.
> > > > >>
> > > > >>Basic Constraints
> > > > >>
> > > > >>As stated in the current text for Basic Constraints (in
> > 2459):  "The
> > > > >>basic constraints extension identifies whether the
> > subject of the
> > > > >>certificate is a CA and how deep a certification path
> > may exist through
> > > > >>that CA."
> > > > >>
> > > > >>I believe this is the right semantics, and that basic
> > constraints should
> > > > >>be included and cA should be asserted in *any*
> > certificate issued to a
> > > > >>CA, regardless of the type or role associated with the
> > public key in the
> > > > >>certificate.
> > > > >>
> > > > >>Key Usage
> > > > >>
> > > > >>The issuer should use the Key Usage extension to
> > disambiguate the
> > > > >>subject's key pairs:
> > > > >>(a) The issuer indicates this public key may be used to
> > verify the
> > > > >>signature on a public key certificate by asserting
> > keyCertSign.  (b) The
> > > > >>issuer indicates this public key may be used to verify
> > the signature on
> > > > >>CRLs by asserting cRLSign.  (c) The issuer indicates
> > that this public key
> > > > >>may be used to establish symmetric keys with the
> > subject by asserting
> > > > >>either keyEncipherment or keyAgreement.  (d) The issuer
> > indicates that
> > > > >>this public key may be used to verify signatures on
> > objects other than
> > > > >>public key certificates and CRLs by asserting 
> nonRerpuidation or
> > > > >>digitalSignature.
> > > > >>
> > > > >>Of course, if a key pair is used for multiple purposes,
> > multiple key
> > > > >>usages may be asserted.
> > > > >>
> > > > >>In each of these cases, the basic constraints extension
> > also appears in
> > > > >>the certificate and asserts that the subject is a CA.
> > > > >>
> > > > >>LDAP Schema
> > > > >>
> > > > >>All certificates issued to CAs would be considered CA
> > certificates since
> > > > >>the basic constraints extension is present and asserts
> > that the subject
> > > > >>is a CA.  As a result, each of these could appear in
> > the cACertificate
> > > > >>attribute or crossCertificatePair attribute.  They
> > would *not* appear in
> > > > >>the userCertificate attribute.  (That would include all
> > types (a) through
> > > > >>(d) above).
> > > > >>
> > > > >>------------------
> > > > >>
> > > > >>The implications of this strategy are as follows: (1)
> > when a client is
> > > > >>searching for a CA certificate, they will not have to 
> check the
> > > > >>userCertificate attribute; (2) the issuer can indicate
> > that the subject
> > > > >>is a CA regardless of the key usage; and (3) minimal
> > changes to the text
> > > > >>(my favorite!).
> > > > >>
> > > > >>What do you think?
> > > > >>
> > > > >>Thanks,
> > > > >>
> > > > >>Tim Polk
> > > > >>
> > > > >>
> > > > >
> > > > >
> >
> 
> 
> 

------_=_NextPart_001_01C0D3DE.30CBFFD0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: Basic constraints, key usage, and LDAP schema</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>I see your point - I was missing the point that they are self-issued and was </FONT>
<BR><FONT SIZE=2>thinking of the case where you are delegating authority to an indirect </FONT>
<BR><FONT SIZE=2>issuer. In the indirect case the cert would need to be in the cross-cert pairs</FONT>
<BR><FONT SIZE=2>attribute and may also appear in the caCerts attribute.</FONT>
</P>

<P><FONT SIZE=2>On the self issued ones, why are they needed at all? Why would a CA issue </FONT>
<BR><FONT SIZE=2>a cert to itself indicating that it can sign CRLs? Why do we need that?</FONT>
</P>

<P><FONT SIZE=2>Sharon</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Tom Gindin [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Wednesday, May 02, 2001 5:43 PM</FONT>
<BR><FONT SIZE=2>&gt; To: Sharon Boeyen</FONT>
<BR><FONT SIZE=2>&gt; Cc: 'Tim Polk'; Denis Pinkas; [e-mail]</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: Basic constraints, key usage, and LDAP schema</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In the current draft of X.509v4, &quot;self-issued&quot; means something</FONT>
<BR><FONT SIZE=2>&gt; different than &quot;self-signed&quot;.&nbsp; &quot;self-issued&quot; appears to be </FONT>
<BR><FONT SIZE=2>&gt; the condition</FONT>
<BR><FONT SIZE=2>&gt; &quot;the certificate's subject name can be matched to its own issuer name,</FONT>
<BR><FONT SIZE=2>&gt; which is that of a CA&quot;, while &quot;self-signed&quot; is that with the added</FONT>
<BR><FONT SIZE=2>&gt; condition &quot;the certificate signature is verifiable with the public key</FONT>
<BR><FONT SIZE=2>&gt; contained in the message&quot;.&nbsp; Most of these CRL signing certificates are</FONT>
<BR><FONT SIZE=2>&gt; &quot;self-issued&quot; in this sense, although not &quot;self-signed&quot;.</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; One other reason why such CRL signing certificates would </FONT>
<BR><FONT SIZE=2>&gt; legitimately</FONT>
<BR><FONT SIZE=2>&gt; not go into the CC Pair attribute would be that there is no </FONT>
<BR><FONT SIZE=2>&gt; other directory</FONT>
<BR><FONT SIZE=2>&gt; entry where the CA certificate to verify the signature on </FONT>
<BR><FONT SIZE=2>&gt; this certificate</FONT>
<BR><FONT SIZE=2>&gt; could be found, unlike any other certificates in CC Pair.</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Lastly, if a CRL signing certificate were issued by a CA </FONT>
<BR><FONT SIZE=2>&gt; certificate</FONT>
<BR><FONT SIZE=2>&gt; with the same DN, it would certainly belong in the same realm, if that</FONT>
<BR><FONT SIZE=2>&gt; concept has any meaning at all.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tom Gindin</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Sharon Boeyen &lt;[e-mail]&gt; on 05/02/2001 04:05:54 PM</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; To:&nbsp;&nbsp; &quot;'Tim Polk'&quot; &lt;[e-mail]&gt;, Denis Pinkas</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=2>&gt; cc:&nbsp;&nbsp; [e-mail]</FONT>
<BR><FONT SIZE=2>&gt; Subject:&nbsp; RE: Basic constraints, key usage, and LDAP schema</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi Tim,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I just want to clarify the directory attributes. All certs </FONT>
<BR><FONT SIZE=2>&gt; that are not</FONT>
<BR><FONT SIZE=2>&gt; self issued must go in the cross certificates attribute. All </FONT>
<BR><FONT SIZE=2>&gt; self issued</FONT>
<BR><FONT SIZE=2>&gt; certs must go in the caCertificates attribute. A subset of </FONT>
<BR><FONT SIZE=2>&gt; the certificates</FONT>
<BR><FONT SIZE=2>&gt; in the cross certificate pairs attributes may also be present in the</FONT>
<BR><FONT SIZE=2>&gt; caCertificates attribute (those issued within the same realm, </FONT>
<BR><FONT SIZE=2>&gt; a term left</FONT>
<BR><FONT SIZE=2>&gt; undefined). Lets not go back down that rathole :-) The two </FONT>
<BR><FONT SIZE=2>&gt; attributes are</FONT>
<BR><FONT SIZE=2>&gt; not interchangeable. Given that the certs you are talking </FONT>
<BR><FONT SIZE=2>&gt; about are not</FONT>
<BR><FONT SIZE=2>&gt; self issued then they must go in the cross certificate pairs </FONT>
<BR><FONT SIZE=2>&gt; attribute and</FONT>
<BR><FONT SIZE=2>&gt; may also be placed in the caCertificate attribute if issued </FONT>
<BR><FONT SIZE=2>&gt; within the same</FONT>
<BR><FONT SIZE=2>&gt; realm.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Sharon</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; &gt; From: Tim Polk [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>&gt; &gt; Sent: Wednesday, May 02, 2001 10:43 AM</FONT>
<BR><FONT SIZE=2>&gt; &gt; To: Denis Pinkas</FONT>
<BR><FONT SIZE=2>&gt; &gt; Cc: [e-mail]</FONT>
<BR><FONT SIZE=2>&gt; &gt; Subject: Re: Basic constraints, key usage, and LDAP schema</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Denis,</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; These messages have been flying fast and furious under several topic</FONT>
<BR><FONT SIZE=2>&gt; &gt; lines.&nbsp; I don't believe I caught them all either!&nbsp; As they</FONT>
<BR><FONT SIZE=2>&gt; &gt; are all related,</FONT>
<BR><FONT SIZE=2>&gt; &gt; it is difficult to resolve the issues one-by-one.&nbsp; The</FONT>
<BR><FONT SIZE=2>&gt; &gt; separate solutions</FONT>
<BR><FONT SIZE=2>&gt; &gt; may combine to present new problems.&nbsp; That was the rationale</FONT>
<BR><FONT SIZE=2>&gt; &gt; for the single</FONT>
<BR><FONT SIZE=2>&gt; &gt; comprehensive posting.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; The real problems, in my opinion, are as follows:</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; (1) Consider a PKIX client, searching for a certificate to </FONT>
<BR><FONT SIZE=2>&gt; validate a</FONT>
<BR><FONT SIZE=2>&gt; &gt; particular CRL.&nbsp; Under 2459, the client cannot guess whether</FONT>
<BR><FONT SIZE=2>&gt; &gt; the basic</FONT>
<BR><FONT SIZE=2>&gt; &gt; constraints extension will be present with the CA bit asserted.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; If the key used to validate the CRL is also used to validate</FONT>
<BR><FONT SIZE=2>&gt; &gt; certificates,</FONT>
<BR><FONT SIZE=2>&gt; &gt; it will have basic constraints and assert cA is TRUE.&nbsp; In</FONT>
<BR><FONT SIZE=2>&gt; &gt; this case, the</FONT>
<BR><FONT SIZE=2>&gt; &gt; certificate should be in the ca certificate attribute (or</FONT>
<BR><FONT SIZE=2>&gt; &gt; perhaps the cross</FONT>
<BR><FONT SIZE=2>&gt; &gt; certificate pairs).</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; If the key is not used to validate certificates, basic</FONT>
<BR><FONT SIZE=2>&gt; &gt; constraints will be</FONT>
<BR><FONT SIZE=2>&gt; &gt; omitted and the certificate will be stored in the user</FONT>
<BR><FONT SIZE=2>&gt; &gt; certificate attribute.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; (2) If a PKIX client wishes to communicate with a CA for certificate</FONT>
<BR><FONT SIZE=2>&gt; &gt; management purposes (e.g., to request a new certificate, request</FONT>
<BR><FONT SIZE=2>&gt; &gt; revocation, or perhaps centralized key generation for key</FONT>
<BR><FONT SIZE=2>&gt; &gt; escrow scenarios)</FONT>
<BR><FONT SIZE=2>&gt; &gt; the client will need to validate the CA's signature and</FONT>
<BR><FONT SIZE=2>&gt; &gt; perhaps make use of</FONT>
<BR><FONT SIZE=2>&gt; &gt; the CA's key management key.&nbsp; If the keys used for these</FONT>
<BR><FONT SIZE=2>&gt; &gt; transactions are</FONT>
<BR><FONT SIZE=2>&gt; &gt; also used to sign PKCs, the certs will be in the CA certificate</FONT>
<BR><FONT SIZE=2>&gt; &gt; attribute.&nbsp; If the keys used for these purposes are not used</FONT>
<BR><FONT SIZE=2>&gt; &gt; to sign PKCs,</FONT>
<BR><FONT SIZE=2>&gt; &gt; there will be no indication that this entity is a CA and the</FONT>
<BR><FONT SIZE=2>&gt; &gt; certs will be</FONT>
<BR><FONT SIZE=2>&gt; &gt; stored in the user certificate attribute.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; As above, the PKIX client does not know where to look for these</FONT>
<BR><FONT SIZE=2>&gt; &gt; certificates.&nbsp; Where they are not used to sign PKCs, there </FONT>
<BR><FONT SIZE=2>&gt; will be no</FONT>
<BR><FONT SIZE=2>&gt; &gt; indication in the certificate that this entity is a CA at all.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; (3) The attribute certificate profile is very clear regarding</FONT>
<BR><FONT SIZE=2>&gt; &gt; AC issuers</FONT>
<BR><FONT SIZE=2>&gt; &gt; versus PKC issuers. Section 4.5 states &quot;the AC issuer's PKC</FONT>
<BR><FONT SIZE=2>&gt; &gt; MUST NOT have a</FONT>
<BR><FONT SIZE=2>&gt; &gt; basicConstraints extension with the cA BOOLEAN set to TRUE.&quot;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; However, the combination of RFC 2459 and the attribute</FONT>
<BR><FONT SIZE=2>&gt; &gt; certificate profile</FONT>
<BR><FONT SIZE=2>&gt; &gt; does not permit an issuer to specify whether a subject can </FONT>
<BR><FONT SIZE=2>&gt; issue CRLs</FONT>
<BR><FONT SIZE=2>&gt; &gt; for&nbsp; PKCs, ACs, or both.&nbsp; This would provide us with an</FONT>
<BR><FONT SIZE=2>&gt; &gt; analogous solution:</FONT>
<BR><FONT SIZE=2>&gt; &gt; if the CA bit is not asserted, but the cRLSign bit is set in</FONT>
<BR><FONT SIZE=2>&gt; &gt; key usage, the</FONT>
<BR><FONT SIZE=2>&gt; &gt; subject is only permitted to issue CRLs for ACs.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; To be honest, (3) is the least compelling problem.&nbsp; The CA</FONT>
<BR><FONT SIZE=2>&gt; &gt; must explicitly</FONT>
<BR><FONT SIZE=2>&gt; &gt; name an indirect CRL issuer in PKCs it issues *anyway*, so</FONT>
<BR><FONT SIZE=2>&gt; &gt; the CA bit isn't</FONT>
<BR><FONT SIZE=2>&gt; &gt; a big security issue.&nbsp; Still, I think it is nice to supply</FONT>
<BR><FONT SIZE=2>&gt; &gt; clients with</FONT>
<BR><FONT SIZE=2>&gt; &gt; this information.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Anyway, I hope this clarifies things a bit.&nbsp; My goal was to</FONT>
<BR><FONT SIZE=2>&gt; &gt; resolve all</FONT>
<BR><FONT SIZE=2>&gt; &gt; three problems simultaneously and consistently.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Thanks,</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Tim Polk</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; At 03:14 PM 5/2/01 +0200, Denis Pinkas wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;Tim,</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;I stayed silent on that topic and it is quite hard to catch</FONT>
<BR><FONT SIZE=2>&gt; &gt; all the e-mails</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;related to it. I certainly missed or skipped missed some of them.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; Terry,</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; I think it would be best if the client did not need to check the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; userCertificate attribute to validate CRLs.&nbsp; This adds</FONT>
<BR><FONT SIZE=2>&gt; &gt; complexity without</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; any real benefit (in my opinion.)&nbsp; I have included some</FONT>
<BR><FONT SIZE=2>&gt; &gt; proposed text for</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; the first paragraph of section 4.2.1.10 (basic</FONT>
<BR><FONT SIZE=2>&gt; &gt; constraints) that would</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; clarify the issue.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; ----------------proposed text for first paragraph of</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; 4.2.1.10----------------</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; The basic constraints extension identifies whether the</FONT>
<BR><FONT SIZE=2>&gt; &gt; subject of the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; certificate is a CA and the maximum depth of valid</FONT>
<BR><FONT SIZE=2>&gt; &gt; certification paths that</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; include this certificate.&nbsp; A subject is considered a CA</FONT>
<BR><FONT SIZE=2>&gt; &gt; if it issues public</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; key certificates or CRLs that describe the revocation</FONT>
<BR><FONT SIZE=2>&gt; &gt; status of public key</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; certificates.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; ----------------------end proposed text</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; What do you think?</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;RFC 2459 only said:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; The basic constraints extension identifies whether the</FONT>
<BR><FONT SIZE=2>&gt; &gt; subject of the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; certificate is a CA and how deep a certification path may exist</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; through that CA.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;However, according to the new text a &quot;CRL Issuer&quot; is now</FONT>
<BR><FONT SIZE=2>&gt; &gt; also a &quot;CA&quot;: &quot; A</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;subject is considered a CA if it issues public key</FONT>
<BR><FONT SIZE=2>&gt; &gt; certificates or CRLs that</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;describe the revocation status of public key certificates.&quot;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;The current text of new-part1-06 also goes in the same direction.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; The cA bit indicates if the certified public key may be used to</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; verify signatures on other certificates.&nbsp; If the cA bit</FONT>
<BR><FONT SIZE=2>&gt; &gt; is asserted,</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; then either the keyCertSign bit or the cRLSign bit in</FONT>
<BR><FONT SIZE=2>&gt; &gt; the key usage</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; extension (see 4.2.1.3) MUST also be asserted. If the cA</FONT>
<BR><FONT SIZE=2>&gt; &gt; bit is not</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; asserted, then both the keyCertSign bit and the cRLSign</FONT>
<BR><FONT SIZE=2>&gt; &gt; in the key</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; usage extension MUST NOT be asserted.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;This seems quite strange. A CRL issuer is just one way to</FONT>
<BR><FONT SIZE=2>&gt; &gt; make available</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;revocation status information. OCSP is another way. RFC 2560 says:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; OCSP signing delegation SHALL be designated by the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; inclusion of id-kp-OCSPSigning in an extendedKeyUsage </FONT>
<BR><FONT SIZE=2>&gt; certificate</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; extension included in the OCSP response signer's</FONT>
<BR><FONT SIZE=2>&gt; &gt; certificate.&nbsp; This</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; certificate MUST be issued directly by the CA that issued the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; certificate in question.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;If a &quot;CRL issuer&quot; is a &quot;CA&quot;, why should an OCSP responder</FONT>
<BR><FONT SIZE=2>&gt; &gt; designated by a CA</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;not also be a &quot;CA&quot; ?</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;As far as I remember, originally the cA boolean in the basic</FONT>
<BR><FONT SIZE=2>&gt; &gt; constraints</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;extension only allowed to make the difference between leaf</FONT>
<BR><FONT SIZE=2>&gt; &gt; certificates and</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;CA certificates. This boolean now seems to be be used with a</FONT>
<BR><FONT SIZE=2>&gt; &gt; different</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;meaning (and, maybe, we should change its meaning - not </FONT>
<BR><FONT SIZE=2>&gt; the syntax).</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;Could someone say again, why that change was requested and</FONT>
<BR><FONT SIZE=2>&gt; &gt; what are the real</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;benefits of that change ?</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;In other words, could someone say again what the problem was ? :-)</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;Thanks,</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;Denis</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; Thanks,</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; Tim Polk</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; At 01:41 PM 5/1/01 -0700, Terry Hayes wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;Tim,</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;I agree with your proposed solution.&nbsp; As you have said,</FONT>
<BR><FONT SIZE=2>&gt; &gt; it separates the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;semantics of the two extensions, and simplifies the</FONT>
<BR><FONT SIZE=2>&gt; &gt; rules for the LDAP</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; schema.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;There is one remaining point to address, and I believe</FONT>
<BR><FONT SIZE=2>&gt; &gt; it may be the main</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;point of discussion in the current thread.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;When a CA uses the CRLDP extension to designate another</FONT>
<BR><FONT SIZE=2>&gt; &gt; entity to be the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;source for revocation information about some of its</FONT>
<BR><FONT SIZE=2>&gt; &gt; certificates, should</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;that entity&nbsp; have a &quot;CA&quot; certificate (with appropriate</FONT>
<BR><FONT SIZE=2>&gt; &gt; basicConstraints</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;extension)?&nbsp; I'm *not* suggesting that a</FONT>
<BR><FONT SIZE=2>&gt; &gt; basicConstraints extension is</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;necessary for the entity to be authorized to sign the</FONT>
<BR><FONT SIZE=2>&gt; &gt; CRL.&nbsp; Instead, the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;problem is that clients that are trying to locate the</FONT>
<BR><FONT SIZE=2>&gt; &gt; certificate will not</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;know whether they should look in the cACertificate</FONT>
<BR><FONT SIZE=2>&gt; &gt; attribute or the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;userCertificate attribute to find the appropriate certificate.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;To solve this, we can suggest that cACertificate be</FONT>
<BR><FONT SIZE=2>&gt; &gt; searched first,</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;followed by userCertificate, or we can require that</FONT>
<BR><FONT SIZE=2>&gt; &gt; designated entities</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;must always be a &quot;CA&quot;, and the client can safely skip</FONT>
<BR><FONT SIZE=2>&gt; &gt; the userCertificate</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;attribute.&nbsp; This is a question of searching the</FONT>
<BR><FONT SIZE=2>&gt; &gt; directory only, and does</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;not suggest changing your assertion that any set of bits</FONT>
<BR><FONT SIZE=2>&gt; &gt; may be set in the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;keyUsage extension of &quot;CA&quot; certificates.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;Terry</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;Tim Polk wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;Folks,</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;I have been reading the email messages on the list about the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;relationships between basic constraints, key usage, and</FONT>
<BR><FONT SIZE=2>&gt; &gt; the schema.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;After mulling over the problem.&nbsp; I would like to</FONT>
<BR><FONT SIZE=2>&gt; &gt; propose a solution - the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;only solution, as far as I can tell...</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;The solution is to simplify and separate the semantics</FONT>
<BR><FONT SIZE=2>&gt; &gt; of the basic</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;constraints and key usage extension.&nbsp; This has positive</FONT>
<BR><FONT SIZE=2>&gt; &gt; implications for</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;the PKIX LDAP schema as well.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;Basic Constraints</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;As stated in the current text for Basic Constraints (in</FONT>
<BR><FONT SIZE=2>&gt; &gt; 2459):&nbsp; &quot;The</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;basic constraints extension identifies whether the</FONT>
<BR><FONT SIZE=2>&gt; &gt; subject of the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;certificate is a CA and how deep a certification path</FONT>
<BR><FONT SIZE=2>&gt; &gt; may exist through</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;that CA.&quot;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;I believe this is the right semantics, and that basic</FONT>
<BR><FONT SIZE=2>&gt; &gt; constraints should</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;be included and cA should be asserted in *any*</FONT>
<BR><FONT SIZE=2>&gt; &gt; certificate issued to a</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;CA, regardless of the type or role associated with the</FONT>
<BR><FONT SIZE=2>&gt; &gt; public key in the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;certificate.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;Key Usage</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;The issuer should use the Key Usage extension to</FONT>
<BR><FONT SIZE=2>&gt; &gt; disambiguate the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;subject's key pairs:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;(a) The issuer indicates this public key may be used to</FONT>
<BR><FONT SIZE=2>&gt; &gt; verify the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;signature on a public key certificate by asserting</FONT>
<BR><FONT SIZE=2>&gt; &gt; keyCertSign.&nbsp; (b) The</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;issuer indicates this public key may be used to verify</FONT>
<BR><FONT SIZE=2>&gt; &gt; the signature on</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;CRLs by asserting cRLSign.&nbsp; (c) The issuer indicates</FONT>
<BR><FONT SIZE=2>&gt; &gt; that this public key</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;may be used to establish symmetric keys with the</FONT>
<BR><FONT SIZE=2>&gt; &gt; subject by asserting</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;either keyEncipherment or keyAgreement.&nbsp; (d) The issuer</FONT>
<BR><FONT SIZE=2>&gt; &gt; indicates that</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;this public key may be used to verify signatures on</FONT>
<BR><FONT SIZE=2>&gt; &gt; objects other than</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;public key certificates and CRLs by asserting </FONT>
<BR><FONT SIZE=2>&gt; nonRerpuidation or</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;digitalSignature.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;Of course, if a key pair is used for multiple purposes,</FONT>
<BR><FONT SIZE=2>&gt; &gt; multiple key</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;usages may be asserted.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;In each of these cases, the basic constraints extension</FONT>
<BR><FONT SIZE=2>&gt; &gt; also appears in</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;the certificate and asserts that the subject is a CA.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;LDAP Schema</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;All certificates issued to CAs would be considered CA</FONT>
<BR><FONT SIZE=2>&gt; &gt; certificates since</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;the basic constraints extension is present and asserts</FONT>
<BR><FONT SIZE=2>&gt; &gt; that the subject</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;is a CA.&nbsp; As a result, each of these could appear in</FONT>
<BR><FONT SIZE=2>&gt; &gt; the cACertificate</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;attribute or crossCertificatePair attribute.&nbsp; They</FONT>
<BR><FONT SIZE=2>&gt; &gt; would *not* appear in</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;the userCertificate attribute.&nbsp; (That would include all</FONT>
<BR><FONT SIZE=2>&gt; &gt; types (a) through</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;(d) above).</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;------------------</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;The implications of this strategy are as follows: (1)</FONT>
<BR><FONT SIZE=2>&gt; &gt; when a client is</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;searching for a CA certificate, they will not have to </FONT>
<BR><FONT SIZE=2>&gt; check the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;userCertificate attribute; (2) the issuer can indicate</FONT>
<BR><FONT SIZE=2>&gt; &gt; that the subject</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;is a CA regardless of the key usage; and (3) minimal</FONT>
<BR><FONT SIZE=2>&gt; &gt; changes to the text</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;(my favorite!).</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;What do you think?</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;Thanks,</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;Tim Polk</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0D3DE.30CBFFD0--


Received: from e1.ny.us.ibm.com ([32.97.182.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA08016 for <[e-mail]>; Thu, 3 May 2001 07:38:56 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA482634; Thu, 3 May 2001 10:36:37 -0400
Received: from d02ml237.somers.hqregion.ibm.com (d02ml237.sby.ibm.com [9.45.4.171]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id KAA81102; Thu, 3 May 2001 10:33:02 -0400
Importance: Normal
Subject: RE: delta CRLs
To: Santosh Chokhani <[e-mail]>
Cc: "Housley, Russ" <[e-mail]>, Denis Pinkas <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Thu, 3 May 2001 10:33:39 -0400
X-MIMETrack: Serialize by Router on D02ML237/02/M/IBM(Release 5.0.7 |March 21, 2001) at 05/03/2001 10:38:06 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

     Why should PKIX drop the "hold" feature?  The only feature which
involves any extra work for the client is "removeFromCRL".  We might want
to make "removeFromCRL" optional to implement and suggest that CA's which
issue delta CRL's SHOULD not use the certificateHold and removeFromCRL
reason codes, but CA's which don't issue deltas aren't imposing any greater
difficulties on the client by using "hold", are they?

          Tom Gindin


Santosh Chokhani <[e-mail]> on 05/03/2001 09:23:56 AM

To:   "Housley, Russ" <[e-mail]>, Denis Pinkas
      <[e-mail]>
cc:   [e-mail]
Subject:  RE: delta CRLs


Russ: Please note minor word smithing for grammar and for technical
accuracy.  The sentences should read as follows.


"A delta CRL provides an update to a previously issued complete CRL.  A
delta CRL only includes entries for certificates that have changed status
since the complete CRL referenced in the delta CRL extension was issued."


Also a minor technical change to your other sentence:


"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 or lower number as
the base CRL."


Please note that the delta CRL can always be applied to a higher base than
the one referenced in the delta CRL extension.


I also agree with Russ that PKIX need not include the "hold" feature.
-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Wednesday, May 02, 2001 9:20 PM
To: Denis Pinkas
Cc: [e-mail]
Subject: Re: delta CRLs





Denis:


For the most part, the text that you provide is an improvement; however, I
MUST object to a few things.


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


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





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





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


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


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


What do others think?





>       (a) If a certificate was listed as revoked with revocation reason
>       certificateHold on a CRL (either a delta CRL or a CRL that is
>       complete for a given scope), and the hold is subsequently
>       released, the certificate must be listed with revocation reason
>       removeFromCRL until the next base CRL is issued.
>
>       Note: Should the certificate be subsequently revoked again for
>             one of the revocation reasons covered by the delta CRL,
>             then the certificate must be listed with the revocation
>             reason appropriate for the subsequent revocation.
>
>       (b) If the certificate was not removed from hold, but was
>       permanently revoked, then it must be listed as such on all
>       subsequent delta CRLs until the next base CRL is issued .
>
>    id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }
>
>    BaseCRLNumber ::= CRLNumber


Russ





Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA05435 for <[e-mail]>; Thu, 3 May 2001 06:59:35 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <KGKQ8DXF>; Thu, 3 May 2001 09:59:06 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Stephen Kent <[e-mail]>, Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Subject: RE: delta CRLs
Date: Thu, 3 May 2001 09:50:01 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D3D7.F3430920"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D3D7.F3430920
Content-Type: text/plain;
	charset="iso-8859-1"

Agreed.  Also, per Denis comment, the term "complete" should be replaced
with "base".

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Thursday, May 03, 2001 9:48 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: delta CRLs


Santosh,

if we want the grammar to be correct, then the second sentence should read:

"A delta CRL includes entries only for certificates that have changed 
status since the complete CRL referenced in the delta CRL extension 
was issued."

Steve

------_=_NextPart_001_01C0D3D7.F3430920
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: delta CRLs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Agreed.&nbsp; Also, per Denis comment, the term &quot;complete&quot; should be replaced with &quot;base&quot;.</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Stephen Kent [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>Sent: Thursday, May 03, 2001 9:48 AM</FONT>
<BR><FONT SIZE=2>To: Santosh Chokhani</FONT>
<BR><FONT SIZE=2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=2>Subject: RE: delta CRLs</FONT>
</P>
<BR>

<P><FONT SIZE=2>Santosh,</FONT>
</P>

<P><FONT SIZE=2>if we want the grammar to be correct, then the second sentence should read:</FONT>
</P>

<P><FONT SIZE=2>&quot;A delta CRL includes entries only for certificates that have changed </FONT>
<BR><FONT SIZE=2>status since the complete CRL referenced in the delta CRL extension </FONT>
<BR><FONT SIZE=2>was issued.&quot;</FONT>
</P>

<P><FONT SIZE=2>Steve</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0D3D7.F3430920--


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA04263 for <[e-mail]>; Thu, 3 May 2001 06:52:15 -0700 (PDT)
Received: from [128.33.4.39] (comsec.bbn.com [128.33.4.39]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id JAA20563; Thu, 3 May 2001 09:52:10 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010404b71711abe7a0@[128.33.4.39]>
In-Reply-To:  <[e-mail]>
References: <[e-mail]>
Date: Thu, 3 May 2001 09:48:19 -0400
To: Santosh Chokhani <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: delta CRLs
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Santosh,

if we want the grammar to be correct, then the second sentence should read:

"A delta CRL includes entries only for certificates that have changed 
status since the complete CRL referenced in the delta CRL extension 
was issued."

Steve


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA03939 for <[e-mail]>; Thu, 3 May 2001 06:50:26 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA16946; Thu, 3 May 2001 15:50:17 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id PAA13212; Thu, 3 May 2001 15:49:51 +0200
Message-ID: <[e-mail]>
Date: Thu, 03 May 2001 15:49:54 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail]
Subject: Re: delta CRLs
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Russ,

Thank you for your response.
 
> Denis:
> 
> For the most part, the text that you provide is an improvement; however, I
> MUST object to a few things.

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

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

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

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

Regards,

Denis

> 
> What do others think?
>
> >       (a) If a certificate was listed as revoked with revocation reason
> >       certificateHold on a CRL (either a delta CRL or a CRL that is
> >       complete for a given scope), and the hold is subsequently
> >       released, the certificate must be listed with revocation reason
> >       removeFromCRL until the next base CRL is issued.
> >
> >       Note: Should the certificate be subsequently revoked again for
> >             one of the revocation reasons covered by the delta CRL,
> >             then the certificate must be listed with the revocation
> >             reason appropriate for the subsequent revocation.
> >
> >       (b) If the certificate was not removed from hold, but was
> >       permanently revoked, then it must be listed as such on all
> >       subsequent delta CRLs until the next base CRL is issued .
> >
> >    id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }
> >
> >    BaseCRLNumber ::= CRLNumber
> 
> Russ


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA01412 for <[e-mail]>; Thu, 3 May 2001 06:33:30 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <KGKQ8DGM>; Thu, 3 May 2001 09:33:00 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: "Housley, Russ" <[e-mail]>, Denis Pinkas <[e-mail]>
Cc: [e-mail]
Subject: RE: delta CRLs
Date: Thu, 3 May 2001 09:23:56 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D3D4.4DEFC2E0"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D3D4.4DEFC2E0
Content-Type: text/plain;
	charset="iso-8859-1"

Russ: Please note minor word smithing for grammar and for technical
accuracy.  The sentences should read as follows.

"A delta CRL provides an update to a previously issued complete CRL.  A
delta CRL only includes entries for certificates that have changed status
since the complete CRL referenced in the delta CRL extension was issued."

Also a minor technical change to your other sentence:

"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 or lower number as
the base CRL."

Please note that the delta CRL can always be applied to a higher base than
the one referenced in the delta CRL extension.

I also agree with Russ that PKIX need not include the "hold" feature.
-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Wednesday, May 02, 2001 9:20 PM
To: Denis Pinkas
Cc: [e-mail]
Subject: Re: delta CRLs


Denis:

For the most part, the text that you provide is an improvement; however, I 
MUST object to a few things.

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

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


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


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

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

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

What do others think?


>       (a) If a certificate was listed as revoked with revocation reason
>       certificateHold on a CRL (either a delta CRL or a CRL that is
>       complete for a given scope), and the hold is subsequently
>       released, the certificate must be listed with revocation reason
>       removeFromCRL until the next base CRL is issued.
>
>       Note: Should the certificate be subsequently revoked again for
>             one of the revocation reasons covered by the delta CRL,
>             then the certificate must be listed with the revocation
>             reason appropriate for the subsequent revocation.
>
>       (b) If the certificate was not removed from hold, but was
>       permanently revoked, then it must be listed as such on all
>       subsequent delta CRLs until the next base CRL is issued .
>
>    id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }
>
>    BaseCRLNumber ::= CRLNumber

Russ

------_=_NextPart_001_01C0D3D4.4DEFC2E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: delta CRLs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Russ: Please note minor word smithing for grammar and =
for technical accuracy.&nbsp; The sentences should read as =
follows.</FONT>
</P>

<P><FONT SIZE=3D2>&quot;A delta CRL provides an update to a previously =
issued complete CRL.&nbsp; A delta CRL only includes entries for =
certificates that have changed status since the complete CRL referenced =
in the delta CRL extension was issued.&quot;</FONT></P>

<P><FONT SIZE=3D2>Also a minor technical change to your other =
sentence:</FONT>
</P>

<P><FONT SIZE=3D2>&quot;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 or lower number as the base CRL.&quot;</FONT></P>

<P><FONT SIZE=3D2>Please note that the delta CRL can always be applied =
to a higher base than the one referenced in the delta CRL =
extension.</FONT></P>

<P><FONT SIZE=3D2>I also agree with Russ that PKIX need not include the =
&quot;hold&quot; feature.</FONT>
<BR><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Housley, Russ [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, May 02, 2001 9:20 PM</FONT>
<BR><FONT SIZE=3D2>To: Denis Pinkas</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: delta CRLs</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Denis:</FONT>
</P>

<P><FONT SIZE=3D2>For the most part, the text that you provide is an =
improvement; however, I </FONT>
<BR><FONT SIZE=3D2>MUST object to a few things.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;5.2.4&nbsp; Delta CRL Indicator</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; The delta CRL indicator is a =
critical CRL extension that identifies</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; a CRL as being a delta CRL. A =
delta-CRL is a CRL that only provides</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; information about =
certificates who statuses have changed since the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; issuance of a specific, =
previously issued CRL. The use of delta</FONT>
</P>

<P><FONT SIZE=3D2>I do not like the second sentence any better than the =
original.&nbsp; How about:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; A delta CRL provides an updates a =
previously issued complete CRL.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; A delta CRL only includes entries =
for certificates that have changed</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; status since the complete CRL was =
issued.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; CRLs can significantly reduce =
network load and processing time in</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; some environments.&nbsp; =
Delta CRLs are generally much smaller than the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; CRLs they update, so =
applications that obtain delta CRLs consume</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; less network bandwidth than =
applications that obtain the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; corresponding complete =
CRLs.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; The delta CRL indicator =
extension contains a single value of type</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; BaseCRLNumber.&nbsp; This =
value identifies the CRL number of the base CRL</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; that was used as the =
foundation in the generation of this delta CRL.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; The referenced base CRL is a =
CRL that was explicitly issued as a CRL</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; that is complete for a given =
scope (e.g., a set of revocation reasons</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; or a particular distribution =
point.) The CRL containing the delta CRL</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; indicator extension contains =
all updates to the certificate</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; revocation status for that =
same scope.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; When a delta CRL is issued, =
it MUST cover the same set of reasons</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; and same set of certificates =
that were covered by the base CRL it</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; references.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; When a conforming CA issues a =
delta CRL, the delta CRL MUST include</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; a critical delta CRL =
indicator extension.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; An application can construct =
a CRL that is the most current for</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; a given scope, for a specific =
date, by retrieving the appropriate</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; base CRL for that scope, and =
combining it with a delta-CRL which</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; contains a Delta CRL =
Indicator equal to the cRLNumber of the base</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; CRL and where the date for =
which the construction is being made is</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; between thisUpdate and =
nextUpdate as indicated the delta CRL.</FONT>
</P>

<P><FONT SIZE=3D2>Can we focus on the most common case?&nbsp; How =
about:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; An application can construct an =
updated CRL by retrieving the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; appropriate base CRL for that =
scope, and combining it with a delta</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; CRL which contains a delta CRL =
indicator extension with the same</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; CRL number as the base =
CRL.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; Conforming implementations of =
this specification are not required</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; to implement the above =
algorithm, but MUST provide functionality</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; equivalent to the external =
behavior resulting from this procedure.</FONT>
</P>

<P><FONT SIZE=3D2>No.&nbsp; We do not presently require CRL =
implementation.&nbsp; The paragraph would </FONT>
<BR><FONT SIZE=3D2>seem to change that situation, and require CRL and =
delta CRL </FONT>
<BR><FONT SIZE=3D2>implelmentation.&nbsp; I suggest that the previous =
paragraph be omitted.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; CAs must ensure that =
application of a delta CRL to the referenced</FONT>
</P>

<P><FONT SIZE=3D2>Change &quot;CAs must&quot; to &quot;Conforming CAs =
that support CRLs and delta CRLs MUST&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; base revocation information =
accurately reflects the current status of</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; revocation.&nbsp; If a CA =
supports the certificateHold revocation reason</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; the following rules must be =
applied when generating delta CRLs:</FONT>
</P>

<P><FONT SIZE=3D2>I argued against the inclusion of support for =
certificate hold in RFC </FONT>
<BR><FONT SIZE=3D2>2459.&nbsp; Your text demonstrates the complexity of =
supporting this feature.&nbsp; I </FONT>
<BR><FONT SIZE=3D2>am quite concerned that this topic is being raised =
so late in the </FONT>
<BR><FONT SIZE=3D2>process.&nbsp; We are in WG Last Call ...&nbsp; =
[Denis, you will recall that you made </FONT>
<BR><FONT SIZE=3D2>a similar response to a comment that I made =
regarding TSP.]</FONT>
</P>

<P><FONT SIZE=3D2>I am still concerned about the significant complexity =
that certificate hold </FONT>
<BR><FONT SIZE=3D2>adds.&nbsp; It makes non-repudiation even more =
difficult.&nbsp; Further, I am not </FONT>
<BR><FONT SIZE=3D2>convinced that there is really a constituency for =
this feature.</FONT>
</P>

<P><FONT SIZE=3D2>I would be very happy if we changed the profile to =
say that conforming CAs </FONT>
<BR><FONT SIZE=3D2>MUST NOT use certificateHold.&nbsp; I would be =
happy&nbsp; if we changed the profile </FONT>
<BR><FONT SIZE=3D2>to say that conforming CAs SHOULD NOT use =
certificateHold. I would be quite </FONT>
<BR><FONT SIZE=3D2>upset if we require clients to support =
certificateHold in any manner other </FONT>
<BR><FONT SIZE=3D2>than simply revoked.&nbsp; (Note that section 5.3.2 =
provides the conformant </FONT>
<BR><FONT SIZE=3D2>application the alternative of simply rejecting the =
certificate.)</FONT>
</P>

<P><FONT SIZE=3D2>What do others think?</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (a) If a =
certificate was listed as revoked with revocation reason</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
certificateHold on a CRL (either a delta CRL or a CRL that is</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; complete =
for a given scope), and the hold is subsequently</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; released, =
the certificate must be listed with revocation reason</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
removeFromCRL until the next base CRL is issued.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Note: =
Should the certificate be subsequently revoked again for</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; one of the revocation reasons covered by the delta =
CRL,</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; then the certificate must be listed with the =
revocation</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; reason appropriate for the subsequent revocation.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (b) If the =
certificate was not removed from hold, but was</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; permanently =
revoked, then it must be listed as such on all</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; subsequent =
delta CRLs until the next base CRL is issued .</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; id-ce-deltaCRLIndicator =
OBJECT IDENTIFIER ::=3D { id-ce 27 }</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; BaseCRLNumber ::=3D =
CRLNumber</FONT>
</P>

<P><FONT SIZE=3D2>Russ</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0D3D4.4DEFC2E0--


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id FAA27746 for <[e-mail]>; Thu, 3 May 2001 05:58:59 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 3 May 2001 12:58:48 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA29797 for <[e-mail]>; Thu, 3 May 2001 08:58:59 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <JY8NT0YY>; Thu, 3 May 2001 08:58:59 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (housley-lap.securitydynamics.com [10.100.23.218]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JY8NT0YT; Thu, 3 May 2001 08:58:58 -0400
From: "Housley, Russ" <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 02 May 2001 21:20:13 -0400
Subject: Re: delta CRLs
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Denis:

For the most part, the text that you provide is an improvement; however, I 
MUST object to a few things.

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

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


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


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

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

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

What do others think?


>       (a) If a certificate was listed as revoked with revocation reason
>       certificateHold on a CRL (either a delta CRL or a CRL that is
>       complete for a given scope), and the hold is subsequently
>       released, the certificate must be listed with revocation reason
>       removeFromCRL until the next base CRL is issued.
>
>       Note: Should the certificate be subsequently revoked again for
>             one of the revocation reasons covered by the delta CRL,
>             then the certificate must be listed with the revocation
>             reason appropriate for the subsequent revocation.
>
>       (b) If the certificate was not removed from hold, but was
>       permanently revoked, then it must be listed as such on all
>       subsequent delta CRLs until the next base CRL is issued .
>
>    id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }
>
>    BaseCRLNumber ::= CRLNumber

Russ


Received: from server ([211.181.218.81]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA05956; Wed, 2 May 2001 16:55:32 -0700 (PDT)
From: [e-mail]
Message-ID: <00002b9e68dc$00004044$[e-mail]>
To: <[e-mail]>
Subject: write back when you can                         21881
Date: Wed, 02 May 2001 04:26:07 -0700
MIME-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal

<HTML><HEAD><TITLE>Take Control Of Your Conference Calls</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dwindows-12=
52">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR></HEAD>
<BODY vLink=3D#c0c0c0 link=3D#c0c0c0 bgColor=3D#ffffff leftMargin=3D0><FON=
T 
face=3Darial,helvetica>
<P>
<CENTER>
<TABLE width=3D600 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><B><FONT color=3D#000066 size=3D6>Long Distance 
      Conferencing<BR>Only <U>18 Cents</U> Per 
Minute</B></FONT></TD></TR></TBODY></TABLE>
<P><FONT color=3D#ff0000 size=3D5><B>Connects Up To 100 Participants!</B><=
/FONT> 
<P>
<TABLE width=3D350 border=3D0>
  <TBODY>
  <TR>
    <TD><FONT size=3D3><B>
      <LI>No setup fees 
      <LI>No contracts or monthly fees 
      <LI>Call anytime, from anywhere, to anywhere 
      <LI>International Dial In 18 cents per minute 
      <LI>Simplicity in set up and administration 
      <LI>Operator Help available 24/7 </B></FONT></LI></TD></TR></TBODY><=
/TABLE>
<P>
<TABLE width=3D500 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT color=3D#ff0000 size=3D60><B><FONT size=3D5>G=
et the best 
      quality, the easiest to use, and lowest rate in the 
      industry.</B></FONT></FONT></TD></TR></TBODY></TABLE>
<P>
<TABLE width=3D400 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT color=3D#000066 size=3D4>If you like saving m=
oney, fill 
      out the form below and one of our consultants will contact 
  you.</FONT></TD></TR></TBODY></TABLE>
<P><FONT color=3D#000066 size=3D2>Required Input Field<FONT color=3D#ff000=
0 
size=3D2>*</FONT></FONT> 
<P>
<TABLE cellSpacing=3D0 borderColorDark=3D#333300 cellPadding=3D3 width=3D6=
00 
borderColorLight=3D#ffffcc>
  <TBODY>
  <TR>
    <TD align=3Dmiddle>
      <FORM action=3Dmailto:[e-mail]?subject=3DConference_Inquir=
y 
      method=3Dpost encType=3Dtext/plain>
      <TABLE width=3D"100%">
        <TBODY>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 
          size=3D2>Name*</FONT></TD>
          <TD><INPUT name=3DNAME></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Web 
            Address*</FONT></TD>
          <TD><INPUT value=3Dhttp:// name=3DURL></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Company 
            Name*</FONT></TD>
          <TD><INPUT name=3DCOMPANY_NAME></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Web 
            Address*</FONT></TD>
          <TD><INPUT size=3D2 name=3DSTATE></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Business 
            Phone*</FONT></TD>
          <TD><INPUT name=3DBUS_PHONE></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Home 
            Phone</FONT></TD>
          <TD><INPUT name=3DHOME_PHONE></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Email 
            Address*</FONT></TD>
          <TD><INPUT name=3DEMAIL></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Type of 
            Business</FONT></TD>
          <TD><INPUT name=3DTYPE_OF_BUSINESS></TD></TR></TBODY></TABLE>
      <P><INPUT type=3Dsubmit value=3D"Submit Information" name=3Dsubmit> 
    </FORM></P></TD></TR></TBODY></TABLE>
<P>
<TABLE width=3D500>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT face=3D"Arial, Helvetica, sans-serif" color=3D=
#000000 
      size=3D1>This email is to those persons that have contacted Conferen=
ce Calls 
      for Less regarding available services or product information. If thi=
s 
      email is reaching you in error and you feel that you have not contac=
ted 
      us, <FONT color=3D#666666><A 
      href=3D"mailto:[e-mail]?subject=3DRemove_Conferencing">C=
lick 
      here</A></FONT>. We will gladly remove you from our mailing 
      list.</FONT><BR></TD></TR></TBODY></TABLE></P></CENTER></FONT></BODY=
></HTML>






Received: from e1.ny.us.ibm.com ([32.97.182.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA28833 for <[e-mail]>; Wed, 2 May 2001 14:43:39 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA236666; Wed, 2 May 2001 17:41:30 -0400
Received: from d02ml237.somers.hqregion.ibm.com (d02ml237.sby.ibm.com [9.45.4.171]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id RAA26638; Wed, 2 May 2001 17:37:56 -0400
Importance: Normal
Subject: RE: Basic constraints, key usage, and LDAP schema
To: Sharon Boeyen <[e-mail]>
Cc: "'Tim Polk'" <[e-mail]>, Denis Pinkas <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Wed, 2 May 2001 17:43:04 -0400
X-MIMETrack: Serialize by Router on D02ML237/02/M/IBM(Release 5.0.7 |March 21, 2001) at 05/02/2001 05:42:59 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

     In the current draft of X.509v4, "self-issued" means something
different than "self-signed".  "self-issued" appears to be the condition
"the certificate's subject name can be matched to its own issuer name,
which is that of a CA", while "self-signed" is that with the added
condition "the certificate signature is verifiable with the public key
contained in the message".  Most of these CRL signing certificates are
"self-issued" in this sense, although not "self-signed".
     One other reason why such CRL signing certificates would legitimately
not go into the CC Pair attribute would be that there is no other directory
entry where the CA certificate to verify the signature on this certificate
could be found, unlike any other certificates in CC Pair.
     Lastly, if a CRL signing certificate were issued by a CA certificate
with the same DN, it would certainly belong in the same realm, if that
concept has any meaning at all.

          Tom Gindin


Sharon Boeyen <[e-mail]> on 05/02/2001 04:05:54 PM

To:   "'Tim Polk'" <[e-mail]>, Denis Pinkas
      <[e-mail]>
cc:   [e-mail]
Subject:  RE: Basic constraints, key usage, and LDAP schema


Hi Tim,


I just want to clarify the directory attributes. All certs that are not
self issued must go in the cross certificates attribute. All self issued
certs must go in the caCertificates attribute. A subset of the certificates
in the cross certificate pairs attributes may also be present in the
caCertificates attribute (those issued within the same realm, a term left
undefined). Lets not go back down that rathole :-) The two attributes are
not interchangeable. Given that the certs you are talking about are not
self issued then they must go in the cross certificate pairs attribute and
may also be placed in the caCertificate attribute if issued within the same
realm.


Sharon


> -----Original Message-----
> From: Tim Polk [mailto:[e-mail]]
> Sent: Wednesday, May 02, 2001 10:43 AM
> To: Denis Pinkas
> Cc: [e-mail]
> Subject: Re: Basic constraints, key usage, and LDAP schema
>
>
> Denis,
>
> These messages have been flying fast and furious under several topic
> lines.  I don't believe I caught them all either!  As they
> are all related,
> it is difficult to resolve the issues one-by-one.  The
> separate solutions
> may combine to present new problems.  That was the rationale
> for the single
> comprehensive posting.
>
> The real problems, in my opinion, are as follows:
>
> (1) Consider a PKIX client, searching for a certificate to validate a
> particular CRL.  Under 2459, the client cannot guess whether
> the basic
> constraints extension will be present with the CA bit asserted.
>
> If the key used to validate the CRL is also used to validate
> certificates,
> it will have basic constraints and assert cA is TRUE.  In
> this case, the
> certificate should be in the ca certificate attribute (or
> perhaps the cross
> certificate pairs).
>
> If the key is not used to validate certificates, basic
> constraints will be
> omitted and the certificate will be stored in the user
> certificate attribute.
>
> (2) If a PKIX client wishes to communicate with a CA for certificate
> management purposes (e.g., to request a new certificate, request
> revocation, or perhaps centralized key generation for key
> escrow scenarios)
> the client will need to validate the CA's signature and
> perhaps make use of
> the CA's key management key.  If the keys used for these
> transactions are
> also used to sign PKCs, the certs will be in the CA certificate
> attribute.  If the keys used for these purposes are not used
> to sign PKCs,
> there will be no indication that this entity is a CA and the
> certs will be
> stored in the user certificate attribute.
>
> As above, the PKIX client does not know where to look for these
> certificates.  Where they are not used to sign PKCs, there will be no
> indication in the certificate that this entity is a CA at all.
>
> (3) The attribute certificate profile is very clear regarding
> AC issuers
> versus PKC issuers. Section 4.5 states "the AC issuer's PKC
> MUST NOT have a
> basicConstraints extension with the cA BOOLEAN set to TRUE."
>
> However, the combination of RFC 2459 and the attribute
> certificate profile
> does not permit an issuer to specify whether a subject can issue CRLs
> for  PKCs, ACs, or both.  This would provide us with an
> analogous solution:
> if the CA bit is not asserted, but the cRLSign bit is set in
> key usage, the
> subject is only permitted to issue CRLs for ACs.
>
> To be honest, (3) is the least compelling problem.  The CA
> must explicitly
> name an indirect CRL issuer in PKCs it issues *anyway*, so
> the CA bit isn't
> a big security issue.  Still, I think it is nice to supply
> clients with
> this information.
>
> Anyway, I hope this clarifies things a bit.  My goal was to
> resolve all
> three problems simultaneously and consistently.
>
> Thanks,
>
> Tim Polk
>
> At 03:14 PM 5/2/01 +0200, Denis Pinkas wrote:
> >Tim,
> >
> >I stayed silent on that topic and it is quite hard to catch
> all the e-mails
> >related to it. I certainly missed or skipped missed some of them.
> >
> > > Terry,
> > >
> > > I think it would be best if the client did not need to check the
> > > userCertificate attribute to validate CRLs.  This adds
> complexity without
> > > any real benefit (in my opinion.)  I have included some
> proposed text for
> > > the first paragraph of section 4.2.1.10 (basic
> constraints) that would
> > > clarify the issue.
> > >
> > > ----------------proposed text for first paragraph of
> > 4.2.1.10----------------
> > >
> > > The basic constraints extension identifies whether the
> subject of the
> > > certificate is a CA and the maximum depth of valid
> certification paths that
> > > include this certificate.  A subject is considered a CA
> if it issues public
> > > key certificates or CRLs that describe the revocation
> status of public key
> > > certificates.
> > >
> > > ----------------------end proposed text
> > > What do you think?
> >
> >RFC 2459 only said:
> >
> >    The basic constraints extension identifies whether the
> subject of the
> >    certificate is a CA and how deep a certification path may exist
> >    through that CA.
> >
> >However, according to the new text a "CRL Issuer" is now
> also a "CA": " A
> >subject is considered a CA if it issues public key
> certificates or CRLs that
> >describe the revocation status of public key certificates."
> >
> >The current text of new-part1-06 also goes in the same direction.
> >
> >    The cA bit indicates if the certified public key may be used to
> >    verify signatures on other certificates.  If the cA bit
> is asserted,
> >    then either the keyCertSign bit or the cRLSign bit in
> the key usage
> >    extension (see 4.2.1.3) MUST also be asserted. If the cA
> bit is not
> >    asserted, then both the keyCertSign bit and the cRLSign
> in the key
> >    usage extension MUST NOT be asserted.
> >
> >This seems quite strange. A CRL issuer is just one way to
> make available
> >revocation status information. OCSP is another way. RFC 2560 says:
> >
> >    OCSP signing delegation SHALL be designated by the
> >    inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate
> >    extension included in the OCSP response signer's
> certificate.  This
> >    certificate MUST be issued directly by the CA that issued the
> >    certificate in question.
> >
> >If a "CRL issuer" is a "CA", why should an OCSP responder
> designated by a CA
> >not also be a "CA" ?
> >
> >As far as I remember, originally the cA boolean in the basic
> constraints
> >extension only allowed to make the difference between leaf
> certificates and
> >CA certificates. This boolean now seems to be be used with a
> different
> >meaning (and, maybe, we should change its meaning - not the syntax).
> >
> >Could someone say again, why that change was requested and
> what are the real
> >benefits of that change ?
> >
> >In other words, could someone say again what the problem was ? :-)
> >
> >Thanks,
> >
> >Denis
> >
> > > Thanks,
> > >
> > > Tim Polk
> > >
> > > At 01:41 PM 5/1/01 -0700, Terry Hayes wrote:
> > > >Tim,
> > > >
> > > >I agree with your proposed solution.  As you have said,
> it separates the
> > > >semantics of the two extensions, and simplifies the
> rules for the LDAP
> > schema.
> > > >
> > > >There is one remaining point to address, and I believe
> it may be the main
> > > >point of discussion in the current thread.
> > > >
> > > >When a CA uses the CRLDP extension to designate another
> entity to be the
> > > >source for revocation information about some of its
> certificates, should
> > > >that entity  have a "CA" certificate (with appropriate
> basicConstraints
> > > >extension)?  I'm *not* suggesting that a
> basicConstraints extension is
> > > >necessary for the entity to be authorized to sign the
> CRL.  Instead, the
> > > >problem is that clients that are trying to locate the
> certificate will not
> > > >know whether they should look in the cACertificate
> attribute or the
> > > >userCertificate attribute to find the appropriate certificate.
> > > >
> > > >To solve this, we can suggest that cACertificate be
> searched first,
> > > >followed by userCertificate, or we can require that
> designated entities
> > > >must always be a "CA", and the client can safely skip
> the userCertificate
> > > >attribute.  This is a question of searching the
> directory only, and does
> > > >not suggest changing your assertion that any set of bits
> may be set in the
> > > >keyUsage extension of "CA" certificates.
> > > >
> > > >Terry
> > > >
> > > >Tim Polk wrote:
> > > >
> > > >>Folks,
> > > >>
> > > >>I have been reading the email messages on the list about the
> > > >>relationships between basic constraints, key usage, and
> the schema.
> > > >>After mulling over the problem.  I would like to
> propose a solution - the
> > > >>only solution, as far as I can tell...
> > > >>
> > > >>The solution is to simplify and separate the semantics
> of the basic
> > > >>constraints and key usage extension.  This has positive
> implications for
> > > >>the PKIX LDAP schema as well.
> > > >>
> > > >>Basic Constraints
> > > >>
> > > >>As stated in the current text for Basic Constraints (in
> 2459):  "The
> > > >>basic constraints extension identifies whether the
> subject of the
> > > >>certificate is a CA and how deep a certification path
> may exist through
> > > >>that CA."
> > > >>
> > > >>I believe this is the right semantics, and that basic
> constraints should
> > > >>be included and cA should be asserted in *any*
> certificate issued to a
> > > >>CA, regardless of the type or role associated with the
> public key in the
> > > >>certificate.
> > > >>
> > > >>Key Usage
> > > >>
> > > >>The issuer should use the Key Usage extension to
> disambiguate the
> > > >>subject's key pairs:
> > > >>(a) The issuer indicates this public key may be used to
> verify the
> > > >>signature on a public key certificate by asserting
> keyCertSign.  (b) The
> > > >>issuer indicates this public key may be used to verify
> the signature on
> > > >>CRLs by asserting cRLSign.  (c) The issuer indicates
> that this public key
> > > >>may be used to establish symmetric keys with the
> subject by asserting
> > > >>either keyEncipherment or keyAgreement.  (d) The issuer
> indicates that
> > > >>this public key may be used to verify signatures on
> objects other than
> > > >>public key certificates and CRLs by asserting nonRerpuidation or
> > > >>digitalSignature.
> > > >>
> > > >>Of course, if a key pair is used for multiple purposes,
> multiple key
> > > >>usages may be asserted.
> > > >>
> > > >>In each of these cases, the basic constraints extension
> also appears in
> > > >>the certificate and asserts that the subject is a CA.
> > > >>
> > > >>LDAP Schema
> > > >>
> > > >>All certificates issued to CAs would be considered CA
> certificates since
> > > >>the basic constraints extension is present and asserts
> that the subject
> > > >>is a CA.  As a result, each of these could appear in
> the cACertificate
> > > >>attribute or crossCertificatePair attribute.  They
> would *not* appear in
> > > >>the userCertificate attribute.  (That would include all
> types (a) through
> > > >>(d) above).
> > > >>
> > > >>------------------
> > > >>
> > > >>The implications of this strategy are as follows: (1)
> when a client is
> > > >>searching for a CA certificate, they will not have to check the
> > > >>userCertificate attribute; (2) the issuer can indicate
> that the subject
> > > >>is a CA regardless of the key usage; and (3) minimal
> changes to the text
> > > >>(my favorite!).
> > > >>
> > > >>What do you think?
> > > >>
> > > >>Thanks,
> > > >>
> > > >>Tim Polk
> > > >>
> > > >>
> > > >
> > > >
>





Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id OAA27272 for <[e-mail]>; Wed, 2 May 2001 14:28:39 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 2 May 2001 21:28:30 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id RAA27330 for <[e-mail]>; Wed, 2 May 2001 17:28:41 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <JY8NT5QW>; Wed, 2 May 2001 17:28:41 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (housley-lap.securitydynamics.com [10.100.23.218]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JY8NT5QS; Wed, 2 May 2001 17:28:36 -0400
From: "Housley, Russ" <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 02 May 2001 12:00:24 -0400
Subject: Re: keyCertSign and cRLSign Key Usage Bits
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Denis:

I know that you have been away and that you are trying to catch up on your 
mail.  This approach is not longer being pursued.  The 
issuingDistributionPoint text remains unchanged.

Russ


At 12:39 PM 5/2/2001 +0200, Denis Pinkas wrote:
>Russ,
>
>In a reply to Santosh (April 24), you said:
>
> > The IDP syntax is:
> >
> >     issuingDistributionPoint ::= SEQUENCE {
> >          distributionPoint       [0] DistributionPointName OPTIONAL,
> >          onlyContainsUserCerts   [1] BOOLEAN DEFAULT FALSE,
> >          onlyContainsCACerts     [2] BOOLEAN DEFAULT FALSE,
> >          onlySomeReasons         [3] ReasonFlags OPTIONAL,
> >          indirectCRL             [4] BOOLEAN DEFAULT FALSE }
> >
> > I was simply suggesting that this extension be present if the CRL is signed
> > with a key other than the one used to sign the certificate.
>
>The current text says (in section 5.2.5):
>
>" 5.2.5  Issuing Distribution Point
>
>    The issuing distribution point is a critical CRL extension that
>    identifies the CRL distribution point for a particular CRL, and it
>    indicates whether the CRL covers revocation for end entity
>    certificates only, CA  certificates only, or a limited set of reason
>    codes.  Although the extension is critical, conforming
>    implementations are not required to support this extension.
>
>    The CRL is signed using the CA's private key."
>
>I would guess that the last sentence would thus need to be changed. So would
>you have a text proposal to fix it ?
>
>Regards,
>
>Denis
>
>
> > I would expect
> > the distributionPoint field to be present (probably with a URL
> > (ldap://...)).  The boolean flags would be set based on the contents of the
> > CRL (probably all FALSE).  The reason codes would also be set based on the
> > contents of the CRL (probably absent).
>
> > Russ


Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA27228 for <[e-mail]>; Wed, 2 May 2001 14:28:24 -0700 (PDT)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA25529; Wed, 2 May 2001 14:28:21 -0700 (PDT)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA01097; Wed, 2 May 2001 17:28:15 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 02 May 2001 17:23:58 -0400
From: Steve Hanna <[e-mail]>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: "Housley, Russ" <[e-mail]>, [e-mail]
Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This is fine with me.

-Steve

Denis Pinkas wrote:
> This is fine in general. I would however prefer to move the two first
> sentences from 6.1 at the end of 6.1. This would lead to:
> 
>     The path validation process determines the set of certificate policies
>     that are valid for this path, based on the certificate policies
>     extension, policy mapping extension, policy constraints extension,
>     and inhibit any-policy extension.  To achieve this, the path
>     validation algorithm constructs a valid policy tree.  If the set of
>     certificate policies that are valid for this path is not empty, then
>     the result will be a valid policy tree of depth n, otherwise the
>     result will be a null valid policy tree. A particular certification
>     path may not, however, be appropriate for all applications.
>     Therefore, an application MAY augment this algorithm to further
>     limit the set of valid paths.
> 
> Regards,
> 
> Denis
> 
> > Denis:
> >
> > I agree with Steve Hanna's observation.  However, I think that we can
> > include a bit of notice in section 6.1.  I propose the following
> > replacement paragraph:
> >
> >     A particular certification path may not, however, be appropriate for
> >     all applications.  Therefore, an application MAY augment this
> >     algorithm to further limit the set of valid paths.  The path
> >     validation process also determines the set of certificate policies
> >     that are valid for this path, based on the certificate policies
> >     extension, policy mapping extension, policy constraints extension,
> >     and inhibit any-policy extension.  To achieve this, the path
> >     validation algorithm constructs a valid policy tree.  If the set of
> >     certificate policies that are valid for this path is not empty, then
> >     the result will be a valid policy tree of depth n, otherwise the
> >     result will be a null valid policy tree.
> >
> > I suggest that we replace the first paragraph of section 6.2. with:
> >
> >     The path validation algorithm describes the process of validating a
> >     single certification path.  While each certification path begins with
> >     a specific trust anchor, there is no requirement that all
> >     certification paths validated by a particular system share a single
> >     trust anchor.  An implementation that supports multiple trust anchors
> >     MAY augment the algorithm presented in section 6.1 to further limit
> >     the set of valid certification paths which begin with a particular
> >     trust anchor.  For example, an implementation MAY modify the
> >     algorithm to apply name constraints to a specific trust anchor during
> >     the initialization phase, or the application MAY require the presence
> >     of a particular alternative name form in the end entity certificate,
> >     or the application MAY impose requirements on application-specific
> >     extensions.  Thus, the path validation algorithm presented in section
> >     6.1 defines the minimum conditions for a path to be considered valid.
> >
> > Russ


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA20993 for <[e-mail]>; Wed, 2 May 2001 13:12:34 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <K12TNTND>; Wed, 2 May 2001 16:12:05 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Tim Polk'" <[e-mail]>, Denis Pinkas <[e-mail]>
Cc: [e-mail]
Subject: RE: Basic constraints, key usage, and LDAP schema
Date: Wed, 2 May 2001 16:05:54 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D343.4B288470"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D343.4B288470
Content-Type: text/plain

Hi Tim,

I just want to clarify the directory attributes. All certs that are not self
issued must go in the cross certificates attribute. All self issued certs
must go in the caCertificates attribute. A subset of the certificates in the
cross certificate pairs attributes may also be present in the caCertificates
attribute (those issued within the same realm, a term left undefined). Lets
not go back down that rathole :-) The two attributes are not
interchangeable. Given that the certs you are talking about are not self
issued then they must go in the cross certificate pairs attribute and may
also be placed in the caCertificate attribute if issued within the same
realm.

Sharon

> -----Original Message-----
> From: Tim Polk [mailto:[e-mail]]
> Sent: Wednesday, May 02, 2001 10:43 AM
> To: Denis Pinkas
> Cc: [e-mail]
> Subject: Re: Basic constraints, key usage, and LDAP schema
> 
> 
> Denis,
> 
> These messages have been flying fast and furious under several topic 
> lines.  I don't believe I caught them all either!  As they 
> are all related, 
> it is difficult to resolve the issues one-by-one.  The 
> separate solutions 
> may combine to present new problems.  That was the rationale 
> for the single 
> comprehensive posting.
> 
> The real problems, in my opinion, are as follows:
> 
> (1) Consider a PKIX client, searching for a certificate to validate a 
> particular CRL.  Under 2459, the client cannot guess whether 
> the basic 
> constraints extension will be present with the CA bit asserted.
> 
> If the key used to validate the CRL is also used to validate 
> certificates, 
> it will have basic constraints and assert cA is TRUE.  In 
> this case, the 
> certificate should be in the ca certificate attribute (or 
> perhaps the cross 
> certificate pairs).
> 
> If the key is not used to validate certificates, basic 
> constraints will be 
> omitted and the certificate will be stored in the user 
> certificate attribute.
> 
> (2) If a PKIX client wishes to communicate with a CA for certificate 
> management purposes (e.g., to request a new certificate, request 
> revocation, or perhaps centralized key generation for key 
> escrow scenarios) 
> the client will need to validate the CA's signature and 
> perhaps make use of 
> the CA's key management key.  If the keys used for these 
> transactions are 
> also used to sign PKCs, the certs will be in the CA certificate 
> attribute.  If the keys used for these purposes are not used 
> to sign PKCs, 
> there will be no indication that this entity is a CA and the 
> certs will be 
> stored in the user certificate attribute.
> 
> As above, the PKIX client does not know where to look for these 
> certificates.  Where they are not used to sign PKCs, there will be no 
> indication in the certificate that this entity is a CA at all.
> 
> (3) The attribute certificate profile is very clear regarding 
> AC issuers 
> versus PKC issuers. Section 4.5 states "the AC issuer's PKC 
> MUST NOT have a 
> basicConstraints extension with the cA BOOLEAN set to TRUE."
> 
> However, the combination of RFC 2459 and the attribute 
> certificate profile 
> does not permit an issuer to specify whether a subject can issue CRLs 
> for  PKCs, ACs, or both.  This would provide us with an 
> analogous solution: 
> if the CA bit is not asserted, but the cRLSign bit is set in 
> key usage, the 
> subject is only permitted to issue CRLs for ACs.
> 
> To be honest, (3) is the least compelling problem.  The CA 
> must explicitly 
> name an indirect CRL issuer in PKCs it issues *anyway*, so 
> the CA bit isn't 
> a big security issue.  Still, I think it is nice to supply 
> clients with 
> this information.
> 
> Anyway, I hope this clarifies things a bit.  My goal was to 
> resolve all 
> three problems simultaneously and consistently.
> 
> Thanks,
> 
> Tim Polk
> 
> At 03:14 PM 5/2/01 +0200, Denis Pinkas wrote:
> >Tim,
> >
> >I stayed silent on that topic and it is quite hard to catch 
> all the e-mails
> >related to it. I certainly missed or skipped missed some of them.
> >
> > > Terry,
> > >
> > > I think it would be best if the client did not need to check the
> > > userCertificate attribute to validate CRLs.  This adds 
> complexity without
> > > any real benefit (in my opinion.)  I have included some 
> proposed text for
> > > the first paragraph of section 4.2.1.10 (basic 
> constraints) that would
> > > clarify the issue.
> > >
> > > ----------------proposed text for first paragraph of 
> > 4.2.1.10----------------
> > >
> > > The basic constraints extension identifies whether the 
> subject of the
> > > certificate is a CA and the maximum depth of valid 
> certification paths that
> > > include this certificate.  A subject is considered a CA 
> if it issues public
> > > key certificates or CRLs that describe the revocation 
> status of public key
> > > certificates.
> > >
> > > ----------------------end proposed text
> > > What do you think?
> >
> >RFC 2459 only said:
> >
> >    The basic constraints extension identifies whether the 
> subject of the
> >    certificate is a CA and how deep a certification path may exist
> >    through that CA.
> >
> >However, according to the new text a "CRL Issuer" is now 
> also a "CA": " A
> >subject is considered a CA if it issues public key 
> certificates or CRLs that
> >describe the revocation status of public key certificates."
> >
> >The current text of new-part1-06 also goes in the same direction.
> >
> >    The cA bit indicates if the certified public key may be used to
> >    verify signatures on other certificates.  If the cA bit 
> is asserted,
> >    then either the keyCertSign bit or the cRLSign bit in 
> the key usage
> >    extension (see 4.2.1.3) MUST also be asserted. If the cA 
> bit is not
> >    asserted, then both the keyCertSign bit and the cRLSign 
> in the key
> >    usage extension MUST NOT be asserted.
> >
> >This seems quite strange. A CRL issuer is just one way to 
> make available
> >revocation status information. OCSP is another way. RFC 2560 says:
> >
> >    OCSP signing delegation SHALL be designated by the
> >    inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate
> >    extension included in the OCSP response signer's 
> certificate.  This
> >    certificate MUST be issued directly by the CA that issued the
> >    certificate in question.
> >
> >If a "CRL issuer" is a "CA", why should an OCSP responder 
> designated by a CA
> >not also be a "CA" ?
> >
> >As far as I remember, originally the cA boolean in the basic 
> constraints
> >extension only allowed to make the difference between leaf 
> certificates and
> >CA certificates. This boolean now seems to be be used with a 
> different
> >meaning (and, maybe, we should change its meaning - not the syntax).
> >
> >Could someone say again, why that change was requested and 
> what are the real
> >benefits of that change ?
> >
> >In other words, could someone say again what the problem was ? :-)
> >
> >Thanks,
> >
> >Denis
> >
> > > Thanks,
> > >
> > > Tim Polk
> > >
> > > At 01:41 PM 5/1/01 -0700, Terry Hayes wrote:
> > > >Tim,
> > > >
> > > >I agree with your proposed solution.  As you have said, 
> it separates the
> > > >semantics of the two extensions, and simplifies the 
> rules for the LDAP 
> > schema.
> > > >
> > > >There is one remaining point to address, and I believe 
> it may be the main
> > > >point of discussion in the current thread.
> > > >
> > > >When a CA uses the CRLDP extension to designate another 
> entity to be the
> > > >source for revocation information about some of its 
> certificates, should
> > > >that entity  have a "CA" certificate (with appropriate 
> basicConstraints
> > > >extension)?  I'm *not* suggesting that a 
> basicConstraints extension is
> > > >necessary for the entity to be authorized to sign the 
> CRL.  Instead, the
> > > >problem is that clients that are trying to locate the 
> certificate will not
> > > >know whether they should look in the cACertificate 
> attribute or the
> > > >userCertificate attribute to find the appropriate certificate.
> > > >
> > > >To solve this, we can suggest that cACertificate be 
> searched first,
> > > >followed by userCertificate, or we can require that 
> designated entities
> > > >must always be a "CA", and the client can safely skip 
> the userCertificate
> > > >attribute.  This is a question of searching the 
> directory only, and does
> > > >not suggest changing your assertion that any set of bits 
> may be set in the
> > > >keyUsage extension of "CA" certificates.
> > > >
> > > >Terry
> > > >
> > > >Tim Polk wrote:
> > > >
> > > >>Folks,
> > > >>
> > > >>I have been reading the email messages on the list about the
> > > >>relationships between basic constraints, key usage, and 
> the schema.
> > > >>After mulling over the problem.  I would like to 
> propose a solution - the
> > > >>only solution, as far as I can tell...
> > > >>
> > > >>The solution is to simplify and separate the semantics 
> of the basic
> > > >>constraints and key usage extension.  This has positive 
> implications for
> > > >>the PKIX LDAP schema as well.
> > > >>
> > > >>Basic Constraints
> > > >>
> > > >>As stated in the current text for Basic Constraints (in 
> 2459):  "The
> > > >>basic constraints extension identifies whether the 
> subject of the
> > > >>certificate is a CA and how deep a certification path 
> may exist through
> > > >>that CA."
> > > >>
> > > >>I believe this is the right semantics, and that basic 
> constraints should
> > > >>be included and cA should be asserted in *any* 
> certificate issued to a
> > > >>CA, regardless of the type or role associated with the 
> public key in the
> > > >>certificate.
> > > >>
> > > >>Key Usage
> > > >>
> > > >>The issuer should use the Key Usage extension to 
> disambiguate the
> > > >>subject's key pairs:
> > > >>(a) The issuer indicates this public key may be used to 
> verify the
> > > >>signature on a public key certificate by asserting 
> keyCertSign.  (b) The
> > > >>issuer indicates this public key may be used to verify 
> the signature on
> > > >>CRLs by asserting cRLSign.  (c) The issuer indicates 
> that this public key
> > > >>may be used to establish symmetric keys with the 
> subject by asserting
> > > >>either keyEncipherment or keyAgreement.  (d) The issuer 
> indicates that
> > > >>this public key may be used to verify signatures on 
> objects other than
> > > >>public key certificates and CRLs by asserting nonRerpuidation or
> > > >>digitalSignature.
> > > >>
> > > >>Of course, if a key pair is used for multiple purposes, 
> multiple key
> > > >>usages may be asserted.
> > > >>
> > > >>In each of these cases, the basic constraints extension 
> also appears in
> > > >>the certificate and asserts that the subject is a CA.
> > > >>
> > > >>LDAP Schema
> > > >>
> > > >>All certificates issued to CAs would be considered CA 
> certificates since
> > > >>the basic constraints extension is present and asserts 
> that the subject
> > > >>is a CA.  As a result, each of these could appear in 
> the cACertificate
> > > >>attribute or crossCertificatePair attribute.  They 
> would *not* appear in
> > > >>the userCertificate attribute.  (That would include all 
> types (a) through
> > > >>(d) above).
> > > >>
> > > >>------------------
> > > >>
> > > >>The implications of this strategy are as follows: (1) 
> when a client is
> > > >>searching for a CA certificate, they will not have to check the
> > > >>userCertificate attribute; (2) the issuer can indicate 
> that the subject
> > > >>is a CA regardless of the key usage; and (3) minimal 
> changes to the text
> > > >>(my favorite!).
> > > >>
> > > >>What do you think?
> > > >>
> > > >>Thanks,
> > > >>
> > > >>Tim Polk
> > > >>
> > > >>
> > > >
> > > >
> 

------_=_NextPart_001_01C0D343.4B288470
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Basic constraints, key usage, and LDAP schema</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Tim,</FONT>
</P>

<P><FONT SIZE=3D2>I just want to clarify the directory attributes. All =
certs that are not self issued must go in the cross certificates =
attribute. All self issued certs must go in the caCertificates =
attribute. A subset of the certificates in the cross certificate pairs =
attributes may also be present in the caCertificates attribute (those =
issued within the same realm, a term left undefined). Lets not go back =
down that rathole :-) The two attributes are not interchangeable. Given =
that the certs you are talking about are not self issued then they must =
go in the cross certificate pairs attribute and may also be placed in =
the caCertificate attribute if issued within the same realm.</FONT></P>

<P><FONT SIZE=3D2>Sharon</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Tim Polk [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, May 02, 2001 10:43 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Denis Pinkas</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: Basic constraints, key usage, and =
LDAP schema</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Denis,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; These messages have been flying fast and =
furious under several topic </FONT>
<BR><FONT SIZE=3D2>&gt; lines.&nbsp; I don't believe I caught them all =
either!&nbsp; As they </FONT>
<BR><FONT SIZE=3D2>&gt; are all related, </FONT>
<BR><FONT SIZE=3D2>&gt; it is difficult to resolve the issues =
one-by-one.&nbsp; The </FONT>
<BR><FONT SIZE=3D2>&gt; separate solutions </FONT>
<BR><FONT SIZE=3D2>&gt; may combine to present new problems.&nbsp; That =
was the rationale </FONT>
<BR><FONT SIZE=3D2>&gt; for the single </FONT>
<BR><FONT SIZE=3D2>&gt; comprehensive posting.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The real problems, in my opinion, are as =
follows:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; (1) Consider a PKIX client, searching for a =
certificate to validate a </FONT>
<BR><FONT SIZE=3D2>&gt; particular CRL.&nbsp; Under 2459, the client =
cannot guess whether </FONT>
<BR><FONT SIZE=3D2>&gt; the basic </FONT>
<BR><FONT SIZE=3D2>&gt; constraints extension will be present with the =
CA bit asserted.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If the key used to validate the CRL is also =
used to validate </FONT>
<BR><FONT SIZE=3D2>&gt; certificates, </FONT>
<BR><FONT SIZE=3D2>&gt; it will have basic constraints and assert cA is =
TRUE.&nbsp; In </FONT>
<BR><FONT SIZE=3D2>&gt; this case, the </FONT>
<BR><FONT SIZE=3D2>&gt; certificate should be in the ca certificate =
attribute (or </FONT>
<BR><FONT SIZE=3D2>&gt; perhaps the cross </FONT>
<BR><FONT SIZE=3D2>&gt; certificate pairs).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If the key is not used to validate =
certificates, basic </FONT>
<BR><FONT SIZE=3D2>&gt; constraints will be </FONT>
<BR><FONT SIZE=3D2>&gt; omitted and the certificate will be stored in =
the user </FONT>
<BR><FONT SIZE=3D2>&gt; certificate attribute.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; (2) If a PKIX client wishes to communicate with =
a CA for certificate </FONT>
<BR><FONT SIZE=3D2>&gt; management purposes (e.g., to request a new =
certificate, request </FONT>
<BR><FONT SIZE=3D2>&gt; revocation, or perhaps centralized key =
generation for key </FONT>
<BR><FONT SIZE=3D2>&gt; escrow scenarios) </FONT>
<BR><FONT SIZE=3D2>&gt; the client will need to validate the CA's =
signature and </FONT>
<BR><FONT SIZE=3D2>&gt; perhaps make use of </FONT>
<BR><FONT SIZE=3D2>&gt; the CA's key management key.&nbsp; If the keys =
used for these </FONT>
<BR><FONT SIZE=3D2>&gt; transactions are </FONT>
<BR><FONT SIZE=3D2>&gt; also used to sign PKCs, the certs will be in =
the CA certificate </FONT>
<BR><FONT SIZE=3D2>&gt; attribute.&nbsp; If the keys used for these =
purposes are not used </FONT>
<BR><FONT SIZE=3D2>&gt; to sign PKCs, </FONT>
<BR><FONT SIZE=3D2>&gt; there will be no indication that this entity is =
a CA and the </FONT>
<BR><FONT SIZE=3D2>&gt; certs will be </FONT>
<BR><FONT SIZE=3D2>&gt; stored in the user certificate =
attribute.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; As above, the PKIX client does not know where =
to look for these </FONT>
<BR><FONT SIZE=3D2>&gt; certificates.&nbsp; Where they are not used to =
sign PKCs, there will be no </FONT>
<BR><FONT SIZE=3D2>&gt; indication in the certificate that this entity =
is a CA at all.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; (3) The attribute certificate profile is very =
clear regarding </FONT>
<BR><FONT SIZE=3D2>&gt; AC issuers </FONT>
<BR><FONT SIZE=3D2>&gt; versus PKC issuers. Section 4.5 states =
&quot;the AC issuer's PKC </FONT>
<BR><FONT SIZE=3D2>&gt; MUST NOT have a </FONT>
<BR><FONT SIZE=3D2>&gt; basicConstraints extension with the cA BOOLEAN =
set to TRUE.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; However, the combination of RFC 2459 and the =
attribute </FONT>
<BR><FONT SIZE=3D2>&gt; certificate profile </FONT>
<BR><FONT SIZE=3D2>&gt; does not permit an issuer to specify whether a =
subject can issue CRLs </FONT>
<BR><FONT SIZE=3D2>&gt; for&nbsp; PKCs, ACs, or both.&nbsp; This would =
provide us with an </FONT>
<BR><FONT SIZE=3D2>&gt; analogous solution: </FONT>
<BR><FONT SIZE=3D2>&gt; if the CA bit is not asserted, but the cRLSign =
bit is set in </FONT>
<BR><FONT SIZE=3D2>&gt; key usage, the </FONT>
<BR><FONT SIZE=3D2>&gt; subject is only permitted to issue CRLs for =
ACs.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; To be honest, (3) is the least compelling =
problem.&nbsp; The CA </FONT>
<BR><FONT SIZE=3D2>&gt; must explicitly </FONT>
<BR><FONT SIZE=3D2>&gt; name an indirect CRL issuer in PKCs it issues =
*anyway*, so </FONT>
<BR><FONT SIZE=3D2>&gt; the CA bit isn't </FONT>
<BR><FONT SIZE=3D2>&gt; a big security issue.&nbsp; Still, I think it =
is nice to supply </FONT>
<BR><FONT SIZE=3D2>&gt; clients with </FONT>
<BR><FONT SIZE=3D2>&gt; this information.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Anyway, I hope this clarifies things a =
bit.&nbsp; My goal was to </FONT>
<BR><FONT SIZE=3D2>&gt; resolve all </FONT>
<BR><FONT SIZE=3D2>&gt; three problems simultaneously and =
consistently.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thanks,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Tim Polk</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; At 03:14 PM 5/2/01 +0200, Denis Pinkas =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Tim,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;I stayed silent on that topic and it is =
quite hard to catch </FONT>
<BR><FONT SIZE=3D2>&gt; all the e-mails</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;related to it. I certainly missed or =
skipped missed some of them.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Terry,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; I think it would be best if the =
client did not need to check the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; userCertificate attribute to validate =
CRLs.&nbsp; This adds </FONT>
<BR><FONT SIZE=3D2>&gt; complexity without</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; any real benefit (in my =
opinion.)&nbsp; I have included some </FONT>
<BR><FONT SIZE=3D2>&gt; proposed text for</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; the first paragraph of section =
4.2.1.10 (basic </FONT>
<BR><FONT SIZE=3D2>&gt; constraints) that would</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; clarify the issue.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; ----------------proposed text for =
first paragraph of </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 4.2.1.10----------------</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; The basic constraints extension =
identifies whether the </FONT>
<BR><FONT SIZE=3D2>&gt; subject of the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; certificate is a CA and the maximum =
depth of valid </FONT>
<BR><FONT SIZE=3D2>&gt; certification paths that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; include this certificate.&nbsp; A =
subject is considered a CA </FONT>
<BR><FONT SIZE=3D2>&gt; if it issues public</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; key certificates or CRLs that =
describe the revocation </FONT>
<BR><FONT SIZE=3D2>&gt; status of public key</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; certificates.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; ----------------------end proposed =
text</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; What do you think?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;RFC 2459 only said:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; The basic constraints =
extension identifies whether the </FONT>
<BR><FONT SIZE=3D2>&gt; subject of the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; certificate is a CA and =
how deep a certification path may exist</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; through that CA.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;However, according to the new text a =
&quot;CRL Issuer&quot; is now </FONT>
<BR><FONT SIZE=3D2>&gt; also a &quot;CA&quot;: &quot; A</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;subject is considered a CA if it issues =
public key </FONT>
<BR><FONT SIZE=3D2>&gt; certificates or CRLs that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;describe the revocation status of public =
key certificates.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;The current text of new-part1-06 also goes =
in the same direction.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; The cA bit indicates if =
the certified public key may be used to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; verify signatures on =
other certificates.&nbsp; If the cA bit </FONT>
<BR><FONT SIZE=3D2>&gt; is asserted,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; then either the =
keyCertSign bit or the cRLSign bit in </FONT>
<BR><FONT SIZE=3D2>&gt; the key usage</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; extension (see 4.2.1.3) =
MUST also be asserted. If the cA </FONT>
<BR><FONT SIZE=3D2>&gt; bit is not</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; asserted, then both the =
keyCertSign bit and the cRLSign </FONT>
<BR><FONT SIZE=3D2>&gt; in the key</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; usage extension MUST NOT =
be asserted.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;This seems quite strange. A CRL issuer is =
just one way to </FONT>
<BR><FONT SIZE=3D2>&gt; make available</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;revocation status information. OCSP is =
another way. RFC 2560 says:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; OCSP signing delegation =
SHALL be designated by the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; inclusion of =
id-kp-OCSPSigning in an extendedKeyUsage certificate</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; extension included in =
the OCSP response signer's </FONT>
<BR><FONT SIZE=3D2>&gt; certificate.&nbsp; This</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; certificate MUST be =
issued directly by the CA that issued the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; certificate in =
question.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;If a &quot;CRL issuer&quot; is a =
&quot;CA&quot;, why should an OCSP responder </FONT>
<BR><FONT SIZE=3D2>&gt; designated by a CA</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;not also be a &quot;CA&quot; ?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;As far as I remember, originally the cA =
boolean in the basic </FONT>
<BR><FONT SIZE=3D2>&gt; constraints</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;extension only allowed to make the =
difference between leaf </FONT>
<BR><FONT SIZE=3D2>&gt; certificates and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;CA certificates. This boolean now seems to =
be be used with a </FONT>
<BR><FONT SIZE=3D2>&gt; different</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;meaning (and, maybe, we should change its =
meaning - not the syntax).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Could someone say again, why that change =
was requested and </FONT>
<BR><FONT SIZE=3D2>&gt; what are the real</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;benefits of that change ?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;In other words, could someone say again =
what the problem was ? :-)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Thanks,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Denis</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Thanks,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Tim Polk</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; At 01:41 PM 5/1/01 -0700, Terry Hayes =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;Tim,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;I agree with your proposed =
solution.&nbsp; As you have said, </FONT>
<BR><FONT SIZE=3D2>&gt; it separates the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;semantics of the two extensions, =
and simplifies the </FONT>
<BR><FONT SIZE=3D2>&gt; rules for the LDAP </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; schema.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;There is one remaining point to =
address, and I believe </FONT>
<BR><FONT SIZE=3D2>&gt; it may be the main</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;point of discussion in the =
current thread.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;When a CA uses the CRLDP =
extension to designate another </FONT>
<BR><FONT SIZE=3D2>&gt; entity to be the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;source for revocation information =
about some of its </FONT>
<BR><FONT SIZE=3D2>&gt; certificates, should</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;that entity&nbsp; have a =
&quot;CA&quot; certificate (with appropriate </FONT>
<BR><FONT SIZE=3D2>&gt; basicConstraints</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;extension)?&nbsp; I'm *not* =
suggesting that a </FONT>
<BR><FONT SIZE=3D2>&gt; basicConstraints extension is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;necessary for the entity to be =
authorized to sign the </FONT>
<BR><FONT SIZE=3D2>&gt; CRL.&nbsp; Instead, the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;problem is that clients that are =
trying to locate the </FONT>
<BR><FONT SIZE=3D2>&gt; certificate will not</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;know whether they should look in =
the cACertificate </FONT>
<BR><FONT SIZE=3D2>&gt; attribute or the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;userCertificate attribute to find =
the appropriate certificate.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;To solve this, we can suggest =
that cACertificate be </FONT>
<BR><FONT SIZE=3D2>&gt; searched first,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;followed by userCertificate, or =
we can require that </FONT>
<BR><FONT SIZE=3D2>&gt; designated entities</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;must always be a &quot;CA&quot;, =
and the client can safely skip </FONT>
<BR><FONT SIZE=3D2>&gt; the userCertificate</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;attribute.&nbsp; This is a =
question of searching the </FONT>
<BR><FONT SIZE=3D2>&gt; directory only, and does</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;not suggest changing your =
assertion that any set of bits </FONT>
<BR><FONT SIZE=3D2>&gt; may be set in the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;keyUsage extension of =
&quot;CA&quot; certificates.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;Terry</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;Tim Polk wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;Folks,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;I have been reading the email =
messages on the list about the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;relationships between basic =
constraints, key usage, and </FONT>
<BR><FONT SIZE=3D2>&gt; the schema.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;After mulling over the =
problem.&nbsp; I would like to </FONT>
<BR><FONT SIZE=3D2>&gt; propose a solution - the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;only solution, as far as I =
can tell...</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;The solution is to simplify =
and separate the semantics </FONT>
<BR><FONT SIZE=3D2>&gt; of the basic</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;constraints and key usage =
extension.&nbsp; This has positive </FONT>
<BR><FONT SIZE=3D2>&gt; implications for</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;the PKIX LDAP schema as =
well.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;Basic Constraints</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;As stated in the current text =
for Basic Constraints (in </FONT>
<BR><FONT SIZE=3D2>&gt; 2459):&nbsp; &quot;The</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;basic constraints extension =
identifies whether the </FONT>
<BR><FONT SIZE=3D2>&gt; subject of the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;certificate is a CA and how =
deep a certification path </FONT>
<BR><FONT SIZE=3D2>&gt; may exist through</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;that CA.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;I believe this is the right =
semantics, and that basic </FONT>
<BR><FONT SIZE=3D2>&gt; constraints should</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;be included and cA should be =
asserted in *any* </FONT>
<BR><FONT SIZE=3D2>&gt; certificate issued to a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;CA, regardless of the type or =
role associated with the </FONT>
<BR><FONT SIZE=3D2>&gt; public key in the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;certificate.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;Key Usage</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;The issuer should use the Key =
Usage extension to </FONT>
<BR><FONT SIZE=3D2>&gt; disambiguate the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;subject's key pairs:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;(a) The issuer indicates this =
public key may be used to </FONT>
<BR><FONT SIZE=3D2>&gt; verify the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;signature on a public key =
certificate by asserting </FONT>
<BR><FONT SIZE=3D2>&gt; keyCertSign.&nbsp; (b) The</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;issuer indicates this public =
key may be used to verify </FONT>
<BR><FONT SIZE=3D2>&gt; the signature on</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;CRLs by asserting =
cRLSign.&nbsp; (c) The issuer indicates </FONT>
<BR><FONT SIZE=3D2>&gt; that this public key</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;may be used to establish =
symmetric keys with the </FONT>
<BR><FONT SIZE=3D2>&gt; subject by asserting</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;either keyEncipherment or =
keyAgreement.&nbsp; (d) The issuer </FONT>
<BR><FONT SIZE=3D2>&gt; indicates that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;this public key may be used =
to verify signatures on </FONT>
<BR><FONT SIZE=3D2>&gt; objects other than</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;public key certificates and =
CRLs by asserting nonRerpuidation or</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;digitalSignature.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;Of course, if a key pair is =
used for multiple purposes, </FONT>
<BR><FONT SIZE=3D2>&gt; multiple key</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;usages may be =
asserted.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;In each of these cases, the =
basic constraints extension </FONT>
<BR><FONT SIZE=3D2>&gt; also appears in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;the certificate and asserts =
that the subject is a CA.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;LDAP Schema</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;All certificates issued to =
CAs would be considered CA </FONT>
<BR><FONT SIZE=3D2>&gt; certificates since</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;the basic constraints =
extension is present and asserts </FONT>
<BR><FONT SIZE=3D2>&gt; that the subject</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;is a CA.&nbsp; As a result, =
each of these could appear in </FONT>
<BR><FONT SIZE=3D2>&gt; the cACertificate</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;attribute or =
crossCertificatePair attribute.&nbsp; They </FONT>
<BR><FONT SIZE=3D2>&gt; would *not* appear in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;the userCertificate =
attribute.&nbsp; (That would include all </FONT>
<BR><FONT SIZE=3D2>&gt; types (a) through</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;(d) above).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;------------------</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;The implications of this =
strategy are as follows: (1) </FONT>
<BR><FONT SIZE=3D2>&gt; when a client is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;searching for a CA =
certificate, they will not have to check the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;userCertificate attribute; =
(2) the issuer can indicate </FONT>
<BR><FONT SIZE=3D2>&gt; that the subject</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;is a CA regardless of the key =
usage; and (3) minimal </FONT>
<BR><FONT SIZE=3D2>&gt; changes to the text</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;(my favorite!).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;What do you think?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;Thanks,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;Tim Polk</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0D343.4B288470--


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA18157 for <[e-mail]>; Wed, 2 May 2001 12:20:43 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 2 May 2001 12:20:55 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]> for [e-mail]; Wed, 02 May 2001 12:20:54 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <HR26Q50L>; Wed, 02 May 2001 12:19:13 -0700
Content-return: allowed
Date: Wed, 02 May 2001 12:19:11 -0700
From: Peter Williams <[e-mail]>
Subject: RE: CPS Pointer
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"

The CPS pointer and the user notice policy 
qualifiers are each an input to the PMI *control model*,
acting as an environmental variable.

Env vars have a defined function for both NR and
access control in conforming authorization and 
privilege management schemes.

The semantics of CPS pointer and user notices are 
properly dealt with not in the sense of 
UI issues of the Netscape/Microsoft browser era 
of PKI, but in the PMI modules that enforce
policy *control*. CPS pointers and user notices are
control devices.

The issue has moved tangentially away, somewhat, from 
choice of URI form, into the factors that motivate
the choice(s) of URI form, for the CPS pointer.
You might decide based on what forms make best
sense for technical interoperability between
CA chain processing and PMI control policy
enforcement modules.

-----Original Message-----
From: Trevor Freeman [mailto:[e-mail]]
Sent: Wednesday, May 02, 2001 10:23 AM
To: Paul Hoffman / IMC; Housley, Russ; [e-mail]
Subject: RE: CPS Pointer


Paul,
This can occur in any certificate, and if we want a client to have this
option, then lets be realistic over what is possible. Te client being on
or offline has no relevance to the types of URI. If we are going to
include this in the profile, then it should have a chance to work.
Trevor

-----Original Message-----
From: Paul Hoffman / IMC [mailto:[e-mail]] 
Sent: Monday, April 30, 2001 3:40 PM
To: Housley, Russ; [e-mail]
Subject: Re: CPS Pointer

At 2:32 PM -0400 4/30/01, Housley, Russ wrote:
>Trevor Freeman noticed we don't have any guidelines for what forms 
>of URI are supported with the CPS Pointer.  Presently, we say:
>
>    The CPS Pointer qualifier contains a pointer to a Certification
>    Practice Statement (CPS) published by the CA.  The pointer is in
the
>    form of a URI.  Processing requirements for this qualifier are a
>    local matter.  No action is mandated by this specification
regardless
>    of the criticality value asserted for the extension.
>
>So, we are not mandating any behavior on the client.

Nor should we. The "client" might be offline, such as a mail user 
agent that uses S/MIME. The "client" might have no user interface for 
certificates, such as an IPsec box.

Let's be realistic: will the end user reading the CPS affect the 
actions in more that 0.000001% of PKI transactions? If a user has 
already loaded a root cert, there is essentially no chance that they 
will read a CPS after the fact.

I propose that you don't change anything.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.9.3/8.9.3) with SMTP id KAA13601 for <[e-mail]>; Wed, 2 May 2001 10:39:54 -0700 (PDT)
Received: from 157.54.9.104 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 02 May 2001 10:21:13 -0700 (Pacific Daylight Time)
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Wed, 2 May 2001 10:23:18 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Wed, 2 May 2001 10:23:18 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 2 May 2001 10:23:10 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: CPS Pointer
Date: Wed, 2 May 2001 10:23:10 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: CPS Pointer
Thread-Index: AcDR3JgUAmZbchQuSFybXTkc2Wn1+wBT5EaQ
From: "Trevor Freeman" <[e-mail]>
To: "Paul Hoffman / IMC" <[e-mail]>, "Housley, Russ" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 02 May 2001 17:23:10.0824 (UTC) FILETIME=[8FA34E80:01C0D32C]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id KAA13602

Paul,
This can occur in any certificate, and if we want a client to have this
option, then lets be realistic over what is possible. Te client being on
or offline has no relevance to the types of URI. If we are going to
include this in the profile, then it should have a chance to work.
Trevor

-----Original Message-----
From: Paul Hoffman / IMC [mailto:[e-mail]] 
Sent: Monday, April 30, 2001 3:40 PM
To: Housley, Russ; [e-mail]
Subject: Re: CPS Pointer

At 2:32 PM -0400 4/30/01, Housley, Russ wrote:
>Trevor Freeman noticed we don't have any guidelines for what forms 
>of URI are supported with the CPS Pointer.  Presently, we say:
>
>    The CPS Pointer qualifier contains a pointer to a Certification
>    Practice Statement (CPS) published by the CA.  The pointer is in
the
>    form of a URI.  Processing requirements for this qualifier are a
>    local matter.  No action is mandated by this specification
regardless
>    of the criticality value asserted for the extension.
>
>So, we are not mandating any behavior on the client.

Nor should we. The "client" might be offline, such as a mail user 
agent that uses S/MIME. The "client" might have no user interface for 
certificates, such as an IPsec box.

Let's be realistic: will the end user reading the CPS affect the 
actions in more that 0.000001% of PKI transactions? If a user has 
already loaded a root cert, there is essentially no chance that they 
will read a CPS after the fact.

I propose that you don't change anything.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA12166 for <[e-mail]>; Wed, 2 May 2001 10:18:45 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id TAA20266; Wed, 2 May 2001 19:18:36 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id TAA06062; Wed, 2 May 2001 19:18:13 +0200
Message-ID: <[e-mail]>
Date: Wed, 02 May 2001 19:18:15 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Jeff Jacoby <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: delta-CRLs
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jeff,

> Greetings,
> 
> I would like to suggest one minor addition (though perhaps painfully
> obvious to most) ...
> 
> Denis Pinkas wrote:
> >
> > David,
> >
> > On monday 23 April, I sent you the following long e-mail, and since I
> > got no
> > reply to it I would guess that you agree with it. So it is now the right
> > time to fix the text.  What follows is a full replacement proposal for
> > section 5.2.4. It simplifies the current text making it easier to read
> > and,
> > when delta CRLs are supported, only mandate the support of what you call
> > "the traditional method".
> >
> > 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
> 
> It's not obvious to me if this "previously issued CRL" is supposed to be
> the base CRL or if it's a prior delta CRL.  Would it be worthwhile to
> specifically say:
> 
>     "issuance of a specific, previously issued base CRL."

This is the correct answer. :-)

Denis

> Or if it can be either base CRL or delta CRL then perhaps the text
> should
> specifically say that.
> 
> [I have been unable to follow this thread is closely as I would like and
> so I apologize if this issue was clearly covered elsewhere/elsewhen.]
> 
> >    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.
> 
> [great big snip]
> 
> Jeff
> 
> --
> Jeff Jacoby, Sr. Programmer
> RSA Security Inc., SMDC
> 
> 2755 Campus Dr., Ste. 300       [e-mail]
> San Mateo, CA  94493            [phone]


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id KAA10759 for <[e-mail]>; Wed, 2 May 2001 10:05:05 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 2 May 2001 17:04:56 UT
Received: from tuna.rsa.com (tuna.rsa.com [10.80.211.153]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id NAA05370 for <[e-mail]>; Wed, 2 May 2001 13:05:06 -0400 (EDT)
Received: from rsasecurity.com ([10.81.217.242]) by tuna.rsa.com (8.8.8+Sun/8.8.8) with ESMTP id KAA18979 for <[e-mail]>; Wed, 2 May 2001 10:05:36 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 02 May 2001 10:04:26 -0700
From: Jeff Jacoby <[e-mail]>
Organization: RSA Security, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Re: delta-CRLs
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Greetings,

I would like to suggest one minor addition (though perhaps painfully 
obvious to most) ...

Denis Pinkas wrote:
> 
> David,
> 
> On monday 23 April, I sent you the following long e-mail, and since I
> got no
> reply to it I would guess that you agree with it. So it is now the right
> time to fix the text.  What follows is a full replacement proposal for
> section 5.2.4. It simplifies the current text making it easier to read
> and,
> when delta CRLs are supported, only mandate the support of what you call
> "the traditional method".
> 
> 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

It's not obvious to me if this "previously issued CRL" is supposed to be
the base CRL or if it's a prior delta CRL.  Would it be worthwhile to 
specifically say:

    "issuance of a specific, previously issued base CRL."

Or if it can be either base CRL or delta CRL then perhaps the text
should
specifically say that.  

[I have been unable to follow this thread is closely as I would like and
so I apologize if this issue was clearly covered elsewhere/elsewhen.]

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

[great big snip]

Jeff

-- 
Jeff Jacoby, Sr. Programmer
RSA Security Inc., SMDC

2755 Campus Dr., Ste. 300	[e-mail]
San Mateo, CA  94493		[phone]


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA05943 for <[e-mail]>; Wed, 2 May 2001 09:13:16 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA46520; Wed, 2 May 2001 18:13:06 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id SAA18736; Wed, 2 May 2001 18:12:42 +0200
Message-ID: <[e-mail]>
Date: Wed, 02 May 2001 18:12:45 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail]
Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Russ,

This is fine in general. I would however prefer to move the two first
sentences from 6.1 at the end of 6.1. This would lead to:

    The path validation process determines the set of certificate policies
    that are valid for this path, based on the certificate policies
    extension, policy mapping extension, policy constraints extension,
    and inhibit any-policy extension.  To achieve this, the path
    validation algorithm constructs a valid policy tree.  If the set of
    certificate policies that are valid for this path is not empty, then
    the result will be a valid policy tree of depth n, otherwise the
    result will be a null valid policy tree. A particular certification 
    path may not, however, be appropriate for all applications.  
    Therefore, an application MAY augment this algorithm to further 
    limit the set of valid paths.

Regards,

Denis 

> Denis:
> 
> I agree with Steve Hanna's observation.  However, I think that we can
> include a bit of notice in section 6.1.  I propose the following
> replacement paragraph:
> 
>     A particular certification path may not, however, be appropriate for
>     all applications.  Therefore, an application MAY augment this
>     algorithm to further limit the set of valid paths.  The path
>     validation process also determines the set of certificate policies
>     that are valid for this path, based on the certificate policies
>     extension, policy mapping extension, policy constraints extension,
>     and inhibit any-policy extension.  To achieve this, the path
>     validation algorithm constructs a valid policy tree.  If the set of
>     certificate policies that are valid for this path is not empty, then
>     the result will be a valid policy tree of depth n, otherwise the
>     result will be a null valid policy tree.
> 
> I suggest that we replace the first paragraph of section 6.2. with:
> 
>     The path validation algorithm describes the process of validating a
>     single certification path.  While each certification path begins with
>     a specific trust anchor, there is no requirement that all
>     certification paths validated by a particular system share a single
>     trust anchor.  An implementation that supports multiple trust anchors
>     MAY augment the algorithm presented in section 6.1 to further limit
>     the set of valid certification paths which begin with a particular
>     trust anchor.  For example, an implementation MAY modify the
>     algorithm to apply name constraints to a specific trust anchor during
>     the initialization phase, or the application MAY require the presence
>     of a particular alternative name form in the end entity certificate,
>     or the application MAY impose requirements on application-specific
>     extensions.  Thus, the path validation algorithm presented in section
>     6.1 defines the minimum conditions for a path to be considered valid.
> 
> Russ


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id IAA03635 for <[e-mail]>; Wed, 2 May 2001 08:57:58 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 2 May 2001 15:57:49 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA29606 for <[e-mail]>; Wed, 2 May 2001 11:57:54 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <JY8NT4WB>; Wed, 2 May 2001 11:57:53 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (housley-lap.securitydynamics.com [10.100.23.218]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JY8NT4V8; Wed, 2 May 2001 11:57:51 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 02 May 2001 11:39:41 -0400
Subject: Re: Basic constraints, key usage, and LDAP schema
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Terry:

In my view, certificates that contain public keys used to verify signatures 
on public key certificates or CRLs that contain revocation status 
information about public key certificates are CA certificates.  As such, 
the basic constraints extension should assert the cA bit, and they should 
be fetched from the cACertificate directory attribute.

Russ

  At 01:41 PM 5/1/2001 -0700, Terry Hayes wrote:
>Tim,
>
>I agree with your proposed solution.  As you have said, it separates the 
>semantics of the two extensions, and simplifies the rules for the LDAP schema.
>
>There is one remaining point to address, and I believe it may be the main 
>point of discussion in the current thread.
>
>When a CA uses the CRLDP extension to designate another entity to be the 
>source for revocation information about some of its certificates, should 
>that entity  have a "CA" certificate (with appropriate basicConstraints 
>extension)?  I'm *not* suggesting that a basicConstraints extension is 
>necessary for the entity to be authorized to sign the CRL.  Instead, the 
>problem is that clients that are trying to locate the certificate will not 
>know whether they should look in the cACertificate attribute or the 
>userCertificate attribute to find the appropriate certificate.
>
>To solve this, we can suggest that cACertificate be searched first, 
>followed by userCertificate, or we can require that designated entities 
>must always be a "CA", and the client can safely skip the userCertificate 
>attribute.  This is a question of searching the directory only, and does 
>not suggest changing your assertion that any set of bits may be set in the 
>keyUsage extension of "CA" certificates.
>
>Terry
>
>Tim Polk wrote:
>
>>Folks,
>>
>>I have been reading the email messages on the list about the 
>>relationships between basic constraints, key usage, and the schema.
>>After mulling over the problem.  I would like to propose a solution - the 
>>only solution, as far as I can tell...
>>
>>The solution is to simplify and separate the semantics of the basic 
>>constraints and key usage extension.  This has positive implications for 
>>the PKIX LDAP schema as well.
>>
>>Basic Constraints
>>
>>As stated in the current text for Basic Constraints (in 2459):  "The 
>>basic constraints extension identifies whether the subject of the 
>>certificate is a CA and how deep a certification path may exist through 
>>that CA."
>>
>>I believe this is the right semantics, and that basic constraints should 
>>be included and cA should be asserted in *any* certificate issued to a 
>>CA, regardless of the type or role associated with the public key in the 
>>certificate.
>>
>>Key Usage
>>
>>The issuer should use the Key Usage extension to disambiguate the 
>>subject's key pairs:
>>(a) The issuer indicates this public key may be used to verify the 
>>signature on a public key certificate by asserting keyCertSign.  (b) The 
>>issuer indicates this public key may be used to verify the signature on 
>>CRLs by asserting cRLSign.  (c) The issuer indicates that this public key 
>>may be used to establish symmetric keys with the subject by asserting 
>>either keyEncipherment or keyAgreement.  (d) The issuer indicates that 
>>this public key may be used to verify signatures on objects other than 
>>public key certificates and CRLs by asserting nonRerpuidation or 
>>digitalSignature.
>>
>>Of course, if a key pair is used for multiple purposes, multiple key 
>>usages may be asserted.
>>
>>In each of these cases, the basic constraints extension also appears in 
>>the certificate and asserts that the subject is a CA.
>>
>>LDAP Schema
>>
>>All certificates issued to CAs would be considered CA certificates since 
>>the basic constraints extension is present and asserts that the subject 
>>is a CA.  As a result, each of these could appear in the cACertificate 
>>attribute or crossCertificatePair attribute.  They would *not* appear in 
>>the userCertificate attribute.  (That would include all types (a) through 
>>(d) above).
>>
>>------------------
>>
>>The implications of this strategy are as follows: (1) when a client is 
>>searching for a CA certificate, they will not have to check the 
>>userCertificate attribute; (2) the issuer can indicate that the subject 
>>is a CA regardless of the key usage; and (3) minimal changes to the text 
>>(my favorite!).
>>
>>What do you think?
>>
>>Thanks,
>>
>>Tim Polk
>>
>>


Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA01852 for <[e-mail]>; Wed, 2 May 2001 08:42:43 -0700 (PDT)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id LAA27269; Wed, 2 May 2001 11:42:40 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 02 May 2001 11:40:34 -0400
To: Denis Pinkas <[e-mail]>, "David A. Cooper" <[e-mail]>, pkix <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: Re: delta-CRLs
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Denis,

Sorry about the silence from NIST.  I was supposed to write the 
reply.  Since you were out last week, I delayed writing the response to 
deal with other, more immediate, crises...

Anyway, the list has agreed that we should remove the requirement for 
issuing full CRLs with every delta.  Since we don't even require issuing 
CRLs at all, it would be inappropriate for us to be heavily prescriptive 
regarding *how* deltas must be implemented.  Basically, I believe the 
modifications you propose are out of scope.

I also should note that we (David Cooper & I) disagree with the 
requirements you have stated.  They seem to depart from the traditional 
deltas in certain details, but prevent use of sliding window deltas.  We 
can continue to discuss effective delta CRL strategies off-line, but I 
believe that no additional changes are required or appropriate in 
son-of-2459. (I do accept that we should remove the requirement for full 
CRLs with each delta.  I believe that reflects the consensus of the list as 
well.)

Thanks,

Tim Polk

At 04:43 PM 5/2/01 +0200, Denis Pinkas wrote:
>David,
>
>On monday 23 April, I sent you the following long e-mail, and since I got no
>reply to it I would guess that you agree with it. So it is now the right
>time to fix the text.  What follows is a full replacement proposal for
>section 5.2.4. It simplifies the current text making it easier to read and,
>when delta CRLs are supported, only mandate the support of what you call
>"the traditional method".
>
>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
>    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.
>
>    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.
>
>    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.
>
>    CAs must ensure that application of a delta CRL to the referenced
>    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:
>
>       (a) If a certificate was listed as revoked with revocation reason
>       certificateHold on a CRL (either a delta CRL or a CRL that is
>       complete for a given scope), and the hold is subsequently
>       released, the certificate must be listed with revocation reason
>       removeFromCRL until the next base CRL is issued.
>
>       Note: Should the certificate be subsequently revoked again for
>             one of the revocation reasons covered by the delta CRL,
>             then the certificate must be listed with the revocation
>             reason appropriate for the subsequent revocation.
>
>       (b) If the certificate was not removed from hold, but was
>       permanently revoked, then it must be listed as such on all
>       subsequent delta CRLs until the next base CRL is issued .
>
>    id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }
>
>    BaseCRLNumber ::= CRLNumber
>
>
>Regards,
>
>Denis
>
>==========================================================================
>
>This is a LONG e-mail and a last e-mail to you, before leaving for a trip
>that will keep me away from my e-mails during a week. So, don't think I am
>giving up if you do not receive a reply soon.
>
> > Denis,
> >
> > My comments are in line.
> >
> > At 06:50 PM 4/20/01 +0200, Denis Pinkas wrote:
> > >[Denis] This is the case I had in mind. However I would disagree to 
> say that
> > >the locally contructed CRL is equal to the full CRL number 8, because 
> there
> > >is no need to issue such CRL (see the first comment). It is simply the
> > >"freshest CRL constructed from the base CRL number 5 for 3:10 am". This
> > >locally contructed CRL bears no number, or if you assign one, this is a
> > >local matter and is not part of the standard. This also avoids the later
> > >confusing between CRL numbers.
>
>[David] This is simply not true.
>
>[Denis] The sentence above is technically correct: "It is simply the
>freshest CRL constructed from the base CRL number 5 for 3:10 am".
>
>[David] A delta-CRL can (will) contain the cRLNumber extension just as a
>full CRL will.
>
>[Denis] The cRLNumber extension is simply an identifier that allows you to
>uniquely identify it and to know whether it is earlier or later another CRL
>issued by the same CRL issuer.
>
>[David] If a full CRL and a delta-CRL are issued at the same time, the
>combination of the delta-CRL and an appropriate base CRL must be equivalent
>to the full CRL, and both the delta-CRL and the full CRL must have the same
>cRLNumber.
>
>[Denis] This is where we do not agree. The delta-CRL and the full CRL MUST
>NOT have the same cRLNumber because this would violate the definition of
>what is a CRLnumber. RFC 2459 says:
>
>5.2.3  CRL Number
>
>    The CRL number is a non-critical CRL extension which conveys a
>    monotonically increasing sequence number for each CRL issued by a CA.
>    This extension allows users to easily determine when a particular CRL
>    supersedes another CRL.  CAs conforming to this profile MUST include
>    this extension in all CRLs.
>
>Maybe you are making some confusion with the deltaCRLindicator.
>
>The construction you mention is not acceptable and is no even part of the
>ISO X509 document.
>
>[David] If a delta-CRL is issued, and no corresponding full CRL issued, then
>the combination of the delta-CRL and an appropriate base CRL should be
>equivalent to the full CRL that would have been issued at that time, if a
>full CRL had been issued.
>
>[Denis] Here is the problem ! Let us take an example: A base CRL
>is issued at midnight. thisUpdate is set to midnight while nextUpdate is
>midnight for the next day. This means that there is no guarantee at all that
>any other base/full CRL will necessarily be seen within the next 24 hours.
>Certainly a base can be issued before, but once again there is no guarantee
>that it will ever be seen. If someone is now using the CRL as a proof to be
>presented later on that the certificate was not revoked, a relying party
>is perfectly right to use the base from midnight (if allowed by the
>validation policy) or the base plus a delta (if mandated by the validation
>policy).
>
>Now if you issue a full CRL (I did not say a base CRL) every hour at the
>same time you issue a delta, the problem becomes worse because at 11:30 p.m.
>you have now 23 full CRLs, and you cannot know which one is the right one to
>use (if someone purposely is blocking the transmission of the latest full
>CRLs), unless precisely you introduce he statement that is the cause of all
>this trouble:
>
>    When a conforming CA issues a delta CRL, the CA MUST also issue a CRL
>    that is complete for the given scope.
>
>Now understand better the problem: this is a stone fundation of the whole
>edifice. If we take it away, the whole edifice collapses.
>
>Anyway, the intention has never been that relying parties will necessarilly
>get the same level of information when using only base CRLs and when using
>base CRLs plus deltas.
>
>The question which arises now is what are the implications if a full CRL is
>issued at the same time a delta is issued and when we apply the modified
>sentence:
>
>    When a conforming CA issues a delta CRL, the CA MAY also issue a full CRL
>    that is complete for the given scope.
>
>In this case the relying pary is using the delta (*in the way I have
>described it*), i.e. testing thisUpdate and nextUpdate from the delta CRL,
>it will get a GUARANTEE to obtain either the freshest revocation
>information or it will know that the freshest revocation information is not
>available.
>
>In the case the relying pary is using not using the delta, he will have no
>GUARANTEE that the information he got is the freshest.
>
>[David] The delta-CRL should have the same cRLNumber as would have been
>assigned to a full CRL issued at the same time.
>
>[Denis] Once again, I disagree, since this would violate the definition of
>CRL Number given in section 5.2.3.
>
>[David] A delta-CRL is nearly the same as a full CRL. It has a thisUpdate,
>nextUpdate, cRLNumber, etc. just as a full CRL. It just has an incomplete
>list of revoked certificates.
>
>[Denis] Yes, but you have to explain detail how a relying party will use
>thisUpdate, nextUpdate for a base CRL and thisUpdate, nextUpdate for a delta
>to make sure that in both cases he got the freshest information.
>
>Remember that RFC 2459 says:
>
>    The behavior of clients processing CRLs which
>    omit nextUpdate is not specified by this profile.
>
>So, in order to be PKIX compliant, you cannot escape a sentence which tells
>what use is made of that field.
>
> > > > A few hours later, at 6:30am, the relying party performs another 
> validation. The relying party has, in its local
>cache, the contents of CRL number 8 (which it constructed at 3:10am). It
>wants to update the information in its local case
>to based on the newly available revocation information. So, it obtains the
>latest delta-CRL. This delta-CRL has a CRL
>number of 11 and a BaseCRLnumber of 5. Since it has a BaseCRLNumber of 5,
>the delta-CRL provides status information for all
>certificates whose status has changed since CRL number 5 was issued.
>(midnight). So, clearly the delta-CRL provides status
>information for all certificates whose status has changed since 3:00am when
>CRL number 8 was issued. Thus, the relying
>party can combine the delta-CRL with its locally cached version of full CRL
>number 8 to obtain the contents of CRL number
>11. This is a case where the CRL number of the complete CRL used is greater
>than the BaseCRLNumber specified in the
>delta-CRL.
>
> > >[Denis] This is a local matter and I would not mandate this in the 
> document
> > >since there is another and simpler way to do it: you keep in the cache the
> > >base CRL (instead of the previously recontructed full CRL). This has the
> > >same end result, except that the method your recommend is not optimum: it
> > >will include many duplicates and deleting the duplicates is more painfull
> > >than making a simple addition.
>
>[David]  I'm not sure what you are saying is a local matter. The contents of
>the delta-CRL is not a local matter and must be mandated in the certificate
>and CRL profile. If you prefer to always apply the delta-CRLs to the
>referenced base CRL instead of to a locally generated, more recent CRL, that
>is your choice. The document states that the delta-CRL may be combined with
>the referenced base CRL or a more recently issued full CRL.
>
>[Denis]
>
>As said later, your paper provides the right answer (on page 1): " 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 text says " *a* specific, previously issued CRL", it does NOT say
>"or any, more recently, issued CRL". Now I understand that you may get the
>same final result (in a less efficient way), if such a CRL has been issued
>and if it could have been seen by the relying party. I would propose that we
>describe in the text, the basic rule. I would have no problem to mention in
>a note that the same result COULD also be obtained, IF a full CRL were
>issued
>after the base.
>
> > >The basic algorithm is to take the base CRL and to add the delta. This is
> > >the standard. As soon as you get the same end result this is fine. This is
> > >the approach we have taken for path validation. Other ways do not need 
> to be
> > >mentionned.
> > >
> > > > There are other reasons why the two numbers may not match, but I 
> will not go into them. If you are interested, you
>can read my paper.
> > >
> > >[Denis] I read it (and skipped the mathematical formulas)
> > >
> > >This paper is proposing a method for over-issuing the CRLs. It omits 
> to take
> > >into consideration that in PKIX-1 we mandate the CRL number extension
> > >(section 5.2.3) so we need to advertise the nextUpdate. If you issue a CRL
> > >before the next update you have no more way to know which base CRL is the
> > >freshest CRL. I believe this is a major security weakness and for that
> > >reason this mechanism should be deprecated.
>
>[David]  The paper does discuss over-issuing of CRLs, but there is plenty of
>information about using delta-CRLs efficiently without over-issuing. Bear in
>mind, however, that the nextUpdate field only specifies the time by which a
>new CRL will be issued. Many people intend to issue a new CRL whenever a
>revocation occurs (or a revocation for key compromise) without waiting until
>the regularly scheduled time.
>
>[Denis] As said earlier, without any guarantee that the fullCRL issued
>before nextUpdate will be seen until the validation time has passed
>nextUpdate.
>
> > >BTW, the same security problem would occur as soon as a base would be used
> > >for every delta. Hence another good reason to delete the sentence which
> > >originally triggered all this discussion.
> >
> > I don't understand this at all.
> >
> > >BTW, I noticed that you have precisely deleted from my previous e-mail all
> > >the text dealing with this nextUpdate. :-(
> > >
> > >So I am still insisting on the major text change to make to that section:
> > >
> > >    An application can construct a CRL that is the most current for
> > >    a given scope, at the current time, by retrieving the current
> > >    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 current date from that delta-CRL is between
> > >    thisUpdate and nextUpdate;
> > >
> > >It is important to notice that the algorithm does NOT use the 
> individual CRL
> > >numbers assigned to the delta-CRLs, but uses instead thisUpdate and
> > >nextUpdate. This is *very* important.
>
>[David]  I thought I did respond to this. First, one should expect that
>delta-CRLs will always be at least as recent as base CRLs. So the first step
>should be to obtain the current delta-CRL. Next, one obtains a base CRL that
>can be used in combination with that delta-CRL. You may choose to only use
>the full CRL whose cRLNumber is equal to the BaseCRLNumber specified in the
>delta-CRL, however, any full CRL with a cRLNumber greater than or equal to
>the BaseCRLNumber is acceptable.
>
>[Denis] Your algorithm is looking at the CRL Numbers only. My algorithm is
>looking at thisUpdate and nextUpdate only. This is a major difference. In
>particular you do not say how "to obtain the current delta-CRL".
>
>[David] Since the cRLNumber of the base can be greater than the specified
>BaseCRLNumber, the document should say so.
>
>[Denis] This can be mentionned in a note (see earlier).
>
>[David] There is no need to state that the current time must be after the
>thisUpdate time in the delta-CRL as this will always be true by
>construction.
>
>[Denis] There is definitively a need to state this because the end result of
>the two algorithms will not be identical as soon as someone will block some
>of the information coming from the repository where the full/base CRLs are
>stored or where the delta CRLs are stored.
>
>[David]  Finally, since a CRL issuer may issue "emergency" delta-CRLs, there
>is no guarantee that any delta-CRL whose nextUpdate time is later than the
>current time is the most current delta-CRL.
>
>[Denis] If you issue such "emergency" delta-CRLs then once again there is no
>guarantee that they will ever be seen. The "most recent delta-CRL" is any
>delta CRL which satisfies the following condition :
>
>" A delta-CRL which contains a Delta CRL Indicator equal to the cRLNumber of
>the base CRL and where the validation date (which may be the current time)
>is between thisUpdate and nextUpdate from that delta-CRL;"
>
> > > > >Finally we should explain what happens at the boundaries, i.e. 
> when a CA
> > > > >decides to generate a (new) base CRL. Here is a text proposal:
> > > > >
> > > > >   When issuing a base CRL that supports a delta-CRL mechanism 
> then the
> > > > >   CRL Issuer MUST at the same time issue a delta CRL that points 
> to that
> > > > >   base CRL. This first delta CRL will usually be empty (or will 
> include
> > > > >   last-minute additions to the base CRL).
>
> > > > This is not acceptable. The rule is that when a base CRL is issued 
> a delta-CRL must be issued that has the same
>cRLNumber. The base CRL referenced by the delta must either be the
>previously issued base CRL or a base CRL issued before
>that one. Since the new base and the delta must have the same cRLNumber,
>there can be no differences as a result of
>"last-minute additions to the base CRL".
>
> > >[Denis] This does not work. Let me explain it differently. Suppose that
> > >during the week you do not generate delta-CRLs but for the week-end you
> > >decide to do it (e.g. more risk, more transactions done by citizens). 
> So you
> > >issue a CRL with the freshest CRLindicator. You say that the delta 
> points to
> > >the previous base CRL. The one from yesterday or the one from last week ?
> > >In either case this simply does not work.
>
>[David]  Why? A delta-CRL must include a BaseCRLNumber that corresponds to a
>CRL that was issued at some time in the past.
>
>[Denis]  A delta-CRL must include a BaseCRLNumber that corresponds to a CRL
>that was issued at some time in the past *or to the current time*. The above
>example demonstrates that the rule does not work the first time you use it
>since there is no such past base CRL or an ambiguity about which one is the
>right one. Since it is not possible to answer the question I raised (i.e.
>does the first delta points to one from yesterday or the one from last
>week ?) this is one way to demonstrate that there is a problem.
>
> > >The rule you mention, i.e. "The rule is that when a base CRL is issued a
> > >delta-CRL must be issued that has the same cRLNumber" is also wrong. The
> > >notion of a base CRL that would have the same number as a delta does not
> > >exist.
>
> > > > >Suppose we issue a base CRL every midnight. The question is whether we
> > > > >should issue a delta and, if yes, does this delta refer to the 
> previous
> > > > >base or to the new one ?
>
> > > > The delta must refer either to the previous base or a base issued 
> before the previous base.
>
> > >[Denis] Certainly not. Your paper however provides the right answer
> > >(on page 1): " 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".
>
>[David] Where is the difference? A CRL that is referenced in the
>BaseCRLNumber of a delta-CRL is by definition a base CRL.
>
>[Denis] The difference lies in the fact that the sentence is using the
>wording "*a* specific, previously issued CRL". If it is *a* (i.e. one)
>specific CRL, it cannot be more than one.
>
> > > > >Suppose it refers to the previous one. According to the current 
> sentence:
> > > > >"The constructed CRL has the CRL number specified in the CRL number
> > > > >extension found in the delta CRL used in its construction.", it is
> > > > >impossible. If that was the case the delta CRL would have a CRL 
> number equal
> > > > >to the base CRL and it is not allowed for two CRLs to have the 
> same CRL
> > > > >number.
> > >
> > > > I think you are confusing two different extensions. The 
> deltaCRLIndicator extension contains a BaseCRLNumber which is
>used to determine against which base CRLs the delta-CRL can be applied. The
>cRLNumber extension specifies the CRL number of
>the full CRL that will be generated by applying the delta-CRL to a base CRL.
>The sentence above states that the CRL number
>of the constructed CRL is taken from the cRLNumber extension, not the
>BaseCRLNumber of the deltaCRLIndicator extension.
> > >
> > >[Denis] I do not think I make a confusion. The confusion comes from the
> > >numbering you introduce (see my earlier comment).
> > >
> > >Let me conclude:
> > >
> > >1) I do not have the time to spend hours of discussions on that topic.
> > >However the current text needs to be corrected and I have provided text
> > >for this. Please take again a look at it in the light of the following.
> > >
> > >2) In your paper you advertise the "traditional delta-CRLs". Let us 
> stay in
> > >the tradition and let us mandate the implementation of the "tradition" if
> > >someone wans to support the delta-CRL mechanism.
> > >
> > >Any other method would first need to be proven to be secure (over-issuing
> > >CRLs and sliding window delta-CRLs have security problems) and should
> > >*anyway* fall in the MAY category, so that noone needs to implement to 
> claim
> > >conformance with the delta CRL mechanism. Standard track documents need to
> > >make choices among multiple methods, otherwise two different 
> implementations
> > >will never interoperate.
>
>[David] you say that you want to stick with "traditional" delta-CRLs,
>however you are proposing changes to the text that would not result in
>"traditional" delta-CRLs but would result in broken implementations.
>
>[Denis] You have provided no evidence of what you say just above. Tell me
>precisely what is wrong in the text I propose that would not allow the
>support of the "traditional" delta-CRLs. If something is wrong, we can fix
>it.
>
>[David] We do not prevent people from implementing "traditional" delta-CRLs,
>but we should not force them to either.
>
>[Denis] We disagree here. Standards are there to support at least one
>(simple) method that all implementations have to support( if they support
>delta). In addition, implementations may support additional methods and it
>will be up to the final customer to decide which one to use. We MAY describe
>these additional methods, but MUST clearly indicate the difference.
>
>[David] There are no security problems with sliding window delta-CRLs and
>they do not add any complexity for those who choose not to
>implement them.
>
>[Denis] There ARE security problems with sliding window delta-CRLs. I have
>descibed at length what the problems are. However, this does not mean that
>this technique cannot be supported as an OPTIO and IF we indicate in the
>text what are their security problems. The current text places the two
>techniques at the same level. The traditional way offers a guarantee while
>the other does not. There is indedd added complexity for building the
>software from the relying party.
>
>[David]  I want to be sure that the delta-CRL text is correct just as you
>do,
>
>[Denis]  At least one point on which we both agree. :-)
>
>[David] ... but I still feel that many of your comments are based on a
>misunderstanding and are not based on actual problems in the text.
>
>[Denis] I do hope that after this response you will think differently.
>
>Regards,
>
>Denis
>
> > Dave



Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA26724 for <[e-mail]>; Wed, 2 May 2001 07:44:37 -0700 (PDT)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id KAA08401; Wed, 2 May 2001 10:44:35 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 02 May 2001 10:42:30 -0400
To: Denis Pinkas <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: Re: Basic constraints, key usage, and LDAP schema
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Denis,

These messages have been flying fast and furious under several topic 
lines.  I don't believe I caught them all either!  As they are all related, 
it is difficult to resolve the issues one-by-one.  The separate solutions 
may combine to present new problems.  That was the rationale for the single 
comprehensive posting.

The real problems, in my opinion, are as follows:

(1) Consider a PKIX client, searching for a certificate to validate a 
particular CRL.  Under 2459, the client cannot guess whether the basic 
constraints extension will be present with the CA bit asserted.

If the key used to validate the CRL is also used to validate certificates, 
it will have basic constraints and assert cA is TRUE.  In this case, the 
certificate should be in the ca certificate attribute (or perhaps the cross 
certificate pairs).

If the key is not used to validate certificates, basic constraints will be 
omitted and the certificate will be stored in the user certificate attribute.

(2) If a PKIX client wishes to communicate with a CA for certificate 
management purposes (e.g., to request a new certificate, request 
revocation, or perhaps centralized key generation for key escrow scenarios) 
the client will need to validate the CA's signature and perhaps make use of 
the CA's key management key.  If the keys used for these transactions are 
also used to sign PKCs, the certs will be in the CA certificate 
attribute.  If the keys used for these purposes are not used to sign PKCs, 
there will be no indication that this entity is a CA and the certs will be 
stored in the user certificate attribute.

As above, the PKIX client does not know where to look for these 
certificates.  Where they are not used to sign PKCs, there will be no 
indication in the certificate that this entity is a CA at all.

(3) The attribute certificate profile is very clear regarding AC issuers 
versus PKC issuers. Section 4.5 states "the AC issuer's PKC MUST NOT have a 
basicConstraints extension with the cA BOOLEAN set to TRUE."

However, the combination of RFC 2459 and the attribute certificate profile 
does not permit an issuer to specify whether a subject can issue CRLs 
for  PKCs, ACs, or both.  This would provide us with an analogous solution: 
if the CA bit is not asserted, but the cRLSign bit is set in key usage, the 
subject is only permitted to issue CRLs for ACs.

To be honest, (3) is the least compelling problem.  The CA must explicitly 
name an indirect CRL issuer in PKCs it issues *anyway*, so the CA bit isn't 
a big security issue.  Still, I think it is nice to supply clients with 
this information.

Anyway, I hope this clarifies things a bit.  My goal was to resolve all 
three problems simultaneously and consistently.

Thanks,

Tim Polk

At 03:14 PM 5/2/01 +0200, Denis Pinkas wrote:
>Tim,
>
>I stayed silent on that topic and it is quite hard to catch all the e-mails
>related to it. I certainly missed or skipped missed some of them.
>
> > Terry,
> >
> > I think it would be best if the client did not need to check the
> > userCertificate attribute to validate CRLs.  This adds complexity without
> > any real benefit (in my opinion.)  I have included some proposed text for
> > the first paragraph of section 4.2.1.10 (basic constraints) that would
> > clarify the issue.
> >
> > ----------------proposed text for first paragraph of 
> 4.2.1.10----------------
> >
> > The basic constraints extension identifies whether the subject of the
> > certificate is a CA and the maximum depth of valid certification paths that
> > include this certificate.  A subject is considered a CA if it issues public
> > key certificates or CRLs that describe the revocation status of public key
> > certificates.
> >
> > ----------------------end proposed text
> > What do you think?
>
>RFC 2459 only said:
>
>    The basic constraints extension identifies whether the subject of the
>    certificate is a CA and how deep a certification path may exist
>    through that CA.
>
>However, according to the new text a "CRL Issuer" is now also a "CA": " A
>subject is considered a CA if it issues public key certificates or CRLs that
>describe the revocation status of public key certificates."
>
>The current text of new-part1-06 also goes in the same direction.
>
>    The cA bit indicates if the certified public key may be used to
>    verify signatures on other certificates.  If the cA bit is asserted,
>    then either the keyCertSign bit or the cRLSign bit in the key usage
>    extension (see 4.2.1.3) MUST also be asserted. If the cA bit is not
>    asserted, then both the keyCertSign bit and the cRLSign in the key
>    usage extension MUST NOT be asserted.
>
>This seems quite strange. A CRL issuer is just one way to make available
>revocation status information. OCSP is another way. RFC 2560 says:
>
>    OCSP signing delegation SHALL be designated by the
>    inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate
>    extension included in the OCSP response signer's certificate.  This
>    certificate MUST be issued directly by the CA that issued the
>    certificate in question.
>
>If a "CRL issuer" is a "CA", why should an OCSP responder designated by a CA
>not also be a "CA" ?
>
>As far as I remember, originally the cA boolean in the basic constraints
>extension only allowed to make the difference between leaf certificates and
>CA certificates. This boolean now seems to be be used with a different
>meaning (and, maybe, we should change its meaning - not the syntax).
>
>Could someone say again, why that change was requested and what are the real
>benefits of that change ?
>
>In other words, could someone say again what the problem was ? :-)
>
>Thanks,
>
>Denis
>
> > Thanks,
> >
> > Tim Polk
> >
> > At 01:41 PM 5/1/01 -0700, Terry Hayes wrote:
> > >Tim,
> > >
> > >I agree with your proposed solution.  As you have said, it separates the
> > >semantics of the two extensions, and simplifies the rules for the LDAP 
> schema.
> > >
> > >There is one remaining point to address, and I believe it may be the main
> > >point of discussion in the current thread.
> > >
> > >When a CA uses the CRLDP extension to designate another entity to be the
> > >source for revocation information about some of its certificates, should
> > >that entity  have a "CA" certificate (with appropriate basicConstraints
> > >extension)?  I'm *not* suggesting that a basicConstraints extension is
> > >necessary for the entity to be authorized to sign the CRL.  Instead, the
> > >problem is that clients that are trying to locate the certificate will not
> > >know whether they should look in the cACertificate attribute or the
> > >userCertificate attribute to find the appropriate certificate.
> > >
> > >To solve this, we can suggest that cACertificate be searched first,
> > >followed by userCertificate, or we can require that designated entities
> > >must always be a "CA", and the client can safely skip the userCertificate
> > >attribute.  This is a question of searching the directory only, and does
> > >not suggest changing your assertion that any set of bits may be set in the
> > >keyUsage extension of "CA" certificates.
> > >
> > >Terry
> > >
> > >Tim Polk wrote:
> > >
> > >>Folks,
> > >>
> > >>I have been reading the email messages on the list about the
> > >>relationships between basic constraints, key usage, and the schema.
> > >>After mulling over the problem.  I would like to propose a solution - the
> > >>only solution, as far as I can tell...
> > >>
> > >>The solution is to simplify and separate the semantics of the basic
> > >>constraints and key usage extension.  This has positive implications for
> > >>the PKIX LDAP schema as well.
> > >>
> > >>Basic Constraints
> > >>
> > >>As stated in the current text for Basic Constraints (in 2459):  "The
> > >>basic constraints extension identifies whether the subject of the
> > >>certificate is a CA and how deep a certification path may exist through
> > >>that CA."
> > >>
> > >>I believe this is the right semantics, and that basic constraints should
> > >>be included and cA should be asserted in *any* certificate issued to a
> > >>CA, regardless of the type or role associated with the public key in the
> > >>certificate.
> > >>
> > >>Key Usage
> > >>
> > >>The issuer should use the Key Usage extension to disambiguate the
> > >>subject's key pairs:
> > >>(a) The issuer indicates this public key may be used to verify the
> > >>signature on a public key certificate by asserting keyCertSign.  (b) The
> > >>issuer indicates this public key may be used to verify the signature on
> > >>CRLs by asserting cRLSign.  (c) The issuer indicates that this public key
> > >>may be used to establish symmetric keys with the subject by asserting
> > >>either keyEncipherment or keyAgreement.  (d) The issuer indicates that
> > >>this public key may be used to verify signatures on objects other than
> > >>public key certificates and CRLs by asserting nonRerpuidation or
> > >>digitalSignature.
> > >>
> > >>Of course, if a key pair is used for multiple purposes, multiple key
> > >>usages may be asserted.
> > >>
> > >>In each of these cases, the basic constraints extension also appears in
> > >>the certificate and asserts that the subject is a CA.
> > >>
> > >>LDAP Schema
> > >>
> > >>All certificates issued to CAs would be considered CA certificates since
> > >>the basic constraints extension is present and asserts that the subject
> > >>is a CA.  As a result, each of these could appear in the cACertificate
> > >>attribute or crossCertificatePair attribute.  They would *not* appear in
> > >>the userCertificate attribute.  (That would include all types (a) through
> > >>(d) above).
> > >>
> > >>------------------
> > >>
> > >>The implications of this strategy are as follows: (1) when a client is
> > >>searching for a CA certificate, they will not have to check the
> > >>userCertificate attribute; (2) the issuer can indicate that the subject
> > >>is a CA regardless of the key usage; and (3) minimal changes to the text
> > >>(my favorite!).
> > >>
> > >>What do you think?
> > >>
> > >>Thanks,
> > >>
> > >>Tim Polk
> > >>
> > >>
> > >
> > >



Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA26616 for <[e-mail]>; Wed, 2 May 2001 07:43:35 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA41588; Wed, 2 May 2001 16:43:24 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id QAA09692; Wed, 2 May 2001 16:43:00 +0200
Message-ID: <[e-mail]>
Date: Wed, 02 May 2001 16:43:02 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "David A. Cooper" <[e-mail]>, pkix <[e-mail]>
Subject: Re: delta-CRLs
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

David,

On monday 23 April, I sent you the following long e-mail, and since I got no
reply to it I would guess that you agree with it. So it is now the right
time to fix the text.  What follows is a full replacement proposal for
section 5.2.4. It simplifies the current text making it easier to read and,
when delta CRLs are supported, only mandate the support of what you call
"the traditional method".

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

   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.

   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.

   CAs must ensure that application of a delta CRL to the referenced
   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:

      (a) If a certificate was listed as revoked with revocation reason
      certificateHold on a CRL (either a delta CRL or a CRL that is
      complete for a given scope), and the hold is subsequently 
      released, the certificate must be listed with revocation reason 
      removeFromCRL until the next base CRL is issued.

      Note: Should the certificate be subsequently revoked again for 
            one of the revocation reasons covered by the delta CRL, 
            then the certificate must be listed with the revocation 
            reason appropriate for the subsequent revocation.

      (b) If the certificate was not removed from hold, but was
      permanently revoked, then it must be listed as such on all 
      subsequent delta CRLs until the next base CRL is issued .

   id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }

   BaseCRLNumber ::= CRLNumber


Regards,

Denis

==========================================================================

This is a LONG e-mail and a last e-mail to you, before leaving for a trip
that will keep me away from my e-mails during a week. So, don't think I am
giving up if you do not receive a reply soon.

> Denis,
> 
> My comments are in line.
> 
> At 06:50 PM 4/20/01 +0200, Denis Pinkas wrote:
> >[Denis] This is the case I had in mind. However I would disagree to say that
> >the locally contructed CRL is equal to the full CRL number 8, because there
> >is no need to issue such CRL (see the first comment). It is simply the
> >"freshest CRL constructed from the base CRL number 5 for 3:10 am". This
> >locally contructed CRL bears no number, or if you assign one, this is a
> >local matter and is not part of the standard. This also avoids the later
> >confusing between CRL numbers.
 
[David] This is simply not true. 

[Denis] The sentence above is technically correct: "It is simply the
freshest CRL constructed from the base CRL number 5 for 3:10 am".
 
[David] A delta-CRL can (will) contain the cRLNumber extension just as a
full CRL will. 

[Denis] The cRLNumber extension is simply an identifier that allows you to
uniquely identify it and to know whether it is earlier or later another CRL
issued by the same CRL issuer.

[David] If a full CRL and a delta-CRL are issued at the same time, the
combination of the delta-CRL and an appropriate base CRL must be equivalent
to the full CRL, and both the delta-CRL and the full CRL must have the same
cRLNumber. 

[Denis] This is where we do not agree. The delta-CRL and the full CRL MUST
NOT have the same cRLNumber because this would violate the definition of
what is a CRLnumber. RFC 2459 says: 

5.2.3  CRL Number

   The CRL number is a non-critical CRL extension which conveys a
   monotonically increasing sequence number for each CRL issued by a CA.
   This extension allows users to easily determine when a particular CRL
   supersedes another CRL.  CAs conforming to this profile MUST include
   this extension in all CRLs.

Maybe you are making some confusion with the deltaCRLindicator. 

The construction you mention is not acceptable and is no even part of the
ISO X509 document.

[David] If a delta-CRL is issued, and no corresponding full CRL issued, then
the combination of the delta-CRL and an appropriate base CRL should be
equivalent to the full CRL that would have been issued at that time, if a
full CRL had been issued. 

[Denis] Here is the problem ! Let us take an example: A base CRL
is issued at midnight. thisUpdate is set to midnight while nextUpdate is
midnight for the next day. This means that there is no guarantee at all that
any other base/full CRL will necessarily be seen within the next 24 hours.
Certainly a base can be issued before, but once again there is no guarantee
that it will ever be seen. If someone is now using the CRL as a proof to be
presented later on that the certificate was not revoked, a relying party 
is perfectly right to use the base from midnight (if allowed by the
validation policy) or the base plus a delta (if mandated by the validation
policy).    

Now if you issue a full CRL (I did not say a base CRL) every hour at the
same time you issue a delta, the problem becomes worse because at 11:30 p.m.
you have now 23 full CRLs, and you cannot know which one is the right one to
use (if someone purposely is blocking the transmission of the latest full
CRLs), unless precisely you introduce he statement that is the cause of all
this trouble:

   When a conforming CA issues a delta CRL, the CA MUST also issue a CRL
   that is complete for the given scope.  

Now understand better the problem: this is a stone fundation of the whole
edifice. If we take it away, the whole edifice collapses.

Anyway, the intention has never been that relying parties will necessarilly
get the same level of information when using only base CRLs and when using
base CRLs plus deltas.

The question which arises now is what are the implications if a full CRL is
issued at the same time a delta is issued and when we apply the modified
sentence:

   When a conforming CA issues a delta CRL, the CA MAY also issue a full CRL
   that is complete for the given scope.  

In this case the relying pary is using the delta (*in the way I have
described it*), i.e. testing thisUpdate and nextUpdate from the delta CRL,
it will get a GUARANTEE to obtain either the freshest revocation
information or it will know that the freshest revocation information is not
available.

In the case the relying pary is using not using the delta, he will have no
GUARANTEE that the information he got is the freshest.

[David] The delta-CRL should have the same cRLNumber as would have been
assigned to a full CRL issued at the same time.

[Denis] Once again, I disagree, since this would violate the definition of
CRL Number given in section 5.2.3. 
 
[David] A delta-CRL is nearly the same as a full CRL. It has a thisUpdate,
nextUpdate, cRLNumber, etc. just as a full CRL. It just has an incomplete
list of revoked certificates.

[Denis] Yes, but you have to explain detail how a relying party will use
thisUpdate, nextUpdate for a base CRL and thisUpdate, nextUpdate for a delta
to make sure that in both cases he got the freshest information.

Remember that RFC 2459 says:

   The behavior of clients processing CRLs which
   omit nextUpdate is not specified by this profile.

So, in order to be PKIX compliant, you cannot escape a sentence which tells
what use is made of that field.

> > > A few hours later, at 6:30am, the relying party performs another validation. The relying party has, in its local
cache, the contents of CRL number 8 (which it constructed at 3:10am). It
wants to update the information in its local case
to based on the newly available revocation information. So, it obtains the
latest delta-CRL. This delta-CRL has a CRL
number of 11 and a BaseCRLnumber of 5. Since it has a BaseCRLNumber of 5,
the delta-CRL provides status information for all
certificates whose status has changed since CRL number 5 was issued.
(midnight). So, clearly the delta-CRL provides status
information for all certificates whose status has changed since 3:00am when
CRL number 8 was issued. Thus, the relying
party can combine the delta-CRL with its locally cached version of full CRL
number 8 to obtain the contents of CRL number
11. This is a case where the CRL number of the complete CRL used is greater
than the BaseCRLNumber specified in the
delta-CRL.

> >[Denis] This is a local matter and I would not mandate this in the document
> >since there is another and simpler way to do it: you keep in the cache the
> >base CRL (instead of the previously recontructed full CRL). This has the
> >same end result, except that the method your recommend is not optimum: it
> >will include many duplicates and deleting the duplicates is more painfull
> >than making a simple addition.
 
[David]  I'm not sure what you are saying is a local matter. The contents of
the delta-CRL is not a local matter and must be mandated in the certificate
and CRL profile. If you prefer to always apply the delta-CRLs to the
referenced base CRL instead of to a locally generated, more recent CRL, that
is your choice. The document states that the delta-CRL may be combined with
the referenced base CRL or a more recently issued full CRL.

[Denis] 

As said later, your paper provides the right answer (on page 1): " 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 text says " *a* specific, previously issued CRL", it does NOT say
"or any, more recently, issued CRL". Now I understand that you may get the
same final result (in a less efficient way), if such a CRL has been issued
and if it could have been seen by the relying party. I would propose that we
describe in the text, the basic rule. I would have no problem to mention in
a note that the same result COULD also be obtained, IF a full CRL were
issued
after the base.

> >The basic algorithm is to take the base CRL and to add the delta. This is
> >the standard. As soon as you get the same end result this is fine. This is
> >the approach we have taken for path validation. Other ways do not need to be
> >mentionned.
> >
> > > There are other reasons why the two numbers may not match, but I will not go into them. If you are interested, you
can read my paper.
> >
> >[Denis] I read it (and skipped the mathematical formulas)
> >
> >This paper is proposing a method for over-issuing the CRLs. It omits to take
> >into consideration that in PKIX-1 we mandate the CRL number extension
> >(section 5.2.3) so we need to advertise the nextUpdate. If you issue a CRL
> >before the next update you have no more way to know which base CRL is the
> >freshest CRL. I believe this is a major security weakness and for that
> >reason this mechanism should be deprecated.

[David]  The paper does discuss over-issuing of CRLs, but there is plenty of
information about using delta-CRLs efficiently without over-issuing. Bear in
mind, however, that the nextUpdate field only specifies the time by which a
new CRL will be issued. Many people intend to issue a new CRL whenever a
revocation occurs (or a revocation for key compromise) without waiting until
the regularly scheduled time.

[Denis] As said earlier, without any guarantee that the fullCRL issued
before nextUpdate will be seen until the validation time has passed
nextUpdate. 

> >BTW, the same security problem would occur as soon as a base would be used
> >for every delta. Hence another good reason to delete the sentence which
> >originally triggered all this discussion.
> 
> I don't understand this at all.
> 
> >BTW, I noticed that you have precisely deleted from my previous e-mail all
> >the text dealing with this nextUpdate. :-(
> >
> >So I am still insisting on the major text change to make to that section:
> >
> >    An application can construct a CRL that is the most current for
> >    a given scope, at the current time, by retrieving the current
> >    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 current date from that delta-CRL is between
> >    thisUpdate and nextUpdate;
> >
> >It is important to notice that the algorithm does NOT use the individual CRL
> >numbers assigned to the delta-CRLs, but uses instead thisUpdate and
> >nextUpdate. This is *very* important.
 
[David]  I thought I did respond to this. First, one should expect that
delta-CRLs will always be at least as recent as base CRLs. So the first step
should be to obtain the current delta-CRL. Next, one obtains a base CRL that
can be used in combination with that delta-CRL. You may choose to only use
the full CRL whose cRLNumber is equal to the BaseCRLNumber specified in the
delta-CRL, however, any full CRL with a cRLNumber greater than or equal to
the BaseCRLNumber is acceptable. 

[Denis] Your algorithm is looking at the CRL Numbers only. My algorithm is
looking at thisUpdate and nextUpdate only. This is a major difference. In
particular you do not say how "to obtain the current delta-CRL".

[David] Since the cRLNumber of the base can be greater than the specified
BaseCRLNumber, the document should say so. 

[Denis] This can be mentionned in a note (see earlier).  

[David] There is no need to state that the current time must be after the
thisUpdate time in the delta-CRL as this will always be true by
construction. 

[Denis] There is definitively a need to state this because the end result of
the two algorithms will not be identical as soon as someone will block some
of the information coming from the repository where the full/base CRLs are
stored or where the delta CRLs are stored.

[David]  Finally, since a CRL issuer may issue "emergency" delta-CRLs, there
is no guarantee that any delta-CRL whose nextUpdate time is later than the
current time is the most current delta-CRL.

[Denis] If you issue such "emergency" delta-CRLs then once again there is no
guarantee that they will ever be seen. The "most recent delta-CRL" is any
delta CRL which satisfies the following condition :

" A delta-CRL which contains a Delta CRL Indicator equal to the cRLNumber of
the base CRL and where the validation date (which may be the current time)
is between thisUpdate and nextUpdate from that delta-CRL;"
 
> > > >Finally we should explain what happens at the boundaries, i.e. when a CA
> > > >decides to generate a (new) base CRL. Here is a text proposal:
> > > >
> > > >   When issuing a base CRL that supports a delta-CRL mechanism then the
> > > >   CRL Issuer MUST at the same time issue a delta CRL that points to that
> > > >   base CRL. This first delta CRL will usually be empty (or will include
> > > >   last-minute additions to the base CRL).

> > > This is not acceptable. The rule is that when a base CRL is issued a delta-CRL must be issued that has the same
cRLNumber. The base CRL referenced by the delta must either be the
previously issued base CRL or a base CRL issued before
that one. Since the new base and the delta must have the same cRLNumber,
there can be no differences as a result of
"last-minute additions to the base CRL".

> >[Denis] This does not work. Let me explain it differently. Suppose that
> >during the week you do not generate delta-CRLs but for the week-end you
> >decide to do it (e.g. more risk, more transactions done by citizens). So you
> >issue a CRL with the freshest CRLindicator. You say that the delta points to
> >the previous base CRL. The one from yesterday or the one from last week ?
> >In either case this simply does not work.
 
[David]  Why? A delta-CRL must include a BaseCRLNumber that corresponds to a
CRL that was issued at some time in the past.

[Denis]  A delta-CRL must include a BaseCRLNumber that corresponds to a CRL
that was issued at some time in the past *or to the current time*. The above
example demonstrates that the rule does not work the first time you use it
since there is no such past base CRL or an ambiguity about which one is the
right one. Since it is not possible to answer the question I raised (i.e.
does the first delta points to one from yesterday or the one from last 
week ?) this is one way to demonstrate that there is a problem.

> >The rule you mention, i.e. "The rule is that when a base CRL is issued a
> >delta-CRL must be issued that has the same cRLNumber" is also wrong. The
> >notion of a base CRL that would have the same number as a delta does not
> >exist.

> > > >Suppose we issue a base CRL every midnight. The question is whether we
> > > >should issue a delta and, if yes, does this delta refer to the previous
> > > >base or to the new one ?

> > > The delta must refer either to the previous base or a base issued before the previous base.

> >[Denis] Certainly not. Your paper however provides the right answer
> >(on page 1): " 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".
 
[David] Where is the difference? A CRL that is referenced in the
BaseCRLNumber of a delta-CRL is by definition a base CRL.

[Denis] The difference lies in the fact that the sentence is using the
wording "*a* specific, previously issued CRL". If it is *a* (i.e. one)
specific CRL, it cannot be more than one.
 
> > > >Suppose it refers to the previous one. According to the current sentence:
> > > >"The constructed CRL has the CRL number specified in the CRL number
> > > >extension found in the delta CRL used in its construction.", it is
> > > >impossible. If that was the case the delta CRL would have a CRL number equal
> > > >to the base CRL and it is not allowed for two CRLs to have the same CRL
> > > >number.
> >
> > > I think you are confusing two different extensions. The deltaCRLIndicator extension contains a BaseCRLNumber which is
used to determine against which base CRLs the delta-CRL can be applied. The
cRLNumber extension specifies the CRL number of
the full CRL that will be generated by applying the delta-CRL to a base CRL.
The sentence above states that the CRL number
of the constructed CRL is taken from the cRLNumber extension, not the
BaseCRLNumber of the deltaCRLIndicator extension.
> >
> >[Denis] I do not think I make a confusion. The confusion comes from the
> >numbering you introduce (see my earlier comment).
> >
> >Let me conclude:
> >
> >1) I do not have the time to spend hours of discussions on that topic.
> >However the current text needs to be corrected and I have provided text
> >for this. Please take again a look at it in the light of the following.
> >
> >2) In your paper you advertise the "traditional delta-CRLs". Let us stay in
> >the tradition and let us mandate the implementation of the "tradition" if
> >someone wans to support the delta-CRL mechanism.
> >
> >Any other method would first need to be proven to be secure (over-issuing
> >CRLs and sliding window delta-CRLs have security problems) and should
> >*anyway* fall in the MAY category, so that noone needs to implement to claim
> >conformance with the delta CRL mechanism. Standard track documents need to
> >make choices among multiple methods, otherwise two different implementations
> >will never interoperate.
 
[David] you say that you want to stick with "traditional" delta-CRLs,
however you are proposing changes to the text that would not result in
"traditional" delta-CRLs but would result in broken implementations. 

[Denis] You have provided no evidence of what you say just above. Tell me
precisely what is wrong in the text I propose that would not allow the
support of the "traditional" delta-CRLs. If something is wrong, we can fix
it.

[David] We do not prevent people from implementing "traditional" delta-CRLs,
but we should not force them to either. 

[Denis] We disagree here. Standards are there to support at least one
(simple) method that all implementations have to support( if they support
delta). In addition, implementations may support additional methods and it
will be up to the final customer to decide which one to use. We MAY describe
these additional methods, but MUST clearly indicate the difference.
 
[David] There are no security problems with sliding window delta-CRLs and
they do not add any complexity for those who choose not to
implement them.

[Denis] There ARE security problems with sliding window delta-CRLs. I have
descibed at length what the problems are. However, this does not mean that
this technique cannot be supported as an OPTIO and IF we indicate in the
text what are their security problems. The current text places the two
techniques at the same level. The traditional way offers a guarantee while
the other does not. There is indedd added complexity for building the
software from the relying party. 

[David]  I want to be sure that the delta-CRL text is correct just as you
do, 

[Denis]  At least one point on which we both agree. :-)

[David] ... but I still feel that many of your comments are based on a
misunderstanding and are not based on actual problems in the text.

[Denis] I do hope that after this response you will think differently.

Regards,

Denis

> Dave


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA20037 for <[e-mail]>; Wed, 2 May 2001 06:14:06 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA31132; Wed, 2 May 2001 15:13:56 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id PAA18634; Wed, 2 May 2001 15:13:33 +0200
Message-ID: <[e-mail]>
Date: Wed, 02 May 2001 15:14:04 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Tim Polk <[e-mail]>
CC: [e-mail]
Subject: Re: Basic constraints, key usage, and LDAP schema
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tim,

I stayed silent on that topic and it is quite hard to catch all the e-mails
related to it. I certainly missed or skipped missed some of them.
 
> Terry,
> 
> I think it would be best if the client did not need to check the
> userCertificate attribute to validate CRLs.  This adds complexity without
> any real benefit (in my opinion.)  I have included some proposed text for
> the first paragraph of section 4.2.1.10 (basic constraints) that would
> clarify the issue.
> 
> ----------------proposed text for first paragraph of 4.2.1.10----------------
> 
> The basic constraints extension identifies whether the subject of the
> certificate is a CA and the maximum depth of valid certification paths that
> include this certificate.  A subject is considered a CA if it issues public
> key certificates or CRLs that describe the revocation status of public key
> certificates.
> 
> ----------------------end proposed text
> What do you think?

RFC 2459 only said:

   The basic constraints extension identifies whether the subject of the
   certificate is a CA and how deep a certification path may exist
   through that CA.

However, according to the new text a "CRL Issuer" is now also a "CA": " A
subject is considered a CA if it issues public key certificates or CRLs that
describe the revocation status of public key certificates."

The current text of new-part1-06 also goes in the same direction.

   The cA bit indicates if the certified public key may be used to
   verify signatures on other certificates.  If the cA bit is asserted,
   then either the keyCertSign bit or the cRLSign bit in the key usage
   extension (see 4.2.1.3) MUST also be asserted. If the cA bit is not
   asserted, then both the keyCertSign bit and the cRLSign in the key
   usage extension MUST NOT be asserted.

This seems quite strange. A CRL issuer is just one way to make available
revocation status information. OCSP is another way. RFC 2560 says:

   OCSP signing delegation SHALL be designated by the
   inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate
   extension included in the OCSP response signer's certificate.  This
   certificate MUST be issued directly by the CA that issued the
   certificate in question.

If a "CRL issuer" is a "CA", why should an OCSP responder designated by a CA
not also be a "CA" ?

As far as I remember, originally the cA boolean in the basic constraints
extension only allowed to make the difference between leaf certificates and
CA certificates. This boolean now seems to be be used with a different
meaning (and, maybe, we should change its meaning - not the syntax). 

Could someone say again, why that change was requested and what are the real
benefits of that change ?

In other words, could someone say again what the problem was ? :-)

Thanks,

Denis

> Thanks,
> 
> Tim Polk
> 
> At 01:41 PM 5/1/01 -0700, Terry Hayes wrote:
> >Tim,
> >
> >I agree with your proposed solution.  As you have said, it separates the
> >semantics of the two extensions, and simplifies the rules for the LDAP schema.
> >
> >There is one remaining point to address, and I believe it may be the main
> >point of discussion in the current thread.
> >
> >When a CA uses the CRLDP extension to designate another entity to be the
> >source for revocation information about some of its certificates, should
> >that entity  have a "CA" certificate (with appropriate basicConstraints
> >extension)?  I'm *not* suggesting that a basicConstraints extension is
> >necessary for the entity to be authorized to sign the CRL.  Instead, the
> >problem is that clients that are trying to locate the certificate will not
> >know whether they should look in the cACertificate attribute or the
> >userCertificate attribute to find the appropriate certificate.
> >
> >To solve this, we can suggest that cACertificate be searched first,
> >followed by userCertificate, or we can require that designated entities
> >must always be a "CA", and the client can safely skip the userCertificate
> >attribute.  This is a question of searching the directory only, and does
> >not suggest changing your assertion that any set of bits may be set in the
> >keyUsage extension of "CA" certificates.
> >
> >Terry
> >
> >Tim Polk wrote:
> >
> >>Folks,
> >>
> >>I have been reading the email messages on the list about the
> >>relationships between basic constraints, key usage, and the schema.
> >>After mulling over the problem.  I would like to propose a solution - the
> >>only solution, as far as I can tell...
> >>
> >>The solution is to simplify and separate the semantics of the basic
> >>constraints and key usage extension.  This has positive implications for
> >>the PKIX LDAP schema as well.
> >>
> >>Basic Constraints
> >>
> >>As stated in the current text for Basic Constraints (in 2459):  "The
> >>basic constraints extension identifies whether the subject of the
> >>certificate is a CA and how deep a certification path may exist through
> >>that CA."
> >>
> >>I believe this is the right semantics, and that basic constraints should
> >>be included and cA should be asserted in *any* certificate issued to a
> >>CA, regardless of the type or role associated with the public key in the
> >>certificate.
> >>
> >>Key Usage
> >>
> >>The issuer should use the Key Usage extension to disambiguate the
> >>subject's key pairs:
> >>(a) The issuer indicates this public key may be used to verify the
> >>signature on a public key certificate by asserting keyCertSign.  (b) The
> >>issuer indicates this public key may be used to verify the signature on
> >>CRLs by asserting cRLSign.  (c) The issuer indicates that this public key
> >>may be used to establish symmetric keys with the subject by asserting
> >>either keyEncipherment or keyAgreement.  (d) The issuer indicates that
> >>this public key may be used to verify signatures on objects other than
> >>public key certificates and CRLs by asserting nonRerpuidation or
> >>digitalSignature.
> >>
> >>Of course, if a key pair is used for multiple purposes, multiple key
> >>usages may be asserted.
> >>
> >>In each of these cases, the basic constraints extension also appears in
> >>the certificate and asserts that the subject is a CA.
> >>
> >>LDAP Schema
> >>
> >>All certificates issued to CAs would be considered CA certificates since
> >>the basic constraints extension is present and asserts that the subject
> >>is a CA.  As a result, each of these could appear in the cACertificate
> >>attribute or crossCertificatePair attribute.  They would *not* appear in
> >>the userCertificate attribute.  (That would include all types (a) through
> >>(d) above).
> >>
> >>------------------
> >>
> >>The implications of this strategy are as follows: (1) when a client is
> >>searching for a CA certificate, they will not have to check the
> >>userCertificate attribute; (2) the issuer can indicate that the subject
> >>is a CA regardless of the key usage; and (3) minimal changes to the text
> >>(my favorite!).
> >>
> >>What do you think?
> >>
> >>Thanks,
> >>
> >>Tim Polk
> >>
> >>
> >
> >


Received: from firewall ([211.205.65.125]) by above.proper.com (8.9.3/8.9.3) with SMTP id EAA12406 for <[e-mail]>; Wed, 2 May 2001 04:23:42 -0700 (PDT)
From: [e-mail]
Message-ID: <00002b9e68dc$00004044$[e-mail]>
To: <[e-mail]>
Subject: write back when you can                         21881
Date: Wed, 02 May 2001 04:25:39 -0700
MIME-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal

<HTML><HEAD><TITLE>Take Control Of Your Conference Calls</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dwindows-12=
52">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR></HEAD>
<BODY vLink=3D#c0c0c0 link=3D#c0c0c0 bgColor=3D#ffffff leftMargin=3D0><FON=
T 
face=3Darial,helvetica>
<P>
<CENTER>
<TABLE width=3D600 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><B><FONT color=3D#000066 size=3D6>Long Distance 
      Conferencing<BR>Only <U>18 Cents</U> Per 
Minute</B></FONT></TD></TR></TBODY></TABLE>
<P><FONT color=3D#ff0000 size=3D5><B>Connects Up To 100 Participants!</B><=
/FONT> 
<P>
<TABLE width=3D350 border=3D0>
  <TBODY>
  <TR>
    <TD><FONT size=3D3><B>
      <LI>No setup fees 
      <LI>No contracts or monthly fees 
      <LI>Call anytime, from anywhere, to anywhere 
      <LI>International Dial In 18 cents per minute 
      <LI>Simplicity in set up and administration 
      <LI>Operator Help available 24/7 </B></FONT></LI></TD></TR></TBODY><=
/TABLE>
<P>
<TABLE width=3D500 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT color=3D#ff0000 size=3D60><B><FONT size=3D5>G=
et the best 
      quality, the easiest to use, and lowest rate in the 
      industry.</B></FONT></FONT></TD></TR></TBODY></TABLE>
<P>
<TABLE width=3D400 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT color=3D#000066 size=3D4>If you like saving m=
oney, fill 
      out the form below and one of our consultants will contact 
  you.</FONT></TD></TR></TBODY></TABLE>
<P><FONT color=3D#000066 size=3D2>Required Input Field<FONT color=3D#ff000=
0 
size=3D2>*</FONT></FONT> 
<P>
<TABLE cellSpacing=3D0 borderColorDark=3D#333300 cellPadding=3D3 width=3D6=
00 
borderColorLight=3D#ffffcc>
  <TBODY>
  <TR>
    <TD align=3Dmiddle>
      <FORM action=3Dmailto:[e-mail]?subject=3DConference_Inquir=
y 
      method=3Dpost encType=3Dtext/plain>
      <TABLE width=3D"100%">
        <TBODY>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 
          size=3D2>Name*</FONT></TD>
          <TD><INPUT name=3DNAME></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Web 
            Address*</FONT></TD>
          <TD><INPUT value=3Dhttp:// name=3DURL></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Company 
            Name*</FONT></TD>
          <TD><INPUT name=3DCOMPANY_NAME></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Web 
            Address*</FONT></TD>
          <TD><INPUT size=3D2 name=3DSTATE></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Business 
            Phone*</FONT></TD>
          <TD><INPUT name=3DBUS_PHONE></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Home 
            Phone</FONT></TD>
          <TD><INPUT name=3DHOME_PHONE></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Email 
            Address*</FONT></TD>
          <TD><INPUT name=3DEMAIL></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Type of 
            Business</FONT></TD>
          <TD><INPUT name=3DTYPE_OF_BUSINESS></TD></TR></TBODY></TABLE>
      <P><INPUT type=3Dsubmit value=3D"Submit Information" name=3Dsubmit> 
    </FORM></P></TD></TR></TBODY></TABLE>
<P>
<TABLE width=3D500>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT face=3D"Arial, Helvetica, sans-serif" color=3D=
#000000 
      size=3D1>This email is to those persons that have contacted Conferen=
ce Calls 
      for Less regarding available services or product information. If thi=
s 
      email is reaching you in error and you feel that you have not contac=
ted 
      us, <FONT color=3D#666666><A 
      href=3D"mailto:[e-mail]?subject=3DRemove_Conferencing">C=
lick 
      here</A></FONT>. We will gladly remove you from our mailing 
      list.</FONT><BR></TD></TR></TBODY></TABLE></P></CENTER></FONT></BODY=
></HTML>






Received: from firewall ([211.205.65.125]) by above.proper.com (8.9.3/8.9.3) with SMTP id EAA12154 for <[e-mail]>; Wed, 2 May 2001 04:22:30 -0700 (PDT)
From: [e-mail]
Message-ID: <00002b9e68dc$00004044$[e-mail]>
To: <[e-mail]>
Subject: write back when you can                         21881
Date: Wed, 02 May 2001 04:24:27 -0700
MIME-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal

<HTML><HEAD><TITLE>Take Control Of Your Conference Calls</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dwindows-12=
52">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR></HEAD>
<BODY vLink=3D#c0c0c0 link=3D#c0c0c0 bgColor=3D#ffffff leftMargin=3D0><FON=
T 
face=3Darial,helvetica>
<P>
<CENTER>
<TABLE width=3D600 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><B><FONT color=3D#000066 size=3D6>Long Distance 
      Conferencing<BR>Only <U>18 Cents</U> Per 
Minute</B></FONT></TD></TR></TBODY></TABLE>
<P><FONT color=3D#ff0000 size=3D5><B>Connects Up To 100 Participants!</B><=
/FONT> 
<P>
<TABLE width=3D350 border=3D0>
  <TBODY>
  <TR>
    <TD><FONT size=3D3><B>
      <LI>No setup fees 
      <LI>No contracts or monthly fees 
      <LI>Call anytime, from anywhere, to anywhere 
      <LI>International Dial In 18 cents per minute 
      <LI>Simplicity in set up and administration 
      <LI>Operator Help available 24/7 </B></FONT></LI></TD></TR></TBODY><=
/TABLE>
<P>
<TABLE width=3D500 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT color=3D#ff0000 size=3D60><B><FONT size=3D5>G=
et the best 
      quality, the easiest to use, and lowest rate in the 
      industry.</B></FONT></FONT></TD></TR></TBODY></TABLE>
<P>
<TABLE width=3D400 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT color=3D#000066 size=3D4>If you like saving m=
oney, fill 
      out the form below and one of our consultants will contact 
  you.</FONT></TD></TR></TBODY></TABLE>
<P><FONT color=3D#000066 size=3D2>Required Input Field<FONT color=3D#ff000=
0 
size=3D2>*</FONT></FONT> 
<P>
<TABLE cellSpacing=3D0 borderColorDark=3D#333300 cellPadding=3D3 width=3D6=
00 
borderColorLight=3D#ffffcc>
  <TBODY>
  <TR>
    <TD align=3Dmiddle>
      <FORM action=3Dmailto:[e-mail]?subject=3DConference_Inquir=
y 
      method=3Dpost encType=3Dtext/plain>
      <TABLE width=3D"100%">
        <TBODY>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 
          size=3D2>Name*</FONT></TD>
          <TD><INPUT name=3DNAME></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Web 
            Address*</FONT></TD>
          <TD><INPUT value=3Dhttp:// name=3DURL></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Company 
            Name*</FONT></TD>
          <TD><INPUT name=3DCOMPANY_NAME></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Web 
            Address*</FONT></TD>
          <TD><INPUT size=3D2 name=3DSTATE></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Business 
            Phone*</FONT></TD>
          <TD><INPUT name=3DBUS_PHONE></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Home 
            Phone</FONT></TD>
          <TD><INPUT name=3DHOME_PHONE></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Email 
            Address*</FONT></TD>
          <TD><INPUT name=3DEMAIL></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Type of 
            Business</FONT></TD>
          <TD><INPUT name=3DTYPE_OF_BUSINESS></TD></TR></TBODY></TABLE>
      <P><INPUT type=3Dsubmit value=3D"Submit Information" name=3Dsubmit> 
    </FORM></P></TD></TR></TBODY></TABLE>
<P>
<TABLE width=3D500>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT face=3D"Arial, Helvetica, sans-serif" color=3D=
#000000 
      size=3D1>This email is to those persons that have contacted Conferen=
ce Calls 
      for Less regarding available services or product information. If thi=
s 
      email is reaching you in error and you feel that you have not contac=
ted 
      us, <FONT color=3D#666666><A 
      href=3D"mailto:[e-mail]?subject=3DRemove_Conferencing">C=
lick 
      here</A></FONT>. We will gladly remove you from our mailing 
      list.</FONT><BR></TD></TR></TBODY></TABLE></P></CENTER></FONT></BODY=
></HTML>






Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA09368 for <[e-mail]>; Wed, 2 May 2001 03:39:41 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA57898; Wed, 2 May 2001 12:39:31 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id MAA16538; Wed, 2 May 2001 12:39:07 +0200
Message-ID: <[e-mail]>
Date: Wed, 02 May 2001 12:39:38 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail]
Subject: Re: keyCertSign and cRLSign Key Usage Bits
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Russ,

In a reply to Santosh (April 24), you said:

> The IDP syntax is:
> 
>     issuingDistributionPoint ::= SEQUENCE {
>          distributionPoint       [0] DistributionPointName OPTIONAL,
>          onlyContainsUserCerts   [1] BOOLEAN DEFAULT FALSE,
>          onlyContainsCACerts     [2] BOOLEAN DEFAULT FALSE,
>          onlySomeReasons         [3] ReasonFlags OPTIONAL,
>          indirectCRL             [4] BOOLEAN DEFAULT FALSE }
> 
> I was simply suggesting that this extension be present if the CRL is signed
> with a key other than the one used to sign the certificate.  

The current text says (in section 5.2.5):

" 5.2.5  Issuing Distribution Point

   The issuing distribution point is a critical CRL extension that
   identifies the CRL distribution point for a particular CRL, and it
   indicates whether the CRL covers revocation for end entity
   certificates only, CA  certificates only, or a limited set of reason
   codes.  Although the extension is critical, conforming
   implementations are not required to support this extension.

   The CRL is signed using the CA's private key."

I would guess that the last sentence would thus need to be changed. So would
you have a text proposal to fix it ?

Regards,

Denis


> I would expect
> the distributionPoint field to be present (probably with a URL
> (ldap://...)).  The boolean flags would be set based on the contents of the
> CRL (probably all FALSE).  The reason codes would also be set based on the
> contents of the CRL (probably absent).
 
> Russ


Received: from david.siemens.it (david.siemens.it [192.109.0.136]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA09292 for <[e-mail]>; Wed, 2 May 2001 03:39:31 -0700 (PDT)
X-Envelope-Sender-Is: [e-mail] (at relayer david.siemens.it)
Received: from milano-b-qfe1.netz.sbs.de (milano-b.netz.sbs.de [192.109.0.135]) by david.siemens.it (8.11.0/8.11.0) with SMTP id f42AdUt15682 for <[e-mail]>; Wed, 2 May 2001 12:39:30 +0200 (MET DST)
Received: from mail.siemens.it ([194.138.237.200]) by milano-b-qfe1.netz.sbs.de via smtpd (for david.siemens.it [192.109.0.136]) with SMTP; 2 May 2001 10:39:30 UT
Received: from mir ([141.29.240.232]) by mail.siemens.it (8.11.0/8.11.0) with SMTP id f42AdUm13299 for <[e-mail]>; Wed, 2 May 2001 12:39:30 +0200 (MET DST)
Message-ID: <006101c0d2f4$86527d20$[e-mail]>
Reply-To: "Fabio Mazzocchi" <[e-mail]>
From: "Fabio Mazzocchi" <[e-mail]>
To: <[e-mail]>
Subject: About Key Usages...
Date: Wed, 2 May 2001 12:37:13 +0200
Organization: Siemens Informatica
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_005E_01C0D304.9CED6F30"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

This is a multi-part message in MIME format.

------=_NextPart_000_005E_01C0D304.9CED6F30
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi all,
I have a little question for you. I need to know if there is at least =
one combination of KeyUsage, Extended Key Usage, and Netscape CertType =
which let me use two certificate with Microsoft products as well as =
Netscape ones. I need a certificate to use with mail clients (Outlook =
and Messenger) and a certificate to work with browsers for SSL =
connections.
My idea was to generate the mail certificate with :

KU -> Digital Signature, Key Enciphrment
EKU -> EMail (1.3.6.1.5.5.7.3.4)
NetscapeExtension -> S/Mime

in the SSL certificate the extensions are :

KU -> Digital Signature
EKU -> EMail (1.3.6.1.5.5.7.3.2)
NetscapeExtension -> SSL Client Authentication

(none of the above extensions is critical)

With IE and Outlook, the certificates work fine, because Microsoft =
products mind just the EKU. With Netscape (4.76) and Messenger, I can =
just use SSL certificate.
How can I force the use of the mail certificate? Why Netscape doesn't =
mind the S/Mime extension?
Till now, the only solution I have found, is to force the usage of my =
mail certificate setting the KU extension as critical, but I don't think =
it is the best one. Have someone a best solution?

Thanks in advance.

Fabio.

------=_NextPart_000_005E_01C0D304.9CED6F30
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4522.1800" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>Hi all,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I have a little question for you. I =
need to know if=20
there is at least one combination of KeyUsage, Extended Key Usage, and =
Netscape=20
CertType which let me use two certificate with Microsoft products as =
well as=20
Netscape ones. I&nbsp;need a certificate to use with mail clients =
(Outlook and=20
Messenger) and a certificate to work with browsers for SSL=20
connections.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>My idea was to generate the mail =
certificate with=20
:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>KU -&gt; Digital Signature, Key=20
Enciphrment</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>EKU -&gt; EMail =
(1.3.6.1.5.5.7.3.4)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>NetscapeExtension -&gt; =
S/Mime</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>in&nbsp;the SSL certificate the =
extensions are=20
:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>
<DIV><FONT face=3DArial size=3D2>KU -&gt; Digital Signature</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>EKU -&gt; EMail =
(1.3.6.1.5.5.7.3.2)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>NetscapeExtension -&gt; SSL Client=20
Authentication</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>(none of the above extensions is=20
critical)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>With IE and Outlook, the certificates =
work fine,=20
because Microsoft products mind just the EKU. With Netscape (4.76) and=20
Messenger, I can just use SSL certificate.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>How can I force the use of the mail =
certificate?=20
Why Netscape doesn't mind the S/Mime extension?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Till now, the only solution I have =
found, is to=20
force the usage of my mail certificate setting the KU extension as =
critical, but=20
I don't think it is the best one. Have someone a best =
solution?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks in advance.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial=20
size=3D2>Fabio.</FONT></DIV></DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_005E_01C0D304.9CED6F30--



Received: from brot.celocom.de (brot.celocom.de [212.78.104.200]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA08017 for <[e-mail]>; Wed, 2 May 2001 03:18:08 -0700 (PDT)
Received: from frolic.celocom.de (frolic.celocom.de [212.78.104.90]) by brot.celocom.de (Postfix) with ESMTP id EB4502FD2 for <[e-mail]>; Wed, 02 May 2001 12:17:54 +0200 (CEST)
Received: from gemplus.com (bernd.celocom.de [212.78.104.41]) by frolic.celocom.de (Postfix) with ESMTP id B0ED0108054 for <[e-mail]>; Wed,  2 May 2001 12:17:54 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Wed, 02 May 2001 12:17:50 +0200
From: Bernd Matthes <[e-mail]>
Organization: Celo Communications -- a Gemplus Company
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: de,en
MIME-Version: 1.0
To: ietf pkix <[e-mail]>
Subject: TimeStamp: Needs clarification
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msDDCF07E0D2BD0C914A494DBC"

This is a cryptographically signed message in MIME format.

--------------msDDCF07E0D2BD0C914A494DBC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi to all!

I need clarification about messageImprint of TimeStampToken.

In <draft-ietf-pkix-time-stamp-14.txt>, Appendix A is written:
"The value of messageImprint field within TimeStampToken shall be a hash
of the value of signature field within SignerInfo for the signedData
being timestamped."

In my opinion is the messageImprint the hash value of the
encryptedDigest
in the SignerInfo (according to RFC2315)
or is the messageImprint the hash value over the message identical to
the
messageDigest in the authenticatedAttributes within the SignerInfo?

Thanks in advance.

-- 
Mors certa, hora incerta. In dubio pro mille.
--------------------------------------------------------------------
Bernd Matthes                   Celo Communications GmbH
Senior Software Engineer    	     - a Gemplus Company
Dipl.-Ing.(FH)                  mailto:[e-mail]
--------------------------------------------------------------------
Every information is sensitive information,
and sensitive informations should be protected from being spied.
ergo: because you read this mail you're probably a spy.
--------------msDDCF07E0D2BD0C914A494DBC
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIH6gYJKoZIhvcNAQcCoIIH2zCCB9cCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
Bb0wggKMMIIB9aADAgECAgMEZkswDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMTAzMTYxNDA0MzJaFw0wMjAzMTYxNDA0MzJa
MEsxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxKDAmBgkqhkiG9w0BCQEWGWJl
cm5kLm1hdHRoZXNAZ2VtcGx1cy5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAA
w8BVu1sFXcFZ0RiaI1E7cQGzD/ilmkCBs2shzSy/ORqzS5XCQvXat5tbDgWQg1qKKvh4gvly
pgwvJtnyOyqUBJ6/L+BiFHYsSgFZZ8dWCSnJFPWbYtvrAzvN3IhkRgkOiit/jo6mIOFDjQKm
ZbxC2sQzcuf3eUJVL5zXvjmnAgMBAAGjNjA0MCQGA1UdEQQdMBuBGWJlcm5kLm1hdHRoZXNA
Z2VtcGx1cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBy4Avl5Chdn6uQ
MnVuQd14NYuqtWZaAPL84JN0P6mEfrSxjvb/XsQNXBnfFeBe9dC28ENTWQqboh2EYlhM1LjD
+BmyyORFcEbJWqQce76vBXu7HAQXo+3GlesUKy3bW34z/bMdbiovChqBxTCbSxe1qCzxdFS3
WDxx+LaaIFJUGDCCAykwggKSoAMCAQICAQwwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYT
AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE
ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg
RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqG
SIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAwMDBa
Fw0wMjA4MjkyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBl
MRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlm
aWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjgu
MzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZgpcO
40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqdknWo
J67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFpAgMB
AAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzASBgNV
HRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQBzG28mZYv/
FTRLWWKK7US+ScfoDbuPuQ1qJipihB+4h2N0HG23zxpTkUvhzeY42e1Q9DpsNJKs5pKcbsEj
AcIJp+9LrnLdBmf1UG8uWLi2C8FQV7XsHNfvF7bViJu3ooga7TlbOX00/LaWGCVNavSdxcOR
L6mWuAU8Uvzd6WIDSDGCAfUwggHxAgEBMIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMM
V2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsG
A1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWls
IFJTQSAyMDAwLjguMzACAwRmSzAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMDUwMjEwMTc1M1owIwYJKoZIhvcNAQkEMRYEFCSz
hl82sIa88R2P7KanedhObSoqMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG
SIb3DQEBAQUABIGAmamEkJxZhOyDC7WHBwRyYJsYfOrv7pFjY9rY03kQFowXGf09Socm24zG
zhwBZLAVeKm5PkkwZG/Xxej34mIE6cNqey4d7wZTT07CAtBXg7KdKUVx2/g95q/de99c3dXF
LseZNfWBgPjhOwc0gagNwUhTKYyiVH44/L/WUwoCoBs=
--------------msDDCF07E0D2BD0C914A494DBC--



Received: from ntsiaexch.office (exchange.sia.it [192.106.192.201]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA04048 for <[e-mail]>; Wed, 2 May 2001 02:51:14 -0700 (PDT)
Received: by ntsiaexch.office with Internet Mail Service (5.5.2653.19) id <KDKW0F46>; Wed, 2 May 2001 11:50:43 +0200
Message-ID: <[e-mail]>
From: Santoni Adriano <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Housley Russ <[e-mail]>
Cc: [e-mail]
Subject: R: CPS Pointer
Date: Wed, 2 May 2001 11:50:42 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id CAA04055

I think that we should also explicitly provide for HTTPS, if that is not
obvious enough from the text and context.
Some CAs publish their CPS on an SSL-protected web site, so the user can
verify it comes from a trusted source (this is good practice, IMO).

Adriano

-----Messaggio originale-----
Da: [e-mail] [mailto:[e-mail]]
Inviato: martedì 1 maggio 2001 19.01
A: Housley Russ
Cc: [e-mail]
Oggetto: Re: CPS Pointer


I think the current text is fine.  I don't think there is any benefit in 
requiring or suggesting that CAs use particular forms of URIs.  This 
should be left as "a local matter".

Terry Hayes

Housley, Russ wrote:

> Trevor Freeman noticed we don't have any guidelines for what forms of 
> URI are supported with the CPS Pointer.  Presently, we say:
>
>    The CPS Pointer qualifier contains a pointer to a Certification
>    Practice Statement (CPS) published by the CA.  The pointer is in the
>    form of a URI.  Processing requirements for this qualifier are a
>    local matter.  No action is mandated by this specification regardless
>    of the criticality value asserted for the extension.
>
> So, we are not mandating any behavior on the client.  Perhaps we 
> should say something about the CA.  Trevor suggests that HTTP and FTP 
> forms of URI are sufficient.  Does anyone see any reason to support 
> other protocols for CPS fetching?
>
> Russ





*******************Internet Email Confidentiality Footer******************* 
Qualsiasi utilizzo non autorizzato del presente messaggio nonche' dei suoi
allegati e' vietato e potrebbe costituire reato. Se lei ha ricevuto
erroneamente il presente messaggio, Le saremmo grati se, via e-mail, ce ne
comunicasse la ricezione e provvedesse alla distruzione del messaggio stesso
e dei suoi eventuali allegati. Le dichiarazioni contenute nel presente
messaggio nonche' nei suoi eventuali allegati devono essere attribuite
esclusivamente al mittente e non possono essere considerate come trasmesse o
autorizzate da SIA S.p.A.; le medesime dichiarazioni non impegnano SIA
S.p.A. nei confronti del destinatario o di terzi. 
SIA S.p.A. non si assume alcuna responsabilita' per eventuali
intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail. 

Any unauthorized use of this e-mail or any of its attachments is prohibited
and could constitute an offence. If you are not the intended addressee
please advise immediately the sender by using the reply facility in your
e-mail software and destroy the message and its attachments. The statements
and opinions expressed in this e-mail message are those of the author of the
message and do not necessarily represent those of SIA. Besides, The contents
of this message shall be understood as neither given nor endorsed by SIA
S.p.A.. 
SIA S.p.A. does not accept liability for corruption, interception or
amendment, if any, or the consequences thereof. 




Received: from samurai.mirai.hu (mirai.hu [195.70.36.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA21376; Tue, 1 May 2001 18:44:40 -0700 (PDT)
From: [e-mail]
Received: from [216.206.146.34] (helo=cis) by samurai.mirai.hu with smtp (Exim 3.12 #1 (Debian)) id 14ulg6-0007vZ-00; Wed, 02 May 2001 03:43:42 +0200
To: Printing supply consumers<>
Subject: Save big on printer supplies!
Date: Tue, 01 May 2001 18:43:28 -0700
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Content-Type: text/html; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
Message-Id: <[e-mail]>

<html>
<head>
<title>Save $$$$ with Computer Imaging Supply Inc.!!!!!</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<!--

You are seeing this message because your email reading
software cannot properly read HTML formatted email.
This message is formatted in HTML.

To view all of Computer Imaging Supply's great deals,
simply click on the following link and start enjoying
the savings.

http://www.computerimagingsupply.com

-------------------------------------------------------
Save $$$$ with Computer Imaging Supply Inc.!!!!!
-------------------------------------------------------

Sincerely,

Team Staff

http://www.ComputerImagingSupply.com









--> 
<meta http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<meta content="MSHTML 6.00.2462.0" name=GENERATOR>
<style></style>
</head>

<body bgcolor="#ffffff">
<div> </div>
<div align=center><a 
href="http://www.computerimagingsupply.com/CDindex.html"><img height=74 
src="http://www.computerimagingsupplies.com/Email/LG/CIS-logo-bevel.gif" 
width=447 border=0></a><font color=#ff0000><b><font 
face="Verdana, Arial, Helvetica, sans-serif" color=#0033cc 
size=-1><br>
  </font><font color=#0033cc><b><font 
face="Verdana, Arial, Helvetica, sans-serif">THE MOST EXPENSIVE PART OF A PRINTER 
  IS THE SUPPLIES!</font></b></font></b></font></div>
<div align=center><font face="Verdana, Arial, Helvetica, sans-serif"><b><font 
size=-1>Get more value for your money with <a 
href="http://www.ComputerImagingSupply.com">http://www.ComputerImagingSupply.com</a>.</font></b></font><br>
</div>
<div align=center> 
  <table height=67 width=418 border=0>
    <tbody> 
    <tr> 
      <td width=153 bgcolor=#ff9999 height=150> 
        <div align=center><font face="Verdana, Arial, Helvetica, sans-serif" 
      size=-1><b><br>
          We have</b><br>
          <font color=#0000cc><i><b><font 
      color=#0000ff>LOWER</font></b></i></font> <font 
      color=#0000ff><i><b>PRICES</b></i></font><br>
          <font size=-2><b><font 
      color=#330066 size=-1>than the office supply superstores on OEM Inkjet/Laser 
          cartridges, FAX supplies &amp; Printer Ribbons!</font> </b></font></font></div>
      </td>
      <td width=125 bgcolor=#6699ff height=150> 
        <div align=center> 
          <p><font face="Verdana, Arial, Helvetica, sans-serif" size=-1><b><font 
      color=black><br>
            FREE SHIPPING</font></b><br>
            <i>on all orders!<br>
            </i><b><font color=black>NO SALES TAX!</font></b><i><br>
            (except CA)<br>
            </i><font color=black><b>100% MONEY BACK<br>
            GURANTEE!</b></font><i><br>
            <font color=#003333>=No Risk To You!</font></i></font> </p>
        </div>
      </td>
      <td width=118 bgcolor=#66ff66 height=150> 
        <p align=center><font face="Verdana, Arial, Helvetica, sans-serif" 
      size=-1><b>Check out our</b></font> <i><br>
          <b><font 
      face="Verdana, Arial, Helvetica, sans-serif" color=#006666>LOW PRICES!</font></b></i></p>
        <form>
          <select onChange="OpenCIS('http://computerimagingsupply.com')" 
      name="printer Model">
            <option selected>Printer Model</option>
            <option>Canon</option>
            <option>Epson</option>
            <option>Hewlett Packard</option>
            <option>Lexmark</option>
            <option>Xerox</option>
          </select>
        </form>
        <p align=center><i><b><font face="Verdana, Arial, Helvetica, sans-serif" 
      color=#006666><a 
      href="http://www.computerimagingsupply.com/CDindex.html">Click Here!</a> 
          </font></b></i></p>
      </td>
    </tr>
    </tbody>
  </table>
  <table width=480 border=0>
    <tbody> 
    <tr> 
      <td width=71 height=67><img height=81 
      src="http://www.computerimagingsupplies.com/Email/LG/cart1.gif" 
    width=70></td>
      <td width=336 height=67> 
        <div align=center><i><font face="Verdana, Arial, Helvetica, sans-serif" 
      color=#0000cc><b><font size=-1>Plus, we carry a full line of OEM quality 
          replacement products and our </font>CIS XL line<font size=-1>. These 
          unique long life products cost less than OEM &amp; they give you <br>
          </font></b></font></i><font 
      face="Verdana, Arial, Helvetica, sans-serif" color=#0000cc><b><font 
      color=#ff0000>25% or more prints!</font></b></font></div>
      </td>
      <td width=10 height=67><img height=81 
      src="http://www.computerimagingsupplies.com/Email/LG/toner1.gif" 
    width=70></td>
    </tr>
    </tbody>
  </table>
  <table width=552 bgcolor=#ffff00 border=0>
    <tbody> 
    <tr> 
      <td height=72> 
        <div align=center><font 
      face="Verdana, Arial, Helvetica, sans-serif"><b><i><font 
      color=#000099>Example</font></i></b></font><font 
      face="Verdana, Arial, Helvetica, sans-serif" size=-1><b>: Your printer needs 
          a <font color=#0000ff>Hewlett Packard</font> Series 2 Black Cartridge.<br>
          </b></font><b><font 
      face="Verdana, Arial, Helvetica, sans-serif" size=-1>Purchase our XL product 
          and you save money &amp; the cartridge has a longer life of up to </font><font 
      face="Verdana, Arial, Helvetica, sans-serif" color=#0000ff>25%</font><font 
      face="Verdana, Arial, Helvetica, sans-serif" size=-1> </font><font 
      face="Verdana, Arial, Helvetica, sans-serif" color=#0000ff>or more!</font><font face="Verdana, Arial, Helvetica, sans-serif" size=-1> 
          <br>
          <i><font color=#006666>It's that simple.</font></i></font></b></div>
      </td>
    </tr>
    </tbody>
  </table>
  <table height=88 width=595 border=0>
    <tbody> 
    <tr> 
      <td width=391 height=136> 
        <div align=center><font size=-2><b><font 
      face="Verdana, Arial, Helvetica, sans-serif" color=#000066 
      size=-1>Computer Imaging Supply is ready <br>
          to serve you<font size=-2> with our world class customer service <br>
          featuring<font size=-1> LIVE</font> onsite chat. Also, check out our<br>
          featured <font 
      color=#3333ff><i><font size=-1>FREE GIFT </font></i></font><font 
      size=-1><i><font color=#0000ff>PREMIUMS</font></i></font>. Visit our secure<br>
          and easy to use website today &amp; you'll receive a<br>
          <i><font 
      color=#cc0000 size=-1>FREE CLEANING KIT</font></i> with your first order 
          ... <br>
          no minimum required!</font></font></b></font></div>
      </td>
      <td width=239 height=136><a 
      href="http://www.computerimagingsupply.com/CDindex.html"><img height=115 
      src="http://www.computerimagingsupplies.com/Email/LG/hdquarters.gif" 
      width=254 border=0></a></td>
    </tr>
    </tbody>
  </table>
  <table width=496 border=0>
    <tbody> 
    <tr> 
      <td width=311 bgcolor=#66ff66> 
        <div align=center><b><font face="Verdana, Arial, Helvetica, sans-serif" 
      color=#000033 size=-1><br>
          START SAVING $$$ NOW AT:<br>
          </font><font 
      face="Verdana, Arial, Helvetica, sans-serif" color=#000033><a 
      href="http://www.computerimagingsupply.com/CDindex.html"><font 
      size=-1>http://www.ComputerImagingSupply.com</font></a></font></b></div>
      </td>
      <td width=169 bgcolor=#ff9999> 
        <div align=center><font face="Verdana, Arial, Helvetica, sans-serif" 
      size=-1><font color=#0000ff><b><font color=#003333>Questions? Call our toll 
          free direct <br>
          customer service:<br>
          1-888-289-4624 </font></b></font></font></div>
      </td>
    </tr>
    </tbody>
  </table>
  <table height=80 width=596 border=0>
    <tbody> 
    <tr> 
      <td height=90> 
        <p align=center><font face="Verdana, Arial, Helvetica, sans-serif" 
      size=-1><font color=#000099>If you are not responsible for printer supply 
          purchasing,<br>
          please forward this e-mail to appropriate persons.</font> <br>
          <font size=-2><br>
          To be removed form this list, please reply to this e-mail and type "Remove" 
          in the subject field. <br>
          You can also remove your email address by clicking on the following 
          link and hitting send: <br>
          <b>mailto:</b><a 
      href="mailto:[e-mail]?subject=Remove ">[e-mail]?subject=Remove</a></font></font><font 
      face="Verdana, Arial, Helvetica, sans-serif" size=-1><font size=-2> Free 
          shipping offer good to continental U.S. only. <br>
          Gift premiums awarded at specific purchase levels. No tax available 
          outside CA only. <br>
          Free cleaning kits available while supplies last. </font></font></p>
      </td>
    </tr>
    </tbody>
  </table>
</div>
</body>
</html>


Received: from e1.ny.us.ibm.com ([32.97.182.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA07710 for <[e-mail]>; Tue, 1 May 2001 14:46:53 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA65662; Tue, 1 May 2001 17:44:39 -0400
Received: from d02ml237.somers.hqregion.ibm.com ([9.45.4.171]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id RAA35356; Tue, 1 May 2001 17:40:57 -0400
Importance: Normal
Subject: Re: Basic constraints, key usage, and LDAP schema
To: [e-mail] (Terry Hayes)
Cc: Tim Polk <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Tue, 1 May 2001 17:46:04 -0400
X-MIMETrack: Serialize by Router on D02ML237/02/M/IBM(Release 5.0.7 |March 21, 2001) at 05/01/2001 05:46:08 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

     Tim's idea looks good to me too.  I have no strong opinions as to
whether an entity delegated to sign PK CRL's which does not have the same
DN as any signer of PK Certificates should have basicConstraints indicating
that it is a CA and be published in caCertificate, or whether it should be
published in userCertificate with no basicConstraints extension in the
certificate.  However, an entity which signs AC CRL's but not PK CRL's is
not a CA (it may be an AA, but not a CA).  First, do we need an Key Purpose
ID to designate such certificates?  I would think that we do.  Second, what
attribute does the CRL signing certificate go into?  It can't go into the
aACertificate attribute which contains AC's rather than PKC's.

          Tom Gindin


[e-mail] (Terry Hayes) on 05/01/2001 04:41:36 PM

To:   Tim Polk <[e-mail]>
cc:   [e-mail]
Subject:  Re: Basic constraints, key usage, and LDAP schema


Tim,

I agree with your proposed solution.  As you have said, it separates the
semantics of the two extensions, and simplifies the rules for the LDAP
schema.

There is one remaining point to address, and I believe it may be the
main point of discussion in the current thread.

When a CA uses the CRLDP extension to designate another entity to be the
source for revocation information about some of its certificates, should
that entity  have a "CA" certificate (with appropriate basicConstraints
extension)?  I'm *not* suggesting that a basicConstraints extension is
necessary for the entity to be authorized to sign the CRL.  Instead, the
problem is that clients that are trying to locate the certificate will
not know whether they should look in the cACertificate attribute or the
userCertificate attribute to find the appropriate certificate.

To solve this, we can suggest that cACertificate be searched first,
followed by userCertificate, or we can require that designated entities
must always be a "CA", and the client can safely skip the
userCertificate attribute.  This is a question of searching the
directory only, and does not suggest changing your assertion that any
set of bits may be set in the keyUsage extension of "CA" certificates.

Terry

Tim Polk wrote:

> Folks,
>
> I have been reading the email messages on the list about the
> relationships between basic constraints, key usage, and the schema.
> After mulling over the problem.  I would like to propose a solution -
> the only solution, as far as I can tell...
>
> The solution is to simplify and separate the semantics of the basic
> constraints and key usage extension.  This has positive implications
> for the PKIX LDAP schema as well.
>
> Basic Constraints
>
> As stated in the current text for Basic Constraints (in 2459):  "The
> basic constraints extension identifies whether the subject of the
> certificate is a CA and how deep a certification path may exist
> through that CA."
>
> I believe this is the right semantics, and that basic constraints
> should be included and cA should be asserted in *any* certificate
> issued to a CA, regardless of the type or role associated with the
> public key in the certificate.
>
> Key Usage
>
> The issuer should use the Key Usage extension to disambiguate the
> subject's key pairs:
> (a) The issuer indicates this public key may be used to verify the
> signature on a public key certificate by asserting keyCertSign.  (b)
> The issuer indicates this public key may be used to verify the
> signature on CRLs by asserting cRLSign.  (c) The issuer indicates that
> this public key may be used to establish symmetric keys with the
> subject by asserting either keyEncipherment or keyAgreement.  (d) The
> issuer indicates that this public key may be used to verify signatures
> on objects other than public key certificates and CRLs by asserting
> nonRerpuidation or digitalSignature.
>
> Of course, if a key pair is used for multiple purposes, multiple key
> usages may be asserted.
>
> In each of these cases, the basic constraints extension also appears
> in the certificate and asserts that the subject is a CA.
>
> LDAP Schema
>
> All certificates issued to CAs would be considered CA certificates
> since the basic constraints extension is present and asserts that the
> subject is a CA.  As a result, each of these could appear in the
> cACertificate attribute or crossCertificatePair attribute.  They would
> *not* appear in the userCertificate attribute.  (That would include
> all types (a) through (d) above).
>
> ------------------
>
> The implications of this strategy are as follows: (1) when a client is
> searching for a CA certificate, they will not have to check the
> userCertificate attribute; (2) the issuer can indicate that the
> subject is a CA regardless of the key usage; and (3) minimal changes
> to the text (my favorite!).
>
> What do you think?
>
> Thanks,
>
> Tim Polk
>
>
>








Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA05506 for <[e-mail]>; Tue, 1 May 2001 14:28:27 -0700 (PDT)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id RAA04732 for <[e-mail]>; Tue, 1 May 2001 17:28:29 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Tue, 01 May 2001 17:27:03 -0400
To: [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: Re: Basic constraints, key usage, and LDAP schema
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Regunathan,

Bear in mind that if an entity other than the certificate issuer issues CRLs that provide revocation information for a certificate, the CRLs should only be accepted if the certificate issuer specifically designates the CRL issuer as the source of revocation information. Whether we call the CRL issuer a CA or not should not affect the degree to which clients trust that entity. Similarly, whether the cA bit is set or not should not affect whether clients trust that entity.

If a CA issues a certificate, specifies entityX as the source of revocation information (using a distribution point), and then issues a certificate to entityX with the cRLSign KeyUsage bit set, then clients that are willing to accept the certificate should trust the CRLs issued by entityX to provide accurate revocation information for the certificate. It doesn't make sense to say that the information in the CRL should be trusted if the certificate issued to entityX has the cA bit set, but should not be trusted if the cRLSign bit is set but the cA bit is not set.

I do like the idea, however, of putting any certificate with cRLSign set in the cACertificate or crossCertificatePair attribute. We should try to have a single place for clients to look to find the certificate they need. Since most certificates with cRLSign set will also have KeyCertSign set as well, the cACertificate or crossCertificatePair attributes seem the best choice.

 From my point of view, the real value that basicConstraints adds is the ability to impose path length constraints. Using the cA bit to confer some degree of "trustworthiness" on the subject seems to be overloading the bit. We already have KeyUsage to indicate whether the subject public key can be used to verify signatures on certificates, CRLs, etc.

Dave

At 05:00 PM 5/1/01 -0400, Regunathan Rajaiah wrote:
>Terry 
>     I like the idea of 
>   " or we can require that designated entities must always be a "CA"," 
>
>I am wondering if the entity [source of revocation info] is not required to be CA , are the clinets expected to trust that entity too? 
>
>We should require the designated entities must always be a CA




Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA04153 for <[e-mail]>; Tue, 1 May 2001 14:07:21 -0700 (PDT)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id RAA16411; Tue, 1 May 2001 17:07:21 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 01 May 2001 17:05:17 -0400
To: [e-mail] (Terry Hayes)
From: Tim Polk <[e-mail]>
Subject: Re: Basic constraints, key usage, and LDAP schema
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Terry,

I think it would be best if the client did not need to check the 
userCertificate attribute to validate CRLs.  This adds complexity without 
any real benefit (in my opinion.)  I have included some proposed text for 
the first paragraph of section 4.2.1.10 (basic constraints) that would 
clarify the issue.

----------------proposed text for first paragraph of 4.2.1.10----------------

The basic constraints extension identifies whether the subject of the 
certificate is a CA and the maximum depth of valid certification paths that 
include this certificate.  A subject is considered a CA if it issues public 
key certificates or CRLs that describe the revocation status of public key 
certificates.

----------------------end proposed text

What do you think?

Thanks,

Tim Polk

At 01:41 PM 5/1/01 -0700, Terry Hayes wrote:
>Tim,
>
>I agree with your proposed solution.  As you have said, it separates the 
>semantics of the two extensions, and simplifies the rules for the LDAP schema.
>
>There is one remaining point to address, and I believe it may be the main 
>point of discussion in the current thread.
>
>When a CA uses the CRLDP extension to designate another entity to be the 
>source for revocation information about some of its certificates, should 
>that entity  have a "CA" certificate (with appropriate basicConstraints 
>extension)?  I'm *not* suggesting that a basicConstraints extension is 
>necessary for the entity to be authorized to sign the CRL.  Instead, the 
>problem is that clients that are trying to locate the certificate will not 
>know whether they should look in the cACertificate attribute or the 
>userCertificate attribute to find the appropriate certificate.
>
>To solve this, we can suggest that cACertificate be searched first, 
>followed by userCertificate, or we can require that designated entities 
>must always be a "CA", and the client can safely skip the userCertificate 
>attribute.  This is a question of searching the directory only, and does 
>not suggest changing your assertion that any set of bits may be set in the 
>keyUsage extension of "CA" certificates.
>
>Terry
>
>Tim Polk wrote:
>
>>Folks,
>>
>>I have been reading the email messages on the list about the 
>>relationships between basic constraints, key usage, and the schema.
>>After mulling over the problem.  I would like to propose a solution - the 
>>only solution, as far as I can tell...
>>
>>The solution is to simplify and separate the semantics of the basic 
>>constraints and key usage extension.  This has positive implications for 
>>the PKIX LDAP schema as well.
>>
>>Basic Constraints
>>
>>As stated in the current text for Basic Constraints (in 2459):  "The 
>>basic constraints extension identifies whether the subject of the 
>>certificate is a CA and how deep a certification path may exist through 
>>that CA."
>>
>>I believe this is the right semantics, and that basic constraints should 
>>be included and cA should be asserted in *any* certificate issued to a 
>>CA, regardless of the type or role associated with the public key in the 
>>certificate.
>>
>>Key Usage
>>
>>The issuer should use the Key Usage extension to disambiguate the 
>>subject's key pairs:
>>(a) The issuer indicates this public key may be used to verify the 
>>signature on a public key certificate by asserting keyCertSign.  (b) The 
>>issuer indicates this public key may be used to verify the signature on 
>>CRLs by asserting cRLSign.  (c) The issuer indicates that this public key 
>>may be used to establish symmetric keys with the subject by asserting 
>>either keyEncipherment or keyAgreement.  (d) The issuer indicates that 
>>this public key may be used to verify signatures on objects other than 
>>public key certificates and CRLs by asserting nonRerpuidation or 
>>digitalSignature.
>>
>>Of course, if a key pair is used for multiple purposes, multiple key 
>>usages may be asserted.
>>
>>In each of these cases, the basic constraints extension also appears in 
>>the certificate and asserts that the subject is a CA.
>>
>>LDAP Schema
>>
>>All certificates issued to CAs would be considered CA certificates since 
>>the basic constraints extension is present and asserts that the subject 
>>is a CA.  As a result, each of these could appear in the cACertificate 
>>attribute or crossCertificatePair attribute.  They would *not* appear in 
>>the userCertificate attribute.  (That would include all types (a) through 
>>(d) above).
>>
>>------------------
>>
>>The implications of this strategy are as follows: (1) when a client is 
>>searching for a CA certificate, they will not have to check the 
>>userCertificate attribute; (2) the issuer can indicate that the subject 
>>is a CA regardless of the key usage; and (3) minimal changes to the text 
>>(my favorite!).
>>
>>What do you think?
>>
>>Thanks,
>>
>>Tim Polk
>>
>>
>
>



Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA03233 for <[e-mail]>; Tue, 1 May 2001 14:00:13 -0700 (PDT)
Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id f41KxYv15767 for <[e-mail]>; Tue, 1 May 2001 13:59:34 -0700 (PDT)
Received: from netscape.com ([205.217.228.132]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GCOCZ602.6DD; Tue, 1 May 2001 13:59:30 -0700 
Message-ID: <[e-mail]>
Date: Tue, 01 May 2001 17:00:40 -0400
From: [e-mail] (Regunathan Rajaiah)
X-Mailer: Mozilla 4.75 [en]C-NSCP  (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Terry Hayes <[e-mail]>
CC: Tim Polk <[e-mail]>, [e-mail]
Subject: Re: Basic constraints, key usage, and LDAP schema
References: <[e-mail]> <[e-mail]>
Content-Type: multipart/mixed; boundary="------------3745B398E1F63156C6504527"

This is a multi-part message in MIME format.
--------------3745B398E1F63156C6504527
Content-Type: multipart/alternative;
 boundary="------------6606F5FE7387399BF9212D05"


--------------6606F5FE7387399BF9212D05
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Terry
    I like the idea of
  " or we can require that designated entities must always be a "CA","

I am wondering if the entity [source of revocation info] is not required to
be CA , are the clinets expected to trust that entity too?

We should require the designated entities must always be a CA


Terry Hayes wrote:

> Tim,
>
> I agree with your proposed solution.  As you have said, it separates the
> semantics of the two extensions, and simplifies the rules for the LDAP
> schema.
>
> There is one remaining point to address, and I believe it may be the
> main point of discussion in the current thread.
>
> When a CA uses the CRLDP extension to designate another entity to be the
> source for revocation information about some of its certificates, should
> that entity  have a "CA" certificate (with appropriate basicConstraints
> extension)?  I'm *not* suggesting that a basicConstraints extension is
> necessary for the entity to be authorized to sign the CRL.  Instead, the
> problem is that clients that are trying to locate the certificate will
> not know whether they should look in the cACertificate attribute or the
> userCertificate attribute to find the appropriate certificate.
>
> To solve this, we can suggest that cACertificate be searched first,
> followed by userCertificate, or we can require that designated entities
> must always be a "CA", and the client can safely skip the
> userCertificate attribute.  This is a question of searching the
> directory only, and does not suggest changing your assertion that any
> set of bits may be set in the keyUsage extension of "CA" certificates.
>
> Terry
>
> Tim Polk wrote:
>
> > Folks,
> >
> > I have been reading the email messages on the list about the
> > relationships between basic constraints, key usage, and the schema.
> > After mulling over the problem.  I would like to propose a solution -
> > the only solution, as far as I can tell...
> >
> > The solution is to simplify and separate the semantics of the basic
> > constraints and key usage extension.  This has positive implications
> > for the PKIX LDAP schema as well.
> >
> > Basic Constraints
> >
> > As stated in the current text for Basic Constraints (in 2459):  "The
> > basic constraints extension identifies whether the subject of the
> > certificate is a CA and how deep a certification path may exist
> > through that CA."
> >
> > I believe this is the right semantics, and that basic constraints
> > should be included and cA should be asserted in *any* certificate
> > issued to a CA, regardless of the type or role associated with the
> > public key in the certificate.
> >
> > Key Usage
> >
> > The issuer should use the Key Usage extension to disambiguate the
> > subject's key pairs:
> > (a) The issuer indicates this public key may be used to verify the
> > signature on a public key certificate by asserting keyCertSign.  (b)
> > The issuer indicates this public key may be used to verify the
> > signature on CRLs by asserting cRLSign.  (c) The issuer indicates that
> > this public key may be used to establish symmetric keys with the
> > subject by asserting either keyEncipherment or keyAgreement.  (d) The
> > issuer indicates that this public key may be used to verify signatures
> > on objects other than public key certificates and CRLs by asserting
> > nonRerpuidation or digitalSignature.
> >
> > Of course, if a key pair is used for multiple purposes, multiple key
> > usages may be asserted.
> >
> > In each of these cases, the basic constraints extension also appears
> > in the certificate and asserts that the subject is a CA.
> >
> > LDAP Schema
> >
> > All certificates issued to CAs would be considered CA certificates
> > since the basic constraints extension is present and asserts that the
> > subject is a CA.  As a result, each of these could appear in the
> > cACertificate attribute or crossCertificatePair attribute.  They would
> > *not* appear in the userCertificate attribute.  (That would include
> > all types (a) through (d) above).
> >
> > ------------------
> >
> > The implications of this strategy are as follows: (1) when a client is
> > searching for a CA certificate, they will not have to check the
> > userCertificate attribute; (2) the issuer can indicate that the
> > subject is a CA regardless of the key usage; and (3) minimal changes
> > to the text (my favorite!).
> >
> > What do you think?
> >
> > Thanks,
> >
> > Tim Polk
> >
> >
> >

--------------6606F5FE7387399BF9212D05
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Terry
<br>&nbsp;&nbsp;&nbsp; I like the idea of
<br>&nbsp; " <b><font color="#3366FF">or we can require that designated
entities must always be a "CA","</font></b><font color="#000000"></font>
<p><font color="#000000">I am wondering if the entity [source of revocation
info] is not required to be CA , are the clinets expected to trust that
entity too?</font><font color="#000000"></font>
<p><font color="#000000">We should require the designated entities must
always be a CA</font>
<br><font color="#000000"></font>&nbsp;<font color="#000000"></font>
<p>Terry Hayes wrote:
<blockquote TYPE=CITE>Tim,
<p>I agree with your proposed solution.&nbsp; As you have said, it separates
the
<br>semantics of the two extensions, and simplifies the rules for the LDAP
<br>schema.
<p>There is one remaining point to address, and I believe it may be the
<br>main point of discussion in the current thread.
<p>When a CA uses the CRLDP extension to designate another entity to be
the
<br>source for revocation information about some of its certificates, should
<br>that entity&nbsp; have a "CA" certificate (with appropriate basicConstraints
<br>extension)?&nbsp; I'm *not* suggesting that a basicConstraints extension
is
<br>necessary for the entity to be authorized to sign the CRL.&nbsp; Instead,
the
<br>problem is that clients that are trying to locate the certificate will
<br>not know whether they should look in the cACertificate attribute or
the
<br>userCertificate attribute to find the appropriate certificate.
<p>To solve this, we can suggest that cACertificate be searched first,
<br>followed by userCertificate, or we can require that designated entities
<br>must always be a "CA", and the client can safely skip the
<br>userCertificate attribute.&nbsp; This is a question of searching the
<br>directory only, and does not suggest changing your assertion that any
<br>set of bits may be set in the keyUsage extension of "CA" certificates.
<p>Terry
<p>Tim Polk wrote:
<p>> Folks,
<br>>
<br>> I have been reading the email messages on the list about the
<br>> relationships between basic constraints, key usage, and the schema.
<br>> After mulling over the problem.&nbsp; I would like to propose a solution
-
<br>> the only solution, as far as I can tell...
<br>>
<br>> The solution is to simplify and separate the semantics of the basic
<br>> constraints and key usage extension.&nbsp; This has positive implications
<br>> for the PKIX LDAP schema as well.
<br>>
<br>> Basic Constraints
<br>>
<br>> As stated in the current text for Basic Constraints (in 2459):&nbsp;
"The
<br>> basic constraints extension identifies whether the subject of the
<br>> certificate is a CA and how deep a certification path may exist
<br>> through that CA."
<br>>
<br>> I believe this is the right semantics, and that basic constraints
<br>> should be included and cA should be asserted in *any* certificate
<br>> issued to a CA, regardless of the type or role associated with the
<br>> public key in the certificate.
<br>>
<br>> Key Usage
<br>>
<br>> The issuer should use the Key Usage extension to disambiguate the
<br>> subject's key pairs:
<br>> (a) The issuer indicates this public key may be used to verify the
<br>> signature on a public key certificate by asserting keyCertSign.&nbsp;
(b)
<br>> The issuer indicates this public key may be used to verify the
<br>> signature on CRLs by asserting cRLSign.&nbsp; (c) The issuer indicates
that
<br>> this public key may be used to establish symmetric keys with the
<br>> subject by asserting either keyEncipherment or keyAgreement.&nbsp;
(d) The
<br>> issuer indicates that this public key may be used to verify signatures
<br>> on objects other than public key certificates and CRLs by asserting
<br>> nonRerpuidation or digitalSignature.
<br>>
<br>> Of course, if a key pair is used for multiple purposes, multiple
key
<br>> usages may be asserted.
<br>>
<br>> In each of these cases, the basic constraints extension also appears
<br>> in the certificate and asserts that the subject is a CA.
<br>>
<br>> LDAP Schema
<br>>
<br>> All certificates issued to CAs would be considered CA certificates
<br>> since the basic constraints extension is present and asserts that
the
<br>> subject is a CA.&nbsp; As a result, each of these could appear in
the
<br>> cACertificate attribute or crossCertificatePair attribute.&nbsp;
They would
<br>> *not* appear in the userCertificate attribute.&nbsp; (That would
include
<br>> all types (a) through (d) above).
<br>>
<br>> ------------------
<br>>
<br>> The implications of this strategy are as follows: (1) when a client
is
<br>> searching for a CA certificate, they will not have to check the
<br>> userCertificate attribute; (2) the issuer can indicate that the
<br>> subject is a CA regardless of the key usage; and (3) minimal changes
<br>> to the text (my favorite!).
<br>>
<br>> What do you think?
<br>>
<br>> Thanks,
<br>>
<br>> Tim Polk
<br>>
<br>>
<br>></blockquote>
</html>

--------------6606F5FE7387399BF9212D05--

--------------3745B398E1F63156C6504527
Content-Type: text/x-vcard; charset=us-ascii;
 name="ragu.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Regunathan Rajaiah
Content-Disposition: attachment;
 filename="ragu.vcf"

begin:vcard 
n:Rajaiah;Regunathan
tel;pager:8004649587
tel;work:2125612044
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:[e-mail]
fn:Ragu
end:vcard

--------------3745B398E1F63156C6504527--



Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA02018 for <[e-mail]>; Tue, 1 May 2001 13:42:11 -0700 (PDT)
Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id f41Kfhn19263 for <[e-mail]>; Tue, 1 May 2001 13:41:43 -0700 (PDT)
Received: from netscape.com ([192.18.121.215]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GCOC5J01.JAU; Tue, 1 May 2001 13:41:43 -0700 
Message-ID: <[e-mail]>
Date: Tue, 01 May 2001 13:41:36 -0700
From: [e-mail] (Terry Hayes)
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.8.1+) Gecko/20010402
X-Accept-Language: en
MIME-Version: 1.0
To: Tim Polk <[e-mail]>
CC: [e-mail]
Subject: Re: Basic constraints, key usage, and LDAP schema
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Tim,

I agree with your proposed solution.  As you have said, it separates the 
semantics of the two extensions, and simplifies the rules for the LDAP 
schema.

There is one remaining point to address, and I believe it may be the 
main point of discussion in the current thread.

When a CA uses the CRLDP extension to designate another entity to be the 
source for revocation information about some of its certificates, should 
that entity  have a "CA" certificate (with appropriate basicConstraints 
extension)?  I'm *not* suggesting that a basicConstraints extension is 
necessary for the entity to be authorized to sign the CRL.  Instead, the 
problem is that clients that are trying to locate the certificate will 
not know whether they should look in the cACertificate attribute or the 
userCertificate attribute to find the appropriate certificate.

To solve this, we can suggest that cACertificate be searched first, 
followed by userCertificate, or we can require that designated entities 
must always be a "CA", and the client can safely skip the 
userCertificate attribute.  This is a question of searching the 
directory only, and does not suggest changing your assertion that any 
set of bits may be set in the keyUsage extension of "CA" certificates.

Terry

Tim Polk wrote:

> Folks,
>
> I have been reading the email messages on the list about the 
> relationships between basic constraints, key usage, and the schema.  
> After mulling over the problem.  I would like to propose a solution - 
> the only solution, as far as I can tell...
>
> The solution is to simplify and separate the semantics of the basic 
> constraints and key usage extension.  This has positive implications 
> for the PKIX LDAP schema as well.
>
> Basic Constraints
>
> As stated in the current text for Basic Constraints (in 2459):  "The 
> basic constraints extension identifies whether the subject of the 
> certificate is a CA and how deep a certification path may exist 
> through that CA."
>
> I believe this is the right semantics, and that basic constraints 
> should be included and cA should be asserted in *any* certificate 
> issued to a CA, regardless of the type or role associated with the 
> public key in the certificate.
>
> Key Usage
>
> The issuer should use the Key Usage extension to disambiguate the 
> subject's key pairs:
> (a) The issuer indicates this public key may be used to verify the 
> signature on a public key certificate by asserting keyCertSign.  (b) 
> The issuer indicates this public key may be used to verify the 
> signature on CRLs by asserting cRLSign.  (c) The issuer indicates that 
> this public key may be used to establish symmetric keys with the 
> subject by asserting either keyEncipherment or keyAgreement.  (d) The 
> issuer indicates that this public key may be used to verify signatures 
> on objects other than public key certificates and CRLs by asserting 
> nonRerpuidation or digitalSignature.
>
> Of course, if a key pair is used for multiple purposes, multiple key 
> usages may be asserted.
>
> In each of these cases, the basic constraints extension also appears 
> in the certificate and asserts that the subject is a CA.
>
> LDAP Schema
>
> All certificates issued to CAs would be considered CA certificates 
> since the basic constraints extension is present and asserts that the 
> subject is a CA.  As a result, each of these could appear in the 
> cACertificate attribute or crossCertificatePair attribute.  They would 
> *not* appear in the userCertificate attribute.  (That would include 
> all types (a) through (d) above).
>
> ------------------
>
> The implications of this strategy are as follows: (1) when a client is 
> searching for a CA certificate, they will not have to check the 
> userCertificate attribute; (2) the issuer can indicate that the 
> subject is a CA regardless of the key usage; and (3) minimal changes 
> to the text (my favorite!).
>
> What do you think?
>
> Thanks,
>
> Tim Polk
>
>
>




Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA29449 for <[e-mail]>; Tue, 1 May 2001 13:05:13 -0700 (PDT)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id QAA19978 for <[e-mail]>; Tue, 1 May 2001 16:05:14 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 01 May 2001 16:03:11 -0400
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: Basic constraints, key usage, and LDAP schema
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Folks,

I have been reading the email messages on the list about the relationships 
between basic constraints, key usage, and the schema.  After mulling over 
the problem.  I would like to propose a solution - the only solution, as 
far as I can tell...

The solution is to simplify and separate the semantics of the basic 
constraints and key usage extension.  This has positive implications for 
the PKIX LDAP schema as well.

Basic Constraints

As stated in the current text for Basic Constraints (in 2459):  "The basic 
constraints extension identifies whether the subject of the certificate is 
a CA and how deep a certification path may exist through that CA."

I believe this is the right semantics, and that basic constraints should be 
included and cA should be asserted in *any* certificate issued to a CA, 
regardless of the type or role associated with the public key in the 
certificate.

Key Usage

The issuer should use the Key Usage extension to disambiguate the subject's 
key pairs:
(a) The issuer indicates this public key may be used to verify the 
signature on a public key certificate by asserting keyCertSign.  (b) The 
issuer indicates this public key may be used to verify the signature on 
CRLs by asserting cRLSign.  (c) The issuer indicates that this public key 
may be used to establish symmetric keys with the subject by asserting 
either keyEncipherment or keyAgreement.  (d) The issuer indicates that this 
public key may be used to verify signatures on objects other than public 
key certificates and CRLs by asserting nonRerpuidation or digitalSignature.

Of course, if a key pair is used for multiple purposes, multiple key usages 
may be asserted.

In each of these cases, the basic constraints extension also appears in the 
certificate and asserts that the subject is a CA.

LDAP Schema

All certificates issued to CAs would be considered CA certificates since 
the basic constraints extension is present and asserts that the subject is 
a CA.  As a result, each of these could appear in the cACertificate 
attribute or crossCertificatePair attribute.  They would *not* appear in 
the userCertificate attribute.  (That would include all types (a) through 
(d) above).

------------------

The implications of this strategy are as follows: (1) when a client is 
searching for a CA certificate, they will not have to check the 
userCertificate attribute; (2) the issuer can indicate that the subject is 
a CA regardless of the key usage; and (3) minimal changes to the text (my 
favorite!).

What do you think?

Thanks,

Tim Polk





Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA19836 for <[e-mail]>; Tue, 1 May 2001 10:01:38 -0700 (PDT)
Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id f41H19n05926 for <[e-mail]>; Tue, 1 May 2001 10:01:09 -0700 (PDT)
Received: from netscape.com ([192.18.121.215]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GCO1XX00.O6X; Tue, 1 May 2001 10:01:09 -0700 
Message-ID: <[e-mail]>
Date: Tue, 01 May 2001 10:01:01 -0700
From: [e-mail] (Terry Hayes)
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.8.1+) Gecko/20010402
X-Accept-Language: en
MIME-Version: 1.0
To: "Housley Russ" <[e-mail]>
CC: [e-mail]
Subject: Re: CPS Pointer
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

I think the current text is fine.  I don't think there is any benefit in 
requiring or suggesting that CAs use particular forms of URIs.  This 
should be left as "a local matter".

Terry Hayes

Housley, Russ wrote:

> Trevor Freeman noticed we don't have any guidelines for what forms of 
> URI are supported with the CPS Pointer.  Presently, we say:
>
>    The CPS Pointer qualifier contains a pointer to a Certification
>    Practice Statement (CPS) published by the CA.  The pointer is in the
>    form of a URI.  Processing requirements for this qualifier are a
>    local matter.  No action is mandated by this specification regardless
>    of the criticality value asserted for the extension.
>
> So, we are not mandating any behavior on the client.  Perhaps we 
> should say something about the CA.  Trevor suggests that HTTP and FTP 
> forms of URI are sufficient.  Does anyone see any reason to support 
> other protocols for CPS fetching?
>
> Russ






Received: from dtctxexchims05.ins.com ([208.164.93.100]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA25215 for <[e-mail]>; Tue, 1 May 2001 04:41:21 -0700 (PDT)
Received: from cpxuser (PPPa69-ResaleDetroit1-2R7402.dialinx.net [4.16.192.226]) by dtctxexchims05.ins.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 210KX5BR; Tue, 1 May 2001 06:36:09 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Tue, 01 May 2001 07:40:18 -0400
To: "Housley, Russ" <[e-mail]>, [e-mail]
From: Roger Younglove <[e-mail]>
Subject: Re: CPS Pointer
In-Reply-To: <[e-mail]. com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

No, I believe that HTTP and FTP forms of URI are sufficient. As long as the 
relying party has a pointer to the CPS that should be sufficient.
At 02:32 PM 04/30/2001 , Housley, Russ wrote:
>Trevor Freeman noticed we don't have any guidelines for what forms of URI 
>are supported with the CPS Pointer.  Presently, we say:
>
>    The CPS Pointer qualifier contains a pointer to a Certification
>    Practice Statement (CPS) published by the CA.  The pointer is in the
>    form of a URI.  Processing requirements for this qualifier are a
>    local matter.  No action is mandated by this specification regardless
>    of the criticality value asserted for the extension.
>
>So, we are not mandating any behavior on the client.  Perhaps we should 
>say something about the CA.  Trevor suggests that HTTP and FTP forms of 
>URI are sufficient.  Does anyone see any reason to support other protocols 
>for CPS fetching?
>
>Russ

--------
TTFN
Roger W. Younglove, CISSP
Distinguished Member of Consulting Staff
Lucent Worldwide Services--Information Security
100 Galleria Officentre, Ste. 220
Southfield, MI 48034-8428
Numeric page: 888.935.6755
E-mail page:
[e-mail]
eFax number: 413.425.5368
www.lucent.com/netcare