announcement of the rescheduled directory meeting in Flagstaff

["Hoyt L. Kesterson II" <[e-mail]>]

hello all

The announcement of the rescheduled Flagstaff meeting is at

     ftp://ftp.bull.com/pub/OSIdirectory/Flagstaff2001/announcementRev3.pdf

The major differences in the announcement are;

The date is 12 - 16 November 2001

The agenda is changed - e.g., work on X.509/part 8 is now on 12 and 13 November

Reservations must be made by 20 October. The room rate is lowered to 
$90 but it will be colder.

Additional input documents are identified.

Travel directions from Las Vegas to the hotel are included. Several 
people found that it was less expensive to book a flight to Las Vegas 
than to Phoenix.

As before, the input documents for this meeting can be found at

   ftp://ftp.bull.com/pub/OSIdirectory/Flagstaff2001/InputDocuments/  and

   ftp://ftp.bull.com/pub/OSIdirectory/Geneva2001Output/

    hoyt



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f912mb829044 for ietf-pkix-bks; Sun, 30 Sep 2001 19:48:37 -0700 (PDT)
Received: from phnxpop4.phnx.uswest.net (phnxpop4.phnx.uswest.net [206.80.192.4]) by above.proper.com (8.11.6/8.11.3) with SMTP id f912mZD29039 for <[e-mail]>; Sun, 30 Sep 2001 19:48:35 -0700 (PDT)
Received: (qmail 2449 invoked by alias); 1 Oct 2001 02:48:32 -0000
Delivered-To: [e-mail]@fixme
Received: (qmail 2273 invoked by uid 0); 1 Oct 2001 02:48:27 -0000
Received: from wdialup111.phnx.uswest.net (HELO ?192.168.0.2?) (209.181.129.111) by phnxpop4.phnx.uswest.net with SMTP; 1 Oct 2001 02:48:27 -0000
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <a05100302b7dd85d0f234@[192.168.0.2]>
Date: Sun, 30 Sep 2001 19:42:53 -0700
To: "X.509":;, IETF LDAP <[e-mail]>, SC6 Staff:;, Boguslaw Georges Sebek <[e-mail]>, "Bertine, Herbert V (Herbert" <[e-mail]>
From: "Hoyt L. Kesterson II" <[e-mail]>
Subject: announcement of the rescheduled directory meeting in Flagstaff
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

The announcement of the rescheduled Flagstaff meeting is at

     ftp://ftp.bull.com/pub/OSIdirectory/Flagstaff2001/announcementRev3.pdf

The major differences in the announcement are;

The date is 12 - 16 November 2001

The agenda is changed - e.g., work on X.509/part 8 is now on 12 and 13 November

Reservations must be made by 20 October. The room rate is lowered to 
$90 but it will be colder.

Additional input documents are identified.

Travel directions from Las Vegas to the hotel are included. Several 
people found that it was less expensive to book a flight to Las Vegas 
than to Phoenix.

As before, the input documents for this meeting can be found at

   ftp://ftp.bull.com/pub/OSIdirectory/Flagstaff2001/InputDocuments/  and

   ftp://ftp.bull.com/pub/OSIdirectory/Geneva2001Output/

    hoyt


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8PBSpU02871 for ietf-pkix-bks; Tue, 25 Sep 2001 04:28:51 -0700 (PDT)
Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8PBSnD02866 for <[e-mail]>; Tue, 25 Sep 2001 04:28:49 -0700 (PDT)
Received: from santesson.addtrust.com ([192.168.101.132]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 25 Sep 2001 13:28:43 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Tue, 25 Sep 2001 13:28:51 +0200
To: Stephen Kent <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: Logos: objection to charter revisions
Cc: "PKIX (E-mail)" <[e-mail]>
In-Reply-To: <p05010406b7d4ef12868c@[128.33.84.34]>
References: <[e-mail]> <[e-mail].a u> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 25 Sep 2001 11:28:43.0906 (UTC) FILETIME=[3BE0A620:01C145B5]
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,

Thanks for the clarifications. I agree in general to everything you say.

Speking of users trust in a CA I wander though what mechanisms users have 
to quantify trust in the certificate and it's content (including 
extensions) after passing the validation mechanisms performed according to 
local policy.

Is the user (human person) supposed to know what kind of extension data 
that this particular CA is trusted to certify?

Havn't we failed if we are forced to use such assumtions?

Isn't it fair to require all cross certifying CA's to make sure that the 
CA's they cross certify have agreed to behave in such was that the user can 
perform an "unqualified act of trust"?

Do you have any suggestions regarding how to contrain CA's use of 
extensions and their content?

/Stefan

At 10:19 2001-09-24 -0400, Stephen Kent wrote:

>Stefan,
>
>
>><snip>
>
>
>
>>Now, the concern here is if a CA issues a certificate with false logos, 
>>inconsistent with the present names. Could a user be fooled?
>>Yes of course would a user be fooled, but the flaw is not in the logotype 
>>presence. The flaw is that your validation processing allows trust in a 
>>bad CA. And if you have allowed trust in such CA, logos are the least of 
>>your problems.
>
>In fairness, your characterization seems to be based on the assumption 
>that acceptance of certs issued by a CA represents an unqualified act of 
>trust.  This may be the case for public CAs, but it is not for 
>organizational CAs, for example. We have the name constraints extension to 
>allow us to control the space of names that we will accept from CAs we 
>cross certify.  So we already have mechanisms to avoid the need to trust 
>completely every CA that we cross certify.
>
>>In the end, the self regulating factor is also that nobody can issue 
>>certificates with bad information and hide from that fact. A bad CA, 
>>which isn't living up to its decalred practices, will soon be out of 
>>business and sued up to its ears.
>
>Yes, but wherever possible we like to impose technical constraints on CA 
>behavior, not just rely on remedial, legal, actions.  The question is to 
>what extent can we do that with the proposed logotype extension?
>
>>I understand the fear for things we can not control, but names and logos 
>>are simply such things. Its use and trust in them must be handled by the 
>>market of CA's, not in a standards body.
>
>But, as noted above, we DO have some ability to control bad names.
>
>>But as I said. The protocol issues are standards work. Lets assume our 
>>responsibility and provide solid tools needed by the market, and make 
>>them good and globally interoperable.
>>
>>Whether you like it or not. So far, all major market players I have 
>>talked to (and they are many), including members of the European CA forum 
>>(ECAF) and including the mobile world, wants and needs logos. Lets not 
>>hide from this fact in our own little dream world. Lets accept the 
>>challenge instead.
>
>Endorsements from vendors and vendor fora of this sort have never been an 
>acceptable justification for our adopting a proposed mechanism.  It's 
>appropriate to cite such interest to justify spending the WG's time on 
>this proposed work item, but it does not mean that we will create a 
>standard based on such endorsements. This WG, like all others in the IETF, 
>is composed of individual technical contributors who represent themselves 
>in discussions and who strive to persuade other WG members of the 
>technical merits of protocols that are offered as standards.
>
>Steve



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8ONKUv20062 for ietf-pkix-bks; Mon, 24 Sep 2001 16:20:30 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8ONKSD20058 for <[e-mail]>; Mon, 24 Sep 2001 16:20:28 -0700 (PDT)
Received: from [128.33.238.23] (TC023.BBN.COM [128.33.238.23]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA29906; Mon, 24 Sep 2001 19:20:20 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <p05010407b7d55ee5ade5@[128.33.238.91]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 24 Sep 2001 18:14:42 -0400
To: "Tom Gindin" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Logos: objection to charter revisions
Cc: "PKIX (E-mail)" <[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>

At 2:03 PM -0400 9/24/01, Tom Gindin wrote:
>      While I am not sure that Steve proposed that individuals issue
>cross-certs in his posting, I would like to record my view that allowing an
>RP to extend trust to a specific root CA with restrictions similar to the
>constraints extensions is a desirable feature in an API.  Since IMHO this
>is basically an API issue, I'm not sure that it's within PKIX's scope.
>
>           Tom Gindin
>
Right.  I did not say anything about "individuals" issuing cross 
certs.  I referred to organizational CAs, e.g., certified by other 
such CAs, or by bridge CAs, etc.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8OI5Np13880 for ietf-pkix-bks; Mon, 24 Sep 2001 11:05:23 -0700 (PDT)
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8OI5LD13873 for <[e-mail]>; Mon, 24 Sep 2001 11:05:21 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA116122; Mon, 24 Sep 2001 14:02:44 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8OHtUZ226922; Mon, 24 Sep 2001 13:55:31 -0400
Importance: Normal
Subject: RE: Logos: objection to charter revisions
To: Peter Williams <[e-mail]>
Cc: "'Stephen Kent'" <[e-mail]>, Stefan Santesson <[e-mail]>, "PKIX (E-mail)" <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Mon, 24 Sep 2001 14:03:54 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.8 SPR #MIAS4UTJ8H |June 21, 2001) at 09/24/2001 02:03:47 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>

     While I am not sure that Steve proposed that individuals issue
cross-certs in his posting, I would like to record my view that allowing an
RP to extend trust to a specific root CA with restrictions similar to the
constraints extensions is a desirable feature in an API.  Since IMHO this
is basically an API issue, I'm not sure that it's within PKIX's scope.

          Tom Gindin


Peter Williams <[e-mail]>@mail.imc.org on 09/24/2001 11:36:46 AM

Sent by:  [e-mail]


To:   "'Stephen Kent'" <[e-mail]>, Stefan Santesson
      <[e-mail]>
cc:   "PKIX (E-mail)" <[e-mail]>
Subject:  RE: Logos: objection to charter revisions



Steve proposed that individuals be
able to issue cross-certificates
to limit, by virtue of the name
constraints, the degree to which
trust is helf in a given CA, acting
in support of some secure interworking activity.

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Monday, September 24, 2001 7:20 AM
To: Stefan Santesson
Cc: PKIX (E-mail)
Subject: Re: Logos: objection to charter revisions



Stefan,


><snip>



>Now, the concern here is if a CA issues a certificate with false
>logos, inconsistent with the present names. Could a user be fooled?
>Yes of course would a user be fooled, but the flaw is not in the
>logotype presence. The flaw is that your validation processing
>allows trust in a bad CA. And if you have allowed trust in such CA,
>logos are the least of your problems.

In fairness, your characterization seems to be based on the
assumption that acceptance of certs issued by a CA represents an
unqualified act of trust.  This may be the case for public CAs, but
it is not for organizational CAs, for example. We have the name
constraints extension to allow us to control the space of names that
we will accept from CAs we cross certify.  So we already have
mechanisms to avoid the need to trust completely every CA that we
cross certify.

>In the end, the self regulating factor is also that nobody can issue
>certificates with bad information and hide from that fact. A bad CA,
>which isn't living up to its decalred practices, will soon be out of
>business and sued up to its ears.

Yes, but wherever possible we like to impose technical constraints on
CA behavior, not just rely on remedial, legal, actions.  The question
is to what extent can we do that with the proposed logotype extension?

>I understand the fear for things we can not control, but names and
>logos are simply such things. Its use and trust in them must be
>handled by the market of CA's, not in a standards body.

But, as noted above, we DO have some ability to control bad names.

>But as I said. The protocol issues are standards work. Lets assume
>our responsibility and provide solid tools needed by the market, and
>make them good and globally interoperable.
>
>Whether you like it or not. So far, all major market players I have
>talked to (and they are many), including members of the European CA
>forum (ECAF) and including the mobile world, wants and needs logos.
>Lets not hide from this fact in our own little dream world. Lets
>accept the challenge instead.

Endorsements from vendors and vendor fora of this sort have never
been an acceptable justification for our adopting a proposed
mechanism.  It's appropriate to cite such interest to justify
spending the WG's time on this proposed work item, but it does not
mean that we will create a standard based on such endorsements. This
WG, like all others in the IETF, is composed of individual technical
contributors who represent themselves in discussions and who strive
to persuade other WG members of the technical merits of protocols
that are offered as standards.

Steve






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8OFi1J05723 for ietf-pkix-bks; Mon, 24 Sep 2001 08:44:01 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8OFhxD05716 for <[e-mail]>; Mon, 24 Sep 2001 08:43:59 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Mon, 24 Sep 2001 08:44:39 -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, 24 Sep 2001 08:44:39 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <SMT36R76>; Mon, 24 Sep 2001 08:36:47 -0700
Content-return: allowed
Date: Mon, 24 Sep 2001 08:36:46 -0700
From: Peter Williams <[e-mail]>
Subject: RE: Logos: objection to charter revisions
To: "'Stephen Kent'" <[e-mail]>, Stefan Santesson <[e-mail]>
Cc: "PKIX (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
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 proposed that individuals be
able to issue cross-certificates
to limit, by virtue of the name
constraints, the degree to which
trust is helf in a given CA, acting
in support of some secure interworking activity. 

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Monday, September 24, 2001 7:20 AM
To: Stefan Santesson
Cc: PKIX (E-mail)
Subject: Re: Logos: objection to charter revisions



Stefan,


><snip>



>Now, the concern here is if a CA issues a certificate with false 
>logos, inconsistent with the present names. Could a user be fooled?
>Yes of course would a user be fooled, but the flaw is not in the 
>logotype presence. The flaw is that your validation processing 
>allows trust in a bad CA. And if you have allowed trust in such CA, 
>logos are the least of your problems.

In fairness, your characterization seems to be based on the 
assumption that acceptance of certs issued by a CA represents an 
unqualified act of trust.  This may be the case for public CAs, but 
it is not for organizational CAs, for example. We have the name 
constraints extension to allow us to control the space of names that 
we will accept from CAs we cross certify.  So we already have 
mechanisms to avoid the need to trust completely every CA that we 
cross certify.

>In the end, the self regulating factor is also that nobody can issue 
>certificates with bad information and hide from that fact. A bad CA, 
>which isn't living up to its decalred practices, will soon be out of 
>business and sued up to its ears.

Yes, but wherever possible we like to impose technical constraints on 
CA behavior, not just rely on remedial, legal, actions.  The question 
is to what extent can we do that with the proposed logotype extension?

>I understand the fear for things we can not control, but names and 
>logos are simply such things. Its use and trust in them must be 
>handled by the market of CA's, not in a standards body.

But, as noted above, we DO have some ability to control bad names.

>But as I said. The protocol issues are standards work. Lets assume 
>our responsibility and provide solid tools needed by the market, and 
>make them good and globally interoperable.
>
>Whether you like it or not. So far, all major market players I have 
>talked to (and they are many), including members of the European CA 
>forum (ECAF) and including the mobile world, wants and needs logos. 
>Lets not hide from this fact in our own little dream world. Lets 
>accept the challenge instead.

Endorsements from vendors and vendor fora of this sort have never 
been an acceptable justification for our adopting a proposed 
mechanism.  It's appropriate to cite such interest to justify 
spending the WG's time on this proposed work item, but it does not 
mean that we will create a standard based on such endorsements. This 
WG, like all others in the IETF, is composed of individual technical 
contributors who represent themselves in discussions and who strive 
to persuade other WG members of the technical merits of protocols 
that are offered as standards.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8OEMnM29143 for ietf-pkix-bks; Mon, 24 Sep 2001 07:22:49 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8OEMmD29138 for <[e-mail]>; Mon, 24 Sep 2001 07:22:48 -0700 (PDT)
Received: from [128.33.84.34] (comsec.bbn.com [128.33.84.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA13790; Mon, 24 Sep 2001 10:22:02 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010406b7d4ef12868c@[128.33.84.34]>
In-Reply-To: <[e-mail]>
References:  <[e-mail].a u> <[e-mail]> <[e-mail]>
Date: Mon, 24 Sep 2001 10:19:45 -0400
To: Stefan Santesson <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Logos: objection to charter revisions
Cc: "PKIX (E-mail)" <[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>

Stefan,


><snip>



>Now, the concern here is if a CA issues a certificate with false 
>logos, inconsistent with the present names. Could a user be fooled?
>Yes of course would a user be fooled, but the flaw is not in the 
>logotype presence. The flaw is that your validation processing 
>allows trust in a bad CA. And if you have allowed trust in such CA, 
>logos are the least of your problems.

In fairness, your characterization seems to be based on the 
assumption that acceptance of certs issued by a CA represents an 
unqualified act of trust.  This may be the case for public CAs, but 
it is not for organizational CAs, for example. We have the name 
constraints extension to allow us to control the space of names that 
we will accept from CAs we cross certify.  So we already have 
mechanisms to avoid the need to trust completely every CA that we 
cross certify.

>In the end, the self regulating factor is also that nobody can issue 
>certificates with bad information and hide from that fact. A bad CA, 
>which isn't living up to its decalred practices, will soon be out of 
>business and sued up to its ears.

Yes, but wherever possible we like to impose technical constraints on 
CA behavior, not just rely on remedial, legal, actions.  The question 
is to what extent can we do that with the proposed logotype extension?

>I understand the fear for things we can not control, but names and 
>logos are simply such things. Its use and trust in them must be 
>handled by the market of CA's, not in a standards body.

But, as noted above, we DO have some ability to control bad names.

>But as I said. The protocol issues are standards work. Lets assume 
>our responsibility and provide solid tools needed by the market, and 
>make them good and globally interoperable.
>
>Whether you like it or not. So far, all major market players I have 
>talked to (and they are many), including members of the European CA 
>forum (ECAF) and including the mobile world, wants and needs logos. 
>Lets not hide from this fact in our own little dream world. Lets 
>accept the challenge instead.

Endorsements from vendors and vendor fora of this sort have never 
been an acceptable justification for our adopting a proposed 
mechanism.  It's appropriate to cite such interest to justify 
spending the WG's time on this proposed work item, but it does not 
mean that we will create a standard based on such endorsements. This 
WG, like all others in the IETF, is composed of individual technical 
contributors who represent themselves in discussions and who strive 
to persuade other WG members of the technical merits of protocols 
that are offered as standards.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8OCopu25048 for ietf-pkix-bks; Mon, 24 Sep 2001 05:50:51 -0700 (PDT)
Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8OComD25044 for <[e-mail]>; Mon, 24 Sep 2001 05:50:48 -0700 (PDT)
Received: from santesson.addtrust.com ([192.168.101.132]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 24 Sep 2001 14:50:42 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Mon, 24 Sep 2001 14:50:49 +0200
To: Denis Pinkas <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: Logos: objection to charter revisions
Cc: "PKIX (E-mail)" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_21470683==_.ALT"
X-OriginalArrivalTime: 24 Sep 2001 12:50:42.0359 (UTC) FILETIME=[85174470:01C144F7]
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>

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

Denis,

3 Issues:

1) Should logos be checked by automatic processing?
No. Logotypes can't be processed as part of certificate validation 
processing, with one exception which is the binary "allowed" or "not 
allowed" local policy.

2) What logotypes should be displayed in a chain of certificates?
This is up to applications to decide but in general: When you view a 
certificate, only the logos of that certificate is displayed. If you view a 
chain, then normally that view doesn't show certificate details and would 
not show any logo at all. Future applications may however show logotypes 
for each certificate as they display a chain but when displaying a single 
certificate i doubt that any other logos will be displayed.

3) Is there a conflict between automatic validation processing and human 
processing of logotypes
My view is that we have no conflict.
A validation process is the first pit-stop, which will check the 
trustworthiness of a certificate (including its chain) including:
- Chaining to a trusted root
- Validity periods
- Revocation status and presence of suitable status checking service
- key usage
- Key lengths and algorithms
- Suitability and acceptance of certificate policies
- Suitability and acceptance of present names and name forms
- Suitability and acceptance of extensions (including logos)

This process gives a yes and no answer to the question. "Is this 
certificate valid, trusted and fit for its purpose?"

If the user is a mashie. This stops here and goes directly to authorization 
processing in applications.

If not, then we have pit-stop number two, display of certificates, given 
that the certificates passed pit-stop 1
If the user is a person and if his client is configured to display logos. 
The user will have a convenient way to view the certificate through display 
of logos together with associated names in text.

Now, the concern here is if a CA issues a certificate with false logos, 
inconsistent with the present names. Could a user be fooled?
Yes of course would a user be fooled, but the flaw is not in the logotype 
presence. The flaw is that your validation processing allows trust in a bad 
CA. And if you have allowed trust in such CA, logos are the least of your 
problems.

In the end, the self regulating factor is also that nobody can issue 
certificates with bad information and hide from that fact. A bad CA, which 
isn't living up to its decalred practices, will soon be out of business and 
sued up to its ears.

I understand the fear for things we can not control, but names and logos 
are simply such things. Its use and trust in them must be handled by the 
market of CA's, not in a standards body.

But as I said. The protocol issues are standards work. Lets assume our 
responsibility and provide solid tools needed by the market, and make them 
good and globally interoperable.

Whether you like it or not. So far, all major market players I have talked 
to (and they are many), including members of the European CA forum (ECAF) 
and including the mobile world, wants and needs logos. Lets not hide from 
this fact in our own little dream world. Lets accept the challenge instead.

/Stefan


At 11:30 2001-09-24 +0200, Denis Pinkas wrote:

>Stefan,
>
>The current point is whether we include or not this work item on our "PKIX
>plate". I wonder what the decision is at this time. Nevertheless, I will
>provide you with some comments on your e-mail.
>
> > Denis,
> >
> > As I catch up the logo discussion, I think your questions are pretty much
> > answered in the current draft.
> >
> > In principle, there is no difference between the certificate types you
> > mention regarding logos. What the logos means to the relying party is up to
> > each relying party to define.
>
>It seems difficult define extensions which have a left open and hence
>undefined meaning !
>
> > What is more important is that the different the logotypes have distinct
> > meanings.
> >
> > 1) Subject organization logotype: The logotype of the organization
> > specified in the subject field
> > 2) Issuer Logotype: The logotype of the organization specified in the
> > issuer field
> > 3) Concept logotype: A logotype used by the issuer to represent the concept
> > under which the certificate was issued.
> >
> > The concept may represent a type of assurance level, policy or a family of
> > distinct services shared between multiple CAs.
>
> > The meaning of these logotypes are the same for any type of certificate,
> > but in general they are only used to enhance human recognition after the
> > certificate having passed all other validation criteria for certificate
> > reliance.
>
>This is the main point that puzzles me. In other words, this extension is
>never checked when an automatic processing is being used, but is only
>checked (how ???, using which criteria ???) by a human being. When this
>extension appears in multiple certificates from a chain, shall all the
>logotypes be displayed, or printed ? How should this be done ?
>
>But the main point is that this could lead to different results whether
>human interactions or automatic processing is performed.
>
>Isn't it a problem ?
>
>Denis
>
>
> > /Stefan
> >
> > At 11:02 2001-09-06 +0200, Denis Pinkas wrote:
> >
> > >After seeing all that discussion about logos, I realized that we had
> > >a solution (i.e. the draft writen by Stefan) for an unknown problem.
> > >
> > >1) Are logos to be used in server certificates ?
> > >    If so, what would be their intended meaning ?
> > >
> > >2) Are logos to be used in human-user certificates ?
> > >    If so, what would be their intended meaning ?
> > >
> > >3) Are logos to be used in CA certificates ?
> > >    If so, what would be their intended meaning ?
> > >
> > >4) Are logos to be used in self-signed certificates ?
> > >    If so, what would be their intented meaning ?
> > >
> > >I do not think that the meaning and the use of the logo information will
> > >necessarilly be the same for all of the above cases.
> > >
> > >If that topic is going to stay on the charter, before we define a solution
> > >we should first define the requirements. So an INFORMATIONAL RFC on the
> > >requirements should be the first step. This Informational RFC should at
> > >least answer to the questions raised above.
> > >
> > >Denis

--=====================_21470683==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Denis,<br>
<br>
3 Issues:<br>
<br>
<b>1) Should logos be checked by automatic processing?<br>
</b>No. Logotypes can't be processed as part of certificate validation
processing, with one exception which is the binary &quot;allowed&quot; or
&quot;not allowed&quot; local policy. <br>
<br>
<b>2) What logotypes should be displayed in a chain of 
certificates?<br>
</b>This is up to applications to decide but in general: When you view a
certificate, only the logos of that certificate is displayed. If you view
a chain, then normally that view doesn't show certificate details and
would not show any logo at all. Future applications may however show
logotypes for each certificate as they display a chain but when
displaying a single certificate i doubt that any other logos will be
displayed.<br>
<br>
<b>3) Is there a conflict between automatic validation processing and
human processing of logotypes<br>
</b>My view is that we have no conflict.<br>
A validation process is the first pit-stop, which will check the
trustworthiness of a certificate (including its chain) including:<br>
- Chaining to a trusted root<br>
- Validity periods<br>
- Revocation status and presence of suitable status checking 
service<br>
- key usage<br>
- Key lengths and algorithms<br>
- Suitability and acceptance of certificate policies<br>
- Suitability and acceptance of present names and name forms<br>
- Suitability and acceptance of extensions (including logos)<br>
<br>
This process gives a yes and no answer to the question. &quot;Is this
certificate valid, trusted and fit for its purpose?&quot;<br>
<br>
If the user is a mashie. This stops here and goes directly to
authorization processing in applications.<br>
<br>
If not, then we have pit-stop number two, display of certificates, given
that the certificates passed pit-stop 1<br>
If the user is a person and if his client is configured to display logos.
The user will have a convenient way to view the certificate through
display of logos together with associated names in text.<br>
<br>
Now, the concern here is if a CA issues a certificate with false logos,
inconsistent with the present names. Could a user be fooled?<br>
Yes of course would a user be fooled, but the flaw is not in the logotype
presence. The flaw is that your validation processing allows trust in a
bad CA. And if you have allowed trust in such CA, logos are the least of
your problems.<br>
<br>
In the end, the self regulating factor is also that nobody can issue
certificates with bad information and hide from that fact. A bad CA,
which isn't living up to its decalred practices, will soon be out of
business and sued up to its ears.<br>
<br>
I understand the fear for things we can not control, but names and logos
are simply such things. Its use and trust in them must be handled by the
market of CA's, not in a standards body.<br>
<br>
But as I said. The protocol issues are standards work. Lets assume our
responsibility and provide solid tools needed by the market, and make
them good and globally interoperable.<br>
<br>
Whether you like it or not. So far, all major market players I have
talked to (and they are many), including members of the European CA forum
(ECAF) and including the mobile world, wants and needs logos. Lets not
hide from this fact in our own little dream world. Lets accept the
challenge instead.<br>
<br>
/Stefan<br>
<br>
<br>
At 11:30 2001-09-24 +0200, Denis Pinkas wrote:<br>
<br>
<blockquote type=cite class=cite cite>Stefan,<br>
<br>
The current point is whether we include or not this work item on our
&quot;PKIX<br>
plate&quot;. I wonder what the decision is at this time. Nevertheless, I
will<br>
provide you with some comments on your e-mail.<br>
<br>
&gt; Denis,<br>
&gt; <br>
&gt; As I catch up the logo discussion, I think your questions are pretty
much<br>
&gt; answered in the current draft.<br>
&gt; <br>
&gt; In principle, there is no difference between the certificate types
you<br>
&gt; mention regarding logos. What the logos means to the relying party
is up to<br>
&gt; each relying party to define.<br>
<br>
It seems difficult define extensions which have a left open and
hence<br>
undefined meaning !<br>
&nbsp;<br>
&gt; What is more important is that the different the logotypes have
distinct<br>
&gt; meanings.<br>
&gt;<br>
&gt; 1) Subject organization logotype: The logotype of the
organization<br>
&gt; specified in the subject field<br>
&gt; 2) Issuer Logotype: The logotype of the organization specified in
the<br>
&gt; issuer field<br>
&gt; 3) Concept logotype: A logotype used by the issuer to represent the
concept<br>
&gt; under which the certificate was issued.<br>
&gt; <br>
&gt; The concept may represent a type of assurance level, policy or a
family of<br>
&gt; distinct services shared between multiple CAs.<br>
&nbsp;<br>
&gt; The meaning of these logotypes are the same for any type of
certificate,<br>
&gt; but in general they are only used to enhance human recognition after
the<br>
&gt; certificate having passed all other validation criteria for
certificate<br>
&gt; reliance.<br>
<br>
This is the main point that puzzles me. In other words, this extension
is<br>
never checked when an automatic processing is being used, but is
only<br>
checked (how ???, using which criteria ???) by a human being. When
this<br>
extension appears in multiple certificates from a chain, shall all
the<br>
logotypes be displayed, or printed ? How should this be done ? <br>
<br>
But the main point is that this could lead to different results
whether<br>
human interactions or automatic processing is performed. <br>
<br>
Isn't it a problem ?&nbsp; <br>
<br>
Denis<br>
<br>
&nbsp;<br>
&gt; /Stefan<br>
&gt; <br>
&gt; At 11:02 2001-09-06 +0200, Denis Pinkas wrote:<br>
&gt; <br>
&gt; &gt;After seeing all that discussion about logos, I realized that we
had<br>
&gt; &gt;a solution (i.e. the draft writen by Stefan) for an unknown
problem.<br>
&gt; &gt;<br>
&gt; &gt;1) Are logos to be used in server certificates ?<br>
&gt; &gt;&nbsp;&nbsp;&nbsp; If so, what would be their intended meaning
?<br>
&gt; &gt;<br>
&gt; &gt;2) Are logos to be used in human-user certificates ?<br>
&gt; &gt;&nbsp;&nbsp;&nbsp; If so, what would be their intended meaning
?<br>
&gt; &gt;<br>
&gt; &gt;3) Are logos to be used in CA certificates ?<br>
&gt; &gt;&nbsp;&nbsp;&nbsp; If so, what would be their intended meaning
?<br>
&gt; &gt;<br>
&gt; &gt;4) Are logos to be used in self-signed certificates ?<br>
&gt; &gt;&nbsp;&nbsp;&nbsp; If so, what would be their intented meaning
?<br>
&gt; &gt;<br>
&gt; &gt;I do not think that the meaning and the use of the logo
information will<br>
&gt; &gt;necessarilly be the same for all of the above cases.<br>
&gt; &gt;<br>
&gt; &gt;If that topic is going to stay on the charter, before we define
a solution<br>
&gt; &gt;we should first define the requirements. So an INFORMATIONAL RFC
on the<br>
&gt; &gt;requirements should be the first step. This Informational RFC
should at<br>
&gt; &gt;least answer to the questions raised above.<br>
&gt; &gt;<br>
&gt; &gt;Denis </blockquote></html>

--=====================_21470683==_.ALT--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8O9kYZ13554 for ietf-pkix-bks; Mon, 24 Sep 2001 02:46:34 -0700 (PDT)
Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8O9kWD13547 for <[e-mail]>; Mon, 24 Sep 2001 02:46:32 -0700 (PDT)
Received: from santesson.addtrust.com ([192.168.101.132]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 24 Sep 2001 11:46:26 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Mon, 24 Sep 2001 11:46:34 +0200
To: Steve Hanna <[e-mail]>, Stephen Kent <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Logos in PKIX - Was: charter revisions
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <p0501040bb7a8214adf35@[128.33.84.34]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 24 Sep 2001 09:46:26.0828 (UTC) FILETIME=[C77B1CC0:01C144DD]
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,

There has been a lot of discussions regarding logos and as reply to the 
whole discussion I would like to debate some of your original issues 
concerning logos.

First as a general remark:

Some say that logos are not a security issue and should not be handled in PKIX.

The security issue is indirect but very real. We are dealing with an 
infrastructure for public key recognition. (i.e. who is the owner of this 
key or what is the right key for XX). The user of this infrastructure is 
devices, applications and humans, where humans is the worst kind.

Humans are unpredictable, has bad memory, acts irresponsibly and has low 
calculation capacity. In other words - they need help.
Providing help to humans, in a human way, IS a real security issue. 
Providing bad human interfaces is BAD security.

The simple rule is:
Human recognition of text based names is bad.
Human recognition of visual symbols and visual concepts is good.

This is why we use logotypes and symbols in all possible situations and 
applications in the world where we have a human user.

The common objection is uncertainties of the trustworthiness of logotypes, 
i.e how we can assure what logotype is legitimate for what entity.

This is in fact an issue which goes far beyond PKIX and where PKIX should 
NOT try to provide solutions as little as PKIX try to make standards for 
policies and legal aspects of names and any other attributes. As 
representing a commercial CA service, I see this as the least problem right 
now. If there is a will, there is a way.

But the protocol aspect of logos is a PKIX issue. I.e. how to include them, 
formats and parsing issues together with its relationship with path 
processing and means of specifying policy aspects.

More comments follow in line;

At 17:00 2001-08-29 -0400, Steve Hanna wrote:

>I haven't seen any comments on the revised charter yet. Most of it looks
>good to me. However, I don't think PKIX should do any work on the
>logotype extension. I know that there is a demand for this from
>marketing folks, but I don't believe that we should standardize it
>unless it can be used securely. This does not seem possible.
>
>First, CAs will find it very hard to verify whether a particular
>logotype should be included in a particular certificate. They'll just
>need to certify whatever the client gives them and disclaim all
>responsibility for its accuracy. With textual names, at least they can
>make some attempt to verify that the name corresponds to the requesting
>client (by requiring a response from an email address before it's
>certified, for instance).

This is a legal issue that PKIX should move away from. There are many ways 
to tie a logotype to an organization, as there are with names. This is 
nothing new for certificates. The simplest way is to get a signed statement 
from the company tied to some penalty for giving false information. It is 
not fool proof but it may be good enough for many applications.

>Second, there's no equivalent to name constraints for use in cross
>certificates. If I cross certify someone, I just have to trust that they
>(and anyone they certify) will only put proper logotypes into
>certificates.

Correct. If you cross certify a CA you will need to determine if you want 
to link trust to their way of issuing certificates.

>Third, an apparently innocuous logotype can change appearance radically
>when scaled to a smaller size or mapped to a different number of colors.
>This can be exploited to deceive cell phone users into thinking that
>they're communicating with their bank, for instance.

This is an issue we need to discuss further. I have no answer to this but 
it is not a reason not to do the job.

>Unless these concerns can be addressed, I do not think that this
>proposal is safe and secure. And I do not think that the IETF should
>publish an RFC on a fundamentally insecure idea, especially from a
>security working group.

Following this reasoning we also need to cancel RFC 2459 and all derivative 
work as well. God knows what kind of un trusted information you can put 
into certificates to fool people if you want.

As I said. We need to remove the legal aspects from the PKIX agenda and 
focus on the protocol aspects, and make that aspect SECURE. As representing 
a commercial CA I guarantee that 1) there is a real need for this, 2) it 
will be implemented and 3) there are ways of being sure enough on the 
accuracy of logotypes.

>-Steve

/Stefan



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8O9V0d11978 for ietf-pkix-bks; Mon, 24 Sep 2001 02:31:00 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8O9UwD11958 for <[e-mail]>; Mon, 24 Sep 2001 02:30:59 -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 LAA31718; Mon, 24 Sep 2001 11:33:16 +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 LAA12080; Mon, 24 Sep 2001 11:30:25 +0200
Message-ID: <[e-mail]>
Date: Mon, 24 Sep 2001 11:30:25 +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: Stefan Santesson <[e-mail]>
CC: "PKIX (E-mail)" <[e-mail]>
Subject: Re: Logos: objection to charter revisions
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>

Stefan,

The current point is whether we include or not this work item on our "PKIX
plate". I wonder what the decision is at this time. Nevertheless, I will
provide you with some comments on your e-mail.

> Denis,
> 
> As I catch up the logo discussion, I think your questions are pretty much
> answered in the current draft.
> 
> In principle, there is no difference between the certificate types you
> mention regarding logos. What the logos means to the relying party is up to
> each relying party to define.

It seems difficult define extensions which have a left open and hence
undefined meaning !
 
> What is more important is that the different the logotypes have distinct
> meanings.
>
> 1) Subject organization logotype: The logotype of the organization
> specified in the subject field
> 2) Issuer Logotype: The logotype of the organization specified in the
> issuer field
> 3) Concept logotype: A logotype used by the issuer to represent the concept
> under which the certificate was issued.
> 
> The concept may represent a type of assurance level, policy or a family of
> distinct services shared between multiple CAs.
 
> The meaning of these logotypes are the same for any type of certificate,
> but in general they are only used to enhance human recognition after the
> certificate having passed all other validation criteria for certificate
> reliance.

This is the main point that puzzles me. In other words, this extension is
never checked when an automatic processing is being used, but is only
checked (how ???, using which criteria ???) by a human being. When this
extension appears in multiple certificates from a chain, shall all the
logotypes be displayed, or printed ? How should this be done ? 

But the main point is that this could lead to different results whether
human interactions or automatic processing is performed. 

Isn't it a problem ?  

Denis

 
> /Stefan
> 
> At 11:02 2001-09-06 +0200, Denis Pinkas wrote:
> 
> >After seeing all that discussion about logos, I realized that we had
> >a solution (i.e. the draft writen by Stefan) for an unknown problem.
> >
> >1) Are logos to be used in server certificates ?
> >    If so, what would be their intended meaning ?
> >
> >2) Are logos to be used in human-user certificates ?
> >    If so, what would be their intended meaning ?
> >
> >3) Are logos to be used in CA certificates ?
> >    If so, what would be their intended meaning ?
> >
> >4) Are logos to be used in self-signed certificates ?
> >    If so, what would be their intented meaning ?
> >
> >I do not think that the meaning and the use of the logo information will
> >necessarilly be the same for all of the above cases.
> >
> >If that topic is going to stay on the charter, before we define a solution
> >we should first define the requirements. So an INFORMATIONAL RFC on the
> >requirements should be the first step. This Informational RFC should at
> >least answer to the questions raised above.
> >
> >Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8O85JG04215 for ietf-pkix-bks; Mon, 24 Sep 2001 01:05:19 -0700 (PDT)
Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8O85GD04211 for <[e-mail]>; Mon, 24 Sep 2001 01:05:17 -0700 (PDT)
Received: from santesson.addtrust.com ([192.168.101.132]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 24 Sep 2001 10:04:54 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Mon, 24 Sep 2001 10:05:02 +0200
To: Denis Pinkas <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: Logos: objection to charter revisions
Cc: "PKIX (E-mail)" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 24 Sep 2001 08:04:55.0297 (UTC) FILETIME=[98A53F10:01C144CF]
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,

As I catch up the logo discussion, I think your questions are pretty much 
answered in the current draft.

In principle, there is no difference between the certificate types you 
mention regarding logos. What the logos means to the relying party is up to 
each relying party to define.

What is more important is that the different the logotypes have distinct 
meanings.

1) Subject organization logotype: The logotype of the organization 
specified in the subject field
2) Issuer Logotype: The logotype of the organization specified in the 
issuer field
3) Concept logotype: A logotype used by the issuer to represent the concept 
under which the certificate was issued.

The concept may represent a type of assurance level, policy or a family of 
distinct services shared between multiple CAs.

The meaning of these logotypes are the same for any type of certificate, 
but in general they are only used to enhance human recognition after the 
certificate having passed all other validation criteria for certificate 
reliance.

/Stefan


At 11:02 2001-09-06 +0200, Denis Pinkas wrote:


>After seeing all that discussion about logos, I realized that we had
>a solution (i.e. the draft writen by Stefan) for an unknown problem.
>
>1) Are logos to be used in server certificates ?
>    If so, what would be their intended meaning ?
>
>2) Are logos to be used in human-user certificates ?
>    If so, what would be their intended meaning ?
>
>3) Are logos to be used in CA certificates ?
>    If so, what would be their intended meaning ?
>
>4) Are logos to be used in self-signed certificates ?
>    If so, what would be their intented meaning ?
>
>I do not think that the meaning and the use of the logo information will
>necessarilly be the same for all of the above cases.
>
>If that topic is going to stay on the charter, before we define a solution
>we should first define the requirements. So an INFORMATIONAL RFC on the
>requirements should be the first step. This Informational RFC should at
>least answer to the questions raised above.
>
>Denis



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8K5W2w23840 for ietf-pkix-bks; Wed, 19 Sep 2001 22:32:02 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8K5W1D23836 for <[e-mail]>; Wed, 19 Sep 2001 22:32:01 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 19 Sep 2001 22:32:43 -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]>; Wed, 19 Sep 2001 22:32:42 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <SMT36D6F>; Wed, 19 Sep 2001 22:25:02 -0700
Content-return: allowed
Date: Wed, 19 Sep 2001 22:24:54 -0700
From: Ryan Hurst <[e-mail]>
Subject: RE: Clarification of ServiceLocator in RFC 2560
To: "'[e-mail]'" <[e-mail]>, "Pkix (E-mail)" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: multipart/alternative; boundary="Boundary_(ID_EEMvrFc5JSN0vkAR9fWCBw)"
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.

--Boundary_(ID_EEMvrFc5JSN0vkAR9fWCBw)
Content-type: text/plain

Andrew -
            My answer is in-line:
 
-----Original Message-----
From: Andrew Sciberras [mailto:[e-mail]] 
Sent: Wednesday, September 19, 2001 9:25 PM
To: Pkix (E-mail)
Subject: Clarification of ServiceLocator in RFC 2560
 
Hi,
 
I have a query regarding the manner in which an OCSP Server should handle
the ServiceLocator extension as specified in RFC2560. 
I would firstly like to point out section 3.2 of RFC 2560:
"    Prior to accepting a signed response as being valid, OCSP clients SHALL
confirm that:
        .......
        3. The identity of the signer matches the intended recipient of the
request.
        .....
 "
 
I would interpret #3 to basically mean that if you send a request to a
particular OCSP Server that it must be the ocsp server that signs the
response.
 
Image the scenario when an ocsp server forwards the request to the location
stated in the ServiceLocator field. 
Upon the external OCSP server processing the request it should return a
signed response regarding the certificate in question.
What should the original ocsp server do now?
    - If it simply gives the client back the signed message, wouldn't the
client have to reject it as stated above in #3?
    - Or, should the server perform all of the steps in 3.2 to ensure that
the signed response is valid, and then just resign it themselves and give
the newly signed copy to the Client?
 
<rmh>Both cases are in-fact valid, essentially it is a question to forward
or to proxy; a forward possibly makes sense in the case of an issuer
operating a public responder using a CA delegated responder
certificate.</rmh>
 
I would assume that the second statement, where the server authenticates and
resigns, is the method to use, however this was not clear to me from the
RFC.
 
Thanks,
Andrew Sciberras
Adacel Technologies Ltd
 

--Boundary_(ID_EEMvrFc5JSN0vkAR9fWCBw)
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:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
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@01C1415A.9C38E140">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"time"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"date"/>
<!--[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:Compatibility>
   <w:UseFELayout/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;
	mso-font-alt:\5B8B\4F53;
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 135135232 16 0 262145 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 135135232 16 0 262145 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:SimSun;}
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:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	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:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	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:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma'>Andrew -<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma'><span =
style=3D'mso-tab-count:1'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; </span>My
answer is in-line:</span></font><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p></o:p></spa=
n></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 style=3D'margin-left:.5in'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Andrew Sciberras
[mailto:[e-mail]<span class=3DGramE>] <br>
<b><span style=3D'font-weight:bold'>Sent</span></b></span><b><span
style=3D'font-weight:bold'>:</span></b> </span></font><st1:date =
Month=3D"9" Day=3D"19"
Year=3D"2001"><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:
 Tahoma'>Wednesday, September 19, 2001</span></font></st1:date><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
</span></font><st1:time
Hour=3D"21" Minute=3D"25"><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
 font-family:Tahoma'>9:25 PM</span></font></st1:time><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'><br>
<b><span style=3D'font-weight:bold'>To:</span></b> Pkix (E-mail)<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Clarification =
of
ServiceLocator in RFC 2560</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Hi,</span></font><o:p></o:p=
></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>I have a query regarding =
the manner
in which an OCSP Server should handle the ServiceLocator extension as =
specified
in RFC2560. </span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>I would firstly like to =
point out
section 3.2 of RFC 2560:</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&quot;&nbsp;&nbsp;&nbsp; </span></font><font =
size=3D2
face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'>Prior =
to accepting
a signed response as being valid, OCSP clients SHALL confirm =
that:</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>.......</span></font><o:p><=
/o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;
3. The identity of the signer matches the intended recipient of the =
request.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>.....</span></font><o:p></o=
:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;&quot;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>I would interpret&nbsp;#3 to basically mean =
that if
you send a request to a particular OCSP Server that it must be the ocsp =
server
that signs the response.<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Image the scenario when an =
ocsp
server forwards the request to the location stated in the =
ServiceLocator field.
</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Upon the external OCSP =
server
processing the request it should return a signed response regarding the
certificate in question.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>What should the original =
ocsp server
do now?</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;&nbsp;&nbsp; </span></font><font =
size=3D2
face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'>- If it =
simply
gives the client back the signed message, wouldn't the client have to =
reject it
as stated above in #3?</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;&nbsp;&nbsp; </span></font><font =
size=3D2
face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'>- Or, =
should the
server perform all of the steps in 3.2 to ensure that the signed =
response is
valid, and then just resign it themselves and give the newly signed =
copy to the
Client?</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<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'>&lt;<span =
class=3DSpellE>rmh</span>&gt;Both
cases are in-fact valid, essentially it is a question to forward or to =
proxy; a
forward possibly makes sense in the case of an issuer operating a =
public
responder using a CA delegated responder certificate.&lt;/<span =
class=3DSpellE>rmh</span>&gt;<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>=


</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>I would assume that the =
second
statement, where the server authenticates and resigns, is the method to =
use,
however this was not clear to me from the =
RFC.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Thanks,</span></font><o:p><=
/o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><strong><b><font =
size=3D2 face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Andrew =
Sciberras</span></font></b></strong><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Adacel Technologies =
Ltd</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

</div>

</body>

</html>

--Boundary_(ID_EEMvrFc5JSN0vkAR9fWCBw)--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8K4OQO21955 for ietf-pkix-bks; Wed, 19 Sep 2001 21:24:26 -0700 (PDT)
Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by above.proper.com (8.11.6/8.11.3) with SMTP id f8K4OFD21951 for <[e-mail]>; Wed, 19 Sep 2001 21:24:20 -0700 (PDT)
Received: (qmail 27131 invoked from network); 20 Sep 2001 04:31:54 -0000
Received: from shylock.adacel.com.au (HELO shylock) (203.8.85.11) by arnie.adacel.com.au with SMTP; 20 Sep 2001 04:31:54 -0000
Reply-To: <[e-mail]>
From: "Andrew Sciberras" <[e-mail]>
To: "Pkix \(E-mail\)" <[e-mail]>
Subject: Clarification of ServiceLocator in RFC 2560
Date: Thu, 20 Sep 2001 14:24:48 +1000
Message-ID: <024b01c1418c$2fb39650$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_024C_01C141E0.015FA650"
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_024C_01C141E0.015FA650
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

I have a query regarding the manner in which an OCSP Server should handle
the ServiceLocator extension as specified in RFC2560.
I would firstly like to point out section 3.2 of RFC 2560:
"    Prior to accepting a signed response as being valid, OCSP clients SHALL
confirm that:
        .......
        3. The identity of the signer matches the intended recipient of the
request.
        .....
 "

I would interpret #3 to basically mean that if you send a request to a
particular OCSP Server that it must be the ocsp server that signs the
response.

Image the scenario when an ocsp server forwards the request to the location
stated in the ServiceLocator field.
Upon the external OCSP server processing the request it should return a
signed response regarding the certificate in question.
What should the original ocsp server do now?
    - If it simply gives the client back the signed message, wouldn't the
client have to reject it as stated above in #3?
    - Or, should the server perform all of the steps in 3.2 to ensure that
the signed response is valid, and then just resign it themselves and give
the newly signed copy to the Client?

I would assume that the second statement, where the server authenticates and
resigns, is the method to use, however this was not clear to me from the
RFC.

Thanks,
Andrew Sciberras
Adacel Technologies Ltd


------=_NextPart_000_024C_01C141E0.015FA650
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><SPAN class=3D234475003-20092001><FONT face=3DArial=20
size=3D2>Hi,</FONT></SPAN></DIV>
<DIV><SPAN class=3D234475003-20092001><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D234475003-20092001><FONT face=3DArial size=3D2>I have =
a query=20
regarding the manner in which an OCSP Server should handle the =
ServiceLocator=20
extension as specified in RFC2560. </FONT></SPAN></DIV>
<DIV><SPAN class=3D234475003-20092001><FONT face=3DArial size=3D2>I =
would firstly like=20
to point out section 3.2 of RFC 2560:</FONT></SPAN></DIV>
<DIV><SPAN class=3D234475003-20092001>"&nbsp;&nbsp;&nbsp; <FONT =
face=3DArial=20
size=3D2>Prior to accepting a signed response as being valid, OCSP =
clients SHALL=20
confirm that:</FONT></SPAN></DIV>
<DIV><SPAN =
class=3D234475003-20092001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<FONT face=3DArial size=3D2>.......</FONT></SPAN></DIV>
<DIV><SPAN class=3D234475003-20092001><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3. The identity of =
the signer=20
matches the intended recipient of the request.</FONT></SPAN></DIV>
<DIV><SPAN =
class=3D234475003-20092001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<FONT face=3DArial size=3D2>.....</FONT></SPAN></DIV>
<DIV><SPAN class=3D234475003-20092001>&nbsp;"</SPAN></DIV>
<DIV><SPAN class=3D234475003-20092001><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D234475003-20092001>I would interpret&nbsp;#3 to =
basically mean=20
that if you send a request to a particular OCSP Server that it must be =
the ocsp=20
server that signs the response.</SPAN></DIV>
<DIV><SPAN class=3D234475003-20092001></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D234475003-20092001><FONT face=3DArial size=3D2>Image =
the scenario=20
when an ocsp server forwards the request to the location stated in the=20
ServiceLocator field. </FONT></SPAN></DIV>
<DIV><SPAN class=3D234475003-20092001><FONT face=3DArial size=3D2>Upon =
the external=20
OCSP server processing the request it should return a signed response =
regarding=20
the certificate in question.</FONT></SPAN></DIV>
<DIV><SPAN class=3D234475003-20092001><FONT face=3DArial size=3D2>What =
should the=20
original ocsp server do now?</FONT></SPAN></DIV>
<DIV><SPAN class=3D234475003-20092001>&nbsp;&nbsp;&nbsp; <FONT =
face=3DArial size=3D2>-=20
If it simply gives the client back the signed message, wouldn't the =
client have=20
to reject it as stated above in #3?</FONT></SPAN></DIV>
<DIV><SPAN class=3D234475003-20092001>&nbsp;&nbsp;&nbsp; <FONT =
face=3DArial size=3D2>-=20
Or, should the server perform all of the steps in 3.2 to ensure that the =
signed=20
response is valid, and then just resign it themselves and give the newly =
signed=20
copy to the Client?</FONT></SPAN></DIV>
<DIV><SPAN class=3D234475003-20092001><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D234475003-20092001><FONT face=3DArial size=3D2>I =
would assume that=20
the second statement, where the server authenticates and resigns, is the =
method=20
to use, however this was not clear to me from the =
RFC.</FONT></SPAN></DIV>
<DIV><SPAN class=3D234475003-20092001><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D234475003-20092001><FONT face=3DArial=20
size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2><STRONG>Andrew =
Sciberras</STRONG></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Adacel Technologies Ltd</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_024C_01C141E0.015FA650--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8IFvIS15159 for ietf-pkix-bks; Tue, 18 Sep 2001 08:57:18 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8IFvFD15144; Tue, 18 Sep 2001 08:57:17 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <R052YHX0>; Tue, 18 Sep 2001 11:57:20 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "Pawling, John" <[e-mail]>
Subject: v1.9.3 Certificate Management Library (CML) Now Available
Date: Tue, 18 Sep 2001 11:57:11 -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>

Getronics Government Solutions has delivered the Version 1.9.3 
Certificate Management Library (CML) for Microsoft Windows, 
Sun Solaris and Linux.  The v1.9.3 CML is freely available
to everyone from the Getronics CML web page at:
<http://www.getronicsgov.com/hot/cml_home.htm>.
This release fixes bugs present in previous CML releases.  

Applications requiring Public Key Infrastructure (PKI) security 
services can use the CML to meet their X.509 certificate and 
Certificate Revocation List (CRL) processing requirements.  
The v1.9.3 CML is described in the v1.9 CML Application Programming
Interface (API) document.  It implements the 2000 X.509 Recommendation
certification path processing rules and SDN.706 profile.  It meets
the majority of the IETF PKIX RFC 2459 Certificate/CRL Profile
requirements.  There are some unsupported features such as 
Delta CRLs.  It Abstract Syntax Notation One (ASN.1) decodes X.509
Certificates and CRLs.  The v1.9.3 CML requires the v1.3 R6 Enhanced
SNACC ASN.1 software that is freely available from:
<http://www.getronicsgov.com/hot/snacc_home.htm>.

The CML uses the accompanying Storage and Retrieval Library (SRL)
(optionally) to provide local certificate and CRL storage management 
functions.  The SRL (optionally) provides remote directory retrieval
capabilities using the Lightweight Directory Access Protocol (LDAP).
The CML uses path building software based on the v2.0 Certificate 
Path Development Library (CPDL) developed by CygnaCom Solutions, 
a division of Entrust, to provide robust certification path 
building capabilities such as using cross certificates. 

The CML has been thoroughly tested including validating X.509 
Certificates and CRLs created by a variety of Certification 
Authority (CA) products, and signed using the Digital Signature
Algorithm (DSA) and RSA algorithms.  Further enhancements, 
ports and testing of the CML are still in process.  Further
releases of the CML will be provided as significant 
capabilities are added. 

The following enhancements are included in the v1.9.3 CML release 
(compared with the v1.9.2 release):

 1. Fixed linked list bugs in loadDSAparameters() function in 
    CM_Cache.cpp source file that caused CML_CreateSession to
    fail to return when adding multiple trusted certificates to
    the SRL.
 
 2. Fixed bug in CMU_DSAEncodePQGparms() function in CM_encode.cpp 
    source file in which it was using the AsnInt class for the 
    DSA P, Q and G parameters instead of using the CSM_BigIntegerStr
    class.  This caused the DSA parameters to be improperly encoded
    which (in some cases) caused the Crypto Token Interface Library 
    (CTIL) to return an error (ex: MSB is 1) indicating that the 
    DSA parameters were not encoded as valid unsigned ASN.1 INTEGER
    values. 

The following v1.9.3 CML files are available from the Getronics CML
web page:
1) Windows_CML_Lib_v1.9.3.ZIP: MS Windows Dynamically Linked Libraries 
2) Windows_CM_Tool_v1.9.3.ZIP: CM_Tool executable
3) Solaris_CML_Lib_v1.9.3.tar.Z: Sun Solaris Libraries 
4) Solaris_CM_Tool_v1.9.3.tar.z: CM_Tool for Solaris
5) Linux_CML_Lib_v1.9.3.tar.Z: Linux Libraries
6) Linux_CM_Tool_v1.9.3.tar.z: CM_Tool for Linux
7) CML_source_v1.9.3.tar.Z: Source, including Windows project files 
8) CMAPI_data.tar.Z: Test Certs and CRLs used to test CML

The v1.9 CML API document (CMv1.9api.doc, CMv1.9api.pdf), v1.9 SRL API 
document (SRLv1.9api.doc, SRLv1.9api.pdf), and v1.9.3 CML readme file
are also available from the Getronics CML web page.

All source code for the CML is being provided at no cost and with no
financial limitations regarding its use and distribution. Organizations 
can use the CML without paying any royalties or licensing fees.  The
CML was originally developed by the U.S. Government.  Getronics is 
enhancing and supporting the CML under contract to the U.S. Government.
The U.S. Government is furnishing the CML software at no cost to the
vendor subject to the conditions of the CML Public License provided
with the CML software.  

The CML makes calls to an algorithm-independent Crypto Token Interface 
Library (CTIL) API.  The CTIL architecture enables the CML to be used
with a variety of crypto libraries and tokens. The v1.9.3 CML uses the
v1.3 R6 Enhanced SNACC ASN.1 C Library to encode and decode objects.
Getronics has successfully tested the v1.9.3 CML with the SNACC and 
CTIL libraries delivered with the v1.10 S/MIME Freeware Library (SFL).  
Source code for the Getronics-developed CTILs is available from 
<http://www.getronicsgov.com/hot/sfl_home.htm>.  The actual crypto 
libraries are not provided with the CML or SFL.  They must be 
independently obtained from the appropriate source.  

The v1.9.3 CML uses path building software based on the v2.0 CPDL
to successfully meet all of the requirements of the Bridge
Certification Authority Demonstration Phase II that includes cross-
certified Entrust, Spyrus, Baltimore, and Motorola v3 certificate 
domains.  The CML_source.tar.Z file includes the Getronics-enhanced
CPDL source code and public license.  More info regarding the CPDL
is available from: <http://www.cygnacom.com/products/index.htm>.

The National Institute of Standards and Technology (NIST) is 
providing a standard test suite of X.509 certificate paths
<http://csrc.nist.gov/pki/testing/x509paths.html> that can be
used for testing applications against RFC 2459.  The CML was 
used to successfully process the NIST test data.

NIST is using the CML and SFL as part of the NIST S/MIME Test 
Facility (NSMTF) that they are planning to host (see 
<http://csrc.ncsl.nist.gov/pki/smime/>).  Organizations will
be able to use the NSMTF to help determine if their products 
comply with the IETF S/MIME v3 specifications and the Federal
S/MIME v3 Clent Profile.

The Internet Mail Consortium (IMC) has established a CML web page
<http://www.imc.org/imc-cml> and a CML mail list which is used to: 
distribute information regarding CML releases; discuss CML-related 
issues; and allow CML users to provide feedback, comments, bug 
reports, etc.  Subscription information for the imc-cml mailing list 
is at the IMC web site listed above.  

All comments regarding the CML source code and documents are welcome. 
This CML release announcement was sent to several mail lists, but
please send all messages regarding the CML to the imc-cml mail list
ONLY. Please do not send messages regarding the CML to any of the IETF
mail lists.  We will respond to all messages sent to the imc-cml mail 
list.

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8I7L9n00495 for ietf-pkix-bks; Tue, 18 Sep 2001 00:21:09 -0700 (PDT)
Received: from mail.ca (ip6.certicom.com [209.121.99.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8I7L7D00486 for <[e-mail]>; Tue, 18 Sep 2001 00:21:08 -0700 (PDT)
Received: from smtpmail.certicom.com (smtpmail [10.0.1.25]) by mail.ca (8.9.3/8.9.3) with SMTP id DAA27343; Tue, 18 Sep 2001 03:13:45 -0400 (EDT)
Received: by smtpmail.certicom.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 85256ACB.002850DB ; Tue, 18 Sep 2001 03:20:21 -0400
X-Lotus-FromDomain: CERTICOM
From: "Amit Kapoor" <[e-mail]>
To: Magnus Nystr=?iso-8859-1?Q?=F6m?= <[e-mail]>
cc: [e-mail], "Richards, Gareth" <[e-mail]>
Message-ID: <[e-mail]>
Date: Mon, 17 Sep 2001 23:57:08 -0700
Subject: Re: Polling in CMP
Mime-Version: 1.0
Content-type: multipart/mixed;  Boundary="0__=kFoRPgb4asWjUFXG3ePhC51ARqqs34Gf90OdA3Iq7FMcbueL69EYE8lf"
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>

--0__=kFoRPgb4asWjUFXG3ePhC51ARqqs34Gf90OdA3Iq7FMcbueL69EYE8lf
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi Magnus, Gareth,

     A quick glance seems the proposal is inline with the original discussion.
However,
     I would like to expand the scope of polling a little bit.  One of the other
problems
     we have been dealing with is that issuance of certificates sometimes
require
     a back and forth question & answer session between the end entity and the
server
     for identity authentication.  The current interoperable subset of the CMP
protocol assumes
     (a) all the information needed by the server is in the original request or
(b) the server
     does out of band verification if information needed is not sufficient.

     I believe this requirement is generic enough to require interoperable
support
     and should go into the CMP protocol.  Based on the use of the proposed CMP
     poll request & response, it looks like a good choice.  Would like to hear
your
     thoughts......

     regards

Amit





Magnus Nystrom <[e-mail]> on 09/06/2001 07:19:28 AM

Please respond to Magnus Nystr
--0__=kFoRPgb4asWjUFXG3ePhC51ARqqs34Gf90OdA3Iq7FMcbueL69EYE8lf
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-transfer-encoding: quoted-printable


=F6m <[e-mail]>

To:   [e-mail]
cc:   "Richards, Gareth" <[e-mail]> (bcc: Amit Kapoor/=
Certicom)

Subject:  Polling in CMP


=

--0__=kFoRPgb4asWjUFXG3ePhC51ARqqs34Gf90OdA3Iq7FMcbueL69EYE8lf
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



All,

Going back to a topic discussed earlier this year, and after
discussions with various individuals at the recent IETF in London, we
would like to propose the attached simple extension to CMP to handle
polling. The reason for this proposal is as stated previously - we
feel that a protocol which specifies a "wait - come back later"
server status also should specify how a client should poll the server,
rather than deferring this to transport protocols.

Assume that the CMP enrollment is taking place in a browser script and
the browser may be terminated before the polling is complete. Then a
way of saving state and continuing the polling at a later date is
needed.  If the polling is done in CMP then this is possible by
reissuing the request or whatever but if it is done by the transport
layer then it does not seem clear how this is going to be done.

Thanks to Amit Kapoor for the original proposal regarding these
messages.

BR,
-- Magnus
Magnus Nystrom
RSA Security
--------------------------------------------------------------------------

pollReq    [25] PollReqContent
pollRep    [26] PollRepContent


PollRepContent ::= SEQUENCE OF SEQUENCE {
  certReqId    INTEGER,
  checkAfter   INTEGER,  -- time in seconds
  reason   [0] PKIFreeText OPTIONAL
}

PollReqContent ::= SEQUENCE OF SEQUENCE {
  certReqId    INTEGER
}

1. It is assumed that multiple certConf messages can be sent during
the transaction.  There will be one sent in response to each ip, cp or kup
containing a CertStatus for each approved certificate.   If a
single certConf must be sent for the transaction then it is possible that the
confirmWaitTime (rfc2510bis section 3.1.1.2) of the first certificate will have
expired before the second cert pickup has take place.

2. In response to an ip, cp or kup message, an EE will send a certConf for all
approved certificates and following the ack, a pollReq for all pending
certificates.

2. In respose to a pollReq, a CA/RA will return a ip, cp or kup if one or more
of the pending certificates is ready otherwise it will return a pollRep.

3. If the EE receives a pollRep in return, it will wait for at least the lowest
checkAfter value before sending another pollReq.

4. If an ip, cp or kup is received in reply to a pollReq then it will be treated
in
the same way as the initial response.

                                 Start
                                   |
                                   |
                                   \/
                                Send ir
                                   |
                                   | ip
                                   |
                                  \/
                              Check status
                               of of returned
<----------------------------------|
                                certs.
|
                                   |
|
    |----------------------------->|<-----------------------|
|
    |                              |                        |
|
    |                             \/                        |
|
                    approved                      waiting
|
 Add to conf list <---------- Check CertResponse --------> Add to pending list
|
                                   /\
|
                        conf list /  \Empty conf list
|
                                 /    \                     ip
|
                                /      \
--------------------------------|
     Empty pending            /        \         |
           list               /          \       |         pRep
     End <--------- Send certConf         Send pReq-------------- Wait
                           |                 /\  /\                 |
                           |                 |    |                 |
                           -------------------    -------------------
                               Pending list              Wait


In the following exchange, the end entity is enroling for two certificates in
one request.

Step  End Entity                            PKI
-------------------------------------------------------------------
1     Format ir
2                      -> ir      ->
3                                      Handle ir
4                                      Manual intervention is
                                       required for both certs.
5                      <- ip      <-
6     Process ip
7     Format pReq
8                      -> pReq     ->
9                                      Check status of certificate requests
10                                     Certificates not ready
11                                     Format pRep
12                     <- pRep     <-
13    Wait
14    Format pReq
15                     -> pReq     ->
16                                     Check status of certificate requests
17                                     One certificate is ready
18                                     Format ip
19                     <- ip       <-
20    Handle ip
21    Format certConf
22                     -> certConf ->
23                                     Handle certConf
24                                     Format ack
25                     <- pkiConf   <-
26    Format pReq
27                     -> pReq     ->
28                                     Check status of certificate
29                                     Certificate is ready
30                                     Format ip
31                     <- ip       <-
31    Handle ip
32    Format certConf
33                     -> certConf ->
34                                     Handle certConf
35                                     Format ack
36                     <- pkiConf  <-







--0__=kFoRPgb4asWjUFXG3ePhC51ARqqs34Gf90OdA3Iq7FMcbueL69EYE8lf--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8HETll17943 for ietf-pkix-bks; Mon, 17 Sep 2001 07:29:47 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8HETkD17938 for <[e-mail]>; Mon, 17 Sep 2001 07:29:46 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Mon, 17 Sep 2001 07:30:25 -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, 17 Sep 2001 07:30:24 -0700 (PDT)
Received: from beethoven (192.168.51.206 [192.168.51.206]) by polaris.valicert.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id SMT35NDB; Mon, 17 Sep 2001 07:22:42 -0700
Date: Mon, 17 Sep 2001 10:29:28 -0400
From: John Thielens <[e-mail]>
Subject: Re: Clarification request on RFC 2560
To: Margus Freudenthal <[e-mail]>, "Pkix (E-mail)" <[e-mail]>
Message-id: <003401c13f85$2b7f2e40$9d64a8c0@beethoven>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
Content-type: text/plain;	charset="iso-8859-1"
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <00c001c13d47$fff9ae10$64fea8c0@beethoven> <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f8HETkD17939
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>

Margus:

> If the client can not count on something, this feature is not very
> useful. In this case, the client must still implement functionality for
> retrieving certificates needed for verification of the OCSP response
> (this is a MUST, because I can't rely on the OCSP response itself).
> Retrieving certificates from the OCSP response itself means that the
> client developer must do additional work in hope that some OCSP
> responder will put something useful in the response.
> 
> I would suggest explicitly stating the assumptions that the client can
> make about the content of the certs field, and if these assumptions
> consist of an empty set, removing this field as it only complicates
> things without providing any measurable value.

Part of this depends on the trust model between the client and the server.  If there were no certs in the request, this would require the server to have foreknowledge of the requester's certificate, indexed by its name (requestorName).  By allowing the requester to supply certs, presumably a cert chain up to but not including some trust root expected at the server, this makes the protocol more flexible.

Ditto for the certs in the response from the server.  This is very common practice and appears in protocols like SSL/TLS, CMS (S/MIME), and so on.

The reason I say the entity using the certs MUST NOT count on any particular meaning to the order or presence of the certs is because normal path discovery and path validation rules apply here per 2459 (sec. 6.1 -- although this is somewhat thin on discovery).  Before path validation, the client counts on nothing.  But after path validation, the client knows exactly what to trust.

John



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8H988A29791 for ietf-pkix-bks; Mon, 17 Sep 2001 02:08:08 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8H986D29787 for <[e-mail]>; Mon, 17 Sep 2001 02:08: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 LAA33410; Mon, 17 Sep 2001 11:10:16 +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 LAA05362; Mon, 17 Sep 2001 11:07:32 +0200
Message-ID: <[e-mail]>
Date: Mon, 17 Sep 2001 11:07:39 +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: Margus Freudenthal <[e-mail]>
CC: "Pkix (E-mail)" <[e-mail]>
Subject: Re: Clarification request on RFC 2560
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <00c001c13d47$fff9ae10$64fea8c0@beethoven> <[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>

Margus,

> John Thielens wrote:

> > >  4) a sequence (chain) of (possibly) "useful" X.509 certificates ?

> > I believe #4 is the correct answer (I have seen enough variation 
> > in the ordering to preclude #1 and #2 -- perhaps this is why CMS 
> > uses SET OF instead of SEQUENCE OF, although it also commits the 
> > sin of OPTIONAL without SIZE (1..MAX)).  #4 puts the onus squarely 
> > on the relying party's shoulders to assess the applicability of 
> > the certificates to substantiate the signature.  Of course, the
> > server SHOULD only put in useful certs, but the client MUST NOT 
> > count on it.

> If the client can not count on something, this feature is not very
> useful. 

In the ASN1 syntax that field is OPTIONAL. So the client cannot assume 
that he will always be present, ... unless we write a profile of that 
document where we make that field mandatory.

Denis

> In this case, the client must still implement functionality for
> retrieving certificates needed for verification of the OCSP response
> (this is a MUST, because I can't rely on the OCSP response itself).
> Retrieving certificates from the OCSP response itself means that the
> client developer must do additional work in hope that some OCSP
> responder will put something useful in the response.
> 
> I would suggest explicitly stating the assumptions that the client can
> make about the content of the certs field, and if these assumptions
> consist of an empty set, removing this field as it only complicates
> things without providing any measurable value.
> 
> --
> Margus


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8H8EdH24180 for ietf-pkix-bks; Mon, 17 Sep 2001 01:14:39 -0700 (PDT)
Received: from atsgw.cyber.ee (atsgw.cyber.ee [195.50.202.13]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8H8EZD24175 for <[e-mail]>; Mon, 17 Sep 2001 01:14:35 -0700 (PDT)
Received: Message by Barricade atsgw.cyber.ee  with ESMTP id f8H8EMd26270 for <[e-mail]>; Mon, 17 Sep 2001 10:14:22 +0200
Message-ID: <[e-mail]>
Date: Mon, 17 Sep 2001 10:16:45 +0200
From: Margus Freudenthal <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: ee,et,en
MIME-Version: 1.0
To: "Pkix (E-mail)" <[e-mail]>
Subject: Re: Clarification request on RFC 2560
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <00c001c13d47$fff9ae10$64fea8c0@beethoven>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-info: Headers changed by Barricade
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 Thielens wrote:
> 
> >  4) a sequence (chain) of (possibly) "useful" X.509 certificates ?
> 
> I believe #4 is the correct answer (I have seen enough variation in the ordering to preclude #1 and #2 -- perhaps this is why CMS uses SET OF instead of SEQUENCE OF, although it also commits the sin of OPTIONAL without SIZE (1..MAX)).  #4 puts the onus squarely on the relying party's shoulders to assess the applicability of the certificates to substantiate the signature.  Of course, the server SHOULD only put in useful certs, but the client MUST NOT count on it.
> 
If the client can not count on something, this feature is not very
useful. In this case, the client must still implement functionality for
retrieving certificates needed for verification of the OCSP response
(this is a MUST, because I can't rely on the OCSP response itself).
Retrieving certificates from the OCSP response itself means that the
client developer must do additional work in hope that some OCSP
responder will put something useful in the response.

I would suggest explicitly stating the assumptions that the client can
make about the content of the certs field, and if these assumptions
consist of an empty set, removing this field as it only complicates
things without providing any measurable value.


-- 
Margus


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8F0YRI20194 for ietf-pkix-bks; Fri, 14 Sep 2001 17:34:27 -0700 (PDT)
Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8F0YPD20190 for <[e-mail]>; Fri, 14 Sep 2001 17:34:25 -0700 (PDT)
Received: from tsg1 ([12.81.87.211]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <20010915003423.FAAL28026.mtiwmhc25.worldnet.att.net@tsg1>; Sat, 15 Sep 2001 00:34:23 +0000
Message-ID: <051c01c13d7e$20700370$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Untrusting a Trusted Third Party: TSA.
Date: Fri, 14 Sep 2001 17:32:16 -0700
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.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
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>

Alfonso - The instant of trust for the issuance of the time stamping token
happens when
the token is verified. At this instant the TSA can easily return a
commentary to the questioning client that its clocks drifted xy and z amount
and as such the relying party can take the testimony of the TSA as being
that the actual time the incident happened was XY and Z + drift_value.

There is nothing anywhere that says that the TST itself is the testimony of
the TSA, just the token to prove that some TS was actually issued - i.e its
a receipt and not a very good one. This is an important concept and is
crucial to many many use models.

Todd

----- Original Message -----
From: "Alfonso De Gregorio" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, September 13, 2001 5:30 AM
Subject: Untrusting a Trusted Third Party: TSA.


>
> Hi Everyone,
>
> The following consideration is quite obvious; however, it's intriguing
> to see how the TSP allows a user to perform a simple test against a
> TSA that he doesn't trust anymore.
>
> Assume a user is afraid that a TSA is issuing time-stamp tokens while
> not in synchronization with UTC; after all if a TSA use a trustworthy
> source of time and include a trustworthy time value for each time-stamp
> token is not necessarily ensuring that the clock doesn't drift outside
> the declared accuracy (this is addressed in ETSI - STF 178-T1 draft H).
>
> The test
> The ordering of time-stamp tokens issued by different TSAs is only
> possible when the _absolute value_ (*) of the difference between the
> genTime of the first time-stamp token and the genTime of the second
> time-stamp token is greater than the sum of the accuracies of the
> genTime for each time-stamp token.
>
> *) partially contrarywise to what is asserted in section 2.4.2 of rfc3161.
>
> TSA-1: the tsa not trusted anymore by alice
> TSA-2..TSA-3: tsa still trusted by alice
>
> 1. Alice send a TimeStampReq to TSA-1 (TSA1Req) where
>    TimeStampReq.messageImprint is simply an hash of a document kept
>    secret (Alice_doc);
> 2. Upon receiving the response (TSA1Response), Alice hash the received
>    time-stamp token ( hash(TSA1Response) ) and send as quickly as possible
>    a time-stamp request to TSA2 (TSA2Req), where
>    TimeStampReq.messageImprint is hash(TSA1Response);
> 3. if the absolute value of the difference of the first time-stamp token
>    and the genTime of the second time-stamp token ( abs(x) ) is greater
>    than the sum of the accuracies of the genTime for each time-stamp
>    token, Alice can order the two tokens; but for a positive value of
>    the difference we have a consistent chain of time-stamp
>    request/response, and for a negative a contradictory result.
>
>   x = TSA2Response.genTime - TSA1Response.genTime;
>   while abs( x ) > (TSA2Response.accuracy + TSA1Response.accuracy)
> if  x > 0 --> TSA2Resoponse follows TSA1Response
> if  x < 0 --> TSA2Response is _antecedents_ to TSA1Response
>
>    Alice can prove the opposite showing the chained sequence of time-stamp
>    requests:
> a. Alice_doc
> b. TSA1Response.TSTInfo.messageImprint = hash(Alice_doc)
> c. TSA2Response.TSTInfo.messageImprint(hash(TSA1Response))
>
>
> Sincerely,
> alfonso
>




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8F0YGY20186 for ietf-pkix-bks; Fri, 14 Sep 2001 17:34:16 -0700 (PDT)
Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8F0YED20182 for <[e-mail]>; Fri, 14 Sep 2001 17:34:14 -0700 (PDT)
Received: from tsg1 ([12.81.87.211]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <20010915003411.EZXN28026.mtiwmhc25.worldnet.att.net@tsg1>; Sat, 15 Sep 2001 00:34:11 +0000
Message-ID: <051701c13d7e$1956ff30$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Cristian Marinescu" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: Question about TSP (rfc 3161)
Date: Fri, 14 Sep 2001 17:31:35 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
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>

----- Original Message -----
From: "Cristian Marinescu" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, September 13, 2001 7:27 AM
Subject: RE: Question about TSP (rfc 3161)


>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> I agree, there is in practice (at least for the moment,
> when everyone is trying to put a TSA together, more or less
> draft compliant), no reason for having such flags.
>
> But, it is also not stupid.
> Let's imagine that some day the TSP will be really used
> by everyone.  :)


For what purpose??? This is the issue, as it has always been Cristian. What
kind of use model would you have this TSA used for?

Personally I can't think of anything that I would want to use this TSP for.
If I need digital testimony between two or more parties that is keenly
established by some Human's testimon, as is the testimony of this TSA, then
why not cut the overhead of running the TSA out of the picture and just
continue to do things the way they are now. Its much less expensive and has
the exact same legal stature in a court. This is now and has always been the
problem with this TSP.

The real use of a TSP is for the creation of an evidentiary token to
memorialize the receipt of some event that was witnessed by a TTP (The TSA).
The Token is the receipt for the trust process, not the process itself and
so... with that said - Why would I want to use this TSP? What does it do for
me as a technology? It allows me to verify signatures in time... OK but I
can do that inside a PKI enhanced application without the overhead of some
protocol that only creates a postage stamp when what I really want is a
grocery receipt.

This is why the mandating of the inclusion of a Use Model is so critical
since now there is this rush to push this particular protocol into legal
standing as part of the EU's operating policy. Trying to create a necessity
to use a protocol by law is ludicrous and speaks well of everyone involved
eh? - NOT

Again in closing - What use models/process did you have in mind?

Todd Glassey

> Hard to imagine, but let's try.
> This will rise the problem of DOS attack, and some
> people, (as I have done myself) will implement the TSA
> and limit the number of parallel requests (and let's understand
> by this the number of spawn processes, or threads) to a fix number. So
> they will
> just return an error back. This is actually not a nice thing
> to do. And I presume, people there, writing the draft,
> tried to be nice: well, if I get a request, but,
> I don't have time to give a response right away, because
> I am busy, let's store the request and tell the person to try
> again sometimes later.
> Perhaps there is also the possibility
> that your clock is at that moment not available, (I would
> like to believe that there will be TSA's out there that won't read
> the time from the local system, like I do at the moment...) or maybe
> some
> other resource... how could I know??  :)
> In any case you have to take cautions about the overflooding with
> requests (or even pending requests, that havn't been answered yet)
>
> Well, at least this is the reason I can imagine. Perhaps
> there are also some other (dark!) reasons, but I would like
> to hear/read about them from the TSP gurus. :))
>
> Kindly regards,
> Cristian
>
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: Mittwoch, 12. September 2001 10:19
> > To: [e-mail]
> > Subject: Question about TSP (rfc 3161)
> >
> >
> >
> > Hi,
> >
> >
> > I would like to know what are the reasons for introducing the
> > flags "pollReq",
> > "pollResp" and "negPollRep" in the socket based protocol
> > (section 3.3).
> >
> >
> > It would mean that a tsa server can divide the der code he
> > calculated for the
> > response. But why would it do that?
> >
> >
> > Thanks
> >
> >
> > Libel
> >
> >
> > --
> > Get your firstname@lastname email for FREE at
> http://Nameplanet.com/?su
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 6.0.2i
>
> iQA/AwUBO6C0P8V5iyNCxCiSEQL9aQCg/DF+dzS6QV+dLFvVV6HTNTF3xvgAoOaZ
> GSkggGhyqVBA6fFIRTnn+4bu
> =FFSm
> -----END PGP SIGNATURE-----
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8EMfRB18779 for ietf-pkix-bks; Fri, 14 Sep 2001 15:41:27 -0700 (PDT)
Received: from zolera.com (IDENT:root@[63.142.188.177]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8EMfPD18775 for <[e-mail]>; Fri, 14 Sep 2001 15:41:25 -0700 (PDT)
Received: from zolera.com (pool-141-154-54-191.bos.east.verizon.net [141.154.54.191]) by zolera.com (8.11.0/8.11.0) with ESMTP id f8EMfra23757; Fri, 14 Sep 2001 18:41:53 -0400
Message-ID: <[e-mail]>
Date: Fri, 14 Sep 2001 18:41:57 -0400
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: EKR <[e-mail]>
CC: "David P. Kemp" <[e-mail]>, "Pkix (E-mail)" <[e-mail]>
Subject: Re: Clarification request on RFC 2560
References: <[e-mail]> <[e-mail]> <[e-mail]> <[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>

Off-list discussion, Eric clarified my incorrect memory allocation.  TLS
does allow the *server* to send a list of known CA's, not the client.

But I still don't understand this part of David's note:

> > > those PKI programs,
> > > such as S/MIME, whose specifications are not so short sighted as to forbid it?
	/r$
-- 
Zolera Systems, Securing web services (XML, SOAP, Signatures,
Encryption)
http://www.zolera.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8EM2Aj18381 for ietf-pkix-bks; Fri, 14 Sep 2001 15:02:10 -0700 (PDT)
Received: from romeo.rtfm.com ([198.144.203.242]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8EM28D18377 for <[e-mail]>; Fri, 14 Sep 2001 15:02:08 -0700 (PDT)
Received: (from ekr@localhost) by romeo.rtfm.com (8.11.3/8.11.1) id f8EM9E240618; Fri, 14 Sep 2001 15:09:14 -0700 (PDT) (envelope-from ekr)
To: Rich Salz <[e-mail]>
Cc: "David P. Kemp" <[e-mail]>, "Pkix (E-mail)" <[e-mail]>
Subject: Re: Clarification request on RFC 2560
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-to: EKR <[e-mail]>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
From: Eric Rescorla <[e-mail]>
Date: 14 Sep 2001 15:09:14 -0700
In-Reply-To: Rich Salz's message of "Fri, 14 Sep 2001 15:17:53 -0400"
Message-ID: <[e-mail]>
Lines: 13
X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald"
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>

Rich Salz <[e-mail]> writes:

> > Is that 99.9999% of all PKI programs (i.e. SSL clients, which are forbidden
> > from handling cross-certification*), or 99.9999% of those PKI programs,
> > such as S/MIME, whose specifications are not so short sighted as to forbid it?
> 
> With a claim like 99.9999% you want me to be specific?
> 
> I'm having trouble parsing that last line of yours.  Doesn't TLS allow
> the client to send a "known CA" list?
No--though there is some discussion of adding an extension for that purpose.

-Ekr


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8EJIXo15408 for ietf-pkix-bks; Fri, 14 Sep 2001 12:18:33 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8EJIVD15402 for <[e-mail]>; Fri, 14 Sep 2001 12:18:31 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 14 Sep 2001 12:19:16 -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, 14 Sep 2001 12:19:15 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <SMT352D1>; Fri, 14 Sep 2001 12:11:49 -0700
Content-return: allowed
Date: Fri, 14 Sep 2001 12:11:40 -0700
From: Ryan Hurst <[e-mail]>
Subject: RE: Clarification request on RFC 2560
To: "'Dr S N Henson'" <[e-mail]>, "Pkix (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
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 --
	Excellent point!

Ryan

-----Original Message-----
From: Dr S N Henson [mailto:[e-mail]] 
Sent: Friday, September 14, 2001 11:21 AM
To: Pkix (E-mail)
Subject: Re: Clarification request on RFC 2560


Ryan Hurst wrote:
> 
> 
> Lets change the question, is there consensus that this is the correct
usage
> of the certs[] attribute?
> 

I would say that RFC2560 is unclear on this point. Some might take the
wording to suggest otherwise. For example twice in section 4.2.2.2 it
uses the term:

"the certificate used to validate the signature on the response".

The use of "the" might be taking to mean that there is only one such
certificate.

> I personally believe so; I do not see how one could deal with multiple ca
> responses without this methodology. Additionally I do not see any
downsides
> to this method.
> 

Certainly without this methodology it can't be handled via a delegated
responder certificate. That would just leave the messy alternative of
local configuration.

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: by above.proper.com (8.11.6/8.11.3) id f8EJHKk15334 for ietf-pkix-bks; Fri, 14 Sep 2001 12:17:20 -0700 (PDT)
Received: from zolera.com (IDENT:root@[63.142.188.177]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8EJHID15317 for <[e-mail]>; Fri, 14 Sep 2001 12:17:19 -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 f8EJHpa22148; Fri, 14 Sep 2001 15:17:51 -0400
Message-ID: <[e-mail]>
Date: Fri, 14 Sep 2001 15:17:53 -0400
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "David P. Kemp" <[e-mail]>
CC: "Pkix (E-mail)" <[e-mail]>
Subject: Re: Clarification request on RFC 2560
References: <[e-mail]> <[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>

> Is that 99.9999% of all PKI programs (i.e. SSL clients, which are forbidden
> from handling cross-certification*), or 99.9999% of those PKI programs,
> such as S/MIME, whose specifications are not so short sighted as to forbid it?

With a claim like 99.9999% you want me to be specific?

I'm having trouble parsing that last line of yours.  Doesn't TLS allow
the client to send a "known CA" list?
	/r$


Received: by above.proper.com (8.11.6/8.11.3) id f8EJHEL15306 for ietf-pkix-bks; Fri, 14 Sep 2001 12:17:14 -0700 (PDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8EJH1D15291 for <[e-mail]>; Fri, 14 Sep 2001 12:17:01 -0700 (PDT)
Received: from [128.33.238.247] (tc238-247.bbn.com [128.33.238.247]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id PAA28149; Fri, 14 Sep 2001 15:19:05 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <p05010402b7c800093f97@[128.33.238.214]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 14 Sep 2001 14:43:57 -0400
To: Cristian Marinescu <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Question about TSP (rfc 3161)
Cc: [e-mail], [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>

At 4:27 PM +0200 9/13/01, Cristian Marinescu wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi,
>
>I agree, there is in practice (at least for the moment,
>when everyone is trying to put a TSA together, more or less
>draft compliant), no reason for having such flags.
>
>But, it is also not stupid.
>Let's imagine that some day the TSP will be really used
>by everyone.  :)  Hard to imagine, but let's try.
>This will rise the problem of DOS attack, and some
>people, (as I have done myself) will implement the TSA
>and limit the number of parallel requests (and let's understand
>by this the number of spawn processes, or threads) to a fix number. So
>they will
>just return an error back. This is actually not a nice thing
>to do. And I presume, people there, writing the draft,
>tried to be nice: well, if I get a request, but,
>I don't have time to give a response right away, because
>I am busy, let's store the request and tell the person to try
>again sometimes later.
>Perhaps there is also the possibility
>that your clock is at that moment not available, (I would
>like to believe that there will be TSA's out there that won't read
>the time from the local system, like I do at the moment...) or maybe
>some
>other resource... how could I know??  :) 
>In any case you have to take cautions about the overflooding with
>requests (or even pending requests, that havn't been answered yet)
>
>Well, at least this is the reason I can imagine. Perhaps
>there are also some other (dark!) reasons, but I would like
>to hear/read about them from the TSP gurus. :))
>
>Kindly regards,
>Cristian

TSP may be carried over various lower layer protocols. A TSA that 
wants to reject DoS attacks could require its clients to use a lower 
layer security protocol that facilitates this, e.g., IPsec.

Steve


Received: by above.proper.com (8.11.6/8.11.3) id f8EJ4WS14536 for ietf-pkix-bks; Fri, 14 Sep 2001 12:04:32 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8EJ4VD14530 for <[e-mail]>; Fri, 14 Sep 2001 12:04:31 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 14 Sep 2001 12:05:15 -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, 14 Sep 2001 12:05:15 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <SMT352AY>; Fri, 14 Sep 2001 11:57:48 -0700
Content-return: allowed
Date: Fri, 14 Sep 2001 11:57:43 -0700
From: Ryan Hurst <[e-mail]>
Subject: RE: Clarification request on RFC 2560
To: "'Rich Salz'" <[e-mail]>, Ambarish Malpani <[e-mail]>
Cc: Dr S N Henson <[e-mail]>, "Pkix (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
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>

Rich --

	Did I say that :), I am now embarrassed that I asked the question!
Yes that would be a cross-certification case.

As far as our "OCSP responder" product :) is concerned it depends on its
configuration...


Ryan
 

-----Original Message-----
From: Rich Salz [mailto:[e-mail]] 
Sent: Friday, September 14, 2001 10:46 AM
To: Ambarish Malpani
Cc: Dr S N Henson; Pkix (E-mail)
Subject: Re: Clarification request on RFC 2560


It sure sounded like Ryan's note ssaid a single key with multiple CA's
verifying it, and the client finds the right verifier.  Or does your VA
product use a separate keypair for each CA it handles?

>issue of a single VA/OCSP Responder ...

You sure you want to risk losing your TM on "Validation Authority" by
consistently using it generically? :)
	/r$
-- 
Zolera Systems, Your Key to Online Integrity
Securing Web services: XML, SOAP, Dig-sig, Encryption
http://www.zolera.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8EJ3kp14490 for ietf-pkix-bks; Fri, 14 Sep 2001 12:03:46 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8EJ3jD14485 for <[e-mail]>; Fri, 14 Sep 2001 12:03:45 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 14 Sep 2001 12:04:26 -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, 14 Sep 2001 12:04:25 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <SMT352AQ>; Fri, 14 Sep 2001 11:56:58 -0700
Content-return: allowed
Date: Fri, 14 Sep 2001 11:56:50 -0700
From: Ryan Hurst <[e-mail]>
Subject: RE: Clarification request on RFC 2560
To: Ambarish Malpani <[e-mail]>, "'Denis Pinkas'" <[e-mail]>, "David P. Kemp" <[e-mail]>
Cc: "Pkix (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
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>

Excerpt from the RFC to support Ambarish's note:


2.6  OCSP Signature Authority Delegation

   .... This certificate MUST be issued directly to the
   responder by the cognizant CA.


Ryan


-----Original Message-----
From: Ambarish Malpani [mailto:[e-mail]] 
Sent: Friday, September 14, 2001 10:58 AM
To: 'Denis Pinkas'; David P. Kemp
Cc: Pkix (E-mail)
Subject: RE: Clarification request on RFC 2560



Hi Denis,
    My interpretation is (4).

It is a bag of certificates that the recipient could find useful
to validate the request/response.

There may be some extraneous/irrelevant certificates, there might
not be all the certificates the client needs.

NOTE: IN THE CA DELEGATED TRUST MODEL FOR OCSP, THE RESPONDER MUST
BE DIRECTLY CERTIFIED BY THE CA - THERE MAY NOT BE CHAINING OF
ARBITRARY DEPTH I.E. IF CA1 CERTIFIES CA2, IT CAN'T CERTIFY
AN OCSP RESPONDER AND HAVE THAT TRUSTED AS A CA DELEGATED OCSP
RESPONDER FOR CA2.


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: Denis Pinkas [mailto:[e-mail]]
> Sent: Friday, September 14, 2001 9:52 AM
> To: David P. Kemp
> Cc: Pkix (E-mail)
> Subject: Re: Clarification request on RFC 2560
> 
> 
> 
> 
> > Is that 99.9999% of all PKI programs (i.e. SSL clients, 
> which are forbidden
> > from handling cross-certification*), or 99.9999% of those 
> PKI programs,
> > such as S/MIME, whose specifications are not so short 
> sighted as to forbid it?
> > 
> > Dave
> > 
> > * SSL 3.0: "certificate_list - This is a sequence (chain) 
> of X.509 certificates,
> >             ordered with the sender's certificate first and 
> the [sender's] root
> >             certificate authority last."
> 
> So my question again: Is certs in the OCSP response:
> 
>  1) a sequence (chain) of X.509 certificates, ordered with 
> the sender's
>     certificate first followed by useful certificates ?
> 
>  2) a sequence (chain) of X.509 certificates, ordered with 
> the sender's
>    certificate and only one chain of certificates with the [sender's] 
>    root certificate authority last ?
> 
>  3) a sequence (chain) of (always) "useful" X.509 certificates ?
> 
>  4) a sequence (chain) of (possibly) "useful" X.509 certificates ?
> 
> In Section 4.1.2 which is specific to the request, the text says: "the
> requestor MAY include certificates that help the OCSP 
> responder verify the
> requestor's signature in the certs field of Signature". The 
> question is
> whether "the requestor MAY include certificates that help the OCSP
> responder" or whether "the requestor MAY include certificates 
> that *MAY*
> help the OCSP responder". In the fisrt case, they really 
> help, so at least
> some certificates from a valid chain shall be included. In 
> the second case,
> they MAY help, so they may also not help, so any kind of 
> certificate may be
> included.   
>  
> Note that the last interpretation allows for all the others.
> 
> Where do we go from this ?
> 
> Denis
> 
> > > > An OCSP client might assume that only a single 
> certificate corresponds
> > > > to the responder ID and for example just look for the 
> first certificate
> > > > in the certs attribute which matches the reponder ID 
> and verify that.
> > >
> > > I think most -- like 99.9999% -- PKI programs are not 
> equipped to handle
> > > cross-certified entities.
> > >         /r$
> > >
> > > --
> > > Zolera Systems, Your Key to Online Integrity
> > > Securing Web services: XML, SOAP, Dig-sig, Encryption
> > > http://www.zolera.com
> 


Received: by above.proper.com (8.11.6/8.11.3) id f8EINQ413270 for ietf-pkix-bks; Fri, 14 Sep 2001 11:23:26 -0700 (PDT)
Received: from anchor-post-30.mail.demon.net (anchor-post-30.mail.demon.net [194.217.242.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8EINOD13266 for <[e-mail]>; Fri, 14 Sep 2001 11:23:24 -0700 (PDT)
Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=celocom.com) by anchor-post-30.mail.demon.net with esmtp (Exim 2.12 #1) id 15hxcY-000DP6-0U for [e-mail]; Fri, 14 Sep 2001 19:23:24 +0100
Message-ID: <[e-mail]>
Date: Fri, 14 Sep 2001 19:20:44 +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: "Pkix (E-mail)" <[e-mail]>
Subject: Re: Clarification request on RFC 2560
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>

Ryan Hurst wrote:
> 
> 
> Lets change the question, is there consensus that this is the correct usage
> of the certs[] attribute?
> 

I would say that RFC2560 is unclear on this point. Some might take the
wording to suggest otherwise. For example twice in section 4.2.2.2 it
uses the term:

"the certificate used to validate the signature on the response".

The use of "the" might be taking to mean that there is only one such
certificate.

> I personally believe so; I do not see how one could deal with multiple ca
> responses without this methodology. Additionally I do not see any downsides
> to this method.
> 

Certainly without this methodology it can't be handled via a delegated
responder certificate. That would just leave the messy alternative of
local configuration.

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 localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8EIDUq13106 for ietf-pkix-bks; Fri, 14 Sep 2001 11:13:30 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8EIDSD13102 for <[e-mail]>; Fri, 14 Sep 2001 11:13:28 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 14 Sep 2001 11:14:12 -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, 14 Sep 2001 11:14:12 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <SMT35HWT>; Fri, 14 Sep 2001 11:06:45 -0700
Content-return: allowed
Date: Fri, 14 Sep 2001 11:06:37 -0700
From: Ryan Hurst <[e-mail]>
Subject: RE: Clarification request on RFC 2560
To: "'Denis Pinkas'" <[e-mail]>, "David P. Kemp" <[e-mail]>
Cc: "Pkix (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
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 --

I would say #5 :)

5) a sequence of (always) "useful" X.509 certificates
	
This allows for most cases to work; I do not see the benefit in restricting
the use of this attribute to a chain either. The only problem I see with
leaving its use generic is that there will be different uses of the
attribute, for that reason I would like to see a recommendation on its use;
possibly:

   BasicOCSPResponse       ::= SEQUENCE {
      tbsResponseData      ResponseData,
      signatureAlgorithm   AlgorithmIdentifier,
      signature            BIT STRING,
      certs                [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

   The certs is field is a sequence X.509 certificates that may be useful
   to a client when verifying a response. When included it SHOULD contain
   all responder certificates that are associated with the signature on
   the response.

Ryan

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Friday, September 14, 2001 9:52 AM
To: David P. Kemp
Cc: Pkix (E-mail)
Subject: Re: Clarification request on RFC 2560



> Is that 99.9999% of all PKI programs (i.e. SSL clients, which are
forbidden
> from handling cross-certification*), or 99.9999% of those PKI programs,
> such as S/MIME, whose specifications are not so short sighted as to forbid
it?
> 
> Dave
> 
> * SSL 3.0: "certificate_list - This is a sequence (chain) of X.509
certificates,
>             ordered with the sender's certificate first and the [sender's]
root
>             certificate authority last."

So my question again: Is certs in the OCSP response:

 1) a sequence (chain) of X.509 certificates, ordered with the sender's
    certificate first followed by useful certificates ?

 2) a sequence (chain) of X.509 certificates, ordered with the sender's
   certificate and only one chain of certificates with the [sender's] 
   root certificate authority last ?

 3) a sequence (chain) of (always) "useful" X.509 certificates ?

 4) a sequence (chain) of (possibly) "useful" X.509 certificates ?

In Section 4.1.2 which is specific to the request, the text says: "the
requestor MAY include certificates that help the OCSP responder verify the
requestor's signature in the certs field of Signature". The question is
whether "the requestor MAY include certificates that help the OCSP
responder" or whether "the requestor MAY include certificates that *MAY*
help the OCSP responder". In the fisrt case, they really help, so at least
some certificates from a valid chain shall be included. In the second case,
they MAY help, so they may also not help, so any kind of certificate may be
included.   
 
Note that the last interpretation allows for all the others.

Where do we go from this ?

Denis

> > > An OCSP client might assume that only a single certificate corresponds
> > > to the responder ID and for example just look for the first
certificate
> > > in the certs attribute which matches the reponder ID and verify that.
> >
> > I think most -- like 99.9999% -- PKI programs are not equipped to handle
> > cross-certified entities.
> >         /r$
> >
> > --
> > Zolera Systems, Your Key to Online Integrity
> > Securing Web services: XML, SOAP, Dig-sig, Encryption
> > http://www.zolera.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8EI6dD12979 for ietf-pkix-bks; Fri, 14 Sep 2001 11:06:39 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8EI6cD12975 for <[e-mail]>; Fri, 14 Sep 2001 11:06:38 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 14 Sep 2001 11:07:22 -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, 14 Sep 2001 11:07:21 -0700 (PDT)
Received: from beethoven (192.168.51.200 [192.168.51.200]) by polaris.valicert.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id SMT35HVR; Fri, 14 Sep 2001 10:59:54 -0700
Date: Fri, 14 Sep 2001 14:06:33 -0400
From: John Thielens <[e-mail]>
Subject: Re: Clarification request on RFC 2560
To: Denis Pinkas <[e-mail]>
Cc: "Pkix (E-mail)" <[e-mail]>
Message-id: <00c001c13d47$fff9ae10$64fea8c0@beethoven>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
Content-type: text/plain;	charset="iso-8859-1"
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f8EI6cD12976
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:

> So my question again: Is certs in the OCSP response:
> 
>  1) a sequence (chain) of X.509 certificates, ordered with the sender's
>     certificate first followed by useful certificates ?
> 
>  2) a sequence (chain) of X.509 certificates, ordered with the sender's
>    certificate and only one chain of certificates with the [sender's] 
>    root certificate authority last ?
> 
>  3) a sequence (chain) of (always) "useful" X.509 certificates ?
> 
>  4) a sequence (chain) of (possibly) "useful" X.509 certificates ?

I believe #4 is the correct answer (I have seen enough variation in the ordering to preclude #1 and #2 -- perhaps this is why CMS uses SET OF instead of SEQUENCE OF, although it also commits the sin of OPTIONAL without SIZE (1..MAX)).  #4 puts the onus squarely on the relying party's shoulders to assess the applicability of the certificates to substantiate the signature.  Of course, the server SHOULD only put in useful certs, but the client MUST NOT count on it.

John



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8EI4TO12946 for ietf-pkix-bks; Fri, 14 Sep 2001 11:04:29 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8EI4SD12942 for <[e-mail]>; Fri, 14 Sep 2001 11:04:28 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 14 Sep 2001 11:05:12 -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, 14 Sep 2001 11:05:12 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <SMT35HVB>; Fri, 14 Sep 2001 10:57:45 -0700
Content-return: allowed
Date: Fri, 14 Sep 2001 10:57:43 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: Clarification request on RFC 2560
To: "'Denis Pinkas'" <[e-mail]>, "David P. Kemp" <[e-mail]>
Cc: "Pkix (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>

Hi Denis,
    My interpretation is (4).

It is a bag of certificates that the recipient could find useful
to validate the request/response.

There may be some extraneous/irrelevant certificates, there might
not be all the certificates the client needs.

NOTE: IN THE CA DELEGATED TRUST MODEL FOR OCSP, THE RESPONDER MUST
BE DIRECTLY CERTIFIED BY THE CA - THERE MAY NOT BE CHAINING OF
ARBITRARY DEPTH I.E. IF CA1 CERTIFIES CA2, IT CAN'T CERTIFY
AN OCSP RESPONDER AND HAVE THAT TRUSTED AS A CA DELEGATED OCSP
RESPONDER FOR CA2.


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: Denis Pinkas [mailto:[e-mail]]
> Sent: Friday, September 14, 2001 9:52 AM
> To: David P. Kemp
> Cc: Pkix (E-mail)
> Subject: Re: Clarification request on RFC 2560
> 
> 
> 
> 
> > Is that 99.9999% of all PKI programs (i.e. SSL clients, 
> which are forbidden
> > from handling cross-certification*), or 99.9999% of those 
> PKI programs,
> > such as S/MIME, whose specifications are not so short 
> sighted as to forbid it?
> > 
> > Dave
> > 
> > * SSL 3.0: "certificate_list - This is a sequence (chain) 
> of X.509 certificates,
> >             ordered with the sender's certificate first and 
> the [sender's] root
> >             certificate authority last."
> 
> So my question again: Is certs in the OCSP response:
> 
>  1) a sequence (chain) of X.509 certificates, ordered with 
> the sender's
>     certificate first followed by useful certificates ?
> 
>  2) a sequence (chain) of X.509 certificates, ordered with 
> the sender's
>    certificate and only one chain of certificates with the [sender's] 
>    root certificate authority last ?
> 
>  3) a sequence (chain) of (always) "useful" X.509 certificates ?
> 
>  4) a sequence (chain) of (possibly) "useful" X.509 certificates ?
> 
> In Section 4.1.2 which is specific to the request, the text says: "the
> requestor MAY include certificates that help the OCSP 
> responder verify the
> requestor's signature in the certs field of Signature". The 
> question is
> whether "the requestor MAY include certificates that help the OCSP
> responder" or whether "the requestor MAY include certificates 
> that *MAY*
> help the OCSP responder". In the fisrt case, they really 
> help, so at least
> some certificates from a valid chain shall be included. In 
> the second case,
> they MAY help, so they may also not help, so any kind of 
> certificate may be
> included.   
>  
> Note that the last interpretation allows for all the others.
> 
> Where do we go from this ?
> 
> Denis
> 
> > > > An OCSP client might assume that only a single 
> certificate corresponds
> > > > to the responder ID and for example just look for the 
> first certificate
> > > > in the certs attribute which matches the reponder ID 
> and verify that.
> > >
> > > I think most -- like 99.9999% -- PKI programs are not 
> equipped to handle
> > > cross-certified entities.
> > >         /r$
> > >
> > > --
> > > Zolera Systems, Your Key to Online Integrity
> > > Securing Web services: XML, SOAP, Dig-sig, Encryption
> > > http://www.zolera.com
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8EHjSR12660 for ietf-pkix-bks; Fri, 14 Sep 2001 10:45:28 -0700 (PDT)
Received: from zolera.com (IDENT:root@[63.142.188.177]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8EHjQD12656 for <[e-mail]>; Fri, 14 Sep 2001 10:45:26 -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 f8EHjua21447; Fri, 14 Sep 2001 13:45:56 -0400
Message-ID: <[e-mail]>
Date: Fri, 14 Sep 2001 13:45:57 -0400
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Ambarish Malpani <[e-mail]>
CC: Dr S N Henson <[e-mail]>, "Pkix (E-mail)" <[e-mail]>
Subject: Re: Clarification request on RFC 2560
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>

It sure sounded like Ryan's note ssaid a single key with multiple CA's
verifying it, and the client finds the right verifier.  Or does your VA
product use a separate keypair for each CA it handles?

>issue of a single VA/OCSP Responder ...

You sure you want to risk losing your TM on "Validation Authority" by
consistently using it generically? :)
	/r$
-- 
Zolera Systems, Your Key to Online Integrity
Securing Web services: XML, SOAP, Dig-sig, Encryption
http://www.zolera.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8EGs7o11763 for ietf-pkix-bks; Fri, 14 Sep 2001 09:54:07 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8EGs5D11759 for <[e-mail]>; Fri, 14 Sep 2001 09:54:05 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 14 Sep 2001 09:54: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]>; Fri, 14 Sep 2001 09:54:49 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <SMT35H21>; Fri, 14 Sep 2001 09:47:23 -0700
Content-return: allowed
Date: Fri, 14 Sep 2001 09:47:22 -0700
From: Ryan Hurst <[e-mail]>
Subject: RE: Clarification request on RFC 2560
To: "'Dr S N Henson'" <[e-mail]>, "Pkix (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
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 --

	Well there goes one of my examples then :), I vaguely remember a
post to the OpenSSL dev list that implied that was what was implemented in
its implementation of OCSP.

Lets change the question, is there consensus that this is the correct usage
of the certs[] attribute? 

I personally believe so; I do not see how one could deal with multiple ca
responses without this methodology. Additionally I do not see any downsides
to this method.

Ryan

-----Original Message-----
From: Dr S N Henson [mailto:[e-mail]] 
Sent: Friday, September 14, 2001 4:01 AM
To: Pkix (E-mail)
Subject: Re: Clarification request on RFC 2560


Ryan Hurst wrote:
> 
> 
> 
> <rmh>You are correct we are looking to prove #3 in this case, the response
> would have contained the each of the responder certificates associated
with
> the signature in the certs[] attribute (eg all three delegated responder
> certificates). The client would then look at each of the CertIDs in the
> response and then make sure that it had it can verify #3 against the
certs[]
> structure (of coarse after confirming that they are trusted).</rmh>
> 

I wonder how many OCSP clients actually behave like that? OpenSSL,
currently at least, doesn't.

An OCSP client might assume that only a single certificate corresponds
to the responder ID and for example just look for the first certificate
in the certs attribute which matches the reponder ID and verify that.
This would reject the response in the above scenario.

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 localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8EGqgO11736 for ietf-pkix-bks; Fri, 14 Sep 2001 09:52:42 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8EGqeD11732 for <[e-mail]>; Fri, 14 Sep 2001 09:52: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 SAA46108; Fri, 14 Sep 2001 18:54:50 +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 SAA17374; Fri, 14 Sep 2001 18:52:06 +0200
Message-ID: <[e-mail]>
Date: Fri, 14 Sep 2001 18:51:54 +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: "Pkix (E-mail)" <[e-mail]>
Subject: Re: Clarification request on RFC 2560
References: <[e-mail]> <[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>

> Is that 99.9999% of all PKI programs (i.e. SSL clients, which are forbidden
> from handling cross-certification*), or 99.9999% of those PKI programs,
> such as S/MIME, whose specifications are not so short sighted as to forbid it?
> 
> Dave
> 
> * SSL 3.0: "certificate_list - This is a sequence (chain) of X.509 certificates,
>             ordered with the sender's certificate first and the [sender's] root
>             certificate authority last."

So my question again: Is certs in the OCSP response:

 1) a sequence (chain) of X.509 certificates, ordered with the sender's
    certificate first followed by useful certificates ?

 2) a sequence (chain) of X.509 certificates, ordered with the sender's
   certificate and only one chain of certificates with the [sender's] 
   root certificate authority last ?

 3) a sequence (chain) of (always) "useful" X.509 certificates ?

 4) a sequence (chain) of (possibly) "useful" X.509 certificates ?

In Section 4.1.2 which is specific to the request, the text says: "the
requestor MAY include certificates that help the OCSP responder verify the
requestor's signature in the certs field of Signature". The question is
whether "the requestor MAY include certificates that help the OCSP
responder" or whether "the requestor MAY include certificates that *MAY*
help the OCSP responder". In the fisrt case, they really help, so at least
some certificates from a valid chain shall be included. In the second case,
they MAY help, so they may also not help, so any kind of certificate may be
included.   
 
Note that the last interpretation allows for all the others.

Where do we go from this ?

Denis

> > > An OCSP client might assume that only a single certificate corresponds
> > > to the responder ID and for example just look for the first certificate
> > > in the certs attribute which matches the reponder ID and verify that.
> >
> > I think most -- like 99.9999% -- PKI programs are not equipped to handle
> > cross-certified entities.
> >         /r$
> >
> > --
> > Zolera Systems, Your Key to Online Integrity
> > Securing Web services: XML, SOAP, Dig-sig, Encryption
> > http://www.zolera.com


Received: by above.proper.com (8.11.6/8.11.3) id f8EGnEP11601 for ietf-pkix-bks; Fri, 14 Sep 2001 09:49:14 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8EGnDD11597 for <[e-mail]>; Fri, 14 Sep 2001 09:49:13 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 14 Sep 2001 09:49:57 -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, 14 Sep 2001 09:49:57 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <SMT35HHM>; Fri, 14 Sep 2001 09:42:31 -0700
Content-return: allowed
Date: Fri, 14 Sep 2001 09:42:30 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: Clarification request on RFC 2560
To: "'Rich Salz'" <[e-mail]>, Dr S N Henson <[e-mail]>
Cc: "Pkix (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>

Hi Rich,

    Are you referring to the issue of a single VA/OCSP Responder
supplying delegated certificates from multiple CAs in a response?


    If so, I wouldn't go quite that far. I know of at least one
implemenation that does support this behavior (and don't think
there are 999,999 other implementations of OCSP out there...)

:-)

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: Rich Salz [mailto:[e-mail]]
> Sent: Friday, September 14, 2001 7:53 AM
> To: Dr S N Henson
> Cc: Pkix (E-mail)
> Subject: Re: Clarification request on RFC 2560
> 
> 
> 
> > An OCSP client might assume that only a single certificate 
> corresponds
> > to the responder ID and for example just look for the first 
> certificate
> > in the certs attribute which matches the reponder ID and 
> verify that.
> 
> I think most -- like 99.9999% -- PKI programs are not 
> equipped to handle
> cross-certified entities.
> 	/r$
> 
> -- 
> Zolera Systems, Your Key to Online Integrity
> Securing Web services: XML, SOAP, Dig-sig, Encryption
> http://www.zolera.com
> 


Received: by above.proper.com (8.11.6/8.11.3) id f8EGjHS11547 for ietf-pkix-bks; Fri, 14 Sep 2001 09:45:17 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8EGjGD11543 for <[e-mail]>; Fri, 14 Sep 2001 09:45:16 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 14 Sep 2001 09:46:00 -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, 14 Sep 2001 09:46:00 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <SMT35HG0>; Fri, 14 Sep 2001 09:38:34 -0700
Content-return: allowed
Date: Fri, 14 Sep 2001 09:38:33 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: Clarification request on RFC 2560
To: "'Dr S N Henson'" <[e-mail]>, "Pkix (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>

Hi Steve,
    I would hope a lot of the clients would support this
capability (of a server supplying multiple certs in a response,
each showing that it had delegated authority from multiple CAs).

A lot of our customers run our server in a mode where it supports
multiple CAs - frequently multiple CAs that form a hierarchy.

By allowing a server to supply delegated certificates from multiple
CAs, a client can make a single query to a VA for a whole chain
(where the VA is the designated responder for all CAs in the chain).

This gives people a reasonable amount of efficiency - client needs
to make a single query for a whole chain.

If a client were not to support multiple delegated certs in a
response, it would need to make multiple queries.


Regards,
Ambarish

P.S. I know that we have supported this behavior in our toolkit
and apps for some time.

---------------------------------------------------------------------
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: Dr S N Henson [mailto:[e-mail]]
> Sent: Friday, September 14, 2001 4:01 AM
> To: Pkix (E-mail)
> Subject: Re: Clarification request on RFC 2560
> 
> 
> 
> Ryan Hurst wrote:
> > 
> > 
> > 
> > <rmh>You are correct we are looking to prove #3 in this 
> case, the response
> > would have contained the each of the responder certificates 
> associated with
> > the signature in the certs[] attribute (eg all three 
> delegated responder
> > certificates). The client would then look at each of the 
> CertIDs in the
> > response and then make sure that it had it can verify #3 
> against the certs[]
> > structure (of coarse after confirming that they are trusted).</rmh>
> > 
> 
> I wonder how many OCSP clients actually behave like that? OpenSSL,
> currently at least, doesn't.
> 
> An OCSP client might assume that only a single certificate corresponds
> to the responder ID and for example just look for the first 
> certificate
> in the certs attribute which matches the reponder ID and verify that.
> This would reject the response in the above scenario.
> 
> 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 localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8EGhBr11508 for ietf-pkix-bks; Fri, 14 Sep 2001 09:43:11 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8EGh9D11503 for <[e-mail]>; Fri, 14 Sep 2001 09:43:09 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 14 Sep 2001 09:43: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]>; Fri, 14 Sep 2001 09:43:48 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <SMT35HG5>; Fri, 14 Sep 2001 09:36:21 -0700
Content-return: allowed
Date: Fri, 14 Sep 2001 09:36:21 -0700
From: Ryan Hurst <[e-mail]>
Subject: RE: Clarification request on RFC 2560
To: "'Rich Salz'" <[e-mail]>, Dr S N Henson <[e-mail]>
Cc: "Pkix (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
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>

Rich --

	I would agree with that, however I do not see this case as being a
cross certification case; can you elaborate?

Ryan

-----Original Message-----
From: Rich Salz [mailto:[e-mail]] 
Sent: Friday, September 14, 2001 7:53 AM
To: Dr S N Henson
Cc: Pkix (E-mail)
Subject: Re: Clarification request on RFC 2560


> An OCSP client might assume that only a single certificate corresponds
> to the responder ID and for example just look for the first certificate
> in the certs attribute which matches the reponder ID and verify that.

I think most -- like 99.9999% -- PKI programs are not equipped to handle
cross-certified entities.
	/r$

-- 
Zolera Systems, Your Key to Online Integrity
Securing Web services: XML, SOAP, Dig-sig, Encryption
http://www.zolera.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8EFt9309382 for ietf-pkix-bks; Fri, 14 Sep 2001 08:55:09 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8EFt8D09375 for <[e-mail]>; Fri, 14 Sep 2001 08:55:08 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id f8EFsYq21482 for <[e-mail]>; Fri, 14 Sep 2001 11:54:34 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 14 Sep 2001 11:48:50 -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: "Pkix (E-mail)" <[e-mail]>
Subject: Re: Clarification request on RFC 2560
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-H-S-Loop-Check-Ejzfr: 
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 that 99.9999% of all PKI programs (i.e. SSL clients, which are forbidden
from handling cross-certification*), or 99.9999% of those PKI programs,
such as S/MIME, whose specifications are not so short sighted as to forbid it?

Dave


* SSL 3.0: "certificate_list - This is a sequence (chain) of X.509 certificates,
            ordered with the sender's certificate first and the [sender's] root
            certificate authority last."



Rich Salz wrote:
> 
> > An OCSP client might assume that only a single certificate corresponds
> > to the responder ID and for example just look for the first certificate
> > in the certs attribute which matches the reponder ID and verify that.
> 
> I think most -- like 99.9999% -- PKI programs are not equipped to handle
> cross-certified entities.
>         /r$
> 
> --
> Zolera Systems, Your Key to Online Integrity
> Securing Web services: XML, SOAP, Dig-sig, Encryption
> http://www.zolera.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8EFN9L05207 for ietf-pkix-bks; Fri, 14 Sep 2001 08:23:09 -0700 (PDT)
Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8EFN7D05202 for <[e-mail]>; Fri, 14 Sep 2001 08:23:07 -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.3) with SMTP id f8EFMrQ29400; Fri, 14 Sep 2001 08:22:53 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Ambarish Malpani" <[e-mail]>, "Denis Pinkas" <[e-mail]>
Cc: "IETF-PKIX" <[e-mail]>
Subject: CRLs for OCSP
Date: Fri, 14 Sep 2001 08:21:32 -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>

Ambarish,

Actually I'm far less concerned about CRLs per se than the timeliness issue
that Carlisle and I discussed a few years back when he and I argued the
notions underlying OCSP.  What concerns me are the systems-level
requirements that derive from assuming CRLs are the only and best means to
deliver OCSP-based (or equivalent) services.

It seems to me we are heading in that direction.  That's not necessarily a
bad thing.  I can see that in some instances CRLs are sufficient, especially
in very large-scale commercial deployments involving ad-hoc interactions
between autonomous trust domains.  I can also see that in certain
deployments, high-frequency deltas can effectively address the timeliness
requirements OCSP might otherwise satisfy.

Yet a requirement on a more closed trust domain that it MUST produce a CRL
in order to deliver OCSP-based services seems to me to unduly burdensome.
Further, the exchange of equivalent information in support of delegated
validation (vice revocation) still remains an open issue in this context.
Lastly, there exists obvious issues when the periodicity of CRLs (as
generally practiced) is put up against the aperiodic and on-demand nature of
OCSP (or equivalent).

So, basically, I just think there's some issues to discuss.  As I've heard
repeatedly in the IETF, current market practices and shipping products
should not be permitted to constrain our consideration of the best technical
solution going forward.  I remain especially concerned that several
under-examined systems-level issues will cause problems down the road.
These are easily predictable today; we should be developing answers in a
concomitant fashion.


Mike

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



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8EEq8k03757 for ietf-pkix-bks; Fri, 14 Sep 2001 07:52:08 -0700 (PDT)
Received: from zolera.com (IDENT:root@[63.142.188.177]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8EEq6D03753 for <[e-mail]>; Fri, 14 Sep 2001 07:52:06 -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 f8EEqVa20177; Fri, 14 Sep 2001 10:52:31 -0400
Message-ID: <[e-mail]>
Date: Fri, 14 Sep 2001 10:52:32 -0400
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Dr S N Henson <[e-mail]>
CC: "Pkix (E-mail)" <[e-mail]>
Subject: Re: Clarification request on RFC 2560
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>

> An OCSP client might assume that only a single certificate corresponds
> to the responder ID and for example just look for the first certificate
> in the certs attribute which matches the reponder ID and verify that.

I think most -- like 99.9999% -- PKI programs are not equipped to handle
cross-certified entities.
	/r$

-- 
Zolera Systems, Your Key to Online Integrity
Securing Web services: XML, SOAP, Dig-sig, Encryption
http://www.zolera.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8EBm0L23664 for ietf-pkix-bks; Fri, 14 Sep 2001 04:48:00 -0700 (PDT)
Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8EBlxD23656 for <[e-mail]>; Fri, 14 Sep 2001 04:47:59 -0700 (PDT)
Received: from hawk.ecs.soton.ac.uk (hawk.ecs.soton.ac.uk [152.78.68.142]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id MAA00456 for <[e-mail]>; Fri, 14 Sep 2001 12:48:05 +0100 (BST)
Received: from jap.ecs.soton.ac.uk (jap.ecs.soton.ac.uk [152.78.69.201]) by hawk.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id MAA03295 for <[e-mail]>; Fri, 14 Sep 2001 12:47:56 +0100 (BST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Fri, 14 Sep 2001 12:44:47 +0100
To: [e-mail]
From: J Adrian Pickering <[e-mail]>
Subject: Re: Notary systems requirements
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 14:32 13/09/01 +0200, Alfonso De Gregorio wrote:

>what about to start to working on a document that collects requirements
>for notary systems based also on TSAs?
>
>In my opinion, the current TSP don't allows always the use of a
>time-stamp token as a proof-of-authorship, because the security
>analysis of the protocol don't address the possibility of a
>deliberate replay attack by a middleman replaying legitimate TS
>_requests_;...

<snip>

To avoid this attack, Alice must be required to hash the sign the
>document she wants to  time-stamp; compute the hash over the signature
>of the signed data and set the messageImprint field of time-stamp
>request to the computed value (similarly to what is required in
>Appendix A, for the proof sign creation before corresponding certificate
>revocation).

Correct. This would be wise anyway if you want to counter Rabin's attack 
i.e. make your own peculiar alteration to the base data - what you suggest 
is just that. If the TSA chooses to work by 'open declaration' of its 
timestamping records then this also can help check what is claimed to be 
happening. The courts will examine the evidence available and make their 
own judgement.

TSAs may well not want to respond to unsolicited requests (a) to avoid DoS 
attacks and (b) to ensure only paid-up subscribers get the service. 
Therefore, there must be some identity/source checking going on and the 
courts may take some notice of this. However, this is outside the scope of TSP.

As someone who is interested in wider uses of TSP I would support looking 
at these. However, I do not think this forum is the right place? PKIX 
thrust is enabling and, in TSP, it has enabled. Yes?

Adrian Pickering/
Electronics and Computer Science
University of Southampton, UK



Received: by above.proper.com (8.11.6/8.11.3) id f8EBD0R20972 for ietf-pkix-bks; Fri, 14 Sep 2001 04:13:00 -0700 (PDT)
Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8EBCwD20962 for <[e-mail]>; Fri, 14 Sep 2001 04:12:58 -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 15hqu1-000Cm5-0A for [e-mail]; Fri, 14 Sep 2001 11:12:57 +0000
Message-ID: <[e-mail]>
Date: Fri, 14 Sep 2001 12:00:33 +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: "Pkix (E-mail)" <[e-mail]>
Subject: Re: Clarification request on RFC 2560
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>

Ryan Hurst wrote:
> 
> 
> 
> <rmh>You are correct we are looking to prove #3 in this case, the response
> would have contained the each of the responder certificates associated with
> the signature in the certs[] attribute (eg all three delegated responder
> certificates). The client would then look at each of the CertIDs in the
> response and then make sure that it had it can verify #3 against the certs[]
> structure (of coarse after confirming that they are trusted).</rmh>
> 

I wonder how many OCSP clients actually behave like that? OpenSSL,
currently at least, doesn't.

An OCSP client might assume that only a single certificate corresponds
to the responder ID and for example just look for the first certificate
in the certs attribute which matches the reponder ID and verify that.
This would reject the response in the above scenario.

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 localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8E46cl17028 for ietf-pkix-bks; Thu, 13 Sep 2001 21:06:38 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8E46aD17024 for <[e-mail]>; Thu, 13 Sep 2001 21:06:36 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Thu, 13 Sep 2001 21:07:23 -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, 13 Sep 2001 21:07:22 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <SMT35F27>; Thu, 13 Sep 2001 20:59:57 -0700
Content-return: allowed
Date: Thu, 13 Sep 2001 20:59:57 -0700
From: Ryan Hurst <[e-mail]>
Subject: RE: Clarification request on RFC 2560
To: "'[e-mail]'" <[e-mail]>
Cc: "Pkix (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
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>

Andrew --

	Nice to meet you, you will find my answers in line.

-----Original Message-----
From: Andrew Sciberras [mailto:[e-mail]] 
Sent: Thursday, September 13, 2001 7:31 PM
To: 'Ryan Hurst'
Cc: Pkix (E-mail)
Subject: RE: Clarification request on RFC 2560

Ryan,

I am at a loss to understand how the scenario which you have described below
will work.

Firstly, Your OCSP responder has 3 different signing certificates. Although
issued by different CA's, each certificate will  contain the same key data.


<rmh>Yes, what is a certificate after all but a mechanism to bind an
identity to a private key, this facilitates multiple authorities attesting
to the identity (and in this case authority to respond on its behalf)</rmh>

When you receive a single request that asks for the status of 3 unrelated
certificates, which certificate will you sign the single response with?


<rmh>remember you do not sign with a certificate you sign with a private
key, so the responder would sign with its "delegated" key</rmh>

>From what I can see, section 4.2.2.2 states:
"..... They MUST reject the response if the certificate required to validate
the signature on the
 response fails to meet at least one of the following criteria:

   1. Matches a local configuration of OCSP signing authority for the
   certificate in question; or

   2. Is the certificate of the CA that issued the certificate in
   question; or

   3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
   extension and is issued by the CA that issued the certificate in
   question.
"

The point that must be satisfied by the scenario described above is #3
which, amongst other things, states that the signing certificate must be
issued by the CA that issued the certificate in question.
Although all three of your signing certificates have the same keys,
shouldn't the OCSP client have to validate the response by looking at the
actual signing certificate and verifying that it was actually issued by the
CA in question?

<rmh>You are correct we are looking to prove #3 in this case, the response
would have contained the each of the responder certificates associated with
the signature in the certs[] attribute (eg all three delegated responder
certificates). The client would then look at each of the CertIDs in the
response and then make sure that it had it can verify #3 against the certs[]
structure (of coarse after confirming that they are trusted).</rmh>

How should the OCSP Client proceed at this point, since there are 3
unrelated certificates in question, with only one certificate signing the
response?

<rmh>Let me know if this answers your question</rmh>

Andrew Sciberras
Software Engineer
Adacel Technologies Ltd





> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Ryan Hurst
> Sent: Friday, September 14, 2001 3:31 AM
> To: 'Denis Pinkas'; pkix
> Cc: Mike Myers; Ambarish Malpani
> Subject: RE: Clarification request on RFC 2560
>
>
>
> Denis --
>
> 	I agree this is not terribly clear in the RFC and your
> question is a
> common one (maybe we can get some amended text in this regard
> in the RFC?).
> In MOST of the implementations I have looked at (ours
> included) the certs
> portion of the structure is used to provide the client with
> the certificates
> associated with the signature on the response.
>
> Consider this scenario; I have a single OCSP responder
> configured to serve
> responses for 3 un-related certificate authorities. The
> responder has CA
> delegated certificates (each CA has certified the same
> request and key pair)
> from each of these certificate authorities (as per section
> 2.2 and 4.2.2.2
> of the OCSP RFC [2560]). I have a client who sends a single
> OCSP request for
> statuses for 3 unrelated certificates (one from each of the previously
> mentioned CAs) to the responder. For the responder to produce
> a response
> this response that could be verified by the client it needs to provide
> certificates that could be chained back to the issuer of the
> certificates in
> question, since a ResponderID only provides the options to
> identify the
> responder byName or byKey the responder needs to provide the
> client with the
> certificates associated with the response. In this case 3 different
> certificates (once again all with the same key material) thus
> allowing the
> client to establish that response was signed by an authority
> delegated by
> each issuing CA.
>
> Using the certs[0] for a single responder chain would then
> limit a responder
> to serving responses for one CA in a delegated scenario as
> described above.
>
> Also the CA delegated scenario described by section 2.6 of
> the RFC [2560]
> states:
>
> "A certificate's issuer explicitly delegates OCSP signing authority by
> issuing a certificate containing a unique value for
> extendedKeyUsage in the
> OCSP signer's certificate. This certificate MUST be issued
> directly to the
> responder by the cognizant CA"
>
> I interpret this to mean that only the issuer of the certificate must
> explicitly delegate to this authority, as such when verifying
> a response in
> this case I would only need the signing certificate not its chain.
>
>
> Ryan M. Hurst
> ValiCert, Inc.
>
>
>  -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Thursday, September 13, 2001 3:20 AM
> To: pkix
> Cc: Mike Myers
> Subject: Clarification request on RFC 2560
>
>
>
> In RFC 2560 section 4.2.1 (OCSP Response), we have
>
> BasicOCSPResponse       ::= SEQUENCE {
>       tbsResponseData      ResponseData,
>       signatureAlgorithm   AlgorithmIdentifier,
>       signature            BIT STRING,
>       certs                [0] EXPLICIT SEQUENCE OF
> Certificate OPTIONAL }
>
> Usually every ASN1 field is explained, but in that document
> the certs field
> is not explained.
>
> Should that optional field be interpreted to carry a sequence
> of possibly
> useful certificates ?
>
> Denis
>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8E2Udj15916 for ietf-pkix-bks; Thu, 13 Sep 2001 19:30:39 -0700 (PDT)
Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by above.proper.com (8.11.6/8.11.3) with SMTP id f8E2UYD15911 for <[e-mail]>; Thu, 13 Sep 2001 19:30:35 -0700 (PDT)
Received: (qmail 5900 invoked from network); 14 Sep 2001 02:37:33 -0000
Received: from shylock.adacel.com.au (HELO shylock) (203.8.85.11) by arnie.adacel.com.au with SMTP; 14 Sep 2001 02:37:33 -0000
Reply-To: <[e-mail]>
From: "Andrew Sciberras" <[e-mail]>
To: "'Ryan Hurst'" <[e-mail]>
Cc: "Pkix \(E-mail\)" <[e-mail]>
Subject: RE: Clarification request on RFC 2560
Date: Fri, 14 Sep 2001 12:31:28 +1000
Message-ID: <029001c13cc5$5c61ed30$[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
In-Reply-To: <[e-mail]>
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>

Ryan,

I am at a loss to understand how the scenario which you have described below
will work.

Firstly, Your OCSP responder has 3 different signing certificates. Although
issued by different CA's, each certificate will  contain the same key data.

When you receive a single request that asks for the status of 3 unrelated
certificates, which certificate will you sign the single response with?

>From what I can see, section 4.2.2.2 states:
"..... They MUST reject the response if the certificate required to validate
the signature on the
 response fails to meet at least one of the following criteria:

   1. Matches a local configuration of OCSP signing authority for the
   certificate in question; or

   2. Is the certificate of the CA that issued the certificate in
   question; or

   3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
   extension and is issued by the CA that issued the certificate in
   question.
"

The point that must be satisfied by the scenario described above is #3
which, amongst other things, states that the signing certificate must be
issued by the CA that issued the certificate in question.
Although all three of your signing certificates have the same keys,
shouldn't the OCSP client have to validate the response by looking at the
actual signing certificate and verifying that it was actually issued by the
CA in question?

How should the OCSP Client proceed at this point, since there are 3
unrelated certificates in question, with only one certificate signing the
response?

Andrew Sciberras
Software Engineer
Adacel Technologies Ltd





> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Ryan Hurst
> Sent: Friday, September 14, 2001 3:31 AM
> To: 'Denis Pinkas'; pkix
> Cc: Mike Myers; Ambarish Malpani
> Subject: RE: Clarification request on RFC 2560
>
>
>
> Denis --
>
> 	I agree this is not terribly clear in the RFC and your
> question is a
> common one (maybe we can get some amended text in this regard
> in the RFC?).
> In MOST of the implementations I have looked at (ours
> included) the certs
> portion of the structure is used to provide the client with
> the certificates
> associated with the signature on the response.
>
> Consider this scenario; I have a single OCSP responder
> configured to serve
> responses for 3 un-related certificate authorities. The
> responder has CA
> delegated certificates (each CA has certified the same
> request and key pair)
> from each of these certificate authorities (as per section
> 2.2 and 4.2.2.2
> of the OCSP RFC [2560]). I have a client who sends a single
> OCSP request for
> statuses for 3 unrelated certificates (one from each of the previously
> mentioned CAs) to the responder. For the responder to produce
> a response
> this response that could be verified by the client it needs to provide
> certificates that could be chained back to the issuer of the
> certificates in
> question, since a ResponderID only provides the options to
> identify the
> responder byName or byKey the responder needs to provide the
> client with the
> certificates associated with the response. In this case 3 different
> certificates (once again all with the same key material) thus
> allowing the
> client to establish that response was signed by an authority
> delegated by
> each issuing CA.
>
> Using the certs[0] for a single responder chain would then
> limit a responder
> to serving responses for one CA in a delegated scenario as
> described above.
>
> Also the CA delegated scenario described by section 2.6 of
> the RFC [2560]
> states:
>
> "A certificate's issuer explicitly delegates OCSP signing authority by
> issuing a certificate containing a unique value for
> extendedKeyUsage in the
> OCSP signer's certificate. This certificate MUST be issued
> directly to the
> responder by the cognizant CA"
>
> I interpret this to mean that only the issuer of the certificate must
> explicitly delegate to this authority, as such when verifying
> a response in
> this case I would only need the signing certificate not its chain.
>
>
> Ryan M. Hurst
> ValiCert, Inc.
>
>
>  -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Thursday, September 13, 2001 3:20 AM
> To: pkix
> Cc: Mike Myers
> Subject: Clarification request on RFC 2560
>
>
>
> In RFC 2560 section 4.2.1 (OCSP Response), we have
>
> BasicOCSPResponse       ::= SEQUENCE {
>       tbsResponseData      ResponseData,
>       signatureAlgorithm   AlgorithmIdentifier,
>       signature            BIT STRING,
>       certs                [0] EXPLICIT SEQUENCE OF
> Certificate OPTIONAL }
>
> Usually every ASN1 field is explained, but in that document
> the certs field
> is not explained.
>
> Should that optional field be interpreted to carry a sequence
> of possibly
> useful certificates ?
>
> Denis
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8E2J2l15711 for ietf-pkix-bks; Thu, 13 Sep 2001 19:19:02 -0700 (PDT)
Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8E2J0D15703 for <[e-mail]>; Thu, 13 Sep 2001 19:19:00 -0700 (PDT)
Received: from tsg1 ([12.81.109.102]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <20010914021857.OHMD28026.mtiwmhc25.worldnet.att.net@tsg1>; Fri, 14 Sep 2001 02:18:57 +0000
Message-ID: <026201c13cc3$96366100$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Untrusting a Trusted Third Party: TSA.
Date: Thu, 13 Sep 2001 18:53:38 -0700
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.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
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>

Alfonso - I have said this many many times, but lets try it once more. The
instant of trust for the issuance of the time stamping token happens when
the token is verified. At this instant the TSA can easily return a
commentary to the questioning client that its clocks drifted xy and z amount
and as such the relying party can take the testimony of the TSA as being
that the actual time the incident happened was XY and Z + drift_value.

There is nothing anywhere that says that the TST itself is the testimony of
the TSA, just the token to prove that some TS was actually issued - i.e its
a receipt and not a very good one. This is an important concept and is
crucial to many many use models, but since the Authors decided not to add
use models to the draft or delineate them in a corresponding use document,
well...

Todd

----- Original Message -----
From: "Alfonso De Gregorio" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, September 13, 2001 5:30 AM
Subject: Untrusting a Trusted Third Party: TSA.


>
> Hi Everyone,
>
> The following consideration is quite obvious; however, it's intriguing
> to see how the TSP allows a user to perform a simple test against a
> TSA that he doesn't trust anymore.
>
> Assume a user is afraid that a TSA is issuing time-stamp tokens while
> not in synchronization with UTC; after all if a TSA use a trustworthy
> source of time and include a trustworthy time value for each time-stamp
> token is not necessarily ensuring that the clock doesn't drift outside
> the declared accuracy (this is addressed in ETSI - STF 178-T1 draft H).
>
> The test
> The ordering of time-stamp tokens issued by different TSAs is only
> possible when the _absolute value_ (*) of the difference between the
> genTime of the first time-stamp token and the genTime of the second
> time-stamp token is greater than the sum of the accuracies of the
> genTime for each time-stamp token.
>
> *) partially contrarywise to what is asserted in section 2.4.2 of rfc3161.
>
> TSA-1: the tsa not trusted anymore by alice
> TSA-2..TSA-3: tsa still trusted by alice
>
> 1. Alice send a TimeStampReq to TSA-1 (TSA1Req) where
>    TimeStampReq.messageImprint is simply an hash of a document kept
>    secret (Alice_doc);
> 2. Upon receiving the response (TSA1Response), Alice hash the received
>    time-stamp token ( hash(TSA1Response) ) and send as quickly as possible
>    a time-stamp request to TSA2 (TSA2Req), where
>    TimeStampReq.messageImprint is hash(TSA1Response);
> 3. if the absolute value of the difference of the first time-stamp token
>    and the genTime of the second time-stamp token ( abs(x) ) is greater
>    than the sum of the accuracies of the genTime for each time-stamp
>    token, Alice can order the two tokens; but for a positive value of
>    the difference we have a consistent chain of time-stamp
>    request/response, and for a negative a contradictory result.
>
>   x = TSA2Response.genTime - TSA1Response.genTime;
>   while abs( x ) > (TSA2Response.accuracy + TSA1Response.accuracy)
> if  x > 0 --> TSA2Resoponse follows TSA1Response
> if  x < 0 --> TSA2Response is _antecedents_ to TSA1Response
>
>    Alice can prove the opposite showing the chained sequence of time-stamp
>    requests:
> a. Alice_doc
> b. TSA1Response.TSTInfo.messageImprint = hash(Alice_doc)
> c. TSA2Response.TSTInfo.messageImprint(hash(TSA1Response))
>
>
> Sincerely,
> alfonso
>



Received: by above.proper.com (8.11.6/8.11.3) id f8E0lNe14035 for ietf-pkix-bks; Thu, 13 Sep 2001 17:47:23 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8E0lMD14031 for <[e-mail]>; Thu, 13 Sep 2001 17:47:23 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Thu, 13 Sep 2001 17:48:08 -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]; Thu, 13 Sep 2001 17:48:08 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <SMT351ZH>; Thu, 13 Sep 2001 17:40:43 -0700
Content-return: allowed
Date: Thu, 13 Sep 2001 17:40:42 -0700
From: Ambarish Malpani <[e-mail]>
Subject: FW: Clarification request on RFC 2560
To: "'[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>

Sorry, Denis/Ryan. My mistake. Have clarified the use of that
field in responses in the candidate for a Draft Standard.

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: Ryan Hurst 
> Sent: Thursday, September 13, 2001 5:15 PM
> To: Ambarish Malpani
> Subject: RE: Clarification request on RFC 2560
> 
> 
> Ambarish that text is specific to the request...
> 
> Ryan
> 
> -----Original Message-----
> From: Ambarish Malpani [mailto:[e-mail]] 
> Sent: Thursday, September 13, 2001 10:57 AM
> To: 'Denis Pinkas'; pkix
> Cc: Mike Myers
> Subject: RE: Clarification request on RFC 2560
> 
> 
> 
> See section 4.1.2. It is explained over there.
> 
> 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: Denis Pinkas [mailto:[e-mail]]
> > Sent: Thursday, September 13, 2001 3:20 AM
> > To: pkix
> > Cc: Mike Myers
> > Subject: Clarification request on RFC 2560
> > 
> > 
> > 
> > 
> > In RFC 2560 section 4.2.1 (OCSP Response), we have
> > 
> > BasicOCSPResponse       ::= SEQUENCE {
> >       tbsResponseData      ResponseData,
> >       signatureAlgorithm   AlgorithmIdentifier,
> >       signature            BIT STRING,
> >       certs                [0] EXPLICIT SEQUENCE OF 
> > Certificate OPTIONAL }
> > 
> > Usually every ASN1 field is explained, but in that document 
> > the certs field
> > is not explained.
> > 
> > Should that optional field be interpreted to carry a sequence 
> > of possibly
> > useful certificates ?
> > 
> > Denis
> > 
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8DNXCN13119 for ietf-pkix-bks; Thu, 13 Sep 2001 16:33:12 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8DNXCD13115 for <[e-mail]>; Thu, 13 Sep 2001 16:33:12 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Thu, 13 Sep 2001 16:33:57 -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, 13 Sep 2001 16:33:56 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <SMT351RH>; Thu, 13 Sep 2001 16:26:32 -0700
Content-return: allowed
Date: Thu, 13 Sep 2001 16:26:31 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: Removing expired certificates from CRLs.....
To: "'Michael Myers'" <[e-mail]>, Denis Pinkas <[e-mail]>
Cc: IETF-PKIX <[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>

Mike, it is unclear to me why you consider CRLs to be a bad
mechanism for passing revocation data to OCSP responders.

The 2 big problems with CRLs are:
a.  distribution of full CRL data to a large number of clients. 
b. notifying all relying clients whenever a new (unexpected) CRL
has been produced due to a revocation event (ie. a CRL produced
earlier than the nextUpdate period on an old CRL).

We have deployed responders in a large number of places, where
we have used a push mechanism to send CRLs to our VA (our
OCSP server). This method has worked very well, even for pretty
large installations - the time to produce 100K CRLs isn't very
large. Neither is the time to get it from the CA to the VA.

The final relying parties are using OCSP and therefore getting
up to date responses, without needing to incur the overhead of
downloading full CRLs every time.

The CRL is just a standards based data
format for getting revocation information from the CA to the
VA - think of it as a database snapshot that is created
whenever the database changes.


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: Michael Myers [mailto:[e-mail]]
> Sent: Thursday, September 13, 2001 11:26 AM
> To: Denis Pinkas
> Cc: IETF-PKIX
> Subject: RE: Removing expired certificates from CRLs.....
> 
> 
> 
> Denis,
> 
> Thank you for your consideration of historic aspect of 
> digital signatures.
> I'm sure more work remains to be done in this area.  I for one however
> remain more concerned of our broad assumptions regarding the 
> use of periodic
> CRLs as the basis for aperiodic OCSP-based services that 
> deliver on-demand
> class timeliness.  Several systems-level issues are 
> under-explored in this
> context.  Within closed environments there might exist data exchange
> mechanisms that are fully responsive to the security requirements CRLs
> satisfy but do so in a means that enables not only the timely 
> inter-domain
> exchange of revocation status, but validation status as well.
> 
> Mike
> 
> 
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of Denis Pinkas
> > Sent: Thursday, September 13, 2001 1:31 AM
> > To: Michael Myers
> > Cc: IETF-PKIX
> > Subject: Re: Removing expired certificates from CRLs.....
> >
> >
> >
> > Michael,
> >
> > > Denis,
> > >
> > > What are your thoughts on the timeliness characteristic 
> between OCSP and
> > > CRLs?
> >
> > Well ...
> >
> > I must admit that the definition of the archive cutofff (section
> > 4.4.4) from
> > RFC 2560 has always been very strange for me, since it 
> defines a time
> > interval rather then an absolute time. I read several times 
> the text and
> > could not figure out how in practice it would be used.
> >
> > The text talks about a retention interval without saying
> > explictly to which
> > event it is relative to.
> >
> > Is it the time interval beyond the notAfter date from a 
> certificate ?
> > The text does not say so.
> >
> > In addition, the text is talking, as an example, of a retention
> > interval of
> > 7 years (!) whereas in the context of that thread we are 
> only talking of
> > about a month.
> >
> > If I had to define from scratch the extension I would 
> simply define an
> > absolute date (e.g. called 
> ExtendedRevocationInformationDate, quite a
> > long name, but explicit) that could directly override the 
> notAfter field
> > from the Validity field of a certificate. This would mean that this
> > extension allows to know until when the revocation information is
> > maintained. It is not directly related to the produceAt 
> time. The only
> > condition is that, when it is present, it is always later 
> than produceAt.
> >
> > This is a problem because, if I understand correctly RC 
> 2560, we have the
> > following equation:
> >
> > ArchiveCutoff = producedAt - retention interval.
> >
> > I do not see a clear relationship between these two concepts.
> >
> > Unless you see one, it would mean that an extension different from
> > ArchiveCutoff would be necessary for OCSP responses so that 
> we can have
> > identical concepts for CRLs and OCSP responses.
> >
> > Thanks for raising the question.
> >
> > Denis
> >
> > > Mike
> > >
> > > Michael Myers
> > > t: +415.819.1362
> > > e: mailto:[e-mail]
> > > w: http://www.traceroutesecurity.com
> > >
> > > > -----Original Message-----
> > > > From: Denis Pinkas [mailto:[e-mail]]
> > > > Sent: Wednesday, September 12, 2001 12:35 AM
> > > > To: Michael Myers
> > > > Cc: IETF-PKIX
> > > > Subject: Re: Removing expired certificates from CRLs.....
> > > >
> > > >
> > > >
> > > > > All,
> > > > >
> > > > > I think a unique extension creates the least impact.
> > > > >
> > > > > More broadly though, what's really bothering me is my sense
> > that we're
> > > > > backing into the notion of a 1-1 between CRLs and 
> online status
> > > > mechanisms.
> > > > >
> > > > > Assume an environment that both publishes CRLs and 
> offers OCSP-based
> > > > > services against the same set of certificates.  What if:
> > > > >
> > > > > a) The CA receives a revocation request at T1;
> > > > >
> > > > > b) A database state variable is flipped at T1+N;
> > > > >
> > > > > c) An OCSP request is received at T1+N+M;
> > > > >
> > > > > d) An OCSP response is transmitted at T1+N+M+K;
> > > > >
> > > > > e) Yet the next CRL cycle won't run (i.e. the cron
> > > > >    job won't fire) until T1+X where X >> (N+M+K).
> > > > >
> > > > > Thus relying parties are enabled to pick and choose between
> > CRLs or OCSP
> > > > > depending on how it might benefit their argument for remedy
> > > > under digital
> > > > > signature laws.
> > > > >
> > > > > Thoughts, anyone?
> > > >
> > > > Some validation policies, like Signature policies are able to
> > say whether
> > > > CRLs or OCSP responses shall be used.
> > > >
> > > > As an example see: draft-ietf-smime-espolicies-01.txt
> > > >
> > > > EnuRevReq  ::= ENUMERATED {
> > > >       clrCheck        (0),
> > > >                    --Checks must be made against current CRLs
> > > >                  -- (or authority revocation lists (ARL))
> > > >       ocspCheck       (1), -- The revocation status 
> must be checked
> > > >                   -- using the Online Certificate 
> Status Protocol
> > > >                   -- (OCSP),RFC 2450.
> > > >       bothCheck       (2),
> > > >                   -- Both CRL and OCSP checks must be 
> carried out
> > > >       eitherCheck     (3),
> > > >                   -- At least one of CRL or OCSP checks must be
> > > >                   -- carried out
> > > >       noCheck         (4),
> > > >                   -- no check is mandated
> > > >       other           (5)
> > > >                   -- Other mechanism as defined by 
> signature policy
> > > >                   -- extension
> > > >         }
> > > >
> > > > If either CRL (i.e.clrCheck) or OCSP (i.e. ocspCheck) is
> > mandated, then
> > > > there is no conflict between the two mechanisms.
> > > >
> > > > Denis
> > > >
> > > >
> > > > > Mike
> > > > >
> > > > > Michael Myers
> > > > > t: +415.819.1362
> > > > > e: mailto:[e-mail]
> > > > > w: http://www.traceroutesecurity.com g
> > > >
> >
> 


Received: by above.proper.com (8.11.6/8.11.3) id f8DN03k12347 for ietf-pkix-bks; Thu, 13 Sep 2001 16:00:03 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8DN02D12341 for <[e-mail]>; Thu, 13 Sep 2001 16:00:02 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Thu, 13 Sep 2001 11:04:16 -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, 13 Sep 2001 11:04:15 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <SMT35C6K>; Thu, 13 Sep 2001 10:56:51 -0700
Content-return: allowed
Date: Thu, 13 Sep 2001 10:56:51 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: Clarification request on RFC 2560
To: "'Denis Pinkas'" <[e-mail]>, pkix <[e-mail]>
Cc: Mike Myers <[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>

See section 4.1.2. It is explained over there.

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: Denis Pinkas [mailto:[e-mail]]
> Sent: Thursday, September 13, 2001 3:20 AM
> To: pkix
> Cc: Mike Myers
> Subject: Clarification request on RFC 2560
> 
> 
> 
> 
> In RFC 2560 section 4.2.1 (OCSP Response), we have
> 
> BasicOCSPResponse       ::= SEQUENCE {
>       tbsResponseData      ResponseData,
>       signatureAlgorithm   AlgorithmIdentifier,
>       signature            BIT STRING,
>       certs                [0] EXPLICIT SEQUENCE OF 
> Certificate OPTIONAL }
> 
> Usually every ASN1 field is explained, but in that document 
> the certs field
> is not explained.
> 
> Should that optional field be interpreted to carry a sequence 
> of possibly
> useful certificates ?
> 
> Denis
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8DN02612343 for ietf-pkix-bks; Thu, 13 Sep 2001 16:00:02 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8DN00D12333 for <[e-mail]>; Thu, 13 Sep 2001 16:00:00 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Thu, 13 Sep 2001 10:38:40 -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, 13 Sep 2001 10:38:40 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <SMT35CYB>; Thu, 13 Sep 2001 10:31:16 -0700
Content-return: allowed
Date: Thu, 13 Sep 2001 10:31:15 -0700
From: Ryan Hurst <[e-mail]>
Subject: RE: Clarification request on RFC 2560
To: "'Denis Pinkas'" <[e-mail]>, pkix <[e-mail]>
Cc: Mike Myers <[e-mail]>, Ambarish Malpani <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain
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 --

	I agree this is not terribly clear in the RFC and your question is a
common one (maybe we can get some amended text in this regard in the RFC?).
In MOST of the implementations I have looked at (ours included) the certs
portion of the structure is used to provide the client with the certificates
associated with the signature on the response. 

Consider this scenario; I have a single OCSP responder configured to serve
responses for 3 un-related certificate authorities. The responder has CA
delegated certificates (each CA has certified the same request and key pair)
from each of these certificate authorities (as per section 2.2 and 4.2.2.2
of the OCSP RFC [2560]). I have a client who sends a single OCSP request for
statuses for 3 unrelated certificates (one from each of the previously
mentioned CAs) to the responder. For the responder to produce a response
this response that could be verified by the client it needs to provide
certificates that could be chained back to the issuer of the certificates in
question, since a ResponderID only provides the options to identify the
responder byName or byKey the responder needs to provide the client with the
certificates associated with the response. In this case 3 different
certificates (once again all with the same key material) thus allowing the
client to establish that response was signed by an authority delegated by
each issuing CA.

Using the certs[0] for a single responder chain would then limit a responder
to serving responses for one CA in a delegated scenario as described above.

Also the CA delegated scenario described by section 2.6 of the RFC [2560]
states:

"A certificate's issuer explicitly delegates OCSP signing authority by
issuing a certificate containing a unique value for extendedKeyUsage in the
OCSP signer's certificate. This certificate MUST be issued directly to the
responder by the cognizant CA"

I interpret this to mean that only the issuer of the certificate must
explicitly delegate to this authority, as such when verifying a response in
this case I would only need the signing certificate not its chain.


Ryan M. Hurst
ValiCert, Inc.


 -----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Thursday, September 13, 2001 3:20 AM
To: pkix
Cc: Mike Myers
Subject: Clarification request on RFC 2560



In RFC 2560 section 4.2.1 (OCSP Response), we have

BasicOCSPResponse       ::= SEQUENCE {
      tbsResponseData      ResponseData,
      signatureAlgorithm   AlgorithmIdentifier,
      signature            BIT STRING,
      certs                [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

Usually every ASN1 field is explained, but in that document the certs field
is not explained.

Should that optional field be interpreted to carry a sequence of possibly
useful certificates ?

Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8DN02P12342 for ietf-pkix-bks; Thu, 13 Sep 2001 16:00:02 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8DN00D12335 for <[e-mail]>; Thu, 13 Sep 2001 16:00:01 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Thu, 13 Sep 2001 11:01: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]>; Thu, 13 Sep 2001 11:01:08 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <SMT35C50>; Thu, 13 Sep 2001 10:53:44 -0700
Content-return: allowed
Date: Thu, 13 Sep 2001 10:53:43 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: Removing expired certificates from CRLs.....
To: "'Denis Pinkas'" <[e-mail]>, Michael Myers <[e-mail]>
Cc: IETF-PKIX <[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>

Hi Denis,
    The ArchiveCutoff text is a little difficult to understand,
but is correct I believe.

The way I think about it, the response is saying that "as long
as your certificate didn't expire before the date specified in
the ArchiveCutoff field, the status reflected in this response
is correct". Conversely, if your certificate expired before the
ArchiveCutoff date, it might have been revoked before expiry, but
I am not saying anything about that status.

The equation you have derived is absolutely correct and this is
exactly the semantics that I was expecting from the CRL extension
we are talking about.

Do we agree?

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: Denis Pinkas [mailto:[e-mail]]
> Sent: Thursday, September 13, 2001 1:31 AM
> To: Michael Myers
> Cc: IETF-PKIX
> Subject: Re: Removing expired certificates from CRLs.....
> 
> 
> 
> Michael,
> 
> > Denis,
> > 
> > What are your thoughts on the timeliness characteristic 
> between OCSP and
> > CRLs?
> 
> Well ...
> 
> I must admit that the definition of the archive cutofff 
> (section 4.4.4) from
> RFC 2560 has always been very strange for me, since it defines a time
> interval rather then an absolute time. I read several times 
> the text and
> could not figure out how in practice it would be used.
> 
> The text talks about a retention interval without saying 
> explictly to which
> event it is relative to.
> 
> Is it the time interval beyond the notAfter date from a certificate ? 
> The text does not say so.
> 
> In addition, the text is talking, as an example, of a 
> retention interval of
> 7 years (!) whereas in the context of that thread we are only 
> talking of
> about a month.
> 
> If I had to define from scratch the extension I would simply define an
> absolute date (e.g. called ExtendedRevocationInformationDate, quite a
> long name, but explicit) that could directly override the 
> notAfter field
> from the Validity field of a certificate. This would mean that this
> extension allows to know until when the revocation information is
> maintained. It is not directly related to the produceAt time. The only
> condition is that, when it is present, it is always later 
> than produceAt.
> 
> This is a problem because, if I understand correctly RC 2560, 
> we have the
> following equation:
> 
> ArchiveCutoff = producedAt - retention interval.
> 
> I do not see a clear relationship between these two concepts. 
> 
> Unless you see one, it would mean that an extension different from
> ArchiveCutoff would be necessary for OCSP responses so that 
> we can have
> identical concepts for CRLs and OCSP responses.
> 
> Thanks for raising the question.
> 
> Denis
> 
> > Mike
> > 
> > Michael Myers
> > t: +415.819.1362
> > e: mailto:[e-mail]
> > w: http://www.traceroutesecurity.com
> > 
> > > -----Original Message-----
> > > From: Denis Pinkas [mailto:[e-mail]]
> > > Sent: Wednesday, September 12, 2001 12:35 AM
> > > To: Michael Myers
> > > Cc: IETF-PKIX
> > > Subject: Re: Removing expired certificates from CRLs.....
> > >
> > >
> > >
> > > > All,
> > > >
> > > > I think a unique extension creates the least impact.
> > > >
> > > > More broadly though, what's really bothering me is my 
> sense that we're
> > > > backing into the notion of a 1-1 between CRLs and online status
> > > mechanisms.
> > > >
> > > > Assume an environment that both publishes CRLs and 
> offers OCSP-based
> > > > services against the same set of certificates.  What if:
> > > >
> > > > a) The CA receives a revocation request at T1;
> > > >
> > > > b) A database state variable is flipped at T1+N;
> > > >
> > > > c) An OCSP request is received at T1+N+M;
> > > >
> > > > d) An OCSP response is transmitted at T1+N+M+K;
> > > >
> > > > e) Yet the next CRL cycle won't run (i.e. the cron
> > > >    job won't fire) until T1+X where X >> (N+M+K).
> > > >
> > > > Thus relying parties are enabled to pick and choose 
> between CRLs or OCSP
> > > > depending on how it might benefit their argument for remedy
> > > under digital
> > > > signature laws.
> > > >
> > > > Thoughts, anyone?
> > >
> > > Some validation policies, like Signature policies are 
> able to say whether
> > > CRLs or OCSP responses shall be used.
> > >
> > > As an example see: draft-ietf-smime-espolicies-01.txt
> > >
> > > EnuRevReq  ::= ENUMERATED {
> > >       clrCheck        (0),
> > >                    --Checks must be made against current CRLs
> > >                  -- (or authority revocation lists (ARL))
> > >       ocspCheck       (1), -- The revocation status must 
> be checked
> > >                   -- using the Online Certificate Status Protocol
> > >                   -- (OCSP),RFC 2450.
> > >       bothCheck       (2),
> > >                   -- Both CRL and OCSP checks must be carried out
> > >       eitherCheck     (3),
> > >                   -- At least one of CRL or OCSP checks must be
> > >                   -- carried out
> > >       noCheck         (4),
> > >                   -- no check is mandated
> > >       other           (5)
> > >                   -- Other mechanism as defined by 
> signature policy
> > >                   -- extension
> > >         }
> > >
> > > If either CRL (i.e.clrCheck) or OCSP (i.e. ocspCheck) is 
> mandated, then
> > > there is no conflict between the two mechanisms.
> > >
> > > Denis
> > >
> > >
> > > > Mike
> > > >
> > > > Michael Myers
> > > > t: +415.819.1362
> > > > e: mailto:[e-mail]
> > > > w: http://www.traceroutesecurity.com g
> > >
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8DKngI10374 for ietf-pkix-bks; Thu, 13 Sep 2001 13:49:42 -0700 (PDT)
Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8DKneD10370 for <[e-mail]>; Thu, 13 Sep 2001 13:49:40 -0700 (PDT)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <SSXMW0H4>; Thu, 13 Sep 2001 16:49:37 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: [e-mail], "'Bob Jueneman'" <[e-mail]>
Cc: [e-mail]
Subject: RE: XACML OID tag?
Date: Thu, 13 Sep 2001 16:49:32 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13C95.96DE76C0"
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_01C13C95.96DE76C0
Content-Type: text/plain;
	charset="iso-8859-7"
Content-Transfer-Encoding: quoted-printable

Hi Bob, Phill,

Forgive me if this sounds a bit harsh, but I do wish that some of the
critics of the attribute certificate portion of the X.509 specification =
were
more familiar with its contents.

I have no real interest in entering into a long thread on this topic, =
but I
have embedded some responses below (just for the sake of =
clarification).

Carlisle.


> ----------
> From: 	Bob Jueneman[SMTP:[e-mail]]
> Sent: 	Thursday, September 13, 2001 1:12 PM
> To: 	[e-mail]; [e-mail]
> Subject: 	RE: XACML OID tag?
>=20
> Phillip,
=20
(...some text deleted...)

> I do agree completely with your eloquent and highly descriptive =
"bogus
> with knobs on" characterization of a parallel, cross-certified =
identity
> and authorization certificate structure, with multiple trust roots =
for
> each attribute =AF such a concept is completely infeasible, and not =
worth
> even thinking about.
=20
(...more text deleted...)


> >>> "Hallam-Baker, Phillip" <[e-mail]> 09/13/01 09:37AM =
>>>
>=20
> Some responses to Bob's points and others.
=20
(...even more text deleted...)

> 3) Although SAML attribute assertions are similar to X509.v3 =
attribute
> certificates there are significant differences in the models. With
> attribute
> certificates the model is of issuing static pieces of data that have =
long
> validity intervals (days at least).=20
=20
No.  The fact that a validity period is present in the certificate does =
not
mean that the interval must be long ("days at least").  A validity =
period
can obviously be for any length of time (even seconds).  SAML =
assertions
also have validity periods.  In both X.509 and SAML the model is =
flexible
and accommodates long-lived and short-lived ACs/assertions.

> The attribute certificates require the
> issuer to establish parallel identity and attribute certification
> hierarchies.=20
=20
No.  The X.509 AC model allows (but does not require) parallel =
certification
"hierarchies" (I use quotes because there need not be a multi-level
hierarchy either; a single authority directly issuing end entity
certificates is consistent with both the model and the syntax of =
X.509).
The SAML model also allows (but does not require) parallel assertion
"hierarchies" -- the authentication authority and the attribute =
authority
may or may not be the same entity.

> The idea that end entity clients would ever implement cross
> certification is bogus.=20
=20
What do you mean by "implement"?  By definition, end entities never =
actually
cross-certify (only authorities do that), so perhaps you simply mean =
that
end entities should never have to understand cross-certification.  If =
so,
fair enough.  But, like SAML, nothing in X.509 forces end entities to
understand cross-certification.  The authorities in both models can
cross-certify or not (depending on the trust model in use in a given
environment), but the existence of protocols such as OCSP and SCVP are =
proof
enough that path validation (including cross-certification, if present) =
can
be delegated to a third party, freeing the end entity from the need to
understand any of these details.

> The idea that end entities are going to implement a
> functioning bifurcated authentication and attribute cross certified
> heterarchy with separate roots of trust is bogus with knobs on.
=20
See my previous response (with knobs on).  The presence of
cross-certification (either on the identity side or the =
attribute/privilege
side) depends on the choice of trust model.  However, this can be
independent from whether or not end entities understand such details =
and are
able to properly process such chains.

> 4) For the specific SAML uses of attribute assertions it is the PDP =
that
> performs the attribute processing and not the enforcement point (i.e. =
the
> device hooking into the system). The important upshot of this is that =
it
> is
> not necessary to standardize implementation of policy languages in =
the end
> entity devices.
=20
X.509 ACs can be implemented using exactly the same model.  I don't
understand you point here.

> 5) SAML does not provide the status management functions of X.509 but =
the
> SAML framework may be readilly extended to support them, not least =
because
> XTASS, the original assertion framework on which SAML is based =
supported
> an
> assertion status mechanism (tier 4).
>=20
> If an attribute statement is simply a statement about a subject the
> chances
> are that a realtime OCSP type system will be much more satisfactory =
than a
> static certificate based system.=20
>=20
Note that "realtime OCSP" systems today are built specifically around =
the
concept of a "static certificate-based system".  OCSP doesn't replace
certificates; it replaces CRLs (at least from the end entity's point of
view).  I don't understand your sentence here.

> The number of accesses within the validity
> interval, the sparseness of the data, etc. is simply to small to make
> certificate issue worthwhile.=20
=20
Fine -- as long as something else is there to provide the integrity and
authenticity.  Relying on the existence (and use!) of underlying secure
transport can be risky.  There's no guarantee that it's there, and if =
it is
there, there's no guarantee that applications will actually use it
correctly.  So, X.509 took the safer route and mandated certificates =
(i.e.,
authority signatures over the payload) for its identity and privilege
information.  SAML (so far) has made this optional and compensated by =
saying
that the potential risks will be discussed in the Bindings or Security
Considerations sections.  Maybe this will turn out to be far-sighted =
and
wise, but maybe it will just come back to bite us.  Who knows?


The bottom line is that there is almost no difference (especially in =
overall
model) between an X.509 attribute certificate and a SAML attribute
assertion.  The way they are used, the requirements on the end entity, =
the
presence or absence of cross-certification, etc., can all be identical =
in
any given environment or deployment.  X.509 is perhaps more general in =
that
its syntax and descriptive text explicitly discuss how delegation and
cross-certification can be accomplished, but these are no more mandated =
in
X.509 than they are in SAML.

Carlisle.


------_=_NextPart_001_01C13C95.96DE76C0
Content-Type: text/html;
	charset="iso-8859-7"
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-7">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: XACML OID tag?</TITLE>
</HEAD>
<BODY>

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

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Forgive me =
if this sounds a bit harsh, but I do wish that some of the critics of =
the attribute certificate portion of the X.509 specification were more =
familiar with its contents.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">I have no =
real interest in entering into a long thread on this topic, but I have =
embedded some responses below (just for the sake of =
clarification).</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>
<BR>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Bob =
Jueneman[SMTP:[e-mail]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Thursday, September 13, 2001 1:12 =
PM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[e-mail]; [e-mail]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">RE: XACML OID tag?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Phillip,</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">(...some =
text deleted...)</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">I do agree completely with your =
eloquent and highly descriptive &quot;bogus with knobs on&quot; =
characterization of a parallel, cross-certified identity and =
authorization certificate structure, with multiple trust roots for each =
attribute =AF such a concept is completely infeasible, and not worth =
even thinking about.</FONT></P>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">(...more =
text deleted...)</FONT>
</P>
<BR>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;&gt;&gt; &quot;Hallam-Baker, =
Phillip&quot; &lt;[e-mail]&gt; 09/13/01 09:37AM =
&gt;&gt;&gt;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Some responses to Bob's points and =
others.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">(...even =
more text deleted...)</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">3) Although SAML attribute assertions =
are similar to X509.v3 attribute</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">certificates there are significant =
differences in the models. With attribute</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">certificates the model is of issuing =
static pieces of data that have long</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">validity intervals (days at least). =
</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">No.&nbsp; =
The fact that a validity period is present in the certificate does not =
mean that the interval must be long (&quot;days at least&quot;).&nbsp; =
A validity period can obviously be for any length of time (even =
seconds).&nbsp; SAML assertions also have validity periods.&nbsp; In =
both X.509 and SAML the model is flexible and accommodates long-lived =
and short-lived ACs/assertions.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">The attribute certificates require =
the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">issuer to establish parallel identity =
and attribute certification</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">hierarchies. </FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">No.&nbsp; =
The X.509 AC model allows (but does not require) parallel certification =
&quot;hierarchies&quot; (I use quotes because there need not be a =
multi-level hierarchy either; a single authority directly issuing end =
entity certificates is consistent with both the model and the syntax of =
X.509).&nbsp; The SAML model also allows (but does not require) =
parallel assertion &quot;hierarchies&quot; -- the authentication =
authority and the attribute authority may or may not be the same =
entity.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">The idea that end entity clients would =
ever implement cross</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">certification is bogus. </FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">What do =
you mean by &quot;implement&quot;?&nbsp; By definition, end entities =
never actually cross-certify (only authorities do that), so perhaps you =
simply mean that end entities should never have to understand =
cross-certification.&nbsp; If so, fair enough.&nbsp; But, like SAML, =
nothing in X.509 forces end entities to understand =
cross-certification.&nbsp; The authorities in both models can =
cross-certify or not (depending on the trust model in use in a given =
environment), but the existence of protocols such as OCSP and SCVP are =
proof enough that path validation (including cross-certification, if =
present) can be delegated to a third party, freeing the end entity from =
the need to understand any of these details.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">The idea that end entities are going =
to implement a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">functioning bifurcated authentication =
and attribute cross certified</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">heterarchy with separate roots of =
trust is bogus with knobs on.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">See my =
previous response (with knobs on).&nbsp; The presence of =
cross-certification (either on the identity side or the =
attribute/privilege side) depends on the choice of trust model.&nbsp; =
However, this can be independent from whether or not end entities =
understand such details and are able to properly process such =
chains.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">4) For the specific SAML uses of =
attribute assertions it is the PDP that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">performs the attribute processing and =
not the enforcement point (i.e. the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">device hooking into the system). The =
important upshot of this is that it is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">not necessary to standardize =
implementation of policy languages in the end</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">entity devices.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">X.509 ACs =
can be implemented using exactly the same model.&nbsp; I don't =
understand you point here.</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">5) SAML does not provide the status =
management functions of X.509 but the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">SAML framework may be readilly =
extended to support them, not least because</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">XTASS, the original assertion =
framework on which SAML is based supported an</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">assertion status mechanism (tier =
4).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">If an attribute statement is simply a =
statement about a subject the chances</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">are that a realtime OCSP type system =
will be much more satisfactory than a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">static certificate based system. =
</FONT>
</P>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Note that =
&quot;realtime OCSP&quot; systems today are built specifically around =
the concept of a &quot;static certificate-based system&quot;.&nbsp; =
OCSP doesn't replace certificates; it replaces CRLs (at least from the =
end entity's point of view).&nbsp; I don't understand your sentence =
here.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">The number of accesses within the =
validity</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">interval, the sparseness of the data, =
etc. is simply to small to make</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">certificate issue worthwhile. </FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Fine -- =
as long as something else is there to provide the integrity and =
authenticity.&nbsp; Relying on the existence (and use!) of underlying =
secure transport can be risky.&nbsp; There's no guarantee that it's =
there, and if it is there, there's no guarantee that applications will =
actually use it correctly.&nbsp; So, X.509 took the safer route and =
mandated certificates (i.e., authority signatures over the payload) for =
its identity and privilege information.&nbsp; SAML (so far) has made =
this optional and compensated by saying that the potential risks will =
be discussed in the Bindings or Security Considerations sections.&nbsp; =
Maybe this will turn out to be far-sighted and wise, but maybe it will =
just come back to bite us.&nbsp; Who knows?</FONT></P>
<BR>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">The bottom =
line is that there is almost no difference (especially in overall =
model) between an X.509 attribute certificate and a SAML attribute =
assertion.&nbsp; The way they are used, the requirements on the end =
entity, the presence or absence of cross-certification, etc., can all =
be identical in any given environment or deployment.&nbsp; X.509 is =
perhaps more general in that its syntax and descriptive text explicitly =
discuss how delegation and cross-certification can be accomplished, but =
these are no more mandated in X.509 than they are in SAML.</FONT></P>

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

</BODY>
</HTML>
------_=_NextPart_001_01C13C95.96DE76C0--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8DKi1x10275 for ietf-pkix-bks; Thu, 13 Sep 2001 13:44:01 -0700 (PDT)
Received: from johnson.mail.mindspring.net (johnson.mail.mindspring.net [207.69.200.177]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8DKhxD10271 for <[e-mail]>; Thu, 13 Sep 2001 13:43:59 -0700 (PDT)
Received: from ASN-1.com (user-2ivf7lj.dialup.mindspring.com [165.247.158.179]) by johnson.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id QAA25130; Thu, 13 Sep 2001 16:43:53 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 13 Sep 2001 16:41:52 -0400
From: Phil Griffin <[e-mail]>
Organization: Griffin Consulting
X-Mailer: Mozilla 4.73 [en]C-{C-UDP; EBM-SONY1}  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: pkix <[e-mail]>, Mike Myers <[e-mail]>
Subject: Re: Clarification request on RFC 2560
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>

Denis Pinkas wrote:
> 
> In RFC 2560 section 4.2.1 (OCSP Response), we have
> 
> BasicOCSPResponse       ::= SEQUENCE {
>       tbsResponseData      ResponseData,
>       signatureAlgorithm   AlgorithmIdentifier,
>       signature            BIT STRING,
>       certs                [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
> 
> Usually every ASN1 field is explained, but in that document the certs field
> is not explained.
> 
> Should that optional field be interpreted to carry a sequence of possibly
> useful certificates ?
> 
> Denis

That might be nice, but the big defect in this
ASN.1 is that there are two more or less "optional"
cases. One is when there are zero values of type 
Certificate, and the other when the OPTIONAL "certs"
component is absent. 

This could be fixed by defining or importing a type

   Certificates ::= SEQUENCE SIZE(1..MAX) OF Certificate

and changing the definition of type BasicOCSPResponse
to 

   BasicOCSPResponse       ::= SEQUENCE {
      tbsResponseData      ResponseData,
      signatureAlgorithm   AlgorithmIdentifier,
      signature            BIT STRING,
      certs                [0] EXPLICIT Certificates OPTIONAL
   }
 
This would also provide better semantic meaning when a
value of type "BasicOCSPResponse" was defined in a user
application using the new ASN.1 XML Value Notation.

Phil Griffin


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8DJxJ109470 for ietf-pkix-bks; Thu, 13 Sep 2001 12:59:19 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8DJxID09466 for <[e-mail]>; Thu, 13 Sep 2001 12:59:18 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id f8DJttc08696 for <[e-mail]>; Thu, 13 Sep 2001 15:55:55 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 13 Sep 2001 15:53: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: IETF-PKIX <[e-mail]>
Subject: Re: Removing expired certificates from CRLs.....
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-H-S-Loop-Check-Ejzfr: 
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,

To understand the broad assumptions more clearly, can you clarify the
distinction you see between "periodic" information and "on-demand class
timeliness" information?

An RFC 2560 OCSP response contains a "producedAt" field.  Is there any
specific time beyond which a consumer should consider an OCSP response
produced at a certain time to be stale or potentially replayed?

1. If not, what prevents the consumer from relying on out-of-date
"on-demand class" information?  Why would that prevention mechanism
not be equally applicable to CRLs that were produced immediately upon
each update to the revocation database?

2. If there is a specific timeliness requirement, why would periodic
CRLs generated more frequently than the requirement not be considered
to have "on-demand class timeliness"?

In other words, there are three possible signing strategies:
timer based (periodic), revocation event based, and query based.
There are two response data structures: CRL and OCSP.
Each of the two data structures can be generated using each of
the three signing strategies.

If you have some particular system-level issues, they would seem
to be more related to the choice of signing strategy than
the choice of data structure.  For any meaning of "on-demand", and
for every choice of partition size (number of in-scope certificates
per response), a CRL can be as timely as, and is definitely much
smaller than, the equivalent OCSP request and response.  What issues
do you see that could not be solved most efficiently by using CRLs
in a manner different from the traditional infrequent-update,
big-partition mode?

Dave



Michael Myers wrote:
> 
> Denis,
> 
> Thank you for your consideration of historic aspect of digital signatures.
> I'm sure more work remains to be done in this area.  I for one however
> remain more concerned of our broad assumptions regarding the use of periodic
> CRLs as the basis for aperiodic OCSP-based services that deliver on-demand
> class timeliness.  Several systems-level issues are under-explored in this
> context.  Within closed environments there might exist data exchange
> mechanisms that are fully responsive to the security requirements CRLs
> satisfy but do so in a means that enables not only the timely inter-domain
> exchange of revocation status, but validation status as well.
> 
> Mike


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8DJVvR09127 for ietf-pkix-bks; Thu, 13 Sep 2001 12:31:57 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8DJVtD09123; Thu, 13 Sep 2001 12:31:55 -0700 (PDT)
Received: from cspa06.nist.gov (cspa06.ncsl.nist.gov [129.6.54.23]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id PAA09954; Thu, 13 Sep 2001 15:31:56 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 13 Sep 2001 15:30:38 -0400
To: [e-mail], [e-mail]
From: Michael Chernick <[e-mail]>
Subject: Reminder - Draft NIST S/MIME Profile - Comment Period Ends Soon
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_1829360==_.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>

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

A Reminder.

At the SMIME session at the London IETF meeting, it was suggested that
NIST extend the deadline for comments on the Draft NIST S/MIME V3 Client
Profile.  Also, it was suggested that this notice be sent to the PKIX list
as well as the SMIME list. The deadline for comments was extended
until 17 September 2001.  THIS DATE IS FAST APPROACHING.
(NEXT WEEK.)

Thanks,
   Mike Chernick


Here's the original  announcement sent out
by Tim Polk on Monday, 2 July 2001 to the SMIME list.

---------Original Message Sent by Tim Polk to SMIME List on 2 July---------
FYI,

I have attached below the announcement for a recently released NIST draft
document concerning S/MIME V3. The document is intended to define an
appropriate subset of the S/MIME standards for broad application in the U.S.
Federal Government. NIST will be supporting this document through the
development of an automated conformance testing tool. We hope the deployment
of this tool will ease the development of conformant S/MIME V3 clients!

We are very interested in comments from both developers and the user
community. Please take the time to review the draft profile and NIST's plans
for the automated testing facility. We would appreciate comments on the
profile by 17 August 2001 (now extended to 17 September). Please send
comments to Mike Chernick (NIST's S/MIME project leader) at 
<[e-mail]>.

BTW, Mike will be presenting an overview of this project in the S/MIME WG
during the London IETF meeting. Both Mike and I will be there all week, and
will be available to discuss this project.

Thanks!

Tim Polk

----------------------
The U.S. National Institute of Standards and Technology (NIST) has recently
released a draft S/MIME V3 Client Profile. This profile was produced as
guidance in the development and procurement of commercial-off-the-shelf (COTS)
S/MIME-compliant products. This profile document identifies requirements for a
secure and interoperable S/MIME V3 client implementation. The profile cites
requirements for sending and receiving both signed and encrypted messages, as
well as requirements for signed receipt processing.

Although the S/MIME specifications were designed to promote interoperable
secure electronic mail, implementations may support different optional 
services
and the specifications may unintentionally allow multiple interpretations. 
As a
result, different implementations of S/MIME may not be fully interoperable or
provide the desired level of security. Conformance to this proposed profile
will help to assure that S/MIME implementations will be able to interoperate
and provide reasonable security assurance to users.

The Draft Profile is available (in PDF format) for public comment at:
http://csrc.ncsl.nist.gov/pki/smime/draft_SMIMEProfile.pdf

Comments are requested by (**was 17 August 2001**) *****NOW EXTENDED TO
17 September 2001***** and should be sent to [e-mail].

NIST is developing tests and testing tools to determine the level of
conformance of an S/MIME V3 client implementation with this profile. It is
planned that within the next several months, NIST will have a remote testing
facility on-line which will allow S/MIME V3 messages to be sent to the NIST
test site for processing to determine if the remotely generated messages
conform to the profile. In addition, messages may be sent to the test site to
cause the NIST site to emit S/MIME V3 messages so that a remote system may
receive S/MIME V3 messages, and verify that remote system can process the
messages correctly.

Further information on the NIST S/MIME Program may be obtained at
http://csrc.ncsl.nist.gov/pki/smime/welcome.htm or by
contacting Michael Chernick at <[e-mail]>.


----------------------------------------------------------------------------------
C. Michael Chernick
[phone]   [e-mail]
Computer Security Division
National Institute of Standards and Technology (NIST)
----------------------------------------------------------------------------------


--=====================_1829360==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
A Reminder.<br>
<br>
At the SMIME session at the London IETF meeting, it was suggested that
<br>
NIST extend the deadline for comments on the Draft NIST S/MIME V3 Client
<br>
Profile.&nbsp; Also, it was suggested that this notice be sent to the
PKIX list <br>
as well as the SMIME list. The deadline for comments was extended <br>
until 17 September 2001.&nbsp; THIS DATE IS FAST APPROACHING.&nbsp; 
<br>
(NEXT WEEK.)<br>
<br>
Thanks, <br>
&nbsp; Mike Chernick<br>
<br>
<br>
Here's the original&nbsp; announcement sent out <br>
by Tim Polk on Monday, 2 July 2001 to the SMIME list. <br>
<br>
---------Original Message Sent by Tim Polk to SMIME List on 2
July--------- <br>
FYI,<br>
<br>
I have attached below the announcement for a recently released NIST draft
<br>
document concerning S/MIME V3. The document is intended to define an
<br>
appropriate subset of the S/MIME standards for broad application in the
U.S. <br>
Federal Government. NIST will be supporting this document through the
<br>
development of an automated conformance testing tool. We hope the
deployment <br>
of this tool will ease the development of conformant S/MIME V3
clients!<br>
<br>
We are very interested in comments from both developers and the user
<br>
community. Please take the time to review the draft profile and NIST's
plans <br>
for the automated testing facility. We would appreciate comments on the
<br>
profile by 17 August 2001 (now extended to 17 September). Please send
<br>
comments to Mike Chernick (NIST's S/MIME project leader) at
&lt;[e-mail]&gt;.<br>
<br>
BTW, Mike will be presenting an overview of this project in the S/MIME WG
<br>
during the London IETF meeting. Both Mike and I will be there all week,
and <br>
will be available to discuss this project.<br>
<br>
Thanks!<br>
<br>
Tim Polk<br>
<br>
----------------------<br>
The U.S. National Institute of Standards and Technology (NIST) has
recently <br>
released a draft S/MIME V3 Client Profile. This profile was produced as
<br>
guidance in the development and procurement of commercial-off-the-shelf
(COTS) <br>
S/MIME-compliant products. This profile document identifies requirements
for a <br>
secure and interoperable S/MIME V3 client implementation. The profile
cites <br>
requirements for sending and receiving both signed and encrypted
messages, as <br>
well as requirements for signed receipt processing.<br>
<br>
Although the S/MIME specifications were designed to promote interoperable
<br>
secure electronic mail, implementations may support different optional
services <br>
and the specifications may unintentionally allow multiple
interpretations. As a <br>
result, different implementations of S/MIME may not be fully
interoperable or <br>
provide the desired level of security. Conformance to this proposed
profile <br>
will help to assure that S/MIME implementations will be able to
interoperate <br>
and provide reasonable security assurance to users.<br>
<br>
The Draft Profile is available (in PDF format) for public comment at:
<br>
<font color="#0000FF"><u><a href="http://csrc.ncsl.nist.gov/pki/smime/draft_SMIMEProfile.pdf" eudora="autourl">http://csrc.ncsl.nist.gov/pki/smime/draft_SMIMEProfile.</a><a href="http://csrc.ncsl.nist.gov/pki/smime/draft_SMIMEProfile.pdf" eudora="autourl">pdf<br>
<br>
</a></u></font>Comments are requested by (**was 17 August 2001**)
*****NOW EXTENDED TO <br>
17 September 2001***** and should be sent to [e-mail].<br>
<br>
NIST is developing tests and testing tools to determine the level of
<br>
conformance of an S/MIME V3 client implementation with this profile. It
is <br>
planned that within the next several months, NIST will have a remote
testing <br>
facility on-line which will allow S/MIME V3 messages to be sent to the
NIST <br>
test site for processing to determine if the remotely generated messages
<br>
conform to the profile. In addition, messages may be sent to the test
site to <br>
cause the NIST site to emit S/MIME V3 messages so that a remote system
may <br>
receive S/MIME V3 messages, and verify that remote system can process the
<br>
messages correctly.<br>
<br>
Further information on the NIST S/MIME Program may be obtained at <br>
<font color="#0000FF"><u><a href="http://csrc.ncsl.nist.gov/pki/smime/welcome.htm" eudora="autourl">http://csrc.ncsl.nist.gov/pki/smime/welcome.</a><a href="http://csrc.ncsl.nist.gov/pki/smime/welcome.htm" eudora="autourl">htm</a></u></font>
or by <br>
contacting Michael Chernick at &lt;[e-mail]&gt;.<br>
<br>
<x-sigsep><p></x-sigsep>
----------------------------------------------------------------------------------<br>
C. Michael Chernick<br>
[phone]&nbsp;&nbsp; [e-mail]<br>
Computer Security Division <br>
National Institute of Standards and Technology (NIST)<br>
----------------------------------------------------------------------------------<br>
<br>
</html>

--=====================_1829360==_.ALT--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8DIREH07832 for ietf-pkix-bks; Thu, 13 Sep 2001 11:27:14 -0700 (PDT)
Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8DIRDD07828 for <[e-mail]>; Thu, 13 Sep 2001 11:27:13 -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.3) with SMTP id f8DIR6Q27229; Thu, 13 Sep 2001 11:27:06 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "IETF-PKIX" <[e-mail]>
Subject: RE: Removing expired certificates from CRLs.....
Date: Thu, 13 Sep 2001 11:25:44 -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
In-Reply-To: <[e-mail]>
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>

Denis,

Thank you for your consideration of historic aspect of digital signatures.
I'm sure more work remains to be done in this area.  I for one however
remain more concerned of our broad assumptions regarding the use of periodic
CRLs as the basis for aperiodic OCSP-based services that deliver on-demand
class timeliness.  Several systems-level issues are under-explored in this
context.  Within closed environments there might exist data exchange
mechanisms that are fully responsive to the security requirements CRLs
satisfy but do so in a means that enables not only the timely inter-domain
exchange of revocation status, but validation status as well.

Mike



> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Denis Pinkas
> Sent: Thursday, September 13, 2001 1:31 AM
> To: Michael Myers
> Cc: IETF-PKIX
> Subject: Re: Removing expired certificates from CRLs.....
>
>
>
> Michael,
>
> > Denis,
> >
> > What are your thoughts on the timeliness characteristic between OCSP and
> > CRLs?
>
> Well ...
>
> I must admit that the definition of the archive cutofff (section
> 4.4.4) from
> RFC 2560 has always been very strange for me, since it defines a time
> interval rather then an absolute time. I read several times the text and
> could not figure out how in practice it would be used.
>
> The text talks about a retention interval without saying
> explictly to which
> event it is relative to.
>
> Is it the time interval beyond the notAfter date from a certificate ?
> The text does not say so.
>
> In addition, the text is talking, as an example, of a retention
> interval of
> 7 years (!) whereas in the context of that thread we are only talking of
> about a month.
>
> If I had to define from scratch the extension I would simply define an
> absolute date (e.g. called ExtendedRevocationInformationDate, quite a
> long name, but explicit) that could directly override the notAfter field
> from the Validity field of a certificate. This would mean that this
> extension allows to know until when the revocation information is
> maintained. It is not directly related to the produceAt time. The only
> condition is that, when it is present, it is always later than produceAt.
>
> This is a problem because, if I understand correctly RC 2560, we have the
> following equation:
>
> ArchiveCutoff = producedAt - retention interval.
>
> I do not see a clear relationship between these two concepts.
>
> Unless you see one, it would mean that an extension different from
> ArchiveCutoff would be necessary for OCSP responses so that we can have
> identical concepts for CRLs and OCSP responses.
>
> Thanks for raising the question.
>
> Denis
>
> > Mike
> >
> > Michael Myers
> > t: +415.819.1362
> > e: mailto:[e-mail]
> > w: http://www.traceroutesecurity.com
> >
> > > -----Original Message-----
> > > From: Denis Pinkas [mailto:[e-mail]]
> > > Sent: Wednesday, September 12, 2001 12:35 AM
> > > To: Michael Myers
> > > Cc: IETF-PKIX
> > > Subject: Re: Removing expired certificates from CRLs.....
> > >
> > >
> > >
> > > > All,
> > > >
> > > > I think a unique extension creates the least impact.
> > > >
> > > > More broadly though, what's really bothering me is my sense
> that we're
> > > > backing into the notion of a 1-1 between CRLs and online status
> > > mechanisms.
> > > >
> > > > Assume an environment that both publishes CRLs and offers OCSP-based
> > > > services against the same set of certificates.  What if:
> > > >
> > > > a) The CA receives a revocation request at T1;
> > > >
> > > > b) A database state variable is flipped at T1+N;
> > > >
> > > > c) An OCSP request is received at T1+N+M;
> > > >
> > > > d) An OCSP response is transmitted at T1+N+M+K;
> > > >
> > > > e) Yet the next CRL cycle won't run (i.e. the cron
> > > >    job won't fire) until T1+X where X >> (N+M+K).
> > > >
> > > > Thus relying parties are enabled to pick and choose between
> CRLs or OCSP
> > > > depending on how it might benefit their argument for remedy
> > > under digital
> > > > signature laws.
> > > >
> > > > Thoughts, anyone?
> > >
> > > Some validation policies, like Signature policies are able to
> say whether
> > > CRLs or OCSP responses shall be used.
> > >
> > > As an example see: draft-ietf-smime-espolicies-01.txt
> > >
> > > EnuRevReq  ::= ENUMERATED {
> > >       clrCheck        (0),
> > >                    --Checks must be made against current CRLs
> > >                  -- (or authority revocation lists (ARL))
> > >       ocspCheck       (1), -- The revocation status must be checked
> > >                   -- using the Online Certificate Status Protocol
> > >                   -- (OCSP),RFC 2450.
> > >       bothCheck       (2),
> > >                   -- Both CRL and OCSP checks must be carried out
> > >       eitherCheck     (3),
> > >                   -- At least one of CRL or OCSP checks must be
> > >                   -- carried out
> > >       noCheck         (4),
> > >                   -- no check is mandated
> > >       other           (5)
> > >                   -- Other mechanism as defined by signature policy
> > >                   -- extension
> > >         }
> > >
> > > If either CRL (i.e.clrCheck) or OCSP (i.e. ocspCheck) is
> mandated, then
> > > there is no conflict between the two mechanisms.
> > >
> > > Denis
> > >
> > >
> > > > Mike
> > > >
> > > > Michael Myers
> > > > t: +415.819.1362
> > > > e: mailto:[e-mail]
> > > > w: http://www.traceroutesecurity.com g
> > >
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8DHXxa07023 for ietf-pkix-bks; Thu, 13 Sep 2001 10:33:59 -0700 (PDT)
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8DHXvD07019 for <[e-mail]>; Thu, 13 Sep 2001 10:33:57 -0700 (PDT)
Received: from vhqpostal-gw2.verisign.com (mailer2.verisign.com [65.205.251.56]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id f8DHV6m01537; Thu, 13 Sep 2001 10:31:06 -0700 (PDT)
Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id <R514XLZ7>; Thu, 13 Sep 2001 10:33:54 -0700
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'Bob Jueneman'" <[e-mail]>, [e-mail], "Hallam-Baker, Phillip" <[e-mail]>
Subject: RE: XACML OID tag?
Date: Thu, 13 Sep 2001 10:33:47 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C13C7A.3E615F50"
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_000_01C13C7A.3E615F50
Content-Type: text/plain;
	charset="iso-8859-7"

> I realize that that scenario doesn't fit the business model 
> of current TTP CAs very well, and at the same time I observe 
> that the do it yourself model of CA toolkits isn't selling 
> very well in the marketplace either.  So I don't know whether 
> that model is really feasible either ? it certainly hasn't 
> done all that well to date.

The key to any complex system is where you put the complexity.

The idea of XKMS and SAML is to put the complexity where it is easily
accessible for maintenance as necessary. The unfortunate side effect of the
'end to end' theology is that too much complexity got embedded into the end
points which cannot be maintained reliably on a day to day basis and once
deployed may be in service for years or decades.

To make an analogy, the XKMS approach is equivalent to putting the access
panel to the compressor on the side of the hot tub, the PKIX approach is
putting the access panel underneath it.

The disadvantage of the SAML/XKMS approach is that it lowers the barrier to
entry for the end point but transfers that cost to the infrastructure. Ten
years ago no party had the necessary capital to invest in the infrastructure
required. Today much of the physical infrastructure is a sunk cost.

To make another analogy, the first electricity companies sold package
generators to individual factories, that model was quickly replaced by the
model in which one large paower station served an entire town and the
capital and maintenance costs were distributed over many more users gaining
economies of scale.


	Phill


------_=_NextPart_000_01C13C7A.3E615F50
Content-Type: application/octet-stream;
	name="Phillip Hallam-Baker (E-mail).vcf"
Content-Disposition: attachment;
	filename="Phillip Hallam-Baker (E-mail).vcf"

BEGIN:VCARD
VERSION:2.1
N:Hallam-Baker;Phillip
FN:Phillip Hallam-Baker (E-mail)
ORG:VeriSign
TITLE:Principal Consultant
TEL;WORK;VOICE:[phone] x227
EMAIL;PREF;INTERNET:[e-mail]
REV:20010214T163732Z
END:VCARD

------_=_NextPart_000_01C13C7A.3E615F50--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8DHAWi06515 for ietf-pkix-bks; Thu, 13 Sep 2001 10:10:32 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8DHATD06506 for <[e-mail]>; Thu, 13 Sep 2001 10:10:29 -0700 (PDT)
Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 13 Sep 2001 11:10:31 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Thu, 13 Sep 2001 11:12:38 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: XACML OID tag?
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-7
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f8DHATD06507
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>

Phillip,

Marshall Rose, back in the NADF days, used to have T-shirts with a picture of a pig with a wooden leg. There was a long-winded story that went with it about how marvelous this life-saving pig was, and the punch line was, "You wouldn't want to eat such a marvelous pig all at once, would you?", referring to the slow deployment of X.500.

That's sort of the way I feel about SAML and all of the X-everything alphabet soup that the standards of the month club is serving up these days (or at least promising to) ¯ I'm not sure that I want to eat that pig all at once.

I was thinking about including something like a SAML assertion (which I had incorrectly understood would be coded in XACML) within an X.509 certificate in order to at least try out some of the XML concepts and compare them to the bit-oriented MAC label approach we have described and partially implemented.  Including them within an X.509 certificate might eventually end up being useful in its own right, or it might be merely a testing crutch or kludge.

I do agree completely with your eloquent and highly descriptive "bogus with knobs on" characterization of a parallel, cross-certified identity and authorization certificate structure, with multiple trust roots for each attribute ¯ such a concept is completely infeasible, and not worth even thinking about.

Having said that, that doesn't ipso facto mean that the SAML approach is necessarily better ¯ it may be or it may not be, and it may even suffer from some of the same problems. That's what I wanted to evaluate before jumping on the band wagon.

I suppose that it greatly depends on the use model that you have in mind.  If you have a retail model in mind, where the user comes to one merchant (or a portal), say 4x4Tires.com, and is then redirected to BigWheels.com that sells stronger wheels for those guys that like to play in the mud, then a very limited duration attribute credential that gives the customer a 10% discount and maybe some kind of a kickback to the referring merchant is appropriate.

On the other hand, if the parts guy at JeepsRUs wants to order some wheels from Daimler-Chrysler, then it isn't at all obvious that he needs to first go to some local SAML server and then be redirected to Daimler with a 5 minute credential in hand.  He could have been issued a semi-permanent certificate/credential containing the necessary entitlements by the dealer (and oh by the way an organizational person identity vouched for by the same dealer), and the dealer's certificate could have either been issued by Daimler or cross-certified by them.  In either case, the duration of that certificate might well last for a year or more, and it isn't at all obvious that an real-time OCSP mechanism is necessary to validate that certificate over and over again.  Cached CRLs would do just fine.

I realize that that scenario doesn't fit the business model of current TTP CAs very well, and at the same time I observe that the do it yourself model of CA toolkits isn't selling very well in the marketplace either.  So I don't know whether that model is really feasible either ¯ it certainly hasn't done all that well to date.

But given the general lack of success (i.e., revenue) in this arena to date, I certainly don't want to launch yet another huge effort on the basis of "if we build it they will come" hope and hype.

I agree with the rest of your comments.

Bob



>>> "Hallam-Baker, Phillip" <[e-mail]> 09/13/01 09:37AM >>>

Some responses to Bob's points and others.

1) There is no OID and if there was I have no idea what the semantics of the
OID would be.

2) The way to link a SAML assertion to a certificate is to use the KeyInfo
element of the SubjectConfirmation field to identify the authentication
credentials of the subject to which the assertion is bound. This may be
either by the Certificate itself, by the certificate serial and issuer or by
the public key parameters.

3) Although SAML attribute assertions are similar to X509.v3 attribute
certificates there are significant differences in the models. With attribute
certificates the model is of issuing static pieces of data that have long
validity intervals (days at least). The attribute certificates require the
issuer to establish parallel identity and attribute certification
hierarchies. The idea that end entity clients would ever implement cross
certification is bogus. The idea that end entities are going to implement a
functioning bifurcated authentication and attribute cross certified
heterarchy with separate roots of trust is bogus with knobs on.

4) For the specific SAML uses of attribute assertions it is the PDP that
performs the attribute processing and not the enforcement point (i.e. the
device hooking into the system). The important upshot of this is that it is
not necessary to standardize implementation of policy languages in the end
entity devices.

5) SAML does not provide the status management functions of X.509 but the
SAML framework may be readilly extended to support them, not least because
XTASS, the original assertion framework on which SAML is based supported an
assertion status mechanism (tier 4).

If an attribute statement is simply a statement about a subject the chances
are that a realtime OCSP type system will be much more satisfactory than a
static certificate based system. The number of accesses within the validity
interval, the sparseness of the data, etc. is simply to small to make
certificate issue worthwhile. 

The intended use for the tier 4 meta-assertion scheme is to manage
assertions that map to negotiable financial instruments.

6) I agree with Hal on the points he made, however remember that the SAML
working group has a very narrow scope. The assertion framework on which SAML
is based was designed as a very general purpose vehicle.

7) We examnined the use of XER encoding at length for a full 6 minutes early
in the design of XTASS/XKMS/SAML/XKASS/XTAML when it was all called TAXI
(Trust Assertion XML Infrastructure). It would be a completely worthless
exercise. There is no intrinsic value in the XML syntax over the X.509 great
enough to outweigh the fact that there is a massive X.509v3/BER installed
base. There is no value therefore in introducing a new PKI syntax unless the
semantics are also changed to allow uses that were not possible before.

8) The idea of canonicalization is broken. It was broken in DER it is still
broken in XML Signature. If you want to be able to check signatures put the
responsibility on the infrastructure not to mess with the bits. The minute
you try to support applications that slightly mangle data you lose big. The
ability to burst a certificate into components and put it in a directory
*and then delete the original* is bogus, was bogus and will remain bogus.

If digital signatures had been implemented in the very first email systems
then gateways would never have got into the idiotic charater set and line
wrapping transformations that break so many messages. That task should
always have been performed by the end client. The reason IP works and many
competitors do not, is that unlike other schemes IP does not mangle the
contents of each packet in transit.

9) If you really wanted to you could use X.509 as a signature envelope for
SAML assertions instead of XML DigSig (which is by the way a joint IETF-W3C
WG). But CMS would appear to be a much easier and simpler solution.
Alternatively you could profile XML-Dig sig, use the minimal c14n etc. to
make implementation trivial.


	Phill



Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
[e-mail] 
781 245 6996 x227

 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8DFbnJ00955 for ietf-pkix-bks; Thu, 13 Sep 2001 08:37:49 -0700 (PDT)
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8DFblD00950 for <[e-mail]>; Thu, 13 Sep 2001 08:37:47 -0700 (PDT)
Received: from vhqpostal-gw1.verisign.com (mailer1.verisign.com [65.205.251.55]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id f8DFZ3m20066; Thu, 13 Sep 2001 08:35:03 -0700 (PDT)
Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2653.19) id <R5GBCGNK>; Thu, 13 Sep 2001 08:37:50 -0700
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'Bob Jueneman'" <[e-mail]>, [e-mail]
Subject: RE: XACML OID tag?
Date: Thu, 13 Sep 2001 08:37:48 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C13C6A.0A68E110"
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_000_01C13C6A.0A68E110
Content-Type: text/plain;
	charset="iso-8859-7"


Some responses to Bob's points and others.

1) There is no OID and if there was I have no idea what the semantics of the
OID would be.

2) The way to link a SAML assertion to a certificate is to use the KeyInfo
element of the SubjectConfirmation field to identify the authentication
credentials of the subject to which the assertion is bound. This may be
either by the Certificate itself, by the certificate serial and issuer or by
the public key parameters.

3) Although SAML attribute assertions are similar to X509.v3 attribute
certificates there are significant differences in the models. With attribute
certificates the model is of issuing static pieces of data that have long
validity intervals (days at least). The attribute certificates require the
issuer to establish parallel identity and attribute certification
hierarchies. The idea that end entity clients would ever implement cross
certification is bogus. The idea that end entities are going to implement a
functioning bifurcated authentication and attribute cross certified
heterarchy with separate roots of trust is bogus with knobs on.

4) For the specific SAML uses of attribute assertions it is the PDP that
performs the attribute processing and not the enforcement point (i.e. the
device hooking into the system). The important upshot of this is that it is
not necessary to standardize implementation of policy languages in the end
entity devices.

5) SAML does not provide the status management functions of X.509 but the
SAML framework may be readilly extended to support them, not least because
XTASS, the original assertion framework on which SAML is based supported an
assertion status mechanism (tier 4).

If an attribute statement is simply a statement about a subject the chances
are that a realtime OCSP type system will be much more satisfactory than a
static certificate based system. The number of accesses within the validity
interval, the sparseness of the data, etc. is simply to small to make
certificate issue worthwhile. 

The intended use for the tier 4 meta-assertion scheme is to manage
assertions that map to negotiable financial instruments.

6) I agree with Hal on the points he made, however remember that the SAML
working group has a very narrow scope. The assertion framework on which SAML
is based was designed as a very general purpose vehicle.

7) We examnined the use of XER encoding at length for a full 6 minutes early
in the design of XTASS/XKMS/SAML/XKASS/XTAML when it was all called TAXI
(Trust Assertion XML Infrastructure). It would be a completely worthless
exercise. There is no intrinsic value in the XML syntax over the X.509 great
enough to outweigh the fact that there is a massive X.509v3/BER installed
base. There is no value therefore in introducing a new PKI syntax unless the
semantics are also changed to allow uses that were not possible before.

8) The idea of canonicalization is broken. It was broken in DER it is still
broken in XML Signature. If you want to be able to check signatures put the
responsibility on the infrastructure not to mess with the bits. The minute
you try to support applications that slightly mangle data you lose big. The
ability to burst a certificate into components and put it in a directory
*and then delete the original* is bogus, was bogus and will remain bogus.

If digital signatures had been implemented in the very first email systems
then gateways would never have got into the idiotic charater set and line
wrapping transformations that break so many messages. That task should
always have been performed by the end client. The reason IP works and many
competitors do not, is that unlike other schemes IP does not mangle the
contents of each packet in transit.

9) If you really wanted to you could use X.509 as a signature envelope for
SAML assertions instead of XML DigSig (which is by the way a joint IETF-W3C
WG). But CMS would appear to be a much easier and simpler solution.
Alternatively you could profile XML-Dig sig, use the minimal c14n etc. to
make implementation trivial.


	Phill



Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
[e-mail]
781 245 6996 x227

 


------_=_NextPart_000_01C13C6A.0A68E110
Content-Type: application/octet-stream;
	name="Phillip Hallam-Baker (E-mail).vcf"
Content-Disposition: attachment;
	filename="Phillip Hallam-Baker (E-mail).vcf"

BEGIN:VCARD
VERSION:2.1
N:Hallam-Baker;Phillip
FN:Phillip Hallam-Baker (E-mail)
ORG:VeriSign
TITLE:Principal Consultant
TEL;WORK;VOICE:[phone] x227
EMAIL;PREF;INTERNET:[e-mail]
REV:20010214T163732Z
END:VCARD

------_=_NextPart_000_01C13C6A.0A68E110--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8DFPuA00738 for ietf-pkix-bks; Thu, 13 Sep 2001 08:25:56 -0700 (PDT)
Received: from michael.checkpoint.com (michael.checkpoint.com [199.203.73.68]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8DFPsD00734 for <[e-mail]>; Thu, 13 Sep 2001 08:25:55 -0700 (PDT)
Received: from earl (localhost [127.0.0.1]) by michael.checkpoint.com (8.9.3/8.9.1) with SMTP id RAA15954; Thu, 13 Sep 2001 17:25:15 +0200 (IST)
From: "Avi Gozlan" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: CMC issue - CA identification
Date: Thu, 13 Sep 2001 18:28:41 +0300
Message-ID: <007901c13c68$c5537190$[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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <000401c13bea$57328800$[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
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>

Jim,

What I would like, is to let the CMC client automatically identify the
self-signed certificate and thus eliminate the manual approval required for
the same purpose.

This operation is suggested to occur as part of the response, to replace the
manual action that sometimes can be done only afterwards, when the chain
with the self-signed certificate arrives in the response.

In the case of RA the same method is used. The RA takes the same buffer of
self-signed certificate as the value to be validated. We need here two
things:

1. Verify that the server, may it be the CA or RA, knows the shared secret.
This may be achieved by creating the HMAC-SHA1 of any agreed upon buffer.
2. Approve the self-signed certificate.

These needs are both achieved by the suggested way.

Avi

-----Original Message-----
From: Jim Schaad [mailto:[e-mail]]
Sent: Thursday, September 13, 2001 3:24 AM
To: 'Avi Gozlan'; [e-mail]
Subject: RE: CMC issue - CA identification


Avi,

Based on the discussion below, I am going to assume that the reason you
want to give the CA the ablitiy to prove it's identity is so that it can
successfully distribute a "Trust Anchor".  Are you suggesting that this
occur before the client sends a certificate request to the CA or that it
be part of the response?

Also how do you think that the identify proof would need to be changed
so that an RA rather than a CA could prove it's identity?

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Avi Gozlan
> Sent: Tuesday, September 11, 2001 12:33 AM
> To: [e-mail]
> Subject: CMC issue - CA identification
>
>
>
> Hello,
>
> CMC supplies the identityProof mechanism, by which a CA can
> immidiately and
> automatically identify a CMC client. However, there are no
> means by which
> the CA identifies itself to the CMC client. According to
> section 4.4 of RFC
> 2797, clients must explicitly approve trust of the included
> self-signed
> certificate.
>
> In the cases where the identityProof machanism is used the
> end entity and
> the CA share a secret. The secret can be used to authenticate
> the reply as
> well as the request.
>
> Following is a proposal that utilizes this mechanism in the reply.
>
> This way of authentication has some advantages:
> - Same strength of authentication on the client side as on the CA side
> - More secure - users are not always familiar with approving
> a CA or its
> fingerprint
> - Easier to use, no user intervention is required for CA
> identification
>
> Is it possible that such an automatic identification proof
> will be added to
> CMC (or descendant)?
>
> Here is the proposal:
>
> 1. The buffer of the self-signed certificate in the
> "certificate" portion of
> the signedData is the value to be validated
> 2. A SHA1 hash of the token is computed.
> 3. An HMAC-SHA1 value is then computed over the value
> produced in Step 1,
> using the hash of the token from Step 2 as the shared secret value
> 4. The 160-bit-HMAC-SHA1 result from Step 3 is then encoded
> as the value of
> the identityProof attribute.
>
> When the client verifies the identityProof attribute, it extracts the
> self-signed certificate from the chain included in the
> "certificate" portion
> of the signedData. It then computes the HMAC-SHA1 value in
> the same way and
> compares it to the identityProof attribute contained in the enrollment
> request.
>
> Thanks,
>
> Avi Gozlan
> PKI team
> Check Point Software Technologies LTD.
>




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8DESm227377 for ietf-pkix-bks; Thu, 13 Sep 2001 07:28:48 -0700 (PDT)
Received: from omicron.at (gw.omicron.at [212.183.10.29]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8DESlD27370 for <[e-mail]>; Thu, 13 Sep 2001 07:28:47 -0700 (PDT)
Received: by gw.omicron.at id <29577>; Thu, 13 Sep 2001 16:29:44 +0200
Message-Id: <[e-mail]>
From: Cristian Marinescu <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: RE: Question about TSP (rfc 3161)
Date: Thu, 13 Sep 2001 16:27:30 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain; charset="windows-1252"
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>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I agree, there is in practice (at least for the moment,
when everyone is trying to put a TSA together, more or less
draft compliant), no reason for having such flags.

But, it is also not stupid.
Let's imagine that some day the TSP will be really used
by everyone.  :)  Hard to imagine, but let's try.
This will rise the problem of DOS attack, and some
people, (as I have done myself) will implement the TSA
and limit the number of parallel requests (and let's understand
by this the number of spawn processes, or threads) to a fix number. So
they will
just return an error back. This is actually not a nice thing
to do. And I presume, people there, writing the draft,
tried to be nice: well, if I get a request, but,
I don't have time to give a response right away, because
I am busy, let's store the request and tell the person to try
again sometimes later. 
Perhaps there is also the possibility
that your clock is at that moment not available, (I would
like to believe that there will be TSA's out there that won't read
the time from the local system, like I do at the moment...) or maybe
some
other resource... how could I know??  :)  
In any case you have to take cautions about the overflooding with
requests (or even pending requests, that havn't been answered yet)

Well, at least this is the reason I can imagine. Perhaps
there are also some other (dark!) reasons, but I would like
to hear/read about them from the TSP gurus. :))

Kindly regards,
Cristian


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Mittwoch, 12. September 2001 10:19
> To: [e-mail]
> Subject: Question about TSP (rfc 3161)
> 
> 
> 
> Hi,
> 
> 
> I would like to know what are the reasons for introducing the 
> flags "pollReq",
> "pollResp" and "negPollRep" in the socket based protocol 
> (section 3.3).
> 
> 
> It would mean that a tsa server can divide the der code he 
> calculated for the
> response. But why would it do that?
> 
> 
> Thanks
> 
> 
> Libel
> 
> 
> -- 
> Get your firstname@lastname email for FREE at 
http://Nameplanet.com/?su

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.0.2i

iQA/AwUBO6C0P8V5iyNCxCiSEQL9aQCg/DF+dzS6QV+dLFvVV6HTNTF3xvgAoOaZ
GSkggGhyqVBA6fFIRTnn+4bu
=FFSm
-----END PGP SIGNATURE-----


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8DDx1E25658 for ietf-pkix-bks; Thu, 13 Sep 2001 06:59:01 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8DDwwD25648 for <[e-mail]>; Thu, 13 Sep 2001 06:58:59 -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 QAA14696; Thu, 13 Sep 2001 16:01:05 +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 PAA14626; Thu, 13 Sep 2001 15:58:23 +0200
Message-ID: <[e-mail]>
Date: Thu, 13 Sep 2001 15:57:55 +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: [e-mail]
CC: [e-mail]
Subject: Re: Comments on RFC3161
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>

Alfonso,
 
> Hi Everyone,
> 
> In my opinion, in a future rfc3161 update, the following parts should
> be corrected .

Since RFC 3161 has just been issued in August 2001, it will not be re-issued
shortly.

> Comment A
> There is an inconsistency between these statements present in section 1:
>  - "It also establishes several security-relevant requirements for TSA
>    operation, with regards to processing requests to generate responses"

>  - "This standard does not establish overall security requirements for
>    TSA operation, just like other PKIX standards do not establish such
>    requirements for CA operation"

This is not inconsistent: "several security-relevant requirements" is
different from "overall security requirements".

> Comment B
> There should be no ambiguity (neither minor) in the scope of TSP.
> 
> In my opinion, it's preferable to say that "The TSA is a TTP that
> creates time-stamp tokens in order to indicate that a datum existed
> _at_ a particular point in time", according to section 2.
> And should be avoided to say that "A time-stamping service supports
> assertions of proof that a datum existed _before_ a particular time",
> as stated several times in section 1.

No. This point has been discussed on the pkix mailing list and the current
text reflects the concensus reached. 

> It's part of the verification phase to understand if a token is subsequent
> or antecedent to another one.
> Comment C
> The part of section 2.4.2:
> 
> rfc3161> In such a case, the ordering of time-stamp tokens issued by
> rfc3161> the same TSA or different TSAs is only possible when the
> rfc3161> difference between the genTime of the first time-stamp token
> rfc3161> and the genTime of the second time-stamp token is greater than
> rfc3161> the sum of the accuracies of the genTime for each time-stamp token.
> 
> should be replaced with:
> In such a case, the ordering of time-stamp tokens issued by
> the same TSA or different TSAs is only possible when the absolute value
> difference between the genTime of the first time-stamp token
> and the genTime of the second time-stamp token is greater than
> the sum of the accuracies of the genTime for each time-stamp token.

It is implicit that such comparisons are made between TSA servers that are
trusted and compliant with the requirements. So adding the word "absolute"
is not necessary in that context.
 
> In fact, when a TSA clock drift outside the declared accuracy 

Hence the TSA becomes non-conformant.

Denis

> it's
> possible to observe time-stamp tokens that have inconsistent genTime
> associated with them (eg. the genTime value of a _first_ time-stamp
> token is grater either than the genTime value of a second token, or
> the sum of the accuracies of the two tokens); please refer to my
> previous message for an example.
> 
> Thanks,
> alfonso


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8DD5xf23284 for ietf-pkix-bks; Thu, 13 Sep 2001 06:05:59 -0700 (PDT)
Received: from zolera.com (IDENT:root@[63.142.188.177]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8DD5wD23280 for <[e-mail]>; Thu, 13 Sep 2001 06:05:58 -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 f8DD6Ga12248; Thu, 13 Sep 2001 09:06:16 -0400
Message-ID: <[e-mail]>
Date: Thu, 13 Sep 2001 09:06:16 -0400
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: pkix <[e-mail]>, Mike Myers <[e-mail]>
Subject: Re: Clarification request on RFC 2560
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>

It's the signer's cert chain.  (Well, not *the* but you get the point.)

-- 
Zolera Systems, Your Key to Online Integrity
Securing Web services: XML, SOAP, Dig-sig, Encryption
http://www.zolera.com


Received: by above.proper.com (8.11.6/8.11.3) id f8DCuP722134 for ietf-pkix-bks; Thu, 13 Sep 2001 05:56:25 -0700 (PDT)
Received: from server.speedcom.it (server.speedcom.it [195.32.69.66]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8DCuND22124 for <[e-mail]>; Thu, 13 Sep 2001 05:56:23 -0700 (PDT)
Received: (from adg@localhost) by server.speedcom.it (0.0.0/0.0.0) id OAA15987 for [e-mail]; Thu, 13 Sep 2001 14:56:22 +0200
Date: Thu, 13 Sep 2001 14:56:21 +0200
From: Alfonso De Gregorio <[e-mail]>
To: [e-mail]
Subject: Comments on rfc3029
Message-ID: <[e-mail]>
Reply-To: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: mymua
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 Everyone,

there are very minor typo errors in rfc3029 (DVCSP),
if they have not been already cought.

In section 9.1 "ccpd" acronym has been mistaken for vpcd.

Similarly, the are several occurences of "vpkc" mistaken
for "cpkc" (eg. in 7.5, 7.6, 8, 9.1).

In 7.2 there is an extra 'a'.


Thank you for your work,
alfonso


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8DCYBF21495 for ietf-pkix-bks; Thu, 13 Sep 2001 05:34:11 -0700 (PDT)
Received: from server.speedcom.it (server.speedcom.it [195.32.69.66]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8DCY9D21491 for <[e-mail]>; Thu, 13 Sep 2001 05:34:10 -0700 (PDT)
Received: (from adg@localhost) by server.speedcom.it (0.0.0/0.0.0) id OAA15888 for [e-mail]; Thu, 13 Sep 2001 14:34:09 +0200
Date: Thu, 13 Sep 2001 14:34:09 +0200
From: Alfonso De Gregorio <[e-mail]>
To: [e-mail]
Subject: multiple time-stamp tokens and untrusting certain users
Message-ID: <[e-mail]>
Reply-To: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: mymua
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 Everyone,

what about to add to a future update of rfc3161 examples of how
a TSA users can produce multiple time-stamp tokens of the same
message imprint?

Similarly with what described in draft-ietf-smime-esformats-04.txt,
time-stamp request can be (obviously) requested in independent 
way from multiple TSAs. Additionally, it would be nice to have
an example of a chained time-stamp request/responses.

 h = hash(doc);
 TSA1TimeStampReq.messageImprint = h;
 h2 = hash(TSA1ResponseToken);
 TSA2TimeStampReq.messageImprint = h2;
 TSA2ResponseToken.TSTInfo.messageImprint = h2;
 ...
 TSAnResponseToken.TSTInfo.messageImprint = hn;



- Untrusting the relation between a specific user (eg. TSA developer,
  administrator, owner) and a TSA.

This expedient can be helpful while proving the absence of collusion
between a user and a particular TSAs. Assuming that the same user
cannot collude with and arbitrary long series on TSAs.

A user in fact, can collude with a TSA to let a false genTime be applied 
to the time-stamp request. This mechanism prevents the generation
of successive or antecedents time-stamps for selected users.

(in my opinion, in future documents should be addressed also the issues
regarding certain potential TTP users and the associated TTPs -
Did you can trust a notary that claims to be the author of a document 
and that want give proof of his authorship throw a deed signed 
by itself? :-) )

Regards,
alfonso



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8DCW4l21447 for ietf-pkix-bks; Thu, 13 Sep 2001 05:32:04 -0700 (PDT)
Received: from server.speedcom.it (server.speedcom.it [195.32.69.66]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8DCW1D21443 for <[e-mail]>; Thu, 13 Sep 2001 05:32:02 -0700 (PDT)
Received: (from adg@localhost) by server.speedcom.it (0.0.0/0.0.0) id OAA15877 for [e-mail]; Thu, 13 Sep 2001 14:32:01 +0200
Date: Thu, 13 Sep 2001 14:32:01 +0200
From: Alfonso De Gregorio <[e-mail]>
To: [e-mail]
Subject: Notary systems requirements
Message-ID: <[e-mail]>
Reply-To: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: mymua
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 Everyone,

what about to start to working on a document that collects requirements
for notary systems based also on TSAs?

In my opinion, the current TSP don't allows always the use of a
time-stamp token as a proof-of-authorship, because the security
analysis of the protocol don't address the possibility of a 
deliberate replay attack by a middleman replaying legitimate TS
_requests_; the point 6 of section 4 of rfc3161 puts replayed requests 
to TSAs down to problems in the intervening network elements.


An additional middleman attack scenario:

- Alice writes a poem and wants publish it on her own public homepage;
- however, Alice is afraid that, upon the publication, Eve read the poem
  and re-publish it with her (Eve) name.
- Eve, knowing Alice's interest and talent, start to eavesdrop Alice's
  network;

Note: the attack scenario is possible either because the channel between 
      Alice and the TSA does not give necessarily confidentiality, or
      because the are no requirement yet on how Alice must construct the
      message imprint being time-stamped while she wants
      proof-of-authorship on corresponding documents (eg. public available
      documents).

The (simple) attack
- Alice computes the hash of her poem with the preferred hash algorithm
  and sends a TimeStampReq to TSA1 (TSA1Req) where TSA1Req.messageImprint
  is the computed hash value;
- Eve intercept Alice's request an makes a copy of it, TSA1ReqCopy;
  Eve rip the associated messageImprint and computes another 
  TimeStampReq with the same hash for TSA2 (TSA2Req);
  Eve send TSA1ReqCopy to TSA1 and TSA2Req to TSA2; 
  these are request of certification of claimed possession of data;
- Alice is still waiting the time-stamp token; but as we know TSP gives
  no warrants about response time (eg. the tsa can use also smtp...)
- Eve collects the two responses associated with TSA1ReqCopy and TSA2Req
  (TSA1Resp1, TSA2Resp) and keep them secret;
- than Eve sends TSA1Req to TSA1;
- TSA1 receive TSA1Req and process it; this is a replayed request, however
  the time-stamping authority perform only basic checks on the imprint
  being time-stamped, as REQUESTED in points 7 and 8 of section 2.1:

   7.    to examine the OID of the one-way collision resistant hash-
         function and to verify that the hash value length is consistent
         with the hash algorithm.

   8.    not to examine the imprint being time-stamped in any way (other
         than to check its length, as specified in the previous bullet).

- Eve receive the time-stamp token produced by TSA1 (TSA1Resp2) and check 
  if the absolute value of the difference between the genTime of the first 
  time-stamp token (TSA1Resp1) and the genTime of the second time-stamp 
  token (TSA1Resp2) is greater than the sum of the accuracies of the
  genTime for each time-stamp token;
- if the condition is true Eve routes TSA1Resp2 to Alice;
  this is a well-formed and consistent response, but the genTime associated
  with reports a time successive with the one indicated in TSA1Resp1;

- now Eve can make a brute-force attack on the imprint or try to break
  on the Alice's computer, but she prefer to wait the publication of
  the poem on the Alice's personal public homepage :-)
- Eve claim to be the real author of the Alice's poem;
- Eve and Alice show their own time-stamp token in a trial;
- Eve wins.

To avoid this attack, Alice must be required to hash the sign the
document she wants to  time-stamp; compute the hash over the signature
of the signed data and set the messageImprint field of time-stamp
request to the computed value (similarly to what is required in 
Appendix A, for the proof sign creation before corresponding certificate
revocation).

Regards,
alfonso


Received: by above.proper.com (8.11.6/8.11.3) id f8DCV5i21424 for ietf-pkix-bks; Thu, 13 Sep 2001 05:31:05 -0700 (PDT)
Received: from server.speedcom.it (server.speedcom.it [195.32.69.66]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8DCV3D21420 for <[e-mail]>; Thu, 13 Sep 2001 05:31:03 -0700 (PDT)
Received: (from adg@localhost) by server.speedcom.it (0.0.0/0.0.0) id OAA15866 for [e-mail]; Thu, 13 Sep 2001 14:31:02 +0200
Date: Thu, 13 Sep 2001 14:31:02 +0200
From: Alfonso De Gregorio <[e-mail]>
To: [e-mail]
Subject: Comments on RFC3161
Message-ID: <[e-mail]>
Reply-To: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: mymua
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 Everyone,

In my opinion, in a future rfc3161 update, the following parts should
be corrected .

Comment A
There is an inconsistency between these statements present in section 1:
 - "It also establishes several security-relevant requirements for TSA
   operation, with regards to processing requests to generate responses"
 - "This standard does not establish overall security requirements for
   TSA operation, just like other PKIX standards do not establish such
   requirements for CA operation"


Comment B
There should be no ambiguity (neither minor) in the scope of TSP. 

In my opinion, it's preferable to say that "The TSA is a TTP that 
creates time-stamp tokens in order to indicate that a datum existed 
_at_ a particular point in time", according to section 2.
And should be avoided to say that "A time-stamping service supports 
assertions of proof that a datum existed _before_ a particular time",
as stated several times in section 1.   
It's part of the verification phase to understand if a token is subsequent 
or antecedent to another one.


Comment C
The part of section 2.4.2:

rfc3161> In such a case, the ordering of time-stamp tokens issued by 
rfc3161> the same TSA or different TSAs is only possible when the 
rfc3161> difference between the genTime of the first time-stamp token 
rfc3161> and the genTime of the second time-stamp token is greater than 
rfc3161> the sum of the accuracies of the genTime for each time-stamp token.

should be replaced with: 
In such a case, the ordering of time-stamp tokens issued by 
the same TSA or different TSAs is only possible when the absolute value
difference between the genTime of the first time-stamp token 
and the genTime of the second time-stamp token is greater than 
the sum of the accuracies of the genTime for each time-stamp token.

In fact, when a TSA clock drift outside the declared accuracy it's
possible to observe time-stamp tokens that have inconsistent genTime
associated with them (eg. the genTime value of a _first_ time-stamp 
token is grater either than the genTime value of a second token, or
the sum of the accuracies of the two tokens); please refer to my 
previous message for an example.

Thanks,
alfonso


Received: by above.proper.com (8.11.6/8.11.3) id f8DCUFb21398 for ietf-pkix-bks; Thu, 13 Sep 2001 05:30:15 -0700 (PDT)
Received: from server.speedcom.it (server.speedcom.it [195.32.69.66]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8DCUDD21394 for <[e-mail]>; Thu, 13 Sep 2001 05:30:13 -0700 (PDT)
Received: (from adg@localhost) by server.speedcom.it (0.0.0/0.0.0) id OAA15833 for [e-mail]; Thu, 13 Sep 2001 14:30:02 +0200
Date: Thu, 13 Sep 2001 14:30:01 +0200
From: Alfonso De Gregorio <[e-mail]>
To: [e-mail]
Subject: Untrusting a Trusted Third Party: TSA.
Message-ID: <[e-mail]>
Reply-To: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: mymua
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 Everyone,

The following consideration is quite obvious; however, it's intriguing
to see how the TSP allows a user to perform a simple test against a
TSA that he doesn't trust anymore.

Assume a user is afraid that a TSA is issuing time-stamp tokens while
not in synchronization with UTC; after all if a TSA use a trustworthy 
source of time and include a trustworthy time value for each time-stamp 
token is not necessarily ensuring that the clock doesn't drift outside
the declared accuracy (this is addressed in ETSI - STF 178-T1 draft H).

The test 
The ordering of time-stamp tokens issued by different TSAs is only
possible when the _absolute value_ (*) of the difference between the
genTime of the first time-stamp token and the genTime of the second
time-stamp token is greater than the sum of the accuracies of the
genTime for each time-stamp token.

*) partially contrarywise to what is asserted in section 2.4.2 of rfc3161.

TSA-1: the tsa not trusted anymore by alice 
TSA-2..TSA-3: tsa still trusted by alice

1. Alice send a TimeStampReq to TSA-1 (TSA1Req) where 
   TimeStampReq.messageImprint is simply an hash of a document kept
   secret (Alice_doc);
2. Upon receiving the response (TSA1Response), Alice hash the received 
   time-stamp token ( hash(TSA1Response) ) and send as quickly as possible
   a time-stamp request to TSA2 (TSA2Req), where 
   TimeStampReq.messageImprint is hash(TSA1Response);
3. if the absolute value of the difference of the first time-stamp token 
   and the genTime of the second time-stamp token ( abs(x) ) is greater 
   than the sum of the accuracies of the genTime for each time-stamp 
   token, Alice can order the two tokens; but for a positive value of
   the difference we have a consistent chain of time-stamp 
   request/response, and for a negative a contradictory result.

  x = TSA2Response.genTime - TSA1Response.genTime;
  while abs( x ) > (TSA2Response.accuracy + TSA1Response.accuracy)
	if  x > 0 --> TSA2Resoponse follows TSA1Response
	if  x < 0 --> TSA2Response is _antecedents_ to TSA1Response 
                      
   Alice can prove the opposite showing the chained sequence of time-stamp 
   requests:
	a. Alice_doc
	b. TSA1Response.TSTInfo.messageImprint = hash(Alice_doc)
	c. TSA2Response.TSTInfo.messageImprint(hash(TSA1Response))


Sincerely,
alfonso


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8DAKkd14699 for ietf-pkix-bks; Thu, 13 Sep 2001 03:20:46 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8DAKjD14690 for <[e-mail]>; Thu, 13 Sep 2001 03:20: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 MAA16974; Thu, 13 Sep 2001 12:22:50 +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 MAA14686; Thu, 13 Sep 2001 12:20:08 +0200
Message-ID: <[e-mail]>
Date: Thu, 13 Sep 2001 12:20:10 +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: pkix <[e-mail]>
CC: Mike Myers <[e-mail]>
Subject: Clarification request on RFC 2560
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>

In RFC 2560 section 4.2.1 (OCSP Response), we have

BasicOCSPResponse       ::= SEQUENCE {
      tbsResponseData      ResponseData,
      signatureAlgorithm   AlgorithmIdentifier,
      signature            BIT STRING,
      certs                [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

Usually every ASN1 field is explained, but in that document the certs field
is not explained.

Should that optional field be interpreted to carry a sequence of possibly
useful certificates ?

Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8D8VO606162 for ietf-pkix-bks; Thu, 13 Sep 2001 01:31:24 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8D8VKD06147 for <[e-mail]>; Thu, 13 Sep 2001 01:31:22 -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 KAA15632; Thu, 13 Sep 2001 10:33:22 +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 KAA10768; Thu, 13 Sep 2001 10:30:36 +0200
Message-ID: <[e-mail]>
Date: Thu, 13 Sep 2001 10:30:38 +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: Michael Myers <[e-mail]>
CC: IETF-PKIX <[e-mail]>
Subject: Re: Removing expired certificates from 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>

Michael,

> Denis,
> 
> What are your thoughts on the timeliness characteristic between OCSP and
> CRLs?

Well ...

I must admit that the definition of the archive cutofff (section 4.4.4) from
RFC 2560 has always been very strange for me, since it defines a time
interval rather then an absolute time. I read several times the text and
could not figure out how in practice it would be used.

The text talks about a retention interval without saying explictly to which
event it is relative to.

Is it the time interval beyond the notAfter date from a certificate ? 
The text does not say so.

In addition, the text is talking, as an example, of a retention interval of
7 years (!) whereas in the context of that thread we are only talking of
about a month.

If I had to define from scratch the extension I would simply define an
absolute date (e.g. called ExtendedRevocationInformationDate, quite a
long name, but explicit) that could directly override the notAfter field
from the Validity field of a certificate. This would mean that this
extension allows to know until when the revocation information is
maintained. It is not directly related to the produceAt time. The only
condition is that, when it is present, it is always later than produceAt.

This is a problem because, if I understand correctly RC 2560, we have the
following equation:

ArchiveCutoff = producedAt - retention interval.

I do not see a clear relationship between these two concepts. 

Unless you see one, it would mean that an extension different from
ArchiveCutoff would be necessary for OCSP responses so that we can have
identical concepts for CRLs and OCSP responses.

Thanks for raising the question.

Denis

> Mike
> 
> Michael Myers
> t: +415.819.1362
> e: mailto:[e-mail]
> w: http://www.traceroutesecurity.com
> 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Wednesday, September 12, 2001 12:35 AM
> > To: Michael Myers
> > Cc: IETF-PKIX
> > Subject: Re: Removing expired certificates from CRLs.....
> >
> >
> >
> > > All,
> > >
> > > I think a unique extension creates the least impact.
> > >
> > > More broadly though, what's really bothering me is my sense that we're
> > > backing into the notion of a 1-1 between CRLs and online status
> > mechanisms.
> > >
> > > Assume an environment that both publishes CRLs and offers OCSP-based
> > > services against the same set of certificates.  What if:
> > >
> > > a) The CA receives a revocation request at T1;
> > >
> > > b) A database state variable is flipped at T1+N;
> > >
> > > c) An OCSP request is received at T1+N+M;
> > >
> > > d) An OCSP response is transmitted at T1+N+M+K;
> > >
> > > e) Yet the next CRL cycle won't run (i.e. the cron
> > >    job won't fire) until T1+X where X >> (N+M+K).
> > >
> > > Thus relying parties are enabled to pick and choose between CRLs or OCSP
> > > depending on how it might benefit their argument for remedy
> > under digital
> > > signature laws.
> > >
> > > Thoughts, anyone?
> >
> > Some validation policies, like Signature policies are able to say whether
> > CRLs or OCSP responses shall be used.
> >
> > As an example see: draft-ietf-smime-espolicies-01.txt
> >
> > EnuRevReq  ::= ENUMERATED {
> >       clrCheck        (0),
> >                    --Checks must be made against current CRLs
> >                  -- (or authority revocation lists (ARL))
> >       ocspCheck       (1), -- The revocation status must be checked
> >                   -- using the Online Certificate Status Protocol
> >                   -- (OCSP),RFC 2450.
> >       bothCheck       (2),
> >                   -- Both CRL and OCSP checks must be carried out
> >       eitherCheck     (3),
> >                   -- At least one of CRL or OCSP checks must be
> >                   -- carried out
> >       noCheck         (4),
> >                   -- no check is mandated
> >       other           (5)
> >                   -- Other mechanism as defined by signature policy
> >                   -- extension
> >         }
> >
> > If either CRL (i.e.clrCheck) or OCSP (i.e. ocspCheck) is mandated, then
> > there is no conflict between the two mechanisms.
> >
> > Denis
> >
> >
> > > Mike
> > >
> > > Michael Myers
> > > t: +415.819.1362
> > > e: mailto:[e-mail]
> > > w: http://www.traceroutesecurity.com g
> >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8D0Nm608350 for ietf-pkix-bks; Wed, 12 Sep 2001 17:23:48 -0700 (PDT)
Received: from femail26.sdc1.sfba.home.com ([24.254.60.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8D0NlD08346 for <[e-mail]>; Wed, 12 Sep 2001 17:23:47 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail26.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010913002345.YVRF12095.femail26.sdc1.sfba.home.com@revelation>; Wed, 12 Sep 2001 17:23:45 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Avi Gozlan'" <[e-mail]>, <[e-mail]>
Subject: RE: CMC issue - CA identification
Date: Wed, 12 Sep 2001 17:23:40 -0700
Message-ID: <000401c13bea$57328800$[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, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2526.0000
In-Reply-To: <002001c13a93$f57ba850$[e-mail]>
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>

Avi,

Based on the discussion below, I am going to assume that the reason you
want to give the CA the ablitiy to prove it's identity is so that it can
successfully distribute a "Trust Anchor".  Are you suggesting that this
occur before the client sends a certificate request to the CA or that it
be part of the response?

Also how do you think that the identify proof would need to be changed
so that an RA rather than a CA could prove it's identity?

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Avi Gozlan
> Sent: Tuesday, September 11, 2001 12:33 AM
> To: [e-mail]
> Subject: CMC issue - CA identification
> 
> 
> 
> Hello,
> 
> CMC supplies the identityProof mechanism, by which a CA can 
> immidiately and
> automatically identify a CMC client. However, there are no 
> means by which
> the CA identifies itself to the CMC client. According to 
> section 4.4 of RFC
> 2797, clients must explicitly approve trust of the included 
> self-signed
> certificate.
> 
> In the cases where the identityProof machanism is used the 
> end entity and
> the CA share a secret. The secret can be used to authenticate 
> the reply as
> well as the request.
> 
> Following is a proposal that utilizes this mechanism in the reply.
> 
> This way of authentication has some advantages:
> - Same strength of authentication on the client side as on the CA side
> - More secure - users are not always familiar with approving 
> a CA or its
> fingerprint
> - Easier to use, no user intervention is required for CA 
> identification
> 
> Is it possible that such an automatic identification proof 
> will be added to
> CMC (or descendant)?
> 
> Here is the proposal:
> 
> 1. The buffer of the self-signed certificate in the 
> "certificate" portion of
> the signedData is the value to be validated
> 2. A SHA1 hash of the token is computed.
> 3. An HMAC-SHA1 value is then computed over the value 
> produced in Step 1,
> using the hash of the token from Step 2 as the shared secret value
> 4. The 160-bit-HMAC-SHA1 result from Step 3 is then encoded 
> as the value of
> the identityProof attribute.
> 
> When the client verifies the identityProof attribute, it extracts the
> self-signed certificate from the chain included in the 
> "certificate" portion
> of the signedData. It then computes the HMAC-SHA1 value in 
> the same way and
> compares it to the identityProof attribute contained in the enrollment
> request.
> 
> Thanks,
> 
> Avi Gozlan
> PKI team
> Check Point Software Technologies LTD.
> 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8CMu5o06800 for ietf-pkix-bks; Wed, 12 Sep 2001 15:56:05 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8CMu3D06796 for <[e-mail]>; Wed, 12 Sep 2001 15:56:03 -0700 (PDT)
Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 12 Sep 2001 16:55:48 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Wed, 12 Sep 2001 16:57:58 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: XACML OID tag?
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_CF9566E4.A8C9B4FB"
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.

--=_CF9566E4.A8C9B4FB
Content-Type: text/plain; charset=ISO-8859-7
Content-Transfer-Encoding: quoted-printable

>Perhaps you are simply looking for an OID to put arbitrary XML in a cert, =
so=20
this response will be overkill, but I believe your message implies a lack =
of=20
understanding of the XML security work currently going on at OASIS (SAML =
and=20
XACML)=20

>XACML is defining the means to express Access Control Policies. I =
don't=20
really see what the semantics of an access control policy in the middle of =
a=20
cert would be.=20
=20
>Perhaps you are thinking of SAML. SAML has Attribute Assertions which =
are=20
almost like Attribute Certs. Also it has Authentication Assertions =
which=20
seem mostly useful in non-PKI environment. Finally there are Authorization=
=20
Decision Assertions, which are likely to be quite specific to a resource =
and=20
short lived. Again it is not clear what putting one in a cert would =
signify=20
exactly.=20
=20
I very well may be confused =AF it certainly wouldn't be the first time!
=20
The last time I looked at SAML, it had "entitlements", but they were an =
unspecified bag of bits, and I was under the impression that the intent =
was for those entitlements to eventually be expressed in XACML.  Since =
XACML hasn't published anything yet, at least to my understanding, I =
done';t know what it would contain. But if you are correct, and XACML is a =
way of expressing an access control POLICY, rather than granting a =
particular user some particular right or capability, then you are right =
=AF including XACML in a certificate wouldn't make much sense. So perhaps =
I need to include the SAML Attribute Assertions instead.
=20
In any case, I'm not quite ready to buy into the necessity of recoding all =
of the infrastructure in XML =AF it just seems like too big a task to bite =
off right now, with less than a solid business case justification (hype =
doesn't count).
=20
So what I was hoping to do was to come half way to the mountain, and play =
around with some XML to learn more about the possible problems =AF get my =
feet wet, so to speak.
=20
Since we have existing support for X.509-based authentication to eDirectory=
 and other applications, putting some XML attributes in the certificate =
would take advantage of that infrastructure, while using XML for the =
attribute assertion would presumably provide a mechanism for supporting =
extranet authentication, assuming the parties agree as to both the name of =
the attribute (easy), and the precise semantics (much harder, generally).

>Of course all can be signed using XMLdsig and thus be consumers of =
PKIX=20
mechanisms. But I am unclear what sort of a use case you have in mind.=20
=20
I don't really want to have to implement XMLdsig at this point in time, as =
I don't see what advantages it provides over existing IETF-standardized =
signature mechanisms.  If I can simply drop the attribute assertions into =
an X.509 certificate issued by the organization that is attesting to the =
attributes (and the user's identity, for what that's worth), then I don't =
have to do anything extra.  XMLdsig seems like politically correct =
overkill, and I can't afford that.

>If you believe X.509 Attribute Certs are broken (as opposed to unused) =
I=20
would like to hear why, since SAML Attribute Assertions are very similar. =
On=20
the other hand, SAML has a lot of other machinery, so perhaps we have=20
already addressed your concerns.=20
=20
I do believe that X.509 attribute certificates are broken, as well as =
unused.  The last time we went through some of those issues on the PKIX =
list, it became apparent that controlling the delegation of attributes =
through a chain of attribute certs was even more difficult than controlling=
 identity assertions via policy constraints, name subordination, etc.  As =
a result, the only uses that I have heard be suggested for attribute certs =
used only a one-level deep model, so that selecting the root validates all =
of the certificates under that root.  To me, that doesn't seem to scale =
very well.
=20
This same issue of the control of delegation concerns me even more in =
SAML, because in at least some of the use cases, every enterprise =
effectively becomes their own identity and attribute authority.  Given the =
experience we have so far with X.509 certificates, there isn't much =
evidence to suggest that most enterprises will do a very good job of this. =
 Even some of the best public CAs have trouble with this, as witness the =
bogus Microsoft code signing certificate.
=20
To my way of thinking, it is extremely important that every entity in the =
delegation chain be able to control delegation of any particular attribute,=
 both up and down the chain.  The top level root and some subordinate CA =
may decide that they don't want to delegate some particular authority to a =
sub-CA, and in that case it shouldn't matter what that sub-CA claims =AF =
the relying party should be able to tell quickly and easily that that =
right wasn't granted.  On the other hand, the relying party may decide =
that he doesn't want to trust some higher level CA or even some root CA =
with respect to some particular attribute.  If Osama ben Laden grants me =
the right to access the CIA's mainframe in a signed XML entitlement, I =
doubt that the CIA will be very impressed.
=20
It seems to me that if the only controls you have in this space is =
certificate chaining, then you are forced into an all or nothing situation.=
  You either have to establish a unique root and a unique certificate =
chain for each individual attribute , or you have to lump several =
attributes into an indistinguishable group of capabilities and either =
accept them all or reject them all.  both alternatives seem unacceptable.
=20
ON the other hand, a bit-oriented MAC label can solve these problem easily =
=AF you just AND all of the capabilities together, from the top to the =
bottom of the chain, and see what you have when you get through.  I'll be =
happy to send you the URL of a document that specifies how all this can be =
done if you are interested. =20
=20
Using XML names rather than bits may make this process a little bit more =
user-friendly, although it also tends to make negation somewhat harder.  =
I'm sure that there are other problems, and I'm equally sure that I don't =
understand them all.
=20
In any case, thanks for the education, and I'll go do some more reading.

Bob


--=_CF9566E4.A8C9B4FB
Content-Type: text/html; charset=ISO-8859-7
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.4616.200" name=3DGENERATOR></HEAD>
<BODY style=3D"MARGIN-TOP: 2px; FONT: 10pt Tahoma; MARGIN-LEFT: 2px">
<DIV>&gt;Perhaps you are simply looking for an OID to put arbitrary XML in =
a=20
cert, so <BR>this response will be overkill, but I believe your message =
implies=20
a lack of <BR>understanding of the XML security work currently going on at =
OASIS=20
(SAML and <BR>XACML) <BR><BR>&gt;XACML is defining the means to express =
Access=20
Control Policies. I don't <BR>really see what the semantics of an access =
control=20
policy in the middle of a <BR>cert would be. </DIV>
<DIV>&nbsp;</DIV>
<DIV>&gt;Perhaps you are thinking of SAML. SAML has Attribute Assertions =
which=20
are <BR>almost like Attribute Certs. Also it has Authentication Assertions =
which=20
<BR>seem mostly useful in non-PKI environment. Finally there are Authorizat=
ion=20
<BR>Decision Assertions, which are likely to be quite specific to a =
resource and=20
<BR>short lived. Again it is not clear what putting one in a cert would =
signify=20
<BR>exactly. </DIV>
<DIV>&nbsp;</DIV>
<DIV>I very well may be confused &#8212; it certainly wouldn't be the =
first=20
time!</DIV>
<DIV>&nbsp;</DIV>
<DIV>The last time I looked at SAML, it had "entitlements", but they were =
an=20
unspecified bag of bits, and I was under the impression that the intent =
was for=20
those entitlements to eventually be expressed in XACML.&nbsp; Since XACML =
hasn't=20
published anything yet, at least to my understanding, I done';t know what =
it=20
would contain. But if you are correct, and XACML is a way of expressing =
an=20
access control POLICY, rather than granting a particular user some =
particular=20
right or capability, then you are right &#8212; including XACML in a =
certificate=20
wouldn't make much sense. So perhaps I need to include the SAML =
Attribute=20
Assertions instead.</DIV>
<DIV>&nbsp;</DIV>
<DIV>In any case, I'm not quite ready to buy into the necessity of =
recoding all=20
of the infrastructure in XML &#8212; it just seems like too big a task to =
bite off=20
right now, with less than a solid business case justification (hype =
doesn't=20
count).</DIV>
<DIV>&nbsp;</DIV>
<DIV>So what I was hoping to do was to come half way to the mountain, and =
play=20
around with some XML to learn more about the possible problems &#8212; get =
my feet=20
wet, so to speak.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Since we have existing support for X.509-based authentication to =
eDirectory=20
and other applications, putting some XML attributes in the certificate =
would=20
take advantage of that infrastructure, while using XML for the attribute=20=

assertion would presumably provide a mechanism for supporting extranet=20
authentication, assuming the parties agree as to both the name of the =
attribute=20
(easy), and the precise semantics (much harder, generally).<BR><BR>&gt;Of =
course=20
all can be signed using XMLdsig and thus be consumers of PKIX <BR>mechanism=
s.=20
But I am unclear what sort of a use case you have in mind. </DIV>
<DIV>&nbsp;</DIV>
<DIV>I don't really want to have to implement XMLdsig at this point in =
time,=20
as&nbsp;I don't see what advantages it provides over existing IETF-standard=
ized=20
signature mechanisms.&nbsp; If I can simply drop the attribute assertions =
into=20
an X.509 certificate issued by the organization that is attesting to =
the=20
attributes (and the user's identity, for what that's worth), then I don't =
have=20
to do anything extra.&nbsp; XMLdsig seems like politically correct =
overkill, and=20
I can't afford that.<BR><BR>&gt;If you believe X.509 Attribute Certs are =
broken=20
(as opposed to unused) I <BR>would like to hear why, since SAML =
Attribute=20
Assertions are very similar. On <BR>the other hand, SAML has a lot of =
other=20
machinery, so perhaps we have <BR>already addressed your concerns. </DIV>
<DIV>&nbsp;</DIV>
<DIV>I do believe that X.509 attribute certificates are broken, as well =
as=20
unused.&nbsp; The last time we went through some of those issues on the =
PKIX=20
list, it became apparent that controlling the delegation of attributes =
through a=20
chain of attribute certs was even more difficult than controlling =
identity=20
assertions via policy constraints, name subordination, etc.&nbsp; As a =
result,=20
the only uses that I have heard be suggested for attribute certs used only =
a=20
one-level deep model, so that selecting the root validates all of the=20
certificates under that root.&nbsp; To me, that doesn't seem to scale =
very=20
well.</DIV>
<DIV>&nbsp;</DIV>
<DIV>This same issue of the control of delegation concerns me even more in =
SAML,=20
because in at least some of the use cases, every enterprise effectively =
becomes=20
their own identity and attribute authority.&nbsp; Given the experience we =
have=20
so far with X.509 certificates, there isn't much evidence to suggest that =
most=20
enterprises will do a very good job of this.&nbsp; Even some of the best =
public=20
CAs have trouble with this, as witness the bogus Microsoft code signing=20
certificate.</DIV>
<DIV>&nbsp;</DIV>
<DIV>To my way of thinking, it is extremely important that every entity in =
the=20
delegation chain be able to control delegation of any particular attribute,=
 both=20
up and down the chain.&nbsp; The top level root and some subordinate CA =
may=20
decide that they don't want to delegate some particular authority to a =
sub-CA,=20
and in that case it shouldn't matter what that sub-CA claims &#8212; the =
relying party=20
should be able to tell quickly and easily that that right wasn't granted.&n=
bsp;=20
On the other hand, the relying party may decide that he doesn't want to =
trust=20
some higher level CA or even some root CA with respect to some particular=
=20
attribute.&nbsp; If Osama ben Laden grants me the right to access the =
CIA's=20
mainframe in a signed&nbsp;XML entitlement, I doubt that the CIA will be =
very=20
impressed.</DIV>
<DIV>&nbsp;</DIV>
<DIV>It seems to me that if the only controls you have in this space is=20
certificate chaining, then you are forced into an all or nothing=20
situation.&nbsp; You either have to establish a unique root and a =
unique=20
certificate chain for each individual attribute , or you have to lump =
several=20
attributes into an indistinguishable group of capabilities and either =
accept=20
them all or reject them all.&nbsp; both alternatives seem unacceptable.</DI=
V>
<DIV>&nbsp;</DIV>
<DIV>ON the other hand, a&nbsp;bit-oriented MAC label can solve these =
problem=20
easily &#8212; you just AND all of the capabilities together, from the top =
to the=20
bottom of the chain, and see what you have when you get through.&nbsp; =
I'll be=20
happy to send you the URL of a document that specifies how all this can be =
done=20
if you are interested.&nbsp; </DIV>
<DIV>&nbsp;</DIV>
<DIV>Using XML names rather than bits may make this process a little bit =
more=20
user-friendly, although it also tends to make negation somewhat harder.&nbs=
p;=20
I'm sure that there are other problems, and I'm equally sure that I =
don't=20
understand them all.</DIV>
<DIV>&nbsp;</DIV>
<DIV>In any case, thanks for the education, and I'll go do some more=20
reading.<BR></DIV>
<DIV>Bob</DIV></BODY></HTML>

--=_CF9566E4.A8C9B4FB--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8CLWhZ05553 for ietf-pkix-bks; Wed, 12 Sep 2001 14:32:43 -0700 (PDT)
Received: from bigbird.gradient.com (bigbird.gradient.com [192.92.110.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8CLWgD05549 for <[e-mail]>; Wed, 12 Sep 2001 14:32:42 -0700 (PDT)
Received: by bigbird.gradient.com with Internet Mail Service (5.5.2650.10) id <SALVY870>; Wed, 12 Sep 2001 17:34:48 -0400
Message-ID: <[e-mail]>
From: Hal Lockhart <[e-mail]>
To: "'Bob Jueneman'" <[e-mail]>, [e-mail]
Cc: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: RE: XACML OID tag?
Date: Wed, 12 Sep 2001 17:34:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain; charset="ISO-8859-7"
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:
> This is join to sound like heresy, but has anyone defined an 
> OID tag for XACML, so that an XACML string could be included 
> in a X.509 certificate?

...

> Toolkits which would provide enterprises to issue their own 
> certificates have so far failed to take off to any 
> significant degree

...

> One of the reasons, I believe, is that the neither the public 
> TTPs nor the toolkit vendors have so far adequately addressed 
> the important issue of providing a cross-enterprise Privilege 
> Management Infrastructure solution.  And now that they are 
> feeling a very significant financial pinch, they may not have 
> the wherewithal to solve that problem.

Perhaps you are simply looking for an OID to put arbitrary XML in a cert, so
this response will be overkill, but I believe your message implies a lack of
understanding of the XML security work currently going on at OASIS (SAML and
XACML)

XACML is defining the means to express Access Control Policies. I don't
really see what the semantics of an access control policy in the middle of a
cert would be.

Perhaps you are thinking of SAML. SAML has Attribute Assertions which are
almost like Attribute Certs. Also it has Authentication Assertions which
seem mostly useful in non-PKI environment. Finally there are Authorization
Decision Assertions, which are likely to be quite specific to a resource and
short lived. Again it is not clear what putting one in a cert would signify
exactly.

Of course all can be signed using XMLdsig and thus be consumers of PKIX
mechanisms. But I am unclear what sort of a use case you have in mind.

> Maybe it's just the religion of the week (XML) creating an 
> evangelistic fervor, but that's where the buzz seems to be 
> these days.  And I'd rather drop some XACML into an X.509 
> certificate and make use of the existing tools, rather than 
> create everything from scratch.  And yes, if X.509 attribute 
> certificates had been better thought out and/or more widely 
> implemented, maybe this wouldn't be necessary. And if pigs 
> could whistle and cows could fly, then the world would be a 
> much different place.

If you believe X.509 Attribute Certs are broken (as opposed to unused) I
would like to hear why, since SAML Attribute Assertions are very similar. On
the other hand, SAML has a lot of other machinery, so perhaps we have
already addressed your concerns.

I understand the buzz concern, but there is actually very little overlap
between the functional capabilities of PKIX and the OASIS security work.

> Anyway, does anyone have such an OID and a suggested way to 
> use it?  If not, I guess I'll explore rolling my own, unless 
> someone else wants to join in the fun.

Before you design something, I suggest you propose a usecase or some
requirements or something.

Regards,

Hal


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8CISND02322 for ietf-pkix-bks; Wed, 12 Sep 2001 11:28:23 -0700 (PDT)
Received: from phnxpop4.phnx.uswest.net (phnxpop4.phnx.uswest.net [206.80.192.4]) by above.proper.com (8.11.6/8.11.3) with SMTP id f8CISMD02318 for <[e-mail]>; Wed, 12 Sep 2001 11:28:22 -0700 (PDT)
Received: (qmail 37203 invoked by alias); 12 Sep 2001 18:28:14 -0000
Delivered-To: [e-mail]@fixme
Received: (qmail 37014 invoked by uid 0); 12 Sep 2001 18:28:12 -0000
Received: from aadialup236.phnx.uswest.net (HELO ?192.168.0.2?) (209.181.133.236) by phnxpop4.phnx.uswest.net with SMTP; 12 Sep 2001 18:28:12 -0000
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <a05100304b7c3e148a8ba@[192.168.0.2]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 12 Sep 2001 11:28:04 -0700
To: "Tom Gindin" <[e-mail]>, Sharon Boeyen <[e-mail]>
From: "Hoyt L. Kesterson II" <[e-mail]>
Subject: private on RE: Removing expired certificates from CRLs.....
Cc: IETF-PKIX <[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>

tom, sharon and i just talked about this. i agree that x.509 could 
use some more clarification in this area, in particular, giving 
guidance when a new extension would be recommended. we have put this 
on the list of discussion topics at the flagstaff meeting the week of 
24 march.

we would probably address it as a defect report and draft text for 
pkix to review.

    hoyt


At 9:32 AM -0400 9/11/01, Tom Gindin wrote:
>      While the rules for extensibility do indeed permit the addition of
>individual fields without reference to criticality, I am not sure that they
>should do so.  This particular case is an extreme one because the component
>which would have been added to the definition is not really critical
>itself.  Do we need to add guidance to the standard that components should
>not be added to critical extensions without changing the OID unless the new
>component's meaning is critical to the meaning of the extension whenever it
>is present?
>
>           Tom Gindin
>
>
>Sharon Boeyen <[e-mail]> on 09/10/2001 01:44:56 PM
>
>To:   Tom Gindin/Watson/IBM@IBMUS
>cc:   "'Denis Pinkas'" <[e-mail]>, IETF-PKIX
>       <[e-mail]>
>Subject:  RE: Removing expired certificates from CRLs.....
>
>
>Regardless of criticality, the rules for extensibility allow additional
>components
>to be added to existing extensions without changing the OIDs. However, I
>hadn't
>considered the criticality issue and in fact the IDP extension can only be
>set to
>critical, so that probably makes it not the most desirable place to add
>this. A new
>extension is probably a better way to go. Thanks for bringing up the
>criticality issue.
>
>
>Sharon
>
>
>>  -----Original Message-----
>>  From: Tom Gindin [mailto:[e-mail]]
>>  Sent: Monday, September 10, 2001 12:25 PM
>>  To: Sharon Boeyen
>>  Cc: 'Denis Pinkas'; IETF-PKIX
>>  Subject: RE: Removing expired certificates from CRLs.....
>>
>>
>>
>>
>>       Sharon:
>>
>>       Like Denis, I'm in favor of a separate extension,
>>  especially since I
>>  think that excluding revocations of encryption certificates
>>  from retention
>>  is a good idea.  Using the IDP makes it very advisable that
>>  the syntax be
>>  trimmed.  Also, since the IDP is recommended to be critical
>>  by both X.509
>>  and PKIX, wouldn't we have to reassign its OID if we're
>>  adding fields to
>>  the syntax, even in a way that is backwards compatible?  If
>>  so, that would
>>  more than neutralize any advantage to be gained by reusing a
>>  well-known
>>  extension.
>>
>>            Tom Gindin
>>
>>
>>  Sharon Boeyen <[e-mail]>@mail.imc.org on 09/10/2001
>>  11:02:03 AM
>>
>>  Sent by:  [e-mail]
>>
>>
>>  To:   "'Denis Pinkas'" <[e-mail]>, Sharon Boeyen
>>        <[e-mail]>
>>  cc:   IETF-PKIX <[e-mail]>
>>  Subject:  RE: Removing expired certificates from CRLs.....
>>
>>
>>  Denis, I'm not necessarily recommending one approach over the
>>  other, just
>>  raising the
>>  options for discussion. However, I do want to note that IDP can, but
>>  obviously need not, be included in a "single big" CRL just as
>>  it can be in
>>  a CRL DP. The only current component that would be likely be
>>  present in
>>  such a CRL would be the name if the IDP.
>>
>>
>>  Cheers,
>>  Sharon
>>
>>
>>  > -----Original Message-----
>>  > From: Denis Pinkas [mailto:[e-mail]]
>>  > Sent: Monday, September 10, 2001 10:19 AM
>>  > To: Sharon Boeyen
>>  > Cc: IETF-PKIX
>>  > Subject: Re: Removing expired certificates from CRLs.....
>>  >
>>  >
>>  > Sharon,
>>  >
>>  > > Tim, I like this proposal because of its simplicity and
>>  > given all the
>>  > > other variable ways we have to set up CRLs, I suspect this,
>>  > combined with
>>  > > them, gives more than enough flexibility. Does this need
>>  to be a new
>>  > > extension on its own? It could be, or it could be added as
>  > > an additional
>>  > > parameter to the IDP extension. That might be even simpler
>  > > - thoughts?
>>  >
>>  > As implictly said in my e-mail from this morning, I am in
>>  favour of an
>>  > independant extension, so that we do not mandate the use of
>>  > IDP to have that
>>  > additional feature. In other words, if the extension were
>>  > part of IDP, a
>>  > single big CRL could not benefit of that advantage.
>>  >
>>  > Denis
>>  >
>>  > > As for the different groups, if there is going to be a new
>>  > extension of
>>  > > this sort, I'd like it to be added to 509 and profiled by PKIX, if
>>  > > possible. If the PKIX groups reaches consensus on what they
>>  > want quickly
>>  > > enough, that input can be submitted on behalf of PKIX to
>>  > the 509 meeting
>>  > > later this month. The timing is very good this time.
>>  > >
>>  > > Cheers,
>>  > > Sharon
>>  > >
>>  > > > -----Original Message-----
>>  > > > From: Tim Polk [mailto:[e-mail]]
>>  > > > Sent: Friday, September 07, 2001 5:20 PM
>>  > > > To: Denis Pinkas; Tom Gindin
>>  > > > Cc: IETF-PKIX
>>  > > > Subject: Re: Removing expired certificates from CRLs.....
>>  > > >
>>  > > >
>>  > > >
>>  > > > Denis, Tom, et al.
>>  > > >
>>  > > > As one of several independent originators of the idea,
>>  > > > (Ambarish Malpani is
>>  > > > another), I thought I ought to weigh in as well.  I had
>>  something
>>  > > > *considerably* simpler in mind.  If a CRL includes revocation
>>  > > > information
>>  > > > for certificates that have expired, a relying party
>>  > should be able to
>>  > > > determine that automatically.
>>  > > >
>>  > > > I would suggest a noncritical CRL extension with a single
>>  > > > value of type
>>  > > > GeneralizedTime.   The ASN.1 syntax would be
>>  > > >
>>  > > >       ExpiredCertsOnCRL ::= GeneralizedTime
>>  > > >
>>  > > > As usual with PKIX times, we would require time Zulu with
>>  > > > seconds (even if
>>  > > > zero).
>>  > > >
>>  > > > The semantics for the extension would be as follows:
>>  > > >
>>  > > >       The scope of a CRL containing this extension is
>>  > > > extended to include
>>  > > > certificates that expired  at the exact time specified in the
>>  > > > extension or
>>  > > > after that time.  If limitations in the CRL's scope are
>>  > specified (by
>>  > > > either reason codes or by distribution points), that applies
>>  > > > to expired
>>  > > > certificates as well.
>>  > > >
>>  > > > IMHO, we shouldn't make the scope of a CRL different for
>>  > expired and
>>  > > > unexpired certificates.  This is a simple idea - let's keep
>>  > > > it that way!
>>  > > >
>>  > > > BTW, folks were wondering why this hasn't been pursued in
>>  > > > PKIX.  This idea
>>  > > > has been floated a couple of times, but no one was
>>  really ready to
>>  > > > implement it.  We needed to concentrate on the core
>>  > functionality.  I
>>  > > > floated the idea again at one of the meetings (in San Diego?)
>>  > > > and Ambarish
>>  > > > said he'd had the same idea and wanted to pursue it.  I asked
>>  > > > him to delay
>>  > > > any new work in this area until the son-of-2459 is
>>  approved by the
>>  > > > IESG.  (Neither of us realized what a long delay we'd
>>  > agreed to...)
>>  > > >
>>  > > > Thanks,
>>  > > >
>>  > > > Tim Polk
>>  > > >
>>  >
>>
>>
>>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8CHWSE01517 for ietf-pkix-bks; Wed, 12 Sep 2001 10:32:28 -0700 (PDT)
Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8CHWQD01513 for <[e-mail]>; Wed, 12 Sep 2001 10:32:26 -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.3) with SMTP id f8CHWKJ11753; Wed, 12 Sep 2001 10:32:20 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "IETF-PKIX" <[e-mail]>
Subject: RE: Removing expired certificates from CRLs.....
Date: Wed, 12 Sep 2001 10:30: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)
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>

Denis,

What are your thoughts on the timeliness characteristic between OCSP and
CRLs?

Mike



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

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Wednesday, September 12, 2001 12:35 AM
> To: Michael Myers
> Cc: IETF-PKIX
> Subject: Re: Removing expired certificates from CRLs.....
>
>
>
> > All,
> >
> > I think a unique extension creates the least impact.
> >
> > More broadly though, what's really bothering me is my sense that we're
> > backing into the notion of a 1-1 between CRLs and online status
> mechanisms.
> >
> > Assume an environment that both publishes CRLs and offers OCSP-based
> > services against the same set of certificates.  What if:
> >
> > a) The CA receives a revocation request at T1;
> >
> > b) A database state variable is flipped at T1+N;
> >
> > c) An OCSP request is received at T1+N+M;
> >
> > d) An OCSP response is transmitted at T1+N+M+K;
> >
> > e) Yet the next CRL cycle won't run (i.e. the cron
> >    job won't fire) until T1+X where X >> (N+M+K).
> >
> > Thus relying parties are enabled to pick and choose between CRLs or OCSP
> > depending on how it might benefit their argument for remedy
> under digital
> > signature laws.
> >
> > Thoughts, anyone?
>
> Some validation policies, like Signature policies are able to say whether
> CRLs or OCSP responses shall be used.
>
> As an example see: draft-ietf-smime-espolicies-01.txt
>
> EnuRevReq  ::= ENUMERATED {
> 	clrCheck	(0),
>                    --Checks must be made against current CRLs
> 		   -- (or authority revocation lists (ARL))
> 	ocspCheck	(1), -- The revocation status must be checked
>                   -- using the Online Certificate Status Protocol
>                   -- (OCSP),RFC 2450.
> 	bothCheck	(2),
>                   -- Both CRL and OCSP checks must be carried out
> 	eitherCheck	(3),
>                   -- At least one of CRL or OCSP checks must be
>                   -- carried out
> 	noCheck		(4),
>                   -- no check is mandated
> 	other		(5)
>                   -- Other mechanism as defined by signature policy
>                   -- extension
> 	  }
>
> If either CRL (i.e.clrCheck) or OCSP (i.e. ocspCheck) is mandated, then
> there is no conflict between the two mechanisms.
>
> Denis
>
>
> > Mike
> >
> > Michael Myers
> > t: +415.819.1362
> > e: mailto:[e-mail]
> > w: http://www.traceroutesecurity.com g
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8C8JQj26152 for ietf-pkix-bks; Wed, 12 Sep 2001 01:19:26 -0700 (PDT)
Received: from mx11.nameplanet.com ([e-mail] [62.70.3.41]) by above.proper.com (8.11.6/8.11.3) with SMTP id f8C8JPD26148 for <[e-mail]>; Wed, 12 Sep 2001 01:19:25 -0700 (PDT)
Received:  12 Sep 2001 08:19:24 -0000
Received: from unknown (HELO www3.nameplanet.com) (192.168.2.43) by mx11 with SMTP; 12 Sep 2001 08:19:24 -0000
Received: (qmail 15359 invoked by uid 400); 12 Sep 2001 08:19:23 -0000
Date: 12 Sep 2001 08:19:23 -0000
Message-ID: <[e-mail]>
From: [e-mail]
To: [e-mail]
MIME-Version: 1.0
Subject: Question about TSP (rfc 3161)
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>

Hi,


I would like to know what are the reasons for introducing the flags "pollReq",
"pollResp" and "negPollRep" in the socket based protocol (section 3.3).


It would mean that a tsa server can divide the der code he calculated for the
response. But why would it do that?


Thanks


Libel


-- 
Get your firstname@lastname email for FREE at http://Nameplanet.com/?su


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8C7ZOf21285 for ietf-pkix-bks; Wed, 12 Sep 2001 00:35:24 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8C7ZMD21281 for <[e-mail]>; Wed, 12 Sep 2001 00:35:23 -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 JAA34282; Wed, 12 Sep 2001 09:37:23 +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 JAA12704; Wed, 12 Sep 2001 09:34:38 +0200
Message-ID: <[e-mail]>
Date: Wed, 12 Sep 2001 09:34:39 +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: Michael Myers <[e-mail]>
CC: IETF-PKIX <[e-mail]>
Subject: Re: Removing expired certificates from 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>

> All,
> 
> I think a unique extension creates the least impact.
> 
> More broadly though, what's really bothering me is my sense that we're
> backing into the notion of a 1-1 between CRLs and online status mechanisms.
> 
> Assume an environment that both publishes CRLs and offers OCSP-based
> services against the same set of certificates.  What if:
> 
> a) The CA receives a revocation request at T1;
> 
> b) A database state variable is flipped at T1+N;
> 
> c) An OCSP request is received at T1+N+M;
> 
> d) An OCSP response is transmitted at T1+N+M+K;
> 
> e) Yet the next CRL cycle won't run (i.e. the cron
>    job won't fire) until T1+X where X >> (N+M+K).
> 
> Thus relying parties are enabled to pick and choose between CRLs or OCSP
> depending on how it might benefit their argument for remedy under digital
> signature laws.
> 
> Thoughts, anyone?

Some validation policies, like Signature policies are able to say whether
CRLs or OCSP responses shall be used.

As an example see: draft-ietf-smime-espolicies-01.txt

EnuRevReq  ::= ENUMERATED {
	clrCheck	(0), 
                   --Checks must be made against current CRLs
		   -- (or authority revocation lists (ARL))
	ocspCheck	(1), -- The revocation status must be checked
                  -- using the Online Certificate Status Protocol 
                  -- (OCSP),RFC 2450.
	bothCheck	(2),	
                  -- Both CRL and OCSP checks must be carried out
	eitherCheck	(3),	
                  -- At least one of CRL or OCSP checks must be
                  -- carried out
	noCheck		(4),	
                  -- no check is mandated
	other		(5)		
                  -- Other mechanism as defined by signature policy 
                  -- extension
	  }

If either CRL (i.e.clrCheck) or OCSP (i.e. ocspCheck) is mandated, then
there is no conflict between the two mechanisms.

Denis

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


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8C5uis06402 for ietf-pkix-bks; Tue, 11 Sep 2001 22:56:44 -0700 (PDT)
Received: from mclean.mail.mindspring.net (mclean.mail.mindspring.net [207.69.200.57]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8C5ugD06397 for <[e-mail]>; Tue, 11 Sep 2001 22:56:42 -0700 (PDT)
Received: from ASN-1.com (user-2ivf26u.dialup.mindspring.com [165.247.136.222]) by mclean.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id BAA00052; Wed, 12 Sep 2001 01:56:43 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 12 Sep 2001 01:54:44 -0400
From: Phil Griffin <[e-mail]>
Organization: Griffin Consulting
X-Mailer: Mozilla 4.73 [en]C-{C-UDP; EBM-SONY1}  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Williams <[e-mail]>
CC: [e-mail]
Subject: Re: XACML OID tag?
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>

Peter,

Peter Williams wrote:
> 
> 
> If one profiled X.509 to change the OCTET
> STRING of the extension type to be OCTET STRING
> (CONTAINING UTF8String ENCODED BY xml), then this
> would seem to meet the profiling rules, for
> the xml environment.
> 
> Sharon would have to alter X.509 to remove
> the comment on extnValue that requires
> DER encoding of a (ASN.1) type. Her change
> could indicate that the encoding should DER
> unless profilers specify an CONTAINING
> and ENCODED BY to specify different rules.
> Obviously, the extnID can implicitely communicate the
> contents and encoding rule, when the defaults are
> not to be assumed.

Well, the OCTET STRING here could follow the current
rules, as could the value of it's content, a UTF8String.
But the UTF8String here would carry an XML markup payload.

But I was actually looking one level deeper when I wrote
this. That is, I was looking at this OCTET STRING as a
possible payload (in an Extension case at least) within
the extnID. So that would be an OCTET STRING that 
contained "Payload" which contained a UTF8String that
carried XML markup. 

Of course, there are other cases in ASN.1 messages where
such nesting would not be required. 

> IT seems strange now to force a particular
> canonicalization scheme, given we have
> others now, more fitting the usage
> environment of (encoded) ASN.1 values.
> 
> If we do this, we can avoid specifying
> extensions which bear an "OCTET STRING ASN.1
> type" (which then bear the xml-encoded
> utf8), merely to satisfy the comment
> in the standard.

Yes, ASN.1 values already have canonical encodings;
the commonly used DER, the unused (I think) CER,
a canonical PER variant, and soon CXER, a canonical
encoding variant of the XML Encoding Rules of ASN.1.

Phil
 
> -----Original Message-----
> From: Phil Griffin [mailto:[e-mail]]
> Sent: Tuesday, September 11, 2001 3:02 PM
> To: Rich Salz
> Cc: Bob Jueneman; [e-mail]
> Subject: Re: XACML OID tag?
> 
> Rich,
> 
> CXER can be related to signing canonical XML
> encodings of ASN.1 values. It has not been
> targeted at all to the workings of XMLDSIG.
> 
> But a canonical encoding of an ASN.1 value
> can be carried easily in an ASN.1 value, say
> an attribute or extension using
> 
> Payload ::=
>    OCTET STRING (CONTAINING UTF8String
>                     ENCODED BY xml)
> 
> where "xml" is an object identifier. There are
> many other useful variants that can be processed
> by XML-aware ASN.1 tools.
> 
> Phil Griffin
> 
> Rich Salz wrote:
> >
> > How does CXER relate to the the XML Canoinicalization spec, designed as
> > part of XML DSIG?
> >
> > I hope the answer is "the same," but I doubt it. :(
> >         /r$
> >
> > --
> > Zolera Systems, Your Key to Online Integrity
> > Securing Web services: XML, SOAP, Dig-sig, Encryption
> > http://www.zolera.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8BNwQH02164 for ietf-pkix-bks; Tue, 11 Sep 2001 16:58:26 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8BNwOD02160 for <[e-mail]>; Tue, 11 Sep 2001 16:58:24 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Tue, 11 Sep 2001 16:59: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]>; Tue, 11 Sep 2001 16:59:09 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <SMT3Z606>; Tue, 11 Sep 2001 16:51:49 -0700
Content-return: allowed
Date: Tue, 11 Sep 2001 16:51:38 -0700
From: Peter Williams <[e-mail]>
Subject: RE: XACML OID tag?
To: "'Phil Griffin'" <[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
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>

 
If one profiled X.509 to change the OCTET
STRING of the extension type to be OCTET STRING 
(CONTAINING UTF8String ENCODED BY xml), then this
would seem to meet the profiling rules, for
the xml environment.

Sharon would have to alter X.509 to remove
the comment on extnValue that requires
DER encoding of a (ASN.1) type. Her change
could indicate that the encoding should DER
unless profilers specify an CONTAINING
and ENCODED BY to specify different rules.
Obviously, the extnID can implicitely communicate the
contents and encoding rule, when the defaults are
not to be assumed.

IT seems strange now to force a particular
canonicalization scheme, given we have
others now, more fitting the usage
environment of (encoded) ASN.1 values.

If we do this, we can avoid specifying
extensions which bear an "OCTET STRING ASN.1
type" (which then bear the xml-encoded
utf8), merely to satisfy the comment
in the standard.

-----Original Message-----
From: Phil Griffin [mailto:[e-mail]]
Sent: Tuesday, September 11, 2001 3:02 PM
To: Rich Salz
Cc: Bob Jueneman; [e-mail]
Subject: Re: XACML OID tag?



Rich,

CXER can be related to signing canonical XML
encodings of ASN.1 values. It has not been
targeted at all to the workings of XMLDSIG.

But a canonical encoding of an ASN.1 value
can be carried easily in an ASN.1 value, say
an attribute or extension using

Payload ::= 
   OCTET STRING (CONTAINING UTF8String 
                    ENCODED BY xml)

where "xml" is an object identifier. There are
many other useful variants that can be processed
by XML-aware ASN.1 tools.

Phil Griffin



Rich Salz wrote:
> 
> How does CXER relate to the the XML Canoinicalization spec, designed as
> part of XML DSIG?
> 
> I hope the answer is "the same," but I doubt it. :(
>         /r$
> 
> --
> Zolera Systems, Your Key to Online Integrity
> Securing Web services: XML, SOAP, Dig-sig, Encryption
> http://www.zolera.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8BMGIQ01064 for ietf-pkix-bks; Tue, 11 Sep 2001 15:16:18 -0700 (PDT)
Received: from zolera.com (IDENT:root@[63.142.188.177]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8BMGGD01060 for <[e-mail]>; Tue, 11 Sep 2001 15:16:16 -0700 (PDT)
Received: from zolera.com (pool-141-154-57-75.bos.east.verizon.net [141.154.57.75]) by zolera.com (8.11.0/8.11.0) with ESMTP id f8BMGTa03255; Tue, 11 Sep 2001 18:16:29 -0400
Message-ID: <[e-mail]>
Date: Tue, 11 Sep 2001 18:16:44 -0400
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Phil Griffin <[e-mail]>
CC: Bob Jueneman <[e-mail]>, [e-mail]
Subject: Re: XACML OID tag?
References: <[e-mail]> <[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>

I don't know what CXER is, but my point is that the W3C already defined
a canonical XML format.  It would be nice if there weren't two.
	/r$

-- 
Zolera Systems, Securing web services (XML, SOAP, Signatures,
Encryption)
http://www.zolera.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8BM4Ic00942 for ietf-pkix-bks; Tue, 11 Sep 2001 15:04:18 -0700 (PDT)
Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8BM4GD00937 for <[e-mail]>; Tue, 11 Sep 2001 15:04:16 -0700 (PDT)
Received: from ASN-1.com (user-2ivf6eu.dialup.mindspring.com [165.247.153.222]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id SAA07815; Tue, 11 Sep 2001 18:04:14 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 11 Sep 2001 18:02:17 -0400
From: Phil Griffin <[e-mail]>
Organization: Griffin Consulting
X-Mailer: Mozilla 4.73 [en]C-{C-UDP; EBM-SONY1}  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Rich Salz <[e-mail]>
CC: Bob Jueneman <[e-mail]>, [e-mail]
Subject: Re: XACML OID tag?
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>

Rich,

CXER can be related to signing canonical XML
encodings of ASN.1 values. It has not been
targeted at all to the workings of XMLDSIG.

But a canonical encoding of an ASN.1 value
can be carried easily in an ASN.1 value, say
an attribute or extension using

Payload ::= 
   OCTET STRING (CONTAINING UTF8String 
                    ENCODED BY xml)

where "xml" is an object identifier. There are
many other useful variants that can be processed
by XML-aware ASN.1 tools.

Phil Griffin



Rich Salz wrote:
> 
> How does CXER relate to the the XML Canoinicalization spec, designed as
> part of XML DSIG?
> 
> I hope the answer is "the same," but I doubt it. :(
>         /r$
> 
> --
> Zolera Systems, Your Key to Online Integrity
> Securing Web services: XML, SOAP, Dig-sig, Encryption
> http://www.zolera.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8BEAZl14211 for ietf-pkix-bks; Tue, 11 Sep 2001 07:10:35 -0700 (PDT)
Received: from zolera.com (IDENT:root@[63.142.188.177]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8BEAXD14207 for <[e-mail]>; Tue, 11 Sep 2001 07:10:33 -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 f8BEAna00355; Tue, 11 Sep 2001 10:10:49 -0400
Message-ID: <[e-mail]>
Date: Tue, 11 Sep 2001 10:10:49 -0400
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Phil Griffin <[e-mail]>
CC: Bob Jueneman <[e-mail]>, [e-mail]
Subject: Re: XACML OID tag?
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>

How does CXER relate to the the XML Canoinicalization spec, designed as
part of XML DSIG?

I hope the answer is "the same," but I doubt it. :(
	/r$

-- 
Zolera Systems, Your Key to Online Integrity
Securing Web services: XML, SOAP, Dig-sig, Encryption
http://www.zolera.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8BDX0t12128 for ietf-pkix-bks; Tue, 11 Sep 2001 06:33:00 -0700 (PDT)
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8BDWwD12124 for <[e-mail]>; Tue, 11 Sep 2001 06:32:58 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA114306; Tue, 11 Sep 2001 09:30:37 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8BDOhi34798; Tue, 11 Sep 2001 09:24:43 -0400
Importance: Normal
Subject: RE: Removing expired certificates from CRLs.....
To: Sharon Boeyen <[e-mail]>
Cc: IETF-PKIX <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Tue, 11 Sep 2001 09:32:53 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.8 SPR #MIAS4UTJ8H |June 21, 2001) at 09/11/2001 09:32:52 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>

     While the rules for extensibility do indeed permit the addition of
individual fields without reference to criticality, I am not sure that they
should do so.  This particular case is an extreme one because the component
which would have been added to the definition is not really critical
itself.  Do we need to add guidance to the standard that components should
not be added to critical extensions without changing the OID unless the new
component's meaning is critical to the meaning of the extension whenever it
is present?

          Tom Gindin


Sharon Boeyen <[e-mail]> on 09/10/2001 01:44:56 PM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   "'Denis Pinkas'" <[e-mail]>, IETF-PKIX
      <[e-mail]>
Subject:  RE: Removing expired certificates from CRLs.....


Regardless of criticality, the rules for extensibility allow additional
components
to be added to existing extensions without changing the OIDs. However, I
hadn't
considered the criticality issue and in fact the IDP extension can only be
set to
critical, so that probably makes it not the most desirable place to add
this. A new
extension is probably a better way to go. Thanks for bringing up the
criticality issue.


Sharon


> -----Original Message-----
> From: Tom Gindin [mailto:[e-mail]]
> Sent: Monday, September 10, 2001 12:25 PM
> To: Sharon Boeyen
> Cc: 'Denis Pinkas'; IETF-PKIX
> Subject: RE: Removing expired certificates from CRLs.....
>
>
>
>
>      Sharon:
>
>      Like Denis, I'm in favor of a separate extension,
> especially since I
> think that excluding revocations of encryption certificates
> from retention
> is a good idea.  Using the IDP makes it very advisable that
> the syntax be
> trimmed.  Also, since the IDP is recommended to be critical
> by both X.509
> and PKIX, wouldn't we have to reassign its OID if we're
> adding fields to
> the syntax, even in a way that is backwards compatible?  If
> so, that would
> more than neutralize any advantage to be gained by reusing a
> well-known
> extension.
>
>           Tom Gindin
>
>
> Sharon Boeyen <[e-mail]>@mail.imc.org on 09/10/2001
> 11:02:03 AM
>
> Sent by:  [e-mail]
>
>
> To:   "'Denis Pinkas'" <[e-mail]>, Sharon Boeyen
>       <[e-mail]>
> cc:   IETF-PKIX <[e-mail]>
> Subject:  RE: Removing expired certificates from CRLs.....
>
>
> Denis, I'm not necessarily recommending one approach over the
> other, just
> raising the
> options for discussion. However, I do want to note that IDP can, but
> obviously need not, be included in a "single big" CRL just as
> it can be in
> a CRL DP. The only current component that would be likely be
> present in
> such a CRL would be the name if the IDP.
>
>
> Cheers,
> Sharon
>
>
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Monday, September 10, 2001 10:19 AM
> > To: Sharon Boeyen
> > Cc: IETF-PKIX
> > Subject: Re: Removing expired certificates from CRLs.....
> >
> >
> > Sharon,
> >
> > > Tim, I like this proposal because of its simplicity and
> > given all the
> > > other variable ways we have to set up CRLs, I suspect this,
> > combined with
> > > them, gives more than enough flexibility. Does this need
> to be a new
> > > extension on its own? It could be, or it could be added as
> > an additional
> > > parameter to the IDP extension. That might be even simpler
> > - thoughts?
> >
> > As implictly said in my e-mail from this morning, I am in
> favour of an
> > independant extension, so that we do not mandate the use of
> > IDP to have that
> > additional feature. In other words, if the extension were
> > part of IDP, a
> > single big CRL could not benefit of that advantage.
> >
> > Denis
> >
> > > As for the different groups, if there is going to be a new
> > extension of
> > > this sort, I'd like it to be added to 509 and profiled by PKIX, if
> > > possible. If the PKIX groups reaches consensus on what they
> > want quickly
> > > enough, that input can be submitted on behalf of PKIX to
> > the 509 meeting
> > > later this month. The timing is very good this time.
> > >
> > > Cheers,
> > > Sharon
> > >
> > > > -----Original Message-----
> > > > From: Tim Polk [mailto:[e-mail]]
> > > > Sent: Friday, September 07, 2001 5:20 PM
> > > > To: Denis Pinkas; Tom Gindin
> > > > Cc: IETF-PKIX
> > > > Subject: Re: Removing expired certificates from CRLs.....
> > > >
> > > >
> > > >
> > > > Denis, Tom, et al.
> > > >
> > > > As one of several independent originators of the idea,
> > > > (Ambarish Malpani is
> > > > another), I thought I ought to weigh in as well.  I had
> something
> > > > *considerably* simpler in mind.  If a CRL includes revocation
> > > > information
> > > > for certificates that have expired, a relying party
> > should be able to
> > > > determine that automatically.
> > > >
> > > > I would suggest a noncritical CRL extension with a single
> > > > value of type
> > > > GeneralizedTime.   The ASN.1 syntax would be
> > > >
> > > >       ExpiredCertsOnCRL ::= GeneralizedTime
> > > >
> > > > As usual with PKIX times, we would require time Zulu with
> > > > seconds (even if
> > > > zero).
> > > >
> > > > The semantics for the extension would be as follows:
> > > >
> > > >       The scope of a CRL containing this extension is
> > > > extended to include
> > > > certificates that expired  at the exact time specified in the
> > > > extension or
> > > > after that time.  If limitations in the CRL's scope are
> > specified (by
> > > > either reason codes or by distribution points), that applies
> > > > to expired
> > > > certificates as well.
> > > >
> > > > IMHO, we shouldn't make the scope of a CRL different for
> > expired and
> > > > unexpired certificates.  This is a simple idea - let's keep
> > > > it that way!
> > > >
> > > > BTW, folks were wondering why this hasn't been pursued in
> > > > PKIX.  This idea
> > > > has been floated a couple of times, but no one was
> really ready to
> > > > implement it.  We needed to concentrate on the core
> > functionality.  I
> > > > floated the idea again at one of the meetings (in San Diego?)
> > > > and Ambarish
> > > > said he'd had the same idea and wanted to pursue it.  I asked
> > > > him to delay
> > > > any new work in this area until the son-of-2459 is
> approved by the
> > > > IESG.  (Neither of us realized what a long delay we'd
> > agreed to...)
> > > >
> > > > Thanks,
> > > >
> > > > Tim Polk
> > > >
> >
>
>
>





Received: by above.proper.com (8.11.6/8.11.3) id f8B7TQg12733 for ietf-pkix-bks; Tue, 11 Sep 2001 00:29:26 -0700 (PDT)
Received: from michael.checkpoint.com (michael.checkpoint.com [199.203.73.68]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8B7TPD12722 for <[e-mail]>; Tue, 11 Sep 2001 00:29:25 -0700 (PDT)
Received: from earl (localhost [127.0.0.1]) by michael.checkpoint.com (8.9.3/8.9.1) with SMTP id JAA02463; Tue, 11 Sep 2001 09:29:18 +0200 (IST)
From: "Avi Gozlan" <[e-mail]>
To: <[e-mail]>
Subject: CMC issue - CA identification
Date: Tue, 11 Sep 2001 10:32:48 +0300
Message-ID: <002001c13a93$f57ba850$[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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
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,

CMC supplies the identityProof mechanism, by which a CA can immidiately and
automatically identify a CMC client. However, there are no means by which
the CA identifies itself to the CMC client. According to section 4.4 of RFC
2797, clients must explicitly approve trust of the included self-signed
certificate.

In the cases where the identityProof machanism is used the end entity and
the CA share a secret. The secret can be used to authenticate the reply as
well as the request.

Following is a proposal that utilizes this mechanism in the reply.

This way of authentication has some advantages:
- Same strength of authentication on the client side as on the CA side
- More secure - users are not always familiar with approving a CA or its
fingerprint
- Easier to use, no user intervention is required for CA identification

Is it possible that such an automatic identification proof will be added to
CMC (or descendant)?

Here is the proposal:

1. The buffer of the self-signed certificate in the "certificate" portion of
the signedData is the value to be validated
2. A SHA1 hash of the token is computed.
3. An HMAC-SHA1 value is then computed over the value produced in Step 1,
using the hash of the token from Step 2 as the shared secret value
4. The 160-bit-HMAC-SHA1 result from Step 3 is then encoded as the value of
the identityProof attribute.

When the client verifies the identityProof attribute, it extracts the
self-signed certificate from the chain included in the "certificate" portion
of the signedData. It then computes the HMAC-SHA1 value in the same way and
compares it to the identityProof attribute contained in the enrollment
request.

Thanks,

Avi Gozlan
PKI team
Check Point Software Technologies LTD.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8AMpdB26725 for ietf-pkix-bks; Mon, 10 Sep 2001 15:51:39 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8AMpbD26632 for <[e-mail]>; Mon, 10 Sep 2001 15:51:37 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Mon, 10 Sep 2001 15:52:22 -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, 10 Sep 2001 15:52:21 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <SMT3ZYD2>; Mon, 10 Sep 2001 15:45:04 -0700
Content-return: allowed
Date: Mon, 10 Sep 2001 15:44:54 -0700
From: Ryan Hurst <[e-mail]>
Subject: RE: Removing expired certificates from CRLs.....
To: "'Michael Myers'" <[e-mail]>, IETF-PKIX <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain
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 --
	Your point that there is not necessarily a 1-1 relationship is
valid, however it is not uncommon for a responder to receive its revocation
information from CRLs and in this case there could be such a relationship.

Additionally since the overall goal in this case is the same for both OCSP
and CRLs; why not just use them same model to solve the problem? 

Ryan

-----Original Message-----
From: Michael Myers [mailto:[e-mail]] 
Sent: Monday, September 10, 2001 2:28 PM
To: IETF-PKIX
Subject: RE: Removing expired certificates from CRLs.....


All,

I think a unique extension creates the least impact.

More broadly though, what's really bothering me is my sense that we're
backing into the notion of a 1-1 between CRLs and online status mechanisms.

Assume an environment that both publishes CRLs and offers OCSP-based
services against the same set of certificates.  What if:

a) The CA receives a revocation request at T1;

b) A database state variable is flipped at T1+N;

c) An OCSP request is received at T1+N+M;

d) An OCSP response is transmitted at T1+N+M+K;

e) Yet the next CRL cycle won't run (i.e. the cron
   job won't fire) until T1+X where X >> (N+M+K).

Thus relying parties are enabled to pick and choose between CRLs or OCSP
depending on how it might benefit their argument for remedy under digital
signature laws.

Thoughts, anyone?

Mike




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


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8AMdXG28021 for ietf-pkix-bks; Mon, 10 Sep 2001 15:39:33 -0700 (PDT)
Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8AMdUD27855 for <[e-mail]>; Mon, 10 Sep 2001 15:39:30 -0700 (PDT)
Received: from ASN-1.com (user-2ivf0sm.dialup.mindspring.com [165.247.131.150]) by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id SAA17775; Mon, 10 Sep 2001 18:39:20 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 10 Sep 2001 18:37:20 -0400
From: Phil Griffin <[e-mail]>
Organization: Griffin Consulting
X-Mailer: Mozilla 4.73 [en]C-{C-UDP; EBM-SONY1}  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Jueneman <[e-mail]>
CC: [e-mail]
Subject: Re: XACML OID tag?
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
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,

Not sure if this is exactly what you're getting at,
but XML 1.0 markup is now a textual encoding of ASN.1
values based on ASN.1 notation (schema) and a new
part of the ASN.1 standards. 

XER is the XML Encoding Rules of ASN.1, and CXER
is a canonical form of XER, in the same manner that
DER is a canonical encoding of BER. CXER is suitable
for the same types of operations. I'm told that tool
support is will be available from vendors in the
fourth quarter of this year.

The new ASN.1 XML Value Notation is an alternative
to the ASN.1 Basic Notation which will be much more
familiar and natural to use for many folks. The values
are equivalent to current ASN.1 abstract values. This
means that it will be possible to send compact binary
encodings over the wire, but to decode them into more
verbose XML markup. Alternatively, the same abstract
values can be transferred as XML markup.

See http://asn1.elibel.tm.fr/en/xml/index.htm for 
more information. This page will be updated soon with
the meeting results and accomplishments of the last 
two weeks in Bangalore India as soon as folks recover
from travel.

There will be several new OIDs defined in the ASN.1 
standards; one to identify XML. Another being kicked
about will identify gZIPed encoded values. These OIDs
will be built into the standards. 

Phil Griffin


Bob Jueneman wrote:
> 
> This is join to sound like heresy, but has anyone defined an OID tag for XACML, so that an XACML string could be included in a X.509 certificate?
> 
> Now, I fully expect to be assailed from both sides for this question ¯ one for mixing XML into a bastardized certificate format instead of using pure ASN.1 as God obviously intended, and the other for daring to pour holy XML into such an impure, defiled, and unclean vessel as an X.509 certificate.
> 
> So be it, and let the flames begin.
> 
> But I'm observing that conventional, identity-based PKI is suffering what the medical community calls a "failure to thrive", with the sole exception being SSL certificates issued by the TTP CAs, with VeriSign obviously having the mind share in that space.
> 
> Toolkits which would provide enterprises to issue their own certificates have so far failed to take off to any significant degree (ours included), with the consequence that some of those vendors, who once flew so high, are close to being delisted by the NASDAQ.
> 
> One of the reasons, I believe, is that the neither the public TTPs nor the toolkit vendors have so far adequately addressed the important issue of providing a cross-enterprise Privilege Management Infrastructure solution.  And now that they are feeling a very significant financial pinch, they may not have the wherewithal to solve that problem.
> 
> Maybe it's just the religion of the week (XML) creating an evangelistic fervor, but that's where the buzz seems to be these days.  And I'd rather drop some XACML into an X.509 certificate and make use of the existing tools, rather than create everything from scratch.  And yes, if X.509 attribute certificates had been better thought out and/or more widely implemented, maybe this wouldn't be necessary. And if pigs could whistle and cows could fly, then the world would be a much different place.
> 
> Anyway, does anyone have such an OID and a suggested way to use it?  If not, I guess I'll explore rolling my own, unless someone else wants to join in the fun.
> 
> Bob
> 
> Robert R. Jueneman
> Security Architect
> 
> Novell, Inc -- the leading provider of Net services software
> 
>   ------------------------------------------------------------------------
> 
>    Bob Jueneman.vcfName: Bob Jueneman.vcf
>                    Type: Plain Text (text/plain)


Received: by above.proper.com (8.11.6/8.11.3) id f8ALSwn08382 for ietf-pkix-bks; Mon, 10 Sep 2001 14:28:58 -0700 (PDT)
Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8ALSuD08376 for <[e-mail]>; Mon, 10 Sep 2001 14:28:56 -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.3) with SMTP id f8ALSvJ26555 for <[e-mail]>; Mon, 10 Sep 2001 14:28:57 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "IETF-PKIX" <[e-mail]>
Subject: RE: Removing expired certificates from CRLs.....
Date: Mon, 10 Sep 2001 14:27:37 -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
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,

I think a unique extension creates the least impact.

More broadly though, what's really bothering me is my sense that we're
backing into the notion of a 1-1 between CRLs and online status mechanisms.

Assume an environment that both publishes CRLs and offers OCSP-based
services against the same set of certificates.  What if:

a) The CA receives a revocation request at T1;

b) A database state variable is flipped at T1+N;

c) An OCSP request is received at T1+N+M;

d) An OCSP response is transmitted at T1+N+M+K;

e) Yet the next CRL cycle won't run (i.e. the cron
   job won't fire) until T1+X where X >> (N+M+K).

Thus relying parties are enabled to pick and choose between CRLs or OCSP
depending on how it might benefit their argument for remedy under digital
signature laws.

Thoughts, anyone?

Mike




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



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8AJV2i05022 for ietf-pkix-bks; Mon, 10 Sep 2001 12:31:02 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8AJV0D05012 for <[e-mail]>; Mon, 10 Sep 2001 12:31:01 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Mon, 10 Sep 2001 12:31:44 -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, 10 Sep 2001 12:31:44 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <SMT3ZXJT>; Mon, 10 Sep 2001 12:24:27 -0700
Content-return: allowed
Date: Mon, 10 Sep 2001 12:24:24 -0700
From: Ryan Hurst <[e-mail]>
Subject: RE: Removing expired certificates from CRLs.....
To: "'Sharon Boeyen'" <[e-mail]>, "'Tim Polk'" <[e-mail]>, Denis Pinkas <[e-mail]>, Tom Gindin <[e-mail]>
Cc: IETF-PKIX <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: multipart/alternative; boundary="Boundary_(ID_SnLtbEzNOftJ3a9c4FnrxA)"
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.

--Boundary_(ID_SnLtbEzNOftJ3a9c4FnrxA)
Content-type: text/plain

Sharon -
            I would rather see this as a separate extension, traditionally
you will only see IDPs in partitioned CRLs and since this would be
independent of that it seems simpler to keep it separate.
 
Ryan
 
 
 
-----Original Message-----
From: Sharon Boeyen [mailto:[e-mail]] 
Sent: Monday, September 10, 2001 7:10 AM
To: 'Tim Polk'; Denis Pinkas; Tom Gindin
Cc: IETF-PKIX
Subject: RE: Removing expired certificates from CRLs.....
 
Tim, I like this proposal because of its simplicity and given all the other
variable ways we have to set up CRLs, I suspect this, combined with them,
gives more than enough flexibility. Does this need to be a new extension on
its own? It could be, or it could be added as an additional parameter to the
IDP extension. That might be even simpler - thoughts?
As for the different groups, if there is going to be a new extension of this
sort, I'd like it to be added to 509 and profiled by PKIX, if possible. If
the PKIX groups reaches consensus on what they want quickly enough, that
input can be submitted on behalf of PKIX to the 509 meeting later this
month. The timing is very good this time.
Cheers, 
Sharon 
> -----Original Message----- 
> From: Tim Polk [mailto:[e-mail] <mailto:[e-mail]> ] 
> Sent: Friday, September 07, 2001 5:20 PM 
> To: Denis Pinkas; Tom Gindin 
> Cc: IETF-PKIX 
> Subject: Re: Removing expired certificates from CRLs..... 
> 
> 
> 
> Denis, Tom, et al. 
> 
> As one of several independent originators of the idea, 
> (Ambarish Malpani is 
> another), I thought I ought to weigh in as well.  I had something 
> *considerably* simpler in mind.  If a CRL includes revocation 
> information 
> for certificates that have expired, a relying party should be able to 
> determine that automatically. 
> 
> I would suggest a noncritical CRL extension with a single 
> value of type 
> GeneralizedTime.   The ASN.1 syntax would be 
> 
>       ExpiredCertsOnCRL ::= GeneralizedTime 
> 
> As usual with PKIX times, we would require time Zulu with 
> seconds (even if 
> zero). 
> 
> The semantics for the extension would be as follows: 
> 
>       The scope of a CRL containing this extension is 
> extended to include 
> certificates that expired  at the exact time specified in the 
> extension or 
> after that time.  If limitations in the CRL's scope are specified (by 
> either reason codes or by distribution points), that applies 
> to expired 
> certificates as well. 
> 
> IMHO, we shouldn't make the scope of a CRL different for expired and 
> unexpired certificates.  This is a simple idea - let's keep 
> it that way! 
> 
> BTW, folks were wondering why this hasn't been pursued in 
> PKIX.  This idea 
> has been floated a couple of times, but no one was really ready to 
> implement it.  We needed to concentrate on the core functionality.  I 
> floated the idea again at one of the meetings (in San Diego?) 
> and Ambarish 
> said he'd had the same idea and wanted to pursue it.  I asked 
> him to delay 
> any new work in this area until the son-of-2459 is approved by the 
> IESG.  (Neither of us realized what a long delay we'd agreed to...) 
> 
> Thanks, 
> 
> Tim Polk 
> 

--Boundary_(ID_SnLtbEzNOftJ3a9c4FnrxA)
Content-type: text/html
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
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@01C139F4.52454780">
<title>RE: Removing expired certificates from CRLs.....</title>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[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:Compatibility>
   <w:UseFELayout/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;
	mso-font-alt:\5B8B\4F53;
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 135135232 16 0 262145 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 135135232 16 0 262145 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:SimSun;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:SimSun;}
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;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	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:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><st1:City><st1:place><font size=3D2 color=3Dnavy =
face=3DArial><span
  =
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Sharon</span></f=
ont></st1:place></st1:City><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'> -<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-tab-count:1'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; </span>I
would rather see this as a separate extension, traditionally you will =
only see <span
class=3DSpellE>IDPs</span> in partitioned <span =
class=3DSpellE>CRLs</span> and
since this would be independent of that it seems simpler to keep it =
separate.<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'>Ryan<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>=


<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Sharon Boeyen
[mailto:[e-mail]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, September =
10, 2001
7:10 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Tim Polk'; Denis =
Pinkas; Tom
Gindin<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> IETF-PKIX<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Removing =
expired
certificates from CRLs.....</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>Tim, I like this proposal because of its =
simplicity
and given all the other variable ways we have to set up CRLs, I suspect =
this,
combined with them, gives more than enough flexibility. Does this need =
to be a
new extension on its own? It could be, or it could be added as an =
additional
parameter to the IDP extension. That might be even simpler - =
thoughts?</span></font><o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>As for the different groups, if there is =
going to be a
new extension of this sort, I'd like it to be added to 509 and profiled =
by
PKIX, if possible. If the PKIX groups reaches consensus on what they =
want
quickly enough, that input can be submitted on behalf of PKIX to the =
509
meeting later this month. The timing is very good this =
time.</span></font><o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>Cheers,</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>Sharon</span></font> =
<o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>&gt; -----Original =
Message-----</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; From: Tim Polk [<a
href=3D"mailto:[e-mail]">mailto:[e-mail]</a>]</span></=
font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Sent: Friday, =
September 07,
2001 5:20 PM</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; To: Denis Pinkas; =
Tom Gindin</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Cc: =
IETF-PKIX</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Subject: Re: =
Removing expired
certificates from CRLs.....</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Denis, Tom, et =
al.</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; As one of several =
independent
originators of the idea, </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; (Ambarish Malpani =
is </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; another), I =
thought I ought to
weigh in as well.&nbsp; I had something </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; *considerably* =
simpler in
mind.&nbsp; If a CRL includes revocation </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; information =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; for certificates =
that have
expired, a relying party should be able to </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; determine that =
automatically.</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; I would suggest a =
noncritical
CRL extension with a single </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; value of type =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
GeneralizedTime.&nbsp;&nbsp;
The ASN.1 syntax would be</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ExpiredCertsOnCRL ::=3D GeneralizedTime</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; As usual with PKIX =
times, we
would require time Zulu with </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; seconds (even if =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
zero).</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; The semantics for =
the
extension would be as follows:</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
The scope of a CRL containing this extension is </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; extended to =
include </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; certificates that =
expired&nbsp;
at the exact time specified in the </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; extension or =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; after that =
time.&nbsp; If
limitations in the CRL's scope are specified (by </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; either reason =
codes or by
distribution points), that applies </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; to expired =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; certificates as =
well.</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; IMHO, we shouldn't =
make the
scope of a CRL different for expired and </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; unexpired =
certificates.&nbsp;
This is a simple idea - let's keep </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; it that =
way!</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; BTW, folks were =
wondering why
this hasn't been pursued in </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; PKIX.&nbsp; This =
idea </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; has been floated a =
couple of
times, but no one was really ready to </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; implement =
it.&nbsp; We needed
to concentrate on the core functionality.&nbsp; I </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; floated the idea =
again at one
of the meetings (in San Diego?) </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; and Ambarish =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; said he'd had the =
same idea
and wanted to pursue it.&nbsp; I asked </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; him to delay =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; any new work in =
this area
until the son-of-2459 is approved by the </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; IESG.&nbsp; =
(Neither of us
realized what a long delay we'd agreed to...)</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
Thanks,</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Tim =
Polk</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
</span></font><o:p></o:p></p>

</div>

</body>

</html>

--Boundary_(ID_SnLtbEzNOftJ3a9c4FnrxA)--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8AHj6j02404 for ietf-pkix-bks; Mon, 10 Sep 2001 10:45:06 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8AHj3D02400 for <[e-mail]>; Mon, 10 Sep 2001 10:45:03 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <SSWH8Z3C>; Mon, 10 Sep 2001 13:44:58 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Tom Gindin'" <[e-mail]>
Cc: "'Denis Pinkas'" <[e-mail]>, IETF-PKIX <[e-mail]>
Subject: RE: Removing expired certificates from CRLs.....
Date: Mon, 10 Sep 2001 13:44:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13A20.4E2470A0"
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_01C13A20.4E2470A0
Content-Type: text/plain

Regardless of criticality, the rules for extensibility allow additional
components
to be added to existing extensions without changing the OIDs. However, I
hadn't 
considered the criticality issue and in fact the IDP extension can only be
set to 
critical, so that probably makes it not the most desirable place to add
this. A new
extension is probably a better way to go. Thanks for bringing up the
criticality issue.

Sharon

> -----Original Message-----
> From: Tom Gindin [mailto:[e-mail]]
> Sent: Monday, September 10, 2001 12:25 PM
> To: Sharon Boeyen
> Cc: 'Denis Pinkas'; IETF-PKIX
> Subject: RE: Removing expired certificates from CRLs.....
> 
> 
> 
> 
>      Sharon:
> 
>      Like Denis, I'm in favor of a separate extension, 
> especially since I
> think that excluding revocations of encryption certificates 
> from retention
> is a good idea.  Using the IDP makes it very advisable that 
> the syntax be
> trimmed.  Also, since the IDP is recommended to be critical 
> by both X.509
> and PKIX, wouldn't we have to reassign its OID if we're 
> adding fields to
> the syntax, even in a way that is backwards compatible?  If 
> so, that would
> more than neutralize any advantage to be gained by reusing a 
> well-known
> extension.
> 
>           Tom Gindin
> 
> 
> Sharon Boeyen <[e-mail]>@mail.imc.org on 09/10/2001
> 11:02:03 AM
> 
> Sent by:  [e-mail]
> 
> 
> To:   "'Denis Pinkas'" <[e-mail]>, Sharon Boeyen
>       <[e-mail]>
> cc:   IETF-PKIX <[e-mail]>
> Subject:  RE: Removing expired certificates from CRLs.....
> 
> 
> Denis, I'm not necessarily recommending one approach over the 
> other, just
> raising the
> options for discussion. However, I do want to note that IDP can, but
> obviously need not, be included in a "single big" CRL just as 
> it can be in
> a CRL DP. The only current component that would be likely be 
> present in
> such a CRL would be the name if the IDP.
> 
> 
> Cheers,
> Sharon
> 
> 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Monday, September 10, 2001 10:19 AM
> > To: Sharon Boeyen
> > Cc: IETF-PKIX
> > Subject: Re: Removing expired certificates from CRLs.....
> >
> >
> > Sharon,
> >
> > > Tim, I like this proposal because of its simplicity and
> > given all the
> > > other variable ways we have to set up CRLs, I suspect this,
> > combined with
> > > them, gives more than enough flexibility. Does this need 
> to be a new
> > > extension on its own? It could be, or it could be added as
> > an additional
> > > parameter to the IDP extension. That might be even simpler
> > - thoughts?
> >
> > As implictly said in my e-mail from this morning, I am in 
> favour of an
> > independant extension, so that we do not mandate the use of
> > IDP to have that
> > additional feature. In other words, if the extension were
> > part of IDP, a
> > single big CRL could not benefit of that advantage.
> >
> > Denis
> >
> > > As for the different groups, if there is going to be a new
> > extension of
> > > this sort, I'd like it to be added to 509 and profiled by PKIX, if
> > > possible. If the PKIX groups reaches consensus on what they
> > want quickly
> > > enough, that input can be submitted on behalf of PKIX to
> > the 509 meeting
> > > later this month. The timing is very good this time.
> > >
> > > Cheers,
> > > Sharon
> > >
> > > > -----Original Message-----
> > > > From: Tim Polk [mailto:[e-mail]]
> > > > Sent: Friday, September 07, 2001 5:20 PM
> > > > To: Denis Pinkas; Tom Gindin
> > > > Cc: IETF-PKIX
> > > > Subject: Re: Removing expired certificates from CRLs.....
> > > >
> > > >
> > > >
> > > > Denis, Tom, et al.
> > > >
> > > > As one of several independent originators of the idea,
> > > > (Ambarish Malpani is
> > > > another), I thought I ought to weigh in as well.  I had 
> something
> > > > *considerably* simpler in mind.  If a CRL includes revocation
> > > > information
> > > > for certificates that have expired, a relying party
> > should be able to
> > > > determine that automatically.
> > > >
> > > > I would suggest a noncritical CRL extension with a single
> > > > value of type
> > > > GeneralizedTime.   The ASN.1 syntax would be
> > > >
> > > >       ExpiredCertsOnCRL ::= GeneralizedTime
> > > >
> > > > As usual with PKIX times, we would require time Zulu with
> > > > seconds (even if
> > > > zero).
> > > >
> > > > The semantics for the extension would be as follows:
> > > >
> > > >       The scope of a CRL containing this extension is
> > > > extended to include
> > > > certificates that expired  at the exact time specified in the
> > > > extension or
> > > > after that time.  If limitations in the CRL's scope are
> > specified (by
> > > > either reason codes or by distribution points), that applies
> > > > to expired
> > > > certificates as well.
> > > >
> > > > IMHO, we shouldn't make the scope of a CRL different for
> > expired and
> > > > unexpired certificates.  This is a simple idea - let's keep
> > > > it that way!
> > > >
> > > > BTW, folks were wondering why this hasn't been pursued in
> > > > PKIX.  This idea
> > > > has been floated a couple of times, but no one was 
> really ready to
> > > > implement it.  We needed to concentrate on the core
> > functionality.  I
> > > > floated the idea again at one of the meetings (in San Diego?)
> > > > and Ambarish
> > > > said he'd had the same idea and wanted to pursue it.  I asked
> > > > him to delay
> > > > any new work in this area until the son-of-2459 is 
> approved by the
> > > > IESG.  (Neither of us realized what a long delay we'd
> > agreed to...)
> > > >
> > > > Thanks,
> > > >
> > > > Tim Polk
> > > >
> >
> 
> 
> 

------_=_NextPart_001_01C13A20.4E2470A0
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: Removing expired certificates from CRLs.....</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Regardless of criticality, the rules for extensibility allow additional components</FONT>
<BR><FONT SIZE=2>to be added to existing extensions without changing the OIDs. However, I hadn't </FONT>
<BR><FONT SIZE=2>considered the criticality issue and in fact the IDP extension can only be set to </FONT>
<BR><FONT SIZE=2>critical, so that probably makes it not the most desirable place to add this. A new</FONT>
<BR><FONT SIZE=2>extension is probably a better way to go. Thanks for bringing up the criticality issue.</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: Monday, September 10, 2001 12:25 PM</FONT>
<BR><FONT SIZE=2>&gt; To: Sharon Boeyen</FONT>
<BR><FONT SIZE=2>&gt; Cc: 'Denis Pinkas'; IETF-PKIX</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: Removing expired certificates from CRLs.....</FONT>
<BR><FONT SIZE=2>&gt; </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; Sharon:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Like Denis, I'm in favor of a separate extension, </FONT>
<BR><FONT SIZE=2>&gt; especially since I</FONT>
<BR><FONT SIZE=2>&gt; think that excluding revocations of encryption certificates </FONT>
<BR><FONT SIZE=2>&gt; from retention</FONT>
<BR><FONT SIZE=2>&gt; is a good idea.&nbsp; Using the IDP makes it very advisable that </FONT>
<BR><FONT SIZE=2>&gt; the syntax be</FONT>
<BR><FONT SIZE=2>&gt; trimmed.&nbsp; Also, since the IDP is recommended to be critical </FONT>
<BR><FONT SIZE=2>&gt; by both X.509</FONT>
<BR><FONT SIZE=2>&gt; and PKIX, wouldn't we have to reassign its OID if we're </FONT>
<BR><FONT SIZE=2>&gt; adding fields to</FONT>
<BR><FONT SIZE=2>&gt; the syntax, even in a way that is backwards compatible?&nbsp; If </FONT>
<BR><FONT SIZE=2>&gt; so, that would</FONT>
<BR><FONT SIZE=2>&gt; more than neutralize any advantage to be gained by reusing a </FONT>
<BR><FONT SIZE=2>&gt; well-known</FONT>
<BR><FONT SIZE=2>&gt; extension.</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;@mail.imc.org on 09/10/2001</FONT>
<BR><FONT SIZE=2>&gt; 11:02:03 AM</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Sent by:&nbsp; [e-mail]</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; To:&nbsp;&nbsp; &quot;'Denis Pinkas'&quot; &lt;[e-mail]&gt;, Sharon Boeyen</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; IETF-PKIX &lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=2>&gt; Subject:&nbsp; RE: Removing expired certificates from CRLs.....</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Denis, I'm not necessarily recommending one approach over the </FONT>
<BR><FONT SIZE=2>&gt; other, just</FONT>
<BR><FONT SIZE=2>&gt; raising the</FONT>
<BR><FONT SIZE=2>&gt; options for discussion. However, I do want to note that IDP can, but</FONT>
<BR><FONT SIZE=2>&gt; obviously need not, be included in a &quot;single big&quot; CRL just as </FONT>
<BR><FONT SIZE=2>&gt; it can be in</FONT>
<BR><FONT SIZE=2>&gt; a CRL DP. The only current component that would be likely be </FONT>
<BR><FONT SIZE=2>&gt; present in</FONT>
<BR><FONT SIZE=2>&gt; such a CRL would be the name if the IDP.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Cheers,</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: Denis Pinkas [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>&gt; &gt; Sent: Monday, September 10, 2001 10:19 AM</FONT>
<BR><FONT SIZE=2>&gt; &gt; To: Sharon Boeyen</FONT>
<BR><FONT SIZE=2>&gt; &gt; Cc: IETF-PKIX</FONT>
<BR><FONT SIZE=2>&gt; &gt; Subject: Re: Removing expired certificates from CRLs.....</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Sharon,</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Tim, I like this proposal because of its simplicity and</FONT>
<BR><FONT SIZE=2>&gt; &gt; given all the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; other variable ways we have to set up CRLs, I suspect this,</FONT>
<BR><FONT SIZE=2>&gt; &gt; combined with</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; them, gives more than enough flexibility. Does this need </FONT>
<BR><FONT SIZE=2>&gt; to be a new</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; extension on its own? It could be, or it could be added as</FONT>
<BR><FONT SIZE=2>&gt; &gt; an additional</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; parameter to the IDP extension. That might be even simpler</FONT>
<BR><FONT SIZE=2>&gt; &gt; - thoughts?</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; As implictly said in my e-mail from this morning, I am in </FONT>
<BR><FONT SIZE=2>&gt; favour of an</FONT>
<BR><FONT SIZE=2>&gt; &gt; independant extension, so that we do not mandate the use of</FONT>
<BR><FONT SIZE=2>&gt; &gt; IDP to have that</FONT>
<BR><FONT SIZE=2>&gt; &gt; additional feature. In other words, if the extension were</FONT>
<BR><FONT SIZE=2>&gt; &gt; part of IDP, a</FONT>
<BR><FONT SIZE=2>&gt; &gt; single big CRL could not benefit of that advantage.</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; &gt; As for the different groups, if there is going to be a new</FONT>
<BR><FONT SIZE=2>&gt; &gt; extension of</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; this sort, I'd like it to be added to 509 and profiled by PKIX, if</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; possible. If the PKIX groups reaches consensus on what they</FONT>
<BR><FONT SIZE=2>&gt; &gt; want quickly</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; enough, that input can be submitted on behalf of PKIX to</FONT>
<BR><FONT SIZE=2>&gt; &gt; the 509 meeting</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; later this month. The timing is very good this time.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Cheers,</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Sharon</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; From: Tim Polk [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; Sent: Friday, September 07, 2001 5:20 PM</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; To: Denis Pinkas; Tom Gindin</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; Cc: IETF-PKIX</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; Subject: Re: Removing expired certificates from CRLs.....</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; Denis, Tom, et al.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; As one of several independent originators of the idea,</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; (Ambarish Malpani is</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; another), I thought I ought to weigh in as well.&nbsp; I had </FONT>
<BR><FONT SIZE=2>&gt; something</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; *considerably* simpler in mind.&nbsp; If a CRL includes revocation</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; information</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; for certificates that have expired, a relying party</FONT>
<BR><FONT SIZE=2>&gt; &gt; should be able to</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; determine that automatically.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; I would suggest a noncritical CRL extension with a single</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; value of type</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; GeneralizedTime.&nbsp;&nbsp; The ASN.1 syntax would be</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ExpiredCertsOnCRL ::= GeneralizedTime</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; As usual with PKIX times, we would require time Zulu with</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; seconds (even if</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; zero).</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; The semantics for the extension would be as follows:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The scope of a CRL containing this extension is</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; extended to include</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; certificates that expired&nbsp; at the exact time specified in the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; extension or</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; after that time.&nbsp; If limitations in the CRL's scope are</FONT>
<BR><FONT SIZE=2>&gt; &gt; specified (by</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; either reason codes or by distribution points), that applies</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; to expired</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; certificates as well.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; IMHO, we shouldn't make the scope of a CRL different for</FONT>
<BR><FONT SIZE=2>&gt; &gt; expired and</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; unexpired certificates.&nbsp; This is a simple idea - let's keep</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; it that way!</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; BTW, folks were wondering why this hasn't been pursued in</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; PKIX.&nbsp; This idea</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; has been floated a couple of times, but no one was </FONT>
<BR><FONT SIZE=2>&gt; really ready to</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; implement it.&nbsp; We needed to concentrate on the core</FONT>
<BR><FONT SIZE=2>&gt; &gt; functionality.&nbsp; I</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; floated the idea again at one of the meetings (in San Diego?)</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; and Ambarish</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; said he'd had the same idea and wanted to pursue it.&nbsp; I asked</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; him to delay</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; any new work in this area until the son-of-2459 is </FONT>
<BR><FONT SIZE=2>&gt; approved by the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; IESG.&nbsp; (Neither of us realized what a long delay we'd</FONT>
<BR><FONT SIZE=2>&gt; &gt; agreed to...)</FONT>
<BR><FONT SIZE=2>&gt; &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;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C13A20.4E2470A0--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8AGTHB00289 for ietf-pkix-bks; Mon, 10 Sep 2001 09:29:17 -0700 (PDT)
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8AGTFD00284 for <[e-mail]>; Mon, 10 Sep 2001 09:29:15 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA153134; Mon, 10 Sep 2001 12:26:46 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8AGGVd160892; Mon, 10 Sep 2001 12:16:46 -0400
Importance: Normal
Subject: RE: Removing expired certificates from CRLs.....
To: Sharon Boeyen <[e-mail]>
Cc: "'Denis Pinkas'" <[e-mail]>, IETF-PKIX <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Mon, 10 Sep 2001 12:24:32 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.8 SPR #MIAS4UTJ8H |June 21, 2001) at 09/10/2001 12:24:54 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>

     Sharon:

     Like Denis, I'm in favor of a separate extension, especially since I
think that excluding revocations of encryption certificates from retention
is a good idea.  Using the IDP makes it very advisable that the syntax be
trimmed.  Also, since the IDP is recommended to be critical by both X.509
and PKIX, wouldn't we have to reassign its OID if we're adding fields to
the syntax, even in a way that is backwards compatible?  If so, that would
more than neutralize any advantage to be gained by reusing a well-known
extension.

          Tom Gindin


Sharon Boeyen <[e-mail]>@mail.imc.org on 09/10/2001
11:02:03 AM

Sent by:  [e-mail]


To:   "'Denis Pinkas'" <[e-mail]>, Sharon Boeyen
      <[e-mail]>
cc:   IETF-PKIX <[e-mail]>
Subject:  RE: Removing expired certificates from CRLs.....


Denis, I'm not necessarily recommending one approach over the other, just
raising the
options for discussion. However, I do want to note that IDP can, but
obviously need not, be included in a "single big" CRL just as it can be in
a CRL DP. The only current component that would be likely be present in
such a CRL would be the name if the IDP.


Cheers,
Sharon


> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Monday, September 10, 2001 10:19 AM
> To: Sharon Boeyen
> Cc: IETF-PKIX
> Subject: Re: Removing expired certificates from CRLs.....
>
>
> Sharon,
>
> > Tim, I like this proposal because of its simplicity and
> given all the
> > other variable ways we have to set up CRLs, I suspect this,
> combined with
> > them, gives more than enough flexibility. Does this need to be a new
> > extension on its own? It could be, or it could be added as
> an additional
> > parameter to the IDP extension. That might be even simpler
> - thoughts?
>
> As implictly said in my e-mail from this morning, I am in favour of an
> independant extension, so that we do not mandate the use of
> IDP to have that
> additional feature. In other words, if the extension were
> part of IDP, a
> single big CRL could not benefit of that advantage.
>
> Denis
>
> > As for the different groups, if there is going to be a new
> extension of
> > this sort, I'd like it to be added to 509 and profiled by PKIX, if
> > possible. If the PKIX groups reaches consensus on what they
> want quickly
> > enough, that input can be submitted on behalf of PKIX to
> the 509 meeting
> > later this month. The timing is very good this time.
> >
> > Cheers,
> > Sharon
> >
> > > -----Original Message-----
> > > From: Tim Polk [mailto:[e-mail]]
> > > Sent: Friday, September 07, 2001 5:20 PM
> > > To: Denis Pinkas; Tom Gindin
> > > Cc: IETF-PKIX
> > > Subject: Re: Removing expired certificates from CRLs.....
> > >
> > >
> > >
> > > Denis, Tom, et al.
> > >
> > > As one of several independent originators of the idea,
> > > (Ambarish Malpani is
> > > another), I thought I ought to weigh in as well.  I had something
> > > *considerably* simpler in mind.  If a CRL includes revocation
> > > information
> > > for certificates that have expired, a relying party
> should be able to
> > > determine that automatically.
> > >
> > > I would suggest a noncritical CRL extension with a single
> > > value of type
> > > GeneralizedTime.   The ASN.1 syntax would be
> > >
> > >       ExpiredCertsOnCRL ::= GeneralizedTime
> > >
> > > As usual with PKIX times, we would require time Zulu with
> > > seconds (even if
> > > zero).
> > >
> > > The semantics for the extension would be as follows:
> > >
> > >       The scope of a CRL containing this extension is
> > > extended to include
> > > certificates that expired  at the exact time specified in the
> > > extension or
> > > after that time.  If limitations in the CRL's scope are
> specified (by
> > > either reason codes or by distribution points), that applies
> > > to expired
> > > certificates as well.
> > >
> > > IMHO, we shouldn't make the scope of a CRL different for
> expired and
> > > unexpired certificates.  This is a simple idea - let's keep
> > > it that way!
> > >
> > > BTW, folks were wondering why this hasn't been pursued in
> > > PKIX.  This idea
> > > has been floated a couple of times, but no one was really ready to
> > > implement it.  We needed to concentrate on the core
> functionality.  I
> > > floated the idea again at one of the meetings (in San Diego?)
> > > and Ambarish
> > > said he'd had the same idea and wanted to pursue it.  I asked
> > > him to delay
> > > any new work in this area until the son-of-2459 is approved by the
> > > IESG.  (Neither of us realized what a long delay we'd
> agreed to...)
> > >
> > > Thanks,
> > >
> > > Tim Polk
> > >
>





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8AFdHs25088 for ietf-pkix-bks; Mon, 10 Sep 2001 08:39:17 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8AFdED25077 for <[e-mail]>; Mon, 10 Sep 2001 08:39:14 -0700 (PDT)
Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 10 Sep 2001 09:39:16 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Mon, 10 Sep 2001 09:41:42 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Subject: XACML OID tag?
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=_A5FF0FB4.B6D7B504"
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.

--=_A5FF0FB4.B6D7B504
Content-Type: text/plain; charset=ISO-8859-7
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This is join to sound like heresy, but has anyone defined an OID tag for =
XACML, so that an XACML string could be included in a X.509 certificate?

Now, I fully expect to be assailed from both sides for this question =AF =
one for mixing XML into a bastardized certificate format instead of using =
pure ASN.1 as God obviously intended, and the other for daring to pour =
holy XML into such an impure, defiled, and unclean vessel as an X.509 =
certificate.

So be it, and let the flames begin.

But I'm observing that conventional, identity-based PKI is suffering what =
the medical community calls a "failure to thrive", with the sole exception =
being SSL certificates issued by the TTP CAs, with VeriSign obviously =
having the mind share in that space.

Toolkits which would provide enterprises to issue their own certificates =
have so far failed to take off to any significant degree (ours included), =
with the consequence that some of those vendors, who once flew so high, =
are close to being delisted by the NASDAQ.

One of the reasons, I believe, is that the neither the public TTPs nor the =
toolkit vendors have so far adequately addressed the important issue of =
providing a cross-enterprise Privilege Management Infrastructure solution. =
 And now that they are feeling a very significant financial pinch, they =
may not have the wherewithal to solve that problem.

Maybe it's just the religion of the week (XML) creating an evangelistic =
fervor, but that's where the buzz seems to be these days.  And I'd rather =
drop some XACML into an X.509 certificate and make use of the existing =
tools, rather than create everything from scratch.  And yes, if X.509 =
attribute certificates had been better thought out and/or more widely =
implemented, maybe this wouldn't be necessary. And if pigs could whistle =
and cows could fly, then the world would be a much different place.

Anyway, does anyone have such an OID and a suggested way to use it?  If =
not, I guess I'll explore rolling my own, unless someone else wants to =
join in the fun.

Bob

Robert R. Jueneman
Security Architect

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




--=_A5FF0FB4.B6D7B504
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


--=_A5FF0FB4.B6D7B504--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8AF2Do22918 for ietf-pkix-bks; Mon, 10 Sep 2001 08:02:13 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8AF29D22905 for <[e-mail]>; Mon, 10 Sep 2001 08:02:10 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <SSWH8WWK>; Mon, 10 Sep 2001 11:02:04 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, Sharon Boeyen <[e-mail]>
Cc: IETF-PKIX <[e-mail]>
Subject: RE: Removing expired certificates from CRLs.....
Date: Mon, 10 Sep 2001 11:02:03 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13A09.8D15D720"
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_01C13A09.8D15D720
Content-Type: text/plain

Denis, I'm not necessarily recommending one approach over the other, just
raising the 
options for discussion. However, I do want to note that IDP can, but
obviously need not, be included in a "single big" CRL just as it can be in a
CRL DP. The only current component that would be likely be present in such a
CRL would be the name if the IDP. 

Cheers,
Sharon

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Monday, September 10, 2001 10:19 AM
> To: Sharon Boeyen
> Cc: IETF-PKIX
> Subject: Re: Removing expired certificates from CRLs.....
> 
> 
> Sharon,
> 
> > Tim, I like this proposal because of its simplicity and 
> given all the
> > other variable ways we have to set up CRLs, I suspect this, 
> combined with
> > them, gives more than enough flexibility. Does this need to be a new
> > extension on its own? It could be, or it could be added as 
> an additional
> > parameter to the IDP extension. That might be even simpler 
> - thoughts?
> 
> As implictly said in my e-mail from this morning, I am in favour of an
> independant extension, so that we do not mandate the use of 
> IDP to have that
> additional feature. In other words, if the extension were 
> part of IDP, a
> single big CRL could not benefit of that advantage.
> 
> Denis
> 
> > As for the different groups, if there is going to be a new 
> extension of
> > this sort, I'd like it to be added to 509 and profiled by PKIX, if
> > possible. If the PKIX groups reaches consensus on what they 
> want quickly
> > enough, that input can be submitted on behalf of PKIX to 
> the 509 meeting
> > later this month. The timing is very good this time.
> > 
> > Cheers,
> > Sharon
> > 
> > > -----Original Message-----
> > > From: Tim Polk [mailto:[e-mail]]
> > > Sent: Friday, September 07, 2001 5:20 PM
> > > To: Denis Pinkas; Tom Gindin
> > > Cc: IETF-PKIX
> > > Subject: Re: Removing expired certificates from CRLs.....
> > >
> > >
> > >
> > > Denis, Tom, et al.
> > >
> > > As one of several independent originators of the idea,
> > > (Ambarish Malpani is
> > > another), I thought I ought to weigh in as well.  I had something
> > > *considerably* simpler in mind.  If a CRL includes revocation
> > > information
> > > for certificates that have expired, a relying party 
> should be able to
> > > determine that automatically.
> > >
> > > I would suggest a noncritical CRL extension with a single
> > > value of type
> > > GeneralizedTime.   The ASN.1 syntax would be
> > >
> > >       ExpiredCertsOnCRL ::= GeneralizedTime
> > >
> > > As usual with PKIX times, we would require time Zulu with
> > > seconds (even if
> > > zero).
> > >
> > > The semantics for the extension would be as follows:
> > >
> > >       The scope of a CRL containing this extension is
> > > extended to include
> > > certificates that expired  at the exact time specified in the
> > > extension or
> > > after that time.  If limitations in the CRL's scope are 
> specified (by
> > > either reason codes or by distribution points), that applies
> > > to expired
> > > certificates as well.
> > >
> > > IMHO, we shouldn't make the scope of a CRL different for 
> expired and
> > > unexpired certificates.  This is a simple idea - let's keep
> > > it that way!
> > >
> > > BTW, folks were wondering why this hasn't been pursued in
> > > PKIX.  This idea
> > > has been floated a couple of times, but no one was really ready to
> > > implement it.  We needed to concentrate on the core 
> functionality.  I
> > > floated the idea again at one of the meetings (in San Diego?)
> > > and Ambarish
> > > said he'd had the same idea and wanted to pursue it.  I asked
> > > him to delay
> > > any new work in this area until the son-of-2459 is approved by the
> > > IESG.  (Neither of us realized what a long delay we'd 
> agreed to...)
> > >
> > > Thanks,
> > >
> > > Tim Polk
> > >
> 

------_=_NextPart_001_01C13A09.8D15D720
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: Removing expired certificates from CRLs.....</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Denis, I'm not necessarily recommending one approach =
over the other, just raising the </FONT>
<BR><FONT SIZE=3D2>options for discussion. However, I do want to note =
that IDP can, but obviously need not, be included in a &quot;single =
big&quot; CRL just as it can be in a CRL DP. The only current component =
that would be likely be present in such a CRL would be the name if the =
IDP. </FONT></P>

<P><FONT SIZE=3D2>Cheers,</FONT>
<BR><FONT SIZE=3D2>Sharon</FONT>
</P>

<P><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: Monday, September 10, 2001 10:19 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Sharon Boeyen</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: IETF-PKIX</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: Removing expired certificates from =
CRLs.....</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Sharon,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Tim, I like this proposal because of its =
simplicity and </FONT>
<BR><FONT SIZE=3D2>&gt; given all the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; other variable ways we have to set up =
CRLs, I suspect this, </FONT>
<BR><FONT SIZE=3D2>&gt; combined with</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; them, gives more than enough flexibility. =
Does this need to be a new</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; extension on its own? It could be, or it =
could be added as </FONT>
<BR><FONT SIZE=3D2>&gt; an additional</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; parameter to the IDP extension. That might =
be even simpler </FONT>
<BR><FONT SIZE=3D2>&gt; - thoughts?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; As implictly said in my e-mail from this =
morning, I am in favour of an</FONT>
<BR><FONT SIZE=3D2>&gt; independant extension, so that we do not =
mandate the use of </FONT>
<BR><FONT SIZE=3D2>&gt; IDP to have that</FONT>
<BR><FONT SIZE=3D2>&gt; additional feature. In other words, if the =
extension were </FONT>
<BR><FONT SIZE=3D2>&gt; part of IDP, a</FONT>
<BR><FONT SIZE=3D2>&gt; single big CRL could not benefit of that =
advantage.</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; As for the different groups, if there is =
going to be a new </FONT>
<BR><FONT SIZE=3D2>&gt; extension of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; this sort, I'd like it to be added to 509 =
and profiled by PKIX, if</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; possible. If the PKIX groups reaches =
consensus on what they </FONT>
<BR><FONT SIZE=3D2>&gt; want quickly</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; enough, that input can be submitted on =
behalf of PKIX to </FONT>
<BR><FONT SIZE=3D2>&gt; the 509 meeting</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; later this month. The timing is very good =
this time.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cheers,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sharon</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; From: Tim Polk [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Sent: Friday, September 07, 2001 5:20 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; To: Denis Pinkas; Tom Gindin</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Cc: IETF-PKIX</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Subject: Re: Removing expired =
certificates from CRLs.....</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Denis, Tom, et al.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; As one of several independent =
originators of the idea,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; (Ambarish Malpani is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; another), I thought I ought to weigh =
in as well.&nbsp; I had something</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; *considerably* simpler in mind.&nbsp; =
If a CRL includes revocation</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; information</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; for certificates that have expired, a =
relying party </FONT>
<BR><FONT SIZE=3D2>&gt; should be able to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; determine that automatically.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; I would suggest a noncritical CRL =
extension with a single</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; value of type</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; GeneralizedTime.&nbsp;&nbsp; The =
ASN.1 syntax would be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
ExpiredCertsOnCRL ::=3D GeneralizedTime</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; As usual with PKIX times, we would =
require time Zulu with</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; seconds (even if</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; zero).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; The semantics for the extension would =
be as follows:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
The scope of a CRL containing this extension is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; extended to include</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; certificates that expired&nbsp; at =
the exact time specified in the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; extension or</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; after that time.&nbsp; If limitations =
in the CRL's scope are </FONT>
<BR><FONT SIZE=3D2>&gt; specified (by</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; either reason codes or by =
distribution points), that applies</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; to expired</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; certificates as well.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; IMHO, we shouldn't make the scope of =
a CRL different for </FONT>
<BR><FONT SIZE=3D2>&gt; expired and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; unexpired certificates.&nbsp; This is =
a simple idea - let's keep</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; it that way!</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; BTW, folks were wondering why this =
hasn't been pursued in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; PKIX.&nbsp; This idea</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; has been floated a couple of times, =
but no one was really ready to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; implement it.&nbsp; We needed to =
concentrate on the core </FONT>
<BR><FONT SIZE=3D2>&gt; functionality.&nbsp; I</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; floated the idea again at one of the =
meetings (in San Diego?)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; and Ambarish</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; said he'd had the same idea and =
wanted to pursue it.&nbsp; I asked</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; him to delay</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; any new work in this area until the =
son-of-2459 is approved by the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; IESG.&nbsp; (Neither of us realized =
what a long delay we'd </FONT>
<BR><FONT SIZE=3D2>&gt; agreed to...)</FONT>
<BR><FONT SIZE=3D2>&gt; &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; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C13A09.8D15D720--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8AEMJ418962 for ietf-pkix-bks; Mon, 10 Sep 2001 07:22:19 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8AEMFD18958 for <[e-mail]>; Mon, 10 Sep 2001 07:22:15 -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 QAA12858; Mon, 10 Sep 2001 16:23:01 +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 QAA16286; Mon, 10 Sep 2001 16:20:25 +0200
Message-ID: <[e-mail]>
Date: Mon, 10 Sep 2001 16:19:23 +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: IETF-PKIX <[e-mail]>
Subject: Re: Removing expired certificates from 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>

Sharon,

> Tim, I like this proposal because of its simplicity and given all the
> other variable ways we have to set up CRLs, I suspect this, combined with
> them, gives more than enough flexibility. Does this need to be a new
> extension on its own? It could be, or it could be added as an additional
> parameter to the IDP extension. That might be even simpler - thoughts?

As implictly said in my e-mail from this morning, I am in favour of an
independant extension, so that we do not mandate the use of IDP to have that
additional feature. In other words, if the extension were part of IDP, a
single big CRL could not benefit of that advantage.

Denis

> As for the different groups, if there is going to be a new extension of
> this sort, I'd like it to be added to 509 and profiled by PKIX, if
> possible. If the PKIX groups reaches consensus on what they want quickly
> enough, that input can be submitted on behalf of PKIX to the 509 meeting
> later this month. The timing is very good this time.
> 
> Cheers,
> Sharon
> 
> > -----Original Message-----
> > From: Tim Polk [mailto:[e-mail]]
> > Sent: Friday, September 07, 2001 5:20 PM
> > To: Denis Pinkas; Tom Gindin
> > Cc: IETF-PKIX
> > Subject: Re: Removing expired certificates from CRLs.....
> >
> >
> >
> > Denis, Tom, et al.
> >
> > As one of several independent originators of the idea,
> > (Ambarish Malpani is
> > another), I thought I ought to weigh in as well.  I had something
> > *considerably* simpler in mind.  If a CRL includes revocation
> > information
> > for certificates that have expired, a relying party should be able to
> > determine that automatically.
> >
> > I would suggest a noncritical CRL extension with a single
> > value of type
> > GeneralizedTime.   The ASN.1 syntax would be
> >
> >       ExpiredCertsOnCRL ::= GeneralizedTime
> >
> > As usual with PKIX times, we would require time Zulu with
> > seconds (even if
> > zero).
> >
> > The semantics for the extension would be as follows:
> >
> >       The scope of a CRL containing this extension is
> > extended to include
> > certificates that expired  at the exact time specified in the
> > extension or
> > after that time.  If limitations in the CRL's scope are specified (by
> > either reason codes or by distribution points), that applies
> > to expired
> > certificates as well.
> >
> > IMHO, we shouldn't make the scope of a CRL different for expired and
> > unexpired certificates.  This is a simple idea - let's keep
> > it that way!
> >
> > BTW, folks were wondering why this hasn't been pursued in
> > PKIX.  This idea
> > has been floated a couple of times, but no one was really ready to
> > implement it.  We needed to concentrate on the core functionality.  I
> > floated the idea again at one of the meetings (in San Diego?)
> > and Ambarish
> > said he'd had the same idea and wanted to pursue it.  I asked
> > him to delay
> > any new work in this area until the son-of-2459 is approved by the
> > IESG.  (Neither of us realized what a long delay we'd agreed to...)
> >
> > Thanks,
> >
> > Tim Polk
> >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8AEA7M18722 for ietf-pkix-bks; Mon, 10 Sep 2001 07:10:07 -0700 (PDT)
Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8AEA4D18716 for <[e-mail]>; Mon, 10 Sep 2001 07:10:04 -0700 (PDT)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <SSXMWX78>; Mon, 10 Sep 2001 10:09:58 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Tim Polk'" <[e-mail]>, Denis Pinkas <[e-mail]>, Tom Gindin <[e-mail]>
Cc: IETF-PKIX <[e-mail]>
Subject: RE: Removing expired certificates from CRLs.....
Date: Mon, 10 Sep 2001 10:09:57 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13A02.45A680D0"
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_01C13A02.45A680D0
Content-Type: text/plain

Tim, I like this proposal because of its simplicity and given all the other
variable ways we have to set up CRLs, I suspect this, combined with them,
gives more than enough flexibility. Does this need to be a new extension on
its own? It could be, or it could be added as an additional parameter to the
IDP extension. That might be even simpler - thoughts?

As for the different groups, if there is going to be a new extension of this
sort, I'd like it to be added to 509 and profiled by PKIX, if possible. If
the PKIX groups reaches consensus on what they want quickly enough, that
input can be submitted on behalf of PKIX to the 509 meeting later this
month. The timing is very good this time.

Cheers,
Sharon

> -----Original Message-----
> From: Tim Polk [mailto:[e-mail]]
> Sent: Friday, September 07, 2001 5:20 PM
> To: Denis Pinkas; Tom Gindin
> Cc: IETF-PKIX
> Subject: Re: Removing expired certificates from CRLs.....
> 
> 
> 
> Denis, Tom, et al.
> 
> As one of several independent originators of the idea, 
> (Ambarish Malpani is 
> another), I thought I ought to weigh in as well.  I had something 
> *considerably* simpler in mind.  If a CRL includes revocation 
> information 
> for certificates that have expired, a relying party should be able to 
> determine that automatically.
> 
> I would suggest a noncritical CRL extension with a single 
> value of type 
> GeneralizedTime.   The ASN.1 syntax would be
> 
> 	ExpiredCertsOnCRL ::= GeneralizedTime
> 
> As usual with PKIX times, we would require time Zulu with 
> seconds (even if 
> zero).
> 
> The semantics for the extension would be as follows:
> 
> 	The scope of a CRL containing this extension is 
> extended to include 
> certificates that expired  at the exact time specified in the 
> extension or 
> after that time.  If limitations in the CRL's scope are specified (by 
> either reason codes or by distribution points), that applies 
> to expired 
> certificates as well.
> 
> IMHO, we shouldn't make the scope of a CRL different for expired and 
> unexpired certificates.  This is a simple idea - let's keep 
> it that way!
> 
> BTW, folks were wondering why this hasn't been pursued in 
> PKIX.  This idea 
> has been floated a couple of times, but no one was really ready to 
> implement it.  We needed to concentrate on the core functionality.  I 
> floated the idea again at one of the meetings (in San Diego?) 
> and Ambarish 
> said he'd had the same idea and wanted to pursue it.  I asked 
> him to delay 
> any new work in this area until the son-of-2459 is approved by the 
> IESG.  (Neither of us realized what a long delay we'd agreed to...)
> 
> Thanks,
> 
> Tim Polk
> 

------_=_NextPart_001_01C13A02.45A680D0
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: Removing expired certificates from CRLs.....</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Tim, I like this proposal because of its simplicity =
and given all the other variable ways we have to set up CRLs, I suspect =
this, combined with them, gives more than enough flexibility. Does this =
need to be a new extension on its own? It could be, or it could be =
added as an additional parameter to the IDP extension. That might be =
even simpler - thoughts?</FONT></P>

<P><FONT SIZE=3D2>As for the different groups, if there is going to be =
a new extension of this sort, I'd like it to be added to 509 and =
profiled by PKIX, if possible. If the PKIX groups reaches consensus on =
what they want quickly enough, that input can be submitted on behalf of =
PKIX to the 509 meeting later this month. The timing is very good this =
time.</FONT></P>

<P><FONT SIZE=3D2>Cheers,</FONT>
<BR><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: Friday, September 07, 2001 5:20 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Denis Pinkas; Tom Gindin</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: IETF-PKIX</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: Removing expired certificates from =
CRLs.....</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Denis, Tom, et al.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; As one of several independent originators of =
the idea, </FONT>
<BR><FONT SIZE=3D2>&gt; (Ambarish Malpani is </FONT>
<BR><FONT SIZE=3D2>&gt; another), I thought I ought to weigh in as =
well.&nbsp; I had something </FONT>
<BR><FONT SIZE=3D2>&gt; *considerably* simpler in mind.&nbsp; If a CRL =
includes revocation </FONT>
<BR><FONT SIZE=3D2>&gt; information </FONT>
<BR><FONT SIZE=3D2>&gt; for certificates that have expired, a relying =
party should be able to </FONT>
<BR><FONT SIZE=3D2>&gt; determine that automatically.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I would suggest a noncritical CRL extension =
with a single </FONT>
<BR><FONT SIZE=3D2>&gt; value of type </FONT>
<BR><FONT SIZE=3D2>&gt; GeneralizedTime.&nbsp;&nbsp; The ASN.1 syntax =
would be</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
ExpiredCertsOnCRL ::=3D GeneralizedTime</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; As usual with PKIX times, we would require time =
Zulu with </FONT>
<BR><FONT SIZE=3D2>&gt; seconds (even if </FONT>
<BR><FONT SIZE=3D2>&gt; zero).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The semantics for the extension would be as =
follows:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The scope of a =
CRL containing this extension is </FONT>
<BR><FONT SIZE=3D2>&gt; extended to include </FONT>
<BR><FONT SIZE=3D2>&gt; certificates that expired&nbsp; at the exact =
time specified in the </FONT>
<BR><FONT SIZE=3D2>&gt; extension or </FONT>
<BR><FONT SIZE=3D2>&gt; after that time.&nbsp; If limitations in the =
CRL's scope are specified (by </FONT>
<BR><FONT SIZE=3D2>&gt; either reason codes or by distribution points), =
that applies </FONT>
<BR><FONT SIZE=3D2>&gt; to expired </FONT>
<BR><FONT SIZE=3D2>&gt; certificates as well.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; IMHO, we shouldn't make the scope of a CRL =
different for expired and </FONT>
<BR><FONT SIZE=3D2>&gt; unexpired certificates.&nbsp; This is a simple =
idea - let's keep </FONT>
<BR><FONT SIZE=3D2>&gt; it that way!</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; BTW, folks were wondering why this hasn't been =
pursued in </FONT>
<BR><FONT SIZE=3D2>&gt; PKIX.&nbsp; This idea </FONT>
<BR><FONT SIZE=3D2>&gt; has been floated a couple of times, but no one =
was really ready to </FONT>
<BR><FONT SIZE=3D2>&gt; implement it.&nbsp; We needed to concentrate on =
the core functionality.&nbsp; I </FONT>
<BR><FONT SIZE=3D2>&gt; floated the idea again at one of the meetings =
(in San Diego?) </FONT>
<BR><FONT SIZE=3D2>&gt; and Ambarish </FONT>
<BR><FONT SIZE=3D2>&gt; said he'd had the same idea and wanted to =
pursue it.&nbsp; I asked </FONT>
<BR><FONT SIZE=3D2>&gt; him to delay </FONT>
<BR><FONT SIZE=3D2>&gt; any new work in this area until the son-of-2459 =
is approved by the </FONT>
<BR><FONT SIZE=3D2>&gt; IESG.&nbsp; (Neither of us realized what a long =
delay we'd agreed to...)</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>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C13A02.45A680D0--


Received: by above.proper.com (8.11.6/8.11.3) id f8A7s8n20862 for ietf-pkix-bks; Mon, 10 Sep 2001 00:54:08 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8A7s6D20855 for <[e-mail]>; Mon, 10 Sep 2001 00:54: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 JAA29672; Mon, 10 Sep 2001 09:53:34 +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 JAA15022; Mon, 10 Sep 2001 09:50:57 +0200
Message-ID: <[e-mail]>
Date: Mon, 10 Sep 2001 09:51:04 +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: Tim Polk <[e-mail]>
CC: Tom Gindin <[e-mail]>, IETF-PKIX <[e-mail]>
Subject: Re: Removing expired certificates from 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>

Tim,

> Denis, Tom, et al.
> 
> As one of several independent originators of the idea, (Ambarish Malpani is
> another), I thought I ought to weigh in as well.  I had something
> *considerably* simpler in mind.  If a CRL includes revocation information
> for certificates that have expired, a relying party should be able to
> determine that automatically.

We strongly agree on that statement.

> I would suggest a noncritical CRL extension with a single value of type
> GeneralizedTime.   The ASN.1 syntax would be
> 
>         ExpiredCertsOnCRL ::= GeneralizedTime
> 
> As usual with PKIX times, we would require time Zulu with seconds (even if
> zero).
> 
> The semantics for the extension would be as follows:
> 
>         The scope of a CRL containing this extension is extended to include
> certificates that expired  at the exact time specified in the extension or
> after that time.  If limitations in the CRL's scope are specified (by
> either reason codes or by distribution points), that applies to expired
> certificates as well.

As Tom said, in practice we would expect certificates with the DS bit set
with a retention period of two or three days, while certificates with the NR
bit set with a retention period of about one month. For other certificates,
it would be the next *scheduled* CRL after revocation.

An option is to say that all certificates from a CRL are maintained for a
fixed time, e.g. one month more. This does not increase the size of CRLs
indefinitively and, as Tim says, is simple enough. 

If different retention periods are needed, there is still a solution, but
there is a price to pay: use CRL Distribution Points with different reason
codes. This means that certificates must originally be produced with this
feature. If there aren't ... then this is not possible.
 
I can buy that simplicity, as long as we include such explanations in the
text.

Denis

> IMHO, we shouldn't make the scope of a CRL different for expired and
> unexpired certificates.  This is a simple idea - let's keep it that way!
> 
> BTW, folks were wondering why this hasn't been pursued in PKIX.  This idea
> has been floated a couple of times, but no one was really ready to
> implement it.  We needed to concentrate on the core functionality.  I
> floated the idea again at one of the meetings (in San Diego?) and Ambarish
> said he'd had the same idea and wanted to pursue it.  I asked him to delay
> any new work in this area until the son-of-2459 is approved by the
> IESG.  (Neither of us realized what a long delay we'd agreed to...)
> 
> Thanks,
> 
> Tim Polk


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f89Ni1W16666 for ietf-pkix-bks; Sun, 9 Sep 2001 16:44:01 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f89NheD16659 for <[e-mail]>; Sun, 9 Sep 2001 16:43:40 -0700 (PDT)
Received: from [128.33.238.15] (TC015.BBN.COM [128.33.238.15]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA16084; Sun, 9 Sep 2001 19:43:06 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010400b7c1ae34753e@[128.33.238.15]>
In-Reply-To: <[e-mail]>
References: <p0501040bb7a8214adf35@[128.33.84.34]>			 <[e-mail]> <p0501040ab7b458549900@[128.33.238.96]>		 <[e-mail]> <p05010403b7bab9e15dcc@[128.33.84.34]>	 <[e-mail]> <p05010404b7bbdfb8674d@[128.33.84.34]> <[e-mail]>
Date: Sun, 9 Sep 2001 19:42:04 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: charter revisions
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 f89NheD16660
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 8:03 PM +0200 9/7/01, Michael Ströder wrote:
>Stephen Kent wrote:
>>
>>  There is not a central registry for DNs
>>  where the CA can check to verify that the company in question is
>>  entitled to use the DN it proposes. Certainly this is true if the
>>  U.S. So, since CAs regularly make value judgements about
>>  appropriateness of DNs given imperfect inputs, I don't see the logo
>>  "verification" as something fundamentally different and harder.
>
>Hmm, do you really want to argue based on these practices?
>Now guess how serious I'll take this argument...

OK, you're on. In the U.S. try to find a definitive database that 
will allow a CA to verify an organization's claim to use a DN. On the 
other hand, the U.S.  Patent and Trademark Office (PTO) has a web 
site listing all names in the U.S. to which trademarks have been 
issued.

Your turn ...

>
>>  >But this is completely pedantic. The original issue was that a logo can
>>  >change appearance when it's scaled or mapped to different colors. A pink
>>  >circle is different from a green circle for trademark and copyright
>>  >purposes. But how do you distinguish them when they're displayed on a
>>  >black and white screen? I don't think that web page technology has any
>>  >magic bullets in this area. And what about blind users? With URLs, they
>>  >can have their screen-reader read the URL back to them. Graphics will be
>>  >completely inaccessible.
>>
>>  Good points about the limitations of a logo.
>
>+1
>
>I don't believe that the displaying problems can be solved.

Your belief is not a basis for making this sort of decision. 
Translated to a less self-centric statement, it becomes a hard 
statement to prove.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f89NTNe16269 for ietf-pkix-bks; Sun, 9 Sep 2001 16:29:23 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f89NTLD16264 for <[e-mail]>; Sun, 9 Sep 2001 16:29:21 -0700 (PDT)
Received: from [128.33.238.15] (TC015.BBN.COM [128.33.238.15]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA15491; Sun, 9 Sep 2001 19:28:53 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <p05010408b7c16acc13f1@[128.33.84.35]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Sun, 9 Sep 2001 15:06:38 -0400
To: "Bob Jueneman" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: charter revisions
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>

At 2:04 PM -0600 9/5/01, Bob Jueneman wrote:
>  >Bob Jueneman wrote:
>>>  I wasn't suggesting that logos should be restricted to end-entities,
>>>  I was only pointing out that such a restriction would immediately
>>>  make the issue of name subordination and misuse of the logo by some
>>>  intermediate CA go away.
>>
>>This isn't true. Name constraints allow me to cross certify IBM's CA but
>>indicate that the only DNs it is trusted to certify are those that begin
>>with "c=us, o=IBM". Even if logos are restricted to end-entities,
>>there's nothing stopping IBM's CA from placing a Sun logo in an
>>end-entity certificate. So restricting logos to end-entities doesn't
>>"make the issue of name subordination and misuse of the logo by some
>>intermediate CA go away."
>
>Sorry, Steve, you are quite correct in that sense.  I guess I wasn't 
>thinking about corporate logos tied to organizational persons as 
>much as I was thinking about brand identification, where the brand 
>isn't owned by the superior CA in any case, any more than VeriSign 
>owns c=us, o=Sun. In any case, name subordination is a very limited 
>mechanism, that solves a problem that basically doesn't exist.  How 
>many subordinate CAs can you point to that aren't owned and 
>controlled by the parent CA?  And how many browsers or other client 
>software correctly implement the constraint?  And how do you apply a 
>name subordination constraint to a DNS name for SSL - restrict it to 
>entities registered under .com?

As a long term supporter of using the name constraints extension, I 
feel compelled to comment on this aspect of the discussion.

Name constraints work well when organizations as as CAs for 
themselves. Under such circumstances, cross certification represents 
not a declaration of "trust" between the cross certifying 
organizations, but a recognition of the authority of each 
organization re its respective name space.  This works well for all 
tree-structured names spaces where such authority is clear.  The DNS 
name space is an excellent example.

The areas where name constraints do not work well, or only in very 
limited fashion, are instances where a CA is not authoritative for 
the name space in which it issue certificates. Public TTP CAs ate the 
best example here. The best one can do when  cross certifying a CA of 
this sort is to use the excluded subtrees facility to prevent certs 
issued by that CA from being accepted if they claim to be for 
entities within one's own name space.  (Well, one could do even 
better, by adding to the excluded subtrees the name spaces of other 
organizations which you have directly cross certified, but this might 
become burdensome.)

So-called bridge CAs also suffer in this regard, and admit a similar 
set of partial safeguards certs.

Note that governmental CAs, of the sort that a number of countries 
are exploring or deploying, also can make good use of name 
constraints in the certs they issue to organizational CAs.

So, the problem with name constraints in practice arises from the 
common use of TTP CAs. This may be characteristic of how PKIs will 
evolve, or it may be a temporary feature of early phases of use of 
PKIs.

Time will tell,

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f88C9lh06990 for ietf-pkix-bks; Sat, 8 Sep 2001 05:09:47 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f88C9jD06986 for <[e-mail]>; Sat, 8 Sep 2001 05:09:45 -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 IAA61200; Sat, 8 Sep 2001 08:07:25 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f88C1Vv134678; Sat, 8 Sep 2001 08:01:32 -0400
Importance: Normal
Subject: Re: Removing expired certificates from CRLs.....
To: Denis Pinkas <[e-mail]>
Cc: IETF-PKIX <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Sat, 8 Sep 2001 08:09:39 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.8 SPR #MIAS4UTJ8H |June 21, 2001) at 09/08/2001 08:09:40 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>

     Denis:

     Given what the other proponents of a mechanism like this one are
suggesting, I think my second alternative will be considered
overcomplicated anyway.  They don't seem to want to enforce multiple dates
for retention.  The only reason for separate retention dates which I can
think of is to allow NR to have a multi-year retention while DS (say) has a
week or two, and if NR relying parties check for revocation information
periodically and stop after the date of the signature, they won't have a
problem.

          Tom Gindin

Denis Pinkas <[e-mail]> on 09/07/2001 08:32:14 AM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   IETF-PKIX <[e-mail]>
Subject:  Re: Removing expired certificates from CRLs.....


Tom,

I still believe that this discussion is more appropriate, at this time, to
X.509 currently rather than PKIX. So I have bindly copied the X.509
discussion list. Having said that, making sure that PKIX members agree with
the proposal cannot hurt.

> I would argue for SHOULD for that extension rather than MUST, but its
> presence can hardly hurt if it is non-critical.

I believe that we basically agree. When this extension is present, then it
is non critical.

> BTW, I hadn't read your note when I composed mine.
> Now, what is the proper syntax for this extension, which could be named
> "RevokeRetention"?  Here are some possibilities:

> 1    Assume that all usage types have either no retention or the same
one.
>   A simple syntax for this would be:
>      RevokeRetention ::= SEQUENCE  {
>           basicUsages    KeyUsage OPTIONAL,
>           extUsages      SEQUENCE OF OBJECT IDENTIFIER OPTIONAL,
>           incExpsAfter   GeneralizedTime
>      }

Since in practice, I would expect a policy where all certicates having DS
or
NR set are kept one month longer, this seems sufficient.

> 2    Assume that usage types may have different non-null retentions.
    A slightly less simple syntax for  this would be:
>
>  RevokeRetention ::= SEQUENCE OF UsageRevokeRetention
>
>    UsageRevokeRetention ::= SEQUENCE   {
>      CHOICE {
>        basicUsage     INTEGER,
                        -- 0-based bit offset from KeyUsage definition
>        extUsage       OBJECT IDENTIFIER,
>     }
>      incExpsAfter     GeneralizedTime
>    }

I would prefer:

        basicUsage     BIT STRING  rather than
        basicUsage     INTEGER


We could also have a simpler syntax:

RevokeRetention ::= SEQUENCE OF UsageRevokeRetention

    UsageRevokeRetention ::= SEQUENCE  {
        incExpsAfter     GeneralizedTime,
        basicUsage       BIT STRING                      OPTIONAL,
        extUsages        SEQUENCE OF OBJECT IDENTIFIER   OPTIONAL
    }

If some dates are different but some dates are common to various types of
certificates, this can save some entries.

> Naturally, any revocation matching a specified usage would be expected
> to be retained on the CRL if the certificate expiration time is after
> "incExpsAfter", but not otherwise.  Furthermore, do you think
> extendedKeyUsage should be omitted?

For completness, since X.509 is a framework, extendedKeyUsage should be
there. PKIX can then decide to keep it or leave it in its profile.

Now, suppose we do this, this is fine for CRLs. How should an OCSP server
behave whether or not expired certificates are kept longer than strictly
mandatory ? RFC 2560 is rather vague on that topic.

Denis


>           Tom Gindin






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f888UE122271 for ietf-pkix-bks; Sat, 8 Sep 2001 01:30:14 -0700 (PDT)
Received: from dolk.extundo.com (dolk.extundo.com [195.42.214.242]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f888UAD22261 for <[e-mail]>; Sat, 8 Sep 2001 01:30:11 -0700 (PDT)
Received: from barbar.josefsson.org (slipsten.extundo.com [195.42.214.241]) (authenticated) by dolk.extundo.com (8.11.6/8.11.6) with ESMTP id f888UBh11156; Sat, 8 Sep 2001 10:30:11 +0200
To: [e-mail]
Cc: Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: charter revisions
References: <p0501040bb7a8214adf35@[128.33.84.34]> <[e-mail]> <p0501040ab7b458549900@[128.33.238.96]> <[e-mail]> <p05010403b7bab9e15dcc@[128.33.84.34]> <[e-mail]> <p05010404b7bbdfb8674d@[128.33.84.34]> <[e-mail]>
From: Simon Josefsson <[e-mail]>
In-Reply-To: <[e-mail]> (Michael =?iso-8859-1?q?Str=F6der's?= message of "Fri, 07 Sep 2001 20:03:40 +0200")
Date: Sat, 08 Sep 2001 10:29:40 +0200
Message-ID: <[e-mail]>
Lines: 29
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.0.105
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
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 Ströder <[e-mail]> writes:

>> >But this is completely pedantic. The original issue was that a logo can
>> >change appearance when it's scaled or mapped to different colors. A pink
>> >circle is different from a green circle for trademark and copyright
>> >purposes. But how do you distinguish them when they're displayed on a
>> >black and white screen? I don't think that web page technology has any
>> >magic bullets in this area. And what about blind users? With URLs, they
>> >can have their screen-reader read the URL back to them. Graphics will be
>> >completely inaccessible.
>> 
>> Good points about the limitations of a logo.
>
> +1
>
> I don't believe that the displaying problems can be solved.

I am not that convinced, at least the SVG format seem to aim to deal
with the problems above:

http://www.w3.org/TR/SVG-access/

I don't think this is a new problem that only exists for PKIX.  Logos
are already often distorted in the real world: Black and white news
papers, low resolution screens, etc.  It's not impossible to fake
logos outside the PKIX world, and people seem to cope.

Not to say that the problems of cross-certifying etc aren't real, but
I don't think they are impossible to solve.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f880nOV26274 for ietf-pkix-bks; Fri, 7 Sep 2001 17:49:24 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f880nND26270 for <[e-mail]>; Fri, 7 Sep 2001 17:49:23 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 7 Sep 2001 17:50:07 -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, 07 Sep 2001 17:50:07 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <SMT3ZSA2>; Fri, 07 Sep 2001 17:42:57 -0700
Content-return: allowed
Date: Fri, 07 Sep 2001 17:42:50 -0700
From: Ryan Hurst <[e-mail]>
Subject: RE: Removing expired certificates from CRLs.....
To: "'Tim Polk'" <[e-mail]>, Denis Pinkas <[e-mail]>, Tom Gindin <[e-mail]>
Cc: IETF-PKIX <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain
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>

Yes --
	Sorry I have not been in this conversation the past couple of days;
Ambarish keeps me busy ;)

	I have seen several ideas in regards to this extension; but I was
thinking of something much simpler (more like what Tim has recommended) An
extension that would be just like the ArchiveCutOff extension in OCSP.

	ArchiveCutOff ::= GeneralizedTime

My 2c,

Ryan

-----Original Message-----
From: Tim Polk [mailto:[e-mail]] 
Sent: Friday, September 07, 2001 2:20 PM
To: Denis Pinkas; Tom Gindin
Cc: IETF-PKIX
Subject: Re: Removing expired certificates from CRLs.....


Denis, Tom, et al.

As one of several independent originators of the idea, (Ambarish Malpani is 
another), I thought I ought to weigh in as well.  I had something 
*considerably* simpler in mind.  If a CRL includes revocation information 
for certificates that have expired, a relying party should be able to 
determine that automatically.

I would suggest a noncritical CRL extension with a single value of type 
GeneralizedTime.   The ASN.1 syntax would be

	ExpiredCertsOnCRL ::= GeneralizedTime

As usual with PKIX times, we would require time Zulu with seconds (even if 
zero).

The semantics for the extension would be as follows:

	The scope of a CRL containing this extension is extended to include 
certificates that expired  at the exact time specified in the extension or 
after that time.  If limitations in the CRL's scope are specified (by 
either reason codes or by distribution points), that applies to expired 
certificates as well.

IMHO, we shouldn't make the scope of a CRL different for expired and 
unexpired certificates.  This is a simple idea - let's keep it that way!

BTW, folks were wondering why this hasn't been pursued in PKIX.  This idea 
has been floated a couple of times, but no one was really ready to 
implement it.  We needed to concentrate on the core functionality.  I 
floated the idea again at one of the meetings (in San Diego?) and Ambarish 
said he'd had the same idea and wanted to pursue it.  I asked him to delay 
any new work in this area until the son-of-2459 is approved by the 
IESG.  (Neither of us realized what a long delay we'd agreed to...)

Thanks,

Tim Polk


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f87MRLd23801 for ietf-pkix-bks; Fri, 7 Sep 2001 15:27:21 -0700 (PDT)
Received: from mailout05.sul.t-online.de (mailout05.sul.t-online.com [194.25.134.82]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f87MRJD23797 for <[e-mail]>; Fri, 7 Sep 2001 15:27:19 -0700 (PDT)
Received: from fwd06.sul.t-online.de  by mailout05.sul.t-online.de with smtp  id 15fU5f-0005r1-01; Sat, 08 Sep 2001 00:27:11 +0200
Received: from junker.stroeder.com (520010731148-0001@[62.224.169.246]) by fmrl06.sul.t-online.com with esmtp id 15fU5V-27zkX2C; Sat, 8 Sep 2001 00:27:01 +0200
Received: from stroeder.com (localhost [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id D919F1574FF; Fri,  7 Sep 2001 20:03:40 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Fri, 07 Sep 2001 20:03:40 +0200
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Reply-To: [e-mail]
Organization: stroeder.com
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
Cc: [e-mail]
Subject: Re: charter revisions
References: <p0501040bb7a8214adf35@[128.33.84.34]>		 <[e-mail]> <p0501040ab7b458549900@[128.33.238.96]>	 <[e-mail]> <p05010403b7bab9e15dcc@[128.33.84.34]> <[e-mail]> <p05010404b7bbdfb8674d@[128.33.84.34]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Sender: [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>

Stephen Kent wrote:
> 
> There is not a central registry for DNs
> where the CA can check to verify that the company in question is
> entitled to use the DN it proposes. Certainly this is true if the
> U.S. So, since CAs regularly make value judgements about
> appropriateness of DNs given imperfect inputs, I don't see the logo
> "verification" as something fundamentally different and harder.

Hmm, do you really want to argue based on these practices?
Now guess how serious I'll take this argument...

> >But this is completely pedantic. The original issue was that a logo can
> >change appearance when it's scaled or mapped to different colors. A pink
> >circle is different from a green circle for trademark and copyright
> >purposes. But how do you distinguish them when they're displayed on a
> >black and white screen? I don't think that web page technology has any
> >magic bullets in this area. And what about blind users? With URLs, they
> >can have their screen-reader read the URL back to them. Graphics will be
> >completely inaccessible.
> 
> Good points about the limitations of a logo.

+1

I don't believe that the displaying problems can be solved.

Ciao, Michael.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f87Lges22964 for ietf-pkix-bks; Fri, 7 Sep 2001 14:42:40 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f87LgeD22960 for <[e-mail]>; Fri, 7 Sep 2001 14:42:40 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 7 Sep 2001 14:43:24 -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, 07 Sep 2001 14:43:23 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <SMT3ZR3B>; Fri, 07 Sep 2001 14:36:14 -0700
Content-return: allowed
Date: Fri, 07 Sep 2001 14:36:06 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: Removing expired certificates from CRLs.....
To: "'Denis Pinkas'" <[e-mail]>, Tom Gindin <[e-mail]>
Cc: IETF-PKIX <[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>

Hi Denis, Tom,
    What I would recommend we add to CRLs, is something similar
(or the same) as the ArchiveCutoff extension in OCSP. If a CA
added that to a CRL, it would be easy for a responder to add it
in responses.

It is unclear to me that there is a huge benefit to CAs to go
through the trouble of retaining only signing certs in the CRL
and not the others.

Regards,
Ambarish


Denis, since you are bcc-ing the X.509 group, could you please
also forward this message to that list?

Thanks,
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: Denis Pinkas [mailto:[e-mail]]
> Sent: Friday, September 07, 2001 5:32 AM
> To: Tom Gindin
> Cc: IETF-PKIX
> Subject: Re: Removing expired certificates from CRLs.....
> 
> 
> 
> Tom,
> 
> I still believe that this discussion is more appropriate, at 
> this time, to
> X.509 currently rather than PKIX. So I have bindly copied the X.509
> discussion list. Having said that, making sure that PKIX 
> members agree with
> the proposal cannot hurt.
> 
> > I would argue for SHOULD for that extension rather than 
> MUST, but its
> > presence can hardly hurt if it is non-critical.  
> 
> I believe that we basically agree. When this extension is 
> present, then it
> is non critical.
> 
> > BTW, I hadn't read your note when I composed mine.  
> > Now, what is the proper syntax for this extension, which 
> could be named 
> > "RevokeRetention"?  Here are some possibilities:
> 
> > 1    Assume that all usage types have either no retention 
> or the same one.
> >   A simple syntax for this would be:
> >      RevokeRetention ::= SEQUENCE  {
> >           basicUsages    KeyUsage OPTIONAL,
> >           extUsages      SEQUENCE OF OBJECT IDENTIFIER OPTIONAL,
> >           incExpsAfter   GeneralizedTime
> >      }
> 
> Since in practice, I would expect a policy where all 
> certicates having DS or
> NR set are kept one month longer, this seems sufficient.
> 
> > 2    Assume that usage types may have different non-null retentions.
>     A slightly less simple syntax for  this would be:
> >
> >  RevokeRetention ::= SEQUENCE OF UsageRevokeRetention
> >
> >    UsageRevokeRetention ::= SEQUENCE   {
> >      CHOICE {
> >        basicUsage     INTEGER, 
>                         -- 0-based bit offset from KeyUsage definition
> >        extUsage       OBJECT IDENTIFIER,
> >     }
> >      incExpsAfter     GeneralizedTime
> >    }
> 
> I would prefer:
>  
>         basicUsage     BIT STRING  rather than
>         basicUsage     INTEGER
> 
> 
> We could also have a simpler syntax:
> 
> RevokeRetention ::= SEQUENCE OF UsageRevokeRetention
> 
>     UsageRevokeRetention ::= SEQUENCE  {
>         incExpsAfter     GeneralizedTime,
>         basicUsage       BIT STRING                      OPTIONAL, 
>         extUsages        SEQUENCE OF OBJECT IDENTIFIER   OPTIONAL
>     }
> 
> If some dates are different but some dates are common to 
> various types of
> certificates, this can save some entries. 
> 
> > Naturally, any revocation matching a specified usage would 
> be expected
> > to be retained on the CRL if the certificate expiration 
> time is after
> > "incExpsAfter", but not otherwise.  Furthermore, do you think
> > extendedKeyUsage should be omitted?
> 
> For completness, since X.509 is a framework, extendedKeyUsage 
> should be
> there. PKIX can then decide to keep it or leave it in its profile.
> 
> Now, suppose we do this, this is fine for CRLs. How should an 
> OCSP server
> behave whether or not expired certificates are kept longer 
> than strictly
> mandatory ? RFC 2560 is rather vague on that topic.
> 
> Denis
> 
> 
> >           Tom Gindin
> 


Received: by above.proper.com (8.11.6/8.11.3) id f87LKqt22627 for ietf-pkix-bks; Fri, 7 Sep 2001 14:20:52 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f87LKoD22623 for <[e-mail]>; Fri, 7 Sep 2001 14:20:50 -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 RAA10319; Fri, 7 Sep 2001 17:20:47 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 07 Sep 2001 17:19:37 -0400
To: Denis Pinkas <[e-mail]>, Tom Gindin <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: Re: Removing expired certificates from CRLs.....
Cc: IETF-PKIX <[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>

Denis, Tom, et al.

As one of several independent originators of the idea, (Ambarish Malpani is 
another), I thought I ought to weigh in as well.  I had something 
*considerably* simpler in mind.  If a CRL includes revocation information 
for certificates that have expired, a relying party should be able to 
determine that automatically.

I would suggest a noncritical CRL extension with a single value of type 
GeneralizedTime.   The ASN.1 syntax would be

	ExpiredCertsOnCRL ::= GeneralizedTime

As usual with PKIX times, we would require time Zulu with seconds (even if 
zero).

The semantics for the extension would be as follows:

	The scope of a CRL containing this extension is extended to include 
certificates that expired  at the exact time specified in the extension or 
after that time.  If limitations in the CRL's scope are specified (by 
either reason codes or by distribution points), that applies to expired 
certificates as well.

IMHO, we shouldn't make the scope of a CRL different for expired and 
unexpired certificates.  This is a simple idea - let's keep it that way!

BTW, folks were wondering why this hasn't been pursued in PKIX.  This idea 
has been floated a couple of times, but no one was really ready to 
implement it.  We needed to concentrate on the core functionality.  I 
floated the idea again at one of the meetings (in San Diego?) and Ambarish 
said he'd had the same idea and wanted to pursue it.  I asked him to delay 
any new work in this area until the son-of-2459 is approved by the 
IESG.  (Neither of us realized what a long delay we'd agreed to...)

Thanks,

Tim Polk



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f87CZUh00478 for ietf-pkix-bks; Fri, 7 Sep 2001 05:35:30 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f87CZTD00474 for <[e-mail]>; Fri, 7 Sep 2001 05:35: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 OAA16610; Fri, 7 Sep 2001 14:34: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 OAA13896; Fri, 7 Sep 2001 14:32:17 +0200
Message-ID: <[e-mail]>
Date: Fri, 07 Sep 2001 14:32:14 +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: Tom Gindin <[e-mail]>
CC: IETF-PKIX <[e-mail]>
Subject: Re: Removing expired certificates from 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>

Tom,

I still believe that this discussion is more appropriate, at this time, to
X.509 currently rather than PKIX. So I have bindly copied the X.509
discussion list. Having said that, making sure that PKIX members agree with
the proposal cannot hurt.

> I would argue for SHOULD for that extension rather than MUST, but its
> presence can hardly hurt if it is non-critical.  

I believe that we basically agree. When this extension is present, then it
is non critical.

> BTW, I hadn't read your note when I composed mine.  
> Now, what is the proper syntax for this extension, which could be named 
> "RevokeRetention"?  Here are some possibilities:

> 1    Assume that all usage types have either no retention or the same one.
>   A simple syntax for this would be:
>      RevokeRetention ::= SEQUENCE  {
>           basicUsages    KeyUsage OPTIONAL,
>           extUsages      SEQUENCE OF OBJECT IDENTIFIER OPTIONAL,
>           incExpsAfter   GeneralizedTime
>      }

Since in practice, I would expect a policy where all certicates having DS or
NR set are kept one month longer, this seems sufficient.

> 2    Assume that usage types may have different non-null retentions.
    A slightly less simple syntax for  this would be:
>
>  RevokeRetention ::= SEQUENCE OF UsageRevokeRetention
>
>    UsageRevokeRetention ::= SEQUENCE   {
>      CHOICE {
>        basicUsage     INTEGER, 
                        -- 0-based bit offset from KeyUsage definition
>        extUsage       OBJECT IDENTIFIER,
>     }
>      incExpsAfter     GeneralizedTime
>    }

I would prefer:
 
        basicUsage     BIT STRING  rather than
        basicUsage     INTEGER


We could also have a simpler syntax:

RevokeRetention ::= SEQUENCE OF UsageRevokeRetention

    UsageRevokeRetention ::= SEQUENCE  {
        incExpsAfter     GeneralizedTime,
        basicUsage       BIT STRING                      OPTIONAL, 
        extUsages        SEQUENCE OF OBJECT IDENTIFIER   OPTIONAL
    }

If some dates are different but some dates are common to various types of
certificates, this can save some entries. 

> Naturally, any revocation matching a specified usage would be expected
> to be retained on the CRL if the certificate expiration time is after
> "incExpsAfter", but not otherwise.  Furthermore, do you think
> extendedKeyUsage should be omitted?

For completness, since X.509 is a framework, extendedKeyUsage should be
there. PKIX can then decide to keep it or leave it in its profile.

Now, suppose we do this, this is fine for CRLs. How should an OCSP server
behave whether or not expired certificates are kept longer than strictly
mandatory ? RFC 2560 is rather vague on that topic.

Denis


>           Tom Gindin


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f87BuoF29882 for ietf-pkix-bks; Fri, 7 Sep 2001 04:56:50 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f87BumD29877 for <[e-mail]>; Fri, 7 Sep 2001 04:56:49 -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 HAA94626; Fri, 7 Sep 2001 07:54:29 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f87BmaF71208; Fri, 7 Sep 2001 07:48:36 -0400
Importance: Normal
Subject: Re: Removing expired certificates from CRLs.....
To: Denis Pinkas <[e-mail]>
Cc: IETF-PKIX <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Fri, 7 Sep 2001 07:56:41 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.8 SPR #MIAS4UTJ8H |June 21, 2001) at 09/07/2001 07:56:43 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>

     I would argue for SHOULD for that extension rather than MUST, but its
presence can hardly hurt if it is non-critical.  BTW, I hadn't read your
note when I composed mine.  Now, what is the proper syntax for this
extension, which could be named "RevokeRetention"?  Here are some
possibilities:
1    Assume that all usage types have either no retention or the same one.
A simple syntax for this would be:
     RevokeRetention ::= SEQUENCE  {
          basicUsages    KeyUsage OPTIONAL,
          extUsages SEQUENCE OF OBJECT IDENTIFIER OPTIONAL,
          incExpsAfter   GeneralizedTime
     }
2    Assume that usage types may have different non-null retentions.  A
slightly less simple syntax for  this would be:
     RevokeRetention ::= SEQUENCE OF UsageRevokeRetention
     UsageRevokeRetention ::= SEQUENCE   {
        CHOICE {
          basicUsage     INTEGER, -- 0-based bit offset from KeyUsage
definition
          extUsage  OBJECT IDENTIFIER,
        }
        incExpsAfter     GeneralizedTime
     }

     Naturally, any revocation matching a specified usage would be expected
to be retained on the CRL if the certificate expiration time is after
"incExpsAfter", but not otherwise.  Furthermore, do you think
extendedKeyUsage should be omitted?

          Tom Gindin


Denis Pinkas <[e-mail]> on 09/07/2001 07:34:12 AM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   IETF-PKIX <[e-mail]>
Subject:  Re: Removing expired certificates from CRLs.....


Hello Tom !


>      Because of unscheduled CRL publication, would it not make sense to
> recommend a minimum period of time after expiration before revoked NR
> certificates get removed from CRL's?  In practice, specifying that they
> should be kept for a week or so beyond expiration would not cause CRL
> bloat, which can admittedly become a serious problem if all CRL entries
are
> kept forever.

Such recommendation would be nice, but only usable in "closed environments"
where it can be known that this policy is enforced. In "open environments"
in order to allow the use of CRLs which include certificates even after
they
expire, some indication SHALL be present in the CRL to know whether or not
it includes such certificates.

Denis

>           Tom Gindin
>
> "Flynn, Michael" <[e-mail]>@mail.imc.org on 09/05/2001
01:02:33
> PM
>
> Sent by:  [e-mail]
>
> To:   "'Ryan Hurst'" <[e-mail]>, IETF-PKIX <[e-mail]>
> cc:
> Subject:  RE: Removing expired certificates from CRLs.....
>
> Ryan,
>
> Ryan wrote::
>
> Now logically it makes sense to remove certificates that are expired from
> CRLs to control size, yes this has a negative point specifically it
> prevents CRLs from being used as a non-repudiation source; but this is
mute
> due to many other issues.
>
> At least regarding removing expired certs from CRLs, I would think that
> non-repudiation can be satisfied by keeping the old CRLs in back up
storage
> for some length of time.  That time being how far back in time a contract
> dispute might go; ten years, twenty?   So long as you could get them off
> tape for the lawyers to look at the legal process would be satisfied,
they
> don't need to be online forever.
>
> Michael
>
>  -----Original Message-----
>  From: Ryan Hurst [mailto:[e-mail]]
>  Sent: Tuesday, September 04, 2001 8:50 PM
>  To: IETF-PKIX
>  Subject: Removing expired certificates from CRLs.....
>
>  I was speaking with Peter Williams today about the removal of expired
>  certificates from CRLs; I have always been under the belief that this
>  behavior was optional, I vaguely remembered reading text in 2459 along
>  those lines; additionally I know of several commercial CAs that do not
>  remove the expired certificates from their CRLs. Peter on the other hand
>  was under the impression that it was a mandate to remove CRLs; he too
>  remembered reading text in 2459 to support is position.
>
>  So we each pulled out the RFC and found that we were both right!
>  Specifically both sections 3.3 and 8.6.2.2 have text on this subject:
>
>  3.3  Revocation
>
>  When a certificate is issued, it is expected to be in use for its entire
>  validity period.  However, various circumstances may cause a certificate
>  to become invalid prior to the expiration of the validity period.
>
>  ....
>
>  An entry is added to the CRL as part of the next update following
>  notification of revocation. An entry may be removed from the CRL after
>  appearing on one regularly scheduled CRL issued beyond the revoked
>  certificate's validity period.
>
>  8.6.2.2 Issuing distribution point extension
>
>  This CRL extension field identifies the CRL distribution point for this
>  particular CRL, and indicates if the CRL is limited to revocations for
>  end-entity certificates only, for authority certificates only, or for a
>  limited set of reasons only. The CRL is signed by the CRL issuer's key-
>  CRL distribution points do not have their own key pairs. However, for a
>  CRL distributed via the Directory, the CRL is stored in the entry of the
>  CRL distribution point, which may not be the directory entry of the CRL
>  issuer. If this field is absent, the CRL shall contain entries for all
>  revoked unexpired certificates issued by the CRL issuer.
>
>  ....
>
>  The distributionPoint component contains the name of the distribution
>  point in one or more name forms. If this field is absent, the CRL shall
>  contain entries for all revoked certificates issued by the CRL issuer.
>  After a certificate appears on a CRL, it is deleted from a subsequent
CRL
>  after the certificate's expiry.
>
>  Although section 8.6.2.2 is specifically in regards to CRLdps, any
>  difference between full CRLs and CRLdps in this case I feel would be an
>  arbitrary one.
>
>  Now logically it makes sense to remove certificates that are expired
from
>  CRLs to control size, yes this has a negative point specifically it
>  prevents CRLs from being used as a non-repudiation source; but this is
>  mute due to many other issues.
>
>  That being the case I think; and I believe Peter would agree the correct
>  thing to do is to remove these expired/revoked entries from the CRL.
>
>  The question now is what is the PKIX stance on this matter?
>
>  Ryan M. Hurst
>
>  ValiCert, Inc.
>
>       "It may roundly be asserted that human ingenuity cannot concoct a
>       cipher which human ingenuity cannot resolve."
>       -Edgar Allan Poe






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f87BYqT27719 for ietf-pkix-bks; Fri, 7 Sep 2001 04:34:52 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f87BYoD27711 for <[e-mail]>; Fri, 7 Sep 2001 04:34: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 NAA22022 for <[e-mail]>; Fri, 7 Sep 2001 13:36:50 +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 NAA15066; Fri, 7 Sep 2001 13:34:13 +0200
Message-ID: <[e-mail]>
Date: Fri, 07 Sep 2001 13:34:12 +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: Tom Gindin <[e-mail]>
CC: IETF-PKIX <[e-mail]>
Subject: Re: Removing expired certificates from 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>

Hello Tom !


>      Because of unscheduled CRL publication, would it not make sense to
> recommend a minimum period of time after expiration before revoked NR
> certificates get removed from CRL's?  In practice, specifying that they
> should be kept for a week or so beyond expiration would not cause CRL
> bloat, which can admittedly become a serious problem if all CRL entries are
> kept forever.

Such recommendation would be nice, but only usable in "closed environments"
where it can be known that this policy is enforced. In "open environments"
in order to allow the use of CRLs which include certificates even after they
expire, some indication SHALL be present in the CRL to know whether or not
it includes such certificates.

Denis 
 
>           Tom Gindin
> 
> "Flynn, Michael" <[e-mail]>@mail.imc.org on 09/05/2001 01:02:33
> PM
> 
> Sent by:  [e-mail]
> 
> To:   "'Ryan Hurst'" <[e-mail]>, IETF-PKIX <[e-mail]>
> cc:
> Subject:  RE: Removing expired certificates from CRLs.....
> 
> Ryan,
> 
> Ryan wrote::
> 
> Now logically it makes sense to remove certificates that are expired from
> CRLs to control size, yes this has a negative point specifically it
> prevents CRLs from being used as a non-repudiation source; but this is mute
> due to many other issues.
> 
> At least regarding removing expired certs from CRLs, I would think that
> non-repudiation can be satisfied by keeping the old CRLs in back up storage
> for some length of time.  That time being how far back in time a contract
> dispute might go; ten years, twenty?   So long as you could get them off
> tape for the lawyers to look at the legal process would be satisfied, they
> don't need to be online forever.
> 
> Michael
> 
>  -----Original Message-----
>  From: Ryan Hurst [mailto:[e-mail]]
>  Sent: Tuesday, September 04, 2001 8:50 PM
>  To: IETF-PKIX
>  Subject: Removing expired certificates from CRLs.....
> 
>  I was speaking with Peter Williams today about the removal of expired
>  certificates from CRLs; I have always been under the belief that this
>  behavior was optional, I vaguely remembered reading text in 2459 along
>  those lines; additionally I know of several commercial CAs that do not
>  remove the expired certificates from their CRLs. Peter on the other hand
>  was under the impression that it was a mandate to remove CRLs; he too
>  remembered reading text in 2459 to support is position.
> 
>  So we each pulled out the RFC and found that we were both right!
>  Specifically both sections 3.3 and 8.6.2.2 have text on this subject:
> 
>  3.3  Revocation
> 
>  When a certificate is issued, it is expected to be in use for its entire
>  validity period.  However, various circumstances may cause a certificate
>  to become invalid prior to the expiration of the validity period.
> 
>  ....
> 
>  An entry is added to the CRL as part of the next update following
>  notification of revocation. An entry may be removed from the CRL after
>  appearing on one regularly scheduled CRL issued beyond the revoked
>  certificate's validity period.
> 
>  8.6.2.2 Issuing distribution point extension
> 
>  This CRL extension field identifies the CRL distribution point for this
>  particular CRL, and indicates if the CRL is limited to revocations for
>  end-entity certificates only, for authority certificates only, or for a
>  limited set of reasons only. The CRL is signed by the CRL issuer's key-
>  CRL distribution points do not have their own key pairs. However, for a
>  CRL distributed via the Directory, the CRL is stored in the entry of the
>  CRL distribution point, which may not be the directory entry of the CRL
>  issuer. If this field is absent, the CRL shall contain entries for all
>  revoked unexpired certificates issued by the CRL issuer.
> 
>  ....
> 
>  The distributionPoint component contains the name of the distribution
>  point in one or more name forms. If this field is absent, the CRL shall
>  contain entries for all revoked certificates issued by the CRL issuer.
>  After a certificate appears on a CRL, it is deleted from a subsequent CRL
>  after the certificate's expiry.
> 
>  Although section 8.6.2.2 is specifically in regards to CRLdps, any
>  difference between full CRLs and CRLdps in this case I feel would be an
>  arbitrary one.
> 
>  Now logically it makes sense to remove certificates that are expired from
>  CRLs to control size, yes this has a negative point specifically it
>  prevents CRLs from being used as a non-repudiation source; but this is
>  mute due to many other issues.
> 
>  That being the case I think; and I believe Peter would agree the correct
>  thing to do is to remove these expired/revoked entries from the CRL.
> 
>  The question now is what is the PKIX stance on this matter?
> 
>  Ryan M. Hurst
> 
>  ValiCert, Inc.
> 
>       "It may roundly be asserted that human ingenuity cannot concoct a
>       cipher which human ingenuity cannot resolve."
>       -Edgar Allan Poe


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8793rq19049 for ietf-pkix-bks; Fri, 7 Sep 2001 02:03:53 -0700 (PDT)
Received: from dns01.infocamere.it (dns01.infocamere.it [193.70.148.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8793pD19040 for <[e-mail]>; Fri, 7 Sep 2001 02:03:52 -0700 (PDT)
Received: from esd03d.icnet ([193.70.148.67]) by dns01.infocamere.it (Netscape Messaging Server 4.15) with ESMTP id GJABEH00.C0R for <[e-mail]>; Fri, 7 Sep 2001 10:54:17 +0200 
Received: from weirma004082 ([1.5.16.68]) by esd03d.icnet (Netscape Messaging Server 4.15) with SMTP id GJABVE00.4VP; Fri, 7 Sep 2001 11:04:26 +0200 
Message-ID: <005301c1377b$b1a0e020$52044701@icnet>
From: "Esposito Alfredo" <[e-mail]>
To: "Sharon Boeyen" <[e-mail]>, "'IETF-PKIX'" <[e-mail]>
References: <[e-mail]>
Subject: Re: Removing expired certificates from CRLs.....
Date: Fri, 7 Sep 2001 11:01:33 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0050_01C1378C.74EFB460"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
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>

Messaggio in formato MIME composto da più parti.

------=_NextPart_000_0050_01C1378C.74EFB460
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The following statement (apart the underscore) is excerpted from =
"Recommendation X.509 (2000) | ISO/IEC 9594-8:2000
Draft Technical Corrigendum 3" that is currently on ballot.
This corrects the defects reported in defect report 280

Replace the existing subclause 8.6.2.2 with the following and make =
associated changes to the ASN.1 in Appendix A:

8 . 6 . 2 . 2 Issuing distribution point extension

This CRL extension field identifies the CRL distribution point for this =
particular CRL, and indicates if the CRL is indirect, or if it is =
limited to covering only a subset of the revocation information. The =
limitation may be based on a subset of the certificate population or on =
a subset of revocation reasons. The CRL is signed by the CRL issuer's =
key - CRL distribution points do not have their own key pairs. However, =
for a CRL distributed via the Directory, the CRL is stored in the entry =
of the CRL distribution point, which may not be the directory entry of =
the CRL issuer. If this field and the CRL scope field are both absent, =
the CRL shall contain entries for all revoked unexpired certificates =
issued by the CRL issuer.

Alfredo Esposito
[e-mail]

----- Original Message -----=20
  From: Sharon Boeyen=20
  To: 'IETF-PKIX'=20
  Sent: Thursday, September 06, 2001 3:24 PM
  Subject: RE: Removing expired certificates from CRLs.....


  There was a problem with my initial attempt to send this to the list, =
so I am resending it.

  Sharon
    -----Original Message-----
    From: Sharon Boeyen=20
    Sent: Wednesday, September 05, 2001 1:36 PM
    To: 'Flynn, Michael'; 'Ryan Hurst'; IETF-PKIX
    Subject: RE: Removing expired certificates from CRLs.....


    I suspect some of the PKIX text was never updated to reflect the =
successful ballot on the X.509 defect report that fixed this in the base =
X.509 text. The approved TC for the defect (DR 204) corrected this =
problem by making the following changes to X.509 (97).


    Clause 12.6.3.1

    =20

    In the first sentence following the ASN.1, delete "unexpired"

    =20

    Add the following as a new second sentence in the first paragraph =
following the ASN.1

    =20

    "After a certificate appears on a CRL, it may be deleted from a =
subsequent CRL after the certificate's expiry."



    Cheers,
    Sharon

      -----Original Message-----
      From: Flynn, Michael [mailto:[e-mail]]
      Sent: Wednesday, September 05, 2001 1:03 PM
      To: 'Ryan Hurst'; IETF-PKIX
      Subject: RE: Removing expired certificates from CRLs.....


      Ryan,

      Ryan wrote::
      Now logically it makes sense to remove certificates that are =
expired from CRLs to control size, yes this has a negative point =
specifically it prevents CRLs from being used as a non-repudiation =
source; but this is mute due to many other issues.



      At least regarding removing expired certs from CRLs, I would think =
that non-repudiation can be satisfied by keeping the old CRLs in back up =
storage for some length of time.  That time being how far back in time a =
contract dispute might go; ten years, twenty?   So long as you could get =
them off  tape for the lawyers to look at the legal process would be =
satisfied, they don't need to be online forever. =20

      =20

      Michael

      =20

        -----Original Message-----
        From: Ryan Hurst [mailto:[e-mail]]
        Sent: Tuesday, September 04, 2001 8:50 PM
        To: IETF-PKIX
        Subject: Removing expired certificates from CRLs.....


        I was speaking with Peter Williams today about the removal of =
expired certificates from CRLs; I have always been under the belief that =
this behavior was optional, I vaguely remembered reading text in 2459 =
along those lines; additionally I know of several commercial CAs that do =
not remove the expired certificates from their CRLs. Peter on the other =
hand was under the impression that it was a mandate to remove CRLs; he =
too remembered reading text in 2459 to support is position.

        =20

        So we each pulled out the RFC and found that we were both right! =
Specifically both sections 3.3 and 8.6.2.2 have text on this subject:

        =20

        3.3  Revocation

        When a certificate is issued, it is expected to be in use for =
its entire validity period.  However, various circumstances may cause a =
certificate to become invalid prior to the expiration of the validity =
period.

        =20

        ....

        =20

        An entry is added to the CRL as part of the next update =
following notification of revocation. An entry may be removed from the =
CRL after appearing on one regularly scheduled CRL issued beyond the =
revoked certificate's validity period.

        =20

        =20

        =20

        8.6.2.2 Issuing distribution point extension

        This CRL extension field identifies the CRL distribution point =
for this particular CRL, and indicates if the CRL is limited to =
revocations for end-entity certificates only, for authority certificates =
only, or for a limited set of reasons only. The CRL is signed by the CRL =
issuer's key- CRL distribution points do not have their own key pairs. =
However, for a CRL distributed via the Directory, the CRL is stored in =
the entry of the CRL distribution point, which may not be the directory =
entry of the CRL issuer. If this field is absent, the CRL shall contain =
entries for all revoked unexpired certificates issued by the CRL issuer.

        =20

        ....

        =20

        The distributionPoint component contains the name of the =
distribution point in one or more name forms. If this field is absent, =
the CRL shall contain entries for all revoked certificates issued by the =
CRL issuer. After a certificate appears on a CRL, it is deleted from a =
subsequent CRL after the certificate's expiry.

        =20

        =20

        Although section 8.6.2.2 is specifically in regards to CRLdps, =
any difference between full CRLs and CRLdps in this case I feel would be =
an arbitrary one.=20

        =20

        Now logically it makes sense to remove certificates that are =
expired from CRLs to control size, yes this has a negative point =
specifically it prevents CRLs from being used as a non-repudiation =
source; but this is mute due to many other issues.

        =20

        That being the case I think; and I believe Peter would agree the =
correct thing to do is to remove these expired/revoked entries from the =
CRL.=20

        =20

        The question now is what is the PKIX stance on this matter?

        =20

        Ryan M. Hurst

        ValiCert, Inc.

        =20

          "It may roundly be asserted that human ingenuity cannot =
concoct a cipher which human ingenuity cannot resolve."

          -Edgar Allan Poe

        =20


------=_NextPart_000_0050_01C1378C.74EFB460
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3DWord.Document name=3DProgId>
<META content=3D"MSHTML 5.50.4522.1800" name=3DGENERATOR>
<META content=3D"Microsoft Word 10" name=3DOriginator><LINK=20
href=3D"cid:[e-mail]4BB00" =
rel=3DFile-List><o:SmartTagType=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"=20
name=3D"PersonName"></o:SmartTagType><!--[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:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
   <w:UseFELayout/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: SimSun;
}
@font-face {
	font-family: \@SimSun;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; =
mso-header-margin: .5in; mso-footer-margin: .5in; mso-paper-source: 0; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: SimSun
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: SimSun
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: SimSun
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline; text-underline: single
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline; text-underline: single
}
SPAN.EmailStyle17 {
	COLOR: windowtext; FONT-FAMILY: Arial; mso-style-type: =
personal-compose; mso-style-noshow: yes; mso-ansi-font-size: 10.0pt; =
mso-bidi-font-size: 10.0pt; mso-ascii-font-family: Arial; =
mso-hansi-font-family: Arial; mso-bidi-font-family: Arial
}
SPAN.SpellE {
	mso-style-name: ""; mso-spl-e: yes
}
SPAN.GramE {
	mso-style-name: ""; mso-gram-e: yes
}
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:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]--></HEAD>
<BODY lang=3DEN-US style=3D"tab-interval: .5in" vLink=3Dpurple =
link=3Dblue=20
bgColor=3D#ffffff><FONT size=3D2><FONT size=3D4>
<DIV><FONT face=3DArial size=3D2>The following statement (apart the =
underscore) is=20
excerpted from "Recommendation X.509 (2000) | ISO/IEC =
9594-8:2000<BR>Draft=20
Technical Corrigendum 3" that is currently on ballot.</FONT></DIV>
<P align=3Dleft><FONT face=3DArial><STRONG><EM>This corrects the defects =
reported in=20
defect report 280</EM></STRONG></FONT></P></FONT>
<P align=3Dleft><FONT face=3DArial><EM>Replace the existing subclause =
8.6.2.2 with=20
the following and make associated changes to the </EM></FONT><FONT=20
face=3DArial><EM>ASN.1 in Appendix A:</EM></FONT></P>
<DIV><B>
<P align=3Dleft><FONT face=3DArial>8 . 6 . 2 . 2 Issuing distribution =
point=20
extension</FONT></P></B>
<P align=3Dleft><FONT face=3DArial>This CRL extension field identifies =
the CRL=20
distribution point for this particular CRL, and indicates if the CRL is=20
indirect, or if it is limited to covering only a subset of the =
revocation=20
information. The limitation may be based on a subset of the certificate=20
population or on a subset of revocation reasons. The CRL is signed by =
the CRL=20
issuer&#8217;s key &#8212; CRL distribution points do not have their own =
key pairs. However,=20
for a CRL distributed via the Directory, the CRL is stored in the entry =
of the=20
CRL distribution point, which may not be the directory entry of the CRL =
issuer.=20
If this field and the CRL scope field are both absent, the CRL shall =
contain=20
entries for all revoked <U>unexpired</U> certificates issued by the CRL=20
issuer.</FONT></P>
<P align=3Dleft><FONT face=3DArial>Alfredo Esposito<BR></FONT><FONT =
face=3DArial><A=20
href=3D"mailto:[e-mail]">alfredo.esposito@infocamer=
e.it</A></FONT></P></FONT>-----=20
Original Message ----- </DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[e-mail]=20
  href=3D"mailto:[e-mail]">Sharon Boeyen</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">'IETF-PKIX'</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Thursday, September 06, =
2001 3:24=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: Removing expired=20
  certificates from CRLs.....</DIV>
  <DIV><BR></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D347082413-06092001>There was a problem with my initial attempt =
to send=20
  this to the list, so I am resending it.</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D347082413-06092001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D347082413-06092001>Sharon</SPAN></FONT></DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Sharon Boeyen=20
    <BR><B>Sent:</B> Wednesday, September 05, 2001 1:36 PM<BR><B>To:</B> =
'Flynn,=20
    Michael'; 'Ryan Hurst'; IETF-PKIX<BR><B>Subject:</B> RE: Removing =
expired=20
    certificates from CRLs.....<BR><BR></FONT></DIV>
    <DIV><SPAN class=3D054173117-05092001><FONT face=3DArial =
color=3D#0000ff size=3D2>I=20
    suspect some of the PKIX text was never updated to reflect the =
successful=20
    ballot on the&nbsp;X.509 defect report that fixed this in the base =
X.509=20
    text. The approved TC for the defect (DR 204) corrected this problem =
by=20
    making the following changes to X.509 (97).</FONT></SPAN></DIV>
    <DIV><SPAN class=3D054173117-05092001></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=3D054173117-05092001>&nbsp;</DIV>
    <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.55pt"><B=20
    style=3D"mso-bidi-font-weight: normal">Clause =
12.6.3.1<o:p></o:p></B></P>
    <P class=3DMsoNormal style=3D"MARGIN-LEFT: =
0.5in">&nbsp;<o:p></o:p></P>
    <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><I=20
    style=3D"mso-bidi-font-style: normal">In the first sentence =
following the=20
    ASN.1, delete &#8220;unexpired&#8221;<o:p></o:p></I></P>
    <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><I=20
    style=3D"mso-bidi-font-style: normal">&nbsp;<o:p></o:p></I></P>
    <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><I=20
    style=3D"mso-bidi-font-style: normal">Add the following as a new =
second=20
    sentence in the first paragraph following the =
ASN.1<o:p></o:p></I></P>
    <P class=3DMsoNormal style=3D"MARGIN-LEFT: =
0.5in">&nbsp;<o:p></o:p></P>
    <P class=3DMsoNormal><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New =
Roman'">&#8220;After a certificate=20
    appears on a CRL, it may be deleted from a subsequent CRL after the=20
    certificate&#8217;s expiry.&#8221;<o:p></o:p></SPAN></P>
    <DIV>&nbsp;</DIV>
    <DIV><FONT size=3D2></FONT>&nbsp;</DIV>
    <DIV><SPAN class=3D054173117-05092001><FONT=20
    color=3D#0000ff>Cheers,</FONT></SPAN></DIV>
    <DIV><SPAN class=3D054173117-05092001><FONT=20
    color=3D#0000ff>Sharon</FONT></SPAN></DIV>
    <DIV><FONT color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
    <BLOCKQUOTE dir=3Dltr=20
    style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff =
2px solid; MARGIN-RIGHT: 0px">
      <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
      size=3D2>-----Original Message-----<BR><B>From:</B> Flynn, Michael =

      [mailto:[e-mail]]<BR><B>Sent:</B> Wednesday, September =
05, 2001=20
      1:03 PM<BR><B>To:</B> 'Ryan Hurst'; IETF-PKIX<BR><B>Subject:</B> =
RE:=20
      Removing expired certificates from CRLs.....<BR><BR></FONT></DIV>
      <DIV><SPAN class=3D537505516-05092001><FONT face=3D"Courier New"=20
      size=3D2>Ryan,</FONT></SPAN></DIV>
      <DIV><SPAN class=3D537505516-05092001><FONT face=3D"Courier New"=20
      size=3D2></FONT></SPAN>&nbsp;</DIV>
      <DIV><SPAN class=3D537505516-05092001><FONT face=3D"Courier New" =
size=3D2>Ryan=20
      wrote::</DIV>
      <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Now logically it =
makes sense=20
      to remove certificates that are expired from <SPAN=20
      class=3DSpellE>CRLs</SPAN> to control size, yes this has a =
negative point=20
      specifically it prevents <SPAN class=3DSpellE>CRLs</SPAN> from =
being used as=20
      a non-repudiation source; but this is mute due to many other=20
      issues.</SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>
      <P class=3DMsoNormal><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p><SPAN=20
      class=3D537505516-05092001>At least regarding removing expired =
certs from=20
      CRLs, I would think that non-repudiation can be satisfied by =
keeping the=20
      old CRLs in back up storage for some length of time.&nbsp; That =
time being=20
      how far back in time a contract dispute might go; ten years, =
twenty?=20
      &nbsp; So long as you could get them off&nbsp; tape for the =
lawyers to=20
      look at the legal process would be satisfied, they don't need to =
be online=20
      forever.&nbsp; </SPAN></o:p></SPAN></P>
      <P class=3DMsoNormal><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p><SPAN=20
      class=3D537505516-05092001></SPAN></o:p></SPAN><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p><SPAN=20
      class=3D537505516-05092001></SPAN></o:p></SPAN>&nbsp;</P>
      <P class=3DMsoNormal><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p><SPAN=20
      class=3D537505516-05092001>Michael</SPAN></o:p></SPAN></P>
      <P class=3DMsoNormal><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p><SPAN=20
      =
class=3D537505516-05092001></SPAN></o:p></SPAN>&nbsp;</P></FONT></SPAN>
      <BLOCKQUOTE dir=3Dltr=20
      style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 =
2px solid; MARGIN-RIGHT: 0px">
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
        size=3D2>-----Original Message-----<BR><B>From:</B> Ryan Hurst=20
        [mailto:[e-mail]]<BR><B>Sent:</B> Tuesday, September =
04, 2001=20
        8:50 PM<BR><B>To:</B> IETF-PKIX<BR><B>Subject:</B> Removing =
expired=20
        certificates from CRLs.....<BR><BR></FONT></DIV>
        <DIV class=3DSection1>
        <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">I was speaking =
with=20
        </SPAN></FONT><st1:PersonName><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Peter=20
        Williams</SPAN></FONT></st1:PersonName><FONT face=3DArial =
size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"> today about the =
removal of=20
        expired certificates from <SPAN class=3DSpellE>CRLs</SPAN>; I =
have always=20
        been under the belief that this behavior was optional, I vaguely =

        remembered reading text in 2459 along those lines; additionally =
I know=20
        of several commercial <SPAN class=3DSpellE>CAs</SPAN> that do =
not remove=20
        the expired certificates from their <SPAN =
class=3DSpellE>CRLs</SPAN>.=20
        Peter on the other hand was under the impression that it was a =
mandate=20
        to remove <SPAN class=3DSpellE>CRLs</SPAN>; he too remembered =
reading text=20
        in 2459 to support is position.<o:p></o:p></SPAN></FONT></P>
        <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
        <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">So we each pulled =
out the=20
        RFC and found that we were both right! Specifically both =
sections 3.3=20
        and 8.6.2.2 have text on this =
subject:<o:p></o:p></SPAN></FONT></P>
        <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
        <P class=3DMsoNormal=20
        style=3D"tab-stops: 45.8pt 91.6pt 137.4pt 183.2pt 229.0pt =
274.8pt 320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt =
687.0pt 732.8pt; mso-layout-grid-align: none"><SPAN=20
        class=3DGramE><B style=3D"mso-bidi-font-weight: normal"><FONT =
face=3DArial=20
        size=3D2><SPAN=20
        style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Arial; =
mso-bidi-font-weight: normal">3.3<SPAN=20
        style=3D"mso-spacerun: yes">&nbsp;=20
        </SPAN>Revocation</SPAN></FONT></B></SPAN><B=20
        style=3D"mso-bidi-font-weight: normal"><FONT face=3DArial =
size=3D2><SPAN=20
        style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Arial; =
mso-bidi-font-weight: normal"><o:p></o:p></SPAN></FONT></B></P>
        <P class=3DMsoNormal=20
        style=3D"tab-stops: 45.8pt 91.6pt 137.4pt 183.2pt 229.0pt =
274.8pt 320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt =
687.0pt 732.8pt; mso-layout-grid-align: none"><FONT=20
        face=3DArial size=3D2><SPAN style=3D"FONT-SIZE: 10pt; =
FONT-FAMILY: Arial">When=20
        a certificate is issued, it is expected to be in use for its =
entire=20
        validity period.<SPAN style=3D"mso-spacerun: yes">&nbsp; =
</SPAN>However,=20
        various circumstances may cause a certificate to become invalid =
prior to=20
        the expiration of the validity =
period.<o:p></o:p></SPAN></FONT></P>
        <P class=3DMsoNormal=20
        style=3D"tab-stops: 45.8pt 91.6pt 137.4pt 183.2pt 229.0pt =
274.8pt 320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt =
687.0pt 732.8pt; mso-layout-grid-align: none"><FONT=20
        face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
        <P class=3DMsoNormal style=3D"mso-layout-grid-align: none"><FONT =
face=3DArial=20
        size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">....<o:p></o:p></SPAN></FONT></P>
        <P class=3DMsoNormal style=3D"mso-layout-grid-align: none"><FONT =
face=3DArial=20
        size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
        <P class=3DMsoNormal=20
        style=3D"tab-stops: 45.8pt 91.6pt 137.4pt 183.2pt 229.0pt =
274.8pt 320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt =
687.0pt 732.8pt; mso-layout-grid-align: none"><FONT=20
        face=3DArial size=3D2><SPAN style=3D"FONT-SIZE: 10pt; =
FONT-FAMILY: Arial">An=20
        entry is added to the CRL as part of the next update following=20
        notification of revocation. <B><I><SPAN=20
        style=3D"FONT-WEIGHT: bold; FONT-STYLE: italic">An entry may be =
removed=20
        from the CRL after appearing on one regularly scheduled CRL =
issued=20
        beyond the revoked certificate's validity=20
        period.</SPAN></I></B><o:p></o:p></SPAN></FONT></P>
        <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
        <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
        <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
        <P class=3DMsoNormal style=3D"mso-layout-grid-align: =
none"><B><FONT=20
        face=3DArial size=3D2><SPAN=20
        style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">8.6.2.2=20
        Issuing distribution point =
extension<o:p></o:p></SPAN></FONT></B></P>
        <P class=3DMsoNormal style=3D"mso-layout-grid-align: none"><FONT =
face=3DArial=20
        size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">This CRL=20
        extension field identifies the CRL distribution point for this=20
        particular CRL, and indicates if the CRL is limited to =
revocations for=20
        end-entity certificates only, for authority certificates only, =
or for a=20
        limited set of reasons only. The CRL is signed by the CRL =
issuer's key-=20
        CRL distribution points do not have their own key pairs. =
However, for a=20
        CRL distributed via the Directory, the CRL is stored in the =
entry of the=20
        CRL distribution point, which may not be the directory entry of =
the CRL=20
        issuer.<I><SPAN style=3D"FONT-STYLE: italic"> <B><SPAN=20
        style=3D"FONT-WEIGHT: bold">If this field is absent, the CRL =
shall contain=20
        entries for all revoked <SPAN class=3DSpellE>unexpired</SPAN> =
certificates=20
        issued by the CRL=20
        issuer.</SPAN></B><o:p></o:p></SPAN></I></SPAN></FONT></P>
        <P class=3DMsoNormal style=3D"mso-layout-grid-align: =
none"><I><FONT=20
        face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; FONT-STYLE: italic; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></I></P>
        <P class=3DMsoNormal style=3D"mso-layout-grid-align: none"><FONT =
face=3DArial=20
        size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">....<o:p></o:p></SPAN></FONT></P>
        <P class=3DMsoNormal style=3D"mso-layout-grid-align: none"><FONT =
face=3DArial=20
        color=3Dblue size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
        <P class=3DMsoNormal style=3D"mso-layout-grid-align: none"><FONT =
face=3DArial=20
        size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The =

        </SPAN></FONT><SPAN class=3DSpellE><B><FONT face=3DArial =
size=3D1><SPAN=20
        style=3D"FONT-WEIGHT: bold; FONT-SIZE: 9pt; FONT-FAMILY: =
Arial">distributionPoint</SPAN></FONT></B></SPAN><B><FONT=20
        face=3DArial size=3D1><SPAN=20
        style=3D"FONT-WEIGHT: bold; FONT-SIZE: 9pt; FONT-FAMILY: Arial"> =

        </SPAN></FONT></B><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">component contains =
the name=20
        of the distribution point in one or more name forms. If this =
field is=20
        absent, the CRL shall contain entries for all revoked =
certificates=20
        issued by the CRL issuer. <B><I><SPAN=20
        style=3D"FONT-WEIGHT: bold; FONT-STYLE: italic">After a =
certificate=20
        appears on a CRL, it is deleted from a subsequent CRL after the=20
        certificate's =
expiry.<o:p></o:p></SPAN></I></B></SPAN></FONT></P>
        <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
        <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
        <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Although section =
8.6.2.2 is=20
        specifically in regards to <SPAN class=3DSpellE>CRLdps</SPAN>, =
any=20
        difference between full <SPAN class=3DSpellE>CRLs</SPAN> and =
<SPAN=20
        class=3DSpellE>CRLdps</SPAN> in this case I feel would be an =
arbitrary=20
        one. <o:p></o:p></SPAN></FONT></P>
        <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
        <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Now logically it =
makes sense=20
        to remove certificates that are expired from <SPAN=20
        class=3DSpellE>CRLs</SPAN> to control size, yes this has a =
negative point=20
        specifically it prevents <SPAN class=3DSpellE>CRLs</SPAN> from =
being used=20
        as a non-repudiation source; but this is mute due to many other=20
        issues.<o:p></o:p></SPAN></FONT></P>
        <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
        <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">That being the =
case I think;=20
        and I believe Peter would agree the correct thing to do is to =
remove=20
        these expired/revoked entries from the CRL.=20
<o:p></o:p></SPAN></FONT></P>
        <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
        <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The question now =
is what is=20
        the PKIX stance on this matter?<o:p></o:p></SPAN></FONT></P>
        <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
        <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Ryan M.=20
        Hurst<o:p></o:p></SPAN></FONT></P>
        <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">ValiCert,=20
        Inc.<o:p></o:p></SPAN></FONT></P>
        <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
        <BLOCKQUOTE style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">
          <P class=3DMsoNormal><I><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
          style=3D"FONT-SIZE: 12pt; FONT-STYLE: italic; mso-no-proof: =
yes">"It may=20
          roundly be asserted that human ingenuity cannot concoct a =
cipher which=20
          human ingenuity cannot resolve."</SPAN></FONT></I><SPAN=20
          style=3D"mso-no-proof: =
yes"><o:p></o:p></SPAN></P></BLOCKQUOTE>
        <BLOCKQUOTE style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">
          <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
          style=3D"FONT-SIZE: 12pt; mso-no-proof: yes">-Edgar Allan=20
          Poe</SPAN><o:p></o:p></FONT></P></BLOCKQUOTE>
        <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
        style=3D"FONT-SIZE: =
12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BLOCKQUOTE>=
</BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0050_01C1378C.74EFB460--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f86NpJ517791 for ietf-pkix-bks; Thu, 6 Sep 2001 16:51:19 -0700 (PDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f86NpHD17787 for <[e-mail]>; Thu, 6 Sep 2001 16:51:17 -0700 (PDT)
Received: from [128.33.84.34] (comsec.bbn.com [128.33.84.34]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id TAA09652; Thu, 6 Sep 2001 19:53:12 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010407b7bdbbc840e3@[128.33.84.34]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]> <[e-mail]>
Date: Thu, 6 Sep 2001 19:51:08 -0400
To: jim <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Removing expired certificates from CRLs.....
Cc: Ryan Hurst <[e-mail]>, IETF-PKIX <[e-mail]>, Nancy Bianco <[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>

Jim,

PKIX, like most other IETF WGs, frowns on product advertisements 
inserted into our standards discussions. The product you mention also 
sounds like it is not connected to the PKI standards work we do here, 
hence even less appropriate for this discussion.

Thanks,

Steve



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f86MR6c16263 for ietf-pkix-bks; Thu, 6 Sep 2001 15:27:06 -0700 (PDT)
Received: from mail.cablespeed.com (mail.cablespeed.com [206.112.192.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f86MR5D16258 for <[e-mail]>; Thu, 6 Sep 2001 15:27:05 -0700 (PDT)
Received: from cablespeed.com (c216-45-71-147.md1.cablespeed.com [216.45.71.147]) by mail.cablespeed.com (8.9.3/8.9.3) with ESMTP id PAA14480; Thu, 6 Sep 2001 15:26:50 -0700
Message-ID: <[e-mail]>
Date: Thu, 06 Sep 2001 18:28:19 -0400
From: jim <[e-mail]>
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Ryan Hurst <[e-mail]>
CC: IETF-PKIX <[e-mail]>, Nancy Bianco <[e-mail]>
Subject: Re: Removing expired certificates from CRLs.....
References: <[e-mail]>
Content-Type: multipart/alternative; boundary="------------512E1D8EABB90226977BBA41"
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>

--------------512E1D8EABB90226977BBA41
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ryan,
    The quick and dirty answer is to use the Conclusive Logic middleware
solution, TrustLogic, for its Persistent Proof capability and do not worry about
notarization after the fact because you will already have captured all of the
legal requirements for notarization during the time when the session in which
the data transfer occurred.  The user will have been authenticated at the
beginning of the session and the data will be stored as encrypted XML in the
audit log, which is hashed and signed by the TrustLogic server.
    Call Nancy and talk with her and Jean about it.
Jim Heimberg, ABC, Ph.D.
Manager, Customer Relations
Conclusive Logic, Inc.
additional e-mail address:  [e-mail]

Ryan Hurst wrote:

> David -
>
> Although my confusion on this issue has been cleared up (note to self; always
> verify your sources) now; this brings up a very interesting point. I and
> others I have spoken with believe that the addition of such an extension (one
> that states that the CRL contains ALL revocation entries both current and
> expired) would be very valuable.
>
> Consider this problem, today I receive a digitally signed and time stamped
> document (a contract possibly), this document was signed by a certificate
> issued off of any number of commercial CA's that exist today. 10 years later
> the document is in question and I need to establish that the certificate
> associated with the signature on the document was valid at the time it was
> signed; there are several significant possibilities here:
>
>   1. CA in question has CRLNumber extension in all of their CRLs and they are
>      all available
>   2. CA in question does not have the CRLNumber in all CRLS or just a subset
>
> Now in #1 the problem is relatively easy, I find all CRLs that were valid
> during my window and of those I pick the one that has the highest CRLnumber.
> An extension like this would be "use-full" in this case but not necessary.
>
> In #2 the problem gets, well unsolvable; Since there are no ways to determine
> if I have all of the CRLs that are within my window (remember validity windows
> on CRLs can overlap so the ones within the overlapped window that state the
> certificate is revoked could be "lost") I will never now if the certificate
> was valid at the time in question. Now if the CRLs that were generated
> contained all entries and were marked as such with an extension I would have a
> mechanism to solve this problem; simply get the most recent CRL.
>
> Ryan
>
> -----Original Message-----
> From: David A. Cooper [mailto:[e-mail]]
> Sent:Wednesday, September 05, 20017:39 AM
> To: IETF-PKIX
> Subject: Re: Removing expired certificates from CRLs.....
>
> At 03:53 PM9/5/01 +0200, Nada Kapidzic Cicovic wrote:
>
> Denis,
>
> I was making comments on the text which Ryan extracted in his mail, assuming
> that they were from the son-of-RFC2459.
>
> In particular the last sentence in this paragraph:
>
> The distributionPoint component contains the name of the distribution point in
> one or more name forms. If this field is absent, the CRL shall contain entries
> for all revoked certificates issued by the CRL issuer. After a certificate
> appears on a CRL, it is deleted from a subsequent CRL after the certificate's
> expiry.
>
> However, after getting your comment I realized that this sentence and the
> referred section 8.6.2.2 comes from the X.509 (the latest version that I have
> on my disk is X_509_4thEditionDraftV6, and it contains the above text).
>
>
> I have X_509_4thEditionDraftV8 on my computer and it appears that this has
> been fixed. I now says "After a certificate appears on a CRL, it may be
> deleted from a subsequent CRL after the certificate's expiry."  I didn't
> bother to look at son-of-2459.
>
> In any case, both X.509 and son-of-2459 should say that a certificate may be
> deleted from a CRL after it has expired.  In general, though, I don't think
> there is much benefit to leaving expired certificates on CRLs.  The problem is
> that, at the moment, if an expired certificate is not listed on a CRL, there
> is no way to determine whether it is not listed because it was never revoked
> or if it was revoked but is not listed because it was removed after
> expiration.
>
> Some time ago, there was a suggestion to create a new, non-critical CRL
> extension that would specify whether an expired certificate was covered by a
> CRL (e.g., the extension could state: "This CRL includes all revoked
> certificates that expire(d) after Jan. 1, 2001 (i.e., notAfter >=
> 010101000000Z)."). There didn't seem to be much support for this idea, so the
> extension was never created.
>
>
> The current text of the son-of-RFC2459 does not seem to contain it or any
> other misleading sentences regarding this issue.
>
> Sorry for the confusion.
>
> Nada
>

--------------512E1D8EABB90226977BBA41
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body link="#0000FF" vlink="#800080" lang="EN-US" style="tab-interval:.5in">
Ryan,
<br>&nbsp;&nbsp;&nbsp; The quick and dirty answer is to use the Conclusive
Logic middleware solution, TrustLogic, for its Persistent Proof capability
and do not worry about notarization after the fact because you will already
have captured all of the legal requirements for notarization during the
time when the session in which the data transfer occurred.&nbsp; The user
will have been authenticated at the beginning of the session and the data
will be stored as encrypted XML in the audit log, which is hashed and signed
by the TrustLogic server.
<br>&nbsp;&nbsp;&nbsp; Call Nancy and talk with her and Jean about it.
<br>Jim Heimberg, ABC, Ph.D.
<br>Manager, Customer Relations
<br>Conclusive Logic, Inc.
<br>additional e-mail address:&nbsp; [e-mail]
<p>Ryan Hurst wrote:
<blockquote TYPE=CITE><link rel=File-List href="cid:filelist.xml@01C13659.21A03020"><o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="time"/><o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="date"/><!--[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:Compatibility>
   <w:UseFELayout/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]--><style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;
	mso-font-alt:\5B8B\4F53;
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 135135232 16 0 262145 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 135135232 16 0 262145 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:SimSun;}
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.EmailStyle17
	{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:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:2002394047;
	mso-list-type:hybrid;
	mso-list-template-ids:2140069784 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */ 
 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:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
<div class=Section1>
<div class="MsoNormal"><span style='font-size:
10.0pt;font-family:Arial;color:navy'><font face="Arial"><font color="#000080"><font size=-1>David
-</font></font></font><o:p></o:p></span></div>


<p class="MsoNormal"><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p></o:p></span>

<p class="MsoNormal"><span style='font-size:
10.0pt;font-family:Arial;color:navy'><span style='mso-tab-count:1'></span><font face="Arial"><font color="#000080"><font size=-1>Although
my confusion on this issue has been cleared up (note to self; always verify
your sources) now; this brings up a very interesting point. I and others
I have spoken with believe that the addition of such an extension (one
that states that the CRL contains ALL revocation entries both current and
expired) would be very valuable.&nbsp;</font></font></font><o:p></o:p></span>

<p class="MsoNormal"><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p></o:p></span>

<p class="MsoNormal"><span style='font-size:
10.0pt;font-family:Arial;color:navy'><font face="Arial"><font color="#000080"><font size=-1>Consider
this problem, today I receive a digitally signed and time stamped document
(a contract possibly), this document was signed by a certificate issued
off of any number of commercial CA's that exist today. 10 years later the
document is in question and I need to establish that the certificate associated
with the signature on the document was valid at the time it was signed;
there are several significant possibilities here:</font></font></font><o:p></o:p></span>

<p class="MsoNormal"><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p></o:p></span>
<ol style='mso-margin-top-alt:0in' start=1 type=1>
<li class="MsoNormal" style="color:navy;mso-list:l0 level1 lfo1;tab-stops:list .5in">
<span style='font-size:10.0pt;font-family:
     Arial'><font face="Arial"><font color="#000080"><font size=-1>CA
in question has&nbsp;<span class=SpellE>CRLNumber</span> extension in all
of their&nbsp;<span class=SpellE>CRLs</span> and they are all available</font></font></font><o:p></o:p></span></li>

<li class="MsoNormal" style="color:navy;mso-list:l0 level1 lfo1;tab-stops:list .5in">
<span style='font-size:10.0pt;font-family:
     Arial'><font face="Arial"><font color="#000080"><font size=-1>CA
in question does not have the&nbsp;<span class=SpellE>CRLNumber</span>
in all CRLS or just a subset</font></font></font><o:p></o:p></span></li>
</ol>

<div class="MsoNormal"><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p></o:p></span></div>


<p class="MsoNormal"><span style='font-size:
10.0pt;font-family:Arial;color:navy'><font face="Arial"><font color="#000080"><font size=-1>Now
in #1 the problem is relatively easy, I find all&nbsp;<span class=SpellE>CRLs</span>
that were valid during my window and of those I pick the one that has the
highest&nbsp;<span class=SpellE>CRLnumber</span>. An extension like this
would be "use-full" in this case but not necessary.</font></font></font><o:p></o:p></span>

<p class="MsoNormal"><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p></o:p></span>

<p class="MsoNormal"><span style='font-size:
10.0pt;font-family:Arial;color:navy'><font face="Arial"><font color="#000080"><font size=-1>In
#2 the problem gets, well unsolvable; Since there are no ways to determine
if I have all of the&nbsp;<span class=SpellE>CRLs</span> that are within
my window (remember validity windows on&nbsp;<span class=SpellE>CRLs</span>
can overlap so the ones within the overlapped window that state the certificate
is revoked could be "lost") I will never now if the certificate was valid
at the time in question. Now if the&nbsp;<span class=SpellE>CRLs</span>
that were generated contained all entries and were marked as such with
an extension I would have a mechanism to solve this problem; simply get
the most recent CRL.</font></font></font><o:p></o:p></span>

<p class="MsoNormal"><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p></o:p></span>

<p class="MsoNormal"><span style='font-size:
10.0pt;font-family:Arial;color:navy'><font face="Arial"><font color="#000080"><font size=-1>Ryan</font></font></font><o:p></o:p></span>

<p class="MsoNormal"><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p></o:p></span>

<p class="MsoNormal"><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p></o:p></span>

<p class="MsoNormal" style="margin-left:.5in"><span 
style='font-size:10.0pt;font-family:Tahoma'><font face="Tahoma"><font size=-1>-----Original
Message-----</font></font>
<br><span style='font-weight:bold'><font face="Tahoma"><font size=-1><b>From:</span></b>
David A. Cooper [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</font></font>
<br><span style='font-weight:bold'><font face="Tahoma"><font size=-1><b>Sent:</span></span><st1:date
Month="9" Day="5" Year="2001"><span style='font-size:
 10.0pt;font-family:Tahoma'></b>Wednesday,
September 05, 2001</span></st1:date><span style='font-size:10.0pt;font-family:Tahoma'></span><st1:time
Hour="7" Minute="39"><span style='font-size:10.0pt;
 font-family:Tahoma'>7:39
AM</font></font></span></st1:time><span 
style='font-size:10.0pt;font-family:Tahoma'>
<br><span style='font-weight:bold'><font face="Tahoma"><font size=-1><b>To:</span></b>
IETF-PKIX</font></font>
<br><span style='font-weight:bold'><font face="Tahoma"><font size=-1><b>Subject:</span></b>
Re: Removing expired certificates from CRLs.....</font></font></span>

<p class="MsoNormal" style="margin-left:.5in"><span 
style='font-size:12.0pt'><o:p></o:p></span>

<p class="MsoNormal" style="margin-left:.5in"><span 
style='font-size:12.0pt'><font face="Times New Roman"><font size=+0>At&nbsp;</span><st1:time Hour="15" Minute="53"></font></font>03:53
PM</st1:time><st1:date Month="9" Day="5" Year="2001">9/5/01</st1:date>
+0200, Nada Kapidzic Cicovic wrote:
<br><![if !supportLineBreakNewLine]>
<br><![endif]><o:p></o:p>

<p class="MsoNormal" style="margin-left:.5in"><span 
style='font-size:12.0pt'><font face="Times New Roman"><font size=+0>Denis,</font></font>
<p><font face="Times New Roman"><font size=+0>I was making comments on
the text which Ryan extracted in his mail, assuming that they were from
the son-of-RFC2459.</font></font>
<p><font face="Times New Roman"><font size=+0>In particular the last sentence
in this paragraph:</font></font>
<p><font face="Times New Roman"><font size=+0>The&nbsp;</span><span style='font-size:10.0pt;font-weight:
bold'></font></font><b><font size=-1>distributionPoint&nbsp;</span></font></b>component
contains the name of the distribution point in one or more name forms.
If this field is absent, the CRL shall contain entries for all revoked
certificates issued by the CRL issuer.&nbsp;<span 
style='font-weight:bold;font-style:italic'><b><i>After
a certificate appears on a CRL, it is deleted from a subsequent CRL after
the certificate's expiry.</i></b>
<p></span>However, after getting your comment I realized that this sentence
and the referred section 8.6.2.2 comes from the X.509 (the latest version
that I have on my disk is X_509_4thEditionDraftV6, and it contains the
above text).&nbsp;<o:p></o:p>

<p class="MsoNormal" style="margin-left:.5in"><span 
style='font-size:12.0pt'>
<br><font face="Times New Roman"><font size=+0>I have X_509_4thEditionDraftV8
on my computer and it appears that this has been fixed. I now says "After
a certificate appears on a CRL, it&nbsp;<span 
style='font-weight:bold'><b>may
be</span></b> deleted from a subsequent CRL after the certificate's expiry."&nbsp;
I didn't bother to look at son-of-2459.</font></font>
<p><font face="Times New Roman"><font size=+0>In any case, both X.509 and
son-of-2459 should say that a certificate may be deleted from a CRL after
it has expired.&nbsp; In general, though, I don't think there is much benefit
to leaving expired certificates on CRLs.&nbsp; The problem is that, at
the moment, if an expired certificate is not listed on a CRL, there is
no way to determine whether it is not listed because it was never revoked
or if it was revoked but is not listed because it was removed after expiration.</font></font>
<p><font face="Times New Roman"><font size=+0>Some time ago, there was
a suggestion to create a new, non-critical CRL extension that would specify
whether an expired certificate was covered by a CRL (e.g., the extension
could state: "This CRL includes all revoked certificates that expire(d)
after&nbsp;</span><st1:date Month="1" Day="1"
Year="2001"></font></font>Jan.
1, 2001</st1:date> (i.e., notAfter >= 010101000000Z)."). There didn't seem
to be much support for this idea, so the extension was never created.
<p><![if !supportLineBreakNewLine]>
<br><![endif]><o:p></o:p>

<p class="MsoNormal" style="margin-left:.5in"><span 
style='font-size:12.0pt'><font face="Times New Roman"><font size=+0>The
current text of the son-of-RFC2459 does not seem to contain it or any other
misleading sentences regarding this issue.</font></font>
<p><font face="Times New Roman"><font size=+0>Sorry for the confusion.</font></font>
<p><font face="Times New Roman"><font size=+0>Nada</font></font><o:p></o:p></span>

<p class="MsoNormal" style="margin-left:.5in"><span 
style='font-size:12.0pt'><o:p></o:p></span></div>
</blockquote>

</body>
</html>

--------------512E1D8EABB90226977BBA41--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f86M1xN15867 for ietf-pkix-bks; Thu, 6 Sep 2001 15:01:59 -0700 (PDT)
Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f86M1vD15863 for <[e-mail]>; Thu, 6 Sep 2001 15:01:57 -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.3) with SMTP id f86M1pa09378; Thu, 6 Sep 2001 15:01:51 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "PKIX \(E-mail\)" <[e-mail]>
Subject: RE: Logos: objection to charter revisions
Date: Thu, 6 Sep 2001 15:00: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)
Importance: Normal
In-reply-to: <[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>

Further, of what utility is a logo to an IPSEC gateway, for example?  I
suspect about as much value as embedded text asserting a relying party's
obligations.

Mike

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Denis Pinkas
> Sent: Thursday, September 06, 2001 2:03 AM
> Cc: PKIX (E-mail)
> Subject: Re: Logos: objection to charter revisions
>
>
>
>
> After seeing all that discussion about logos, I realized that we had
> a solution (i.e. the draft writen by Stefan) for an unknown problem.
>
> 1) Are logos to be used in server certificates ?
>    If so, what would be their intended meaning ?
>
> 2) Are logos to be used in human-user certificates ?
>    If so, what would be their intended meaning ?
>
> 3) Are logos to be used in CA certificates ?
>    If so, what would be their intended meaning ?
>
> 4) Are logos to be used in self-signed certificates ?
>    If so, what would be their intented meaning ?
>
> I do not think that the meaning and the use of the logo information will
> necessarilly be the same for all of the above cases.
>
> If that topic is going to stay on the charter, before we define a solution
> we should first define the requirements. So an INFORMATIONAL RFC on the
> requirements should be the first step. This Informational RFC should at
> least answer to the questions raised above.
>
> Denis
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f86KFwI13518 for ietf-pkix-bks; Thu, 6 Sep 2001 13:15:58 -0700 (PDT)
Received: from phnxpop4.phnx.uswest.net (phnxpop4.phnx.uswest.net [206.80.192.4]) by above.proper.com (8.11.6/8.11.3) with SMTP id f86KFuD13514 for <[e-mail]>; Thu, 6 Sep 2001 13:15:57 -0700 (PDT)
Received: (qmail 50039 invoked by alias); 6 Sep 2001 20:15:54 -0000
Delivered-To: [e-mail]@fixme
Received: (qmail 49659 invoked by uid 0); 6 Sep 2001 20:15:50 -0000
Received: from aydialup158.phnx.uswest.net (HELO ?192.168.0.2?) (63.225.214.158) by phnxpop4.phnx.uswest.net with SMTP; 6 Sep 2001 20:15:50 -0000
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <a05100305b7bd87a263b6@[192.168.0.2]>
Date: Thu, 6 Sep 2001 13:14:02 -0700
To: "X.509":;, IETF LDAP <[e-mail]>
From: "Hoyt L. Kesterson II" <[e-mail]>
Subject: Version 15 of the Implementor's Guide for X.500
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>

Version 15 of the guide can be found in bookmarked PDF at

 
ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/Implementor%27sGuideV15.pdf

The version contains a defect summary, TCs correcting errors, and 
DTCs under ballot for the 3rd and 4th edition. Those still interested 
in the 2nd edition should keep Version 14 of the guide.

Although this guide contains corrections to all the parts of the 
X.500 recommendation, bookmarks point directly to the TCs for both 
editions of X.509.

The file is about 1.3 MB in size

    hout


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f86JXXS12753 for ietf-pkix-bks; Thu, 6 Sep 2001 12:33:33 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f86JXVD12749 for <[e-mail]>; Thu, 6 Sep 2001 12:33:31 -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 PAA373504; Thu, 6 Sep 2001 15:31:13 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f86JPKa53578; Thu, 6 Sep 2001 15:25:20 -0400
Importance: Normal
Subject: RE: Removing expired certificates from CRLs.....
To: "Flynn, Michael" <[e-mail]>
Cc: "'Ryan Hurst'" <[e-mail]>, IETF-PKIX <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Thu, 6 Sep 2001 15:18:57 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.8 SPR #MIAS4UTJ8H |June 21, 2001) at 09/06/2001 03:33:27 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>

     Because of unscheduled CRL publication, would it not make sense to
recommend a minimum period of time after expiration before revoked NR
certificates get removed from CRL's?  In practice, specifying that they
should be kept for a week or so beyond expiration would not cause CRL
bloat, which can admittedly become a serious problem if all CRL entries are
kept forever.

          Tom Gindin



"Flynn, Michael" <[e-mail]>@mail.imc.org on 09/05/2001 01:02:33
PM

Sent by:  [e-mail]


To:   "'Ryan Hurst'" <[e-mail]>, IETF-PKIX <[e-mail]>
cc:
Subject:  RE: Removing expired certificates from CRLs.....


Ryan,

Ryan wrote::


Now logically it makes sense to remove certificates that are expired from
CRLs to control size, yes this has a negative point specifically it
prevents CRLs from being used as a non-repudiation source; but this is mute
due to many other issues.





At least regarding removing expired certs from CRLs, I would think that
non-repudiation can be satisfied by keeping the old CRLs in back up storage
for some length of time.  That time being how far back in time a contract
dispute might go; ten years, twenty?   So long as you could get them off
tape for the lawyers to look at the legal process would be satisfied, they
don't need to be online forever.





Michael





 -----Original Message-----
 From: Ryan Hurst [mailto:[e-mail]]
 Sent: Tuesday, September 04, 2001 8:50 PM
 To: IETF-PKIX
 Subject: Removing expired certificates from CRLs.....



 I was speaking with Peter Williams today about the removal of expired
 certificates from CRLs; I have always been under the belief that this
 behavior was optional, I vaguely remembered reading text in 2459 along
 those lines; additionally I know of several commercial CAs that do not
 remove the expired certificates from their CRLs. Peter on the other hand
 was under the impression that it was a mandate to remove CRLs; he too
 remembered reading text in 2459 to support is position.





 So we each pulled out the RFC and found that we were both right!
 Specifically both sections 3.3 and 8.6.2.2 have text on this subject:





 3.3  Revocation


 When a certificate is issued, it is expected to be in use for its entire
 validity period.  However, various circumstances may cause a certificate
 to become invalid prior to the expiration of the validity period.





 ....





 An entry is added to the CRL as part of the next update following
 notification of revocation. An entry may be removed from the CRL after
 appearing on one regularly scheduled CRL issued beyond the revoked
 certificate's validity period.











 8.6.2.2 Issuing distribution point extension


 This CRL extension field identifies the CRL distribution point for this
 particular CRL, and indicates if the CRL is limited to revocations for
 end-entity certificates only, for authority certificates only, or for a
 limited set of reasons only. The CRL is signed by the CRL issuer's key-
 CRL distribution points do not have their own key pairs. However, for a
 CRL distributed via the Directory, the CRL is stored in the entry of the
 CRL distribution point, which may not be the directory entry of the CRL
 issuer. If this field is absent, the CRL shall contain entries for all
 revoked unexpired certificates issued by the CRL issuer.





 ....





 The distributionPoint component contains the name of the distribution
 point in one or more name forms. If this field is absent, the CRL shall
 contain entries for all revoked certificates issued by the CRL issuer.
 After a certificate appears on a CRL, it is deleted from a subsequent CRL
 after the certificate's expiry.








 Although section 8.6.2.2 is specifically in regards to CRLdps, any
 difference between full CRLs and CRLdps in this case I feel would be an
 arbitrary one.





 Now logically it makes sense to remove certificates that are expired from
 CRLs to control size, yes this has a negative point specifically it
 prevents CRLs from being used as a non-repudiation source; but this is
 mute due to many other issues.





 That being the case I think; and I believe Peter would agree the correct
 thing to do is to remove these expired/revoked entries from the CRL.





 The question now is what is the PKIX stance on this matter?





 Ryan M. Hurst


 ValiCert, Inc.



      "It may roundly be asserted that human ingenuity cannot concoct a
      cipher which human ingenuity cannot resolve."
      -Edgar Allan Poe








Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f86HsrE10138 for ietf-pkix-bks; Thu, 6 Sep 2001 10:54:53 -0700 (PDT)
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f86HspD10131 for <[e-mail]>; Thu, 6 Sep 2001 10:54:51 -0700 (PDT)
Received: from vhqpostal-gw1.verisign.com (mailer1.verisign.com [65.205.251.55]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id f86Hq5m13935; Thu, 6 Sep 2001 10:52:05 -0700 (PDT)
Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2653.19) id <R5GASAYR>; Thu, 6 Sep 2001 10:54:50 -0700
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'Steve Hanna'" <[e-mail]>, "Manger, James H" <[e-mail]>
Cc: "PKIX (E-mail)" <[e-mail]>
Subject: RE: Logos: objection to charter revisions
Date: Thu, 6 Sep 2001 10:54:49 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C136FD.058DCF10"
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_000_01C136FD.058DCF10
Content-Type: text/plain;
	charset="iso-8859-1"

I still fail to see the problem, if you have a cross certified cert chain
you should show the entire chain as logos.

So the user would see the following 

[VeriSign PCA3] -> [SureTrust] -> [British Stuff PLC] -> [Alice]

Or

[JIS RoT] -X-> [BAL RoT] -X-> [Bob]

In other words there is no need for constraints because the user is going to
see the trust chain explicitly.

I don't see any problem in stating that logotypes on end user certs should
only be displayed if the root of trust says to use 'em. I think it is pretty
clear that the app software vendors would want to load the new roots of
trust with the images in them.

I would not want to have to re-issue several thousand intermediate CAs to
support logotypes however. So the OID for the root cert would have to allow
for the following cases:

1) Show logotypes of any cert in the chain that has one.

2) Only show logotypes if every cert bellow this one in the chain has a
'show logotypes' OID.


		Phill


Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
[e-mail]
781 245 6996 x227

 


------_=_NextPart_000_01C136FD.058DCF10
Content-Type: application/octet-stream;
	name="Phillip Hallam-Baker (E-mail).vcf"
Content-Disposition: attachment;
	filename="Phillip Hallam-Baker (E-mail).vcf"

BEGIN:VCARD
VERSION:2.1
N:Hallam-Baker;Phillip
FN:Phillip Hallam-Baker (E-mail)
ORG:VeriSign
TITLE:Principal Consultant
TEL;WORK;VOICE:[phone] x227
EMAIL;PREF;INTERNET:[e-mail]
REV:20010214T163732Z
END:VCARD

------_=_NextPart_000_01C136FD.058DCF10--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f86FOaE02330 for ietf-pkix-bks; Thu, 6 Sep 2001 08:24:36 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f86FOYD02326 for <[e-mail]>; Thu, 6 Sep 2001 08:24: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 RAA12236; Thu, 6 Sep 2001 17:23:50 +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 RAA16542; Thu, 6 Sep 2001 17:21:13 +0200
Message-ID: <[e-mail]>
Date: Thu, 06 Sep 2001 17:21:16 +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 A. Cooper" <[e-mail]>
CC: IETF-PKIX <[e-mail]>
Subject: Re: Removing expired certificates from 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,

> > > With the 509 meeting coming up in just a couple of weeks,
> > > if we reach consensus that it would be useful to add either
> > > a new extension or a new component to the IDP extension to indicate
> > > that a CRL includes revocation notices for expired certs,
> > > we could probably add it to the 509 WD at that meeting.

> >At this time it is more an X.509 discussion, rather than a PKIX discussion.
> >Anyway, I would support in principle the idea for X.509.

> >The information could be placed either in the certificate or in the CRL.
> >Placing it in the CRL has the advantage of not overloading the certificate,
> >so this solution should be better. So, if the information is placed in the
> >CRL, then the CRL should say something like: certificates which have the
> >keyUsage bits set to XXXX are maintained on the CRL Y weeks after they
> >expire.
 
> I agree that the information should be placed in the CRL. This provides 
> the CRL issuer with flexibility.

> The idea of specifying keyUsage bits sounds interesting. This could be used 
> to specify that only certificates used to verify signatures 
> (i.e., keyUsage of digitalSignature and/or nonRepudiation) are listed after 
> expiration. I can't think of any compelling reason to include key management 
> certificates after they have expired. 

OK.

> However, I'm not sure if the benefit is worth the increased complexity.

Every time an new extension is added, an additional piece of software is
needed to handle it. Yes, this is debatable, but the problem we currently
have, is that the only current way to know that certificates are still
maintained in the CRL after they expire is by using the PDS, which is not
machine processable. When PDS are used, the time certificates are maintained
in the CRL after they expire cannot be changed very often.
 
> I would also suggest a slight re-wording of the meaning of the extension 
> to "this CRL lists all revoked certificates that have expired within the 
> last Y weeks (in addition to all unexpired revoked certificates)."
> The extension should only specify what is included in that particular CRL, 
> it should not make any promises about what is included in other CRLs. 
> The CRL issuer should always be free to expand or shrink the set of 
> expired certificates covered by its CRLs.

I agree. The time may vary from one CRL to the next, so it allows to change
the policy over time.

Denis

> Dave


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f86FBuT01733 for ietf-pkix-bks; Thu, 6 Sep 2001 08:11:56 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f86FBpD01729 for <[e-mail]>; Thu, 6 Sep 2001 08:11:52 -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 RAA13574; Thu, 6 Sep 2001 17:13:49 +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 RAA17414; Thu, 6 Sep 2001 17:11:13 +0200
Message-ID: <[e-mail]>
Date: Thu, 06 Sep 2001 17:11:15 +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: "'David A. Cooper'" <[e-mail]>, IETF-PKIX <[e-mail]>, "Hoyt Kesterson (E-mail)" <[e-mail]>
Subject: Re: Removing expired certificates from 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>

Sharon,

> Denis, sorry for the display problem - I cut and pasted the text
> from the actual TC - next time I'll try to remember not to do that :-)
 
> Actually, I'm second-guessing the value of the extension. I think it is
> generally the case that good key management would have the signing key
> rolled over long before the expiry date of the verification certificate 
> so hopefully the chances of a signature being applied "just" before a
> certificate expired would be slim/none. 

It is true that I get my next (Visa) credit card (valid two years) 
one month in advance, but nothing prevents me to use it, until the very 
last day of its validity period.

> If that is true, then original validation would be happening before 
> the certificate expired. If the RP needs to be able to argue
> that the signature was good at that time, it shouldn't be relying 
> on a future CRL at the time they need to do that defence because
> there may not be one available, regardless of whether it contains 
> this extension or not (CAs go out of business, their policy of CRL 
> issuance may have changed etc). If the RP needs to be able to defend 
> the validation, it would need to retain the evidence from the time 
> of original validation, including a timestamped copy of the signed 
> document, CRL that was valid at the time of verification etc.

If the CRL includes the information, then it is usable, otherwise it is not.
When a CA goes out of business, it should have previously taken provisions
to transmit the task of providing certificate status information to another
authority. As an example ETSI TS 101 456 states:

"The CA shall have an arrangement to cover the costs to fulfil these minimum
requirements in case the CA becomes bankrupt or for other reasons is unable
to cover the costs by itself.

c) The CA shall state in its practices the provisions made for termination
of service. This shall include:
 
 - notification of affected entities,
 - transferring the CA obligations to other parties,
 - how the revocation status of unexpired certificates that have been issued
   will be handled."

Denis
 
> Sharon
> 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Thursday, September 06, 2001 10:12 AM
> > To: Sharon Boeyen
> > Cc: 'David A. Cooper'; IETF-PKIX; Hoyt Kesterson (E-mail)
> > Subject: Re: Removing expired certificates from CRLs.....
> >
> >
> >
> > Hi Sharon,
> >
> > Glad to see back on the PKIX mailing list for a short while. :-)
> >
> > > David I do remember some discussion of a new extension but
> > > don't recall the reason why it wasn't pursued - do you remember?
> >
> > > With the 509 meeting coming up in just a couple of weeks,
> > > if we reach consensus that it would be useful to add either
> > > a new extension or a new component to the IDP extension to indicate
> > > that a CRL includes revocation notices for expired certs,
> > > we could probably add it to the 509 WD at that meeting.
> >
> > At this time it is more an X.509 discussion, rather than a
> > PKIX discussion.
> > Anyway, I would support in principle the idea for X.509.
> >
> > The information could be placed either in the certificate or
> > in the CRL.
> > Placing it in the CRL has the advantage of not overloading
> > the certificate,
> > so this solution should be better. So, if the information is
> > placed in the
> > CRL, then the CRL should say something like: certificates
> > which have the
> > keyUsage bits set to XXXX are maintained on the CRL Y weeks after they
> > expire.
> >
> > One of the main benefits is the following: you receive an
> > e-mail while on
> > holidays. The signature was done just before the certificate
> > expired, but
> > the e-amil was opened after it expired. With this additional
> > feature it
> > would be possible to know by fetching the current CRL whether
> > the e-mail was
> > signed legitimately.
> >
> > > I believe there is value in allowing expired certs to remain
> > > on CRLs, but certainly it should be an optional feature as
> > > it is not needed in all environments.
> >
> > True.
> >
> > Regards,
> >
> > Denis
> >
> > > Cheers,
> > > Sharon
> >
> >
> > BTW: my Netscape 4.7 browser is unable to display your
> > message correctly.
> > Next time, please use plaintext.
> >


Received: by above.proper.com (8.11.6/8.11.3) id f86F9VE01587 for ietf-pkix-bks; Thu, 6 Sep 2001 08:09:31 -0700 (PDT)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f86F9TD01583 for <[e-mail]>; Thu, 6 Sep 2001 08:09:29 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id DAA22596; Fri, 7 Sep 2001 03:09:20 +1200 (NZST) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id DAA172308; Fri, 7 Sep 2001 03:09:20 +1200 (NZST) (sender [e-mail])
Date: Fri, 7 Sep 2001 03:09:20 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re:  Polling in CMP
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>

>  reason   [0] PKIFreeText OPTIONAL

You put the spurious tag in there just to ensure you'd get a reply from me,
right? :-).

Peter.


Received: by above.proper.com (8.11.6/8.11.3) id f86EqiJ01241 for ietf-pkix-bks; Thu, 6 Sep 2001 07:52:44 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f86EqhD01237 for <[e-mail]>; Thu, 6 Sep 2001 07:52:44 -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 KAA08193 for <[e-mail]>; Thu, 6 Sep 2001 10:52:44 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Thu, 06 Sep 2001 10:51:57 -0400
To: IETF-PKIX <[e-mail]>
From: "David A. Cooper" <[e-mail]>
Subject: Re: Removing expired certificates from CRLs.....
In-Reply-To: <[e-mail]>
References: <[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>

At 04:11 PM 9/6/01 +0200, Denis Pinkas wrote:

>At 09:41 AM 9/6/01 -0400, Sharon Boeyen wrote:
> > With the 509 meeting coming up in just a couple of weeks, 
> > if we reach consensus that it would be useful to add either 
> > a new extension or a new component to the IDP extension to indicate 
> > that a CRL includes revocation notices for expired certs, 
> > we could probably add it to the 509 WD at that meeting. 
>
>At this time it is more an X.509 discussion, rather than a PKIX discussion.
>Anyway, I would support in principle the idea for X.509. 
>
>The information could be placed either in the certificate or in the CRL.
>Placing it in the CRL has the advantage of not overloading the certificate,
>so this solution should be better. So, if the information is placed in the
>CRL, then the CRL should say something like: certificates which have the 
>keyUsage bits set to XXXX are maintained on the CRL Y weeks after they
>expire.

I agree that the information should be placed in the CRL. This provides the CRL issuer with flexibility.

The idea of specifying keyUsage bits sounds interesting. This could be used to specify that only certificates used to verify signatures (i.e., keyUsage of digitalSignature and/or nonRepudiation) are listed after expiration. I can't think of any compelling reason to include key management certificates after they have expired. However, I'm not sure if the benefit is worth the increased complexity.

I would also suggest a slight re-wording of the meaning of the extension to "this CRL lists all revoked certificates that have expired within the last Y weeks (in addition to all unexpired revoked certificates).". The extension should only specify what is included in that particular CRL, it should not make any promises about what is included in other CRLs. The CRL issuer should always be free to expand or shrink the set of expired certificates covered by its CRLs.

Dave



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f86Ekmj01074 for ietf-pkix-bks; Thu, 6 Sep 2001 07:46:48 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f86EkhD01069 for <[e-mail]>; Thu, 6 Sep 2001 07:46:44 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <SM1TANSF>; Thu, 6 Sep 2001 10:46:38 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, Sharon Boeyen <[e-mail]>
Cc: "'David A. Cooper'" <[e-mail]>, IETF-PKIX <[e-mail]>, "Hoyt Kesterson (E-mail)" <[e-mail]>
Subject: RE: Removing expired certificates from CRLs.....
Date: Thu, 6 Sep 2001 10:46:37 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C136E2.BB501120"
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_01C136E2.BB501120
Content-Type: text/plain

Denis, sorry for the display problem - I cut and pasted the text 
from the actual TC - next time I'll try to remember not to do that :-)

Actually, I'm second-guessing the value of the extension. I think it is 
generally the case that good key management would have the signing key 
rolled over long before the expiry date of the verification certificate so 
hopefully the chances of a signature being applied "just" before a
certificate
expired would be slim/none. If that is true, then original validation would 
be happening before the certificate expired. If the RP needs to be able to
argue 
that the signature was good at that time, it shouldn't be relying on a
future 
CRL at the time they need to do that defence because there may not be one 
available, regardless of whether it contains this extension or not (CAs go
out 
of business, their policy of CRL issuance may have changed etc). If the RP
needs 
to be able to defend the validation, it would need to retain the evidence
from 
the time of original validation, including a timestamped copy of the signed
document,
CRL that was valid at the time of verification etc.

Sharon

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Thursday, September 06, 2001 10:12 AM
> To: Sharon Boeyen
> Cc: 'David A. Cooper'; IETF-PKIX; Hoyt Kesterson (E-mail)
> Subject: Re: Removing expired certificates from CRLs.....
> 
> 
> 
> Hi Sharon,
> 
> Glad to see back on the PKIX mailing list for a short while. :-)
> 
> > David I do remember some discussion of a new extension but 
> > don't recall the reason why it wasn't pursued - do you remember? 
>  
> > With the 509 meeting coming up in just a couple of weeks, 
> > if we reach consensus that it would be useful to add either 
> > a new extension or a new component to the IDP extension to indicate 
> > that a CRL includes revocation notices for expired certs, 
> > we could probably add it to the 509 WD at that meeting. 
> 
> At this time it is more an X.509 discussion, rather than a 
> PKIX discussion.
> Anyway, I would support in principle the idea for X.509. 
> 
> The information could be placed either in the certificate or 
> in the CRL.
> Placing it in the CRL has the advantage of not overloading 
> the certificate,
> so this solution should be better. So, if the information is 
> placed in the
> CRL, then the CRL should say something like: certificates 
> which have the 
> keyUsage bits set to XXXX are maintained on the CRL Y weeks after they
> expire.
> 
> One of the main benefits is the following: you receive an 
> e-mail while on
> holidays. The signature was done just before the certificate 
> expired, but
> the e-amil was opened after it expired. With this additional 
> feature it
> would be possible to know by fetching the current CRL whether 
> the e-mail was
> signed legitimately.
> 
> > I believe there is value in allowing expired certs to remain 
> > on CRLs, but certainly it should be an optional feature as 
> > it is not needed in all environments.
> 
> True.
> 
> Regards,
> 
> Denis 
>  
> > Cheers,
> > Sharon
> 
> 
> BTW: my Netscape 4.7 browser is unable to display your 
> message correctly.
> Next time, please use plaintext.
> 

------_=_NextPart_001_01C136E2.BB501120
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: Removing expired certificates from CRLs.....</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Denis, sorry for the display problem - I cut and pasted the text </FONT>
<BR><FONT SIZE=2>from the actual TC - next time I'll try to remember not to do that :-)</FONT>
</P>

<P><FONT SIZE=2>Actually, I'm second-guessing the value of the extension. I think it is </FONT>
<BR><FONT SIZE=2>generally the case that good key management would have the signing key </FONT>
<BR><FONT SIZE=2>rolled over long before the expiry date of the verification certificate so </FONT>
<BR><FONT SIZE=2>hopefully the chances of a signature being applied &quot;just&quot; before a certificate</FONT>
<BR><FONT SIZE=2>expired would be slim/none. If that is true, then original validation would </FONT>
<BR><FONT SIZE=2>be happening before the certificate expired. If the RP needs to be able to argue </FONT>
<BR><FONT SIZE=2>that the signature was good at that time, it shouldn't be relying on a future </FONT>
<BR><FONT SIZE=2>CRL at the time they need to do that defence because there may not be one </FONT>
<BR><FONT SIZE=2>available, regardless of whether it contains this extension or not (CAs go out </FONT>
<BR><FONT SIZE=2>of business, their policy of CRL issuance may have changed etc). If the RP needs </FONT>
<BR><FONT SIZE=2>to be able to defend the validation, it would need to retain the evidence from </FONT>
<BR><FONT SIZE=2>the time of original validation, including a timestamped copy of the signed document,</FONT>
<BR><FONT SIZE=2>CRL that was valid at the time of verification etc.</FONT>
</P>

<P><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, September 06, 2001 10:12 AM</FONT>
<BR><FONT SIZE=2>&gt; To: Sharon Boeyen</FONT>
<BR><FONT SIZE=2>&gt; Cc: 'David A. Cooper'; IETF-PKIX; Hoyt Kesterson (E-mail)</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: Removing expired certificates from CRLs.....</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi Sharon,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Glad to see back on the PKIX mailing list for a short while. :-)</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; David I do remember some discussion of a new extension but </FONT>
<BR><FONT SIZE=2>&gt; &gt; don't recall the reason why it wasn't pursued - do you remember? </FONT>
<BR><FONT SIZE=2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt; With the 509 meeting coming up in just a couple of weeks, </FONT>
<BR><FONT SIZE=2>&gt; &gt; if we reach consensus that it would be useful to add either </FONT>
<BR><FONT SIZE=2>&gt; &gt; a new extension or a new component to the IDP extension to indicate </FONT>
<BR><FONT SIZE=2>&gt; &gt; that a CRL includes revocation notices for expired certs, </FONT>
<BR><FONT SIZE=2>&gt; &gt; we could probably add it to the 509 WD at that meeting. </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; At this time it is more an X.509 discussion, rather than a </FONT>
<BR><FONT SIZE=2>&gt; PKIX discussion.</FONT>
<BR><FONT SIZE=2>&gt; Anyway, I would support in principle the idea for X.509. </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; The information could be placed either in the certificate or </FONT>
<BR><FONT SIZE=2>&gt; in the CRL.</FONT>
<BR><FONT SIZE=2>&gt; Placing it in the CRL has the advantage of not overloading </FONT>
<BR><FONT SIZE=2>&gt; the certificate,</FONT>
<BR><FONT SIZE=2>&gt; so this solution should be better. So, if the information is </FONT>
<BR><FONT SIZE=2>&gt; placed in the</FONT>
<BR><FONT SIZE=2>&gt; CRL, then the CRL should say something like: certificates </FONT>
<BR><FONT SIZE=2>&gt; which have the </FONT>
<BR><FONT SIZE=2>&gt; keyUsage bits set to XXXX are maintained on the CRL Y weeks after they</FONT>
<BR><FONT SIZE=2>&gt; expire.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; One of the main benefits is the following: you receive an </FONT>
<BR><FONT SIZE=2>&gt; e-mail while on</FONT>
<BR><FONT SIZE=2>&gt; holidays. The signature was done just before the certificate </FONT>
<BR><FONT SIZE=2>&gt; expired, but</FONT>
<BR><FONT SIZE=2>&gt; the e-amil was opened after it expired. With this additional </FONT>
<BR><FONT SIZE=2>&gt; feature it</FONT>
<BR><FONT SIZE=2>&gt; would be possible to know by fetching the current CRL whether </FONT>
<BR><FONT SIZE=2>&gt; the e-mail was</FONT>
<BR><FONT SIZE=2>&gt; signed legitimately.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; I believe there is value in allowing expired certs to remain </FONT>
<BR><FONT SIZE=2>&gt; &gt; on CRLs, but certainly it should be an optional feature as </FONT>
<BR><FONT SIZE=2>&gt; &gt; it is not needed in all environments.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; True.</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;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Cheers,</FONT>
<BR><FONT SIZE=2>&gt; &gt; Sharon</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; BTW: my Netscape 4.7 browser is unable to display your </FONT>
<BR><FONT SIZE=2>&gt; message correctly.</FONT>
<BR><FONT SIZE=2>&gt; Next time, please use plaintext.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C136E2.BB501120--


Received: by above.proper.com (8.11.6/8.11.3) id f86EVxF29767 for ietf-pkix-bks; Thu, 6 Sep 2001 07:31:59 -0700 (PDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f86EVvD29760 for <[e-mail]>; Thu, 6 Sep 2001 07:31:57 -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 IAA22802; Thu, 6 Sep 2001 08:31:56 -0600 (MDT)
Received: from sun.com (dhcp75-167 [129.148.75.167]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03465; Thu, 6 Sep 2001 10:31:56 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 06 Sep 2001 10:31:35 -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: "Manger, James H" <[e-mail]>
CC: "PKIX (E-mail)" <[e-mail]>
Subject: Re: Logos: objection to charter revisions
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>

"Manger, James H" wrote:
> You says "nobody has been able to come up with any way to fix [the
> current logo proposal]" and conclude "that it can't be fixed".
>  .. but you provide fixes earlier in the same e-mail!

That will teach me to offer constructive suggestions! ;-)

> Your statement that logos should be "ignored unless all certificates in the
> path indicate that they should be supported" is just the sort of "logo
> constraint" that enables safe use of logos.

I still wouldn't call this "safe". There are other concerns that haven't
have been addressed (problems with scaling or color mapping,
accessibility concerns, etc.). But at least a "logo constraint" (or,
more accurately, a "logo enabler") would restrict use of logos to
communities that have considered these concerns and decided that they
are acceptable.

-Steve


Received: by above.proper.com (8.11.6/8.11.3) id f86EQGK29133 for ietf-pkix-bks; Thu, 6 Sep 2001 07:26:16 -0700 (PDT)
Received: from bigbird.gradient.com (bigbird.gradient.com [192.92.110.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f86EQFD29129 for <[e-mail]>; Thu, 6 Sep 2001 07:26:15 -0700 (PDT)
Received: by bigbird.gradient.com with Internet Mail Service (5.5.2650.10) id <SALVYX5X>; Thu, 6 Sep 2001 10:28:30 -0400
Message-ID: <[e-mail]>
From: Hal Lockhart <[e-mail]>
To: "'Bland, Graham'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Charter Revisions, Logotype Business models
Date: Thu, 6 Sep 2001 10:28:24 -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>

> CA Logo
> End Entity requests a certificate with or without a logotype 
> included in the
> cert request as above.  In this case the CA wishes to place a 
> logo in the
> issued cert to indicate something; for example this is a Visa 
> Cert.  I do
> not see the logo reference being requested by the end entity 
> in this case,
> more of it being inserted by the CA.  this is the primary 
> trust mechanism
> (this cert was issued by Visa) not this cert belongs to Visa.

Funny you should mention this case. It is my understanding that in many
cases today, the plastic credit card is legally the property of the issuer.
(typically the bank, but sometimes the card company) Among other things,
this makes it easier for them to demand its return under any conditions they
choose.

The PKI-related aspect of this is that some card issuers intend to issue (or
may already have issued) smartcards with secrets intented to be inaccessable
to the consumer. 

Hal


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f86EM8b29014 for ietf-pkix-bks; Thu, 6 Sep 2001 07:22:08 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f86EM5D29010 for <[e-mail]>; Thu, 6 Sep 2001 07:22:05 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 6 Sep 2001 14:19:31 UT
Received: from spirit.dynas.se (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with SMTP id KAA17022 for <[e-mail]>; Thu, 6 Sep 2001 10:18:29 -0400 (EDT)
Received: (qmail 14219 invoked from network); 6 Sep 2001 14:18:28 -0000
Received: from mnystrom-lap.d.dynas.se (HELO mnystrom-lap) (172.16.13.167) by spirit.dynas.se with SMTP; 6 Sep 2001 14:18:28 -0000
Date: Thu, 6 Sep 2001 16:19:28 +0200 (W. Europe Daylight Time)
From: Magnus Nystrom <[e-mail]>
Reply-To: =?iso-8859-1?Q?Magnus_Nystr=F6m?= <[e-mail]>
To: <[e-mail]>
cc: "Richards, Gareth" <[e-mail]>
Subject: Polling in CMP
Message-ID: <Pine.WNT.4.31.0109061610040.1220-100000@mnystrom-lap>
X-X-Sender: [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>

All,

Going back to a topic discussed earlier this year, and after
discussions with various individuals at the recent IETF in London, we
would like to propose the attached simple extension to CMP to handle
polling. The reason for this proposal is as stated previously - we
feel that a protocol which specifies a "wait - come back later"
server status also should specify how a client should poll the server,
rather than deferring this to transport protocols.

Assume that the CMP enrollment is taking place in a browser script and
the browser may be terminated before the polling is complete. Then a
way of saving state and continuing the polling at a later date is
needed.  If the polling is done in CMP then this is possible by
reissuing the request or whatever but if it is done by the transport
layer then it does not seem clear how this is going to be done.

Thanks to Amit Kapoor for the original proposal regarding these
messages.

BR,
-- Magnus
Magnus Nystrom
RSA Security
--------------------------------------------------------------------------

pollReq    [25] PollReqContent
pollRep    [26] PollRepContent


PollRepContent ::= SEQUENCE OF SEQUENCE {
  certReqId    INTEGER,
  checkAfter   INTEGER,  -- time in seconds
  reason   [0] PKIFreeText OPTIONAL
}

PollReqContent ::= SEQUENCE OF SEQUENCE {
  certReqId    INTEGER
}

1. It is assumed that multiple certConf messages can be sent during
the transaction.  There will be one sent in response to each ip, cp or kup
containing a CertStatus for each approved certificate.   If a
single certConf must be sent for the transaction then it is possible that the
confirmWaitTime (rfc2510bis section 3.1.1.2) of the first certificate will have
expired before the second cert pickup has take place.

2. In response to an ip, cp or kup message, an EE will send a certConf for all
approved certificates and following the ack, a pollReq for all pending certificates.

2. In respose to a pollReq, a CA/RA will return a ip, cp or kup if one or more
of the pending certificates is ready otherwise it will return a pollRep.

3. If the EE receives a pollRep in return, it will wait for at least the lowest
checkAfter value before sending another pollReq.

4. If an ip, cp or kup is received in reply to a pollReq then it will be treated in
the same way as the initial response.

                                 Start
                                   |
                                   |
                                   \/
                                Send ir
                                   |
                                   | ip
                                   |
                                  \/
                              Check status
                               of of returned <----------------------------------|
                                certs.                                           |
                                   |                                             |
    |----------------------------->|<-----------------------|                    |
    |                              |                        |                    |
    |                             \/                        |                    |
                    approved                      waiting                        |
 Add to conf list <---------- Check CertResponse --------> Add to pending list   |
                                   /\                                            |
                        conf list /  \Empty conf list                            |
                                 /    \                     ip                   |
                                /      \         --------------------------------|
     Empty pending            /        \         |
           list               /          \       |         pRep
     End <--------- Send certConf         Send pReq-------------- Wait
                           |                 /\  /\                 |
                           |                 |    |                 |
                           -------------------    -------------------
                               Pending list              Wait


In the following exchange, the end entity is enroling for two certificates in one request.

Step  End Entity                            PKI
-------------------------------------------------------------------
1     Format ir
2                      -> ir      ->
3                                      Handle ir
4                                      Manual intervention is
                                       required for both certs.
5                      <- ip      <-
6     Process ip
7     Format pReq
8                      -> pReq     ->
9                                      Check status of certificate requests
10                                     Certificates not ready
11                                     Format pRep
12                     <- pRep     <-
13    Wait
14    Format pReq
15                     -> pReq     ->
16                                     Check status of certificate requests
17                                     One certificate is ready
18                                     Format ip
19                     <- ip       <-
20    Handle ip
21    Format certConf
22                     -> certConf ->
23                                     Handle certConf
24                                     Format ack
25                     <- pkiConf   <-
26    Format pReq
27                     -> pReq     ->
28                                     Check status of certificate
29                                     Certificate is ready
30                                     Format ip
31                     <- ip       <-
31    Handle ip
32    Format certConf
33                     -> certConf ->
34                                     Handle certConf
35                                     Format ack
36                     <- pkiConf  <-




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f86ECOc28582 for ietf-pkix-bks; Thu, 6 Sep 2001 07:12:24 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f86ECMD28571 for <[e-mail]>; Thu, 6 Sep 2001 07:12:22 -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 QAA23248; Thu, 6 Sep 2001 16:14:19 +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 QAA04586; Thu, 6 Sep 2001 16:11:43 +0200
Message-ID: <[e-mail]>
Date: Thu, 06 Sep 2001 16:11:46 +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: "'David A. Cooper'" <[e-mail]>, IETF-PKIX <[e-mail]>, "Hoyt Kesterson (E-mail)" <[e-mail]>
Subject: Re: Removing expired certificates from 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>

Hi Sharon,

Glad to see back on the PKIX mailing list for a short while. :-)

> David I do remember some discussion of a new extension but 
> don't recall the reason why it wasn't pursued - do you remember? 
 
> With the 509 meeting coming up in just a couple of weeks, 
> if we reach consensus that it would be useful to add either 
> a new extension or a new component to the IDP extension to indicate 
> that a CRL includes revocation notices for expired certs, 
> we could probably add it to the 509 WD at that meeting. 

At this time it is more an X.509 discussion, rather than a PKIX discussion.
Anyway, I would support in principle the idea for X.509. 

The information could be placed either in the certificate or in the CRL.
Placing it in the CRL has the advantage of not overloading the certificate,
so this solution should be better. So, if the information is placed in the
CRL, then the CRL should say something like: certificates which have the 
keyUsage bits set to XXXX are maintained on the CRL Y weeks after they
expire.

One of the main benefits is the following: you receive an e-mail while on
holidays. The signature was done just before the certificate expired, but
the e-amil was opened after it expired. With this additional feature it
would be possible to know by fetching the current CRL whether the e-mail was
signed legitimately.

> I believe there is value in allowing expired certs to remain 
> on CRLs, but certainly it should be an optional feature as 
> it is not needed in all environments.

True.

Regards,

Denis 
 
> Cheers,
> Sharon


BTW: my Netscape 4.7 browser is unable to display your message correctly.
Next time, please use plaintext.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f86DfnV27540 for ietf-pkix-bks; Thu, 6 Sep 2001 06:41:49 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f86DfjD27536 for <[e-mail]>; Thu, 6 Sep 2001 06:41:46 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <SM1TAMTG>; Thu, 6 Sep 2001 09:41:40 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Ryan Hurst'" <[e-mail]>, "'David A. Cooper'" <[e-mail]>, IETF-PKIX <[e-mail]>
Cc: "Hoyt Kesterson (E-mail)" <[e-mail]>
Subject: RE: Removing expired certificates from CRLs.....
Date: Thu, 6 Sep 2001 09:41:38 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C136D9.A750D460"
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_01C136D9.A750D460
Content-Type: text/plain

David I do remember some discussion of a new extension but don't recall the
reason why it wasn't pursued - do you remember? 
 
With the 509 meeting coming up in just a couple of weeks, if we reach
consensus that it would be useful to add either a new extension or a new
component to the IDP extension to indicate that a CRL includes revocation
notices for expired certs, we could probably add it to the 509 WD at that
meeting. 
 
I believe there is value in allowing expired certs to remain on CRLs, but
certainly it should be an optional feature as it is not needed in all
environments.
 
Cheers,
Sharon
-----Original Message-----
From: Ryan Hurst [mailto:[e-mail]]
Sent: Thursday, September 06, 2001 1:16 AM
To: 'David A. Cooper'; IETF-PKIX
Subject: RE: Removing expired certificates from CRLs.....


David -
 
            Although my confusion on this issue has been cleared up (note to
self; always verify your sources) now; this brings up a very interesting
point. I and others I have spoken with believe that the addition of such an
extension (one that states that the CRL contains ALL revocation entries both
current and expired) would be very valuable. 
 
Consider this problem, today I receive a digitally signed and time stamped
document (a contract possibly), this document was signed by a certificate
issued off of any number of commercial CA's that exist today. 10 years later
the document is in question and I need to establish that the certificate
associated with the signature on the document was valid at the time it was
signed; there are several significant possibilities here:
 
1.	CA in question has CRLNumber extension in all of their CRLs and they
are all available 

2.	CA in question does not have the CRLNumber in all CRLS or just a
subset 
 
Now in #1 the problem is relatively easy, I find all CRLs that were valid
during my window and of those I pick the one that has the highest CRLnumber.
An extension like this would be "use-full" in this case but not necessary.
 
In #2 the problem gets, well unsolvable; Since there are no ways to
determine if I have all of the CRLs that are within my window (remember
validity windows on CRLs can overlap so the ones within the overlapped
window that state the certificate is revoked could be "lost") I will never
now if the certificate was valid at the time in question. Now if the CRLs
that were generated contained all entries and were marked as such with an
extension I would have a mechanism to solve this problem; simply get the
most recent CRL.
 
Ryan
 
 
-----Original Message-----
From: David A. Cooper [mailto:[e-mail]] 
Sent: Wednesday, September 05, 2001 7:39 AM
To: IETF-PKIX
Subject: Re: Removing expired certificates from CRLs.....
 
At 03:53 PM 9/5/01 +0200, Nada Kapidzic Cicovic wrote:


Denis,

I was making comments on the text which Ryan extracted in his mail, assuming
that they were from the son-of-RFC2459.

In particular the last sentence in this paragraph:

The distributionPoint component contains the name of the distribution point
in one or more name forms. If this field is absent, the CRL shall contain
entries for all revoked certificates issued by the CRL issuer. After a
certificate appears on a CRL, it is deleted from a subsequent CRL after the
certificate's expiry.

However, after getting your comment I realized that this sentence and the
referred section 8.6.2.2 comes from the X.509 (the latest version that I
have on my disk is X_509_4thEditionDraftV6, and it contains the above text).


I have X_509_4thEditionDraftV8 on my computer and it appears that this has
been fixed. I now says "After a certificate appears on a CRL, it may be
deleted from a subsequent CRL after the certificate's expiry."  I didn't
bother to look at son-of-2459.

In any case, both X.509 and son-of-2459 should say that a certificate may be
deleted from a CRL after it has expired.  In general, though, I don't think
there is much benefit to leaving expired certificates on CRLs.  The problem
is that, at the moment, if an expired certificate is not listed on a CRL,
there is no way to determine whether it is not listed because it was never
revoked or if it was revoked but is not listed because it was removed after
expiration.

Some time ago, there was a suggestion to create a new, non-critical CRL
extension that would specify whether an expired certificate was covered by a
CRL (e.g., the extension could state: "This CRL includes all revoked
certificates that expire(d) after Jan. 1, 2001 (i.e., notAfter >=
010101000000Z)."). There didn't seem to be much support for this idea, so
the extension was never created.



The current text of the son-of-RFC2459 does not seem to contain it or any
other misleading sentences regarding this issue. 

Sorry for the confusion.

Nada
 

------_=_NextPart_001_01C136D9.A750D460
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">


<META content=3DWord.Document name=3DProgId>
<META content=3D"MSHTML 5.50.4522.1800" name=3DGENERATOR>
<META content=3D"Microsoft Word 10" name=3DOriginator><LINK=20
href=3D"cid:filelist.xml@01C13659.21A03020" =
rel=3DFile-List><o:SmartTagType=20
name=3D"time"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTag=
Type><o:SmartTagType=20
name=3D"date"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTag=
Type><!--[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:Compatibility>
   <w:UseFELayout/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: SimSun;
}
@font-face {
	font-family: Tahoma;
}
@font-face {
	font-family: \@SimSun;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; =
mso-header-margin: .5in; mso-footer-margin: .5in; mso-paper-source: 0; =
}
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: SimSun
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: SimSun
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: SimSun
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline; text-underline: single
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline; text-underline: single
}
SPAN.EmailStyle17 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply; =
mso-style-noshow: yes; mso-ansi-font-size: 10.0pt; mso-bidi-font-size: =
10.0pt; mso-ascii-font-family: Arial; mso-hansi-font-family: Arial; =
mso-bidi-font-family: Arial
}
SPAN.SpellE {
	mso-style-name: ""; mso-spl-e: yes
}
SPAN.GramE {
	mso-style-name: ""; mso-gram-e: yes
}
DIV.Section1 {
	page: Section1
}
OL {
	MARGIN-BOTTOM: 0in
}
UL {
	MARGIN-BOTTOM: 0in
}
</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:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]--></HEAD>
<BODY lang=3DEN-US style=3D"tab-interval: .5in" vLink=3Dpurple =
link=3Dblue>
<DIV><SPAN class=3D418303813-06092001><FONT face=3DArial =
color=3D#0000ff size=3D2>David=20
I do remember some discussion of a new extension but don't recall the =
reason why=20
it wasn't pursued - do you remember? </FONT></SPAN></DIV>
<DIV><SPAN class=3D418303813-06092001><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D418303813-06092001><FONT face=3DArial =
color=3D#0000ff size=3D2>With=20
the 509 meeting coming up in just a couple of weeks, if we reach =
consensus that=20
it would be useful to add either a new extension or a new component to =
the IDP=20
extension to indicate that a CRL includes revocation notices for =
expired certs,=20
we could probably add it to the 509 WD at that meeting. =
</FONT></SPAN></DIV>
<DIV><SPAN class=3D418303813-06092001><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D418303813-06092001><FONT face=3DArial =
color=3D#0000ff size=3D2>I=20
believe there is value in allowing expired certs to remain on CRLs, but =

certainly it should be an optional feature as it is not needed in all=20
environments.</FONT></SPAN></DIV>
<DIV><SPAN class=3D418303813-06092001><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D418303813-06092001><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Cheers,</FONT></SPAN></DIV>
<DIV><SPAN class=3D418303813-06092001><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Sharon</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Ryan Hurst=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, September 06, =
2001 1:16=20
  AM<BR><B>To:</B> 'David A. Cooper'; IETF-PKIX<BR><B>Subject:</B> RE: =
Removing=20
  expired certificates from CRLs.....<BR><BR></FONT></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">David=20
  -<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
  style=3D"mso-tab-count: =
1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>Although my confusion on this issue has been cleared up (note =
to self;=20
  always verify your sources) now; this brings up a very interesting =
point. I=20
  and others I have spoken with believe that the addition of such an =
extension=20
  (one that states that the CRL contains ALL revocation entries both =
current and=20
  expired) would be very valuable. <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Consider =
this=20
  problem, today I receive a digitally signed and time stamped document =
(a=20
  contract possibly), this document was signed by a certificate issued =
off of=20
  any number of commercial CA's that exist today. 10 years later the =
document is=20
  in question and I need to establish that the certificate associated =
with the=20
  signature on the document was valid at the time it was signed; there =
are=20
  several significant possibilities here:<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <OL style=3D"mso-margin-top-alt: 0in" type=3D1>
    <LI class=3DMsoNormal=20
    style=3D"COLOR: navy; mso-list: l0 level1 lfo1; tab-stops: list =
.5in"><FONT=20
    face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">CA in question has =
<SPAN=20
    class=3DSpellE>CRLNumber</SPAN> extension in all of their <SPAN=20
    class=3DSpellE>CRLs</SPAN> and they are all =
available<o:p></o:p></SPAN></FONT>=20

    <LI class=3DMsoNormal=20
    style=3D"COLOR: navy; mso-list: l0 level1 lfo1; tab-stops: list =
.5in"><FONT=20
    face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">CA in question does =
not have the=20
    <SPAN class=3DSpellE>CRLNumber</SPAN> in all CRLS or just a=20
    subset<o:p></o:p></SPAN></FONT> </LI></OL>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Now in #1 =
the problem=20
  is relatively easy, I find all <SPAN class=3DSpellE>CRLs</SPAN> that =
were valid=20
  during my window and of those I pick the one that has the highest =
<SPAN=20
  class=3DSpellE>CRLnumber</SPAN>. An extension like this would be =
"use-full" in=20
  this case but not necessary.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">In #2 the =
problem=20
  gets, well unsolvable; Since there are no ways to determine if I have =
all of=20
  the <SPAN class=3DSpellE>CRLs</SPAN> that are within my window =
(remember=20
  validity windows on <SPAN class=3DSpellE>CRLs</SPAN> can overlap so =
the ones=20
  within the overlapped window that state the certificate is revoked =
could be=20
  "lost") I will never now if the certificate was valid at the time in =
question.=20
  Now if the <SPAN class=3DSpellE>CRLs</SPAN> that were generated =
contained all=20
  entries and were marked as such with an extension I would have a =
mechanism to=20
  solve this problem; simply get the most recent=20
  CRL.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Ryan<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><FONT face=3DTahoma =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">-----Original=20
  Message-----<BR><B><SPAN style=3D"FONT-WEIGHT: bold">From:</SPAN></B> =
David A.=20
  Cooper [mailto:[e-mail]] <BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> </SPAN></FONT><st1:date =
Year=3D"2001"=20
  Day=3D"5" Month=3D"9"><FONT face=3DTahoma size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">Wednesday, September =
05,=20
  2001</SPAN></FONT></st1:date><FONT face=3DTahoma size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"> =
</SPAN></FONT><st1:time=20
  Minute=3D"39" Hour=3D"7"><FONT face=3DTahoma size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">7:39=20
  AM</SPAN></FONT></st1:time><FONT face=3DTahoma size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"><BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">To:</SPAN></B> IETF-PKIX<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> Re: Removing expired=20
  certificates from CRLs.....</SPAN></FONT></P>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><FONT face=3D"Times =
New Roman"=20
  size=3D3><SPAN style=3D"FONT-SIZE: =
12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><FONT face=3D"Times =
New Roman"=20
  size=3D3><SPAN style=3D"FONT-SIZE: 12pt">At </SPAN></FONT><st1:time =
Minute=3D"53"=20
  Hour=3D"15">03:53 PM</st1:time> <st1:date Year=3D"2001" Day=3D"5"=20
  Month=3D"9">9/5/01</st1:date> +0200, Nada Kapidzic Cicovic wrote:<BR=20
  style=3D"mso-special-character: line-break"><![if =
!supportLineBreakNewLine]><BR=20
  style=3D"mso-special-character: line-break"><![endif]><o:p></o:p></P>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><FONT face=3D"Times =
New Roman"=20
  size=3D3><SPAN style=3D"FONT-SIZE: 12pt">Denis,<BR><BR>I was making =
comments on=20
  the text which Ryan extracted in his mail, assuming that they were =
from the=20
  son-of-RFC2459.<BR><BR>In particular the last sentence in this=20
  paragraph:<BR><BR>The </SPAN></FONT><B><FONT size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt">distributionPoint=20
  </SPAN></FONT></B>component contains the name of the distribution =
point in one=20
  or more name forms. If this field is absent, the CRL shall contain =
entries for=20
  all revoked certificates issued by the CRL issuer. <B><I><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-STYLE: italic">After a certificate =
appears on a=20
  CRL, it is deleted from a subsequent CRL after the certificate's=20
  expiry.<BR><BR></SPAN></I></B>However, after getting your comment I =
realized=20
  that this sentence and the referred section 8.6.2.2 comes from the =
X.509 (the=20
  latest version that I have on my disk is X_509_4thEditionDraftV6, and =
it=20
  contains the above text). <o:p></o:p></P>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><FONT face=3D"Times =
New Roman"=20
  size=3D3><SPAN style=3D"FONT-SIZE: 12pt"><BR>I have =
X_509_4thEditionDraftV8 on my=20
  computer and it appears that this has been fixed. I now says "After a =

  certificate appears on a CRL, it <B><SPAN style=3D"FONT-WEIGHT: =
bold">may=20
  be</SPAN></B> deleted from a subsequent CRL after the certificate's=20
  expiry."&nbsp; I didn't bother to look at son-of-2459.<BR><BR>In any =
case,=20
  both X.509 and son-of-2459 should say that a certificate may be =
deleted from a=20
  CRL after it has expired.&nbsp; In general, though, I don't think =
there is=20
  much benefit to leaving expired certificates on CRLs.&nbsp; The =
problem is=20
  that, at the moment, if an expired certificate is not listed on a =
CRL, there=20
  is no way to determine whether it is not listed because it was never =
revoked=20
  or if it was revoked but is not listed because it was removed after=20
  expiration.<BR><BR>Some time ago, there was a suggestion to create a =
new,=20
  non-critical CRL extension that would specify whether an expired =
certificate=20
  was covered by a CRL (e.g., the extension could state: "This CRL =
includes all=20
  revoked certificates that expire(d) after </SPAN></FONT><st1:date =
Year=3D"2001"=20
  Day=3D"1" Month=3D"1">Jan. 1, 2001</st1:date> (i.e., notAfter &gt;=3D =

  010101000000Z)."). There didn't seem to be much support for this =
idea, so the=20
  extension was never created.<BR><BR style=3D"mso-special-character: =
line-break"><![if !supportLineBreakNewLine]><BR=20
  style=3D"mso-special-character: line-break"><![endif]><o:p></o:p></P>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><FONT face=3D"Times =
New Roman"=20
  size=3D3><SPAN style=3D"FONT-SIZE: 12pt">The current text of the =
son-of-RFC2459=20
  does not seem to contain it or any other misleading sentences =
regarding this=20
  issue. <BR><BR>Sorry for the=20
  confusion.<BR><BR>Nada<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><FONT face=3D"Times =
New Roman"=20
  size=3D3><SPAN=20
style=3D"FONT-SIZE: =
12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BODY></HTM=
L>

------_=_NextPart_001_01C136D9.A750D460--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f86DOsp26434 for ietf-pkix-bks; Thu, 6 Sep 2001 06:24:54 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f86DOoD26428 for <[e-mail]>; Thu, 6 Sep 2001 06:24:50 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <SM1TAML2>; Thu, 6 Sep 2001 09:24:44 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'IETF-PKIX'" <[e-mail]>
Subject: RE: Removing expired certificates from CRLs.....
Date: Thu, 6 Sep 2001 09:24:43 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C136D7.4A4096E0"
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_01C136D7.4A4096E0
Content-Type: text/plain;
	charset="iso-8859-1"

There was a problem with my initial attempt to send this to the list, so I
am resending it.
 
Sharon
-----Original Message-----
From: Sharon Boeyen 
Sent: Wednesday, September 05, 2001 1:36 PM
To: 'Flynn, Michael'; 'Ryan Hurst'; IETF-PKIX
Subject: RE: Removing expired certificates from CRLs.....


I suspect some of the PKIX text was never updated to reflect the successful
ballot on the X.509 defect report that fixed this in the base X.509 text.
The approved TC for the defect (DR 204) corrected this problem by making the
following changes to X.509 (97).
 
 
Clause 12.6.3.1
 
In the first sentence following the ASN.1, delete "unexpired"
 
Add the following as a new second sentence in the first paragraph following
the ASN.1
 
"After a certificate appears on a CRL, it may be deleted from a subsequent
CRL after the certificate's expiry."
 
 
Cheers,
Sharon
 
-----Original Message-----
From: Flynn, Michael [mailto:[e-mail]]
Sent: Wednesday, September 05, 2001 1:03 PM
To: 'Ryan Hurst'; IETF-PKIX
Subject: RE: Removing expired certificates from CRLs.....


Ryan,
 
Ryan wrote::
Now logically it makes sense to remove certificates that are expired from
CRLs to control size, yes this has a negative point specifically it prevents
CRLs from being used as a non-repudiation source; but this is mute due to
many other issues.
 
At least regarding removing expired certs from CRLs, I would think that
non-repudiation can be satisfied by keeping the old CRLs in back up storage
for some length of time.  That time being how far back in time a contract
dispute might go; ten years, twenty?   So long as you could get them off
tape for the lawyers to look at the legal process would be satisfied, they
don't need to be online forever.  
 
Michael
 
-----Original Message-----
From: Ryan Hurst [mailto:[e-mail]]
Sent: Tuesday, September 04, 2001 8:50 PM
To: IETF-PKIX
Subject: Removing expired certificates from CRLs.....


I was speaking with Peter Williams today about the removal of expired
certificates from CRLs; I have always been under the belief that this
behavior was optional, I vaguely remembered reading text in 2459 along those
lines; additionally I know of several commercial CAs that do not remove the
expired certificates from their CRLs. Peter on the other hand was under the
impression that it was a mandate to remove CRLs; he too remembered reading
text in 2459 to support is position.
 
So we each pulled out the RFC and found that we were both right!
Specifically both sections 3.3 and 8.6.2.2 have text on this subject:
 
3.3  Revocation
When a certificate is issued, it is expected to be in use for its entire
validity period.  However, various circumstances may cause a certificate to
become invalid prior to the expiration of the validity period.
 
....
 
An entry is added to the CRL as part of the next update following
notification of revocation. An entry may be removed from the CRL after
appearing on one regularly scheduled CRL issued beyond the revoked
certificate's validity period.
 
 
 
8.6.2.2 Issuing distribution point extension
This CRL extension field identifies the CRL distribution point for this
particular CRL, and indicates if the CRL is limited to revocations for
end-entity certificates only, for authority certificates only, or for a
limited set of reasons only. The CRL is signed by the CRL issuer's key- CRL
distribution points do not have their own key pairs. However, for a CRL
distributed via the Directory, the CRL is stored in the entry of the CRL
distribution point, which may not be the directory entry of the CRL issuer.
If this field is absent, the CRL shall contain entries for all revoked
unexpired certificates issued by the CRL issuer.
 
....
 
The distributionPoint component contains the name of the distribution point
in one or more name forms. If this field is absent, the CRL shall contain
entries for all revoked certificates issued by the CRL issuer. After a
certificate appears on a CRL, it is deleted from a subsequent CRL after the
certificate's expiry.
 
 
Although section 8.6.2.2 is specifically in regards to CRLdps, any
difference between full CRLs and CRLdps in this case I feel would be an
arbitrary one. 
 
Now logically it makes sense to remove certificates that are expired from
CRLs to control size, yes this has a negative point specifically it prevents
CRLs from being used as a non-repudiation source; but this is mute due to
many other issues.
 
That being the case I think; and I believe Peter would agree the correct
thing to do is to remove these expired/revoked entries from the CRL. 
 
The question now is what is the PKIX stance on this matter?
 
Ryan M. Hurst
ValiCert, Inc.
 
"It may roundly be asserted that human ingenuity cannot concoct a cipher
which human ingenuity cannot resolve."
-Edgar Allan Poe
 

------_=_NextPart_001_01C136D7.4A4096E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3DWord.Document name=3DProgId>
<META content=3D"MSHTML 5.50.4522.1800" name=3DGENERATOR>
<META content=3D"Microsoft Word 10" name=3DOriginator><LINK=20
href=3D"cid:[e-mail]4BB00" =
rel=3DFile-List><o:SmartTagType=20
name=3D"PersonName"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTag=
Type><!--[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:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
   <w:UseFELayout/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: SimSun;
}
@font-face {
	font-family: \@SimSun;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; =
mso-header-margin: .5in; mso-footer-margin: .5in; mso-paper-source: 0; =
}
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: SimSun
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: SimSun
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: SimSun
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline; text-underline: single
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline; text-underline: single
}
SPAN.EmailStyle17 {
	COLOR: windowtext; FONT-FAMILY: Arial; mso-style-type: =
personal-compose; mso-style-noshow: yes; mso-ansi-font-size: 10.0pt; =
mso-bidi-font-size: 10.0pt; mso-ascii-font-family: Arial; =
mso-hansi-font-family: Arial; mso-bidi-font-family: Arial
}
SPAN.SpellE {
	mso-style-name: ""; mso-spl-e: yes
}
SPAN.GramE {
	mso-style-name: ""; mso-gram-e: yes
}
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:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]--></HEAD>
<BODY lang=3DEN-US style=3D"tab-interval: .5in" vLink=3Dpurple =
link=3Dblue>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D347082413-06092001>There=20
was a problem with my initial attempt to send this to the list, so I am =

resending it.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D347082413-06092001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D347082413-06092001>Sharon</SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Sharon Boeyen=20
  <BR><B>Sent:</B> Wednesday, September 05, 2001 1:36 PM<BR><B>To:</B> =
'Flynn,=20
  Michael'; 'Ryan Hurst'; IETF-PKIX<BR><B>Subject:</B> RE: Removing =
expired=20
  certificates from CRLs.....<BR><BR></FONT></DIV>
  <DIV><SPAN class=3D054173117-05092001><FONT face=3DArial =
color=3D#0000ff size=3D2>I=20
  suspect some of the PKIX text was never updated to reflect the =
successful=20
  ballot on the&nbsp;X.509 defect report that fixed this in the base =
X.509 text.=20
  The approved TC for the defect (DR 204) corrected this problem by =
making the=20
  following changes to X.509 (97).</FONT></SPAN></DIV>
  <DIV><SPAN class=3D054173117-05092001></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D054173117-05092001>&nbsp;</DIV>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.55pt"><B=20
  style=3D"mso-bidi-font-weight: normal">Clause =
12.6.3.1<o:p></o:p></B></P>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: =
0.5in">&nbsp;<o:p></o:p></P>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><I=20
  style=3D"mso-bidi-font-style: normal">In the first sentence following =
the ASN.1,=20
  delete &#8220;unexpired&#8221;<o:p></o:p></I></P>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><I=20
  style=3D"mso-bidi-font-style: normal">&nbsp;<o:p></o:p></I></P>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><I=20
  style=3D"mso-bidi-font-style: normal">Add the following as a new =
second sentence=20
  in the first paragraph following the ASN.1<o:p></o:p></I></P>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: =
0.5in">&nbsp;<o:p></o:p></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New =
Roman'">&#8220;After a certificate=20
  appears on a CRL, it may be deleted from a subsequent CRL after the=20
  certificate&#8217;s expiry.&#8221;<o:p></o:p></SPAN></P>
  <DIV>&nbsp;</DIV>
  <DIV><FONT size=3D2></FONT>&nbsp;</DIV>
  <DIV><SPAN class=3D054173117-05092001><FONT=20
  color=3D#0000ff>Cheers,</FONT></SPAN></DIV>
  <DIV><SPAN class=3D054173117-05092001><FONT=20
  color=3D#0000ff>Sharon</FONT></SPAN></DIV>
  <DIV><FONT color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff =
2px solid; MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Flynn, Michael=20
    [mailto:[e-mail]]<BR><B>Sent:</B> Wednesday, September =
05, 2001=20
    1:03 PM<BR><B>To:</B> 'Ryan Hurst'; IETF-PKIX<BR><B>Subject:</B> =
RE:=20
    Removing expired certificates from CRLs.....<BR><BR></FONT></DIV>
    <DIV><SPAN class=3D537505516-05092001><FONT face=3D"Courier New"=20
    size=3D2>Ryan,</FONT></SPAN></DIV>
    <DIV><SPAN class=3D537505516-05092001><FONT face=3D"Courier New"=20
    size=3D2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=3D537505516-05092001><FONT face=3D"Courier New" =
size=3D2>Ryan=20
    wrote::</DIV>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Now logically it =
makes sense to=20
    remove certificates that are expired from <SPAN =
class=3DSpellE>CRLs</SPAN> to=20
    control size, yes this has a negative point specifically it =
prevents <SPAN=20
    class=3DSpellE>CRLs</SPAN> from being used as a non-repudiation =
source; but=20
    this is mute due to many other issues.</SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>
    <P class=3DMsoNormal><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p><SPAN=20
    class=3D537505516-05092001>At least regarding removing expired =
certs from=20
    CRLs, I would think that non-repudiation can be satisfied by =
keeping the old=20
    CRLs in back up storage for some length of time.&nbsp; That time =
being how=20
    far back in time a contract dispute might go; ten years, twenty? =
&nbsp; So=20
    long as you could get them off&nbsp; tape for the lawyers to look =
at the=20
    legal process would be satisfied, they don't need to be online=20
    forever.&nbsp; </SPAN></o:p></SPAN></P>
    <P class=3DMsoNormal><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p><SPAN=20
    class=3D537505516-05092001></SPAN></o:p></SPAN><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p><SPAN=20
    class=3D537505516-05092001></SPAN></o:p></SPAN>&nbsp;</P>
    <P class=3DMsoNormal><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p><SPAN=20
    class=3D537505516-05092001>Michael</SPAN></o:p></SPAN></P>
    <P class=3DMsoNormal><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p><SPAN=20
    =
class=3D537505516-05092001></SPAN></o:p></SPAN>&nbsp;</P></FONT></SPAN>
    <BLOCKQUOTE dir=3Dltr=20
    style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 =
2px solid; MARGIN-RIGHT: 0px">
      <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
      size=3D2>-----Original Message-----<BR><B>From:</B> Ryan Hurst=20
      [mailto:[e-mail]]<BR><B>Sent:</B> Tuesday, September =
04, 2001=20
      8:50 PM<BR><B>To:</B> IETF-PKIX<BR><B>Subject:</B> Removing =
expired=20
      certificates from CRLs.....<BR><BR></FONT></DIV>
      <DIV class=3DSection1>
      <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">I was speaking with =

      </SPAN></FONT><st1:PersonName><FONT face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Peter=20
      Williams</SPAN></FONT></st1:PersonName><FONT face=3DArial =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"> today about the =
removal of=20
      expired certificates from <SPAN class=3DSpellE>CRLs</SPAN>; I =
have always=20
      been under the belief that this behavior was optional, I vaguely=20
      remembered reading text in 2459 along those lines; additionally I =
know of=20
      several commercial <SPAN class=3DSpellE>CAs</SPAN> that do not =
remove the=20
      expired certificates from their <SPAN class=3DSpellE>CRLs</SPAN>. =
Peter on=20
      the other hand was under the impression that it was a mandate to =
remove=20
      <SPAN class=3DSpellE>CRLs</SPAN>; he too remembered reading text =
in 2459 to=20
      support is position.<o:p></o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">So we each pulled =
out the RFC=20
      and found that we were both right! Specifically both sections 3.3 =
and=20
      8.6.2.2 have text on this subject:<o:p></o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
      <P class=3DMsoNormal=20
      style=3D"tab-stops: 45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt =
320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt =
732.8pt; mso-layout-grid-align: none"><SPAN=20
      class=3DGramE><B style=3D"mso-bidi-font-weight: normal"><FONT =
face=3DArial=20
      size=3D2><SPAN=20
      style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Arial; =
mso-bidi-font-weight: normal">3.3<SPAN=20
      style=3D"mso-spacerun: yes">&nbsp;=20
      </SPAN>Revocation</SPAN></FONT></B></SPAN><B=20
      style=3D"mso-bidi-font-weight: normal"><FONT face=3DArial =
size=3D2><SPAN=20
      style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Arial; =
mso-bidi-font-weight: normal"><o:p></o:p></SPAN></FONT></B></P>
      <P class=3DMsoNormal=20
      style=3D"tab-stops: 45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt =
320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt =
732.8pt; mso-layout-grid-align: none"><FONT=20
      face=3DArial size=3D2><SPAN style=3D"FONT-SIZE: 10pt; =
FONT-FAMILY: Arial">When a=20
      certificate is issued, it is expected to be in use for its entire =
validity=20
      period.<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>However, =
various=20
      circumstances may cause a certificate to become invalid prior to =
the=20
      expiration of the validity period.<o:p></o:p></SPAN></FONT></P>
      <P class=3DMsoNormal=20
      style=3D"tab-stops: 45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt =
320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt =
732.8pt; mso-layout-grid-align: none"><FONT=20
      face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
      <P class=3DMsoNormal style=3D"mso-layout-grid-align: none"><FONT =
face=3DArial=20
      size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">....<o:p></o:p></SPAN></FONT></P>
      <P class=3DMsoNormal style=3D"mso-layout-grid-align: none"><FONT =
face=3DArial=20
      size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
      <P class=3DMsoNormal=20
      style=3D"tab-stops: 45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt =
320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt =
732.8pt; mso-layout-grid-align: none"><FONT=20
      face=3DArial size=3D2><SPAN style=3D"FONT-SIZE: 10pt; =
FONT-FAMILY: Arial">An=20
      entry is added to the CRL as part of the next update following=20
      notification of revocation. <B><I><SPAN=20
      style=3D"FONT-WEIGHT: bold; FONT-STYLE: italic">An entry may be =
removed from=20
      the CRL after appearing on one regularly scheduled CRL issued =
beyond the=20
      revoked certificate's validity=20
      period.</SPAN></I></B><o:p></o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
      <P class=3DMsoNormal style=3D"mso-layout-grid-align: =
none"><B><FONT face=3DArial=20
      size=3D2><SPAN=20
      style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">8.6.2.2=20
      Issuing distribution point =
extension<o:p></o:p></SPAN></FONT></B></P>
      <P class=3DMsoNormal style=3D"mso-layout-grid-align: none"><FONT =
face=3DArial=20
      size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">This =
CRL=20
      extension field identifies the CRL distribution point for this =
particular=20
      CRL, and indicates if the CRL is limited to revocations for =
end-entity=20
      certificates only, for authority certificates only, or for a =
limited set=20
      of reasons only. The CRL is signed by the CRL issuer's key- CRL=20
      distribution points do not have their own key pairs. However, for =
a CRL=20
      distributed via the Directory, the CRL is stored in the entry of =
the CRL=20
      distribution point, which may not be the directory entry of the =
CRL=20
      issuer.<I><SPAN style=3D"FONT-STYLE: italic"> <B><SPAN=20
      style=3D"FONT-WEIGHT: bold">If this field is absent, the CRL =
shall contain=20
      entries for all revoked <SPAN class=3DSpellE>unexpired</SPAN> =
certificates=20
      issued by the CRL=20
      issuer.</SPAN></B><o:p></o:p></SPAN></I></SPAN></FONT></P>
      <P class=3DMsoNormal style=3D"mso-layout-grid-align: =
none"><I><FONT face=3DArial=20
      size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-STYLE: italic; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></I></P>
      <P class=3DMsoNormal style=3D"mso-layout-grid-align: none"><FONT =
face=3DArial=20
      size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">....<o:p></o:p></SPAN></FONT></P>
      <P class=3DMsoNormal style=3D"mso-layout-grid-align: none"><FONT =
face=3DArial=20
      color=3Dblue size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
      <P class=3DMsoNormal style=3D"mso-layout-grid-align: none"><FONT =
face=3DArial=20
      size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The=20
      </SPAN></FONT><SPAN class=3DSpellE><B><FONT face=3DArial =
size=3D1><SPAN=20
      style=3D"FONT-WEIGHT: bold; FONT-SIZE: 9pt; FONT-FAMILY: =
Arial">distributionPoint</SPAN></FONT></B></SPAN><B><FONT=20
      face=3DArial size=3D1><SPAN=20
      style=3D"FONT-WEIGHT: bold; FONT-SIZE: 9pt; FONT-FAMILY: Arial">=20
      </SPAN></FONT></B><FONT face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">component contains =
the name of=20
      the distribution point in one or more name forms. If this field =
is absent,=20
      the CRL shall contain entries for all revoked certificates issued =
by the=20
      CRL issuer. <B><I><SPAN=20
      style=3D"FONT-WEIGHT: bold; FONT-STYLE: italic">After a =
certificate appears=20
      on a CRL, it is deleted from a subsequent CRL after the =
certificate's=20
      expiry.<o:p></o:p></SPAN></I></B></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Although section =
8.6.2.2 is=20
      specifically in regards to <SPAN class=3DSpellE>CRLdps</SPAN>, =
any=20
      difference between full <SPAN class=3DSpellE>CRLs</SPAN> and =
<SPAN=20
      class=3DSpellE>CRLdps</SPAN> in this case I feel would be an =
arbitrary one.=20
      <o:p></o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Now logically it =
makes sense=20
      to remove certificates that are expired from <SPAN=20
      class=3DSpellE>CRLs</SPAN> to control size, yes this has a =
negative point=20
      specifically it prevents <SPAN class=3DSpellE>CRLs</SPAN> from =
being used as=20
      a non-repudiation source; but this is mute due to many other=20
      issues.<o:p></o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">That being the case =
I think;=20
      and I believe Peter would agree the correct thing to do is to =
remove these=20
      expired/revoked entries from the CRL. =
<o:p></o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The question now is =
what is=20
      the PKIX stance on this matter?<o:p></o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Ryan M.=20
      Hurst<o:p></o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">ValiCert,=20
      Inc.<o:p></o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
      <BLOCKQUOTE style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">
        <P class=3DMsoNormal><I><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt; FONT-STYLE: italic; mso-no-proof: =
yes">"It may=20
        roundly be asserted that human ingenuity cannot concoct a =
cipher which=20
        human ingenuity cannot resolve."</SPAN></FONT></I><SPAN=20
        style=3D"mso-no-proof: yes"><o:p></o:p></SPAN></P></BLOCKQUOTE>
      <BLOCKQUOTE style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">
        <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt; mso-no-proof: yes">-Edgar Allan=20
        Poe</SPAN><o:p></o:p></FONT></P></BLOCKQUOTE>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
      style=3D"FONT-SIZE: =
12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BLOCKQUOTE=
></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C136D7.4A4096E0--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f86B2sV18484 for ietf-pkix-bks; Thu, 6 Sep 2001 04:02:54 -0700 (PDT)
Received: from claudio.bib.co.uk (gateway.bib.co.uk [195.171.24.2]) by above.proper.com (8.11.6/8.11.3) with SMTP id f86B2rD18476 for <[e-mail]>; Thu, 6 Sep 2001 04:02:53 -0700 (PDT)
Received: from 127.0.0.1 by claudio.bib.co.uk (InterScan E-Mail VirusWall NT); Thu, 06 Sep 2001 12:02:49 +0100
Received: by claudio with Internet Mail Service (5.5.2653.19) id <SKNCJTL6>; Thu, 6 Sep 2001 12:02:49 +0100
Message-ID: <36086CC80304D3119B040008C75DF596095F2105@claudio>
From: "Bland, Graham" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Charter Revisions, Logotype Business models
Date: Thu, 6 Sep 2001 12:02:48 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
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.

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"

To clear up some of the Logotype discussions in my mind is it possible to
define some business models which they are trying to support, without a
clear understanding of these models the detailed discussions seem moot.

As I understand it the primary motivation for Logotype is to allow the
display of a recognisable visual cue(s) to aid the end user of the cert to
make a trust decision.

Here are some examples for discussion, please feel free to tear them to bits
and add others:

End Entity Logo
End entity requests a certificate with a logotype included in the cert
request.  This only applies to the EE cert and for example is a company
logo.  The use of the logo is designed to convey that the certificate holder
is a representative of the organisation, as such the validation of the
requested logo by the CA is similar to the process for the DN.

CA Logo
End Entity requests a certificate with or without a logotype included in the
cert request as above.  In this case the CA wishes to place a logo in the
issued cert to indicate something; for example this is a Visa Cert.  I do
not see the logo reference being requested by the end entity in this case,
more of it being inserted by the CA.  this is the primary trust mechanism
(this cert was issued by Visa) not this cert belongs to Visa.  Other
examples are numerous, such as this is a Verisign SSL server cert.

Logo Hierarchy
The CA logo example above could also be identified by Logos in the issuing
cert, this would require the display of a hierarchy of logos which would be
an output of DPD/DPV ?.  These may be complete or incomplete if for example
not all certs in the chain contain logos.
Also the Logo would get more complex, do we need the logo to indicate the
difference between Verisign Class1, Class 2 etc. certs or would it just be
the same Verisign Logo in all of them. 

Some other questions on the requirements:
Are there circumstances where a cert could contain multiple EE Logos such as
a well known division of a conglomerate could conceivably contain more than
one, for example Volkswagen owns Rolls Royce.

If a hierarchy of Logos are displayed how is this conveyed to the end user
or is just the logo in the EE cert displayed?



> Graham Bland
> Security Designer
> Open....
> 34-35 Farringdon Street London EC4A 4HJ
> Tel: [phone]   Fax: [phone]
> E Mail [e-mail]
> 
> 

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="Open_Interactive_Disclaimer.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="Open_Interactive_Disclaimer.txt"

This message is confidential and is intended for the addressee only; unless clearly 
stated that this disclaimer should not apply, this e-mail is not intended to create legally
 binding commitments on behalf of any company in the British Interactive Broadcasting 
Holding Limited group, nor do its contents reflect the corporate views or policies of any 
such company. Any unauthorised disclosure, use or dissemination, either whole or 
partial, is prohibited. If you are not the intended recipient of the message, please notify 
the sender immediately.

--------------InterScan_NT_MIME_Boundary--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8693Bj11702 for ietf-pkix-bks; Thu, 6 Sep 2001 02:03:11 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8693AD11696 for <[e-mail]>; Thu, 6 Sep 2001 02:03: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 LAA21194 for <[e-mail]>; Thu, 6 Sep 2001 11:05:09 +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 LAA16794 for <[e-mail]>; Thu, 6 Sep 2001 11:02:34 +0200
Message-ID: <[e-mail]>
Date: Thu, 06 Sep 2001 11:02:37 +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
CC: "PKIX (E-mail)" <[e-mail]>
Subject: Re: Logos: objection to charter revisions
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>

After seeing all that discussion about logos, I realized that we had 
a solution (i.e. the draft writen by Stefan) for an unknown problem.

1) Are logos to be used in server certificates ? 
   If so, what would be their intended meaning ?

2) Are logos to be used in human-user certificates ? 
   If so, what would be their intended meaning ?

3) Are logos to be used in CA certificates ? 
   If so, what would be their intended meaning ?

4) Are logos to be used in self-signed certificates ? 
   If so, what would be their intented meaning ?

I do not think that the meaning and the use of the logo information will
necessarilly be the same for all of the above cases.

If that topic is going to stay on the charter, before we define a solution
we should first define the requirements. So an INFORMATIONAL RFC on the
requirements should be the first step. This Informational RFC should at
least answer to the questions raised above.

Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f868JMQ06838 for ietf-pkix-bks; Thu, 6 Sep 2001 01:19:22 -0700 (PDT)
Received: from webo.vtcif.telstra.com.au (webo.vtcif.telstra.com.au [202.12.144.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f868JKD06833 for <[e-mail]>; Thu, 6 Sep 2001 01:19:20 -0700 (PDT)
Received: (from uucp@localhost) by webo.vtcif.telstra.com.au (8.8.2/8.6.9) id SAA16874 for <[e-mail]>; Thu, 6 Sep 2001 18:19:14 +1000 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by webo.vtcif.telstra.com.au, id smtpdLyHyD_; Thu Sep  6 18:19:05 2001
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id SAA15370 for <[e-mail]>; Thu, 6 Sep 2001 18:19:04 +1000 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpdn9bCm_; Thu Sep  6 18:19:02 2001
Received: from ntmsg0028.corpmail.telstra.com.au (ntmsg0028.corpmail.telstra.com.au [192.168.174.24]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id SAA25770 for <[e-mail]>; Thu, 6 Sep 2001 18:19:02 +1000 (EST)
Received: by ntmsg0028.corpmail.telstra.com.au with Internet Mail Service (5.5.2653.19) id <SHBL2A13>; Thu, 6 Sep 2001 19:15:03 +1100
Message-ID: <[e-mail]>
From: "Manger, James H" <[e-mail]>
To: "PKIX (E-mail)" <[e-mail]>
Subject: RE: Logos: objection to charter revisions
Date: Thu, 6 Sep 2001 19:14:58 +1100 
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>

Steve Hanna,

You says "nobody has been able to come up with any way to fix [the current
logo proposal]" and conclude "that it can't be fixed".  .. but you provide
fixes earlier in the same e-mail!

Your statement that logos should be "ignored unless all certificates in the
path indicate that they should be supported" is just the sort of "logo
constraint" that enables safe use of logos.

One good reason for looking at logos is that it focuses attention on the
limitations of the current name constraints mechanism.  Name constraints
should be able to deal with new name forms and with non-hierarchical name
forms (logos are both), but the current extension cannot.  Name constraints
should, for instance, be able to exclude names of specified types or only
permit names of specified types.  [Another problem with the current name
constraints is that the "constraints" have to use the same syntax as the
"name", which is not always appropriate.]


> ----------
> From: 	Steve Hanna [mailto:[e-mail]] 
> Sent:	Thursday, 6 September 2001 7:36
> 
	..I, for one, would be much more comfortable if logotypes were
ignored unless all certificates in the path indicate that they should be
supported..

	..provide similar text warning that logotypes in certificates should
not be scaled or mapped to different colors before display. If this
requirement cannot be met, the certificate should be treated as if it did
not contain the logotype.

	..the proposal is demonstrably flawed (although this is subject to
some debate). Nobody has been able to come up with any way to fix it. My
conclusion is that it can't be fixed.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f865MEM14986 for ietf-pkix-bks; Wed, 5 Sep 2001 22:22:14 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f865MDD14981 for <[e-mail]>; Wed, 5 Sep 2001 22:22:13 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 5 Sep 2001 22:22:53 -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]>; Wed, 05 Sep 2001 22:22:53 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <QP4KWBSL>; Wed, 05 Sep 2001 22:15:48 -0700
Content-return: allowed
Date: Wed, 05 Sep 2001 22:15:47 -0700
From: Ryan Hurst <[e-mail]>
Subject: RE: Removing expired certificates from CRLs.....
To: "'David A. Cooper'" <[e-mail]>, IETF-PKIX <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: multipart/alternative; boundary="Boundary_(ID_JkgCqYPxPr3/zzS1dial1Q)"
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.

--Boundary_(ID_JkgCqYPxPr3/zzS1dial1Q)
Content-type: text/plain

David -
 
            Although my confusion on this issue has been cleared up (note to
self; always verify your sources) now; this brings up a very interesting
point. I and others I have spoken with believe that the addition of such an
extension (one that states that the CRL contains ALL revocation entries both
current and expired) would be very valuable. 
 
Consider this problem, today I receive a digitally signed and time stamped
document (a contract possibly), this document was signed by a certificate
issued off of any number of commercial CA's that exist today. 10 years later
the document is in question and I need to establish that the certificate
associated with the signature on the document was valid at the time it was
signed; there are several significant possibilities here:
 
1.	CA in question has CRLNumber extension in all of their CRLs and they
are all available
2.	CA in question does not have the CRLNumber in all CRLS or just a
subset
 
Now in #1 the problem is relatively easy, I find all CRLs that were valid
during my window and of those I pick the one that has the highest CRLnumber.
An extension like this would be "use-full" in this case but not necessary.
 
In #2 the problem gets, well unsolvable; Since there are no ways to
determine if I have all of the CRLs that are within my window (remember
validity windows on CRLs can overlap so the ones within the overlapped
window that state the certificate is revoked could be "lost") I will never
now if the certificate was valid at the time in question. Now if the CRLs
that were generated contained all entries and were marked as such with an
extension I would have a mechanism to solve this problem; simply get the
most recent CRL.
 
Ryan
 
 
-----Original Message-----
From: David A. Cooper [mailto:[e-mail]] 
Sent: Wednesday, September 05, 2001 7:39 AM
To: IETF-PKIX
Subject: Re: Removing expired certificates from CRLs.....
 
At 03:53 PM 9/5/01 +0200, Nada Kapidzic Cicovic wrote:


Denis,

I was making comments on the text which Ryan extracted in his mail, assuming
that they were from the son-of-RFC2459.

In particular the last sentence in this paragraph:

The distributionPoint component contains the name of the distribution point
in one or more name forms. If this field is absent, the CRL shall contain
entries for all revoked certificates issued by the CRL issuer. After a
certificate appears on a CRL, it is deleted from a subsequent CRL after the
certificate's expiry.

However, after getting your comment I realized that this sentence and the
referred section 8.6.2.2 comes from the X.509 (the latest version that I
have on my disk is X_509_4thEditionDraftV6, and it contains the above text).


I have X_509_4thEditionDraftV8 on my computer and it appears that this has
been fixed. I now says "After a certificate appears on a CRL, it may be
deleted from a subsequent CRL after the certificate's expiry."  I didn't
bother to look at son-of-2459.

In any case, both X.509 and son-of-2459 should say that a certificate may be
deleted from a CRL after it has expired.  In general, though, I don't think
there is much benefit to leaving expired certificates on CRLs.  The problem
is that, at the moment, if an expired certificate is not listed on a CRL,
there is no way to determine whether it is not listed because it was never
revoked or if it was revoked but is not listed because it was removed after
expiration.

Some time ago, there was a suggestion to create a new, non-critical CRL
extension that would specify whether an expired certificate was covered by a
CRL (e.g., the extension could state: "This CRL includes all revoked
certificates that expire(d) after Jan. 1, 2001 (i.e., notAfter >=
010101000000Z)."). There didn't seem to be much support for this idea, so
the extension was never created.



The current text of the son-of-RFC2459 does not seem to contain it or any
other misleading sentences regarding this issue. 

Sorry for the confusion.

Nada
 

--Boundary_(ID_JkgCqYPxPr3/zzS1dial1Q)
Content-type: text/html
Content-transfer-encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
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@01C13659.21A03020">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"time"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"date"/>
<!--[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:Compatibility>
   <w:UseFELayout/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;
	mso-font-alt:\5B8B\4F53;
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 135135232 16 0 262145 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 135135232 16 0 262145 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:SimSun;}
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.EmailStyle17
	{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:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:2002394047;
	mso-list-type:hybrid;
	mso-list-template-ids:2140069784 67698703 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</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:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>David =
-<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'><span =
style=3D'mso-tab-count:1'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; </span>Although
my confusion on this issue has been cleared up (note to self; always =
verify
your sources) now; this brings up a very interesting point. I and =
others I have
spoken with believe that the addition of such an extension (one that =
states
that the CRL contains ALL revocation entries both current and expired) =
would be
very valuable. <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'>Consider this problem, today I =
receive a digitally
signed and time stamped document (a contract possibly), this document =
was
signed by a certificate issued off of any number of commercial CA's =
that
exist today. 10 years later the document is in question and I need to =
establish
that the certificate associated with the signature on the document was =
valid at
the time it was signed; there are several significant possibilities =
here:<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>=


<ol style=3D'mso-margin-top-alt:0in' start=3D1 type=3D1>
 <li class=3DMsoNormal style=3D'color:navy;mso-list:l0 level1 =
lfo1;tab-stops:list .5in'><font
     size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:
     Arial'>CA in question has <span class=3DSpellE>CRLNumber</span> =
extension in
     all of their <span class=3DSpellE>CRLs</span> and they are all =
available<o:p></o:p></span></font></li>
 <li class=3DMsoNormal style=3D'color:navy;mso-list:l0 level1 =
lfo1;tab-stops:list .5in'><font
     size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:
     Arial'>CA in question does not have the <span =
class=3DSpellE>CRLNumber</span>
     in all CRLS or just a subset<o:p></o:p></span></font></li>
</ol>

<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'>Now in #1 the problem is =
relatively easy,
I find all <span class=3DSpellE>CRLs</span> that were valid during my =
window and
of those I pick the one that has the highest <span =
class=3DSpellE>CRLnumber</span>.
An extension like this would be "use-full" in this case but not
necessary.<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'>In #2 the problem gets, well =
unsolvable;
Since there are no ways to determine if I have all of the <span =
class=3DSpellE>CRLs</span>
that are within my window (remember validity windows on <span =
class=3DSpellE>CRLs</span>
can overlap so the ones within the overlapped window that state the =
certificate
is revoked could be "lost") I will never now if the certificate was
valid at the time in question. Now if the <span =
class=3DSpellE>CRLs</span> that
were generated contained all entries and were marked as such with an =
extension
I would have a mechanism to solve this problem; simply get the most =
recent CRL.<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'>Ryan<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 style=3D'margin-left:.5in'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> David A. Cooper
[mailto:[e-mail]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> =
</span></font><st1:date
Month=3D"9" Day=3D"5" Year=3D"2001"><font size=3D2 face=3DTahoma><span =
style=3D'font-size:
 10.0pt;font-family:Tahoma'>Wednesday, September 05, =
2001</span></font></st1:date><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'> </span></font><st1:time
Hour=3D"7" Minute=3D"39"><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
 font-family:Tahoma'>7:39 AM</span></font></st1:time><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'><br>
<b><span style=3D'font-weight:bold'>To:</span></b> IETF-PKIX<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: Removing =
expired
certificates from CRLs.....</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>At </span></font><st1:time Hour=3D"15" =
Minute=3D"53">03:53
 PM</st1:time> <st1:date Month=3D"9" Day=3D"5" =
Year=3D"2001">9/5/01</st1:date> +0200,
Nada Kapidzic Cicovic wrote:<br =
style=3D'mso-special-character:line-break'>
<![if !supportLineBreakNewLine]><br =
style=3D'mso-special-character:line-break'>
<![endif]><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>Denis,<br>
<br>
I was making comments on the text which Ryan extracted in his mail, =
assuming
that they were from the son-of-RFC2459.<br>
<br>
In particular the last sentence in this paragraph:<br>
<br>
The </span></font><b><font size=3D2><span =
style=3D'font-size:10.0pt;font-weight:
bold'>distributionPoint </span></font></b>component contains the name =
of the
distribution point in one or more name forms. If this field is absent, =
the CRL
shall contain entries for all revoked certificates issued by the CRL =
issuer. <b><i><span
style=3D'font-weight:bold;font-style:italic'>After a certificate =
appears on a
CRL, it is deleted from a subsequent CRL after the certificate's =
expiry.<br>
<br>
</span></i></b>However, after getting your comment I realized that this
sentence and the referred section 8.6.2.2 comes from the X.509 (the =
latest
version that I have on my disk is X_509_4thEditionDraftV6, and it =
contains the
above text). <o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><br>
I have X_509_4thEditionDraftV8 on my computer and it appears that this =
has been
fixed. I now says &quot;After a certificate appears on a CRL, it =
<b><span
style=3D'font-weight:bold'>may be</span></b> deleted from a subsequent =
CRL after
the certificate's expiry.&quot;&nbsp; I didn't bother to look at =
son-of-2459.<br>
<br>
In any case, both X.509 and son-of-2459 should say that a certificate =
may be
deleted from a CRL after it has expired.&nbsp; In general, though, I =
don't
think there is much benefit to leaving expired certificates on =
CRLs.&nbsp; The
problem is that, at the moment, if an expired certificate is not listed =
on a
CRL, there is no way to determine whether it is not listed because it =
was never
revoked or if it was revoked but is not listed because it was removed =
after
expiration.<br>
<br>
Some time ago, there was a suggestion to create a new, non-critical CRL
extension that would specify whether an expired certificate was covered =
by a
CRL (e.g., the extension could state: &quot;This CRL includes all =
revoked
certificates that expire(d) after </span></font><st1:date Month=3D"1" =
Day=3D"1"
Year=3D"2001">Jan. 1, 2001</st1:date> (i.e., notAfter &gt;=3D =
010101000000Z).&quot;).
There didn't seem to be much support for this idea, so the extension =
was never
created.<br>
<br style=3D'mso-special-character:line-break'>
<![if !supportLineBreakNewLine]><br =
style=3D'mso-special-character:line-break'>
<![endif]><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>The current text of the son-of-RFC2459 does =
not seem
to contain it or any other misleading sentences regarding this issue. =
<br>
<br>
Sorry for the confusion.<br>
<br>
Nada<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

--Boundary_(ID_JkgCqYPxPr3/zzS1dial1Q)--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85Lg2M07910 for ietf-pkix-bks; Wed, 5 Sep 2001 14:42:02 -0700 (PDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85Lg0D07903 for <[e-mail]>; Wed, 5 Sep 2001 14:42:00 -0700 (PDT)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA12180; Wed, 5 Sep 2001 13:16:51 -0700 (PDT)
Received: from sun.com (dhcp75-167 [129.148.75.167]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA29997; Wed, 5 Sep 2001 16:16:47 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 05 Sep 2001 16:16:27 -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: "Hallam-Baker, Phillip" <[e-mail]>
CC: Bob Jueneman <[e-mail]>, [e-mail]
Subject: Re: charter revisions
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>

"Hallam-Baker, Phillip" wrote:
> > Bob Jueneman wrote:
> > > I wasn't suggesting that logos should be restricted to end-entities,
> > > I was only pointing out that such a restriction would immediately
> > > make the issue of name subordination and misuse of the logo by some
> > > intermediate CA go away.
> >
> > This isn't true. Name constraints allow me to cross certify
> > IBM's CA but
> > indicate that the only DNs it is trusted to certify are those
> > that begin
> > with "c=us, o=IBM". Even if logos are restricted to end-entities,
> > there's nothing stopping IBM's CA from placing a Sun logo in an
> > end-entity certificate. So restricting logos to end-entities doesn't
> > "make the issue of name subordination and misuse of the logo by some
> > intermediate CA go away."
> 
> I don't see this as a problem for several reasons:
> 
> 1) Logotypes have utility even if they cannot be used with
> cross-certification.

Their utility would be substantially reduced.

> 2) The security of the infrastructure depends on the DNS system and
> not the X.500 name system. The fact that the name is constrained as
> you state does not in practice affect Internet applications. It might
> affect OSI applications if any existed.

Name constraints work the same way for dNSName and rfc822Name name
forms, as well as for X.500 DNs that use the domainComponent attribute
type. I recognize that many CAs stuff DNS and rfc822 names into DNs
using the commonName or EmailAddress attribute types. This practice is
"deprecated but permitted", according to RFC 2459 and successors. Lack
of support for name constraints is one reason why.

> 3) The objection is simply a restatement of the proposition that
> 'bad things happen if you cross certify with someone who
> is not trustworthy'. This is not news.

Name constraints allow you to limit the "bad things" that happen. You
can trust MIT to certify MIT affiliates without worrying about whether
they might issue a certificate claiming to be for George W. Bush.

Most bridge CAs employ name constraints in this fashion. I recognize
that the bridge CA model (and perhaps cross-certification in general)
does not fit well with some business models, but it is quite popular in
many communities. Name constraints and other technology that supports
cross-certification and the bridge CA model are an important part of RFC
2459 and successors.

If logotypes are in fact inconsistent with cross-certification, then
they may not be suitable for use on the Internet.

> > Apparently, you haven't read the draft that serves as the
> > basis for this
> > discussion, draft-ietf-pkix-logotypes-00.txt. The suggested
> > format is a
> > message digest and a URL.
> 
> The basis for this discussion is the proposed charter ammendments.

Reading the latest Internet Draft on the topic will help avoid needless
digressions.

-Steve


Received: by above.proper.com (8.11.6/8.11.3) id f85Lcn707815 for ietf-pkix-bks; Wed, 5 Sep 2001 14:38:49 -0700 (PDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85LclD07811 for <[e-mail]>; Wed, 5 Sep 2001 14:38:47 -0700 (PDT)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA21813; Wed, 5 Sep 2001 14:38:48 -0700 (PDT)
Received: from sun.com (dhcp75-167 [129.148.75.167]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA16667; Wed, 5 Sep 2001 17:38:47 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 05 Sep 2001 17:38:25 -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: "Hallam-Baker, Phillip" <[e-mail]>
CC: Bob Jueneman <[e-mail]>, [e-mail]
Subject: Re: charter revisions
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>

"Hallam-Baker, Phillip" wrote:
> > Name constraints allow you to limit the "bad things" that happen. You
> > can trust MIT to certify MIT affiliates without worrying about whether
> > they might issue a certificate claiming to be for George W. Bush.
> 
> No you can't.
> 
> You can prevent someone from issuing a certificate that claims to
> be for C=US; O=Government; OU=EOP; CN=George W Bush.
> 
> What you can't do is to stop someone from issuing a subjectAltName
> for [e-mail].

Use a name constraint with permitted subtrees of:
 rfc822Name:mit.edu

-Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85LZwa07758 for ietf-pkix-bks; Wed, 5 Sep 2001 14:35:58 -0700 (PDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85LZuD07752; Wed, 5 Sep 2001 14:35:56 -0700 (PDT)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA20478; Wed, 5 Sep 2001 14:35:57 -0700 (PDT)
Received: from sun.com (dhcp75-167 [129.148.75.167]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA00810; Wed, 5 Sep 2001 17:35:55 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 05 Sep 2001 17:35: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: Paul Hoffman / IMC <[e-mail]>
CC: [e-mail]
Subject: Re: charter revisions
References: <p0501040bb7a8214adf35@[128.33.84.34]>	 <[e-mail]>	 <[e-mail]> <p05100327b7baf1ca610b@[165.227.249.20]> <[e-mail]> <p05100343b7bc35f38a13@[165.227.249.20]>
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>

Paul Hoffman / IMC wrote:
> >My original email cited several other security risks that are greater
> >for logotypes than for textual names: CAs may find it harder to verify a
> >certificate requester's right to use a logotype than their right to use
> >a textual name
> 
> That is not a security risk, and it is a supposition.

The risk is that it may be quite easy for a certificate requester to get
an invalid logotype certified. However, this is a supposition, as you
say. We have heard the CA vendors say "Trust us, we can handle it." And
maybe they can. But I, for one, would be much more comfortable if
logotypes were ignored unless all certificates in the path indicate that
they should be supported. This shouldn't be a problem for those who
think that cross-certification is a bad idea.

> >  and logotypes may change appearance radically on
> >different devices.
> 
> More radically than the way a UTF-8 name with non-ASCII characters
> will be displayed?

Maybe not, especially when part of the UTF-8 name cannot be rendered
properly on the user's device (because it includes characters that
aren't present in any font on that device, for instance). We should
probably consider adding text to some future successor to 2459 warning
about this case. Maybe we can provide similar text warning that
logotypes in certificates should not be scaled or mapped to different
colors before display. If this requirement cannot be met, the
certificate should be treated as if it did not contain the logotype.

> >  Several other risks have been pointed out in the
> >recent email discussion: users may not be able to distinguish one
> >logotype from another,
> 
> Ditto for names ("Type 1" vs. "Type 3", similar-looking glyphs in
> various fonts)

Users who aren't concerned about security will always just click OK (or
enter their brokerage info at a web site without considering whether
this is secure). It's hard to provide much protection for such users
(although putting logotypes in certificates will make it harder for
programs that try to be smart about what's safe).

But we should try to avoid designing in features that nobody can use
securely. The current system allows a careful user with a properly
configured system to type a URL and have the browser check that the host
name matches the certificate or examine a name in a signed email and
decide whether it is the one desired (ignoring poor fonts, misspellings,
etc). Certifying and examining a logotype is a much more fuzzy process,
open to many more errors.

> >  users may not recall which logotype corresponds
> >to which entity,
> 
> Ditto for names
> 
> >  and logotypes are not accessible to vision-impaired
> >users or usable on text-only terminals.
> 
> This is indeed an issue.
> 
> >The whole paragraph should be considered predicated by the first clause
> >("Unless..."). If that clause does not apply (i.e., we can develop a
> >fairly secure way to place logotypes in certificates), then I don't have
> >any objection to having this as a PKIX work item. But I have seen no
> >sign that the objections raised so far can be overcome.
> 
> Then that should come up when discussing the protocols, not the
> charter.

But we have a proposal on the table for how to include logotypes in
certificates and the proposal is demonstrably flawed (although this is
subject to some debate). Nobody has been able to come up with any way to
fix it. My conclusion is that it can't be fixed. Shouldn't the question
of whether the work item is feasible be relevant to a discussion of
whether it should be added to the charter?

> >RFC 2418 (BCP 25) says that "IETF developed technologies should not add
> >insecurity to the environment in which they run." The IESG has enforced
> >this in the past and it seems especially pertinent to a working group in
> >the Security Area. I doubt that the IESG or the Security ADs will accept
> >this work item in our charter unless we can argue convincingly that we
> >can develop something that would not add insecurity to the environment
> >in which it is run. I don't think we're there yet.
> 
> Trying to predict what the IESG will do is just plain silly (even
> individual IESG members are bad at this).

You're probably right. I suggest that our working group chairs make a
decision about whether they still want to include this work item in the
proposed charter. If they want to do so, I would ask that they inform
the Security ADs that the working group did not reach consensus on this
question and point the Security ADs to the discussion here on the list
so that they can make up their own mind. I believe that all of the
relevant arguments in favor and opposed have been raised.

Thanks,

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85LNGJ07552 for ietf-pkix-bks; Wed, 5 Sep 2001 14:23:16 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85LNFD07548 for <[e-mail]>; Wed, 5 Sep 2001 14:23:15 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id f85LKcr10341 for <[e-mail]>; Wed, 5 Sep 2001 17:20:38 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 05 Sep 2001 17:17:09 -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: charter revisions
References: <p0501040bb7a8214adf35@[128.33.84.34]>	 <[e-mail]>	 <[e-mail]> <p05100327b7baf1ca610b@[165.227.249.20]> <[e-mail]> <p05100343b7bc35f38a13@[165.227.249.20]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-H-S-Loop-Check-Ejzfr: 
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 Hoffman / IMC wrote:
> 
> At 10:18 AM -0400 9/5/01, Steve Hanna wrote:
> >Paul Hoffman / IMC wrote
> >>  Are the risks any greater than what we have in 2459 now with spelling
> >>  errors or things like "FooCA type 1 certificate" vs. "FooCA type 2
> >>  certificate"? I agree with Russ that the benefits are higher, but I'm
> >>  not at all convinced that the risks are higher.
> >
> >Yes, the risks are greater than those encountered with textual names.
> >For one thing, name constraints provide an effective way to limit the
> >portion of the name space that can be reached via a cross certificate.
> >No corresponding mechanism has been suggested for logotypes nor does it
> >seem likely that such a mechanism could be developed.
> 
> I don't think that name constraints works well against spelling
> errors or the kinds of names I specified above. I agree that it will
> probably be impossible to constrain logotypes any more than it is to
> constrain the value within CN.


The distinction is that name constraints is a mechanism; there is no
analogous mechanism for logotypes.  If you have name constraint with
a permitted subtree under "FooCA Type 1", then your browser will reject
all certificates under "FooCA Type 2" regardless of whether the "2" is
an innocent spelling error or a malicious spoof attempt.  What makes
you believe that name constraints don't work well (i.e. that the rejection
of "2" is an undesired outcome)?


> >RFC 2418 (BCP 25) says that "IETF developed technologies should not add
> >insecurity to the environment in which they run." The IESG has enforced
> >this in the past and it seems especially pertinent to a working group in
> >the Security Area. I doubt that the IESG or the Security ADs will accept
> >this work item in our charter unless we can argue convincingly that we
> >can develop something that would not add insecurity to the environment
> >in which it is run. I don't think we're there yet.
> 
> Trying to predict what the IESG will do is just plain silly (even
> individual IESG members are bad at this).

There is a distinction between what BCP 25 says in black and white,
and attempting to predict how the IESG will interpret BCP 25 when
considering a new work item.   Rather than wasting bandwidth calling
prediction "silly", you should argue substantively about why logotypes
do not add insecurity to the environment in which they run.

I'm agnostic on the actual issue - logotypes in certificates are
both seductive and dangerous.  The potential harm from user
confusion will outweigh the cuteness factor in some circumstances
(promiscuous trust lists) and will not in others (trustworthy CAs who
attempt to make logos meaningful, distinct, and few).  What should
PKIX do about it?  I don't know.


Received: by above.proper.com (8.11.6/8.11.3) id f85L2Ij06971 for ietf-pkix-bks; Wed, 5 Sep 2001 14:02:18 -0700 (PDT)
Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85L2GD06965 for <[e-mail]>; Wed, 5 Sep 2001 14:02:16 -0700 (PDT)
Received: from postal-gw1.verisign.com (verisign.com [63.104.27.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id OAA04679; Wed, 5 Sep 2001 14:02:49 -0700 (PDT)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2654.89) id <R5Q8CYHF>; Wed, 5 Sep 2001 13:59:33 -0700
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'Steve Hanna'" <[e-mail]>, "Hallam-Baker, Phillip" <[e-mail]>
Cc: Bob Jueneman <[e-mail]>, [e-mail]
Subject: RE: charter revisions
Date: Wed, 5 Sep 2001 13:59:28 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1364D.A7471600"
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_000_01C1364D.A7471600
Content-Type: text/plain;
	charset="iso-8859-1"

> > I don't see this as a problem for several reasons:
> > 
> > 1) Logotypes have utility even if they cannot be used with
> > cross-certification.
> 
> Their utility would be substantially reduced.

I disagree.

The arguments against logotypes in cross certificates simply
restate the long standing problems with the concept of cross 
certification. If you care about the problems being raised with
and have not already found a solution then you cannot use 
cross certification.


> Name constraints allow you to limit the "bad things" that happen. You
> can trust MIT to certify MIT affiliates without worrying about whether
> they might issue a certificate claiming to be for George W. Bush.

No you can't.

You can prevent someone from issuing a certificate that claims to
be for C=US; O=Government; OU=EOP; CN=George W Bush.

What you can't do is to stop someone from issuing a subjectAltName
for [e-mail].


> Most bridge CAs employ name constraints in this fashion. I recognize
> that the bridge CA model (and perhaps cross-certification in general)
> does not fit well with some business models, but it is quite 
> popular in
> many communities. Name constraints and other technology that supports
> cross-certification and the bridge CA model are an important 
> part of RFC
> 2459 and successors.

I still do not buy the argument that the trust rests upon the name
constraints. A machine can make sensible decisions on the basis of
a DN, but then again a machine is going to ignore the logotypes in
any case.

The logotypes argument is about the human interface, not the 
machine interface. DNs are a lousy human interface as the virtual
extinction of X.400 mail proves.


		Phill


------_=_NextPart_000_01C1364D.A7471600
Content-Type: application/octet-stream;
	name="Phillip Hallam-Baker (E-mail).vcf"
Content-Disposition: attachment;
	filename="Phillip Hallam-Baker (E-mail).vcf"

BEGIN:VCARD
VERSION:2.1
N:Hallam-Baker;Phillip
FN:Phillip Hallam-Baker (E-mail)
ORG:VeriSign
TITLE:Principal Consultant
TEL;WORK;VOICE:[phone] x227
EMAIL;PREF;INTERNET:[e-mail]
REV:20010214T163732Z
END:VCARD

------_=_NextPart_000_01C1364D.A7471600--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85KYT006310 for ietf-pkix-bks; Wed, 5 Sep 2001 13:34:29 -0700 (PDT)
Received: from bach.digsigtrust.com (host65-54.digsigtrust.com [208.30.65.54]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85KYRD06306 for <[e-mail]>; Wed, 5 Sep 2001 13:34:27 -0700 (PDT)
Received: from smtp.digsigtrust.com by smtp1.digsigtrust.com  with ESMTP id f85KYOu02145; Wed, 5 Sep 2001 14:34:24 -0600 (MDT)
Received: from cc474623a (cc474623-a.abdn1.md.home.com [24.18.83.123]) by smtp.digsigtrust.com with SMTP id f85KY0x07615; Wed, 5 Sep 2001 14:34:00 -0600 (MDT)
Reply-To: <[e-mail]>
From: "Yuriy Dzambasow" <[e-mail]>
To: "Al Arsenault" <[e-mail]>, "Steve Hanna" <[e-mail]>
Cc: "Stephen Kent" <[e-mail]>, <[e-mail]>
Subject: RE: charter revisions
Date: Wed, 5 Sep 2001 16:31:23 -0400
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.00.2615.200
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 too agree that logotypes can help foster deployment of certificates to the
broader consumer community.  Consider how merchants use the Visa, MC, and
AMEX logos to denote which credit cards they accept.  Consumers then look
into their wallets and pull out the appropriate credit card (using the logo
as an identifier) based on what the merchant will accept.  Of course, the
merchant still processes the credit card to ensure it is still valid, and
does not solely rely on the logo on the card.  The same approach can be
taken with consumers trying to gain access to services at merchant web
sites.  Therefore, I think it would be helpful to define a standard way of
representing logos in certificates.

Yuriy

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Al Arsenault
Sent: Thursday, August 30, 2001 4:43 PM
To: Steve Hanna
Cc: Stephen Kent; [e-mail]
Subject: RE: charter revisions


I agree with Russ here.  The issues involved with logos, while difficult,
are not insurmountable.  They do serve a useful purpose in some
environments, and a standard way of including them will be much better than
letting every CA invents its own.

I believe that the logo work should be in the PKIX charter.

                Al Arsenault
                Chief Security Architect
                Diversinet



-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Housley, Russ
Sent: Thursday, August 30, 2001 1:33 PM
To: Steve Hanna
Cc: Stephen Kent; [e-mail]
Subject: Re: charter revisions



Steve Hanna:

>I haven't seen any comments on the revised charter yet. Most of it looks
>good to me. However, I don't think PKIX should do any work on the
>logotype extension. I know that there is a demand for this from
>marketing folks, but I don't believe that we should standardize it
>unless it can be used securely. This does not seem possible.

You and I agree on most things, but we have a major disagreement here.  I
do not think that we will see widespread deployment of certificates without
logos.  One measure of success will be the number of certificates that
average Internet user have.  Hopefully every Internet user will have at
least one.  I suspect that as we become successful, these logos will be the
tag by which users select a certificate.

I do not want to see more than one way that logos can be put into
certificates.  That is the most important reason for PKIX to be involved in
the definition.  You seem to agree that the market has a demand for
logos.  Letting each vendor devise an independent way to meet this
marketing requirement would be very bad for all implementors.

You seem to be concerned with the security of logos.  I am not.  From my
perspective, we are asking CAs to do many things that are harder than
including a URL and hash of a the appropriate logo.  In many, many cases,
this will be the same logo in every certificate that is issued by that CA.

Anyway, we should not have the complete technical debate on a threat about
the charter.  I strongly encourage the PKIX working group to include this
area in the charter sent forward to the Area Directors for approval.  Once
the revised charter is approved, we can have the technical debate and sort
out the details.

Russ



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85KMt606045 for ietf-pkix-bks; Wed, 5 Sep 2001 13:22:55 -0700 (PDT)
Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85KMrD06038 for <[e-mail]>; Wed, 5 Sep 2001 13:22:53 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100343b7bc35f38a13@[165.227.249.20]>
In-Reply-To: <[e-mail]>
References: <p0501040bb7a8214adf35@[128.33.84.34]>	 <[e-mail]>	 <[e-mail]> <p05100327b7baf1ca610b@[165.227.249.20]> <[e-mail]>
Date: Wed, 5 Sep 2001 13:16:46 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: charter revisions
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:18 AM -0400 9/5/01, Steve Hanna wrote:
>Paul Hoffman / IMC wrote:
>>  At 11:58 AM -0400 9/4/01, Steve Hanna wrote:
>>  >Unless the author of the Internet Draft indicates otherwise, I will
>>  >assume that the primary purpose of putting logotypes in certificates
>>  >is so that users can view them to make decisions about whether the
>>  >certificates are trustworthy. In that case, the risks are much greater
>  > >than those for the use case you described.
>>
>>  Are the risks any greater than what we have in 2459 now with spelling
>>  errors or things like "FooCA type 1 certificate" vs. "FooCA type 2
>>  certificate"? I agree with Russ that the benefits are higher, but I'm
>>  not at all convinced that the risks are higher.
>
>Yes, the risks are greater than those encountered with textual names.
>For one thing, name constraints provide an effective way to limit the
>portion of the name space that can be reached via a cross certificate.
>No corresponding mechanism has been suggested for logotypes nor does it
>seem likely that such a mechanism could be developed.

I don't think that name constraints works well against spelling 
errors or the kinds of names I specified above. I agree that it will 
probably be impossible to constrain logotypes any more than it is to 
constrain the value within CN.

>My original email cited several other security risks that are greater
>for logotypes than for textual names: CAs may find it harder to verify a
>certificate requester's right to use a logotype than their right to use
>a textual name

That is not a security risk, and it is a supposition.

>  and logotypes may change appearance radically on
>different devices.

More radically than the way a UTF-8 name with non-ASCII characters 
will be displayed?

>  Several other risks have been pointed out in the
>recent email discussion: users may not be able to distinguish one
>logotype from another,

Ditto for names ("Type 1" vs. "Type 3", similar-looking glyphs in 
various fonts)

>  users may not recall which logotype corresponds
>to which entity,

Ditto for names

>  and logotypes are not accessible to vision-impaired
>users or usable on text-only terminals.

This is indeed an issue.

>The whole paragraph should be considered predicated by the first clause
>("Unless..."). If that clause does not apply (i.e., we can develop a
>fairly secure way to place logotypes in certificates), then I don't have
>any objection to having this as a PKIX work item. But I have seen no
>sign that the objections raised so far can be overcome.

Then that should come up when discussing the protocols, not the charter.

>RFC 2418 (BCP 25) says that "IETF developed technologies should not add
>insecurity to the environment in which they run." The IESG has enforced
>this in the past and it seems especially pertinent to a working group in
>the Security Area. I doubt that the IESG or the Security ADs will accept
>this work item in our charter unless we can argue convincingly that we
>can develop something that would not add insecurity to the environment
>in which it is run. I don't think we're there yet.

Trying to predict what the IESG will do is just plain silly (even 
individual IESG members are bad at this).

--Paul Hoffman, Director
--Internet Mail Consortium


Received: by above.proper.com (8.11.6/8.11.3) id f85K2AN05408 for ietf-pkix-bks; Wed, 5 Sep 2001 13:02:10 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85K28D05404 for <[e-mail]>; Wed, 5 Sep 2001 13:02:08 -0700 (PDT)
Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 05 Sep 2001 14:02:07 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Wed, 05 Sep 2001 14:04:27 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: charter revisions
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-7
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f85K29D05405
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:
>> I wasn't suggesting that logos should be restricted to end-entities,
>> I was only pointing out that such a restriction would immediately
>> make the issue of name subordination and misuse of the logo by some
>> intermediate CA go away.
>
>This isn't true. Name constraints allow me to cross certify IBM's CA but
>indicate that the only DNs it is trusted to certify are those that begin
>with "c=us, o=IBM". Even if logos are restricted to end-entities,
>there's nothing stopping IBM's CA from placing a Sun logo in an
>end-entity certificate. So restricting logos to end-entities doesn't
>"make the issue of name subordination and misuse of the logo by some
>intermediate CA go away."

Sorry, Steve, you are quite correct in that sense.  I guess I wasn't thinking about corporate logos tied to organizational persons as much as I was thinking about brand identification, where the brand isn't owned by the superior CA in any case, any more than VeriSign owns c=us, o=Sun. In any case, name subordination is a very limited mechanism, that solves a problem that basically doesn't exist.  How many subordinate CAs can you point to that aren't owned and controlled by the parent CA?  And how many browsers or other client software correctly implement the constraint?  And how do you apply a name subordination constraint to a DNS name for SSL ¯ restrict it to entities registered under .com?

As Phillip points out, if you are going to cross-certify a CA that would violate a trademarked logo, you probably have even worse problems, particularly since such a case would provide the kind of iron-clad, smoking gun type of evidence that an attorney would love to have.  

But if we were really and truly concerned about this issue, I believe that other alternatives could be created, for example (just off the top of my head), by somehow embedding the logo URL within a policy OID that could be subject to a policy constraint, or by inventing some entirely new mechanism. We could pile on attribute certificates and/or lots of other baggage that would provide a firm, technically sound foundation for proving that someone was duly authorized to do this, that, or the other function, including displaying a logo in his certificate, but that just negates the assumption we were making about the CA being trustworthy in the first place.

>Apparently, you haven't read the draft that serves as the basis for this
>discussion, draft-ietf-pkix-logotypes-00.txt. The suggested format is a
>message digest and a URL.

Yes, I had.  I was merely echoing, or perhaps re-echoing, support for that idea, particularly after Peter Gutman had mentioned the old MPEG of a cat included within a certificate.

In any case, I believe that the merits of charter discussion have been adequately addressed, even though we may not have unanimity, and may not have even changed anyone's mind.

I move that we call the question, and let the chairs decide.

Bob




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85JCUm04137 for ietf-pkix-bks; Wed, 5 Sep 2001 12:12:30 -0700 (PDT)
Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85JCSD04130 for <[e-mail]>; Wed, 5 Sep 2001 12:12:28 -0700 (PDT)
Received: from postal-gw1.verisign.com (verisign.com [63.104.27.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id MAA25125; Wed, 5 Sep 2001 12:15:46 -0700 (PDT)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2654.89) id <R5Q8CXKN>; Wed, 5 Sep 2001 12:12:30 -0700
Message-ID: <[e-mail]>
From: "Flynn, Michael" <[e-mail]>
To: "'Ryan Hurst'" <[e-mail]>, "Flynn, Michael" <[e-mail]>, IETF-PKIX <[e-mail]>
Subject: RE: Removing expired certificates from CRLs.....
Date: Wed, 5 Sep 2001 12:12:26 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1363E.B3650960"
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_01C1363E.B3650960
Content-Type: text/plain;
	charset="iso-8859-1"

Ryan,
You wrote, "However CRL validity windows commonly overlap; so determining
how would some one know (without CRLNumbers which most CAs do not include
yet) if they had them all?"
 
That is a good point.
 
Michael
 
-----Original Message-----
From: Ryan Hurst [mailto:[e-mail]]
Sent: Wednesday, September 05, 2001 12:02 PM
To: 'Flynn, Michael'; Ryan Hurst; IETF-PKIX
Subject: RE: Removing expired certificates from CRLs.....


Michael -
            In regards to storing all generated CRLs for n period of time to
address the non-repudiation issues; yes this would deal with the problem.
However CRL validity windows commonly overlap; so determining how would some
one know (without CRLNumbers which most CAs do not include yet) if they had
them all? Additionally the process of looking at ALL CRLs and determining
which one is the "most recent" match would be an expensive one.
 
For these reasons it would be "nice" if CRLs were only used by servers and
contained all revoked certificates; but this means that clients would not
want to use CRLs due to the expense associated with acquiring the recent
CRL.
 
I believe the overall goal of CRLs was not to deal with NR, but to instead
have a simple mechanism to distribute bulk "current" revocation information
to the broadest set of clients. For this reason; I think its best to remove
the expired certificates and deal with NR through another mechanism,
probably service based.
 
After reading every ones posts on this topic, I guess I do not think we
should mandate the removal of the entries; we may wish recommend this be
done though. This of coarse is a mute point due to the last-call already
taking place ;)
 
Ryan
 
-----Original Message-----
From: Flynn, Michael [mailto:[e-mail]] 
Sent: Wednesday, September 05, 2001 10:03 AM
To: 'Ryan Hurst'; IETF-PKIX
Subject: RE: Removing expired certificates from CRLs.....
 
Ryan,
 
Ryan wrote::
Now logically it makes sense to remove certificates that are expired from
CRLs to control size, yes this has a negative point specifically it prevents
CRLs from being used as a non-repudiation source; but this is mute due to
many other issues.
 
At least regarding removing expired certs from CRLs, I would think that
non-repudiation can be satisfied by keeping the old CRLs in back up storage
for some length of time. That time being how far back in time a contract
dispute might go; ten years, twenty?   So long as you could get them off
tape for the lawyers to look at the legal process would be satisfied, they
don't need to be online forever.  
 
Michael
 
-----Original Message-----
From: Ryan Hurst [mailto:[e-mail]]
Sent: Tuesday, September 04, 2001 8:50 PM
To: IETF-PKIX
Subject: Removing expired certificates from CRLs.....
I was speaking with Peter Williams today about the removal of expired
certificates from CRLs; I have always been under the belief that this
behavior was optional, I vaguely remembered reading text in 2459 along those
lines; additionally I know of several commercial CAs that do not remove the
expired certificates from their CRLs. Peter on the other hand was under the
impression that it was a mandate to remove CRLs; he too remembered reading
text in 2459 to support is position.
 
So we each pulled out the RFC and found that we were both right!
Specifically both sections 3.3 and 8.6.2.2 have text on this subject:
 
3.3  Revocation
When a certificate is issued, it is expected to be in use for its entire
validity period.  However, various circumstances may cause a certificate to
become invalid prior to the expiration of the validity period.
 
....
 
An entry is added to the CRL as part of the next update following
notification of revocation. An entry may be removed from the CRL after
appearing on one regularly scheduled CRL issued beyond the revoked
certificate's validity period.
 
 
 
8.6.2.2 Issuing distribution point extension
This CRL extension field identifies the CRL distribution point for this
particular CRL, and indicates if the CRL is limited to revocations for
end-entity certificates only, for authority certificates only, or for a
limited set of reasons only. The CRL is signed by the CRL issuer's key- CRL
distribution points do not have their own key pairs. However, for a CRL
distributed via the Directory, the CRL is stored in the entry of the CRL
distribution point, which may not be the directory entry of the CRL issuer.
If this field is absent, the CRL shall contain entries for all revoked
unexpired certificates issued by the CRL issuer.
 
....
 
The distributionPoint component contains the name of the distribution point
in one or more name forms. If this field is absent, the CRL shall contain
entries for all revoked certificates issued by the CRL issuer. After a
certificate appears on a CRL, it is deleted from a subsequent CRL after the
certificate's expiry.
 
 
Although section 8.6.2.2 is specifically in regards to CRLdps, any
difference between full CRLs and CRLdps in this case I feel would be an
arbitrary one. 
 
Now logically it makes sense to remove certificates that are expired from
CRLs to control size, yes this has a negative point specifically it prevents
CRLs from being used as a non-repudiation source; but this is mute due to
many other issues.
 
That being the case I think; and I believe Peter would agree the correct
thing to do is to remove these expired/revoked entries from the CRL. 
 
The question now is what is the PKIX stance on this matter?
 
Ryan M. Hurst
ValiCert, Inc.
 
"It may roundly be asserted that human ingenuity cannot concoct a cipher
which human ingenuity cannot resolve."
-Edgar Allan Poe
 

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:o = 
"urn:schemas-microsoft-com:office:office" xmlns:w = 
"urn:schemas-microsoft-com:office:word" xmlns:st1 = 
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content=Word.Document name=ProgId>
<META content="MSHTML 5.50.4616.200" name=GENERATOR>
<META content="Microsoft Word 10" name=Originator><LINK 
href="cid:filelist.xml@01C13603.66FB6DC0" rel=File-List><o:SmartTagType 
name="PersonName" 
namespaceuri="urn:schemas-microsoft-com:office:smarttags"></o:SmartTagType><o:SmartTagType 
name="time" 
namespaceuri="urn:schemas-microsoft-com:office:smarttags"></o:SmartTagType><o:SmartTagType 
name="date" 
namespaceuri="urn:schemas-microsoft-com:office:smarttags"></o:SmartTagType><!--[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:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
   <w:UseFELayout/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<STYLE>
st1\:*{behavior:url(#default#ieooui) }
</STYLE>
<![endif]-->
<STYLE>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;
	mso-font-alt:\5B8B\4F53;
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 135135232 16 0 262145 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 135135232 16 0 262145 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:SimSun;}
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.EmailStyle17
	{mso-style-type:personal;
	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:windowtext;}
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:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</STYLE>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */ 
 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:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]--></HEAD>
<BODY lang=EN-US style="tab-interval: .5in" vLink=purple link=blue>
<DIV><FONT face=Arial><FONT color=#000080><FONT size=2><SPAN 
class=226091019-05092001>Ryan,</SPAN></FONT></FONT></FONT></DIV>
<DIV><SPAN class=226091019-05092001></SPAN><FONT face=Arial><FONT 
color=#000080><FONT size=2><SPAN class=226091019-05092001>You wrote, 
"</SPAN>However CRL validity windows commonly overlap; so determining how would 
some one know (without CRLNumbers which most CAs do not include yet) if they had 
them all?<SPAN class=226091019-05092001>"</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial color=#000080 size=2></FONT>&nbsp;</DIV>
<DIV><SPAN class=226091019-05092001><FONT face=Arial color=#000080 size=2>That 
is a good point.</FONT></SPAN></DIV>
<DIV><SPAN class=226091019-05092001><FONT face=Arial color=#000080 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=226091019-05092001><FONT face=Arial color=#000080 
size=2>Michael</FONT></SPAN></DIV>
<DIV><SPAN class=226091019-05092001></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Ryan Hurst 
  [mailto:[e-mail]]<BR><B>Sent:</B> Wednesday, September 05, 2001 
  12:02 PM<BR><B>To:</B> 'Flynn, Michael'; Ryan Hurst; 
  IETF-PKIX<BR><B>Subject:</B> RE: Removing expired certificates from 
  CRLs.....<BR><BR></FONT></DIV>
  <DIV class=Section1>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Michael 
  -<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN 
  style="mso-tab-count: 1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>In regards to storing all generated CRLs for <I 
  style="mso-bidi-font-style: normal"><SPAN 
  style="FONT-STYLE: italic; mso-bidi-font-style: normal">n </SPAN></I>period of 
  time to address the non-repudiation issues; yes this would deal with the 
  problem. However CRL validity windows commonly overlap; so determining how 
  would some one know (without CRLNumbers which most CAs do not include yet) if 
  they had them all? Additionally the process of looking at ALL CRLs and 
  determining which one is the "most recent" match would be an expensive 
  one.<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">For these reasons it 
  would be "nice" if CRLs were only used by servers and contained all revoked 
  certificates; but this means that clients would not want to use CRLs due to 
  the expense associated with acquiring the recent 
  CRL.<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I believe the overall 
  goal of CRLs was not to deal with NR, but to instead have a simple mechanism 
  to distribute bulk "current" revocation information to the broadest set of 
  clients. For this reason; I think its best to remove the expired certificates 
  and deal with NR through another mechanism, probably service 
  based.<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">After reading every 
  ones posts on this topic, I guess I do not think we should mandate the removal 
  of the entries; we may wish recommend this be done though. This of coarse is a 
  mute point due to the last-call already taking place 
  ;)<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Ryan<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face=Tahoma size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">-----Original 
  Message-----<BR><B><SPAN style="FONT-WEIGHT: bold">From:</SPAN></B> Flynn, 
  Michael [mailto:[e-mail]] <BR><B><SPAN 
  style="FONT-WEIGHT: bold">Sent:</SPAN></B> </SPAN></FONT><st1:date Year="2001" 
  Day="5" Month="9"><FONT face=Tahoma size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">Wednesday, September 05, 
  2001</SPAN></FONT></st1:date><FONT face=Tahoma size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"> </SPAN></FONT><st1:time 
  Minute="3" Hour="10"><FONT face=Tahoma size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">10:03 
  AM</SPAN></FONT></st1:time><FONT face=Tahoma size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"><BR><B><SPAN 
  style="FONT-WEIGHT: bold">To:</SPAN></B> 'Ryan Hurst'; IETF-PKIX<BR><B><SPAN 
  style="FONT-WEIGHT: bold">Subject:</SPAN></B> RE: Removing expired 
  certificates from CRLs.....</SPAN></FONT></P>
  <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face="Times New Roman" 
  size=3><SPAN style="FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <DIV>
  <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face="Courier New" 
  size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Ryan,</SPAN></FONT><o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face="Times New Roman" 
  size=3><SPAN style="FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
  <DIV>
  <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face="Courier New" 
  size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Ryan 
  wrote::<o:p></o:p></SPAN></FONT></P></DIV>
  <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Now logically it makes sense to 
  remove certificates that are expired from CRLs to control size, yes this has a 
  negative point specifically it prevents CRLs from being used as a 
  non-repudiation source; but this is mute due to many other 
  issues.</SPAN></FONT><o:p></o:p></P>
  <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face="Times New Roman" 
  size=3><SPAN style="FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">At least regarding removing 
  expired certs from CRLs, I would think that non-repudiation can be satisfied 
  by keeping the old CRLs in back up storage for some length of time. That time 
  being how far back in time a contract dispute might go; ten years, twenty? 
  &nbsp; So long as you could get them off&nbsp; tape for the lawyers to look at 
  the legal process would be satisfied, they don't need to be online 
  forever.&nbsp; <o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face="Times New Roman" 
  size=3><SPAN style="FONT-SIZE: 12pt">&nbsp;</SPAN></FONT><FONT face=Arial 
  size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Michael<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face="Times New Roman" 
  size=3><SPAN style="FONT-SIZE: 12pt">&nbsp;</SPAN></FONT><FONT face=Arial 
  size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT></P>
  <BLOCKQUOTE 
  style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; MARGIN: 5pt 0in 5pt 3.75pt; BORDER-LEFT: black 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: medium none">
    <P class=MsoNormal 
    style="MARGIN-BOTTOM: 12pt; MARGIN-LEFT: 0.5in; MARGIN-RIGHT: 0in; mso-margin-top-alt: 0in"><FONT 
    face=Tahoma size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">-----Original 
    Message-----<BR><B><SPAN style="FONT-WEIGHT: bold">From:</SPAN></B> Ryan 
    Hurst [mailto:[e-mail]]<BR><B><SPAN 
    style="FONT-WEIGHT: bold">Sent:</SPAN></B> Tuesday, September 04, 2001 8:50 
    PM<BR><B><SPAN style="FONT-WEIGHT: bold">To:</SPAN></B> 
    IETF-PKIX<BR><B><SPAN style="FONT-WEIGHT: bold">Subject:</SPAN></B> Removing 
    expired certificates from CRLs.....</SPAN></FONT><o:p></o:p></P>
    <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">I was speaking with 
    </SPAN></FONT><st1:PersonName><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Peter 
    Williams</SPAN></FONT></st1:PersonName><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> today about the removal of 
    expired certificates from CRLs; I have always been under the belief that 
    this behavior was optional, I vaguely remembered reading text in 2459 along 
    those lines; additionally I know of several commercial CAs that do not 
    remove the expired certificates from their CRLs. Peter on the other hand was 
    under the impression that it was a mandate to remove CRLs; he too remembered 
    reading text in 2459 to support is position.<o:p></o:p></SPAN></FONT></P>
    <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">So we each pulled out the RFC 
    and found that we were both right! Specifically both sections 3.3 and 
    8.6.2.2 have text on this subject:<o:p></o:p></SPAN></FONT></P>
    <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoNormal 
    style="MARGIN-LEFT: 0.5in; tab-stops: 45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt 320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt 732.8pt; mso-layout-grid-align: none"><B 
    style="mso-bidi-font-weight: normal"><FONT face=Arial size=2><SPAN 
    style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-bidi-font-weight: normal">3.3<SPAN 
    style="mso-spacerun: yes">&nbsp; 
    </SPAN>Revocation<o:p></o:p></SPAN></FONT></B></P>
    <P class=MsoNormal 
    style="MARGIN-LEFT: 0.5in; tab-stops: 45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt 320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt 732.8pt; mso-layout-grid-align: none"><FONT 
    face=Arial size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">When a 
    certificate is issued, it is expected to be in use for its entire validity 
    period.<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>However, various 
    circumstances may cause a certificate to become invalid prior to the 
    expiration of the validity period.<o:p></o:p></SPAN></FONT></P>
    <P class=MsoNormal 
    style="MARGIN-LEFT: 0.5in; tab-stops: 45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt 320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt 732.8pt; mso-layout-grid-align: none"><FONT 
    face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoNormal 
    style="MARGIN-LEFT: 0.5in; mso-layout-grid-align: none"><FONT face=Arial 
    size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">....<o:p></o:p></SPAN></FONT></P>
    <P class=MsoNormal 
    style="MARGIN-LEFT: 0.5in; mso-layout-grid-align: none"><FONT face=Arial 
    size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoNormal 
    style="MARGIN-LEFT: 0.5in; tab-stops: 45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt 320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt 732.8pt; mso-layout-grid-align: none"><FONT 
    face=Arial size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">An entry 
    is added to the CRL as part of the next update following notification of 
    revocation. <B><I><SPAN style="FONT-WEIGHT: bold; FONT-STYLE: italic">An 
    entry may be removed from the CRL after appearing on one regularly scheduled 
    CRL issued beyond the revoked certificate's validity 
    period.</SPAN></I></B><o:p></o:p></SPAN></FONT></P>
    <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoNormal 
    style="MARGIN-LEFT: 0.5in; mso-layout-grid-align: none"><B><FONT face=Arial 
    size=2><SPAN 
    style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Arial">8.6.2.2 
    Issuing distribution point extension<o:p></o:p></SPAN></FONT></B></P>
    <P class=MsoNormal 
    style="MARGIN-LEFT: 0.5in; mso-layout-grid-align: none"><FONT face=Arial 
    size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">This CRL extension 
    field identifies the CRL distribution point for this particular CRL, and 
    indicates if the CRL is limited to revocations for end-entity certificates 
    only, for authority certificates only, or for a limited set of reasons only. 
    The CRL is signed by the CRL issuer's key- CRL distribution points do not 
    have their own key pairs. However, for a CRL distributed via the Directory, 
    the CRL is stored in the entry of the CRL distribution point, which may not 
    be the directory entry of the CRL issuer.<I><SPAN 
    style="FONT-STYLE: italic"> <B><SPAN style="FONT-WEIGHT: bold">If this field 
    is absent, the CRL shall contain entries for all revoked unexpired 
    certificates issued by the CRL 
    issuer.</SPAN></B><o:p></o:p></SPAN></I></SPAN></FONT></P>
    <P class=MsoNormal 
    style="MARGIN-LEFT: 0.5in; mso-layout-grid-align: none"><I><FONT face=Arial 
    size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-STYLE: italic; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></I></P>
    <P class=MsoNormal 
    style="MARGIN-LEFT: 0.5in; mso-layout-grid-align: none"><FONT face=Arial 
    size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">....<o:p></o:p></SPAN></FONT></P>
    <P class=MsoNormal 
    style="MARGIN-LEFT: 0.5in; mso-layout-grid-align: none"><FONT face=Arial 
    color=blue size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoNormal 
    style="MARGIN-LEFT: 0.5in; mso-layout-grid-align: none"><FONT face=Arial 
    size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">The 
    </SPAN></FONT><B><FONT face=Arial size=1><SPAN 
    style="FONT-WEIGHT: bold; FONT-SIZE: 9pt; FONT-FAMILY: Arial">distributionPoint 
    </SPAN></FONT></B><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">component contains the name of 
    the distribution point in one or more name forms. If this field is absent, 
    the CRL shall contain entries for all revoked certificates issued by the CRL 
    issuer. <B><I><SPAN style="FONT-WEIGHT: bold; FONT-STYLE: italic">After a 
    certificate appears on a CRL, it is deleted from a subsequent CRL after the 
    certificate's expiry.<o:p></o:p></SPAN></I></B></SPAN></FONT></P>
    <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Although section 8.6.2.2 is 
    specifically in regards to CRLdps, any difference between full CRLs and 
    CRLdps in this case I feel would be an arbitrary one. 
    <o:p></o:p></SPAN></FONT></P>
    <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Now logically it makes sense to 
    remove certificates that are expired from CRLs to control size, yes this has 
    a negative point specifically it prevents CRLs from being used as a 
    non-repudiation source; but this is mute due to many other 
    issues.<o:p></o:p></SPAN></FONT></P>
    <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">That being the case I think; and 
    I believe Peter would agree the correct thing to do is to remove these 
    expired/revoked entries from the CRL. <o:p></o:p></SPAN></FONT></P>
    <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">The question now is what is the 
    PKIX stance on this matter?<o:p></o:p></SPAN></FONT></P>
    <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Ryan M. 
    Hurst<o:p></o:p></SPAN></FONT></P>
    <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">ValiCert, 
    Inc.<o:p></o:p></SPAN></FONT></P>
    <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <BLOCKQUOTE style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">
      <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><I><FONT 
      face="Times New Roman" size=3><SPAN 
      style="FONT-SIZE: 12pt; FONT-STYLE: italic; mso-no-proof: yes">"It may 
      roundly be asserted that human ingenuity cannot concoct a cipher which 
      human ingenuity cannot resolve."</SPAN></FONT></I><SPAN 
      style="mso-no-proof: yes"><o:p></o:p></SPAN></P></BLOCKQUOTE>
    <BLOCKQUOTE style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">
      <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face="Times New Roman" 
      size=3><SPAN style="FONT-SIZE: 12pt; mso-no-proof: yes">-Edgar Allan 
      Poe</SPAN><o:p></o:p></FONT></P></BLOCKQUOTE>
    <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face="Times New Roman" 
    size=3><SPAN 
  style="FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></BLOCKQUOTE></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1363E.B3650960--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85JBZK04045 for ietf-pkix-bks; Wed, 5 Sep 2001 12:11:35 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85JBWD04041 for <[e-mail]>; Wed, 5 Sep 2001 12:11:32 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 5 Sep 2001 12:12:15 -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]>; Wed, 05 Sep 2001 12:12:15 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <QP4KV0JM>; Wed, 05 Sep 2001 12:05:11 -0700
Content-return: allowed
Date: Wed, 05 Sep 2001 12:05:10 -0700
From: Ryan Hurst <[e-mail]>
Subject: RE: Removing expired certificates from CRLs.....
To: "'Sharon Boeyen'" <[e-mail]>, "'Flynn, Michael'" <[e-mail]>, Ryan Hurst <[e-mail]>, IETF-PKIX <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: multipart/alternative; boundary="Boundary_(ID_xLkhTDD4+HYrWByFtJbT+w)"
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.

--Boundary_(ID_xLkhTDD4+HYrWByFtJbT+w)
Content-type: text/plain

Thanks Sharon -
 
            I guess both documents are consistent now; I must have had an
older copy of X509. Sorry for any confusion I caused; and thanks for the
great participation in the discussion ;)
 
Ryan
 
-----Original Message-----
From: Sharon Boeyen [mailto:[e-mail]] 
Sent: Wednesday, September 05, 2001 10:36 AM
To: 'Flynn, Michael'; 'Ryan Hurst'; IETF-PKIX
Subject: RE: Removing expired certificates from CRLs.....
 
I suspect some of the PKIX text was never updated to reflect the successful
ballot on the X.509 defect report that fixed this in the base X.509 text.
The approved TC for the defect (DR 204) corrected this problem by making the
following changes to X.509 (97).
 
 
Clause 12.6.3.1
 
In the first sentence following the ASN.1, delete "unexpired"
 
Add the following as a new second sentence in the first paragraph following
the ASN.1
 
"After a certificate appears on a CRL, it may be deleted from a subsequent
CRL after the certificate's expiry."
 
 
Cheers,
Sharon
 
-----Original Message-----
From: Flynn, Michael [mailto:[e-mail]]
Sent: Wednesday, September 05, 2001 1:03 PM
To: 'Ryan Hurst'; IETF-PKIX
Subject: RE: Removing expired certificates from CRLs.....
Ryan,
 
Ryan wrote::
Now logically it makes sense to remove certificates that are expired from
CRLs to control size, yes this has a negative point specifically it prevents
CRLs from being used as a non-repudiation source; but this is mute due to
many other issues.
 
At least regarding removing expired certs from CRLs, I would think that
non-repudiation can be satisfied by keeping the old CRLs in back up storage
for some length of time. That time being how far back in time a contract
dispute might go; ten years, twenty?   So long as you could get them off
tape for the lawyers to look at the legal process would be satisfied, they
don't need to be online forever.  
 
Michael
 
-----Original Message-----
From: Ryan Hurst [mailto:[e-mail]]
Sent: Tuesday, September 04, 2001 8:50 PM
To: IETF-PKIX
Subject: Removing expired certificates from CRLs.....
I was speaking with Peter Williams today about the removal of expired
certificates from CRLs; I have always been under the belief that this
behavior was optional, I vaguely remembered reading text in 2459 along those
lines; additionally I know of several commercial CAs that do not remove the
expired certificates from their CRLs. Peter on the other hand was under the
impression that it was a mandate to remove CRLs; he too remembered reading
text in 2459 to support is position.
 
So we each pulled out the RFC and found that we were both right!
Specifically both sections 3.3 and 8.6.2.2 have text on this subject:
 
3.3  Revocation
When a certificate is issued, it is expected to be in use for its entire
validity period.  However, various circumstances may cause a certificate to
become invalid prior to the expiration of the validity period.
 
....
 
An entry is added to the CRL as part of the next update following
notification of revocation. An entry may be removed from the CRL after
appearing on one regularly scheduled CRL issued beyond the revoked
certificate's validity period.
 
 
 
8.6.2.2 Issuing distribution point extension
This CRL extension field identifies the CRL distribution point for this
particular CRL, and indicates if the CRL is limited to revocations for
end-entity certificates only, for authority certificates only, or for a
limited set of reasons only. The CRL is signed by the CRL issuer's key- CRL
distribution points do not have their own key pairs. However, for a CRL
distributed via the Directory, the CRL is stored in the entry of the CRL
distribution point, which may not be the directory entry of the CRL issuer.
If this field is absent, the CRL shall contain entries for all revoked
unexpired certificates issued by the CRL issuer.
 
....
 
The distributionPoint component contains the name of the distribution point
in one or more name forms. If this field is absent, the CRL shall contain
entries for all revoked certificates issued by the CRL issuer. After a
certificate appears on a CRL, it is deleted from a subsequent CRL after the
certificate's expiry.
 
 
Although section 8.6.2.2 is specifically in regards to CRLdps, any
difference between full CRLs and CRLdps in this case I feel would be an
arbitrary one. 
 
Now logically it makes sense to remove certificates that are expired from
CRLs to control size, yes this has a negative point specifically it prevents
CRLs from being used as a non-repudiation source; but this is mute due to
many other issues.
 
That being the case I think; and I believe Peter would agree the correct
thing to do is to remove these expired/revoked entries from the CRL. 
 
The question now is what is the PKIX stance on this matter?
 
Ryan M. Hurst
ValiCert, Inc.
 
"It may roundly be asserted that human ingenuity cannot concoct a cipher
which human ingenuity cannot resolve."
-Edgar Allan Poe
 

--Boundary_(ID_xLkhTDD4+HYrWByFtJbT+w)
Content-type: text/html
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
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@01C13603.D43EECE0">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"time"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"date"/>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
   <w:UseFELayout/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;
	mso-font-alt:\5B8B\4F53;
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 135135232 16 0 262145 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 135135232 16 0 262145 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:SimSun;}
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.EmailStyle17
	{mso-style-type:personal;
	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:windowtext;}
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;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	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:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks =
</span></font><st1:City><st1:place><font
  size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
  color:navy'>Sharon</span></font></st1:place></st1:City><font size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'> -<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'><span =
style=3D'mso-tab-count:1'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; </span>I
guess both documents are consistent now; I must have had an older copy =
of X509.
Sorry for any confusion I caused; and thanks for the great =
participation in the
discussion ;)<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'>Ryan<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 style=3D'margin-left:.5in'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Sharon Boeyen
[mailto:[e-mail]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> =
</span></font><st1:date
Month=3D"9" Day=3D"5" Year=3D"2001"><font size=3D2 face=3DTahoma><span =
style=3D'font-size:
 10.0pt;font-family:Tahoma'>Wednesday, September 05, =
2001</span></font></st1:date><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'> </span></font><st1:time
Hour=3D"10" Minute=3D"36"><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
 font-family:Tahoma'>10:36 AM</span></font></st1:time><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'><br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Flynn, Michael'; =
'Ryan
Hurst'; IETF-PKIX<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Removing =
expired
certificates from CRLs.....</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dblue face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>I suspect some =
of the
PKIX text was never updated to reflect the successful ballot on =
the&nbsp;X.509
defect report that fixed this in the base X.509 text. The approved TC =
for the
defect (DR 204) corrected this problem by making the following changes =
to X.509
(97).</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<p class=3DMsoNormal style=3D'margin-left:36.55pt'><b =
style=3D'mso-bidi-font-weight:
normal'><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;
font-weight:bold;mso-bidi-font-weight:normal'>Clause =
12.6.3.1<o:p></o:p></span></font></b></p>

<p class=3DMsoNormal style=3D'margin-left:1.0in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:1.0in'><i =
style=3D'mso-bidi-font-style:
normal'><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;
font-style:italic;mso-bidi-font-style:normal'>In the first sentence =
following
the ASN.1, delete "unexpired"<o:p></o:p></span></font></i></p>

<p class=3DMsoNormal style=3D'margin-left:1.0in'><i =
style=3D'mso-bidi-font-style:
normal'><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;
font-style:italic;mso-bidi-font-style:normal'>&nbsp;<o:p></o:p></span></=
font></i></p>

<p class=3DMsoNormal style=3D'margin-left:1.0in'><i =
style=3D'mso-bidi-font-style:
normal'><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;
font-style:italic;mso-bidi-font-style:normal'>Add the following as a =
new second
sentence in the first paragraph following the =
ASN.1<o:p></o:p></span></font></i></p>

<p class=3DMsoNormal style=3D'margin-left:1.0in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt'>"After a certificate appears on a CRL, it =
may be
deleted from a subsequent CRL after the certificate's =
expiry."<o:p></o:p></span></font></p>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
color=3Dblue
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:blue'>Cheers,</span></font><o:p></o:p></=
p>

</div>

<div>

<p class=3DMsoNormal =
style=3D'margin-left:.5in'><st1:City><st1:place><font size=3D3
  color=3Dblue face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:blue'>Sharon</span></font></st1:place></=
st1:City><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
color=3Dblue
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:blue'>&nbsp;</span></font><o:p></o:p></p=
>

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0in 0in 0in 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt=
'>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:0in;margin-right:0in;margin-bottom:
12.0pt;margin-left:.5in'><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma'>-----Original Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Flynn, Michael
[mailto:[e-mail]]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> =
</span></font><st1:date
Month=3D"9" Day=3D"5" Year=3D"2001"><font size=3D2 face=3DTahoma><span =
style=3D'font-size:
 10.0pt;font-family:Tahoma'>Wednesday, September 05, =
2001</span></font></st1:date><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'> </span></font><st1:time
Hour=3D"13" Minute=3D"3"><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
 font-family:Tahoma'>1:03 PM</span></font></st1:time><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'><br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Ryan Hurst'; =
IETF-PKIX<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Removing =
expired
certificates from CRLs.....</span></font><o:p></o:p></p>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>Ryan,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Ryan =
wrote::<o:p></o:p></span></font></p>

</div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Now logically it makes =
sense to
remove certificates that are expired from CRLs to control size, yes =
this has a
negative point specifically it prevents CRLs from being used as a
non-repudiation source; but this is mute due to many other =
issues.</span></font><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>At least regarding =
removing expired
certs from CRLs, I would think that non-repudiation can be satisfied by =
keeping
the old CRLs in back up storage for some length of time. That time =
being how
far back in time a contract dispute might go; ten years, twenty? &nbsp; =
So long
as you could get them off&nbsp; tape for the lawyers to look at the =
legal
process would be satisfied, they don't need to be online forever.&nbsp; =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></=
p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Michael<o:p></o:p></span></=
font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></=
p>

<blockquote style=3D'border:none;border-left:solid black =
1.5pt;padding:0in 0in 0in 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt=
'>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:0in;margin-right:0in;margin-bottom:
12.0pt;margin-left:.5in'><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma'>-----Original Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Ryan Hurst
[mailto:[e-mail]]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, September =
04, 2001
8:50 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> IETF-PKIX<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Removing =
expired
certificates from CRLs.....</span></font><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>I was speaking with =
</span></font><st1:PersonName><font
 size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Peter
 Williams</span></font></st1:PersonName><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'> today about the removal =
of expired
certificates from CRLs; I have always been under the belief that this =
behavior
was optional, I vaguely remembered reading text in 2459 along those =
lines;
additionally I know of several commercial CAs that do not remove the =
expired
certificates from their CRLs. Peter on the other hand was under the =
impression
that it was a mandate to remove CRLs; he too remembered reading text in =
2459 to
support is position.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></f=
ont></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>So we each pulled out the =
RFC and
found that we were both right! Specifically both sections 3.3 and =
8.6.2.2 have
text on this subject:<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></f=
ont></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;tab-stops:45.8pt 91.6pt =
137.4pt 183.2pt 229.0pt 274.8pt 320.6pt 366.4pt 412.2pt 458.0pt 503.8pt =
549.6pt 595.4pt 641.2pt 687.0pt 732.8pt;
mso-layout-grid-align:none'><b =
style=3D'mso-bidi-font-weight:normal'><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;font-weight:
bold;mso-bidi-font-weight:normal'>3.3<span =
style=3D'mso-spacerun:yes'>&nbsp;
</span>Revocation<o:p></o:p></span></font></b></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;tab-stops:45.8pt 91.6pt =
137.4pt 183.2pt 229.0pt 274.8pt 320.6pt 366.4pt 412.2pt 458.0pt 503.8pt =
549.6pt 595.4pt 641.2pt 687.0pt 732.8pt;
mso-layout-grid-align:none'><font size=3D2 face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial'>When a certificate is issued, it is expected =
to be in
use for its entire validity period.<span =
style=3D'mso-spacerun:yes'>&nbsp;
</span>However, various circumstances may cause a certificate to become =
invalid
prior to the expiration of the validity =
period.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;tab-stops:45.8pt 91.6pt =
137.4pt 183.2pt 229.0pt 274.8pt 320.6pt 366.4pt 412.2pt 458.0pt 503.8pt =
549.6pt 595.4pt 641.2pt 687.0pt 732.8pt;
mso-layout-grid-align:none'><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 =
style=3D'margin-left:.5in;mso-layout-grid-align:none'><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>....<o:p></o:p></span></fon=
t></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;mso-layout-grid-align:none'><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></f=
ont></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;tab-stops:45.8pt 91.6pt =
137.4pt 183.2pt 229.0pt 274.8pt 320.6pt 366.4pt 412.2pt 458.0pt 503.8pt =
549.6pt 595.4pt 641.2pt 687.0pt 732.8pt;
mso-layout-grid-align:none'><font size=3D2 face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial'>An entry is added to the CRL as part of the =
next
update following notification of revocation. <b><i><span =
style=3D'font-weight:
bold;font-style:italic'>An entry may be removed from the CRL after =
appearing on
one regularly scheduled CRL issued beyond the revoked certificate's =
validity
period.</span></i></b><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></f=
ont></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></f=
ont></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></f=
ont></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;mso-layout-grid-align:none'><b><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;font-weight:
bold'>8.6.2.2 Issuing distribution point =
extension<o:p></o:p></span></font></b></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;mso-layout-grid-align:none'><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>This CRL
extension field identifies the CRL distribution point for this =
particular CRL,
and indicates if the CRL is limited to revocations for end-entity =
certificates
only, for authority certificates only, or for a limited set of reasons =
only.
The CRL is signed by the CRL issuer's key- CRL distribution points do =
not have
their own key pairs. However, for a CRL distributed via the Directory, =
the CRL
is stored in the entry of the CRL distribution point, which may not be =
the
directory entry of the CRL issuer.<i><span style=3D'font-style:italic'> =
<b><span
style=3D'font-weight:bold'>If this field is absent, the CRL shall =
contain entries
for all revoked unexpired certificates issued by the CRL =
issuer.</span></b><o:p></o:p></span></i></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;mso-layout-grid-align:none'><i><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;font-style:
italic'><o:p>&nbsp;</o:p></span></font></i></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;mso-layout-grid-align:none'><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>....<o:p></o:p></span></fon=
t></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;mso-layout-grid-align:none'><font
size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:blue'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;mso-layout-grid-align:none'><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>The </span></font><b><font
size=3D1 face=3DArial><span =
style=3D'font-size:9.0pt;font-family:Arial;font-weight:
bold'>distributionPoint </span></font></b><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>component contains the =
name of the
distribution point in one or more name forms. If this field is absent, =
the CRL
shall contain entries for all revoked certificates issued by the CRL =
issuer. <b><i><span
style=3D'font-weight:bold;font-style:italic'>After a certificate =
appears on a CRL,
it is deleted from a subsequent CRL after the certificate's =
expiry.<o:p></o:p></span></i></b></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></f=
ont></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></f=
ont></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Although section 8.6.2.2 =
is
specifically in regards to CRLdps, any difference between full CRLs and =
CRLdps
in this case I feel would be an arbitrary one. =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></f=
ont></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Now logically it makes =
sense to
remove certificates that are expired from CRLs to control size, yes =
this has a
negative point specifically it prevents CRLs from being used as a
non-repudiation source; but this is mute due to many other =
issues.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></f=
ont></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>That being the case I =
think; and I
believe Peter would agree the correct thing to do is to remove these
expired/revoked entries from the CRL. <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></f=
ont></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>The question now is what =
is the PKIX
stance on this matter?<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></f=
ont></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Ryan M. =
Hurst<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>ValiCert, =
Inc.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></f=
ont></p>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>

<p class=3DMsoNormal style=3D'margin-left:.5in'><i><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;font-style:italic;
mso-no-proof:yes'>&quot;It may roundly be asserted that human ingenuity =
cannot
concoct a cipher which human ingenuity cannot =
resolve.&quot;</span></font></i><span
style=3D'mso-no-proof:yes'><o:p></o:p></span></p>

</blockquote>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt;mso-no-proof:yes'>-Edgar Allan =
Poe</span><o:p></o:p></font></p>

</blockquote>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</blockquote>

</blockquote>

</div>

</body>

</html>

--Boundary_(ID_xLkhTDD4+HYrWByFtJbT+w)--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85J8VS03910 for ietf-pkix-bks; Wed, 5 Sep 2001 12:08:31 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85J8TD03905 for <[e-mail]>; Wed, 5 Sep 2001 12:08:29 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 5 Sep 2001 12:09:12 -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]>; Wed, 05 Sep 2001 12:09:12 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <QP4KV02Z>; Wed, 05 Sep 2001 12:02:08 -0700
Content-return: allowed
Date: Wed, 05 Sep 2001 12:02:07 -0700
From: Ryan Hurst <[e-mail]>
Subject: RE: Removing expired certificates from CRLs.....
To: "'Flynn, Michael'" <[e-mail]>, Ryan Hurst <[e-mail]>, IETF-PKIX <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: multipart/alternative; boundary="Boundary_(ID_5o83KWaDDNRlwIiBIh7UyQ)"
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.

--Boundary_(ID_5o83KWaDDNRlwIiBIh7UyQ)
Content-type: text/plain

Michael -
            In regards to storing all generated CRLs for n period of time to
address the non-repudiation issues; yes this would deal with the problem.
However CRL validity windows commonly overlap; so determining how would some
one know (without CRLNumbers which most CAs do not include yet) if they had
them all? Additionally the process of looking at ALL CRLs and determining
which one is the "most recent" match would be an expensive one.
 
For these reasons it would be "nice" if CRLs were only used by servers and
contained all revoked certificates; but this means that clients would not
want to use CRLs due to the expense associated with acquiring the recent
CRL.
 
I believe the overall goal of CRLs was not to deal with NR, but to instead
have a simple mechanism to distribute bulk "current" revocation information
to the broadest set of clients. For this reason; I think its best to remove
the expired certificates and deal with NR through another mechanism,
probably service based.
 
After reading every ones posts on this topic, I guess I do not think we
should mandate the removal of the entries; we may wish recommend this be
done though. This of coarse is a mute point due to the last-call already
taking place ;)
 
Ryan
 
-----Original Message-----
From: Flynn, Michael [mailto:[e-mail]] 
Sent: Wednesday, September 05, 2001 10:03 AM
To: 'Ryan Hurst'; IETF-PKIX
Subject: RE: Removing expired certificates from CRLs.....
 
Ryan,
 
Ryan wrote::
Now logically it makes sense to remove certificates that are expired from
CRLs to control size, yes this has a negative point specifically it prevents
CRLs from being used as a non-repudiation source; but this is mute due to
many other issues.
 
At least regarding removing expired certs from CRLs, I would think that
non-repudiation can be satisfied by keeping the old CRLs in back up storage
for some length of time. That time being how far back in time a contract
dispute might go; ten years, twenty?   So long as you could get them off
tape for the lawyers to look at the legal process would be satisfied, they
don't need to be online forever.  
 
Michael
 
-----Original Message-----
From: Ryan Hurst [mailto:[e-mail]]
Sent: Tuesday, September 04, 2001 8:50 PM
To: IETF-PKIX
Subject: Removing expired certificates from CRLs.....
I was speaking with Peter Williams today about the removal of expired
certificates from CRLs; I have always been under the belief that this
behavior was optional, I vaguely remembered reading text in 2459 along those
lines; additionally I know of several commercial CAs that do not remove the
expired certificates from their CRLs. Peter on the other hand was under the
impression that it was a mandate to remove CRLs; he too remembered reading
text in 2459 to support is position.
 
So we each pulled out the RFC and found that we were both right!
Specifically both sections 3.3 and 8.6.2.2 have text on this subject:
 
3.3  Revocation
When a certificate is issued, it is expected to be in use for its entire
validity period.  However, various circumstances may cause a certificate to
become invalid prior to the expiration of the validity period.
 
....
 
An entry is added to the CRL as part of the next update following
notification of revocation. An entry may be removed from the CRL after
appearing on one regularly scheduled CRL issued beyond the revoked
certificate's validity period.
 
 
 
8.6.2.2 Issuing distribution point extension
This CRL extension field identifies the CRL distribution point for this
particular CRL, and indicates if the CRL is limited to revocations for
end-entity certificates only, for authority certificates only, or for a
limited set of reasons only. The CRL is signed by the CRL issuer's key- CRL
distribution points do not have their own key pairs. However, for a CRL
distributed via the Directory, the CRL is stored in the entry of the CRL
distribution point, which may not be the directory entry of the CRL issuer.
If this field is absent, the CRL shall contain entries for all revoked
unexpired certificates issued by the CRL issuer.
 
....
 
The distributionPoint component contains the name of the distribution point
in one or more name forms. If this field is absent, the CRL shall contain
entries for all revoked certificates issued by the CRL issuer. After a
certificate appears on a CRL, it is deleted from a subsequent CRL after the
certificate's expiry.
 
 
Although section 8.6.2.2 is specifically in regards to CRLdps, any
difference between full CRLs and CRLdps in this case I feel would be an
arbitrary one. 
 
Now logically it makes sense to remove certificates that are expired from
CRLs to control size, yes this has a negative point specifically it prevents
CRLs from being used as a non-repudiation source; but this is mute due to
many other issues.
 
That being the case I think; and I believe Peter would agree the correct
thing to do is to remove these expired/revoked entries from the CRL. 
 
The question now is what is the PKIX stance on this matter?
 
Ryan M. Hurst
ValiCert, Inc.
 
"It may roundly be asserted that human ingenuity cannot concoct a cipher
which human ingenuity cannot resolve."
-Edgar Allan Poe
 

--Boundary_(ID_5o83KWaDDNRlwIiBIh7UyQ)
Content-type: text/html
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
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@01C13603.66FB6DC0">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"time"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"date"/>
<!--[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:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
   <w:UseFELayout/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;
	mso-font-alt:\5B8B\4F53;
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 135135232 16 0 262145 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 135135232 16 0 262145 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:SimSun;}
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.EmailStyle17
	{mso-style-type:personal;
	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:windowtext;}
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:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	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:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Michael =
-<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-tab-count:1'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; </span>In
regards to storing all generated CRLs for <i =
style=3D'mso-bidi-font-style:normal'><span
style=3D'font-style:italic;mso-bidi-font-style:normal'>n =
</span></i>period of
time to address the non-repudiation issues; yes this would deal with =
the
problem. However CRL validity windows commonly overlap; so determining =
how
would some one know (without CRLNumbers which most CAs do not include =
yet) if
they had them all? Additionally the process of looking at ALL CRLs and
determining which one is the "most recent" match would be an
expensive one.<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'>For these reasons it would be =
"nice"
if CRLs were only used by servers and contained all revoked =
certificates; but
this means that clients would not want to use CRLs due to the expense
associated with acquiring the recent CRL.<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'>I believe the overall goal of CRLs =
was not
to deal with NR, but to instead have a simple mechanism to distribute =
bulk "current"
revocation information to the broadest set of clients. For this reason; =
I think
its best to remove the expired certificates and deal with NR through =
another mechanism,
probably service based.<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'>After reading every ones posts on =
this
topic, I guess I do not think we should mandate the removal of the =
entries; we
may wish recommend this be done though. This of coarse is a mute point =
due to
the last-call already taking place ;)<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'>Ryan<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 style=3D'margin-left:.5in'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Flynn, Michael
[mailto:[e-mail]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> =
</span></font><st1:date
Month=3D"9" Day=3D"5" Year=3D"2001"><font size=3D2 face=3DTahoma><span =
style=3D'font-size:
 10.0pt;font-family:Tahoma'>Wednesday, September 05, =
2001</span></font></st1:date><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'> </span></font><st1:time
Hour=3D"10" Minute=3D"3"><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
 font-family:Tahoma'>10:03 AM</span></font></st1:time><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'><br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Ryan Hurst'; =
IETF-PKIX<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Removing =
expired
certificates from CRLs.....</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>Ryan,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Ryan =
wrote::<o:p></o:p></span></font></p>

</div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Now logically it makes =
sense to
remove certificates that are expired from CRLs to control size, yes =
this has a
negative point specifically it prevents CRLs from being used as a
non-repudiation source; but this is mute due to many other =
issues.</span></font><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>At least regarding =
removing expired
certs from CRLs, I would think that non-repudiation can be satisfied by =
keeping
the old CRLs in back up storage for some length of time. That time =
being how
far back in time a contract dispute might go; ten years, twenty? &nbsp; =
So long
as you could get them off&nbsp; tape for the lawyers to look at the =
legal
process would be satisfied, they don't need to be online forever.&nbsp; =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></=
p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Michael<o:p></o:p></span></=
font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></=
p>

<blockquote style=3D'border:none;border-left:solid black =
1.5pt;padding:0in 0in 0in 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt=
'>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:0in;margin-right:0in;margin-bottom:
12.0pt;margin-left:.5in'><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma'>-----Original Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Ryan Hurst
[mailto:[e-mail]]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, September =
04, 2001
8:50 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> IETF-PKIX<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Removing =
expired
certificates from CRLs.....</span></font><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>I was speaking with =
</span></font><st1:PersonName><font
 size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Peter
 Williams</span></font></st1:PersonName><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'> today about the removal =
of expired
certificates from CRLs; I have always been under the belief that this =
behavior
was optional, I vaguely remembered reading text in 2459 along those line=
s;
additionally I know of several commercial CAs that do not remove the =
expired
certificates from their CRLs. Peter on the other hand was under the =
impression
that it was a mandate to remove CRLs; he too remembered reading text in =
2459 to
support is position.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></f=
ont></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>So we each pulled out the =
RFC and
found that we were both right! Specifically both sections 3.3 and =
8.6.2.2 have
text on this subject:<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></f=
ont></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;tab-stops:45.8pt 91.6pt =
137.4pt 183.2pt 229.0pt 274.8pt 320.6pt 366.4pt 412.2pt 458.0pt 503.8pt =
549.6pt 595.4pt 641.2pt 687.0pt 732.8pt;
mso-layout-grid-align:none'><b =
style=3D'mso-bidi-font-weight:normal'><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;font-weight:
bold;mso-bidi-font-weight:normal'>3.3<span =
style=3D'mso-spacerun:yes'>&nbsp;
</span>Revocation<o:p></o:p></span></font></b></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;tab-stops:45.8pt 91.6pt =
137.4pt 183.2pt 229.0pt 274.8pt 320.6pt 366.4pt 412.2pt 458.0pt 503.8pt =
549.6pt 595.4pt 641.2pt 687.0pt 732.8pt;
mso-layout-grid-align:none'><font size=3D2 face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial'>When a certificate is issued, it is expected =
to be in
use for its entire validity period.<span =
style=3D'mso-spacerun:yes'>&nbsp;
</span>However, various circumstances may cause a certificate to become =
invalid
prior to the expiration of the validity =
period.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;tab-stops:45.8pt 91.6pt =
137.4pt 183.2pt 229.0pt 274.8pt 320.6pt 366.4pt 412.2pt 458.0pt 503.8pt =
549.6pt 595.4pt 641.2pt 687.0pt 732.8pt;
mso-layout-grid-align:none'><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 =
style=3D'margin-left:.5in;mso-layout-grid-align:none'><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>....<o:p></o:p></span></fon=
t></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;mso-layout-grid-align:none'><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></f=
ont></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;tab-stops:45.8pt 91.6pt =
137.4pt 183.2pt 229.0pt 274.8pt 320.6pt 366.4pt 412.2pt 458.0pt 503.8pt =
549.6pt 595.4pt 641.2pt 687.0pt 732.8pt;
mso-layout-grid-align:none'><font size=3D2 face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial'>An entry is added to the CRL as part of the =
next
update following notification of revocation. <b><i><span =
style=3D'font-weight:
bold;font-style:italic'>An entry may be removed from the CRL after =
appearing on
one regularly scheduled CRL issued beyond the revoked certificate's =
validity
period.</span></i></b><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></f=
ont></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></f=
ont></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></f=
ont></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;mso-layout-grid-align:none'><b><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;font-weight:
bold'>8.6.2.2 Issuing distribution point =
extension<o:p></o:p></span></font></b></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;mso-layout-grid-align:none'><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>This CRL
extension field identifies the CRL distribution point for this =
particular CRL,
and indicates if the CRL is limited to revocations for end-entity =
certificates
only, for authority certificates only, or for a limited set of reasons =
only.
The CRL is signed by the CRL issuer's key- CRL distribution points do =
not have
their own key pairs. However, for a CRL distributed via the Directory, =
the CRL
is stored in the entry of the CRL distribution point, which may not be =
the
directory entry of the CRL issuer.<i><span style=3D'font-style:italic'> =
<b><span
style=3D'font-weight:bold'>If this field is absent, the CRL shall =
contain entries
for all revoked unexpired certificates issued by the CRL =
issuer.</span></b><o:p></o:p></span></i></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;mso-layout-grid-align:none'><i><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;font-style:
italic'><o:p>&nbsp;</o:p></span></font></i></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;mso-layout-grid-align:none'><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>....<o:p></o:p></span></fon=
t></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;mso-layout-grid-align:none'><font
size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:blue'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;mso-layout-grid-align:none'><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>The </span></font><b><font
size=3D1 face=3DArial><span =
style=3D'font-size:9.0pt;font-family:Arial;font-weight:
bold'>distributionPoint </span></font></b><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>component contains the =
name of the
distribution point in one or more name forms. If this field is absent, =
the CRL
shall contain entries for all revoked certificates issued by the CRL =
issuer. <b><i><span
style=3D'font-weight:bold;font-style:italic'>After a certificate =
appears on a
CRL, it is deleted from a subsequent CRL after the certificate's =
expiry.<o:p></o:p></span></i></b></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></f=
ont></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></f=
ont></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Although section 8.6.2.2 =
is
specifically in regards to CRLdps, any difference between full CRLs and =
CRLdps
in this case I feel would be an arbitrary one. =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></f=
ont></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Now logically it makes =
sense to
remove certificates that are expired from CRLs to control size, yes =
this has a
negative point specifically it prevents CRLs from being used as a
non-repudiation source; but this is mute due to many other =
issues.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></f=
ont></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>That being the case I =
think; and I
believe Peter would agree the correct thing to do is to remove these
expired/revoked entries from the CRL. <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></f=
ont></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'>The question now is what =
is the PKIX
stance on this matter?<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></f=
ont></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Ryan M. =
Hurst<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>ValiCert, =
Inc.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></f=
ont></p>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>

<p class=3DMsoNormal style=3D'margin-left:.5in'><i><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;font-style:italic;
mso-no-proof:yes'>&quot;It may roundly be asserted that human ingenuity =
cannot
concoct a cipher which human ingenuity cannot =
resolve.&quot;</span></font></i><span
style=3D'mso-no-proof:yes'><o:p></o:p></span></p>

</blockquote>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt;mso-no-proof:yes'>-Edgar Allan =
Poe</span><o:p></o:p></font></p>

</blockquote>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</blockquote>

</div>

</body>

</html>

--Boundary_(ID_5o83KWaDDNRlwIiBIh7UyQ)--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85IxW603629 for ietf-pkix-bks; Wed, 5 Sep 2001 11:59:32 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85IxVD03625 for <[e-mail]>; Wed, 5 Sep 2001 11:59:31 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 5 Sep 2001 12:00:14 -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]>; Wed, 05 Sep 2001 12:00:13 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <QP4KV0HC>; Wed, 05 Sep 2001 11:53:10 -0700
Content-return: allowed
Date: Wed, 05 Sep 2001 11:53:08 -0700
From: Ryan Hurst <[e-mail]>
Subject: RE: Removing expired certificates from CRLs.....
To: "'Denis Pinkas'" <[e-mail]>, Nada Kapidzic Cicovic <[e-mail]>
Cc: Ryan Hurst <[e-mail]>, IETF-PKIX <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain
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>

Apologies --

	Looks like I jumped to an assumption in regards to the origin of the
8.6.2.2 text I quoted, apparently it did not come from 2459; instead it came
from x509 v4. That being the case I guess that 2549 is not inconsistent as I
originally stated.

That being said shouldn't these two sources be consistent?

Ryan

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Wednesday, September 05, 2001 6:22 AM
To: Nada Kapidzic Cicovic
Cc: Ryan Hurst; IETF-PKIX
Subject: Re: Removing expired certificates from CRLs.....


Nada,

Which text are using using ? In son-of-RC2459 there is no section 8.6.2.2.
as you indicate.

Please be more specific on the exact sentence that you think is not
appropriate in son-of-RC2459 and which exact change you would like to be
done.

Denis

 
> >Nada and Ryan,
> >
> > > Ryan,
> > >
> > > Some years ago we at Entegrity also had similar discussion. We were
> > > positive CRLs were not to contain the information about the expired
> > > certificates, until we came across some industry CA CRLs containing
> > > information about all revoked certificates. We then looked into 2459
> > > (draft in those days) and X.509 text and came to the conclusion that
> > > deleting info about expired certificates from a CRL is only an option.
> > >
> > > I am not sure what was the intention of the original authors of X.509
> > > (perhaps Sharon and Hoyt know more about it), but the current industry
> > > practice seems to be a mixture of both approaches.
> >
> >At the very beginning, when ISO started the work, non-repudiation was not
> >considered, but only authentication and data origin authentication.
> >
> > > My personal opinion is that keeping all revoked certificates info in
CRLs
> > > brings more problems than benefits. However, it is questionable
whether
> > > PKIX needs to take a vote for one approach or the other.
> > >
> > > In any case I would suggest that the text of 2459 be modified so that
it
> > > has a MAY (or a MUST) consistently in all places where deleting
expired
> > > certificates revocation info from CRLs is mentioned. The current text
only
> > > brings confusion, as you have already pointed out.
> >
> >In all the sentences that have been extracted below, I could not find a
> >place where a change would be necessary. So I believe that the current
text
> >is OK : it tells how long revoked certificates MUST be kept in a CRL but
> >does not forbid to maintain them longer. I agree that maintaining them
too
> 
> The text in 8.6.2.2 does not mention the possibility of leaving the
expired
> certificates identifiers in CRL. The last extracted sentence is very
> explicit in requiring removal of revocation info for expired certificates.
> 
> >long would be a problem because of the increasing size of the CRL, hence
why
> >CRL information should be captured when still available, in case a
> >non-repudiation service is supported.
> 
> I could not agree more. Perhaps DPV/DPD work could include such
guidelines.
> 
> >We could add is a recommendation like: "Certificates identifiers
> >for certificates that contain the NR bit in the KeyUsage extension field
> >SHOULD be maintained in a CRL a few days or weeks after they have
expired."
> >
> >However, it seems rather late to add such a sentence, since we passed
IETF
> >last call. I leave the issue to the editors ...
> 
> You are right. Since the document has already progressed this far, it may
> not be worth making additional modifications.
> 
> Nada
> 
> >Denis
> >
> >
> > > Nada
> > >
> > > At 08:49 PM 9/4/01 -0700, Ryan Hurst wrote:
> > >
> > > > I was speaking with Peter Williams today about the removal of
expired
> > > > certificates from CRLs; I have always been under the belief that
this
> > > > behavior was optional, I vaguely remembered reading text in 2459
along
> > > > those lines; additionally I know of several commercial CAs that do
not
> > > > remove the expired certificates from their CRLs. Peter on the other
hand
> > > > was under the impression that it was a mandate to remove CRLs; he
too
> > > > remembered reading text in 2459 to support is position.
> > > >
> > > >
> > > >
> > > > So we each pulled out the RFC and found that we were both right!
> > > > Specifically both sections 3.3 and 8.6.2.2 have text on this
subject:
> > > >
> > > >
> > > >
> > > > 3.3  Revocation
> > > >
> > > > When a certificate is issued, it is expected to be in use for its
entire
> > > > validity period.  However, various circumstances may cause a
certificate
> > > > to become invalid prior to the expiration of the validity period.
> > > >
> > > >
> > > >
> > > > ....
> > > >
> > > >
> > > >
> > > > An entry is added to the CRL as part of the next update following
> > > > notification of revocation. An entry may be removed from the CRL
after
> > > > appearing on one regularly scheduled CRL issued beyond the revoked
> > > > certificate's validity period.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > 8.6.2.2 Issuing distribution point extension
> > > >
> > > > This CRL extension field identifies the CRL distribution point for
this
> > > > particular CRL, and indicates if the CRL is limited to revocations
for
> > > > end-entity certificates only, for authority certificates only, or
for a
> > > > limited set of reasons only. The CRL is signed by the CRL issuer's
key-
> > > > CRL distribution points do not have their own key pairs. However,
for a
> > > > CRL distributed via the Directory, the CRL is stored in the entry of
the
> > > > CRL distribution point, which may not be the directory entry of the
CRL
> > > > issuer. If this field is absent, the CRL shall contain entries for
all
> > > > revoked unexpired certificates issued by the CRL issuer.
> > > >
> > > >
> > > >
> > > > ....
> > > >
> > > >
> > > >
> > > > The distributionPoint component contains the name of the
distribution
> > > > point in one or more name forms. If this field is absent, the CRL
shall
> > > > contain entries for all revoked certificates issued by the CRL
issuer.
> > > > After a certificate appears on a CRL, it is deleted from a
subsequent
> > > > CRL after the certificate's expiry.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Although section 8.6.2.2 is specifically in regards to CRLdps, any
> > > > difference between full CRLs and CRLdps in this case I feel would be
an
> > > > arbitrary one.
> > > >
> > > >
> > > >
> > > > Now logically it makes sense to remove certificates that are expired
> > > > from CRLs to control size, yes this has a negative point
specifically it
> > > > prevents CRLs from being used as a non-repudiation source; but this
is
> > > > mute due to many other issues.
> > > >
> > > >
> > > >
> > > > That being the case I think; and I believe Peter would agree the
correct
> > > > thing to do is to remove these expired/revoked entries from the CRL.
> > > >
> > > >
> > > >
> > > > The question now is what is the PKIX stance on this matter?
> > > >
> > > >
> > > >
> > > > Ryan M. Hurst
> > > >
> > > > ValiCert, Inc.
> > > >
> > > >
> > > >
> > > >      "It may roundly be asserted that human ingenuity cannot concoct
a
> > > >      cipher which human ingenuity cannot resolve."
> > > >      -Edgar Allan Poe
> > > >
> > > >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85IxH503620 for ietf-pkix-bks; Wed, 5 Sep 2001 11:59:17 -0700 (PDT)
Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85IxGD03616 for <[e-mail]>; Wed, 5 Sep 2001 11:59:16 -0700 (PDT)
Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id MAA23475; Wed, 5 Sep 2001 12:02:23 -0700 (PDT)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2653.19) id <R5Q7WT85>; Wed, 5 Sep 2001 11:59:08 -0700
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'Steve Hanna'" <[e-mail]>, Bob Jueneman <[e-mail]>
Cc: "Hallam-Baker, Phillip" <[e-mail]>, [e-mail]
Subject: RE: charter revisions
Date: Wed, 5 Sep 2001 11:59:04 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1363C.D5133CF0"
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_000_01C1363C.D5133CF0
Content-Type: text/plain;
	charset="iso-8859-1"


> Bob Jueneman wrote:
> > I wasn't suggesting that logos should be restricted to end-entities,
> > I was only pointing out that such a restriction would immediately
> > make the issue of name subordination and misuse of the logo by some
> > intermediate CA go away.
> 
> This isn't true. Name constraints allow me to cross certify 
> IBM's CA but
> indicate that the only DNs it is trusted to certify are those 
> that begin
> with "c=us, o=IBM". Even if logos are restricted to end-entities,
> there's nothing stopping IBM's CA from placing a Sun logo in an
> end-entity certificate. So restricting logos to end-entities doesn't
> "make the issue of name subordination and misuse of the logo by some
> intermediate CA go away."

I don't see this as a problem for several reasons:

1) Logotypes have utility even if they cannot be used with 
cross-certification.

2) The security of the infrastructure depends on the DNS system and
not the X.500 name system. The fact that the name is constrained as
you state does not in practice affect Internet applications. It might
affect OSI applications if any existed.

3) The objection is simply a restatement of the proposition that
'bad things happen if you cross certify with someone who
is not trustworthy'. This is not news.


> Apparently, you haven't read the draft that serves as the 
> basis for this
> discussion, draft-ietf-pkix-logotypes-00.txt. The suggested 
> format is a
> message digest and a URL.

The basis for this discussion is the proposed charter ammendments.

		Phill


------_=_NextPart_000_01C1363C.D5133CF0
Content-Type: application/octet-stream;
	name="Phillip Hallam-Baker (E-mail).vcf"
Content-Disposition: attachment;
	filename="Phillip Hallam-Baker (E-mail).vcf"

BEGIN:VCARD
VERSION:2.1
N:Hallam-Baker;Phillip
FN:Phillip Hallam-Baker (E-mail)
ORG:VeriSign
TITLE:Principal Consultant
TEL;WORK;VOICE:[phone] x227
EMAIL;PREF;INTERNET:[e-mail]
REV:20010214T163732Z
END:VCARD

------_=_NextPart_000_01C1363C.D5133CF0--


Received: by above.proper.com (8.11.6/8.11.3) id f85ICPV02709 for ietf-pkix-bks; Wed, 5 Sep 2001 11:12:25 -0700 (PDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85ICND02705 for <[e-mail]>; Wed, 5 Sep 2001 11:12:23 -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 MAA22557; Wed, 5 Sep 2001 12:12:21 -0600 (MDT)
Received: from sun.com (dhcp75-167 [129.148.75.167]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA05595; Wed, 5 Sep 2001 14:12:23 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 05 Sep 2001 14:12:02 -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: Bob Jueneman <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: charter revisions
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:
> I wasn't suggesting that logos should be restricted to end-entities,
> I was only pointing out that such a restriction would immediately
> make the issue of name subordination and misuse of the logo by some
> intermediate CA go away.

This isn't true. Name constraints allow me to cross certify IBM's CA but
indicate that the only DNs it is trusted to certify are those that begin
with "c=us, o=IBM". Even if logos are restricted to end-entities,
there's nothing stopping IBM's CA from placing a Sun logo in an
end-entity certificate. So restricting logos to end-entities doesn't
"make the issue of name subordination and misuse of the logo by some
intermediate CA go away."

> (BTW, someone informed me that null crypto, e.g., plaintext, is a
> valid option in SSL, and worse yet, that if that option were
> selected because it was all that was available, the padlock icon
> would still appear and the https requirement for SSL security would
> be satisfied.  Can anyone confirm that?)

I don't know about Internet Explorer, but Netscape Communicator 4.75 has
a checkbox under Security Preferences (accessed by clicking the
Navigator tab on the left and the Configure SSLv3 button) that allows
the user to enable "No encryption with an MD5 MAC". This checkbox is NOT
checked by default. I expect that this means that support for
Communicator will REJECT SSL connections with authentication but no
encryption, unless the user explicitly configures it otherwise. This
seems like reasonable behavior.

Phillip Hallam-Baker wrote:
> Another issue is size. I don't much want to see the size of
> certificates increase yet further. Perhaps a hash of the image
> and a URL would be preferable. Perhaps something a bit more.

Bob Jueneman wrote:
> I also like your suggestion of a URL and a message digest, rather
> than attempting to transport the entire logo itself within the
> certificate.

Apparently, you haven't read the draft that serves as the basis for this
discussion, draft-ietf-pkix-logotypes-00.txt. The suggested format is a
message digest and a URL.

-Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85HwQw02419 for ietf-pkix-bks; Wed, 5 Sep 2001 10:58:26 -0700 (PDT)
Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [129.83.20.90]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85HwND02415 for <[e-mail]>; Wed, 5 Sep 2001 10:58:23 -0700 (PDT)
Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id f85HvZc25138; Wed, 5 Sep 2001 13:57:36 -0400 (EDT)
Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id f85HvYf15902; Wed, 5 Sep 2001 13:57:35 -0400 (EDT)
Received: from schaen-pc.mitre.org (128.29.162.49) by mailhub1.mitre.org with SMTP id 7524958; Wed, 05 Sep 2001 13:57:18 -0400
Message-ID: <[e-mail]>
Date: Wed, 05 Sep 2001 13:59:37 -0400
From: Sam Schaen <[e-mail]>
Organization: The MITRE Corporation
X-Mailer: Mozilla 4.76 [en]C-20010313M  (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Flynn, Michael" <[e-mail]>
CC: "'Ryan Hurst'" <[e-mail]>, IETF-PKIX <[e-mail]>
Subject: Re: Removing expired certificates from 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>

For what it's worth, the US DOD PKI is relying on the archival strategy
described below.  We're currently looking at 10.5 years for our Class 3
and 20.5 years for our class 4.  I have no idea why someone considered
the extra half year important but that's what's in our CP.  Certificates
will be removed from the CRL after they expire.

Sam Schaen
MITRE Corporation

"Flynn, Michael" wrote:

> Ryan,Ryan wrote::
> Now logically it makes sense to remove certificates that are expired
> from CRLs to control size, yes this has a negative point specifically
> it prevents CRLs from being used as a non-repudiation source; but this
> is mute due to many other issues.
>
> At least regarding removing expired certs from CRLs, I would think
> that non-repudiation can be satisfied by keeping the old CRLs in back
> up storage for some length of time.  That time being how far back in
> time a contract dispute might go; ten years, twenty?   So long as you
> could get them off  tape for the lawyers to look at the legal process
> would be satisfied, they don't need to be online forever.
>
> Michael
>
>
>      -----Original Message-----
>      From: Ryan Hurst [mailto:[e-mail]]
>      Sent: Tuesday, September 04, 2001 8:50 PM
>      To: IETF-PKIX
>      Subject: Removing expired certificates from CRLs.....
>
>      I was speaking with Peter Williams today about the removal
>      of expired certificates from CRLs; I have always been under
>      the belief that this behavior was optional, I vaguely
>      remembered reading text in 2459 along those lines;
>      additionally I know of several commercial CAs that do not
>      remove the expired certificates from their CRLs. Peter on
>      the other hand was under the impression that it was a
>      mandate to remove CRLs; he too remembered reading text in
>      2459 to support is position.
>
>      So we each pulled out the RFC and found that we were both
>      right! Specifically both sections 3.3 and 8.6.2.2 have text
>      on this subject:
>
>      3.3Revocation
>
>      When a certificate is issued, it is expected to be in use
>      for its entire validity period.However, various
>      circumstances may cause a certificate to become invalid
>      prior to the expiration of the validity period.
>
>      ....
>
>      An entry is added to the CRL as part of the next update
>      following notification of revocation. An entry may be
>      removed from the CRL after appearing on one regularly
>      scheduled CRL issued beyond the revoked certificate's
>      validity period.
>
>      8.6.2.2 Issuing distribution point extension
>
>      This CRL extension field identifies the CRL distribution
>      point for this particular CRL, and indicates if the CRL is
>      limited to revocations for end-entity certificates only, for
>      authority certificates only, or for a limited set of reasons
>      only. The CRL is signed by the CRL issuer's key- CRL
>      distribution points do not have their own key pairs.
>      However, for a CRL distributed via the Directory, the CRL is
>      stored in the entry of the CRL distribution point, which may
>      not be the directory entry of the CRL issuer.If this field
>      is absent, the CRL shall contain entries for all
>      revoked unexpired certificates issued by the CRL issuer.
>
>      ....
>
>      The distributionPointcomponent contains the name of the
>      distribution point in one or more name forms. If this field
>      is absent, the CRL shall contain entries for all revoked
>      certificates issued by the CRL issuer. After a certificate
>      appears on a CRL, it is deleted from a subsequent CRL after
>      the certificate's expiry.
>
>      Although section 8.6.2.2 is specifically in regards
>      to CRLdps, any difference between full CRLs and CRLdps in
>      this case I feel would be an arbitrary one.
>
>      Now logically it makes sense to remove certificates that are
>      expired from CRLs to control size, yes this has a negative
>      point specifically it prevents CRLs from being used as a
>      non-repudiation source; but this is mute due to many other
>      issues.
>
>      That being the case I think; and I believe Peter would agree
>      the correct thing to do is to remove these expired/revoked
>      entries from the CRL.
>
>      The question now is what is the PKIX stance on this matter?
>
>      Ryan M. Hurst
>
>      ValiCert, Inc.
>
>           "It may roundly be asserted that human ingenuity
>           cannot concoct a cipher which human ingenuity
>           cannot resolve."
>
>           -Edgar Allan Poe
>




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85HaHx01829 for ietf-pkix-bks; Wed, 5 Sep 2001 10:36:17 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85HaED01821 for <[e-mail]>; Wed, 5 Sep 2001 10:36:14 -0700 (PDT)
Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 05 Sep 2001 11:36:12 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Wed, 05 Sep 2001 11:38:28 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Removing expired certificates from CRLs.....
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=_3B619B9C.472643A6"
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.

--=_3B619B9C.472643A6
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Ryan,

If you (the relying party) trust that the CA will be around for that long, =
and that the CRL records will be available if and when you need them, even =
if for a reasonable fee, then you can trust either the CA or some kind of =
a trusted repository to provide this function. Or if you are a true =
paranoid, you can archive them yourself, along with the document in =
question, together with all of the necessary timestamps and other =
corroborating evidence.

In either case, the primary reason for having a certificate validity =
period in the first place was to avoid an ever-increasing CRL list.  The =
other factors, including a sunset-clause type of renewal requirement in =
lieu of active status monitoring by the CA, and the concomitant opportunity=
 for an ongoing yearly revenue stream, were nice to have also.

So there is no reason why expired CRLs can't be removed one publication =
cycle after the certificate has expired, and they should.  But they can't =
be removed immediately, because they might have been revoked one microsecon=
d prior to expiration, and before the next scheduled CRL has been =
published.

Bob

Robert R. Jueneman
Security Architect

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



>>> "Flynn, Michael" <[e-mail]> 09/05/01 11:02AM >>>
Ryan,
=20
Ryan wrote::
Now logically it makes sense to remove certificates that are expired from
CRLs to control size, yes this has a negative point specifically it =
prevents
CRLs from being used as a non-repudiation source; but this is mute due to
many other issues.
=20
At least regarding removing expired certs from CRLs, I would think that
non-repudiation can be satisfied by keeping the old CRLs in back up =
storage
for some length of time.  That time being how far back in time a contract
dispute might go; ten years, twenty?   So long as you could get them off
tape for the lawyers to look at the legal process would be satisfied, they
don't need to be online forever. =20
=20
Michael
=20
-----Original Message-----
From: Ryan Hurst [mailto:[e-mail]]=20
Sent: Tuesday, September 04, 2001 8:50 PM
To: IETF-PKIX
Subject: Removing expired certificates from CRLs.....


I was speaking with Peter Williams today about the removal of expired
certificates from CRLs; I have always been under the belief that this
behavior was optional, I vaguely remembered reading text in 2459 along =
those
lines; additionally I know of several commercial CAs that do not remove =
the
expired certificates from their CRLs. Peter on the other hand was under =
the
impression that it was a mandate to remove CRLs; he too remembered reading
text in 2459 to support is position.
=20
So we each pulled out the RFC and found that we were both right!
Specifically both sections 3.3 and 8.6.2.2 have text on this subject:
=20
3.3  Revocation
When a certificate is issued, it is expected to be in use for its entire
validity period.  However, various circumstances may cause a certificate =
to
become invalid prior to the expiration of the validity period.
=20
...
=20
An entry is added to the CRL as part of the next update following
notification of revocation. An entry may be removed from the CRL after
appearing on one regularly scheduled CRL issued beyond the revoked
certificate's validity period.
=20
=20
=20
8.6.2.2 Issuing distribution point extension
This CRL extension field identifies the CRL distribution point for this
particular CRL, and indicates if the CRL is limited to revocations for
end-entity certificates only, for authority certificates only, or for a
limited set of reasons only. The CRL is signed by the CRL issuer's key- =
CRL
distribution points do not have their own key pairs. However, for a CRL
distributed via the Directory, the CRL is stored in the entry of the CRL
distribution point, which may not be the directory entry of the CRL =
issuer.
If this field is absent, the CRL shall contain entries for all revoked
unexpired certificates issued by the CRL issuer.
=20
...
=20
The distributionPoint component contains the name of the distribution =
point
in one or more name forms. If this field is absent, the CRL shall contain
entries for all revoked certificates issued by the CRL issuer. After a
certificate appears on a CRL, it is deleted from a subsequent CRL after =
the
certificate's expiry.
=20
=20
Although section 8.6.2.2 is specifically in regards to CRLdps, any
difference between full CRLs and CRLdps in this case I feel would be an
arbitrary one.=20
=20
Now logically it makes sense to remove certificates that are expired from
CRLs to control size, yes this has a negative point specifically it =
prevents
CRLs from being used as a non-repudiation source; but this is mute due to
many other issues.
=20
That being the case I think; and I believe Peter would agree the correct
thing to do is to remove these expired/revoked entries from the CRL.=20
=20
The question now is what is the PKIX stance on this matter?
=20
Ryan M. Hurst
ValiCert, Inc.
=20
"It may roundly be asserted that human ingenuity cannot concoct a cipher
which human ingenuity cannot resolve."
-Edgar Allan Poe
=20

--=_3B619B9C.472643A6
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


--=_3B619B9C.472643A6--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85HJIN01464 for ietf-pkix-bks; Wed, 5 Sep 2001 10:19:18 -0700 (PDT)
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85HJHD01460 for <[e-mail]>; Wed, 5 Sep 2001 10:19:17 -0700 (PDT)
Received: from vhqpostal-gw2.verisign.com (mailer2.verisign.com [65.205.251.56]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id f85HGZm25331; Wed, 5 Sep 2001 10:16:35 -0700 (PDT)
Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id <R514SMD6>; Wed, 5 Sep 2001 10:19:18 -0700
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'Bob Jueneman'" <[e-mail]>, "Hallam-Baker, Phillip" <[e-mail]>
Cc: [e-mail]
Subject: RE: charter revisions
Date: Wed, 5 Sep 2001 10:19:13 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1362E.E22BA070"
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_000_01C1362E.E22BA070
Content-Type: text/plain;
	charset="iso-8859-7"

Bob,


> I wasn't suggesting that logos should be restricted to 
> end-entities, I was only pointing out that such a restriction 
> would immediately make the issue of name subordination and 
> misuse of the logo by some intermediate CA go away.

I didn't understand the problem. If you have bad intermediate CAs you have
rather more problems than just bad logos!


> I can see some significant marketing value in supporting an 
> AUTHENTICATED use of a logo in an end-entity certificate, for 
> example to convey a professional license or association 
> membership in the case of an individual, and accredited 
> membership in a trade or merchant association, such as a Visa brand.

Which is my interest. The fact that a logo must be authenticated is not a
problem if the market will bear the cost. I believe that customers would be
very pleased to pay an additional fee for an enhanced certificate.


> I also like your suggestion of a URL and a message digest, 
> rather than attempting to transport the entire logo itself 
> within the certificate. Both the retrieval and display of the 
> logo could then be optional, and the logo could be cached 
> within the browsers, etc. Although you didn't raise the point 
> regarding the use by visually handicapped users, I was 
> particularly impressed by the original reference to Scalable 
> Vector Graphics, and to the potential use of alternate forms 
> of identification, ranging from a audible logo (spoken, a 
> commercial jingle, or whatever) to a braille pattern. 

I don't see that disabilities issue is relevant. We are talking about an
additional feature, not the sole feature. Browsers for disabled users
already have to deal with the security issue. Logos would not make that
problem any harder. It is already possible to put the DN into Braille.

The spoken logo is more interesting because voice based applications are
increasing. The problem of distinguishing authenticated voice from
unauthenticated is considerably worse however.


> Of course it would be nice to have a solid indication of 
> interest from the client software vendors to address the "if 
> we build it will they come" question, but the absence of such 
> a commitment certainly hasn't stopped us in the past, and it 
> seems quite unlikely that we could ever obtain such a 
> commitment when we are still debating the charter, and 
> haven't begun to work on an RFC yet. 

Absolutely, I just thought I would add in my one legitimate concern.

The concerns raised seemed to be mainly legal quibbles from non-lawyers. I
asked our lawyers and got a pretty enthusiastic response to the idea in
principle but as with the policy document they believe lawyers should be
involved in the drafting of the document. The idea of a legal considerations
section was well received.


> I don't mean to ignore or reject the valid concerns that have 
> been expressed, but I do believe that sufficient technical 
> progress has been made even in this limited dialogue to 
> conclude that this is a valid work item, and one that has a 
> least a reasonable chance of success.

I agree.


		Phill


------_=_NextPart_000_01C1362E.E22BA070
Content-Type: application/octet-stream;
	name="Phillip Hallam-Baker (E-mail).vcf"
Content-Disposition: attachment;
	filename="Phillip Hallam-Baker (E-mail).vcf"

BEGIN:VCARD
VERSION:2.1
N:Hallam-Baker;Phillip
FN:Phillip Hallam-Baker (E-mail)
ORG:VeriSign
TITLE:Principal Consultant
TEL;WORK;VOICE:[phone] x227
EMAIL;PREF;INTERNET:[e-mail]
REV:20010214T163732Z
END:VCARD

------_=_NextPart_000_01C1362E.E22BA070--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85H4nB01067 for ietf-pkix-bks; Wed, 5 Sep 2001 10:04:49 -0700 (PDT)
Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85H4mD01063 for <[e-mail]>; Wed, 5 Sep 2001 10:04:48 -0700 (PDT)
Received: from postal-gw1.verisign.com (verisign.com [63.104.27.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id KAA10426; Wed, 5 Sep 2001 10:05:53 -0700 (PDT)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2654.89) id <R5Q8C4CJ>; Wed, 5 Sep 2001 10:02:37 -0700
Message-ID: <[e-mail]>
From: "Flynn, Michael" <[e-mail]>
To: "'Ryan Hurst'" <[e-mail]>, IETF-PKIX <[e-mail]>
Subject: RE: Removing expired certificates from CRLs.....
Date: Wed, 5 Sep 2001 10:02:33 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1362C.8E3F2B50"
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_01C1362C.8E3F2B50
Content-Type: text/plain;
	charset="iso-8859-1"

Ryan,
 
Ryan wrote::
Now logically it makes sense to remove certificates that are expired from
CRLs to control size, yes this has a negative point specifically it prevents
CRLs from being used as a non-repudiation source; but this is mute due to
many other issues.
 
At least regarding removing expired certs from CRLs, I would think that
non-repudiation can be satisfied by keeping the old CRLs in back up storage
for some length of time.  That time being how far back in time a contract
dispute might go; ten years, twenty?   So long as you could get them off
tape for the lawyers to look at the legal process would be satisfied, they
don't need to be online forever.  
 
Michael
 
-----Original Message-----
From: Ryan Hurst [mailto:[e-mail]]
Sent: Tuesday, September 04, 2001 8:50 PM
To: IETF-PKIX
Subject: Removing expired certificates from CRLs.....


I was speaking with Peter Williams today about the removal of expired
certificates from CRLs; I have always been under the belief that this
behavior was optional, I vaguely remembered reading text in 2459 along those
lines; additionally I know of several commercial CAs that do not remove the
expired certificates from their CRLs. Peter on the other hand was under the
impression that it was a mandate to remove CRLs; he too remembered reading
text in 2459 to support is position.
 
So we each pulled out the RFC and found that we were both right!
Specifically both sections 3.3 and 8.6.2.2 have text on this subject:
 
3.3  Revocation
When a certificate is issued, it is expected to be in use for its entire
validity period.  However, various circumstances may cause a certificate to
become invalid prior to the expiration of the validity period.
 
....
 
An entry is added to the CRL as part of the next update following
notification of revocation. An entry may be removed from the CRL after
appearing on one regularly scheduled CRL issued beyond the revoked
certificate's validity period.
 
 
 
8.6.2.2 Issuing distribution point extension
This CRL extension field identifies the CRL distribution point for this
particular CRL, and indicates if the CRL is limited to revocations for
end-entity certificates only, for authority certificates only, or for a
limited set of reasons only. The CRL is signed by the CRL issuer's key- CRL
distribution points do not have their own key pairs. However, for a CRL
distributed via the Directory, the CRL is stored in the entry of the CRL
distribution point, which may not be the directory entry of the CRL issuer.
If this field is absent, the CRL shall contain entries for all revoked
unexpired certificates issued by the CRL issuer.
 
....
 
The distributionPoint component contains the name of the distribution point
in one or more name forms. If this field is absent, the CRL shall contain
entries for all revoked certificates issued by the CRL issuer. After a
certificate appears on a CRL, it is deleted from a subsequent CRL after the
certificate's expiry.
 
 
Although section 8.6.2.2 is specifically in regards to CRLdps, any
difference between full CRLs and CRLdps in this case I feel would be an
arbitrary one. 
 
Now logically it makes sense to remove certificates that are expired from
CRLs to control size, yes this has a negative point specifically it prevents
CRLs from being used as a non-repudiation source; but this is mute due to
many other issues.
 
That being the case I think; and I believe Peter would agree the correct
thing to do is to remove these expired/revoked entries from the CRL. 
 
The question now is what is the PKIX stance on this matter?
 
Ryan M. Hurst
ValiCert, Inc.
 
"It may roundly be asserted that human ingenuity cannot concoct a cipher
which human ingenuity cannot resolve."
-Edgar Allan Poe
 

------_=_NextPart_001_01C1362C.8E3F2B50
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:o = 
"urn:schemas-microsoft-com:office:office" xmlns:w = 
"urn:schemas-microsoft-com:office:word" xmlns:st1 = 
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content=Word.Document name=ProgId>
<META content="MSHTML 5.50.4616.200" name=GENERATOR>
<META content="Microsoft Word 10" name=Originator><LINK 
href="cid:[e-mail]4BB00" rel=File-List><o:SmartTagType 
name="PersonName" 
namespaceuri="urn:schemas-microsoft-com:office:smarttags"></o:SmartTagType><!--[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:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
   <w:UseFELayout/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<STYLE>
st1\:*{behavior:url(#default#ieooui) }
</STYLE>
<![endif]-->
<STYLE>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;
	mso-font-alt:\5B8B\4F53;
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 135135232 16 0 262145 0;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 135135232 16 0 262145 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:SimSun;}
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.EmailStyle17
	{mso-style-type:personal-compose;
	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:windowtext;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</STYLE>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */ 
 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:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]--></HEAD>
<BODY lang=EN-US style="tab-interval: .5in" vLink=purple link=blue>
<DIV><SPAN class=537505516-05092001><FONT face="Courier New" 
size=2>Ryan,</FONT></SPAN></DIV>
<DIV><SPAN class=537505516-05092001><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=537505516-05092001><FONT face="Courier New" size=2>Ryan 
wrote::</DIV>
<P class=MsoNormal><FONT face=Arial size=2><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Now logically it makes sense to 
remove certificates that are expired from <SPAN class=SpellE>CRLs</SPAN> to 
control size, yes this has a negative point specifically it prevents <SPAN 
class=SpellE>CRLs</SPAN> from being used as a non-repudiation source; but this 
is mute due to many other issues.</SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial size=2><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
<P class=MsoNormal><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p><SPAN 
class=537505516-05092001>At least regarding removing expired certs from CRLs, I 
would think that non-repudiation can be satisfied by keeping the old CRLs in 
back up storage for some length of time.&nbsp; That time being how far back in 
time a contract dispute might go; ten years, twenty? &nbsp; So long as you could 
get them off&nbsp; tape for the lawyers to look at the legal process would be 
satisfied, they don't need to be online forever.&nbsp; </SPAN></o:p></SPAN></P>
<P class=MsoNormal><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p><SPAN 
class=537505516-05092001></SPAN></o:p></SPAN><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p><SPAN 
class=537505516-05092001></SPAN></o:p></SPAN>&nbsp;</P>
<P class=MsoNormal><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p><SPAN 
class=537505516-05092001>Michael</SPAN></o:p></SPAN></P>
<P class=MsoNormal><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p><SPAN 
class=537505516-05092001></SPAN></o:p></SPAN>&nbsp;</P></FONT></SPAN>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Ryan Hurst 
  [mailto:[e-mail]]<BR><B>Sent:</B> Tuesday, September 04, 2001 8:50 
  PM<BR><B>To:</B> IETF-PKIX<BR><B>Subject:</B> Removing expired certificates 
  from CRLs.....<BR><BR></FONT></DIV>
  <DIV class=Section1>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">I was speaking with 
  </SPAN></FONT><st1:PersonName><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Peter 
  Williams</SPAN></FONT></st1:PersonName><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> today about the removal of 
  expired certificates from <SPAN class=SpellE>CRLs</SPAN>; I have always been 
  under the belief that this behavior was optional, I vaguely remembered reading 
  text in 2459 along those lines; additionally I know of several commercial 
  <SPAN class=SpellE>CAs</SPAN> that do not remove the expired certificates from 
  their <SPAN class=SpellE>CRLs</SPAN>. Peter on the other hand was under the 
  impression that it was a mandate to remove <SPAN class=SpellE>CRLs</SPAN>; he 
  too remembered reading text in 2459 to support is 
  position.<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">So we each pulled out the RFC and 
  found that we were both right! Specifically both sections 3.3 and 8.6.2.2 have 
  text on this subject:<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal 
  style="tab-stops: 45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt 320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt 732.8pt; mso-layout-grid-align: none"><SPAN 
  class=GramE><B style="mso-bidi-font-weight: normal"><FONT face=Arial 
  size=2><SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-bidi-font-weight: normal">3.3<SPAN 
  style="mso-spacerun: yes">&nbsp; </SPAN>Revocation</SPAN></FONT></B></SPAN><B 
  style="mso-bidi-font-weight: normal"><FONT face=Arial size=2><SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-bidi-font-weight: normal"><o:p></o:p></SPAN></FONT></B></P>
  <P class=MsoNormal 
  style="tab-stops: 45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt 320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt 732.8pt; mso-layout-grid-align: none"><FONT 
  face=Arial size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">When a 
  certificate is issued, it is expected to be in use for its entire validity 
  period.<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>However, various 
  circumstances may cause a certificate to become invalid prior to the 
  expiration of the validity period.<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal 
  style="tab-stops: 45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt 320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt 732.8pt; mso-layout-grid-align: none"><FONT 
  face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal style="mso-layout-grid-align: none"><FONT face=Arial 
  size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">....<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal style="mso-layout-grid-align: none"><FONT face=Arial 
  size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal 
  style="tab-stops: 45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt 320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt 732.8pt; mso-layout-grid-align: none"><FONT 
  face=Arial size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">An entry 
  is added to the CRL as part of the next update following notification of 
  revocation. <B><I><SPAN style="FONT-WEIGHT: bold; FONT-STYLE: italic">An entry 
  may be removed from the CRL after appearing on one regularly scheduled CRL 
  issued beyond the revoked certificate's validity 
  period.</SPAN></I></B><o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal style="mso-layout-grid-align: none"><B><FONT face=Arial 
  size=2><SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Arial">8.6.2.2 Issuing 
  distribution point extension<o:p></o:p></SPAN></FONT></B></P>
  <P class=MsoNormal style="mso-layout-grid-align: none"><FONT face=Arial 
  size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">This CRL extension 
  field identifies the CRL distribution point for this particular CRL, and 
  indicates if the CRL is limited to revocations for end-entity certificates 
  only, for authority certificates only, or for a limited set of reasons only. 
  The CRL is signed by the CRL issuer's key- CRL distribution points do not have 
  their own key pairs. However, for a CRL distributed via the Directory, the CRL 
  is stored in the entry of the CRL distribution point, which may not be the 
  directory entry of the CRL issuer.<I><SPAN style="FONT-STYLE: italic"> 
  <B><SPAN style="FONT-WEIGHT: bold">If this field is absent, the CRL shall 
  contain entries for all revoked <SPAN class=SpellE>unexpired</SPAN> 
  certificates issued by the CRL 
  issuer.</SPAN></B><o:p></o:p></SPAN></I></SPAN></FONT></P>
  <P class=MsoNormal style="mso-layout-grid-align: none"><I><FONT face=Arial 
  size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-STYLE: italic; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></I></P>
  <P class=MsoNormal style="mso-layout-grid-align: none"><FONT face=Arial 
  size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">....<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal style="mso-layout-grid-align: none"><FONT face=Arial 
  color=blue size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal style="mso-layout-grid-align: none"><FONT face=Arial 
  size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">The 
  </SPAN></FONT><SPAN class=SpellE><B><FONT face=Arial size=1><SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 9pt; FONT-FAMILY: Arial">distributionPoint</SPAN></FONT></B></SPAN><B><FONT 
  face=Arial size=1><SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 9pt; FONT-FAMILY: Arial"> 
  </SPAN></FONT></B><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">component contains the name of the 
  distribution point in one or more name forms. If this field is absent, the CRL 
  shall contain entries for all revoked certificates issued by the CRL issuer. 
  <B><I><SPAN style="FONT-WEIGHT: bold; FONT-STYLE: italic">After a certificate 
  appears on a CRL, it is deleted from a subsequent CRL after the certificate's 
  expiry.<o:p></o:p></SPAN></I></B></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Although section 8.6.2.2 is 
  specifically in regards to <SPAN class=SpellE>CRLdps</SPAN>, any difference 
  between full <SPAN class=SpellE>CRLs</SPAN> and <SPAN 
  class=SpellE>CRLdps</SPAN> in this case I feel would be an arbitrary one. 
  <o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Now logically it makes sense to 
  remove certificates that are expired from <SPAN class=SpellE>CRLs</SPAN> to 
  control size, yes this has a negative point specifically it prevents <SPAN 
  class=SpellE>CRLs</SPAN> from being used as a non-repudiation source; but this 
  is mute due to many other issues.<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">That being the case I think; and I 
  believe Peter would agree the correct thing to do is to remove these 
  expired/revoked entries from the CRL. <o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">The question now is what is the 
  PKIX stance on this matter?<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Ryan M. 
  Hurst<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">ValiCert, 
  Inc.<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <BLOCKQUOTE style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">
    <P class=MsoNormal><I><FONT face="Times New Roman" size=3><SPAN 
    style="FONT-SIZE: 12pt; FONT-STYLE: italic; mso-no-proof: yes">"It may 
    roundly be asserted that human ingenuity cannot concoct a cipher which human 
    ingenuity cannot resolve."</SPAN></FONT></I><SPAN 
    style="mso-no-proof: yes"><o:p></o:p></SPAN></P></BLOCKQUOTE>
  <BLOCKQUOTE style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">
    <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
    style="FONT-SIZE: 12pt; mso-no-proof: yes">-Edgar Allan 
    Poe</SPAN><o:p></o:p></FONT></P></BLOCKQUOTE>
  <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
  style="FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1362C.8E3F2B50--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85Gl4900700 for ietf-pkix-bks; Wed, 5 Sep 2001 09:47:04 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85Gl2D00695 for <[e-mail]>; Wed, 5 Sep 2001 09:47:02 -0700 (PDT)
Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 05 Sep 2001 10:47:00 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Wed, 05 Sep 2001 10:49:21 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: charter revisions
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-7
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f85Gl3D00696
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, Phillip,

Although you didn't attach my note, you seemed to be responding to some of my comments, at least in part, so at the risk of violently agreeing with you, let me comment further.

I wasn't suggesting that logos should be restricted to end-entities, I was only pointing out that such a restriction would immediately make the issue of name subordination and misuse of the logo by some intermediate CA go away.

I can see some significant marketing value in supporting an AUTHENTICATED use of a logo in an end-entity certificate, for example to convey a professional license or association membership in the case of an individual, and accredited membership in a trade or merchant association, such as a Visa brand.

Whether multi-cultural issues are sufficient to place the Coca-Cola logo in a certificate, I'm not so sure, but I certainly wouldn't rule out the possibility, as I discussed with the Air Canada example.  Standards organizations sometimes tend to be rather cavalier in such regards ¯ sort of a "let them eat ASCII" type of attitude.  But I'd certainly prefer to see the Sony name/logotype displayed than I would their name in katakana, much less in Japanese ideographs.

But I also see considerable merit in your suggestion of a trust brand, to replace the "silly padlock".  In many respects, it could be a human-readable equivalent of a CP, which is otherwise nearly useless in current practice, I believe.

(BTW, someone informed me that null crypto, e.g., plaintext, is a valid option in SSL, and worse yet, that if that option were selected because it was all that was available, the padlock icon would still appear and the https requirement for SSL security would be satisfied.  Can anyone confirm that?)

I also like your suggestion of a URL and a message digest, rather than attempting to transport the entire logo itself within the certificate. Both the retrieval and display of the logo could then be optional, and the logo could be cached within the browsers, etc. Although you didn't raise the point regarding the use by visually handicapped users, I was particularly impressed by the original reference to Scalable Vector Graphics, and to the potential use of alternate forms of identification, ranging from a audible logo (spoken, a commercial jingle, or whatever) to a braille pattern. 

Of course it would be nice to have a solid indication of interest from the client software vendors to address the "if we build it will they come" question, but the absence of such a commitment certainly hasn't stopped us in the past, and it seems quite unlikely that we could ever obtain such a commitment when we are still debating the charter, and haven't begun to work on an RFC yet. 

I don't mean to ignore or reject the valid concerns that have been expressed, but I do believe that sufficient technical progress has been made even in this limited dialogue to conclude that this is a valid work item, and one that has a least a reasonable chance of success.

We aren't trying to square the circle using straight-edge and compass, nor are we trying to invent a perpetual motion machine.  And yes, as Peter Gutman has demonstrated, anyone could include my gedanken MPEG of a cat in a certificate in any ad hoc way they wanted to, even in the DN if they were so inclined.  One of major purposes of a group such as this is to try to herd all of the cats into a reasonably straight line, and towards an agreed-upon objective, just so that kind of ad hockery doesn't occur.

But no one is forced to contribute to such an RFC, or even read it, if they lack the energy.:-)

Bob



>>> "Hallam-Baker, Phillip" <[e-mail]> 09/05/01 09:17AM >>>
Why do logotypes have to be restricted to end entity certificates?

The most usefull place for a logo is in the root certificate so that you
know the trust brand that you are relying upon. Instead of the silly padlock
there should be an icon telling you who the trust provider is (Thawte,
VeriSign, etc.) and the strength (128bit, 40bit, WEP, etc.)

As for the complexity of cross certification etc., if logotypes don't work
in those situations then don't use them. We better hope that the
introduction of logotypes does not cause a problem with the cross
certification mechanism as some seem to believe since if that were true it
would indicate that the cross certification mechanism was broken (which
would imply adding a WG charter item to fix it which I do not see anyone
proposing).


I do consider the introduction of logotypes to be an intrinsic difficulty
for the CA or RA. Whether they would consider the market for them to be
worthwhile is another matter, likely to closely track the level of client
support.

I have not seen a convincing argument on the trademark issue. The registrar
will simply have to authenticate the ownership of the mark the same they
would any other piece of information, and presumably charge accordingly.
This can be subject to a CPS etc.

These issues may not be simple, however the degree of difficulty is
certainly not so great that the idea should be thrown out as some appear to
imply. If there really is concern we can go ask some lawyers and write a
'legal considerations' section to go along with the 'security
considerations' section.


The issue of far greater interest to me is whether any makers of client
application software have any interest in supporting the scheme. If not it
would simply be another crenelation on the specification.

Another issue is size. I don't much want to see the size of certificates
increase yet further. Perhaps a hash of the image and a URL would be
preferable. Perhaps something a bit more.


At any rate there is certainly enough to justify a WG item. If the WG
ultimately decides that it cannot solve the legal and technical difficulties
it can write a note explaining them for the benefit of future WGs.


		Phill



Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
[e-mail] 
781 245 6996 x227


> -----Original Message-----
> From: Steve Hanna [mailto:[e-mail]] 
> Sent: Wednesday, September 05, 2001 10:19 AM
> To: Paul Hoffman / IMC
> Cc: [e-mail] 
> Subject: Re: charter revisions
> 
> 
> 
> Paul Hoffman / IMC wrote:
> > At 11:58 AM -0400 9/4/01, Steve Hanna wrote:
> > >Unless the author of the Internet Draft indicates otherwise, I will
> > >assume that the primary purpose of putting logotypes in 
> certificates
> > >is so that users can view them to make decisions about whether the
> > >certificates are trustworthy. In that case, the risks are 
> much greater
> > >than those for the use case you described.
> > 
> > Are the risks any greater than what we have in 2459 now 
> with spelling
> > errors or things like "FooCA type 1 certificate" vs. "FooCA type 2
> > certificate"? I agree with Russ that the benefits are 
> higher, but I'm
> > not at all convinced that the risks are higher.
> 
> Yes, the risks are greater than those encountered with textual names.
> For one thing, name constraints provide an effective way to limit the
> portion of the name space that can be reached via a cross certificate.
> No corresponding mechanism has been suggested for logotypes 
> nor does it
> seem likely that such a mechanism could be developed.
> 
> My original email cited several other security risks that are greater
> for logotypes than for textual names: CAs may find it harder 
> to verify a
> certificate requester's right to use a logotype than their 
> right to use
> a textual name and logotypes may change appearance radically on
> different devices. Several other risks have been pointed out in the
> recent email discussion: users may not be able to distinguish one
> logotype from another, users may not recall which logotype corresponds
> to which entity, and logotypes are not accessible to vision-impaired
> users or usable on text-only terminals.
> 
> > >Unless we can develop a fairly secure way to meet the "marketing
> > >requirement" for logotypes in certificates, I would say that it is
> > >our obligation as an IETF working group to NOT accept this as a
> > >work item. Much better to have multiple incompatible ways
> > >to do something insecure (probably resulting in little deployment
> > >of this feature) than to have the PKIX working group issue an RFC
> > >explaining the one true way to do it. We are in the Security area,
> > >after all!
> > 
> > The end of that paragraph doesn't follow from the beginning of the
> > paragraph. As long as the method we described doesn't have any
> > security holes, it doesn't matter if we meet some pre-existing
> > marketing "need". Further, some of the multiple, non-interoperable
> > protocols are likely to have security problems; that is worse than
> > having one protocol that doesn't meet the need of some CAs.
> 
> The whole paragraph should be considered predicated by the 
> first clause
> ("Unless..."). If that clause does not apply (i.e., we can develop a
> fairly secure way to place logotypes in certificates), then I 
> don't have
> any objection to having this as a PKIX work item. But I have seen no
> sign that the objections raised so far can be overcome.
> 
> > Mike Myers wrote:
> > >I agree with Stephen Farrell and Steve Hanna that logotypes are
> > >out of scope.
> > 
> > They are out of scope; the discussion is whether to add them to
> > the scope.
> 
> Of course, you are right. This is a charter discussion.
> 
> RFC 2418 (BCP 25) says that "IETF developed technologies 
> should not add
> insecurity to the environment in which they run." The IESG 
> has enforced
> this in the past and it seems especially pertinent to a 
> working group in
> the Security Area. I doubt that the IESG or the Security ADs 
> will accept
> this work item in our charter unless we can argue convincingly that we
> can develop something that would not add insecurity to the environment
> in which it is run. I don't think we're there yet.
> 
> -Steve
> 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85FHg224525 for ietf-pkix-bks; Wed, 5 Sep 2001 08:17:42 -0700 (PDT)
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85FHfD24519 for <[e-mail]>; Wed, 5 Sep 2001 08:17:41 -0700 (PDT)
Received: from vhqpostal-gw1.verisign.com (mailer1.verisign.com [65.205.251.55]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id f85FEvm04887 for <[e-mail]>; Wed, 5 Sep 2001 08:14:57 -0700 (PDT)
Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2653.19) id <R5GA3YKM>; Wed, 5 Sep 2001 08:17:40 -0700
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: [e-mail]
Subject: RE: charter revisions
Date: Wed, 5 Sep 2001 08:17:28 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1361D.E0596130"
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_000_01C1361D.E0596130
Content-Type: text/plain;
	charset="iso-8859-1"

Why do logotypes have to be restricted to end entity certificates?

The most usefull place for a logo is in the root certificate so that you
know the trust brand that you are relying upon. Instead of the silly padlock
there should be an icon telling you who the trust provider is (Thawte,
VeriSign, etc.) and the strength (128bit, 40bit, WEP, etc.)

As for the complexity of cross certification etc., if logotypes don't work
in those situations then don't use them. We better hope that the
introduction of logotypes does not cause a problem with the cross
certification mechanism as some seem to believe since if that were true it
would indicate that the cross certification mechanism was broken (which
would imply adding a WG charter item to fix it which I do not see anyone
proposing).


I do consider the introduction of logotypes to be an intrinsic difficulty
for the CA or RA. Whether they would consider the market for them to be
worthwhile is another matter, likely to closely track the level of client
support.

I have not seen a convincing argument on the trademark issue. The registrar
will simply have to authenticate the ownership of the mark the same they
would any other piece of information, and presumably charge accordingly.
This can be subject to a CPS etc.

These issues may not be simple, however the degree of difficulty is
certainly not so great that the idea should be thrown out as some appear to
imply. If there really is concern we can go ask some lawyers and write a
'legal considerations' section to go along with the 'security
considerations' section.


The issue of far greater interest to me is whether any makers of client
application software have any interest in supporting the scheme. If not it
would simply be another crenelation on the specification.

Another issue is size. I don't much want to see the size of certificates
increase yet further. Perhaps a hash of the image and a URL would be
preferable. Perhaps something a bit more.


At any rate there is certainly enough to justify a WG item. If the WG
ultimately decides that it cannot solve the legal and technical difficulties
it can write a note explaining them for the benefit of future WGs.


		Phill



Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
[e-mail]
781 245 6996 x227


> -----Original Message-----
> From: Steve Hanna [mailto:[e-mail]]
> Sent: Wednesday, September 05, 2001 10:19 AM
> To: Paul Hoffman / IMC
> Cc: [e-mail]
> Subject: Re: charter revisions
> 
> 
> 
> Paul Hoffman / IMC wrote:
> > At 11:58 AM -0400 9/4/01, Steve Hanna wrote:
> > >Unless the author of the Internet Draft indicates otherwise, I will
> > >assume that the primary purpose of putting logotypes in 
> certificates
> > >is so that users can view them to make decisions about whether the
> > >certificates are trustworthy. In that case, the risks are 
> much greater
> > >than those for the use case you described.
> > 
> > Are the risks any greater than what we have in 2459 now 
> with spelling
> > errors or things like "FooCA type 1 certificate" vs. "FooCA type 2
> > certificate"? I agree with Russ that the benefits are 
> higher, but I'm
> > not at all convinced that the risks are higher.
> 
> Yes, the risks are greater than those encountered with textual names.
> For one thing, name constraints provide an effective way to limit the
> portion of the name space that can be reached via a cross certificate.
> No corresponding mechanism has been suggested for logotypes 
> nor does it
> seem likely that such a mechanism could be developed.
> 
> My original email cited several other security risks that are greater
> for logotypes than for textual names: CAs may find it harder 
> to verify a
> certificate requester's right to use a logotype than their 
> right to use
> a textual name and logotypes may change appearance radically on
> different devices. Several other risks have been pointed out in the
> recent email discussion: users may not be able to distinguish one
> logotype from another, users may not recall which logotype corresponds
> to which entity, and logotypes are not accessible to vision-impaired
> users or usable on text-only terminals.
> 
> > >Unless we can develop a fairly secure way to meet the "marketing
> > >requirement" for logotypes in certificates, I would say that it is
> > >our obligation as an IETF working group to NOT accept this as a
> > >work item. Much better to have multiple incompatible ways
> > >to do something insecure (probably resulting in little deployment
> > >of this feature) than to have the PKIX working group issue an RFC
> > >explaining the one true way to do it. We are in the Security area,
> > >after all!
> > 
> > The end of that paragraph doesn't follow from the beginning of the
> > paragraph. As long as the method we described doesn't have any
> > security holes, it doesn't matter if we meet some pre-existing
> > marketing "need". Further, some of the multiple, non-interoperable
> > protocols are likely to have security problems; that is worse than
> > having one protocol that doesn't meet the need of some CAs.
> 
> The whole paragraph should be considered predicated by the 
> first clause
> ("Unless..."). If that clause does not apply (i.e., we can develop a
> fairly secure way to place logotypes in certificates), then I 
> don't have
> any objection to having this as a PKIX work item. But I have seen no
> sign that the objections raised so far can be overcome.
> 
> > Mike Myers wrote:
> > >I agree with Stephen Farrell and Steve Hanna that logotypes are
> > >out of scope.
> > 
> > They are out of scope; the discussion is whether to add them to
> > the scope.
> 
> Of course, you are right. This is a charter discussion.
> 
> RFC 2418 (BCP 25) says that "IETF developed technologies 
> should not add
> insecurity to the environment in which they run." The IESG 
> has enforced
> this in the past and it seems especially pertinent to a 
> working group in
> the Security Area. I doubt that the IESG or the Security ADs 
> will accept
> this work item in our charter unless we can argue convincingly that we
> can develop something that would not add insecurity to the environment
> in which it is run. I don't think we're there yet.
> 
> -Steve
> 


------_=_NextPart_000_01C1361D.E0596130
Content-Type: application/octet-stream;
	name="Phillip Hallam-Baker (E-mail).vcf"
Content-Disposition: attachment;
	filename="Phillip Hallam-Baker (E-mail).vcf"

BEGIN:VCARD
VERSION:2.1
N:Hallam-Baker;Phillip
FN:Phillip Hallam-Baker (E-mail)
ORG:VeriSign
TITLE:Principal Consultant
TEL;WORK;VOICE:[phone] x227
EMAIL;PREF;INTERNET:[e-mail]
REV:20010214T163732Z
END:VCARD

------_=_NextPart_000_01C1361D.E0596130--


Received: by above.proper.com (8.11.6/8.11.3) id f85EqdH23774 for ietf-pkix-bks; Wed, 5 Sep 2001 07:52:39 -0700 (PDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85EqbD23770 for <[e-mail]>; Wed, 5 Sep 2001 07:52:37 -0700 (PDT)
Received: from [128.33.84.34] (comsec.bbn.com [128.33.84.34]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27581; Wed, 5 Sep 2001 10:54:24 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010406b7bbeb93305a@[128.33.84.34]>
In-Reply-To: <[e-mail]>
References: <p0501040bb7a8214adf35@[128.33.84.34]>		 <[e-mail]> <p05010404b7babe9a79ed@[128.33.84.34]> <[e-mail]>
Date: Wed, 5 Sep 2001 10:47:58 -0400
To: Denis Pinkas <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: charter revisions
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>

At 9:15 AM +0200 9/5/01, Denis Pinkas wrote:
>Steve,
>
>(deleted text)
>
>>  >I also found that 3/02 for DPV/DPD Protocols RFCs, may be a little bit
>>  >optimistic. 3/04 would probably be more appropriate.
>
>>  OK, I'll make that change.
>
>With the writing of dates in the reverse way between my country and yours,
>I got confused. I was thinking that April 2002 would be reasonable, not
>for the RFC being published (by experience we know that it takes months
>between an IETF last call being passed and an RFC publication), but for
>a WG last call.
>
>So if we assume WG Last call in April 2002 and IETF last call in June 2002,
>then we add 6 months for publication and this makes December 2002 (12/02,
>I presume) for a possible publication.
>
>Denis

OK.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85Eg8121644 for ietf-pkix-bks; Wed, 5 Sep 2001 07:42:08 -0700 (PDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85Eg6D21640 for <[e-mail]>; Wed, 5 Sep 2001 07:42:06 -0700 (PDT)
Received: from [128.33.84.34] (comsec.bbn.com [128.33.84.34]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24962 for <[e-mail]>; Wed, 5 Sep 2001 10:44:25 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010405b7bbe821612c@[128.33.84.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 5 Sep 2001 10:42:59 -0400
To: <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: charter revisions
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,

There seems to be some misunderstanding about the future of PKIX, 
that has arisen as a side effect of the charter discussions.

PKIX is far from the longest lived WG, or even the longest lived 
security WG, as some comments have suggested.  Check out the lifetime 
of CAT for example.

Neither co-chair has suggested that they are running out of energy, 
although that characterization was made about the WG.

In addition to new work items, we have a long term commitment to 
progressing our current, standards track RFCs through to full 
standard status, and we anticipate continuing interactions with the 
X.509 committee as the base standards that we profile continue to 
evolve.  We have had very good interactions with the X.509 committee 
members over the years; both groups have benefited from the give and 
take.

Finally, people are always free to pursue PKI-related activities in 
other fora, e.g., industry consortia.  However, these other fora 
usually do not operate in the same fashion as an IETF WG, e.g., they 
have different agendas, different "membership" requirements, and one 
ought not expect the output to be the same.  Thus I do not anticipate 
PKIX ceding its role in this arena to such fora.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85EdU221550 for ietf-pkix-bks; Wed, 5 Sep 2001 07:39:30 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85EdSD21546 for <[e-mail]>; Wed, 5 Sep 2001 07:39:29 -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 KAA03856 for <[e-mail]>; Wed, 5 Sep 2001 10:39:29 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Wed, 05 Sep 2001 10:38:41 -0400
To: IETF-PKIX <[e-mail]>
From: "David A. Cooper" <[e-mail]>
Subject: Re: Removing expired certificates from CRLs.....
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_6098898==_.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>

--=====================_6098898==_.ALT
Content-Type: text/plain; charset="us-ascii"

At 03:53 PM 9/5/01 +0200, Nada Kapidzic Cicovic wrote:
>Denis,
>
>I was making comments on the text which Ryan extracted in his mail, assuming that they were from the son-of-RFC2459.
>
>In particular the last sentence in this paragraph:
>
>The distributionPoint component contains the name of the distribution point in one or more name forms. If this field is absent, the CRL shall contain entries for all revoked certificates issued by the CRL issuer. After a certificate appears on a CRL, it is deleted from a subsequent CRL after the certificate's expiry.
>
>However, after getting your comment I realized that this sentence and the referred section 8.6.2.2 comes from the X.509 (the latest version that I have on my disk is X_509_4thEditionDraftV6, and it contains the above text). 

I have X_509_4thEditionDraftV8 on my computer and it appears that this has been fixed. I now says "After a certificate appears on a CRL, it may be deleted from a subsequent CRL after the certificate’s expiry."  I didn't bother to look at son-of-2459.

In any case, both X.509 and son-of-2459 should say that a certificate may be deleted from a CRL after it has expired.  In general, though, I don't think there is much benefit to leaving expired certificates on CRLs.  The problem is that, at the moment, if an expired certificate is not listed on a CRL, there is no way to determine whether it is not listed because it was never revoked or if it was revoked but is not listed because it was removed after expiration.

Some time ago, there was a suggestion to create a new, non-critical CRL extension that would specify whether an expired certificate was covered by a CRL (e.g., the extension could state: "This CRL includes all revoked certificates that expire(d) after Jan. 1, 2001 (i.e., notAfter >= 010101000000Z)."). There didn't seem to be much support for this idea, so the extension was never created.

>The current text of the son-of-RFC2459 does not seem to contain it or any other misleading sentences regarding this issue. 
>
>Sorry for the confusion.
>
>Nada


--=====================_6098898==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
At 03:53 PM 9/5/01 +0200, Nada Kapidzic Cicovic wrote:<br>
<blockquote type=cite cite>Denis,<br>
<br>
I was making comments on the text which Ryan extracted in his mail,
assuming that they were from the son-of-RFC2459.<br>
<br>
In particular the last sentence in this paragraph:<br>
<br>
The <font size=2><b>distributionPoint </font></b>component contains the
name of the distribution point in one or more name forms. If this field
is absent, the CRL shall contain entries for all revoked certificates
issued by the CRL issuer. <b><i>After a certificate appears on a CRL, it
is deleted from a subsequent CRL after the certificate's expiry.<br>
<br>
</b></i>However, after getting your comment I realized that this sentence
and the referred section 8.6.2.2 comes from the X.509 (the latest version
that I have on my disk is X_509_4thEditionDraftV6, and it contains the
above text). </blockquote><br>
I have X_509_4thEditionDraftV8 on my computer and it appears that this
has been fixed. I now says &quot;After a certificate appears on a CRL, it
<b>may be</b> deleted from a subsequent CRL after the certificate’s
expiry.&quot;&nbsp; I didn't bother to look at son-of-2459.<br>
<br>
In any case, both X.509 and son-of-2459 should say that a certificate may
be deleted from a CRL after it has expired.&nbsp; In general, though, I
don't think there is much benefit to leaving expired certificates on
CRLs.&nbsp; The problem is that, at the moment, if an expired certificate
is not listed on a CRL, there is no way to determine whether it is not
listed because it was never revoked or if it was revoked but is not
listed because it was removed after expiration.<br>
<br>
Some time ago, there was a suggestion to create a new, non-critical CRL
extension that would specify whether an expired certificate was covered
by a CRL (e.g., the extension could state: &quot;This CRL includes all
revoked certificates that expire(d) after Jan. 1, 2001 (i.e., notAfter
&gt;= 010101000000Z).&quot;). There didn't seem to be much support for
this idea, so the extension was never created.<br>
<br>
<blockquote type=cite cite>The current text of the son-of-RFC2459 does
not seem to contain it or any other misleading sentences regarding this
issue. <br>
<br>
Sorry for the confusion.<br>
<br>
Nada</blockquote><br>
</html>

--=====================_6098898==_.ALT--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85EbH721514 for ietf-pkix-bks; Wed, 5 Sep 2001 07:37:17 -0700 (PDT)
Received: from menelao.polito.it (menelao.polito.it [130.192.3.30]) by above.proper.com (8.11.6/8.11.3) with SMTP id f85EbGD21510 for <[e-mail]>; Wed, 5 Sep 2001 07:37:16 -0700 (PDT)
Message-Id: <[e-mail]>
Received: (qmail 8796 invoked from network); 5 Sep 2001 14:37:15 -0000
Received: from lioy.polito.it (HELO LIOY) (130.192.1.64) by menelao.polito.it with SMTP; 5 Sep 2001 14:37:15 -0000
Subject: Re: Removing expired certificates from CRLs.....
Date: Wed, 05 Sep 2001 13:48:09 +0200
From: Antonio Lioy <[e-mail]>
Organization: Politecnico di Torino
To: IETF-PKIX <[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>

Nada Kapidzic Cicovic wrote:
>
> Ryan,
>
> Some years ago we at Entegrity also had similar discussion. We were
> positive CRLs were not to contain the information about the expired
> certificates, until we came across some industry CA CRLs containing
> information about all revoked certificates. We then looked into 2459
> (draft in those days) and X.509 text and came to the conclusion that
> deleting info about expired certificates from a CRL is only an option.
>
> I am not sure what was the intention of the original authors of X.509
> (perhaps Sharon and Hoyt know more about it), but the current industry
> practice seems to be a mixture of both approaches.
>
> My personal opinion is that keeping all revoked certificates info in
> CRLs brings more problems than benefits. However, it is questionable
> whether PKIX needs to take a vote for one approach or the other.
>
> In any case I would suggest that the text of 2459 be modified so that
> it has a MAY (or a MUST) consistently in all places where deleting
> expired certificates revocation info from CRLs is mentioned. The
> current text only brings confusion, as you have already pointed out.

I vote for MAY (rather than MUST) because it is largely a matter of the
CA: if there are few revoked certificates, there is no benefit in
deleting them from the CRL once they expire, but - on the countrary - if
they are deleted, this can cause problems to applications.
For example, let us suppose that I receive today a document signed two
years ago with a cert currently expired, and I want to check the
revokation status of the related certificates at the signature time.
If I retrieve the current CRL, it might not contain the cert (if it was
revoked) due to the CA policy of deleting from the CRL the expired
certificates.
So, how can I retrieve the first CRL issued after signature time? it
seems to me that there is no provision for such a request in neither
OCSP nor CMP, so many CAs do not delete expired certs from CRLs to avoid
this problem. Therefore, I think that PKIX should permit this kind of
behaviour and not force CA into a mode of operation that can cause
application problems.

Just my 2c.

Antonio Lioy




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85EWV621382 for ietf-pkix-bks; Wed, 5 Sep 2001 07:32:31 -0700 (PDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85EWUD21378 for <[e-mail]>; Wed, 5 Sep 2001 07:32:30 -0700 (PDT)
Received: from [128.33.84.34] (comsec.bbn.com [128.33.84.34]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22016; Wed, 5 Sep 2001 10:34:48 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010404b7bbdfb8674d@[128.33.84.34]>
In-Reply-To: <[e-mail]>
References: <p0501040bb7a8214adf35@[128.33.84.34]>		 <[e-mail]> <p0501040ab7b458549900@[128.33.238.96]>	 <[e-mail]> <p05010403b7bab9e15dcc@[128.33.84.34]> <[e-mail]>
Date: Wed, 5 Sep 2001 10:32:56 -0400
To: Steve Hanna <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: charter revisions
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>

At 4:00 PM -0400 9/4/01, Steve Hanna wrote:
>Stephen Kent wrote:
>>  The same name may be used for products or by organizations in
>>  different "areas" if there is a belief that no confusion will result.
>>  However, a trademark, in its graphic form, is also a copyrighted image
>>  and as such is subject to a different set of legal rules that
>>  generally prohibit outright duplication. The legal challenges arise
>>  when two logos seem too similar to one another, in the eyes of one of
>>  the logo holders, and this is when courts step in and adjudicate the
>>  dispute. Nonetheless, this discussion does not argue against the
>>  ability of a CA to make a judgement about the legitimacy of a
>>  subject's claim to the right to use a trademarked logo. Perahps the
>>  point you're making above is that logos may not be as uniquely helpful
>>  in identifying an organization because of the possibility of similar
>>  logos being used by entities in different areas. That's a fair
>>  critique, but in a different dimension.
>
>I don't think copyright would help much if two companies had trademarks
>in different countries for a logo that looks like a red circle. But
>IANAL, so I will abandon that line of argument. Maybe the international
>copyright and trademark system is strong enough to ensure that the same
>logo cannot be registered by two different entities in different
>countries, even if one of those entities is a sham operated by criminals
>for the purpose of impersonating the other.

I hate to beat a dead horse, but ...  Consider the current problem 
for a CA that is asked to issue a cert to Company X, with a DN 
selected by that company. There is not a central registry for DNs 
where the CA can check to verify that the company in question is 
entitled to use the DN it proposes. Certainly this is true if the 
U.S. So, since CAs regularly make value judgements about 
appropriateness of DNs given imperfect inputs, I don't see the logo 
"verification" as something fundamentally different and harder. 
(Gee, for someone who has not been a big supporter of this I seem to 
spend an awful lot of time defending it ...  Stefan, where are you?)

>You do make a good point that two logos different enough to be legally
>distinct may not be distinguishable to the average user. It's also true
>that users may not remember the logo associated with a particular
>company. Visa, yes. But maybe not Schwab.

Yep. And if we adopt a logo extension, I would expect to see this as 
part of the security considerations section.

>
>>  > Do we know of any CAs that want to include logotypes in certificates
>>  > that they issue, plan to verify those logotypes, and would be
>>  > willing to
>>  > provide some sort of assurances to back that up in their CPS's?
>>
>>  Stefan represents one such CA service provider.
>
>Really? I haven't heard Stefan say anything about how AddTrust would
>verify logotypes or what assurances his company would provide in this
>regard. Maybe he told you this in private conversation.

Stefan certainly has indicated that his interest in pursuing this was 
motivated by his perception of a market need, based on his experience 
as CTO for AddTrust. I inferred that AddTrust would make use of this 
facility if it were available.

>  > I would prefer to find a way to impose some form of constraint on
>>  the appearance of logos analogous to what we do in cross certs for names
>>  or policies.  because a logo is not structured, the name constraints
>>  mechanism can never be used in so precise a fashion, even if we choose
>>  to put a logo in some name form. but, it would be nice to have a way
>>  to prevent a CA further down a cross-cert chain from introducing a
>>  logo if one wants to prevent such action. Just because we don't have a
>>  mechanism to do this yet doesn't mean we can't work toward one.
>
>This would mean that all existing cross-certificates would allow
>logotypes in certificates. It might be better to say that certificate
>containing a logotype should not be validated (or, at least, the
>logotype should be ignored) unless all preceding certificates in the
>path have an extension that says logotypes are allowed.

I didn't mean to suggest details of solution at this point; I just 
wanted to express what I thought was a good requirement. To be 
analogous to what we can do with policy mapping and inhibition of 
policy mapping and with name constraints, it might sufficient if a CA 
could preclude inclusion of a logo extension in any subsequent cert 
in a path.

>
>>  > > >Third, an apparently innocuous logotype can change appearance
>>  > radically
>>  > > >when scaled to a smaller size or mapped to a different number of
>>  > colors.
>>  > > >This can be exploited to deceive cell phone users into thinking
>>  > that
>>  > > >they're communicating with their bank, for instance.
>>  > >
>>  > > I had not considered this issue. we should explore ways that this
>>  > > problem might be avoided. presumably anyone displaying a logo on a
>>  > > web page has a similar concern, so maybe there are viable means to
>>  > > address this issue.
>>  >
>>  > The problem with displaying a logo on a web page is different
>>  > (unless I
>>  > didn't understand you). With a logo in a certificate, we want to
>>  > make
>>  > sure that the person requesting the certificate doesn't trademark a
>>  > bogus logo and get it included in their certificate just so they can
>>  > trick a user who sees a scaled-down version of the logo into
>>  > believing
>>  > it's a trusted logo. The closest analogy is getting a web server
>>  > certificate for paypa1.com (where the letter ell is actually a
>>  > number
>>  > one). If you can get the user to click on an https://www.paypa1.com
>>  > URL,
>>  > the user will think they are viewing a secure paypal website if the
>>  > font
>>  > they use to view URLs displays ell and one the same way.
>>  >
>>  > When viewing a logo on a web page, the user should not make
>>  > decisions
>>  > about whose web page it is based on the logo. Instead, we have been
>>  > trying to convince them to look at the host name in the URL and
>>  > check
>>  > that the padlock or key is lit up to indicate that an SSL connection
>>  > is
>>
>>  > in use.
>>
>>  The reality is that logos on web pages are designed to inspire
>>  confidence in users based on visiting the web page, period. Yes,
>>  someone can put up a similar logo to try to fool people, or even put
>>  up the valid logo without the permission of the logo owner. We rely on
>>  the legal system to detect and remedy these problems, ex post facto.
>>  That's not as good as preventing them, but many folks argue that it is
>>  better than not offering a logo-based marking facility.  When it comes
>>  to putting logos in certs, we have a better mechanism in many cases,
>>  since the binding is secured and there are fewer CAs than there are
>>  web sites.
>
>Just seeing a logo on a web page doesn't inspire much confidence in me.
>Yes, the logo owner will probably pursue those who misuse the logo. But
>the Internet is a rough place. The miscreants may skip town with no
>forwarding address and I (the user) will be very sad if I gave them my
>brokerage account password and they emptied the account.

You and I probably are not the folks for whom the logo extension 
would be of great value.

>That's why we have HTTPS. The end user notices that the padlock or key
>is lit up and decides that the host name in the URL is OK, so they enter
>their brokerage account password. If we change this so that the user is
>deciding that a *logo* is OK, I want to make sure the binding between
>the logotype and the public key is secure and that the logotype that
>appears in the certificate is properly displayed to the user.

Agreed.

>But this is completely pedantic. The original issue was that a logo can
>change appearance when it's scaled or mapped to different colors. A pink
>circle is different from a green circle for trademark and copyright
>purposes. But how do you distinguish them when they're displayed on a
>black and white screen? I don't think that web page technology has any
>magic bullets in this area. And what about blind users? With URLs, they
>can have their screen-reader read the URL back to them. Graphics will be
>completely inaccessible.

Good points about the limitations of a logo.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85EJ2r20142 for ietf-pkix-bks; Wed, 5 Sep 2001 07:19:02 -0700 (PDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85EJ0D20132; Wed, 5 Sep 2001 07:19:00 -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 IAA28994; Wed, 5 Sep 2001 08:18:57 -0600 (MDT)
Received: from sun.com (dhcp75-167 [129.148.75.167]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02353; Wed, 5 Sep 2001 10:19:01 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 05 Sep 2001 10:18:39 -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: Paul Hoffman / IMC <[e-mail]>
CC: [e-mail]
Subject: Re: charter revisions
References: <p0501040bb7a8214adf35@[128.33.84.34]> <[e-mail]> <[e-mail]> <p05100327b7baf1ca610b@[165.227.249.20]>
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>

Paul Hoffman / IMC wrote:
> At 11:58 AM -0400 9/4/01, Steve Hanna wrote:
> >Unless the author of the Internet Draft indicates otherwise, I will
> >assume that the primary purpose of putting logotypes in certificates
> >is so that users can view them to make decisions about whether the
> >certificates are trustworthy. In that case, the risks are much greater
> >than those for the use case you described.
> 
> Are the risks any greater than what we have in 2459 now with spelling
> errors or things like "FooCA type 1 certificate" vs. "FooCA type 2
> certificate"? I agree with Russ that the benefits are higher, but I'm
> not at all convinced that the risks are higher.

Yes, the risks are greater than those encountered with textual names.
For one thing, name constraints provide an effective way to limit the
portion of the name space that can be reached via a cross certificate.
No corresponding mechanism has been suggested for logotypes nor does it
seem likely that such a mechanism could be developed.

My original email cited several other security risks that are greater
for logotypes than for textual names: CAs may find it harder to verify a
certificate requester's right to use a logotype than their right to use
a textual name and logotypes may change appearance radically on
different devices. Several other risks have been pointed out in the
recent email discussion: users may not be able to distinguish one
logotype from another, users may not recall which logotype corresponds
to which entity, and logotypes are not accessible to vision-impaired
users or usable on text-only terminals.

> >Unless we can develop a fairly secure way to meet the "marketing
> >requirement" for logotypes in certificates, I would say that it is
> >our obligation as an IETF working group to NOT accept this as a
> >work item. Much better to have multiple incompatible ways
> >to do something insecure (probably resulting in little deployment
> >of this feature) than to have the PKIX working group issue an RFC
> >explaining the one true way to do it. We are in the Security area,
> >after all!
> 
> The end of that paragraph doesn't follow from the beginning of the
> paragraph. As long as the method we described doesn't have any
> security holes, it doesn't matter if we meet some pre-existing
> marketing "need". Further, some of the multiple, non-interoperable
> protocols are likely to have security problems; that is worse than
> having one protocol that doesn't meet the need of some CAs.

The whole paragraph should be considered predicated by the first clause
("Unless..."). If that clause does not apply (i.e., we can develop a
fairly secure way to place logotypes in certificates), then I don't have
any objection to having this as a PKIX work item. But I have seen no
sign that the objections raised so far can be overcome.

> Mike Myers wrote:
> >I agree with Stephen Farrell and Steve Hanna that logotypes are
> >out of scope.
> 
> They are out of scope; the discussion is whether to add them to
> the scope.

Of course, you are right. This is a charter discussion.

RFC 2418 (BCP 25) says that "IETF developed technologies should not add
insecurity to the environment in which they run." The IESG has enforced
this in the past and it seems especially pertinent to a working group in
the Security Area. I doubt that the IESG or the Security ADs will accept
this work item in our charter unless we can argue convincingly that we
can develop something that would not add insecurity to the environment
in which it is run. I don't think we're there yet.

-Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85E2wK19475 for ietf-pkix-bks; Wed, 5 Sep 2001 07:02:58 -0700 (PDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85E2uD19471 for <[e-mail]>; Wed, 5 Sep 2001 07:02:56 -0700 (PDT)
Received: from [128.33.84.34] (comsec.bbn.com [128.33.84.34]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03272; Wed, 5 Sep 2001 10:04:28 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010403b7bbdf885c0f@[128.33.84.34]>
In-Reply-To: <[e-mail]>
References: <p0501040bb7a8214adf35@[128.33.84.34]> <[e-mail]>
Date: Wed, 5 Sep 2001 09:57:05 -0400
To: Denis Pinkas <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: charter revisions
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>

At 6:51 PM +0200 9/4/01, Denis Pinkas wrote:
>Steve,
>
>This is a very late answer, but I took some more vacations. :-)
>
>During the London meeting I presented some preliminary work about an
>INFORMATIONAL RFC on PKI Disaster Planning and Recovery and I realized that
>this is not included in the new charter.
>
>I would think that the following time table could be appropriate:
>
>  3/04  PKI Disaster Planning and Recovery. INFORMATIONAL RFC.
>
>Would it still be possible to add it to the list ?
>
>I also found that 3/02 for DPV/DPD Protocols RFCs, may be a little bit
>optimistic. 3/04 would probably be more appropriate.
>
>Regards,
>
>Denis

I think it would be appropriate, as an informational RFC, analogous 
to the PKI P&P RFC.

Comments from others?

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85E2uX19470 for ietf-pkix-bks; Wed, 5 Sep 2001 07:02:56 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85E2tD19466 for <[e-mail]>; Wed, 5 Sep 2001 07:02:55 -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 KAA01734; Wed, 5 Sep 2001 10:02:53 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Wed, 05 Sep 2001 10:02:07 -0400
To: Peter Williams <[e-mail]>, [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: RE: Path validation and self-signed certificates
In-Reply-To: <[e-mail] .com>
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>

Peter,

Perhaps I could have been more clear, but I believe that the two of us agree on this issue.

At 06:21 PM 9/4/01 -0700, Peter Williams wrote:
>I disagree with your recommendation. I am thinking
>as an long-term implementor who has followed
>and interpreted the particular X.509 guidance through
>5 generations of PKI software now, when I say the 
>following:
>
>Anyone can send any set of certificates in a proposed path; it
>is for the receipient to sort, and select, which certs represent
>a trust path that meets their local security policy 
>requirements. This includes choosing certs based on their
>convergence with locally-recognised trust anchors.

I agree.  If the sender of a message includes a bag of certificates with that message, the sender can include any set of certificates that he/she wants.  It is the recipient's responsibility to sort through these certificates (and any other certificates from any other source that the recipient chooses) to create a certification path for path validation.

The message that I sent was only dealing with the sequence of certificates in the certification path to be validated.  I never intended to address the allowable contents of a certificate bag in a PKCS #7.  While it would be nice if the sender of a message only included certificates in the message that have the potential to be useful to the recipient, that is outside the scope of the e-mail that I sent as well as the previous messages in this thread.

>For example, one can send two parallel paths to
>a given recipient in the certs list of a PKCS7 
>msg, each of whose trust-anchors may be indicated by a 
>self-signed cert.
>
>The one path (of the two sent) to be actually validated depends upon the 
>receivers application software, not the PKIX path processing
>algorithm.  Upon discovery, elements of the selected path should be 
>then passed to the X.509 path processing
>algorithm implementation. In a good implementation
>of the application, the passed path will include only those 
>elements of the trust path that meet the path processing rules; 
>this should does not include the self-signed cert. If found,
>the self signed cert should be ignored by the security module
>evaluated to ensure conformance to PKIX/509.

The above paragraph is in agreement with my recommendation. A relying party application should either (a) only generate certification paths that do not include self-signed certificates or (b) ignore self-signed certificates that appear in certification paths when performing path validation.  In either case, this has nothing to do with the set of certificates that an entity may send to a potential relying party.

>Of course, how the path processing algorithm learns which
>trust anchors are legitimate is something that is 
>not-standardized, and should not be indicated to the algorithm 
>by information derived from a cert path. If the application
>before passing the cert path to X.509 path processing
>has setup a path-processing security context with the two trust
>anchors recently delivered via self-signed certs,
>then this is acceptable application practice. If we were
>building PEM, perhaps the IPRA public key would be
>pre-installed in every security context...
>
>Lets remember, its not IETF business to standardize the 
>non-Internet applications that use PKI; of which there are now
>many. They discover paths and control trust anchors however
>they wish. It is PKIX business to ensure that two path processing
>algorithm given the same inputs would
>produce the same result concerning a valid path. After 
>10 years of trying, we are about as far from this
>goal as ever, unfortunately, in Internet praxis. 
>
>Peter.
>
>-----Original Message-----
>From: David A. Cooper [mailto:[e-mail]]
>Sent: Saturday, August 25, 2001 2:33 PM
>To: [e-mail]
>Subject: RE: Path validation and self-signed certificates
>
>
>
>All,
>
>I believe that PKIX should either discourage or forbid the inclusion of
>self-signed certificates in certification paths for the following reasons:
>
>1) Section 8.1.5 of the 4th edition of X.509 states that
>
>          There are three circumstances under which a certification authority
>may
>          issue a certificate to itself:
>
>          a) as a convenient way of encoding its public key for communication
>to,
>               and storage by, its certificate users;
>
>          b) ...
>
>          For purposes of path validation, self-issued certificates of type
>a) are verified
>          with the public key contained in them, and if they are encountered
>in the path,
>          they shall be ignored.
>
>So, X.509 states that self-signed certificate are only to be used as a
>convenient way of encoding a public key, and that self-signed certificates,
>if they are encountered in a certification path are to be ignored. Thus, if
>PKIX were to allow the processing of self-signed certificates, it would not
>be compliant with X.509.
>
>2) As Peter Hesse pointed out, many CAs issue self-signed certificates with
>a minimum necessary information (e.g., a version 1 certificate with just a
>name, public key, and validity dates).  Any such certificates included in a
>certification path would result in an empty valid_policy_tree.  Old-with-new
>and new-with-old self-issued certificates are designed to be used as part of
>certification paths and so should contain all of the necessary extensions
>(e.g., basicConstraints, certificatePolicies), but self-signed certificates
>may be been issued simply as a means of distributing the public key to
>relying parties that will use that key as a trust anchor. If these
>certificates are included in, and are processed as parts of, certification
>paths, the results may be rejecting end certificates that should be have
>been accepted.
>
>3) If a CA suspects that its key has been compromised (or it otherwise
>determines that none of the certificates it has issued should be considered
>valid), it should request that every certificate issued to it be revoked (as
>is stated in the Security Considerations section).  If possible, it should
>also revoke all of the certificates it has issued (not just its self-signed
>certificate). If a CA can revoke its own self-signed certificate then it can
>revoke all of the certificates it has issued. Doing so will ensure that all
>relying parties know about the revocation, not just those relying parties
>that check to see whether the signed-signed certificate has been revoked.
>
>4) If an organization uses client software that processes self-signed
>certificates, there is risk that that organization will issue certificates
>from its own CA assuming that relying parties process self-signed
>certificates. This organization's CA may then issue self-signed certificates
>with constraints (e.g., name constraints, path length constraints, etc.)
>that they expect relying parties to see, but the CA, assuming that relying
>parties will process its self-signed certificates, may not include the
>constraints in any of its other certificates.
>
>So, if there is no set rule, there is the risk that relying parties that do
>process self-signed certificates will lose some interoperability and those
>that do not will overlook intended path processing constraints.
>
>Hiroyuki Sakakibara presented an example in which processing self-signed
>certificates helped to prevent a security breach.  In his example, A issues
>a cross-certificate to B and B's private key is compromised. Hiroyuki
>pointed out that by processing B's self-signed certificate (to see if it has
>expired or has been revoked) one may have a chance to detect the compromise
>even if A does not cooperate by revoking the certificate that it issued to
>B.  However, as he pointed out, this is not foolproof. The entity that
>compromised B's key could issue a new self-signed certificate with a later
>notAfter date along with CRLs that make it appear as if B's certificates are
>still good. If on the other hand, B were able to get its own CRLs to relying
>parties, it could just revoke all of its certificates instead of just its
>self-signed certificate, thus ensuring that any relying party that receives
>its CRLs will know that its certificates can not be trusted, whether they
>process B's self-s!
>igned certificates or not.
>
>In general though, if a certification path of the form ... --> A --> B -->
>... is being processed, I don't think there is much that B can do to protect
>relying parties from A's improper behavior. If A issues certificates to B
>with notAfter dates that are later than they should be or if A refuses to
>revoke B's certificate when requested to do so, there is little that B can
>do to protect A's relying parties (or the relying parties of any CA that
>preceded A in the path) from A, particularly in the case when B's private
>key has been compromised.  I don't think that it is worth diverging from
>X.509 and introducing interoperability problems into PKIX in an attempt to
>try.
>
>Dave
>
>At 04:37 PM 8/24/01 -0700, Ryan Hurst wrote:
> >Peter -
> >
> >I agree with your comments on self-signed certificates in chains with only
>one exception, specifically in regards to revocation. There are several
>cases where the revocation of a self-signed CA would make sense, what about
>cessationOfOperation, superseded and affiliationChanged? These reasons do
>not imply any sort of compromise of key material. We make many "known
>assumptions" in PKI and the catch 22 of key material management and trust is
>one of them, without these "known assumptions" many of the things in son-off
>fall apart.
> >
> >Ryan




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85E2PS19452 for ietf-pkix-bks; Wed, 5 Sep 2001 07:02:25 -0700 (PDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85E2OD19444 for <[e-mail]>; Wed, 5 Sep 2001 07:02:24 -0700 (PDT)
Received: from [128.33.84.34] (comsec.bbn.com [128.33.84.34]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03263; Wed, 5 Sep 2001 10:04:26 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010402b7bbdf2243fc@[128.33.84.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Wed, 5 Sep 2001 09:56:11 -0400
To: Rich Salz <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: charter revisions
Cc: Michael Myers <[e-mail]>, [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>

At 3:55 PM -0400 9/4/01, Rich Salz wrote:
>Is the CA processing for adding a logo extension any different from
>adding any other extension?  I don't see how/why.
>
>Can't this work item be accomplished just by an RFC that assigns OID's
>to some popular image formats?
>
>	/r$
>
>--
>Zolera Systems, Your Key to Online Integrity
>Securing Web services: XML, SOAP, Dig-sig, Encryption
>http://www.zolera.com

Although we have yet to decide how (or maybe even whether) to address 
this problem, it seems likely that more is needed than just an OID 
for an image, e.g., because we may not want to carry the image in the 
cert, but rather have a pointer to the image.

Steve




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85Dtuf18615 for ietf-pkix-bks; Wed, 5 Sep 2001 06:55:56 -0700 (PDT)
Received: from exchsvr1.entegrity.com (exchsvr1.entegrity.com [207.215.19.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85DttD18611 for <[e-mail]>; Wed, 5 Sep 2001 06:55:55 -0700 (PDT)
Received: from cooper.entegrity.com (dave.entegrity.se [195.100.88.62]) by exchsvr1.entegrity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id PGA42AG2; Wed, 5 Sep 2001 07:00:44 -0700
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 05 Sep 2001 15:53:30 +0200
To: Denis Pinkas <[e-mail]>
From: Nada Kapidzic Cicovic <[e-mail]>
Subject: Re: Removing expired certificates from CRLs.....
Cc: Ryan Hurst <[e-mail]>, IETF-PKIX <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/html; 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>

<html>
At 03:22 PM 9/5/01 +0200, Denis Pinkas wrote:<br>
<blockquote type=cite class=cite cite>Nada,<br><br>
Which text are using using ? In son-of-RC2459 there is no section
8.6.2.2.<br>
as you indicate.</blockquote><br>
Denis,<br><br>
I was making comments on the text which Ryan extracted in his mail,
assuming that they were from the son-of-RFC2459.<br><br>
In particular the last sentence in this paragraph:<br><br>
The <font size=2><b>distributionPoint </b></font>component contains the
name of the distribution point in one or more name forms. If this field
is absent, the CRL shall contain entries for all revoked certificates
issued by the CRL issuer. <b><i>After a certificate appears on a CRL, it
is deleted from a subsequent CRL after the certificate's 
expiry.<br><br>
</i></b>However, after getting your comment I realized that this sentence
and the referred section 8.6.2.2 comes from the X.509 (the latest version
that I have on my disk is X_509_4thEditionDraftV6, and it contains the
above text). <br><br>
The current text of the son-of-RFC2459 does not seem to contain it or any
other misleading sentences regarding this issue. <br><br>
Sorry for the confusion.<br><br>
Nada<br><br>
<br><br>
<blockquote type=cite class=cite cite>Please be more specific on the
exact sentence that you think is not<br>
appropriate in son-of-RC2459 and which exact change you would like to
be<br>
done.<br><br>
Denis<br><br>
&nbsp;<br>
&gt; &gt;Nada and Ryan,<br>
&gt; &gt;<br>
&gt; &gt; &gt; Ryan,<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Some years ago we at Entegrity also had similar
discussion. We were<br>
&gt; &gt; &gt; positive CRLs were not to contain the information about
the expired<br>
&gt; &gt; &gt; certificates, until we came across some industry CA CRLs
containing<br>
&gt; &gt; &gt; information about all revoked certificates. We then looked
into 2459<br>
&gt; &gt; &gt; (draft in those days) and X.509 text and came to the
conclusion that<br>
&gt; &gt; &gt; deleting info about expired certificates from a CRL is
only an option.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I am not sure what was the intention of the original
authors of X.509<br>
&gt; &gt; &gt; (perhaps Sharon and Hoyt know more about it), but the
current industry<br>
&gt; &gt; &gt; practice seems to be a mixture of both approaches.<br>
&gt; &gt;<br>
&gt; &gt;At the very beginning, when ISO started the work,
non-repudiation was not<br>
&gt; &gt;considered, but only authentication and data origin
authentication.<br>
&gt; &gt;<br>
&gt; &gt; &gt; My personal opinion is that keeping all revoked
certificates info in CRLs<br>
&gt; &gt; &gt; brings more problems than benefits. However, it is
questionable whether<br>
&gt; &gt; &gt; PKIX needs to take a vote for one approach or the
other.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; In any case I would suggest that the text of 2459 be
modified so that it<br>
&gt; &gt; &gt; has a MAY (or a MUST) consistently in all places where
deleting expired<br>
&gt; &gt; &gt; certificates revocation info from CRLs is mentioned. The
current text only<br>
&gt; &gt; &gt; brings confusion, as you have already pointed out.<br>
&gt; &gt;<br>
&gt; &gt;In all the sentences that have been extracted below, I could not
find a<br>
&gt; &gt;place where a change would be necessary. So I believe that the
current text<br>
&gt; &gt;is OK : it tells how long revoked certificates MUST be kept in a
CRL but<br>
&gt; &gt;does not forbid to maintain them longer. I agree that
maintaining them too<br>
&gt; <br>
&gt; The text in 8.6.2.2 does not mention the possibility of leaving the
expired<br>
&gt; certificates identifiers in CRL. The last extracted sentence is
very<br>
&gt; explicit in requiring removal of revocation info for expired
certificates.<br>
&gt; <br>
&gt; &gt;long would be a problem because of the increasing size of the
CRL, hence why<br>
&gt; &gt;CRL information should be captured when still available, in case
a<br>
&gt; &gt;non-repudiation service is supported.<br>
&gt; <br>
&gt; I could not agree more. Perhaps DPV/DPD work could include such
guidelines.<br>
&gt; <br>
&gt; &gt;We could add is a recommendation like: &quot;Certificates
identifiers<br>
&gt; &gt;for certificates that contain the NR bit in the KeyUsage
extension field<br>
&gt; &gt;SHOULD be maintained in a CRL a few days or weeks after they
have expired.&quot;<br>
&gt; &gt;<br>
&gt; &gt;However, it seems rather late to add such a sentence, since we
passed IETF<br>
&gt; &gt;last call. I leave the issue to the editors ...<br>
&gt; <br>
&gt; You are right. Since the document has already progressed this far,
it may<br>
&gt; not be worth making additional modifications.<br>
&gt; <br>
&gt; Nada<br>
&gt; <br>
&gt; &gt;Denis<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; &gt; Nada<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; At 08:49 PM 9/4/01 -0700, Ryan Hurst wrote:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; I was speaking with Peter Williams today about the
removal of expired<br>
&gt; &gt; &gt; &gt; certificates from CRLs; I have always been under the
belief that this<br>
&gt; &gt; &gt; &gt; behavior was optional, I vaguely remembered reading
text in 2459 along<br>
&gt; &gt; &gt; &gt; those lines; additionally I know of several
commercial CAs that do not<br>
&gt; &gt; &gt; &gt; remove the expired certificates from their CRLs.
Peter on the other hand<br>
&gt; &gt; &gt; &gt; was under the impression that it was a mandate to
remove CRLs; he too<br>
&gt; &gt; &gt; &gt; remembered reading text in 2459 to support is
position.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; So we each pulled out the RFC and found that we were
both right!<br>
&gt; &gt; &gt; &gt; Specifically both sections 3.3 and 8.6.2.2 have text
on this subject:<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; 3.3&nbsp; Revocation<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; When a certificate is issued, it is expected to be in
use for its entire<br>
&gt; &gt; &gt; &gt; validity period.&nbsp; However, various circumstances
may cause a certificate<br>
&gt; &gt; &gt; &gt; to become invalid prior to the expiration of the
validity period.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; ....<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; An entry is added to the CRL as part of the next
update following<br>
&gt; &gt; &gt; &gt; notification of revocation. An entry may be removed
from the CRL after<br>
&gt; &gt; &gt; &gt; appearing on one regularly scheduled CRL issued
beyond the revoked<br>
&gt; &gt; &gt; &gt; certificate's validity period.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; 8.6.2.2 Issuing distribution point extension<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; This CRL extension field identifies the CRL
distribution point for this<br>
&gt; &gt; &gt; &gt; particular CRL, and indicates if the CRL is limited
to revocations for<br>
&gt; &gt; &gt; &gt; end-entity certificates only, for authority
certificates only, or for a<br>
&gt; &gt; &gt; &gt; limited set of reasons only. The CRL is signed by the
CRL issuer's key-<br>
&gt; &gt; &gt; &gt; CRL distribution points do not have their own key
pairs. However, for a<br>
&gt; &gt; &gt; &gt; CRL distributed via the Directory, the CRL is stored
in the entry of the<br>
&gt; &gt; &gt; &gt; CRL distribution point, which may not be the
directory entry of the CRL<br>
&gt; &gt; &gt; &gt; issuer. If this field is absent, the CRL shall
contain entries for all<br>
&gt; &gt; &gt; &gt; revoked unexpired certificates issued by the CRL
issuer.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; ....<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; The distributionPoint component contains the name of
the distribution<br>
&gt; &gt; &gt; &gt; point in one or more name forms. If this field is
absent, the CRL shall<br>
&gt; &gt; &gt; &gt; contain entries for all revoked certificates issued
by the CRL issuer.<br>
&gt; &gt; &gt; &gt; After a certificate appears on a CRL, it is deleted
from a subsequent<br>
&gt; &gt; &gt; &gt; CRL after the certificate's expiry.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Although section 8.6.2.2 is specifically in regards
to CRLdps, any<br>
&gt; &gt; &gt; &gt; difference between full CRLs and CRLdps in this case
I feel would be an<br>
&gt; &gt; &gt; &gt; arbitrary one.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Now logically it makes sense to remove certificates
that are expired<br>
&gt; &gt; &gt; &gt; from CRLs to control size, yes this has a negative
point specifically it<br>
&gt; &gt; &gt; &gt; prevents CRLs from being used as a non-repudiation
source; but this is<br>
&gt; &gt; &gt; &gt; mute due to many other issues.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; That being the case I think; and I believe Peter
would agree the correct<br>
&gt; &gt; &gt; &gt; thing to do is to remove these expired/revoked
entries from the CRL.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; The question now is what is the PKIX stance on this
matter?<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Ryan M. Hurst<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; ValiCert, Inc.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;It may roundly be
asserted that human ingenuity cannot concoct a<br>
&gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cipher which human
ingenuity cannot resolve.&quot;<br>
&gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -Edgar Allan Poe<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; </blockquote></html>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85DMip17749 for ietf-pkix-bks; Wed, 5 Sep 2001 06:22:44 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85DMgD17745 for <[e-mail]>; Wed, 5 Sep 2001 06:22:43 -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 PAA46864; Wed, 5 Sep 2001 15:24:41 +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 PAA05890; Wed, 5 Sep 2001 15:22:08 +0200
Message-ID: <[e-mail]>
Date: Wed, 05 Sep 2001 15:22:10 +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: Nada Kapidzic Cicovic <[e-mail]>
CC: Ryan Hurst <[e-mail]>, IETF-PKIX <[e-mail]>
Subject: Re: Removing expired certificates from 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>

Nada,

Which text are using using ? In son-of-RC2459 there is no section 8.6.2.2.
as you indicate.

Please be more specific on the exact sentence that you think is not
appropriate in son-of-RC2459 and which exact change you would like to be
done.

Denis

 
> >Nada and Ryan,
> >
> > > Ryan,
> > >
> > > Some years ago we at Entegrity also had similar discussion. We were
> > > positive CRLs were not to contain the information about the expired
> > > certificates, until we came across some industry CA CRLs containing
> > > information about all revoked certificates. We then looked into 2459
> > > (draft in those days) and X.509 text and came to the conclusion that
> > > deleting info about expired certificates from a CRL is only an option.
> > >
> > > I am not sure what was the intention of the original authors of X.509
> > > (perhaps Sharon and Hoyt know more about it), but the current industry
> > > practice seems to be a mixture of both approaches.
> >
> >At the very beginning, when ISO started the work, non-repudiation was not
> >considered, but only authentication and data origin authentication.
> >
> > > My personal opinion is that keeping all revoked certificates info in CRLs
> > > brings more problems than benefits. However, it is questionable whether
> > > PKIX needs to take a vote for one approach or the other.
> > >
> > > In any case I would suggest that the text of 2459 be modified so that it
> > > has a MAY (or a MUST) consistently in all places where deleting expired
> > > certificates revocation info from CRLs is mentioned. The current text only
> > > brings confusion, as you have already pointed out.
> >
> >In all the sentences that have been extracted below, I could not find a
> >place where a change would be necessary. So I believe that the current text
> >is OK : it tells how long revoked certificates MUST be kept in a CRL but
> >does not forbid to maintain them longer. I agree that maintaining them too
> 
> The text in 8.6.2.2 does not mention the possibility of leaving the expired
> certificates identifiers in CRL. The last extracted sentence is very
> explicit in requiring removal of revocation info for expired certificates.
> 
> >long would be a problem because of the increasing size of the CRL, hence why
> >CRL information should be captured when still available, in case a
> >non-repudiation service is supported.
> 
> I could not agree more. Perhaps DPV/DPD work could include such guidelines.
> 
> >We could add is a recommendation like: "Certificates identifiers
> >for certificates that contain the NR bit in the KeyUsage extension field
> >SHOULD be maintained in a CRL a few days or weeks after they have expired."
> >
> >However, it seems rather late to add such a sentence, since we passed IETF
> >last call. I leave the issue to the editors ...
> 
> You are right. Since the document has already progressed this far, it may
> not be worth making additional modifications.
> 
> Nada
> 
> >Denis
> >
> >
> > > Nada
> > >
> > > At 08:49 PM 9/4/01 -0700, Ryan Hurst wrote:
> > >
> > > > I was speaking with Peter Williams today about the removal of expired
> > > > certificates from CRLs; I have always been under the belief that this
> > > > behavior was optional, I vaguely remembered reading text in 2459 along
> > > > those lines; additionally I know of several commercial CAs that do not
> > > > remove the expired certificates from their CRLs. Peter on the other hand
> > > > was under the impression that it was a mandate to remove CRLs; he too
> > > > remembered reading text in 2459 to support is position.
> > > >
> > > >
> > > >
> > > > So we each pulled out the RFC and found that we were both right!
> > > > Specifically both sections 3.3 and 8.6.2.2 have text on this subject:
> > > >
> > > >
> > > >
> > > > 3.3  Revocation
> > > >
> > > > When a certificate is issued, it is expected to be in use for its entire
> > > > validity period.  However, various circumstances may cause a certificate
> > > > to become invalid prior to the expiration of the validity period.
> > > >
> > > >
> > > >
> > > > ....
> > > >
> > > >
> > > >
> > > > An entry is added to the CRL as part of the next update following
> > > > notification of revocation. An entry may be removed from the CRL after
> > > > appearing on one regularly scheduled CRL issued beyond the revoked
> > > > certificate's validity period.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > 8.6.2.2 Issuing distribution point extension
> > > >
> > > > This CRL extension field identifies the CRL distribution point for this
> > > > particular CRL, and indicates if the CRL is limited to revocations for
> > > > end-entity certificates only, for authority certificates only, or for a
> > > > limited set of reasons only. The CRL is signed by the CRL issuer's key-
> > > > CRL distribution points do not have their own key pairs. However, for a
> > > > CRL distributed via the Directory, the CRL is stored in the entry of the
> > > > CRL distribution point, which may not be the directory entry of the CRL
> > > > issuer. If this field is absent, the CRL shall contain entries for all
> > > > revoked unexpired certificates issued by the CRL issuer.
> > > >
> > > >
> > > >
> > > > ....
> > > >
> > > >
> > > >
> > > > The distributionPoint component contains the name of the distribution
> > > > point in one or more name forms. If this field is absent, the CRL shall
> > > > contain entries for all revoked certificates issued by the CRL issuer.
> > > > After a certificate appears on a CRL, it is deleted from a subsequent
> > > > CRL after the certificate's expiry.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Although section 8.6.2.2 is specifically in regards to CRLdps, any
> > > > difference between full CRLs and CRLdps in this case I feel would be an
> > > > arbitrary one.
> > > >
> > > >
> > > >
> > > > Now logically it makes sense to remove certificates that are expired
> > > > from CRLs to control size, yes this has a negative point specifically it
> > > > prevents CRLs from being used as a non-repudiation source; but this is
> > > > mute due to many other issues.
> > > >
> > > >
> > > >
> > > > That being the case I think; and I believe Peter would agree the correct
> > > > thing to do is to remove these expired/revoked entries from the CRL.
> > > >
> > > >
> > > >
> > > > The question now is what is the PKIX stance on this matter?
> > > >
> > > >
> > > >
> > > > Ryan M. Hurst
> > > >
> > > > ValiCert, Inc.
> > > >
> > > >
> > > >
> > > >      "It may roundly be asserted that human ingenuity cannot concoct a
> > > >      cipher which human ingenuity cannot resolve."
> > > >      -Edgar Allan Poe
> > > >
> > > >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85DDri16986 for ietf-pkix-bks; Wed, 5 Sep 2001 06:13:53 -0700 (PDT)
Received: from web13703.mail.yahoo.com (web13703.mail.yahoo.com [216.136.175.136]) by above.proper.com (8.11.6/8.11.3) with SMTP id f85DDqD16982 for <[e-mail]>; Wed, 5 Sep 2001 06:13:52 -0700 (PDT)
Message-ID: <[e-mail]>
Received: from [61.139.82.190] by web13703.mail.yahoo.com via HTTP; Wed, 05 Sep 2001 21:13:53 CST
Date: Wed, 5 Sep 2001 21:13:53 +0800 (CST)
From: =?gb2312?q?li=20yunfeng?= <[e-mail]>
Subject: Re: Removing expired certificates from CRLs.....
To: Ryan Hurst <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 8bit
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>

Ryan:
I now  are developing PKIX software, and encouted the
same question as yours, Because befor one can check
the CRL, one may first check  the certificate's
validate period. So I think remove the expired
certificate from the CRL will be benefit to keep the
CRL small at least 

forward li

 --- Ryan Hurst <[e-mail]> µÄÕýÎÄ£º> I was
speaking with Peter Williams today about the
> removal of expired
> certificates from CRLs; I have always been under the
> belief that this
> behavior was optional, I vaguely remembered reading
> text in 2459 along those
> lines; additionally I know of several commercial CAs
> that do not remove the
> expired certificates from their CRLs. Peter on the
> other hand was under the
> impression that it was a mandate to remove CRLs; he
> too remembered reading
> text in 2459 to support is position.
>  
> So we each pulled out the RFC and found that we were
> both right!
> Specifically both sections 3.3 and 8.6.2.2 have text
> on this subject:
>  
> 3.3  Revocation
> When a certificate is issued, it is expected to be
> in use for its entire
> validity period.  However, various circumstances may
> cause a certificate to
> become invalid prior to the expiration of the
> validity period.
>  
> ....
>  
> An entry is added to the CRL as part of the next
> update following
> notification of revocation. An entry may be removed
> from the CRL after
> appearing on one regularly scheduled CRL issued
> beyond the revoked
> certificate's validity period.
>  
>  
>  
> 8.6.2.2 Issuing distribution point extension
> This CRL extension field identifies the CRL
> distribution point for this
> particular CRL, and indicates if the CRL is limited
> to revocations for
> end-entity certificates only, for authority
> certificates only, or for a
> limited set of reasons only. The CRL is signed by
> the CRL issuer's key- CRL
> distribution points do not have their own key pairs.
> However, for a CRL
> distributed via the Directory, the CRL is stored in
> the entry of the CRL
> distribution point, which may not be the directory
> entry of the CRL issuer.
> If this field is absent, the CRL shall contain
> entries for all revoked
> unexpired certificates issued by the CRL issuer.
>  
> ....
>  
> The distributionPoint component contains the name of
> the distribution point
> in one or more name forms. If this field is absent,
> the CRL shall contain
> entries for all revoked certificates issued by the
> CRL issuer. After a
> certificate appears on a CRL, it is deleted from a
> subsequent CRL after the
> certificate's expiry.
>  
>  
> Although section 8.6.2.2 is specifically in regards
> to CRLdps, any
> difference between full CRLs and CRLdps in this case
> I feel would be an
> arbitrary one. 
>  
> Now logically it makes sense to remove certificates
> that are expired from
> CRLs to control size, yes this has a negative point
> specifically it prevents
> CRLs from being used as a non-repudiation source;
> but this is mute due to
> many other issues.
>  
> That being the case I think; and I believe Peter
> would agree the correct
> thing to do is to remove these expired/revoked
> entries from the CRL. 
>  
> The question now is what is the PKIX stance on this
> matter?
>  
> Ryan M. Hurst
> ValiCert, Inc.
>  
> "It may roundly be asserted that human ingenuity
> cannot concoct a cipher
> which human ingenuity cannot resolve."
> -Edgar Allan Poe
>  
>  

_________________________________________________________
Do You Yahoo!? µÇ¼Ãâ·ÑÑÅ»¢µçÓÊ! http://mail.yahoo.com.cn

<font color=#6666FF>ÎÞÁÄ£¿ÓôÃÆ£¿¸ßÐË£¿Ã»ÀíÓÉ£¿¶¼À´ÁÄÌì°É£¡</font>¡ª¡ª 
ÑÅ»¢È«ÐÂÁÄÌìÊÒ! http://cn.chat.yahoo.com/c/roomlist.html


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85DCKK16940 for ietf-pkix-bks; Wed, 5 Sep 2001 06:12:20 -0700 (PDT)
Received: from web13707.mail.yahoo.com (web13707.mail.yahoo.com [216.136.175.140]) by above.proper.com (8.11.6/8.11.3) with SMTP id f85DCID16934 for <[e-mail]>; Wed, 5 Sep 2001 06:12:18 -0700 (PDT)
Message-ID: <[e-mail]>
Received: from [61.139.82.190] by web13707.mail.yahoo.com via HTTP; Wed, 05 Sep 2001 21:12:19 CST
Date: Wed, 5 Sep 2001 21:12:19 +0800 (CST)
From: =?gb2312?q?li=20yunfeng?= <[e-mail]>
Subject: Re: Removing expired certificates from CRLs.....
To: Nada Kapidzic Cicovic <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 8bit
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>

Ryan:
I now  are developing PKIX software, and encouted the
same question as yours, Because befor one can check
the CRL, one may first check  the certificate's
validate period. So I think remove the expired
certificate from the CRL will be benefit to keep the
CRL small. 

forward li

--- Nada Kapidzic Cicovic <[e-mail]>
µÄÕýÎÄ£º
<HR>

<html>
Ryan,<br><br>
Some years ago we at Entegrity also had similar
discussion. We were
positive CRLs were not to contain the information
about the expired
certificates, until we came across some industry CA
CRLs containing
information about all revoked certificates. We then
looked into 2459
(draft in those days) and X.509 text and came to the
conclusion that
deleting info about expired certificates from a CRL is
only an
option.<br><br>
I am not sure what was the intention of the original
authors of X.509
(perhaps Sharon and Hoyt know more about it), but the
current industry
practice seems to be a mixture of both
approaches.<br><br>
My personal opinion is that keeping all revoked
certificates info in CRLs
brings more problems than benefits. However, it is
questionable whether
PKIX needs to take a vote for one approach or the
other. <br><br>
In any case I would suggest that the text of 2459 be
modified so that it
has a MAY (or a MUST) c<font face="Arial,
Helvetica">onsistently</font>
in all places where deleting expired certificates
revocation info from
CRLs is mentioned. The current text only brings
confusion, as you have
already pointed out.<br><br>
Nada<br><br>
At 08:49 PM 9/4/01 -0700, Ryan Hurst wrote:<br><br>
<blockquote type=cite class=cite cite><font
face="arial" size=2>I was
speaking with Peter Williams today about the removal
of expired
certificates from CRLs; I have always been under the
belief that this
behavior was optional, I vaguely remembered reading
text in 2459 along
those lines; additionally I know of several commercial
CAs that do not
remove the expired certificates from their CRLs. Peter
on the other hand
was under the impression that it was a mandate to
remove CRLs; he too
remembered reading text in 2459 to support is
position.<br>
</font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2>So we each pulled out the
RFC and found that we
were both right! Specifically both sections 3.3 and
8.6.2.2 have text on
this subject:<br>
</font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2><b>3.3&nbsp; Revocation<br>
</b></font><br>
<font face="arial" size=2>When a certificate is
issued, it is expected to
be in use for its entire validity period.&nbsp;
However, various
circumstances may cause a certificate to become
invalid prior to the
expiration of the validity period.<br>
</font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2>....<br>
</font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2>An entry is added to the CRL
as part of the
next update following notification of revocation.
<b><i>An entry may be
removed from the CRL after appearing on one regularly
scheduled CRL
issued beyond the revoked certificate's validity
period.<br>
</i></b></font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2><b>8.6.2.2 Issuing
distribution point
extension<br>
</b></font><br>
<font face="arial" size=2>This CRL extension field
identifies the CRL
distribution point for this particular CRL, and
indicates if the CRL is
limited to revocations for end-entity certificates
only, for authority
certificates only, or for a limited set of reasons
only. The CRL is
signed by the CRL issuer's key- CRL distribution
points do not have their
own key pairs. However, for a CRL distributed via the
Directory, the CRL
is stored in the entry of the CRL distribution point,
which may not be
the directory entry of the CRL issuer.<i> <b>If this
field is absent, the
CRL shall contain entries for all revoked unexpired
certificates issued
by the CRL issuer.<br>
</i></b></font><br>
<font face="arial" size=2><i>&nbsp;<br>
</i></font><br>
<font face="arial" size=2>....<br>
</font><br>
<font face="arial" size=2 color="#0000FF">&nbsp;<br>
</font><br>
<font face="arial" size=2>The
</font><font face="arial" size=1><b>distributionPoint
</b></font><font face="arial" size=2>component
contains the name of the
distribution point in one or more name forms. If this
field is absent,
the CRL shall contain entries for all revoked
certificates issued by the
CRL issuer. <b><i>After a certificate appears on a
CRL, it is deleted
from a subsequent CRL after the certificate's
expiry.<br>
</i></b></font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2>Although section 8.6.2.2 is
specifically in
regards to CRLdps, any difference between full CRLs
and CRLdps in this
case I feel would be an arbitrary one. <br>
</font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2>Now logically it makes sense
to remove
certificates that are expired from CRLs to control
size, yes this has a
negative point specifically it prevents CRLs from
being used as a
non-repudiation source; but this is mute due to many
other issues.<br>
</font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2>That being the case I think;
and I believe
Peter would agree the correct thing to do is to remove
these
expired/revoked entries from the CRL. <br>
</font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2>The question now is what is
the PKIX stance on
this matter?<br>
</font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2>Ryan M. Hurst<br>
</font><br>
<font face="arial" size=2>ValiCert, Inc.<br>
</font><br>
<font face="arial" size=2>&nbsp;</font>
<dl><font face="Times New Roman, Times">
<dd>&quot;It may roundly be asserted that human
ingenuity cannot concoct
a cipher which human ingenuity cannot
resolve.&quot;</i></font><font face="Times New Roman,
Times">
<dd>-Edgar Allan Poe</font>
</dl><font face="Times New Roman,
Times">&nbsp;</font></blockquote></html>
 

_________________________________________________________
Do You Yahoo!? µÇ¼Ãâ·ÑÑÅ»¢µçÓÊ! http://mail.yahoo.com.cn

<font color=#6666FF>ÎÞÁÄ£¿ÓôÃÆ£¿¸ßÐË£¿Ã»ÀíÓÉ£¿¶¼À´ÁÄÌì°É£¡</font>¡ª¡ª 
ÑÅ»¢È«ÐÂÁÄÌìÊÒ! http://cn.chat.yahoo.com/c/roomlist.html


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85Ct0P15631 for ietf-pkix-bks; Wed, 5 Sep 2001 05:55:00 -0700 (PDT)
Received: from exchsvr1.entegrity.com (exchsvr1.entegrity.com [207.215.19.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85CswD15627 for <[e-mail]>; Wed, 5 Sep 2001 05:54:58 -0700 (PDT)
Received: from cooper.entegrity.com (dave.entegrity.se [195.100.88.62]) by exchsvr1.entegrity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id PGA42AB1; Wed, 5 Sep 2001 05:59:49 -0700
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 05 Sep 2001 14:52:40 +0200
To: Denis Pinkas <[e-mail]>
From: Nada Kapidzic Cicovic <[e-mail]>
Subject: Re: Removing expired certificates from CRLs.....
Cc: Ryan Hurst <[e-mail]>, IETF-PKIX <[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>

At 02:12 PM 9/5/01 +0200, Denis Pinkas wrote:
>Nada and Ryan,
>
> > Ryan,
> >
> > Some years ago we at Entegrity also had similar discussion. We were
> > positive CRLs were not to contain the information about the expired
> > certificates, until we came across some industry CA CRLs containing
> > information about all revoked certificates. We then looked into 2459
> > (draft in those days) and X.509 text and came to the conclusion that
> > deleting info about expired certificates from a CRL is only an option.
> >
> > I am not sure what was the intention of the original authors of X.509
> > (perhaps Sharon and Hoyt know more about it), but the current industry
> > practice seems to be a mixture of both approaches.
>
>At the very beginning, when ISO started the work, non-repudiation was not
>considered, but only authentication and data origin authentication.
>
> > My personal opinion is that keeping all revoked certificates info in CRLs
> > brings more problems than benefits. However, it is questionable whether
> > PKIX needs to take a vote for one approach or the other.
> >
> > In any case I would suggest that the text of 2459 be modified so that it
> > has a MAY (or a MUST) consistently in all places where deleting expired
> > certificates revocation info from CRLs is mentioned. The current text only
> > brings confusion, as you have already pointed out.
>
>In all the sentences that have been extracted below, I could not find a
>place where a change would be necessary. So I believe that the current text
>is OK : it tells how long revoked certificates MUST be kept in a CRL but
>does not forbid to maintain them longer. I agree that maintaining them too

The text in 8.6.2.2 does not mention the possibility of leaving the expired 
certificates identifiers in CRL. The last extracted sentence is very 
explicit in requiring removal of revocation info for expired certificates.

>long would be a problem because of the increasing size of the CRL, hence why
>CRL information should be captured when still available, in case a
>non-repudiation service is supported.

I could not agree more. Perhaps DPV/DPD work could include such guidelines.


>We could add is a recommendation like: "Certificates identifiers
>for certificates that contain the NR bit in the KeyUsage extension field
>SHOULD be maintained in a CRL a few days or weeks after they have expired."
>
>However, it seems rather late to add such a sentence, since we passed IETF
>last call. I leave the issue to the editors ...

You are right. Since the document has already progressed this far, it may 
not be worth making additional modifications.

Nada


>Denis
>
>
> > Nada
> >
> > At 08:49 PM 9/4/01 -0700, Ryan Hurst wrote:
> >
> > > I was speaking with Peter Williams today about the removal of expired
> > > certificates from CRLs; I have always been under the belief that this
> > > behavior was optional, I vaguely remembered reading text in 2459 along
> > > those lines; additionally I know of several commercial CAs that do not
> > > remove the expired certificates from their CRLs. Peter on the other hand
> > > was under the impression that it was a mandate to remove CRLs; he too
> > > remembered reading text in 2459 to support is position.
> > >
> > >
> > >
> > > So we each pulled out the RFC and found that we were both right!
> > > Specifically both sections 3.3 and 8.6.2.2 have text on this subject:
> > >
> > >
> > >
> > > 3.3  Revocation
> > >
> > > When a certificate is issued, it is expected to be in use for its entire
> > > validity period.  However, various circumstances may cause a certificate
> > > to become invalid prior to the expiration of the validity period.
> > >
> > >
> > >
> > > ....
> > >
> > >
> > >
> > > An entry is added to the CRL as part of the next update following
> > > notification of revocation. An entry may be removed from the CRL after
> > > appearing on one regularly scheduled CRL issued beyond the revoked
> > > certificate's validity period.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > 8.6.2.2 Issuing distribution point extension
> > >
> > > This CRL extension field identifies the CRL distribution point for this
> > > particular CRL, and indicates if the CRL is limited to revocations for
> > > end-entity certificates only, for authority certificates only, or for a
> > > limited set of reasons only. The CRL is signed by the CRL issuer's key-
> > > CRL distribution points do not have their own key pairs. However, for a
> > > CRL distributed via the Directory, the CRL is stored in the entry of the
> > > CRL distribution point, which may not be the directory entry of the CRL
> > > issuer. If this field is absent, the CRL shall contain entries for all
> > > revoked unexpired certificates issued by the CRL issuer.
> > >
> > >
> > >
> > > ....
> > >
> > >
> > >
> > > The distributionPoint component contains the name of the distribution
> > > point in one or more name forms. If this field is absent, the CRL shall
> > > contain entries for all revoked certificates issued by the CRL issuer.
> > > After a certificate appears on a CRL, it is deleted from a subsequent
> > > CRL after the certificate's expiry.
> > >
> > >
> > >
> > >
> > >
> > > Although section 8.6.2.2 is specifically in regards to CRLdps, any
> > > difference between full CRLs and CRLdps in this case I feel would be an
> > > arbitrary one.
> > >
> > >
> > >
> > > Now logically it makes sense to remove certificates that are expired
> > > from CRLs to control size, yes this has a negative point specifically it
> > > prevents CRLs from being used as a non-repudiation source; but this is
> > > mute due to many other issues.
> > >
> > >
> > >
> > > That being the case I think; and I believe Peter would agree the correct
> > > thing to do is to remove these expired/revoked entries from the CRL.
> > >
> > >
> > >
> > > The question now is what is the PKIX stance on this matter?
> > >
> > >
> > >
> > > Ryan M. Hurst
> > >
> > > ValiCert, Inc.
> > >
> > >
> > >
> > >      "It may roundly be asserted that human ingenuity cannot concoct a
> > >      cipher which human ingenuity cannot resolve."
> > >      -Edgar Allan Poe
> > >
> > >



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85CCjF13803 for ietf-pkix-bks; Wed, 5 Sep 2001 05:12:45 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85CChD13795 for <[e-mail]>; Wed, 5 Sep 2001 05:12:44 -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 OAA39116; Wed, 5 Sep 2001 14:14: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 OAA16324; Wed, 5 Sep 2001 14:12:09 +0200
Message-ID: <[e-mail]>
Date: Wed, 05 Sep 2001 14:12:11 +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: Nada Kapidzic Cicovic <[e-mail]>
CC: Ryan Hurst <[e-mail]>, IETF-PKIX <[e-mail]>
Subject: Re: Removing expired certificates from 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>

Nada and Ryan,

> Ryan,
> 
> Some years ago we at Entegrity also had similar discussion. We were
> positive CRLs were not to contain the information about the expired
> certificates, until we came across some industry CA CRLs containing
> information about all revoked certificates. We then looked into 2459
> (draft in those days) and X.509 text and came to the conclusion that
> deleting info about expired certificates from a CRL is only an option.
> 
> I am not sure what was the intention of the original authors of X.509
> (perhaps Sharon and Hoyt know more about it), but the current industry
> practice seems to be a mixture of both approaches.

At the very beginning, when ISO started the work, non-repudiation was not
considered, but only authentication and data origin authentication.

> My personal opinion is that keeping all revoked certificates info in CRLs
> brings more problems than benefits. However, it is questionable whether
> PKIX needs to take a vote for one approach or the other.
> 
> In any case I would suggest that the text of 2459 be modified so that it
> has a MAY (or a MUST) consistently in all places where deleting expired
> certificates revocation info from CRLs is mentioned. The current text only
> brings confusion, as you have already pointed out.

In all the sentences that have been extracted below, I could not find a
place where a change would be necessary. So I believe that the current text
is OK : it tells how long revoked certificates MUST be kept in a CRL but
does not forbid to maintain them longer. I agree that maintaining them too
long would be a problem because of the increasing size of the CRL, hence why
CRL information should be captured when still available, in case a
non-repudiation service is supported.

We could add is a recommendation like: "Certificates identifiers
for certificates that contain the NR bit in the KeyUsage extension field
SHOULD be maintained in a CRL a few days or weeks after they have expired." 

However, it seems rather late to add such a sentence, since we passed IETF
last call. I leave the issue to the editors ...

Denis


> Nada
> 
> At 08:49 PM 9/4/01 -0700, Ryan Hurst wrote:
> 
> > I was speaking with Peter Williams today about the removal of expired
> > certificates from CRLs; I have always been under the belief that this
> > behavior was optional, I vaguely remembered reading text in 2459 along
> > those lines; additionally I know of several commercial CAs that do not
> > remove the expired certificates from their CRLs. Peter on the other hand
> > was under the impression that it was a mandate to remove CRLs; he too
> > remembered reading text in 2459 to support is position.
> >
> >
> >
> > So we each pulled out the RFC and found that we were both right!
> > Specifically both sections 3.3 and 8.6.2.2 have text on this subject:
> >
> >
> >
> > 3.3  Revocation
> >
> > When a certificate is issued, it is expected to be in use for its entire
> > validity period.  However, various circumstances may cause a certificate
> > to become invalid prior to the expiration of the validity period.
> >
> >
> >
> > ....
> >
> >
> >
> > An entry is added to the CRL as part of the next update following
> > notification of revocation. An entry may be removed from the CRL after
> > appearing on one regularly scheduled CRL issued beyond the revoked
> > certificate's validity period.
> >
> >
> >
> >
> >
> >
> >
> > 8.6.2.2 Issuing distribution point extension
> >
> > This CRL extension field identifies the CRL distribution point for this
> > particular CRL, and indicates if the CRL is limited to revocations for
> > end-entity certificates only, for authority certificates only, or for a
> > limited set of reasons only. The CRL is signed by the CRL issuer's key-
> > CRL distribution points do not have their own key pairs. However, for a
> > CRL distributed via the Directory, the CRL is stored in the entry of the
> > CRL distribution point, which may not be the directory entry of the CRL
> > issuer. If this field is absent, the CRL shall contain entries for all
> > revoked unexpired certificates issued by the CRL issuer.
> >
> >
> >
> > ....
> >
> >
> >
> > The distributionPoint component contains the name of the distribution
> > point in one or more name forms. If this field is absent, the CRL shall
> > contain entries for all revoked certificates issued by the CRL issuer.
> > After a certificate appears on a CRL, it is deleted from a subsequent
> > CRL after the certificate's expiry.
> >
> >
> >
> >
> >
> > Although section 8.6.2.2 is specifically in regards to CRLdps, any
> > difference between full CRLs and CRLdps in this case I feel would be an
> > arbitrary one.
> >
> >
> >
> > Now logically it makes sense to remove certificates that are expired
> > from CRLs to control size, yes this has a negative point specifically it
> > prevents CRLs from being used as a non-repudiation source; but this is
> > mute due to many other issues.
> >
> >
> >
> > That being the case I think; and I believe Peter would agree the correct
> > thing to do is to remove these expired/revoked entries from the CRL.
> >
> >
> >
> > The question now is what is the PKIX stance on this matter?
> >
> >
> >
> > Ryan M. Hurst
> >
> > ValiCert, Inc.
> >
> >
> >
> >      "It may roundly be asserted that human ingenuity cannot concoct a
> >      cipher which human ingenuity cannot resolve."
> >      -Edgar Allan Poe
> >
> >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f859p2d04599 for ietf-pkix-bks; Wed, 5 Sep 2001 02:51:02 -0700 (PDT)
Received: from exchsvr1.entegrity.com (exchsvr1.entegrity.com [207.215.19.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f859p0D04589 for <[e-mail]>; Wed, 5 Sep 2001 02:51:00 -0700 (PDT)
Received: from cooper.entegrity.com (dave.entegrity.se [195.100.88.62]) by exchsvr1.entegrity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id PGA4H0VN; Wed, 5 Sep 2001 02:55:50 -0700
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 05 Sep 2001 11:48:26 +0200
To: Ryan Hurst <[e-mail]>, IETF-PKIX <[e-mail]>
From: Nada Kapidzic Cicovic <[e-mail]>
Subject: Re: Removing expired certificates from CRLs.....
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: text/html; 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>

<html>
Ryan,<br><br>
Some years ago we at Entegrity also had similar discussion. We were
positive CRLs were not to contain the information about the expired
certificates, until we came across some industry CA CRLs containing
information about all revoked certificates. We then looked into 2459
(draft in those days) and X.509 text and came to the conclusion that
deleting info about expired certificates from a CRL is only an
option.<br><br>
I am not sure what was the intention of the original authors of X.509
(perhaps Sharon and Hoyt know more about it), but the current industry
practice seems to be a mixture of both approaches.<br><br>
My personal opinion is that keeping all revoked certificates info in CRLs
brings more problems than benefits. However, it is questionable whether
PKIX needs to take a vote for one approach or the other. <br><br>
In any case I would suggest that the text of 2459 be modified so that it
has a MAY (or a MUST) c<font face="Arial, Helvetica">onsistently</font>
in all places where deleting expired certificates revocation info from
CRLs is mentioned. The current text only brings confusion, as you have
already pointed out.<br><br>
Nada<br><br>
At 08:49 PM 9/4/01 -0700, Ryan Hurst wrote:<br><br>
<blockquote type=cite class=cite cite><font face="arial" size=2>I was
speaking with Peter Williams today about the removal of expired
certificates from CRLs; I have always been under the belief that this
behavior was optional, I vaguely remembered reading text in 2459 along
those lines; additionally I know of several commercial CAs that do not
remove the expired certificates from their CRLs. Peter on the other hand
was under the impression that it was a mandate to remove CRLs; he too
remembered reading text in 2459 to support is position.<br>
</font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2>So we each pulled out the RFC and found that we
were both right! Specifically both sections 3.3 and 8.6.2.2 have text on
this subject:<br>
</font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2><b>3.3&nbsp; Revocation<br>
</b></font><br>
<font face="arial" size=2>When a certificate is issued, it is expected to
be in use for its entire validity period.&nbsp; However, various
circumstances may cause a certificate to become invalid prior to the
expiration of the validity period.<br>
</font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2>....<br>
</font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2>An entry is added to the CRL as part of the
next update following notification of revocation. <b><i>An entry may be
removed from the CRL after appearing on one regularly scheduled CRL
issued beyond the revoked certificate's validity period.<br>
</i></b></font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2><b>8.6.2.2 Issuing distribution point
extension<br>
</b></font><br>
<font face="arial" size=2>This CRL extension field identifies the CRL
distribution point for this particular CRL, and indicates if the CRL is
limited to revocations for end-entity certificates only, for authority
certificates only, or for a limited set of reasons only. The CRL is
signed by the CRL issuer's key- CRL distribution points do not have their
own key pairs. However, for a CRL distributed via the Directory, the CRL
is stored in the entry of the CRL distribution point, which may not be
the directory entry of the CRL issuer.<i> <b>If this field is absent, the
CRL shall contain entries for all revoked unexpired certificates issued
by the CRL issuer.<br>
</i></b></font><br>
<font face="arial" size=2><i>&nbsp;<br>
</i></font><br>
<font face="arial" size=2>....<br>
</font><br>
<font face="arial" size=2 color="#0000FF">&nbsp;<br>
</font><br>
<font face="arial" size=2>The
</font><font face="arial" size=1><b>distributionPoint
</b></font><font face="arial" size=2>component contains the name of the
distribution point in one or more name forms. If this field is absent,
the CRL shall contain entries for all revoked certificates issued by the
CRL issuer. <b><i>After a certificate appears on a CRL, it is deleted
from a subsequent CRL after the certificate's expiry.<br>
</i></b></font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2>Although section 8.6.2.2 is specifically in
regards to CRLdps, any difference between full CRLs and CRLdps in this
case I feel would be an arbitrary one. <br>
</font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2>Now logically it makes sense to remove
certificates that are expired from CRLs to control size, yes this has a
negative point specifically it prevents CRLs from being used as a
non-repudiation source; but this is mute due to many other issues.<br>
</font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2>That being the case I think; and I believe
Peter would agree the correct thing to do is to remove these
expired/revoked entries from the CRL. <br>
</font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2>The question now is what is the PKIX stance on
this matter?<br>
</font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2>Ryan M. Hurst<br>
</font><br>
<font face="arial" size=2>ValiCert, Inc.<br>
</font><br>
<font face="arial" size=2>&nbsp;</font>
<dl><font face="Times New Roman, Times">
<dd>&quot;It may roundly be asserted that human ingenuity cannot concoct
a cipher which human ingenuity cannot
resolve.&quot;</i></font><font face="Times New Roman, Times">
<dd>-Edgar Allan Poe</font>
</dl><font face="Times New Roman, Times">&nbsp;</font></blockquote></html>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f858obo00437 for ietf-pkix-bks; Wed, 5 Sep 2001 01:50:37 -0700 (PDT)
Received: from carbone.certplus.com (facteur.certplus.com [195.101.88.81]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f858oZD00431 for <[e-mail]>; Wed, 5 Sep 2001 01:50:35 -0700 (PDT)
Received: from certplus.com ([192.168.212.27]) by carbone.certplus.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 5 Sep 2001 10:46:46 +0200
Message-ID: <[e-mail]>
Date: Wed, 05 Sep 2001 10:47:09 +0200
From: Jean-Marc Desperrier <[e-mail]>
Organization: Certplus
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: New test TSA available
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 05 Sep 2001 08:46:46.0406 (UTC) FILETIME=[4B88D260:01C135E7]
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>

Jean-Marc Desperrier wrote:

> What is needed is a finalized version of this protocol in an RFC, so that _this_
> becomes a reference, and something one can actually use for interoperability.
> Therefore the true question is why is this RFC still not there when supposedly the
> draft is on the last stages of approval since monthes [...]

I did not stand corrected about this point by anyone in the mailing list.
Surprising.

The TSP RFC is indeed issued now :

http://www.ietf.org/rfc/rfc3161.txt




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f858HLC26358 for ietf-pkix-bks; Wed, 5 Sep 2001 01:17:21 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f858HJD26352 for <[e-mail]>; Wed, 5 Sep 2001 01:17:19 -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 KAA43940; Wed, 5 Sep 2001 10:19: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 KAA19928; Wed, 5 Sep 2001 10:16:45 +0200
Message-ID: <[e-mail]>
Date: Wed, 05 Sep 2001 10:16:46 +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: Simonato Carolina <[e-mail]>
CC: IETF-PKIX <[e-mail]>
Subject: Re: Question: who signs a CRL if the CAcertificate, that signs it, is  immediately revoked?
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>

Carolina,

> Hello all!
> 
> Suppose a simple situation in which a certificate chain is constituted
> only by two certificates: a trusted (by some important authority) root
> certificate (self-signed) and an end-entity certificate, signed by that
> root certificate.

> The same root certificate also signs the certificate revocation list (a
> unique crl that contains all revoked certificates- for all reasons).

> The problem is: who signs the crl when the root certificate is
> immediately revoked, because of, for example, cacompromise?

If the key is the CA is compromised, then the attacker has the key and thus
may generate any CRL. The CA might still attempt to publish a CRL using the 
compromised key, but with no garantee that the CRL he has issued will ever
be seen (PKIX or X.509 does NOT assume that access to the repository where
the CRLs are placed is secured).

Nevetheless, all relying parties making use of the root key *shall* be
informed that the current root key is no longer valid. With your
assumptions, unless using some out-of-bands mechanism, it cannot be
guaranteed that they will always be informed (see later for a proposal). 

Once they know it, they should be able to obtain the new root key (which,
anyway has to be changed) using out-of-bands means, e.g. by publishing the
hash of the new self-signed certificate or by pushing or pulling the new
self-signed certificate.
 
I believe that this answers to your question without changing any parameter
from the situation you describe. However, by using a more realistic but 
different model, with an additional level in the hierarchy, then there is a
different answer. The model involves: a root level, a CA level, an end-user
level. 

If relying parties can directly trust both the root level and the CA key
that has issued their certificate, then there is another alternative: an
indirect CRL issued by that CA can be used to signal that the root CA has
been compromised. In this way the software can *always* receive a warning
that the root key has been compromised. 

Of course the attacker could say that the CA key is no longer valid (i.e.
revoked), by issued a (root) CRL but the warning is always obtained. After
getting such a warning, relying parties should be stop processing and
further inquiries should anyway be necessary to know what really happened
... to finally get the new root key and the possibly new CA key using some
out-of-bands mechanisms.

As a summary, using two trust points, instead of one, and indirect CRLs
is one way to solve the problem.

Denis


> Probably it is necessary to create a new couple of keys (and so a new
> root certificate) and sign the crl with the new  ca private key?

> Or is it possible to create a couple of  CA keys to sign only
> certificate revocation list and not to make provision for revoking this
> last  ca root certificate?
> 
> I would like to riceive suggestions about this topic.
> Thank you in advance.
> 
> regards
> Carolina


Received: by above.proper.com (8.11.6/8.11.3) id f857GTY18905 for ietf-pkix-bks; Wed, 5 Sep 2001 00:16:29 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f857GRD18898 for <[e-mail]>; Wed, 5 Sep 2001 00:16:28 -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 JAA31834; Wed, 5 Sep 2001 09:18:25 +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 JAA08920; Wed, 5 Sep 2001 09:15:52 +0200
Message-ID: <[e-mail]>
Date: Wed, 05 Sep 2001 09:15:54 +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: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: charter revisions
References: <p0501040bb7a8214adf35@[128.33.84.34]> <[e-mail]> <p05010404b7babe9a79ed@[128.33.84.34]>
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,

(deleted text)

> >I also found that 3/02 for DPV/DPD Protocols RFCs, may be a little bit
> >optimistic. 3/04 would probably be more appropriate.
 
> OK, I'll make that change.

With the writing of dates in the reverse way between my country and yours, 
I got confused. I was thinking that April 2002 would be reasonable, not 
for the RFC being published (by experience we know that it takes months 
between an IETF last call being passed and an RFC publication), but for 
a WG last call.

So if we assume WG Last call in April 2002 and IETF last call in June 2002,
then we add 6 months for publication and this makes December 2002 (12/02, 
I presume) for a possible publication.

Denis

> Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f854Ido12891 for ietf-pkix-bks; Tue, 4 Sep 2001 21:18:39 -0700 (PDT)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f854IXD12369 for <[e-mail]>; Tue, 4 Sep 2001 21:18:33 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id QAA25863; Wed, 5 Sep 2001 16:18:00 +1200 (NZST) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id QAA128532; Wed, 5 Sep 2001 16:17:51 +1200 (NZST) (sender [e-mail])
Date: Wed, 5 Sep 2001 16:17:51 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: RE: charter revisions
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>

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

>I agree with Stephen Farrell and Steve Hanna that logotypes are out of scope.

Unaccustomed as I am to agreeing with everyone else, I'll drop in my $0.02 and
concur.  In any case since it's been demonstrated that a sufficiently motivated
person can put a cat MPEG in a cert, I don't see that a simple logo will be any
problem for someone who really wants it.

Peter.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f853u2m26342 for ietf-pkix-bks; Tue, 4 Sep 2001 20:56:02 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f853txD26232 for <[e-mail]>; Tue, 4 Sep 2001 20:55:59 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Tue, 4 Sep 2001 20:56:44 -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]; Tue, 04 Sep 2001 20:56:44 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <QP4KV7NA>; Tue, 04 Sep 2001 20:49:41 -0700
Content-return: allowed
Date: Tue, 04 Sep 2001 20:49:40 -0700
From: Ryan Hurst <[e-mail]>
Subject: Removing expired certificates from CRLs.....
To: IETF-PKIX <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: multipart/alternative; boundary="Boundary_(ID_VIuqVop7j1bRuV68o60z4w)"
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.

--Boundary_(ID_VIuqVop7j1bRuV68o60z4w)
Content-type: text/plain

I was speaking with Peter Williams today about the removal of expired
certificates from CRLs; I have always been under the belief that this
behavior was optional, I vaguely remembered reading text in 2459 along those
lines; additionally I know of several commercial CAs that do not remove the
expired certificates from their CRLs. Peter on the other hand was under the
impression that it was a mandate to remove CRLs; he too remembered reading
text in 2459 to support is position.
 
So we each pulled out the RFC and found that we were both right!
Specifically both sections 3.3 and 8.6.2.2 have text on this subject:
 
3.3  Revocation
When a certificate is issued, it is expected to be in use for its entire
validity period.  However, various circumstances may cause a certificate to
become invalid prior to the expiration of the validity period.
 
....
 
An entry is added to the CRL as part of the next update following
notification of revocation. An entry may be removed from the CRL after
appearing on one regularly scheduled CRL issued beyond the revoked
certificate's validity period.
 
 
 
8.6.2.2 Issuing distribution point extension
This CRL extension field identifies the CRL distribution point for this
particular CRL, and indicates if the CRL is limited to revocations for
end-entity certificates only, for authority certificates only, or for a
limited set of reasons only. The CRL is signed by the CRL issuer's key- CRL
distribution points do not have their own key pairs. However, for a CRL
distributed via the Directory, the CRL is stored in the entry of the CRL
distribution point, which may not be the directory entry of the CRL issuer.
If this field is absent, the CRL shall contain entries for all revoked
unexpired certificates issued by the CRL issuer.
 
....
 
The distributionPoint component contains the name of the distribution point
in one or more name forms. If this field is absent, the CRL shall contain
entries for all revoked certificates issued by the CRL issuer. After a
certificate appears on a CRL, it is deleted from a subsequent CRL after the
certificate's expiry.
 
 
Although section 8.6.2.2 is specifically in regards to CRLdps, any
difference between full CRLs and CRLdps in this case I feel would be an
arbitrary one. 
 
Now logically it makes sense to remove certificates that are expired from
CRLs to control size, yes this has a negative point specifically it prevents
CRLs from being used as a non-repudiation source; but this is mute due to
many other issues.
 
That being the case I think; and I believe Peter would agree the correct
thing to do is to remove these expired/revoked entries from the CRL. 
 
The question now is what is the PKIX stance on this matter?
 
Ryan M. Hurst
ValiCert, Inc.
 
"It may roundly be asserted that human ingenuity cannot concoct a cipher
which human ingenuity cannot resolve."
-Edgar Allan Poe
 

--Boundary_(ID_VIuqVop7j1bRuV68o60z4w)
Content-type: text/html
Content-transfer-encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
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:[e-mail]4BB00">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName"/>
<!--[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:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
   <w:UseFELayout/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;
	mso-font-alt:\5B8B\4F53;
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 135135232 16 0 262145 0;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 135135232 16 0 262145 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:SimSun;}
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.EmailStyle17
	{mso-style-type:personal-compose;
	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:windowtext;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	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:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I was speaking with =
</span></font><st1:PersonName><font
 size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Peter
 Williams</span></font></st1:PersonName><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'> today about the removal =
of expired
certificates from <span class=3DSpellE>CRLs</span>; I have always been =
under the belief
that this behavior was optional, I vaguely remembered reading text in =
2459 along
those lines; additionally I know of several commercial <span =
class=3DSpellE>CAs</span>
that do not remove the expired certificates from their <span =
class=3DSpellE>CRLs</span>.
Peter on the other hand was under the impression that it was a mandate =
to
remove <span class=3DSpellE>CRLs</span>; he too remembered reading text =
in 2459 to
support is position.<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'>So we each pulled out the RFC and found that we were =
both
right! Specifically both sections 3.3 and 8.6.2.2 have text on this =
subject:<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 style=3D'tab-stops:45.8pt 91.6pt 137.4pt 183.2pt =
229.0pt 274.8pt 320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt =
641.2pt 687.0pt 732.8pt;
mso-layout-grid-align:none;text-autospace:none'><span class=3DGramE><b
style=3D'mso-bidi-font-weight:normal'><font size=3D2 face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;font-weight:bold;mso-bidi-fo=
nt-weight:
normal'>3.3<span style=3D'mso-spacerun:yes'>&nbsp; =
</span>Revocation</span></font></b></span><b
style=3D'mso-bidi-font-weight:normal'><font size=3D2 face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;font-weight:bold;mso-bidi-fo=
nt-weight:
normal'><o:p></o:p></span></font></b></p>

<p class=3DMsoNormal style=3D'tab-stops:45.8pt 91.6pt 137.4pt 183.2pt =
229.0pt 274.8pt 320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt =
641.2pt 687.0pt 732.8pt;
mso-layout-grid-align:none;text-autospace:none'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>When a certificate is =
issued, it is
expected to be in use for its entire validity period.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>However, various circumstances =
may cause
a certificate to become invalid prior to the expiration of the validity =
period.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'tab-stops:45.8pt 91.6pt 137.4pt 183.2pt =
229.0pt 274.8pt 320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt =
641.2pt 687.0pt 732.8pt;
mso-layout-grid-align:none;text-autospace:none'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></f=
ont></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>....<o:p></o:p></span></fon=
t></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></f=
ont></p>

<p class=3DMsoNormal style=3D'tab-stops:45.8pt 91.6pt 137.4pt 183.2pt =
229.0pt 274.8pt 320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt =
641.2pt 687.0pt 732.8pt;
mso-layout-grid-align:none;text-autospace:none'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>An entry is added to the =
CRL as part
of the next update following notification of revocation. <b><i><span
style=3D'font-weight:bold;font-style:italic'>An entry may be removed =
from the CRL
after appearing on one regularly scheduled CRL issued beyond the =
revoked
certificate's validity =
period.</span></i></b><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'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><b><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;font-weight:
bold'>8.6.2.2 Issuing distribution point =
extension<o:p></o:p></span></font></b></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>This CRL
extension field identifies the CRL distribution point for this =
particular CRL,
and indicates if the CRL is limited to revocations for end-entity =
certificates
only, for authority certificates only, or for a limited set of reasons =
only. The
CRL is signed by the CRL issuer's key- CRL distribution points do not
have their own key pairs. However, for a CRL distributed via the =
Directory, the
CRL is stored in the entry of the CRL distribution point, which may not =
be the directory
entry of the CRL issuer.<i><span style=3D'font-style:italic'> <b><span
style=3D'font-weight:bold'>If this field is absent, the CRL shall =
contain entries
for all revoked <span class=3DSpellE>unexpired</span> certificates =
issued by the
CRL issuer.</span></b><o:p></o:p></span></i></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><i><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;font-style:
italic'><o:p>&nbsp;</o:p></span></font></i></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>....<o:p></o:p></span></fon=
t></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:blue'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>The </span></font><span
class=3DSpellE><b><font size=3D1 face=3DArial><span =
style=3D'font-size:9.0pt;
font-family:Arial;font-weight:bold'>distributionPoint</span></font></b><=
/span><b><font
size=3D1 face=3DArial><span =
style=3D'font-size:9.0pt;font-family:Arial;font-weight:
bold'> </span></font></b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>component contains the name of the distribution =
point in one
or more name forms. If this field is absent, the CRL shall contain =
entries for
all revoked certificates issued by the CRL issuer. <b><i><span
style=3D'font-weight:bold;font-style:italic'>After a certificate =
appears on a
CRL, it is deleted from a subsequent CRL after the certificate's =
expiry.<o:p></o:p></span></i></b></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'>Although section 8.6.2.2 is specifically in regards =
to <span
class=3DSpellE>CRLdps</span>, any difference between full <span =
class=3DSpellE>CRLs</span>
and <span class=3DSpellE>CRLdps</span> in this case I feel would be an =
arbitrary
one. <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'>Now logically it makes sense to remove certificates =
that are
expired from <span class=3DSpellE>CRLs</span> to control size, yes this =
has a
negative point specifically it prevents <span =
class=3DSpellE>CRLs</span> from
being used as a non-repudiation source; but this is mute due to many =
other
issues.<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'>That being the case I think; and I believe Peter =
would agree
the correct thing to do is to remove these expired/revoked entries from =
the CRL.
<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'>The question now is what is the PKIX stance on this =
matter?<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'>Ryan M. Hurst<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'>ValiCert, Inc.<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>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>

<p class=3DMsoNormal><i><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt;font-style:italic;mso-no-proof:yes'>&quot;It =
may
roundly be asserted that human ingenuity cannot concoct a cipher which =
human
ingenuity cannot resolve.&quot;</span></font></i><span =
style=3D'mso-no-proof:
yes'><o:p></o:p></span></p>

</blockquote>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt;mso-no-proof:yes'>-Edgar Allan Poe</span><o:p></o:p></font></p>

</blockquote>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

--Boundary_(ID_VIuqVop7j1bRuV68o60z4w)--


Received: by above.proper.com (8.11.6/8.11.3) id f853I8U15392 for ietf-pkix-bks; Tue, 4 Sep 2001 20:18:08 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f853I5D15289 for <[e-mail]>; Tue, 4 Sep 2001 20:18:05 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Tue, 4 Sep 2001 20:18: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]> for [e-mail]; Tue, 04 Sep 2001 20:18:49 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <QP4KV7LD>; Tue, 04 Sep 2001 20:11:47 -0700
Content-return: allowed
Date: Tue, 04 Sep 2001 20:11:46 -0700
From: Peter Williams <[e-mail]>
Subject: RE: charter revisions
To: 
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain
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 its irrelevant that particular
folks do not wish to do any work
on a potential work topic. Personally,
I have done little or no work on several PKIX
work items for years, their being
largely irrelevant to the Internet
deployment community. 

I did not feel it appropriate to seek to stop others 
however, or voice my personal prejudice toward 
their work area. In the future, these standards
may be very important baselines, as things catch
up to some of our visions.

If there is constituency to do the logotype work,
then let it happen. I cannot judge
whether the material on logotypes is legitimate
or secure, until I see IDs and active WG/list discussion
on actual proposals. 

I do know broadly the underlying issue is pertinent to many current
deployment matters across the world, including internationl
char sets issues where, culturally, unique graphical 
chars are created for an idea/name, and as DNS 
names/attributes/graphical-chars and 509 converge in the hands 
of the business known as VeriSign. 

Personally, I see the  engineering topic as wider than logotypes; its 
about the use of graphic symbols in a non-Roman way of thinking about
identifiers, names and the forms of reliance. To
me this is all very exciting, as a cultural issue set relevant 
to global uptake enters that is little addressed 
in Western-dominated ISO/IETF standards. 

If the chairs are tired, then replace the 
chairs at an appropriate milestone. I dont think anyone 
would think any worse of our chairs for ceding the floor, after
so many years of sterling service. Personally, I'd keep
both of our chairs, but thats for them to decide.

-----Original Message-----
From: Michael Myers [mailto:[e-mail]]
Sent: Tuesday, September 04, 2001 10:34 AM
To: [e-mail]; Stephen Kent
Cc: Steve Hanna; [e-mail]
Subject: RE: charter revisions



All,

I agree with Stephen Farrell and Steve Hanna that logotypes are out of
scope.  These needs are better addressed by other forums.  Let's focus the
WG's remaining energy on resolving DPV/DPD issues.

Mike


> On Thursday, August 30, 2001 2:35 AM Stephen Farrell wrote in part:
> . . .
> Steve (K),
>
> I'd have to agree with Steve H, though maybe not as strongly.
> My suggestion would be to limit the additional items to the
> dpd/dpv.


> On  Wednesday, August 29, 2001 2:01 PM Steve Hanna wrote in part:
>
> . . . I don't think PKIX should do any work on the
> logotype extension. I know that there is a demand for this from
> marketing folks, but I don't believe that we should standardize it
> unless it can be used securely. This does not seem possible.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f851RbV22346 for ietf-pkix-bks; Tue, 4 Sep 2001 18:27:37 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f851RZD22342 for <[e-mail]>; Tue, 4 Sep 2001 18:27:35 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Tue, 4 Sep 2001 18:28:19 -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, 04 Sep 2001 18:28:19 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <QP4KV71Q>; Tue, 04 Sep 2001 18:21:17 -0700
Content-return: allowed
Date: Tue, 04 Sep 2001 18:21:17 -0700
From: Peter Williams <[e-mail]>
Subject: RE: Path validation and self-signed certificates
To: "'David A. Cooper'" <[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>

I disagree with your recommendation. I am thinking
as an long-term implementor who has followed
and interpreted the particular X.509 guidance through
5 generations of PKI software now, when I say the 
following:

Anyone can send any set of certificates in a proposed path; it
is for the receipient to sort, and select, which certs represent
a trust path that meets their local security policy 
requirements. This includes choosing certs based on their
convergence with locally-recognised trust anchors.

For example, one can send two parallel paths to
a given recipient in the certs list of a PKCS7 
msg, each of whose trust-anchors may be indicated by a 
self-signed cert.

The one path (of the two sent) to be actually validated depends upon the 
receivers application software, not the PKIX path processing
algorithm.  Upon discovery, elements of the selected path should be 
then passed to the X.509 path processing
algorithm implementation. In a good implementation
of the application, the passed path will include only those 
elements of the trust path that meet the path processing rules; 
this should does not include the self-signed cert. If found,
the self signed cert should be ignored by the security module
evaluated to ensure conformance to PKIX/509.

Of course, how the path processing algorithm learns which
trust anchors are legitimate is something that is 
not-standardized, and should not be indicated to the algorithm 
by information derived from a cert path. If the application
before passing the cert path to X.509 path processing
has setup a path-processing security context with the two trust
anchors recently delivered via self-signed certs,
then this is acceptable application practice. If we were
building PEM, perhaps the IPRA public key would be
pre-installed in every security context...

Lets remember, its not IETF business to standardize the 
non-Internet applications that use PKI; of which there are now
many. They discover paths and control trust anchors however
they wish. It is PKIX business to ensure that two path processing
algorithm given the same inputs would
produce the same result concerning a valid path. After 
10 years of trying, we are about as far from this
goal as ever, unfortunately, in Internet praxis. 

Peter.

-----Original Message-----
From: David A. Cooper [mailto:[e-mail]]
Sent: Saturday, August 25, 2001 2:33 PM
To: [e-mail]
Subject: RE: Path validation and self-signed certificates



All,

I believe that PKIX should either discourage or forbid the inclusion of
self-signed certificates in certification paths for the following reasons:

1) Section 8.1.5 of the 4th edition of X.509 states that

         There are three circumstances under which a certification authority
may
         issue a certificate to itself:

         a) as a convenient way of encoding its public key for communication
to,
              and storage by, its certificate users;

         b) ...

         For purposes of path validation, self-issued certificates of type
a) are verified
         with the public key contained in them, and if they are encountered
in the path,
         they shall be ignored.

So, X.509 states that self-signed certificate are only to be used as a
convenient way of encoding a public key, and that self-signed certificates,
if they are encountered in a certification path are to be ignored. Thus, if
PKIX were to allow the processing of self-signed certificates, it would not
be compliant with X.509.

2) As Peter Hesse pointed out, many CAs issue self-signed certificates with
a minimum necessary information (e.g., a version 1 certificate with just a
name, public key, and validity dates).  Any such certificates included in a
certification path would result in an empty valid_policy_tree.  Old-with-new
and new-with-old self-issued certificates are designed to be used as part of
certification paths and so should contain all of the necessary extensions
(e.g., basicConstraints, certificatePolicies), but self-signed certificates
may be been issued simply as a means of distributing the public key to
relying parties that will use that key as a trust anchor. If these
certificates are included in, and are processed as parts of, certification
paths, the results may be rejecting end certificates that should be have
been accepted.

3) If a CA suspects that its key has been compromised (or it otherwise
determines that none of the certificates it has issued should be considered
valid), it should request that every certificate issued to it be revoked (as
is stated in the Security Considerations section).  If possible, it should
also revoke all of the certificates it has issued (not just its self-signed
certificate). If a CA can revoke its own self-signed certificate then it can
revoke all of the certificates it has issued. Doing so will ensure that all
relying parties know about the revocation, not just those relying parties
that check to see whether the signed-signed certificate has been revoked.

4) If an organization uses client software that processes self-signed
certificates, there is risk that that organization will issue certificates
from its own CA assuming that relying parties process self-signed
certificates. This organization's CA may then issue self-signed certificates
with constraints (e.g., name constraints, path length constraints, etc.)
that they expect relying parties to see, but the CA, assuming that relying
parties will process its self-signed certificates, may not include the
constraints in any of its other certificates.

So, if there is no set rule, there is the risk that relying parties that do
process self-signed certificates will lose some interoperability and those
that do not will overlook intended path processing constraints.

Hiroyuki Sakakibara presented an example in which processing self-signed
certificates helped to prevent a security breach.  In his example, A issues
a cross-certificate to B and B's private key is compromised. Hiroyuki
pointed out that by processing B's self-signed certificate (to see if it has
expired or has been revoked) one may have a chance to detect the compromise
even if A does not cooperate by revoking the certificate that it issued to
B.  However, as he pointed out, this is not foolproof. The entity that
compromised B's key could issue a new self-signed certificate with a later
notAfter date along with CRLs that make it appear as if B's certificates are
still good. If on the other hand, B were able to get its own CRLs to relying
parties, it could just revoke all of its certificates instead of just its
self-signed certificate, thus ensuring that any relying party that receives
its CRLs will know that its certificates can not be trusted, whether they
process B's self-s!
igned certificates or not.

In general though, if a certification path of the form ... --> A --> B -->
... is being processed, I don't think there is much that B can do to protect
relying parties from A's improper behavior. If A issues certificates to B
with notAfter dates that are later than they should be or if A refuses to
revoke B's certificate when requested to do so, there is little that B can
do to protect A's relying parties (or the relying parties of any CA that
preceded A in the path) from A, particularly in the case when B's private
key has been compromised.  I don't think that it is worth diverging from
X.509 and introducing interoperability problems into PKIX in an attempt to
try.

Dave

At 04:37 PM 8/24/01 -0700, Ryan Hurst wrote:
>Peter -
>
>I agree with your comments on self-signed certificates in chains with only
one exception, specifically in regards to revocation. There are several
cases where the revocation of a self-signed CA would make sense, what about
cessationOfOperation, superseded and affiliationChanged? These reasons do
not imply any sort of compromise of key material. We make many "known
assumptions" in PKI and the catch 22 of key material management and trust is
one of them, without these "known assumptions" many of the things in son-off
fall apart.
>
>Ryan



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f84Npph03227 for ietf-pkix-bks; Tue, 4 Sep 2001 16:51:51 -0700 (PDT)
Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84NpnD03223 for <[e-mail]>; Tue, 4 Sep 2001 16:51:49 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100331b7bb18707579@[165.227.249.20]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 4 Sep 2001 16:51:45 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: charter revisions
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 4:44 PM -0700 9/4/01, Michael Myers wrote:
>  > >   These needs are better addressed by other forums.
>>
>>  Such as...?
>
>
>Such as whomever chooses to stand up the responsibility, or is PKIX going to
>go on forever ratifying extension X, protocol Y and policy Z?

History say "the latter".

>   This role
>does not strike me as an engineering activity.

Fully agree. Oh, well.

>To the extent these issues remain relevant to the IETF and its governing
>bodies, perhaps those superior organizations may wish to consider their
>role.  In *that* regard, IANA's classic role comes to mind but since so much
>of what PKI is and does to an enterprise is intrinsically bound up in
>enterprise security policy (as it should be), it's not clear to me that an
>IANA-like organization is the  best path forward.

IANA is not a body that should pass security standards.

>Perhaps, Paul, given your exposure IETF/IESG/IAB organizational issues, you
>could propose something?

I did: I supported putting it in the PKIX WG charter. Seeing some 
vendor interest, and seeing the PKIX WG does a fair job at putting 
out protocols without gaping security holes, and not seeing any other 
reputable (or even half-reputable) organization stepping up, I don't 
see why it should not be done here. Charter creep is pretty common in 
the IETF security area, yes? Should we not fully embrace that?

>I fear I've stirred the fire more than I should have.

Spoken like a true Californian at the end of a long, dry summer.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f84NjYr03133 for ietf-pkix-bks; Tue, 4 Sep 2001 16:45:34 -0700 (PDT)
Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84NjXD03127; Tue, 4 Sep 2001 16:45:33 -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.3) with SMTP id f84NjYH14451; Tue, 4 Sep 2001 16:45:34 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Paul Hoffman / IMC" <[e-mail]>, <[e-mail]>
Subject: RE: charter revisions
Date: Tue, 4 Sep 2001 16:44:17 -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: <p05100327b7baf1ca610b@[165.227.249.20]>
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>

> >   These needs are better addressed by other forums.
>
> Such as...?


Such as whomever chooses to stand up the responsibility, or is PKIX going to
go on forever ratifying extension X, protocol Y and policy Z?  This role
does not strike me as an engineering activity.  Hence my recent advocacy.

To the extent these issues remain relevant to the IETF and its governing
bodies, perhaps those superior organizations may wish to consider their
role.  In *that* regard, IANA's classic role comes to mind but since so much
of what PKI is and does to an enterprise is intrinsically bound up in
enterprise security policy (as it should be), it's not clear to me that an
IANA-like organization is the  best path forward.

Perhaps, Paul, given your exposure IETF/IESG/IAB organizational issues, you
could propose something?

I fear I've stirred the fire more than I should have.

Mike



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f84NQ5a02757 for ietf-pkix-bks; Tue, 4 Sep 2001 16:26:05 -0700 (PDT)
Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84NQ4D02753 for <[e-mail]>; Tue, 4 Sep 2001 16:26:04 -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.3) with SMTP id f84NQ1H12445; Tue, 4 Sep 2001 16:26:01 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Bob Jueneman" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: charter revisions
Date: Tue, 4 Sep 2001 16:24:42 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 8bit
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>

Bob,

I read through this but remain firm in my opinion that upon resolution of
the DPV/DPD issues, the working group has achieved its original engineering
mission.  Others may disagree.  This is just one vote.

Further, of course there remains vast battlefields of market share.  But
such issues I feel are better addressed in fora more appropriate to open
discussion of business interests given the sound technical platform PKIX has
defined (modulo resolution of DPV/DPD).

I'm more pleased to read of your support for Dave's efforts.  I'm assuming
as I write this that that design hasn't changed in fundamental substance
since I was last involved in its definition.  Perhaps Dave, John Pawling,
Russ or somebody could confirm my assumptions?

Minimally, I think it would be useful in the long run to have that work
documented as an Informational but perhaps that reach exceeds its grasp.

Mike

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




> -----Original Message-----
> From: Bob Jueneman [mailto:[e-mail]]
> Sent: Tuesday, September 04, 2001 3:36 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: RE: charter revisions
>
>
> Michael,
>
> Certainly you and I, and Russ, and a handful of Steves, and
> countless others, have been involved in this WG for so long that
> it sometimes feels like it was our life's mission.
>
> However, I think it might be a bit premature to suggest that PKIX
> be disbanded when there is relatively scant evidence (outside of
> SSL) that even the most basic goals of PKI have been achieved
> with anything close to ubiquity. To the contrary, lots of people
> are suggesting that "PKI is dead", without, of course, having an
> alternative suggestion ¯ except perhaps to throw the buggers out
> and have a new team start all over, this time presumably encoding
> everything in XML.
>
> (There might even be some merit in the "throw the buggers out"
> school of thought, for if we aren't part of the solution, perhaps
> we are part of the problem.  I don't think so ¯ I would prefer to
> think that we were just ahead of our time. Some of us, of course,
> may be a little more ahead of our time than others. :-)  And I'm
> sure we all have our own personal list of those features we would
> most like to see added, and if push came to shove, which ones we
> never cared about in the first place.  Speaking only personally,
> I crossed that point a long time ago with respect to DPV/DPD,
> TSP, certain forms of cross-certification, and some other things
> that I probably don't understand well enough to care much about,
> and happily so.)
>
> But although I might question the wisdom of continuing to
> proliferate this, that, and the other option during the technical
> discussion, I wouldn't try to invoke cloture before the debate
> had even started.
>
> I wouldn't go quite as far as Patrick Henry's "I disagree with
> what you say, but will defend to the death your right to say it",
> but I don't think that we need to have that discussion as part of
> the charter. That seems to be putting the cart before the horse.
> Instead, we should allow those who espouse the idea to work up an
> RFC and submit it, and if a rough consensus emerges, so be it.
> If not, the idea may languish forever as an experimental RFC, or
> it may go nowhere at all, with little harm done.  And some
> careful consideration might prevent someone from going off and
> offering something really dumb as a proprietary solution.
>
> As far as Dave Fillingham's ideas regarding clearances and other
> privileges are concerned, I absolutely agree with the basic
> thought, and would be more than willing to contribute a number of
> ideas of my own in that arena. If as alleged the PKI "movement"
> has been less than successful, it is arguably because we have
> concentrated far too much on identity, and trying to implement
> the world's finest system of identity-based nonrepudiation, while
> almost completely ignoring the basic concept of trust,
> particularly as regards the end user.
>
> No one cares much whether my name is Robert, Bob, or Beelzebub.
> What they really want to know is what I am allowed to DO, and
> whether there is enough money in my account to pay for it, and
> who says so.  Attribute certificates don't begin to really solve
> that problem, IMHO, for a host of reasons I won't get into.
>
> So should we simply that we're tired, throw up our hands, and go
> fishing, i.e., leave it to the XACML crowd to try it get right?
> I hope not.
>
> A friend recently characterized their apartment complex as being
> made up of the "newly wed, and nearly dead".  This WG may be
> nearer the second than the first, but I don't think it is time to
> call for the Last Rights quite yet.
>
> Bob
>
> >>> "Michael Myers" <[e-mail]> 09/04/01 03:33PM >>>
> Bob,
>
> Ignoring for a moment the durability of the IPSEC WG, as an IETF WG, PKIX
> must eventually close.  Of course, it's the chairs' call as to
> that precise
> timing but towards those considerations, I join those who say
> that the value
> added by addressing logotypes (and concomitantly extending the
> charter) does
> not warrant the energy required to fully address the requirements,
> particularly when placed in the context of the WG's predictable closure.
>
> At some point, we should declare victory and go fishing.  In my opinion,
> that state is most clearly signaled by closure of the DPV/DPD issues.
> Beyond that, I look forward to various other fora to step forward.
> Basically, move the feast.
>
> In my individual opinion as a WG participant, logotypes are no more
> technically fundamental to PKIX's mission than, say, the use of Subject
> Directory Attributes to convey clearance constraints.  In fact, if someone
> were to put the two on equal terms and call for a vote, I'd go for the
> latter.  What Dave Fillingham et. al. put together deserves far broader
> exposure than it's received to date.  My sense is that such considerations
> would have longer-reaching impact than logotypes.
>
> But that's just my opinion.  I could be wrong.
>
> Mike
>
>
> Michael Myers
> t: +415.819.1362
> e: mailto:[e-mail]
> w: http://www.traceroutesecurity.com
>
> > -----Original Message-----
> > From: Bob Jueneman [mailto:[e-mail]]
> > Sent: Tuesday, September 04, 2001 1:11 PM
> >
> > . . . is there any evidence that  the WG is running out of energy?
>
>



Received: by above.proper.com (8.11.6/8.11.3) id f84NICI02648 for ietf-pkix-bks; Tue, 4 Sep 2001 16:18:12 -0700 (PDT)
Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115]) by above.proper.com (8.11.6/8.11.3) with SMTP id f84NIAD02644 for <[e-mail]>; Tue, 4 Sep 2001 16:18:10 -0700 (PDT)
Received: from c1157592-b.skokie1.il.home.com (HELO rpca) (65.3.237.109) by smtp.mail.vip.sc5.yahoo.com with SMTP; 4 Sep 2001 23:17:53 -0000
X-Apparently-From: <[e-mail]>
From: "Karim Ladhani" <[e-mail]>
To: "Simonato Carolina" <[e-mail]>, "IETF-PKIX" <[e-mail]>
Subject: RE: Question: who signs a CRL if the CAcertificate, that signs it, is  immediately revoked?
Date: Tue, 4 Sep 2001 18:15:39 -0500
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.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
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>

Carolina,

Typically in a PKI the Root CA has multiple key pairs and their key usages
are split up (certificate signing,CRL signing,etc). So in the event that the
certificate signing key is compromised, it would still be able to sign the
CRL since it would use a different pair of keys to do so.

Karim Ladhani

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Simonato Carolina
Sent: Tuesday, September 04, 2001 10:42 AM
To: IETF-PKIX
Subject: Question: who signs a CRL if the CAcertificate, that signs it,
is immediately revoked?



Hello all!

Suppose a simple situation in which a certificate chain is constituted
only by two certificates: a trusted (by some important authority) root
certificate (self-signed) and an end-entity certificate, signed by that
root certificate.
The same root certificate also signs the certificate revocation list (a
unique crl that contains all revoked certificates- for all reasons).
The problem is: who signs the crl when the root certificate is
immediately revoked, because of, for example, cacompromise?
Probably it is necessary to create a new couple of keys (and so a new
root certificate) and sign the crl with the new  ca private key?
Or is it possible to create a couple of  CA keys to sign only
certificate revocation list and not to make provision for revoking this
last  ca root certificate?

I would like to riceive suggestions about this topic.
Thank you in advance.

regards
Carolina


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f84MYqc01796 for ietf-pkix-bks; Tue, 4 Sep 2001 15:34:52 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84MYnD01792 for <[e-mail]>; Tue, 4 Sep 2001 15:34:49 -0700 (PDT)
Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 04 Sep 2001 16:34:41 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Tue, 04 Sep 2001 16:35:57 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: charter revisions
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-7
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f84MYpD01793
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,

Certainly you and I, and Russ, and a handful of Steves, and countless others, have been involved in this WG for so long that it sometimes feels like it was our life's mission.  

However, I think it might be a bit premature to suggest that PKIX be disbanded when there is relatively scant evidence (outside of SSL) that even the most basic goals of PKI have been achieved with anything close to ubiquity. To the contrary, lots of people are suggesting that "PKI is dead", without, of course, having an alternative suggestion ¯ except perhaps to throw the buggers out and have a new team start all over, this time presumably encoding everything in XML.

(There might even be some merit in the "throw the buggers out" school of thought, for if we aren't part of the solution, perhaps we are part of the problem.  I don't think so ¯ I would prefer to think that we were just ahead of our time. Some of us, of course, may be a little more ahead of our time than others. :-)  And I'm sure we all have our own personal list of those features we would most like to see added, and if push came to shove, which ones we never cared about in the first place.  Speaking only personally, I crossed that point a long time ago with respect to DPV/DPD, TSP, certain forms of cross-certification, and some other things that I probably don't understand well enough to care much about, and happily so.)

But although I might question the wisdom of continuing to proliferate this, that, and the other option during the technical discussion, I wouldn't try to invoke cloture before the debate had even started.

I wouldn't go quite as far as Patrick Henry's "I disagree with what you say, but will defend to the death your right to say it", but I don't think that we need to have that discussion as part of the charter. That seems to be putting the cart before the horse. Instead, we should allow those who espouse the idea to work up an RFC and submit it, and if a rough consensus emerges, so be it.  If not, the idea may languish forever as an experimental RFC, or it may go nowhere at all, with little harm done.  And some careful consideration might prevent someone from going off and offering something really dumb as a proprietary solution.

As far as Dave Fillingham's ideas regarding clearances and other privileges are concerned, I absolutely agree with the basic thought, and would be more than willing to contribute a number of ideas of my own in that arena. If as alleged the PKI "movement" has been less than successful, it is arguably because we have concentrated far too much on identity, and trying to implement the world's finest system of identity-based nonrepudiation, while almost completely ignoring the basic concept of trust, particularly as regards the end user.

No one cares much whether my name is Robert, Bob, or Beelzebub.  What they really want to know is what I am allowed to DO, and whether there is enough money in my account to pay for it, and who says so.  Attribute certificates don't begin to really solve that problem, IMHO, for a host of reasons I won't get into.  

So should we simply that we're tired, throw up our hands, and go fishing, i.e., leave it to the XACML crowd to try it get right?  I hope not.

A friend recently characterized their apartment complex as being made up of the "newly wed, and nearly dead".  This WG may be nearer the second than the first, but I don't think it is time to call for the Last Rights quite yet.

Bob

>>> "Michael Myers" <[e-mail]> 09/04/01 03:33PM >>>
Bob,

Ignoring for a moment the durability of the IPSEC WG, as an IETF WG, PKIX
must eventually close.  Of course, it's the chairs' call as to that precise
timing but towards those considerations, I join those who say that the value
added by addressing logotypes (and concomitantly extending the charter) does
not warrant the energy required to fully address the requirements,
particularly when placed in the context of the WG's predictable closure.

At some point, we should declare victory and go fishing.  In my opinion,
that state is most clearly signaled by closure of the DPV/DPD issues.
Beyond that, I look forward to various other fora to step forward.
Basically, move the feast.

In my individual opinion as a WG participant, logotypes are no more
technically fundamental to PKIX's mission than, say, the use of Subject
Directory Attributes to convey clearance constraints.  In fact, if someone
were to put the two on equal terms and call for a vote, I'd go for the
latter.  What Dave Fillingham et. al. put together deserves far broader
exposure than it's received to date.  My sense is that such considerations
would have longer-reaching impact than logotypes.

But that's just my opinion.  I could be wrong.

Mike


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

> -----Original Message-----
> From: Bob Jueneman [mailto:[e-mail]] 
> Sent: Tuesday, September 04, 2001 1:11 PM
>
> . . . is there any evidence that  the WG is running out of energy?



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f84LZD900860 for ietf-pkix-bks; Tue, 4 Sep 2001 14:35:13 -0700 (PDT)
Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84LZCD00856 for <[e-mail]>; Tue, 4 Sep 2001 14:35:12 -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.3) with SMTP id f84LZDH00768; Tue, 4 Sep 2001 14:35:13 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Bob Jueneman" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: charter revisions
Date: Tue, 4 Sep 2001 14:33:55 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
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>

Bob,

Ignoring for a moment the durability of the IPSEC WG, as an IETF WG, PKIX
must eventually close.  Of course, it's the chairs' call as to that precise
timing but towards those considerations, I join those who say that the value
added by addressing logotypes (and concomitantly extending the charter) does
not warrant the energy required to fully address the requirements,
particularly when placed in the context of the WG's predictable closure.

At some point, we should declare victory and go fishing.  In my opinion,
that state is most clearly signaled by closure of the DPV/DPD issues.
Beyond that, I look forward to various other fora to step forward.
Basically, move the feast.

In my individual opinion as a WG participant, logotypes are no more
technically fundamental to PKIX's mission than, say, the use of Subject
Directory Attributes to convey clearance constraints.  In fact, if someone
were to put the two on equal terms and call for a vote, I'd go for the
latter.  What Dave Fillingham et. al. put together deserves far broader
exposure than it's received to date.  My sense is that such considerations
would have longer-reaching impact than logotypes.

But that's just my opinion.  I could be wrong.

Mike


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

> -----Original Message-----
> From: Bob Jueneman [mailto:[e-mail]]
> Sent: Tuesday, September 04, 2001 1:11 PM
>
> . . . is there any evidence that  the WG is running out of energy?



Received: by above.proper.com (8.11.6/8.11.3) id f84LBWN00410 for ietf-pkix-bks; Tue, 4 Sep 2001 14:11:32 -0700 (PDT)
Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84LBTD00403 for <[e-mail]>; Tue, 4 Sep 2001 14:11:29 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100327b7baf1ca610b@[165.227.249.20]>
In-Reply-To: <[e-mail]>
References: <p0501040bb7a8214adf35@[128.33.84.34]> <[e-mail]> <[e-mail]>
Date: Tue, 4 Sep 2001 14:11:23 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: charter revisions
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 11:58 AM -0400 9/4/01, Steve Hanna wrote:
>Unless the author of the Internet Draft indicates otherwise, I will
>assume that the primary purpose of putting logotypes in certificates
>is so that users can view them to make decisions about whether the
>certificates are trustworthy. In that case, the risks are much greater
>than those for the use case you described.

Are the risks any greater than what we have in 2459 now with spelling 
errors or things like "FooCA type 1 certificate" vs. "FooCA type 2 
certificate"? I agree with Russ that the benefits are higher, but I'm 
not at all convinced that the risks are higher.

>Unless we can develop a fairly secure way to meet the "marketing
>requirement" for logotypes in certificates, I would say that it is
>our obligation as an IETF working group to NOT accept this as a
>work item. Much better to have multiple incompatible ways
>to do something insecure (probably resulting in little deployment
>of this feature) than to have the PKIX working group issue an RFC
>explaining the one true way to do it. We are in the Security area,
>after all!

The end of that paragraph doesn't follow from the beginning of the 
paragraph. As long as the method we described doesn't have any 
security holes, it doesn't matter if we meet some pre-existing 
marketing "need". Further, some of the multiple, non-interoperable 
protocols are likely to have security problems; that is worse than 
having one protocol that doesn't meet the need of some CAs.

At 10:34 AM -0700 9/4/01, Michael Myers wrote:
>I agree with Stephen Farrell and Steve Hanna that logotypes are out of
>scope.

They are out of scope; the discussion is whether to add them to the scope.

>   These needs are better addressed by other forums.

Such as...?

>   Let's focus the
>WG's remaining energy on resolving DPV/DPD issues.

The current charter has much more than that already. The "focus" on 
DPV/DPD is already so fuzzy that it is probably just wishful to hope 
for much more.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f84K8Ol27432 for ietf-pkix-bks; Tue, 4 Sep 2001 13:08:24 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84K8MD27082 for <[e-mail]>; Tue, 4 Sep 2001 13:08:22 -0700 (PDT)
Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 04 Sep 2001 14:08:17 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Tue, 04 Sep 2001 14:10:40 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: charter revisions
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-7
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f84K8MD27171
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, Michael,

I realize that this summer has seen some rolling blackouts, particularly on the west coast, but is there any evidence that the WG is running out of energy?  If so, is there any evidence that DPV/DPD is more deserving of those last few dying breaths than anything else? :-)

I'd like to make one observation ¯ that most of the comments about the security of logos, the ability to enforce their legal usage, the difficulty of cross-certifying them, etc., apply primarily to the use of PUBLIC CAs, a la VeriSign, etc.

But without naysaying their use in such a context, I think there is also a significant potential use for branding in the case of closed PKI communities, such as certificates issued by American Express or Visa to their merchants, if not to their customers.  And the local Board of Realtors may wish to hand out logos to the individual Realtors(tm), even if the certificates are issued by VeriSign. And maybe the Masons, and the Elk, and Mary Kay, and maybe the Democrats and the NRA would want to get in on the act as well, to give their members sort of a "vanity plate" certificate.  And who is to say no, especially if someone could finally make some money in the business?

In fact, one possible compromise ¯ one that I am neither advocating nor deprecating, merely pointing out ¯  would be to restrict the use of logos to end-entity certificates, whereupon most of he issues of cross-certification, name subordination, etc., go away immediately.

There is still the possibility that a CA violates the logo trademark and hands it out to someone without authorization, but any CA I know of has more than enough lawyers to realize the consequences of trademark infringement, so I don't think we need to worry about that.

Bob

>>> "Michael Myers" <[e-mail]> 09/04/01 11:34AM >>>

All,

I agree with Stephen Farrell and Steve Hanna that logotypes are out of
scope.  These needs are better addressed by other forums.  Let's focus the
WG's remaining energy on resolving DPV/DPD issues.

Mike


> On Thursday, August 30, 2001 2:35 AM Stephen Farrell wrote in part:
> . . .
> Steve (K),
>
> I'd have to agree with Steve H, though maybe not as strongly.
> My suggestion would be to limit the additional items to the
> dpd/dpv.


> On  Wednesday, August 29, 2001 2:01 PM Steve Hanna wrote in part:
>
> . . . I don't think PKIX should do any work on the
> logotype extension. I know that there is a demand for this from
> marketing folks, but I don't believe that we should standardize it
> unless it can be used securely. This does not seem possible.




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f84K0YM17176 for ietf-pkix-bks; Tue, 4 Sep 2001 13:00:34 -0700 (PDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84K0WD17012 for <[e-mail]>; Tue, 4 Sep 2001 13:00:32 -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 OAA26609; Tue, 4 Sep 2001 14:00:30 -0600 (MDT)
Received: from sun.com (dhcp75-167 [129.148.75.167]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA01119; Tue, 4 Sep 2001 16:00:31 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 04 Sep 2001 16:00:12 -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: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: charter revisions
References: <p0501040bb7a8214adf35@[128.33.84.34]>	 <[e-mail]> <p0501040ab7b458549900@[128.33.238.96]> <[e-mail]> <p05010403b7bab9e15dcc@[128.33.84.34]>
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>

Stephen Kent wrote:
> The same name may be used for products or by organizations in
> different "areas" if there is a belief that no confusion will result.
> However, a trademark, in its graphic form, is also a copyrighted image
> and as such is subject to a different set of legal rules that
> generally prohibit outright duplication. The legal challenges arise
> when two logos seem too similar to one another, in the eyes of one of
> the logo holders, and this is when courts step in and adjudicate the
> dispute. Nonetheless, this discussion does not argue against the
> ability of a CA to make a judgement about the legitimacy of a
> subject's claim to the right to use a trademarked logo. Perahps the
> point you're making above is that logos may not be as uniquely helpful
> in identifying an organization because of the possibility of similar
> logos being used by entities in different areas. That's a fair
> critique, but in a different dimension.

I don't think copyright would help much if two companies had trademarks
in different countries for a logo that looks like a red circle. But
IANAL, so I will abandon that line of argument. Maybe the international
copyright and trademark system is strong enough to ensure that the same
logo cannot be registered by two different entities in different
countries, even if one of those entities is a sham operated by criminals
for the purpose of impersonating the other.

You do make a good point that two logos different enough to be legally
distinct may not be distinguishable to the average user. It's also true
that users may not remember the logo associated with a particular
company. Visa, yes. But maybe not Schwab.

> > Do we know of any CAs that want to include logotypes in certificates
> > that they issue, plan to verify those logotypes, and would be
> > willing to
> > provide some sort of assurances to back that up in their CPS's?
> 
> Stefan represents one such CA service provider.

Really? I haven't heard Stefan say anything about how AddTrust would
verify logotypes or what assurances his company would provide in this
regard. Maybe he told you this in private conversation.

> I would prefer to find a way to impose some form of constraint on
> the appearance of logos analogous to what we do in cross certs for names
> or policies.  because a logo is not structured, the name constraints
> mechanism can never be used in so precise a fashion, even if we choose
> to put a logo in some name form. but, it would be nice to have a way
> to prevent a CA further down a cross-cert chain from introducing a
> logo if one wants to prevent such action. Just because we don't have a
> mechanism to do this yet doesn't mean we can't work toward one.

This would mean that all existing cross-certificates would allow
logotypes in certificates. It might be better to say that certificate
containing a logotype should not be validated (or, at least, the
logotype should be ignored) unless all preceding certificates in the
path have an extension that says logotypes are allowed.

> > > >Third, an apparently innocuous logotype can change appearance
> > radically
> > > >when scaled to a smaller size or mapped to a different number of
> > colors.
> > > >This can be exploited to deceive cell phone users into thinking
> > that
> > > >they're communicating with their bank, for instance.
> > >
> > > I had not considered this issue. we should explore ways that this
> > > problem might be avoided. presumably anyone displaying a logo on a
> > > web page has a similar concern, so maybe there are viable means to
> > > address this issue.
> >
> > The problem with displaying a logo on a web page is different
> > (unless I
> > didn't understand you). With a logo in a certificate, we want to
> > make
> > sure that the person requesting the certificate doesn't trademark a
> > bogus logo and get it included in their certificate just so they can
> > trick a user who sees a scaled-down version of the logo into
> > believing
> > it's a trusted logo. The closest analogy is getting a web server
> > certificate for paypa1.com (where the letter ell is actually a
> > number
> > one). If you can get the user to click on an https://www.paypa1.com
> > URL,
> > the user will think they are viewing a secure paypal website if the
> > font
> > they use to view URLs displays ell and one the same way.
> >
> > When viewing a logo on a web page, the user should not make
> > decisions
> > about whose web page it is based on the logo. Instead, we have been
> > trying to convince them to look at the host name in the URL and
> > check
> > that the padlock or key is lit up to indicate that an SSL connection
> > is
> 
> > in use.
> 
> The reality is that logos on web pages are designed to inspire
> confidence in users based on visiting the web page, period. Yes,
> someone can put up a similar logo to try to fool people, or even put
> up the valid logo without the permission of the logo owner. We rely on
> the legal system to detect and remedy these problems, ex post facto.
> That's not as good as preventing them, but many folks argue that it is
> better than not offering a logo-based marking facility.  When it comes
> to putting logos in certs, we have a better mechanism in many cases,
> since the binding is secured and there are fewer CAs than there are
> web sites.

Just seeing a logo on a web page doesn't inspire much confidence in me.
Yes, the logo owner will probably pursue those who misuse the logo. But
the Internet is a rough place. The miscreants may skip town with no
forwarding address and I (the user) will be very sad if I gave them my
brokerage account password and they emptied the account.

That's why we have HTTPS. The end user notices that the padlock or key
is lit up and decides that the host name in the URL is OK, so they enter
their brokerage account password. If we change this so that the user is
deciding that a *logo* is OK, I want to make sure the binding between
the logotype and the public key is secure and that the logotype that
appears in the certificate is properly displayed to the user.

But this is completely pedantic. The original issue was that a logo can
change appearance when it's scaled or mapped to different colors. A pink
circle is different from a green circle for trademark and copyright
purposes. But how do you distinguish them when they're displayed on a
black and white screen? I don't think that web page technology has any
magic bullets in this area. And what about blind users? With URLs, they
can have their screen-reader read the URL back to them. Graphics will be
completely inaccessible.

-Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f84JtV012534 for ietf-pkix-bks; Tue, 4 Sep 2001 12:55:31 -0700 (PDT)
Received: from zolera.com (IDENT:root@[63.142.188.177]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84JtSD12264 for <[e-mail]>; Tue, 4 Sep 2001 12:55:28 -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 f84JtYB28778; Tue, 4 Sep 2001 15:55:35 -0400
Message-ID: <[e-mail]>
Date: Tue, 04 Sep 2001 15:55:36 -0400
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: charter revisions
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>

Is the CA processing for adding a logo extension any different from
adding any other extension?  I don't see how/why.

Can't this work item be accomplished just by an RFC that assigns OID's
to some popular image formats?

	/r$

-- 
Zolera Systems, Your Key to Online Integrity
Securing Web services: XML, SOAP, Dig-sig, Encryption
http://www.zolera.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f84HdcG22971 for ietf-pkix-bks; Tue, 4 Sep 2001 10:39:38 -0700 (PDT)
Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84HdbD22967 for <[e-mail]>; Tue, 4 Sep 2001 10:39:37 -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.3) with SMTP id f84HZSH06802; Tue, 4 Sep 2001 10:35:28 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: "Steve Hanna" <[e-mail]>, <[e-mail]>
Subject: RE: charter revisions
Date: Tue, 4 Sep 2001 10:34: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
In-Reply-To: <[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>

All,

I agree with Stephen Farrell and Steve Hanna that logotypes are out of
scope.  These needs are better addressed by other forums.  Let's focus the
WG's remaining energy on resolving DPV/DPD issues.

Mike


> On Thursday, August 30, 2001 2:35 AM Stephen Farrell wrote in part:
> . . .
> Steve (K),
>
> I'd have to agree with Steve H, though maybe not as strongly.
> My suggestion would be to limit the additional items to the
> dpd/dpv.


> On  Wednesday, August 29, 2001 2:01 PM Steve Hanna wrote in part:
>
> . . . I don't think PKIX should do any work on the
> logotype extension. I know that there is a demand for this from
> marketing folks, but I don't believe that we should standardize it
> unless it can be used securely. This does not seem possible.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f84HYSf22756 for ietf-pkix-bks; Tue, 4 Sep 2001 10:34:28 -0700 (PDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84HYLD22752 for <[e-mail]>; Tue, 4 Sep 2001 10:34:22 -0700 (PDT)
Received: from [128.33.84.34] (comsec.bbn.com [128.33.84.34]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id NAA29280; Tue, 4 Sep 2001 13:35:55 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010405b7babf0191e9@[128.33.84.34]>
In-Reply-To: <[e-mail]>
References: <p0501040bb7a8214adf35@[128.33.84.34]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 4 Sep 2001 13:28:09 -0400
To: Denis Pinkas <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: charter revisions (2)
Cc: Steve Hanna <[e-mail]>, "Housley, Russ" <[e-mail]>, [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>

At 6:55 PM +0200 9/4/01, Denis Pinkas wrote:
>Steve,
>
>I have much sympathy with your position. During the London meeting
>I expressed reservations (not to say more) about this idea.
>
>I have a major problem with the wording below:
>
>"Not all of these items may become standards track RFCs. Some may become
>INFORMATIONAL or EXPERIMENTAL RFCs."
>
>It implicity means that the document will either become a STANDARD, an
>INFORMATIONAL or an EXPERIMENTAL RFCs, while the logo type document could
>never turn out into an RFC at all, because several member of the WG have
>expressed reservations.
>
>ISO has the concept of a "study period" where ideas can be debated before a
>NWI is placed on the menu. We don't have officially this equivalent.
>However, in that case, it would be wise to adopt a similar approach:
>it seems too early to include the logo type proposal on the charter, at
>least using the current wording mentionned above.
>
>However, it also seems difficult to refuse any discussion on that topic,
>even if, for some of us, it will be a waste of our time to argue on the
>advantages and disadvantages of the proposal.
>
>So I propose the following compromise: to allow for the discussion on that
>topic on the mailing list, without for the time being any commitment from
>the WG that the proposal will ever become a STANDARD, an INFORMATIONAL or an
>EXPERIMENTAL RFC.
>
>Denis

I know that I was not the "Steve" to whom the message was addressed, 
but since Tim and I drafted the revised charter I will reply anyway.

We could reword the charter to not require that the new work items 
yield an RFC, i.e., one of more of the proposed items may fail to 
make it as an RFC. However, because publication as an Informational 
RFC is generally an easy thing to do, absent a strong negative 
reactions by a WG, I think it likely that all of the items cited have 
a very good opportunity to become RFCs in one of the 3 forms noted.

Steve



Received: by above.proper.com (8.11.6/8.11.3) id f84HOX922559 for ietf-pkix-bks; Tue, 4 Sep 2001 10:24:33 -0700 (PDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84HOVD22555 for <[e-mail]>; Tue, 4 Sep 2001 10:24:31 -0700 (PDT)
Received: from [128.33.84.34] (comsec.bbn.com [128.33.84.34]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id NAA27389; Tue, 4 Sep 2001 13:26:36 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010404b7babe9a79ed@[128.33.84.34]>
In-Reply-To: <[e-mail]>
References: <p0501040bb7a8214adf35@[128.33.84.34]> <[e-mail]>
Date: Tue, 4 Sep 2001 13:24:45 -0400
To: Denis Pinkas <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: charter revisions
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>

At 6:51 PM +0200 9/4/01, Denis Pinkas wrote:
>Steve,
>
>This is a very late answer, but I took some more vacations. :-)
>
>During the London meeting I presented some preliminary work about an
>INFORMATIONAL RFC on PKI Disaster Planning and Recovery and I realized that
>this is not included in the new charter.

Good point. We can include this topic if others support it's inclusion.

>
>I would think that the following time table could be appropriate:
>
>  3/04  PKI Disaster Planning and Recovery. INFORMATIONAL RFC.

OK, pending resolution of the above comment.

>
>Would it still be possible to add it to the list ?

Yes.

>
>I also found that 3/02 for DPV/DPD Protocols RFCs, may be a little bit
>optimistic. 3/04 would probably be more appropriate.

OK, I'll make that change.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f84HOOt22551 for ietf-pkix-bks; Tue, 4 Sep 2001 10:24:24 -0700 (PDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84HOMD22543 for <[e-mail]>; Tue, 4 Sep 2001 10:24:22 -0700 (PDT)
Received: from [128.33.84.34] (comsec.bbn.com [128.33.84.34]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id NAA27381; Tue, 4 Sep 2001 13:26:35 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010403b7bab9e15dcc@[128.33.84.34]>
In-Reply-To: <[e-mail]>
References: <p0501040bb7a8214adf35@[128.33.84.34]>	 <[e-mail]> <p0501040ab7b458549900@[128.33.238.96]> <[e-mail]>
Date: Tue, 4 Sep 2001 13:22:52 -0400
To: Steve Hanna <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: charter revisions
Cc: [e-mail]
Content-Type: multipart/alternative; boundary="============_-1212498106==_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>

--============_-1212498106==_ma============
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable

At 11:58 AM -0400 9/4/01, Steve Hanna wrote:
>Stephen Kent wrote:
>>  Just as a CA may employ various means to verify a subject's claim to
>>  a name, a CA can employ analogous means to verify a subject's claim
>>  to a logotype.  In fact, this may be relatively easy to verify if the
>>  logo is a registered trademark (something a CA could require via its
>>  CPS).
>
>As Michael Str=F6der pointed out, this may not be easy for CAs. Requiring
>that a logo be a registered trademark doesn't mean that there won't be
>conflicts. A particular logo can be trademarked by different parties in
>different countries. In fact, it can sometimes be trademarked by
>different parties in the same country if there is little likelihood of
>confusion (as when the goods identified are very different). And it may
>be difficult for a CA to judge whether a particular image matches a
>registered trademark. Verifying someone's right to use a DNS name or
>email address is much easier.

The same name may be used for products or by organizations in 
different "areas" if there is a belief that no confusion will result. 
However, a trademark, in its graphic form, is also a copyrighted 
image and as such is subject to a different set of legal rules that 
generally prohibit outright duplication. The legal challenges arise 
when two logos seem too similar to one another, in the eyes of one of 
the logo holders, and this is when courts step in and adjudicate the 
dispute. Nonetheless, this discussion does not argue against the 
ability of a CA to make a judgement about the legitimacy of a 
subject's claim to the right to use a trademarked logo. Perahps the 
point you're making above is that logos may not be as uniquely 
helpful in identifying an organization because of the possibility of 
similar logos being used by entities in different areas. That's a 
fair critique, but in a different dimension.

>Do we know of any CAs that want to include logotypes in certificates
>that they issue, plan to verify those logotypes, and would be willing to
>provide some sort of assurances to back that up in their CPS's?

Stefan represents one such CA service provider.

>If not, I will claim that including logotypes in certificates will have
>a negative effect on security. Some CAs will be glad to charge extra to
>include a logotype, but if the CA does not verify the logotype and
>disclaims all responsibility for the correctness of the logotype, then
>what's the point? The user will be misled into believing that the
>logotypes have some security significance.

PKIX has long adopted the position that a CA should not include data 
in certs that the CA does not verify, even though this is not a 
universally agreed upon position.  The same philosophy could apply 
here.

>Certainly, CAs are welcome to include anything they want in their
>certificates. But we should not provide a PKIX blessing unless there is
>some security benefit.

See comments immediately above.

>
>>  >Second, there's no equivalent to name constraints for use in cross
>>  >certificates. If I cross certify someone, I just have to trust that the=
y
>>  >(and anyone they certify) will only put proper logotypes into
>>  >certificates.
>>
>>  This has been my greatest concern as well, and I'd like to see a
>>  better proposal on how to better control use of the extension.
>>  Stefan rejected some approaches, and provided rationales for the
>>  rejections, but that doesn't mean that we have to live with the
>>  current proposal if the WG finds the inherent security problematic.
>
>Since the logotypes are to be used to identify issuers and subjects,
>I think we must develop a solution to this problem. Otherwise, a
>cross-certificate represents complete trust in the subject to
>certify anyone.

I would prefer to find a way to impose some form of constraint on the 
appearance of logos analogous to what we do in cross certs for names 
or policies.  because a logo is not structured, the name constraints 
mechanism can never be used in so precise a fashion, even if we 
choose to put a logo in some name form. but, it would be nice to have 
a way to prevent a CA further down a cross-cert chain from 
introducing a logo if one wants to prevent such action. Just because 
we don't have a mechanism to do this yet doesn't mean we can't work 
toward one.

>  > >Third, an apparently innocuous logotype can change appearance radicall=
y
>>  >when scaled to a smaller size or mapped to a different number of colors=
=2E
>>  >This can be exploited to deceive cell phone users into thinking that
>>  >they're communicating with their bank, for instance.
>>
>>  I had not considered this issue. we should explore ways that this
>>  problem might be avoided. presumably anyone displaying a logo on a
>>  web page has a similar concern, so maybe there are viable means to
>>  address this issue.
>
>The problem with displaying a logo on a web page is different (unless I
>didn't understand you). With a logo in a certificate, we want to make
>sure that the person requesting the certificate doesn't trademark a
>bogus logo and get it included in their certificate just so they can
>trick a user who sees a scaled-down version of the logo into believing
>it's a trusted logo. The closest analogy is getting a web server
>certificate for paypa1.com (where the letter ell is actually a number
>one). If you can get the user to click on an https://www.paypa1.com URL,
>the user will think they are viewing a secure paypal website if the font
>they use to view URLs displays ell and one the same way.
>
>When viewing a logo on a web page, the user should not make decisions
>about whose web page it is based on the logo. Instead, we have been
>trying to convince them to look at the host name in the URL and check
>that the padlock or key is lit up to indicate that an SSL connection is
>in use.

The reality is that logos on web pages are designed to inspire 
confidence in users based on visiting the web page, period. Yes, 
someone can put up a similar logo to try to fool people, or even put 
up the valid logo without the permission of the logo owner. We rely 
on the legal system to detect and remedy these problems, ex post 
facto.  That's not as good as preventing them, but many folks argue 
that it is better than not offering a logo-based marking facility. 
When it comes to putting logos in certs, we have a better mechanism 
in many cases, since the binding is secured and there are fewer CAs 
than there are web sites.

>
>>  >Unless these concerns can be addressed, I do not think that this
>>  >proposal is safe and secure. And I do not think that the IETF should
>>  >publish an RFC on a fundamentally insecure idea, especially from a
>>  >security working group.
>>
>>  The attribute RFC has some problems too, in that bad choices of how
>>  to map an AC to a PKC can result in security failures, right?  So,
>>  the issue is not whether there are insecure ways to make use of the
>>  extension, but whether there are ways to make its use secure and
>>  whether, on the balance, we think appropriate use of the extension
>>  is beneficial, from a security (not marketing) perspective.
>
>Agreed. If we believe that IETF standardization of this extension will
>be beneficial from a security perspective, then we should go ahead with
>it. Otherwise, we should not. I remain unconvinced.
>
>-Steve
>
>P.S. Note that I have no personal advantage (and, as far as I know, my
>employer has no corporate advantage) to gain by the adoption or failure
>of this particular proposal. My views are my own and don't represent the
>views of Sun Microsystems. I just want to see the working group spend
>its energies on worthwhile projects.

Same here.

Steve
--============_-1212498106==_ma============
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type=3D"text/css"><!--
blockquote, dl, ul, ol, li { margin-top: 0 ; margin-bottom: 0 }
 --></style><title>Re: charter revisions</title></head><body>
<div>At 11:58 AM -0400 9/4/01, Steve Hanna wrote:</div>
<blockquote type=3D"cite" cite>Stephen Kent wrote:<br>
&gt; Just as a CA may employ various means to verify a subject's claim
to<br>
&gt; a name, a CA can employ analogous means to verify a subject's
claim<br>
&gt; to a logotype.&nbsp; In fact, this may be relatively easy to
verify if the<br>
&gt; logo is a registered trademark (something a CA could require via
its<br>
&gt; CPS).<br>
<br>
As Michael Str=F6der pointed out, this may not be easy for CAs.
Requiring<br>
that a logo be a registered trademark doesn't mean that there won't
be<br>
conflicts. A particular logo can be trademarked by different parties
in<br>
different countries. In fact, it can sometimes be trademarked by<br>
different parties in the same country if there is little likelihood
of<br>
confusion (as when the goods identified are very different). And it
may<br>
be difficult for a CA to judge whether a particular image matches
a<br>
registered trademark. Verifying someone's right to use a DNS name
or</blockquote>
<blockquote type=3D"cite" cite>email address is much
easier.</blockquote>
<div><br></div>
<div>The same<u> name</u> may be used for products or by organizations
in different &quot;areas&quot; if there is a belief that no confusion
will result. However, a trademark, in its graphic form, is also a
copyrighted image and as such is subject to a different set of legal
rules that generally prohibit outright duplication. The legal
challenges arise when two logos seem too similar to one another, in
the eyes of one of the logo holders, and this is when courts step in
and adjudicate the dispute. Nonetheless, this discussion does not
argue against the ability of a CA to make a judgement about the
legitimacy of a subject's claim to the right to use a trademarked
logo. Perahps the point you're making above is that logos may not be
as uniquely helpful in identifying an organization because of the
possibility of similar logos being used by entities in different
areas. That's a fair critique, but in a different dimension.</div>
<div><br></div>
<blockquote type=3D"cite" cite>Do we know of any CAs that want to
include logotypes in certificates<br>
that they issue, plan to verify those logotypes, and would be willing
to<br>
provide some sort of assurances to back that up in their
CPS's?</blockquote>
<div><br></div>
<div>Stefan represents one such CA service provider.</div>
<div><br></div>
<blockquote type=3D"cite" cite>If not, I will claim that including
logotypes in certificates will have<br>
a negative effect on security. Some CAs will be glad to charge extra
to<br>
include a logotype, but if the CA does not verify the logotype and<br>
disclaims all responsibility for the correctness of the logotype,
then<br>
what's the point? The user will be misled into believing that
the</blockquote>
<blockquote type=3D"cite" cite>logotypes have some security
significance.</blockquote>
<div><br></div>
<div>PKIX has long adopted the position that a CA should not include
data in certs that the CA does not verify, even though this is not a
universally agreed upon position.&nbsp; The same philosophy could
apply here.</div>
<div><br></div>
<blockquote type=3D"cite" cite>Certainly, CAs are welcome to include
anything they want in their<br>
certificates. But we should not provide a PKIX blessing unless there
is</blockquote>
<blockquote type=3D"cite" cite>some security benefit.</blockquote>
<div><br></div>
<div>See comments immediately above.</div>
<div><br></div>
<blockquote type=3D"cite" cite><br>
&gt; &gt;Second, there's no equivalent to name constraints for use in
cross<br>
&gt; &gt;certificates. If I cross certify someone, I just have to
trust that they<br>
&gt; &gt;(and anyone they certify) will only put proper logotypes
into<br>
&gt; &gt;certificates.<br>
&gt;<br>
&gt; This has been my greatest concern as well, and I'd like to see
a<br>
&gt; better proposal on how to better control use of the
extension.<br>
&gt; Stefan rejected some approaches, and provided rationales for
the<br>
&gt; rejections, but that doesn't mean that we have to live with
the<br>
&gt; current proposal if the WG finds the inherent security
problematic.<br>
<br>
Since the logotypes are to be used to identify issuers and
subjects,<br>
I think we must develop a solution to this problem. Otherwise, a<br>
cross-certificate represents complete trust in the subject to<br>
certify anyone.</blockquote>
<div><br></div>
<div>I would prefer to find a way to impose some form of constraint on
the appearance of logos analogous to what we do in cross certs for
names or policies.&nbsp; because a logo is not structured, the name
constraints mechanism can never be used in so precise a fashion, even
if we choose to put a logo in some name form. but, it would be nice to
have a way to prevent a CA further down a cross-cert chain from
introducing a logo if one wants to prevent such action. Just because
we don't have a mechanism to do this yet doesn't mean we can't work
toward one.</div>
<div><br></div>
<blockquote type=3D"cite" cite>&gt; &gt;Third, an apparently innocuous
logotype can change appearance radically<br>
&gt; &gt;when scaled to a smaller size or mapped to a different number
of colors.<br>
&gt; &gt;This can be exploited to deceive cell phone users into
thinking that<br>
&gt; &gt;they're communicating with their bank, for instance.<br>
&gt;<br>
&gt; I had not considered this issue. we should explore ways that
this<br>
&gt; problem might be avoided. presumably anyone displaying a logo on
a<br>
&gt; web page has a similar concern, so maybe there are viable means
to<br>
&gt; address this issue.<br>
<br>
The problem with displaying a logo on a web page is different (unless
I<br>
didn't understand you). With a logo in a certificate, we want to
make<br>
sure that the person requesting the certificate doesn't trademark
a<br>
bogus logo and get it included in their certificate just so they
can<br>
trick a user who sees a scaled-down version of the logo into
believing<br>
it's a trusted logo. The closest analogy is getting a web server<br>
certificate for paypa1.com (where the letter ell is actually a
number<br>
one). If you can get the user to click on an https://www.paypa1.com
URL,<br>
the user will think they are viewing a secure paypal website if the
font<br>
they use to view URLs displays ell and one the same way.<br>
<br>
When viewing a logo on a web page, the user should not make
decisions<br>
about whose web page it is based on the logo. Instead, we have
been<br>
trying to convince them to look at the host name in the URL and
check<br>
that the padlock or key is lit up to indicate that an SSL connection
is</blockquote>
<blockquote type=3D"cite" cite>in use.</blockquote>
<div><br></div>
<div>The reality is that logos on web pages are designed to inspire
confidence in users based on visiting the web page, period. Yes,
someone can put up a similar logo to try to fool people, or even put
up the valid logo without the permission of the logo owner. We rely on
the legal system to detect and remedy these problems, ex post facto.&nbsp;
That's not as good as preventing them, but many folks argue that it is
better than not offering a logo-based marking facility.&nbsp; When it
comes to putting logos in certs, we have a better mechanism in many
cases, since the binding is secured and there are fewer CAs than there
are web sites.</div>
<div><br></div>
<blockquote type=3D"cite" cite><br>
&gt; &gt;Unless these concerns can be addressed, I do not think that
this<br>
&gt; &gt;proposal is safe and secure. And I do not think that the IETF
should<br>
&gt; &gt;publish an RFC on a fundamentally insecure idea, especially
from a<br>
&gt; &gt;security working group.<br>
&gt;<br>
&gt; The attribute RFC has some problems too, in that bad choices of
how<br>
&gt; to map an AC to a PKC can result in security failures, right?&nbsp;
So,<br>
&gt; the issue is not whether there are insecure ways to make use of
the<br>
&gt; extension, but whether there are ways to make its use secure
and<br>
&gt; whether, on the balance, we think appropriate use of the
extension<br>
&gt; is beneficial, from a security (not marketing) perspective.<br>
<br>
Agreed. If we believe that IETF standardization of this extension
will<br>
be beneficial from a security perspective, then we should go ahead
with<br>
it. Otherwise, we should not. I remain unconvinced.<br>
<br>
-Steve<br>
<br>
P.S. Note that I have no personal advantage (and, as far as I know,
my<br>
employer has no corporate advantage) to gain by the adoption or
failure<br>
of this particular proposal. My views are my own and don't represent
the<br>
views of Sun Microsystems. I just want to see the working group
spend<br>
its energies on worthwhile projects.</blockquote>
<div><br></div>
<div>Same here.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1212498106==_ma============--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f84GtnC21870 for ietf-pkix-bks; Tue, 4 Sep 2001 09:55:49 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84GtlD21866 for <[e-mail]>; Tue, 4 Sep 2001 09:55:47 -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 SAA61688; Tue, 4 Sep 2001 18:57: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 SAA15618; Tue, 4 Sep 2001 18:55:14 +0200
Message-ID: <[e-mail]>
Date: Tue, 04 Sep 2001 18:55:14 +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: Steve Hanna <[e-mail]>
CC: "Housley, Russ" <[e-mail]>, Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: charter revisions (2)
References: <p0501040bb7a8214adf35@[128.33.84.34]> <[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>

Steve,

I have much sympathy with your position. During the London meeting 
I expressed reservations (not to say more) about this idea.

I have a major problem with the wording below:

"Not all of these items may become standards track RFCs. Some may become
INFORMATIONAL or EXPERIMENTAL RFCs."

It implicity means that the document will either become a STANDARD, an
INFORMATIONAL or an EXPERIMENTAL RFCs, while the logo type document could
never turn out into an RFC at all, because several member of the WG have
expressed reservations. 

ISO has the concept of a "study period" where ideas can be debated before a
NWI is placed on the menu. We don't have officially this equivalent.
However, in that case, it would be wise to adopt a similar approach: 
it seems too early to include the logo type proposal on the charter, at
least using the current wording mentionned above.

However, it also seems difficult to refuse any discussion on that topic,
even if, for some of us, it will be a waste of our time to argue on the
advantages and disadvantages of the proposal. 

So I propose the following compromise: to allow for the discussion on that
topic on the mailing list, without for the time being any commitment from
the WG that the proposal will ever become a STANDARD, an INFORMATIONAL or an
EXPERIMENTAL RFC.

Denis

> > I do not think that we will see widespread deployment of
> > certificates without logos.  One measure of success will be the
> > number of certificates that average Internet user have.  Hopefully
> > every Internet user will have at least one.  I suspect that as we
> > become successful, these logos will be the tag by which users
> > select a certificate.
> 
> This is an interesting argument. I think you're saying that the user
> will find the logo useful when deciding which of his certificates to
> use (such as when signing an email or performing client authentication
> over SSL). If this were the primary use of logotypes in certificates,
> then the risks of displaying an invalid logo would be considerably
> reduced (the user might select the wrong one of his certificates to
> authenticate with). However, the current logotype Internet Draft does
> not describe this use case. All of the use cases described in section
> 1.1 of that document have the user looking at a logo to decide
> whether a certificate presented by some other party is trustworthy.
> In those cases, the risks of making an error are much greater.
> 
> Unless the author of the Internet Draft indicates otherwise, I will
> assume that the primary purpose of putting logotypes in certificates
> is so that users can view them to make decisions about whether the
> certificates are trustworthy. In that case, the risks are much greater
> than those for the use case you described.
> 
> > I do not want to see more than one way that logos can be put into
> > certificates. That is the most important reason for PKIX to be
> > involved in the definition. You seem to agree that the market has
> > a demand for logos. Letting each vendor devise an independent way
> > to meet this marketing requirement would be very bad for all
> > implementors.
> 
> Unless we can develop a fairly secure way to meet the "marketing
> requirement" for logotypes in certificates, I would say that it is
> our obligation as an IETF working group to NOT accept this as a
> work item. Much better to have multiple incompatible ways
> to do something insecure (probably resulting in little deployment
> of this feature) than to have the PKIX working group issue an RFC
> explaining the one true way to do it. We are in the Security area,
> after all!
> 
> > Anyway, we should not have the complete technical debate on a
> > threat about the charter.
> 
> Certainly, we don't need to have the complete technical debate at
> this point. But there should be some requirement that work items
> be feasible and provide some security benefit before they are
> accepted by this working group. Otherwise, we will waste our time
> (and confuse the public) by accepting all sort of ideas and then
> having to throw them out.
> 
> -Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f84Gpmp21794 for ietf-pkix-bks; Tue, 4 Sep 2001 09:51:48 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84GpkD21790 for <[e-mail]>; Tue, 4 Sep 2001 09:51:46 -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 SAA25156; Tue, 4 Sep 2001 18:53:45 +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 SAA19218; Tue, 4 Sep 2001 18:51:13 +0200
Message-ID: <[e-mail]>
Date: Tue, 04 Sep 2001 18:51:13 +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: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: charter revisions
References: <p0501040bb7a8214adf35@[128.33.84.34]>
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,

This is a very late answer, but I took some more vacations. :-)

During the London meeting I presented some preliminary work about an
INFORMATIONAL RFC on PKI Disaster Planning and Recovery and I realized that
this is not included in the new charter.

I would think that the following time table could be appropriate:

 3/04  PKI Disaster Planning and Recovery. INFORMATIONAL RFC.

Would it still be possible to add it to the list ?

I also found that 3/02 for DPV/DPD Protocols RFCs, may be a little bit
optimistic. 3/04 would probably be more appropriate.

Regards,

Denis

> 
> Folks,
> 
> We were pinged about the need to update the PKIX WG charter, both during
> the meeting in London, and via a message the chairs received from the IETF
> Secretariat. So, here is a proposed revision to the charter that Tim and I
> have developed.  Please review it and provide comments by 8/28, so that we
> can post the revised charter by the end of the momth.
> 
> Thanks,
> 
> Steve
> -------
> 
> Description of Working Group:
> 
> The PKIX Working Group was established in the Fall of 1995 with the intent
> of developing Internet standards needed to support an X.509-based PKI. The
> scope of PKIX work has expanded beyond this initial goal. PKIX not only
> profiles ITU PKI standards, but also develops new standards apropos to the
> use of X.509-based PKIs in the Internet.
> 
> PKIX has produced several informational and standards track documents in
> support of the original and revised scope of the WG. The first of these
> standards, RFC 2459, profiled X.509 version 3 certificates and version 2
> CRLs for use in the Internet. Profiles for the use of LDAP v2 for
> certificate and CRL storage (RFC 2587), the Internet X.509 Public Key
> Infrastructure Qualified Certificates Profile (RFC 2875), and the Internet
> X.509 Public Key Infrastructure Certificate Policy and certification
> Practices Framework (RFC 2527 - Informational) are in line with the
> initial scope.
> 
> The Certificate Management Protocol (CMP) (RFC 2510), the Online
> Certificate Status Protocol (OCSP) (RFC 2560), Certificate Management
> Request Format (CRMF) (RFC 2511),  Certificate Management Messages over
> CMS (RFC 2797),  Internet X.509 Public Key Infrastructure Time Stamp
> Protocols (RFC xxxx), and the use of FTP and HTTP for transport of PKI
> operations (RFC 2585) are representative of the expanded scope of PKIX, as
> these are new protocols developed in the working group, not profiles of
> ITU PKI standards.
> 
> A roadmap, providing a guide to the growing set of PKIX document, also has
> been developed as an informational RFC.
> 
> Ongoing PKIX Work items
> 
> An ongoing PKIX task is the progression of existing, standards track RFCs
> from PROPOSED to DRAFT. Also, to the extent that PKIX work relates to
> protocols from other areas, e.g., LDAP, it is necessary to track the
> evolution of the other protocols and produce updated RFCs. For example,
> the LDAP v2 documents from PKIX are evolving to address LDAP v3.
> 
> New Work items for PKIX
> 
> - production of a requirements RFC for delegated path discovery and path
> validation protocols (DPD/DPV) and subsequent production of RFCs for
> protocols that satisfy the requirements
> 
> - development of an RFC for a logotype extension for certificates
> 
> - development of a proxy certificate extension and associated processing
> rules
> 
> Not all of these items may become standards track RFCs. Some may become
> INFORMATIONAL or EXPERIMENTAL RFCs.
> 
> Goals and Milestones:
> 
> Done         PROPOSED Standard RFCs for public key and attribute
> certificate profiles, CMP, OCSP, CMC, CRMF, TSP, Qualified Certificates,
> LDAP v2 schema, use of FTP/HTTP, Diffie-Hellman POP
> Done            INFORMATIONAL RFCs for X.509 PKI policies and practices,
> use of KEA
> Done         Experimental RFC for Data Validation and Certification Server
> Protocols
> 8/01             Production of revised certificate and CRL syntax and
> processing RFC (son-of-2459)
> 10/01          Progression of CRMF, CMP, and CMP Transport to DRAFT
> Standard
> 12/01              Production of revised CMC RFCs (updates and split of
> CMC into several parts)
> 12/ 01              DPD/DVP Requirements RFC
> 12/01           Progression of OCSP to DRAFT Standard
> 3/02               DPV/DPD Protocols RFCs
> 3/02              Logotype Extension RFC
> 3/02              Proxy Certificate RFC
> 7/02               Progression of CMC RFCs to DRAFT Standard


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f84G2a620941 for ietf-pkix-bks; Tue, 4 Sep 2001 09:02:36 -0700 (PDT)
Received: from mtiwmhc23.worldnet.att.net (mtiwmhc23.worldnet.att.net [204.127.131.48]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84G2YD20937 for <[e-mail]>; Tue, 4 Sep 2001 09:02:35 -0700 (PDT)
Received: from webmail.worldnet.att.net ([204.127.135.60]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <[e-mail]>; Tue, 4 Sep 2001 16:02:31 +0000
Received: from [161.215.27.111] by webmail.worldnet.att.net; Tue, 04 Sep 2001 16:02:30 +0000
From: [e-mail]
To: Carlisle Adams <[e-mail]>
Cc: "'tho'" <[e-mail]>, [e-mail]
Subject: RE: New test TSA available
Date: Tue, 04 Sep 2001 16:02:30 +0000
X-Mailer: AT&T Message Center Version 1 (May  2 2001)
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>

> Hi tho,
> 
> > ----------
> > From: 	tho[SMTP:[e-mail]]
> > Sent: 	Tuesday, September 04, 2001 4:26 AM
> > To: 	[e-mail]
> > Subject: 	Re: New test TSA available
> > 
> > hi todd,
> >    
> > todd glassey wrote:
> > > 1)      In the existing RFC, the data about how the time data was
> > obtained
> > > and how it was managed so that in the future someone can look at TST's
> > from
> > > any number of sources and compare their validity or deviation from the
> > > proscribed time source. This also means a audit model around the time
> > base
> > > itself. And it implies that the operator knows how to manage UTC in
> > relation
> > > to its soft value.
> > >
> > > 2)    A declaratory payload - something that can be used to indicate the
> > > intent of the executor of the TST itself. That way going forward in the
> > > future the Courts would not have to interpret that. And maybe other
> > payload
> > > types. Like the BERT Token for instance.
> > 
> > i think that these two points should be a matter of policy (and
> > corresponding
> > practice statement) for which we have a pointer inside the TSTInfo
>  
> Absolutely.
> 
> As far as I can tell, we all understand and agree on this point, except for
> Todd.
> 
> [Todd:  if you think that these points of yours were being marginalized all
> this time, this may be why.  You were either alone or in the extreme
> minority in voicing them, and in IETF "rough consensus" is the only thing
> that leads to any progress at all, so the "rough consensus" opinion is what
> shows up in the RFCs...]
> 
> Carlisle.
> 

You are right Carlisle - they were marginalized. But the reason that anyone 
possibly could marginalize what I was saying was 
'cause they refused to state how the Protocol was to 
be used. What you and the rest of the Authors did was 
to create a protocol for verifying signatures in time 
and declared that the be "the Time Stamping protocol" 
and that is just plain wrong.

What you should have done is said "we are creating a 
protocol to memorialize events in time and to make them
comparable to each other thus." And then with that 
simple statem a set of uses could have been nuilt for 
the tokens and their creation. Instead what you have 
done is built the plumbing for the movement of the 
time without qualifying the time so that the content 
is essentially anonymous in nature.

If any of you authors had built a real word use model 
for this boat-anchor you would have come to the 
conslusions I and the other auditors, pki designers, 
time keepers, and security specialists who looked at 
the protocol did. And that is that the protocol is of 
limited if any real-world use since already existing 
methods do the same things and are already legally 
accepted by Courts on a global basis.

Thus the TSP and its TST's are an overhead not a blessing 
of testimonial value.

Sorry -

Todd



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f84FxKt20365 for ietf-pkix-bks; Tue, 4 Sep 2001 08:59:20 -0700 (PDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84FxJD20358 for <[e-mail]>; Tue, 4 Sep 2001 08:59:19 -0700 (PDT)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA05688; Tue, 4 Sep 2001 08:59:19 -0700 (PDT)
Received: from sun.com (dhcp75-167 [129.148.75.167]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24615; Tue, 4 Sep 2001 11:59:17 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 04 Sep 2001 11:58:57 -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: "Housley, Russ" <[e-mail]>
CC: Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: charter revisions
References: <p0501040bb7a8214adf35@[128.33.84.34]> <[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 Housley wrote:
> I do not think that we will see widespread deployment of
> certificates without logos.  One measure of success will be the
> number of certificates that average Internet user have.  Hopefully
> every Internet user will have at least one.  I suspect that as we
> become successful, these logos will be the tag by which users
> select a certificate.

This is an interesting argument. I think you're saying that the user
will find the logo useful when deciding which of his certificates to
use (such as when signing an email or performing client authentication
over SSL). If this were the primary use of logotypes in certificates,
then the risks of displaying an invalid logo would be considerably
reduced (the user might select the wrong one of his certificates to
authenticate with). However, the current logotype Internet Draft does
not describe this use case. All of the use cases described in section
1.1 of that document have the user looking at a logo to decide
whether a certificate presented by some other party is trustworthy.
In those cases, the risks of making an error are much greater.

Unless the author of the Internet Draft indicates otherwise, I will
assume that the primary purpose of putting logotypes in certificates
is so that users can view them to make decisions about whether the
certificates are trustworthy. In that case, the risks are much greater
than those for the use case you described.

> I do not want to see more than one way that logos can be put into
> certificates. That is the most important reason for PKIX to be
> involved in the definition. You seem to agree that the market has
> a demand for logos. Letting each vendor devise an independent way
> to meet this marketing requirement would be very bad for all
> implementors.

Unless we can develop a fairly secure way to meet the "marketing
requirement" for logotypes in certificates, I would say that it is
our obligation as an IETF working group to NOT accept this as a
work item. Much better to have multiple incompatible ways
to do something insecure (probably resulting in little deployment
of this feature) than to have the PKIX working group issue an RFC
explaining the one true way to do it. We are in the Security area,
after all!

> Anyway, we should not have the complete technical debate on a
> threat about the charter.

Certainly, we don't need to have the complete technical debate at
this point. But there should be some requirement that work items
be feasible and provide some security benefit before they are
accepted by this working group. Otherwise, we will waste our time
(and confuse the public) by accepting all sort of ideas and then
having to throw them out.

-Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f84Fx0620300 for ietf-pkix-bks; Tue, 4 Sep 2001 08:59:00 -0700 (PDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84FwxD20294 for <[e-mail]>; Tue, 4 Sep 2001 08:58:59 -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 JAA04027; Tue, 4 Sep 2001 09:58:56 -0600 (MDT)
Received: from sun.com (dhcp75-167 [129.148.75.167]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA22806; Tue, 4 Sep 2001 11:58:58 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 04 Sep 2001 11:58:38 -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: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: charter revisions
References: <p0501040bb7a8214adf35@[128.33.84.34]> <[e-mail]> <p0501040ab7b458549900@[128.33.238.96]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
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:
> Just as a CA may employ various means to verify a subject's claim to
> a name, a CA can employ analogous means to verify a subject's claim
> to a logotype.  In fact, this may be relatively easy to verify if the
> logo is a registered trademark (something a CA could require via its
> CPS).

As Michael Ströder pointed out, this may not be easy for CAs. Requiring
that a logo be a registered trademark doesn't mean that there won't be
conflicts. A particular logo can be trademarked by different parties in
different countries. In fact, it can sometimes be trademarked by
different parties in the same country if there is little likelihood of
confusion (as when the goods identified are very different). And it may
be difficult for a CA to judge whether a particular image matches a
registered trademark. Verifying someone's right to use a DNS name or
email address is much easier.

Do we know of any CAs that want to include logotypes in certificates
that they issue, plan to verify those logotypes, and would be willing to
provide some sort of assurances to back that up in their CPS's?

If not, I will claim that including logotypes in certificates will have
a negative effect on security. Some CAs will be glad to charge extra to
include a logotype, but if the CA does not verify the logotype and
disclaims all responsibility for the correctness of the logotype, then
what's the point? The user will be misled into believing that the
logotypes have some security significance.

Certainly, CAs are welcome to include anything they want in their
certificates. But we should not provide a PKIX blessing unless there is
some security benefit.

> >Second, there's no equivalent to name constraints for use in cross
> >certificates. If I cross certify someone, I just have to trust that they
> >(and anyone they certify) will only put proper logotypes into
> >certificates.
> 
> This has been my greatest concern as well, and I'd like to see a
> better proposal on how to better control use of the extension.
> Stefan rejected some approaches, and provided rationales for the
> rejections, but that doesn't mean that we have to live with the
> current proposal if the WG finds the inherent security problematic.

Since the logotypes are to be used to identify issuers and subjects,
I think we must develop a solution to this problem. Otherwise, a
cross-certificate represents complete trust in the subject to
certify anyone.

> >Third, an apparently innocuous logotype can change appearance radically
> >when scaled to a smaller size or mapped to a different number of colors.
> >This can be exploited to deceive cell phone users into thinking that
> >they're communicating with their bank, for instance.
> 
> I had not considered this issue. we should explore ways that this
> problem might be avoided. presumably anyone displaying a logo on a
> web page has a similar concern, so maybe there are viable means to
> address this issue.

The problem with displaying a logo on a web page is different (unless I
didn't understand you). With a logo in a certificate, we want to make
sure that the person requesting the certificate doesn't trademark a
bogus logo and get it included in their certificate just so they can
trick a user who sees a scaled-down version of the logo into believing
it's a trusted logo. The closest analogy is getting a web server
certificate for paypa1.com (where the letter ell is actually a number
one). If you can get the user to click on an https://www.paypa1.com URL,
the user will think they are viewing a secure paypal website if the font
they use to view URLs displays ell and one the same way.

When viewing a logo on a web page, the user should not make decisions
about whose web page it is based on the logo. Instead, we have been
trying to convince them to look at the host name in the URL and check
that the padlock or key is lit up to indicate that an SSL connection is
in use.

> >Unless these concerns can be addressed, I do not think that this
> >proposal is safe and secure. And I do not think that the IETF should
> >publish an RFC on a fundamentally insecure idea, especially from a
> >security working group.
> 
> The attribute RFC has some problems too, in that bad choices of how
> to map an AC to a PKC can result in security failures, right?  So,
> the issue is not whether there are insecure ways to make use of the
> extension, but whether there are ways to make its use secure and
> whether, on the balance, we think appropriate use of the extension
> is beneficial, from a security (not marketing) perspective.

Agreed. If we believe that IETF standardization of this extension will
be beneficial from a security perspective, then we should go ahead with
it. Otherwise, we should not. I remain unconvinced.

-Steve

P.S. Note that I have no personal advantage (and, as far as I know, my
employer has no corporate advantage) to gain by the adoption or failure
of this particular proposal. My views are my own and don't represent the
views of Sun Microsystems. I just want to see the working group spend
its energies on worthwhile projects.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f84FkPO18146 for ietf-pkix-bks; Tue, 4 Sep 2001 08:46:25 -0700 (PDT)
Received: from dns01.infocamere.it (dns01.infocamere.it [193.70.148.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84FkND18138 for <[e-mail]>; Tue, 4 Sep 2001 08:46:23 -0700 (PDT)
Received: from esd03d.icnet ([193.70.148.67]) by dns01.infocamere.it (Netscape Messaging Server 4.15) with ESMTP id GJ5A1H00.D2E for <[e-mail]>; Tue, 4 Sep 2001 17:36:53 +0200 
Received: from infocamere.it ([1.5.16.68]) by esd03d.icnet (Netscape Messaging Server 4.15) with ESMTP id GJ5AIA00.HUD for <[e-mail]>; Tue, 4 Sep 2001 17:46:58 +0200 
Message-ID: <[e-mail]>
Date: Tue, 04 Sep 2001 17:42:07 +0200
From: "Simonato Carolina" <[e-mail]>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: IETF-PKIX <[e-mail]>
Subject: Question: who signs a CRL if the CAcertificate, that signs it, is  immediately revoked?
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>

Hello all!

Suppose a simple situation in which a certificate chain is constituted
only by two certificates: a trusted (by some important authority) root
certificate (self-signed) and an end-entity certificate, signed by that
root certificate.
The same root certificate also signs the certificate revocation list (a
unique crl that contains all revoked certificates- for all reasons).
The problem is: who signs the crl when the root certificate is
immediately revoked, because of, for example, cacompromise?
Probably it is necessary to create a new couple of keys (and so a new
root certificate) and sign the crl with the new  ca private key?
Or is it possible to create a couple of  CA keys to sign only
certificate revocation list and not to make provision for revoking this
last  ca root certificate?

I would like to riceive suggestions about this topic.
Thank you in advance.

regards
Carolina



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f84EslL14941 for ietf-pkix-bks; Tue, 4 Sep 2001 07:54:47 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84EsjD14937 for <[e-mail]>; Tue, 4 Sep 2001 07:54:46 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <SDDPPLJJ>; Tue, 4 Sep 2001 10:54:38 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'tho'" <[e-mail]>
Cc: [e-mail]
Subject: RE: New test TSA available
Date: Tue, 4 Sep 2001 10:54:31 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13551.80FAD5B0"
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_01C13551.80FAD5B0
Content-Type: text/plain

Hi tho,

> ----------
> From: 	tho[SMTP:[e-mail]]
> Sent: 	Tuesday, September 04, 2001 4:26 AM
> To: 	[e-mail]
> Subject: 	Re: New test TSA available
> 
> hi todd,
>    
> todd glassey wrote:
> > 1)      In the existing RFC, the data about how the time data was
> obtained
> > and how it was managed so that in the future someone can look at TST's
> from
> > any number of sources and compare their validity or deviation from the
> > proscribed time source. This also means a audit model around the time
> base
> > itself. And it implies that the operator knows how to manage UTC in
> relation
> > to its soft value.
> >
> > 2)    A declaratory payload - something that can be used to indicate the
> > intent of the executor of the TST itself. That way going forward in the
> > future the Courts would not have to interpret that. And maybe other
> payload
> > types. Like the BERT Token for instance.
> 
> i think that these two points should be a matter of policy (and
> corresponding
> practice statement) for which we have a pointer inside the TSTInfo
 
Absolutely.

As far as I can tell, we all understand and agree on this point, except for
Todd.

[Todd:  if you think that these points of yours were being marginalized all
this time, this may be why.  You were either alone or in the extreme
minority in voicing them, and in IETF "rough consensus" is the only thing
that leads to any progress at all, so the "rough consensus" opinion is what
shows up in the RFCs...]

Carlisle.


------_=_NextPart_001_01C13551.80FAD5B0
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: New test TSA available</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
tho,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">tho[SMTP:[e-mail]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Tuesday, September 04, 2001 4:26 =
AM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[e-mail]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">Re: New test TSA available</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">hi todd,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">todd glassey wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; 1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
In the existing RFC, the data about how the time data was =
obtained</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; and how it was managed so that =
in the future someone can look at TST's from</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; any number of sources and =
compare their validity or deviation from the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; proscribed time source. This =
also means a audit model around the time base</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; itself. And it implies that the =
operator knows how to manage UTC in relation</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; to its soft value.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; 2)&nbsp;&nbsp;&nbsp; A =
declaratory payload - something that can be used to indicate the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; intent of the executor of the =
TST itself. That way going forward in the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; future the Courts would not have =
to interpret that. And maybe other payload</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; types. Like the BERT Token for =
instance.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">i think that these two points should =
be a matter of policy (and corresponding</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">practice statement) for which we have =
a pointer inside the TSTInfo</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Absolutely.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">As far as =
I can tell, we all understand and agree on this point, except for =
Todd.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">[Todd:&nbsp; if you think that these points of yours were being =
marginalized all this time, this may be why.&nbsp; You were either =
alone or in the extreme minority in voicing them, and in IETF =
&quot;rough consensus&quot; is the only thing that leads to any =
progress at all, so the &quot;rough consensus&quot; opinion is what =
shows up in the RFCs...]</FONT></P>

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

</BODY>
</HTML>
------_=_NextPart_001_01C13551.80FAD5B0--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f848QLH18343 for ietf-pkix-bks; Tue, 4 Sep 2001 01:26:21 -0700 (PDT)
Received: from firewall.andxor.it (firewall.andxor.it [195.223.2.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f848QHD18339 for <[e-mail]>; Tue, 4 Sep 2001 01:26:18 -0700 (PDT)
Received: from tho.andxor.com (tho.andxor.it [195.223.2.222]) by firewall.andxor.it (8.9.2/8.9.2) with ESMTP id KAA75090 for <[e-mail]>; Tue, 4 Sep 2001 10:26:15 +0200 (CEST) (envelope-from [e-mail])
Received: (from tho@localhost) by tho.andxor.com (8.9.3/8.9.3) id KAA64037 for [e-mail]; Tue, 4 Sep 2001 10:26:29 +0200 (CEST) (envelope-from tho)
Date: Tue, 4 Sep 2001 10:26:29 +0200
From: tho <[e-mail]>
To: [e-mail]
Subject: Re: New test TSA available
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <03dc01c134ed$427fa680$020aff0c@tsg1>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <03dc01c134ed$427fa680$020aff0c@tsg1>; from [e-mail] on Mon, Sep 03, 2001 at 07:56:50PM -0700
X-Operating-System: FreeBSD
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 todd,
   
todd glassey wrote:
> 1)      In the existing RFC, the data about how the time data was obtained
> and how it was managed so that in the future someone can look at TST's from
> any number of sources and compare their validity or deviation from the
> proscribed time source. This also means a audit model around the time base
> itself. And it implies that the operator knows how to manage UTC in relation
> to its soft value.
>
> 2)    A declaratory payload - something that can be used to indicate the
> intent of the executor of the TST itself. That way going forward in the
> future the Courts would not have to interpret that. And maybe other payload
> types. Like the BERT Token for instance.

i think that these two points should be a matter of policy (and corresponding
practice statement) for which we have a pointer inside the TSTInfo

tho
--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f842wDc15342 for ietf-pkix-bks; Mon, 3 Sep 2001 19:58:13 -0700 (PDT)
Received: from mtiwmhc21.worldnet.att.net (mtiwmhc21.worldnet.att.net [204.127.131.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f842w7D15338 for <[e-mail]>; Mon, 3 Sep 2001 19:58:07 -0700 (PDT)
Received: from tsg1 ([12.81.64.34]) by mtiwmhc21.worldnet.att.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <20010904025753.TMIM1680.mtiwmhc21.worldnet.att.net@tsg1>; Tue, 4 Sep 2001 02:57:53 +0000
Message-ID: <03dc01c134ed$427fa680$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Jean-Marc Desperrier" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: New test TSA available
Date: Mon, 3 Sep 2001 19:56:50 -0700
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.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
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 Apologies to many of you. This is a another push back against the TSA and
what I believe to be the manner in which criticism to the design or
suggestions for the design have been taken.

As to the complaint Jean-Marc made that no one raised objections, just look
in the archive.  Every time I or someone else objected to the draft we were
slammed. Sometimes politely but most times not. Many times I myself got back
a belligerent blast of  "NO TODD, WE ARE NOT GOING TO..." and I have to tell
you that people just get tired of being beaten up over the obvious.

For the record - I personally have objected to this time stamping protocol
for the exact same reasons now for the last 3 years. Some of them are listed
below for your reading enjoyment. And it seems from the responses that
nobody was willing to hear that in order for a TS Solution to be embraced by
the world it must have some positive Business Value other than just by
trying to sneak it into law. One would think that the protocol has to do
something positive of value for the transaction process or it has no ongoing
value and as such then becomes an overhead.

Look at this from the standpoint of the Business Operator.

Example #1: they are self insured, so what value in their process is a
timestamp over a simple systems audit process and a timebase management
process. Either way the time data coming out of the report generator has to
be believed... so then what value is the TST in this?

If I believe that both of these are OK, then a simple printed report is all
the Evidence they need. If they need to attach entity to the time data
itself, which is at best a legal stretch, then they can easily hash and sign
the time data itself before they stick it in the DB - they don't need a TST
or a TSA to do this. They can do it with scripts inline in a CGI script or
an ASP model easily and quickly. All they would need is a secured site and a
good audit of the operations of the site and the time management regimen and
viola, what timestamps do they need?

If we need to go to court, you bring your timestamps and the CPS/RPA and I
bring my reports and timebase management audits and we will see who
prevails.  So once again I have to ask "why would I want a formal
oken?"  -- As it happens, there are a couple of good answers here, but they
both require TSTokens that are much larger so that they can contain the
material being stamped and carry other payloads for things like Notorial
Seal Info.

Otherwise I just cant see anyway to justify this device. Its true, it is a
simple system for passing "unauthenticated and uncertified" time data to a
limited use stamp token, but there is no specific value relative to the
trust model of whether I have a TSA as a TTP or not. As such it adds nothing
to the trust or indemnity model other than its own cost of operations, and
its something that the same operators couldn't get from an application and a
DB and an accompanying affidavit from the Operators.

Example #2 - The business uses a TSA to timestamp the services it provides
instead of relying on just a single field in a DB. Now there is a totally
secured linkage between the TSA and the client server too, and a relational
linkage between the DB rows and the tokens.

Does this reduce the operating liability? probably not unless you can see
how some externally linked token can reduce the operating risk on the
systems underlying the transaction process.

Example #3 - Two busnesses doing business between themselves in front of the
TTP. - So the TTP watches the transaction and issues a token as the receipt
for this service. The next question then is would the token be enough for a
receipt and myself I vote no. They are too small.

The Points:
------------
The point is that Time Stamping was supposed to be more than just checking
to see whether a signature was valid at some point in time as it was in
TSA Draft version 1. The TSP's only value over existing trust processes is
in creating a token that could memorialize an event. And could do so in a
commercial environment in such a way as to add value to the transaction
model. Or to substantiate some legal requirement in a filing process
although most of these would do just fine with a report from some DB
Application.

Time Stamps of the past and today
------------------------------------
TS's have for 10's or years been instances of time data stored in Databases
and that's it. The fact that the report that the report generator printed
time data on it from the DB as part of an event verification or testimony
has been accepted for some time is also very relevant here.

What then would I use a TST for then? Certainly not just for the creation of
the TST, if its just about testing to see whether a signature is valid there
are many ways to do that. No its ablaut creating some portable evidentiary
token to codify some event. The problem is that this TST is so light weight
and ignores all of the background testimony that it has the same legal value
(IMHO) as the testimony of the systems operators. And that makes it
worthless for any historical or long term evidentiary use.

The problem is that much of what also represents the events is the rest of
the row of data or the rows correlated or attached to it forming a larger
event structure. There is no legal difference in this type or report or in
an operator signing a printed report with a Digital Key. Legally they have
exactly the same value. So why then would I invest in or buy a TS Solution
that didn't add more to it.

What's missing is simple. As I have said many times in the past -

1)      In the existing RFC, the data about how the time data was obtained
and how it was managed so that in the future someone can look at TST's from
any number of sources and compare their validity or deviation from the
proscribed time source. This also means a audit model around the time base
itself. And it implies that the operator knows how to manage UTC in relation
to its soft value.

2)    A declaratory payload - something that can be used to indicate the
intent of the executor of the TST itself. That way going forward in the
future the Courts would not have to interpret that. And maybe other payload
types. Like the BERT Token for instance.

The other problem...
--------------------
In closing I would point out that the services of the PKIX time stamping
service can be had through NTP and perhaps some of Syslog too. And that as
such, this protocol is a piker. It pretty much does what the pre-existing
NTP and Syslog do together and based in that it violated the "no replicating
protocols that have been designed in other WG's" rule. OOOps.

What should have happened is that PKIX should of come up with something
other than a TST as a universal method of attaching time data to tokens or
other objects, something that could be used across all PKIX and a universal
Message Format for PKI based responses as well -  and this would have been
big win.

Instead we got what we got after 13 trips to the alter and the demise of the
Notary Draft in the process.


Todd


----- Original Message -----
From: "Jean-Marc Desperrier" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, August 27, 2001 2:57 AM
Subject: Re: New test TSA available


>
> Peter Gutmann wrote:
>
> > But the token only allows one version value, v1, which is always present
anyway
> > (that is, it's a non-optional field).  Thus my earlier questions, that
there's
> > no way to indicate that you're using draft-n because it's assumed
there's only
> > one version, v1, as per the final RFC.  That means that anything from
> > draft-....-01 through to RFCxxxx can only indicate use of v1.
>
> A draft is just that, a draft.
> " It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress"
> And basically, you want them to become reference material.
> There isn't, and hasn't to be a formalism for interoperability between
versions of
> a draft.
>
> What is needed is a finalized version of this protocol in an RFC, so that
_this_
> becomes a reference, and something one can actually use for
interoperability.
> As long as this doesn't exist, the tokens can't be anything more than
laboratory
> experiments.
>
> Therefore the true question is why is this RFC still not there when
supposedly the
> draft is on the last stages of approval since monthes, and there hasn't
been any
> point raised about it in this mailing list since a long time ?
>
>




Received: by above.proper.com (8.11.6/8.11.3) id f82LGFd24145 for ietf-pkix-bks; Sun, 2 Sep 2001 14:16:15 -0700 (PDT)
Received: from [203.46.112.10] (mail.rsasecurity.com.au [203.46.112.10]) by above.proper.com (8.11.6/8.11.3) with SMTP id f82LGCD24141 for <[e-mail]>; Sun, 2 Sep 2001 14:16:13 -0700 (PDT)
Received: from [192.168.18.3] by [203.46.112.10] via smtpd (for [208.184.76.43]) with SMTP; 18 Mar 2001 17:16:28 UT
Received: from exaus01.local.aus.rsa.com (exaus01.local.aus.rsa.com [10.177.1.15]) by grover.local.aus.rsa.com (8.10.2/8.10.2) with ESMTP id f82LK4q26591 for <[e-mail]>; Mon, 3 Sep 2001 07:20:05 +1000 (EST)
Received: by exaus01.local.aus.rsa.com with Internet Mail Service (5.5.2653.19) id <QX7RVL2M>; Mon, 3 Sep 2001 07:11:08 +1000
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 QTWCT6SN; Sun, 2 Sep 2001 17:15:44 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Sun, 02 Sep 2001 17:15:30 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: RE: charter revisions
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>

>Russ:
>
>Do you honestly believe that CA or company based logos in certificates
>will actually bring critical mass to deployments?

No.  However, I think that mass deployments will not happen without logos.

>If I have 6 certs from the same company CA - logos does nothing for me
>here in cert selection . . .

I agree that logos do not completely solve the problem of selecting 
certificates.  However, when the certificates are from different CAs or 
thay have distinctly different purposes, then a logo can be a big help.


>-----Original Message-----
>From: Housley, Russ [mailto:[e-mail]]
>Sent: Thursday, August 30, 2001 10:33 AM
>To: Steve Hanna
>Cc: Stephen Kent; [e-mail]
>Subject: Re: charter revisions
>
>
>
>Steve Hanna:
>
> >I haven't seen any comments on the revised charter yet. Most of it
> >looks good to me. However, I don't think PKIX should do any work on the
>
> >logotype extension. I know that there is a demand for this from
> >marketing folks, but I don't believe that we should standardize it
> >unless it can be used securely. This does not seem possible.
>
>You and I agree on most things, but we have a major disagreement here.  I
>do not think that we will see widespread deployment of certificates without
>logos.  One measure of success will be the number of certificates that
>average Internet user have.  Hopefully every Internet user will have at
>least one.  I suspect that as we become successful, these logos will be
>the tag by which users select a certificate.
>
>I do not want to see more than one way that logos can be put into
>certificates.  That is the most important reason for PKIX to be involved
>in the definition.  You seem to agree that the market has a demand for
>logos.  Letting each vendor devise an independent way to meet this
>marketing requirement would be very bad for all implementors.
>
>You seem to be concerned with the security of logos.  I am not.  From my
>perspective, we are asking CAs to do many things that are harder than
>including a URL and hash of a the appropriate logo.  In many, many cases,
>this will be the same logo in every certificate that is issued by that CA.
>
>Anyway, we should not have the complete technical debate on a threat
>about the charter.  I strongly encourage the PKIX working group to include
>this area in the charter sent forward to the Area Directors for approval.
>Once the revised charter is approved, we can have the technical debate and
>sort out the details.
>
>Russ