RE: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-03.txt

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

Tim,

Two working days seems a bit tight given the breadth of
comments.  Given that constraint, silence may not necessarily
concurrence.  It could very well be the effects of our day jobs.
But that said, I'll see what I can do regarding those comments I
made.

Mike

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Tim Polk
> Sent: Friday, March 29, 2002 2:55 PM
> To: [e-mail]
> Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-03.txt
>
>
>
> Folks,
>
> The editors have informed me that they believe the
> -03 draft satisfies all
> WG Last Call comments and meets the criteria of rough
> consesnsus. My review
> agrees with their position, and I would like to ship
> the document to the
> ADs as soon as possible.
>
> If you have a dog in this fight, *please review the
> specification by
> Tuesday COB.*  If I do not see any traffic on the
> list stating that
> unresolved comments remain, I will forward the
> document to the ADs
> Wednesday morning.
>
> Thanks,
>
> Tim Polk
>
> At 07:03 AM 3/29/02 -0500, you wrote:
> >A New Internet-Draft is available from the on-line
> Internet-Drafts
> >directories.
> >This draft is a work item of the Public-Key
> Infrastructure (X.509) Working
> >Group of the IETF.
> >
> >         Title           : Delegated Path Validation
> and Delegated Path
> > Discovery
> >                           Protocol Requirements
> (DPV&DPD-REQ)
> >         Author(s)       : D. Pinkas, R. Housley
> >         Filename        : draft-ietf-pkix-dpv-dpd-req-03.txt
> >         Pages           : 11
> >         Date            : 28-Mar-02
> >
> >This document specifies the requirements for
> Delegated Path Validation
> >(DPV) and Delegated Path Discovery (DPD) for Public
> Key Certificates.
> >It also specifies the requirements for DPV and DPD
> policy management.
> >
> >A URL for this Internet-Draft is:
> >http://www.ietf.org/internet-drafts/draft-ietf-pkix-d
> pv-dpd-req-03.txt
> >
> >To remove yourself from the IETF Announcement list,
> send a message to
> >ietf-announce-request with the word unsubscribe in
> the body of the message.
> >
> >Internet-Drafts are also available by anonymous FTP.
> Login with the username
> >"anonymous" and a password of your e-mail address.
> After logging in,
> >type "cd internet-drafts" and then
> >         "get draft-ietf-pkix-dpv-dpd-req-03.txt".
> >
> >A list of Internet-Drafts directories can be found in
> >http://www.ietf.org/shadow.html
> >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> >Internet-Drafts can also be obtained by e-mail.
> >
> >Send a message to:
> >         [e-mail].
> >In the body type:
> >         "FILE
> /internet-drafts/draft-ietf-pkix-dpv-dpd-req-03.txt".
> >
> >NOTE:   The mail server at ietf.org can return the
> document in
> >         MIME-encoded form by using the "mpack"
> utility.  To use this
> >         feature, insert the command "ENCODING mime"
> before the "FILE"
> >         command.  To decode the response(s), you
> will need "munpack" or
> >         a MIME-compliant mail reader.  Different
> MIME-compliant mail readers
> >         exhibit different behavior, especially when
> dealing with
> >         "multipart" MIME messages (i.e. documents
> which have been split
> >         up into multiple messages), so check your
> local documentation on
> >         how to manipulate these messages.
> >
> >
> >Below is the data which will enable a MIME compliant
> mail reader
> >implementation to automatically retrieve the ASCII
> version of the
> >Internet-Draft.
> >Content-Type: text/plain
> >Content-ID:     <[e-mail]>
> >
> >ENCODING mime
> >FILE /internet-drafts/draft-ietf-pkix-dpv-dpd-req-03.txt
> >
> ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-d
pv-dpd-req-03.txt>





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2U26mI18208 for ietf-pkix-bks; Fri, 29 Mar 2002 18:06:48 -0800 (PST)
Received: from poseidon.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2U26km18200 for <[e-mail]>; Fri, 29 Mar 2002 18:06:47 -0800 (PST)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g2U26lO4029504; Fri, 29 Mar 2002 18:06:48 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "Tim Polk" <[e-mail]>, <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-03.txt
Date: Fri, 29 Mar 2002 18:04:06 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim,

Two working days seems a bit tight given the breadth of
comments.  Given that constraint, silence may not necessarily
concurrence.  It could very well be the effects of our day jobs.
But that said, I'll see what I can do regarding those comments I
made.

Mike

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Tim Polk
> Sent: Friday, March 29, 2002 2:55 PM
> To: [e-mail]
> Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-03.txt
>
>
>
> Folks,
>
> The editors have informed me that they believe the
> -03 draft satisfies all
> WG Last Call comments and meets the criteria of rough
> consesnsus. My review
> agrees with their position, and I would like to ship
> the document to the
> ADs as soon as possible.
>
> If you have a dog in this fight, *please review the
> specification by
> Tuesday COB.*  If I do not see any traffic on the
> list stating that
> unresolved comments remain, I will forward the
> document to the ADs
> Wednesday morning.
>
> Thanks,
>
> Tim Polk
>
> At 07:03 AM 3/29/02 -0500, you wrote:
> >A New Internet-Draft is available from the on-line
> Internet-Drafts
> >directories.
> >This draft is a work item of the Public-Key
> Infrastructure (X.509) Working
> >Group of the IETF.
> >
> >         Title           : Delegated Path Validation
> and Delegated Path
> > Discovery
> >                           Protocol Requirements
> (DPV&DPD-REQ)
> >         Author(s)       : D. Pinkas, R. Housley
> >         Filename        : draft-ietf-pkix-dpv-dpd-req-03.txt
> >         Pages           : 11
> >         Date            : 28-Mar-02
> >
> >This document specifies the requirements for
> Delegated Path Validation
> >(DPV) and Delegated Path Discovery (DPD) for Public
> Key Certificates.
> >It also specifies the requirements for DPV and DPD
> policy management.
> >
> >A URL for this Internet-Draft is:
> >http://www.ietf.org/internet-drafts/draft-ietf-pkix-d
> pv-dpd-req-03.txt
> >
> >To remove yourself from the IETF Announcement list,
> send a message to
> >ietf-announce-request with the word unsubscribe in
> the body of the message.
> >
> >Internet-Drafts are also available by anonymous FTP.
> Login with the username
> >"anonymous" and a password of your e-mail address.
> After logging in,
> >type "cd internet-drafts" and then
> >         "get draft-ietf-pkix-dpv-dpd-req-03.txt".
> >
> >A list of Internet-Drafts directories can be found in
> >http://www.ietf.org/shadow.html
> >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> >Internet-Drafts can also be obtained by e-mail.
> >
> >Send a message to:
> >         [e-mail].
> >In the body type:
> >         "FILE
> /internet-drafts/draft-ietf-pkix-dpv-dpd-req-03.txt".
> >
> >NOTE:   The mail server at ietf.org can return the
> document in
> >         MIME-encoded form by using the "mpack"
> utility.  To use this
> >         feature, insert the command "ENCODING mime"
> before the "FILE"
> >         command.  To decode the response(s), you
> will need "munpack" or
> >         a MIME-compliant mail reader.  Different
> MIME-compliant mail readers
> >         exhibit different behavior, especially when
> dealing with
> >         "multipart" MIME messages (i.e. documents
> which have been split
> >         up into multiple messages), so check your
> local documentation on
> >         how to manipulate these messages.
> >
> >
> >Below is the data which will enable a MIME compliant
> mail reader
> >implementation to automatically retrieve the ASCII
> version of the
> >Internet-Draft.
> >Content-Type: text/plain
> >Content-ID:     <[e-mail]>
> >
> >ENCODING mime
> >FILE /internet-drafts/draft-ietf-pkix-dpv-dpd-req-03.txt
> >
> ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-d
pv-dpd-req-03.txt>




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2TMuPE08266 for ietf-pkix-bks; Fri, 29 Mar 2002 14:56:25 -0800 (PST)
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 g2TMuNm08261 for <[e-mail]>; Fri, 29 Mar 2002 14:56:23 -0800 (PST)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.12.2/8.12.2) with ESMTP id g2TMuJCl028859 for <[e-mail]>; Fri, 29 Mar 2002 17:56:19 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 29 Mar 2002 17:54:51 -0500
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-03.txt
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>

Folks,

The editors have informed me that they believe the -03 draft satisfies all 
WG Last Call comments and meets the criteria of rough consesnsus. My review 
agrees with their position, and I would like to ship the document to the 
ADs as soon as possible.

If you have a dog in this fight, *please review the specification by 
Tuesday COB.*  If I do not see any traffic on the list stating that 
unresolved comments remain, I will forward the document to the ADs 
Wednesday morning.

Thanks,

Tim Polk

At 07:03 AM 3/29/02 -0500, you wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Public-Key Infrastructure (X.509) Working 
>Group of the IETF.
>
>         Title           : Delegated Path Validation and Delegated Path 
> Discovery
>                           Protocol Requirements (DPV&DPD-REQ)
>         Author(s)       : D. Pinkas, R. Housley
>         Filename        : draft-ietf-pkix-dpv-dpd-req-03.txt
>         Pages           : 11
>         Date            : 28-Mar-02
>
>This document specifies the requirements for Delegated Path Validation
>(DPV) and Delegated Path Discovery (DPD) for Public Key Certificates.
>It also specifies the requirements for DPV and DPD policy management.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-req-03.txt
>
>To remove yourself from the IETF Announcement list, send a message to
>ietf-announce-request with the word unsubscribe in the body of the message.
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>         "get draft-ietf-pkix-dpv-dpd-req-03.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>         [e-mail].
>In the body type:
>         "FILE /internet-drafts/draft-ietf-pkix-dpv-dpd-req-03.txt".
>
>NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>Content-Type: text/plain
>Content-ID:     <[e-mail]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-pkix-dpv-dpd-req-03.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-req-03.txt>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2TGpx521383 for ietf-pkix-bks; Fri, 29 Mar 2002 08:51:59 -0800 (PST)
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 g2TGpvm21378 for <[e-mail]>; Fri, 29 Mar 2002 08:51:57 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.us.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA494516; Fri, 29 Mar 2002 11:48:28 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g2TGppW183902; Fri, 29 Mar 2002 11:51:51 -0500
Importance: Normal
Sensitivity: 
Subject: Re: WG Last Call: Roadmap
To: Denis Pinkas <[e-mail]>
Cc: [e-mail], Carlisle Adams <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Fri, 29 Mar 2002 11:51:44 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.9a |January 28, 2002) at 03/29/2002 11:51: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>

      I have a few issues with this, and some corrections as well.
      In comment 12, I have two issues.  The first one, which is minor, is
that  "one or more Top CA's may be trusted" should refer to root CA's
instead - the two terms mean the same thing more often than not, but when
they differ the trust point is the root rather than the top.  The second is
less minor.  Is it truly intended that a signing EE be permitted to specify
the set of trusted CA's for an RP to use in verifying a signature?  At a
minimum, an RP in this model is responsible for validating the the set of
rules is identical to one it has already decided to trust, but there is no
reference in the model description to any active role for the RP.
      In your comment 5 (on page 15), replace "date of issue" by "date and
time of issue".
      At a slightly more substantive level, shouldn't the clarification of
the definition of Top CA on page 4 end "and reserve 'root CA' for a CA
directly trusted by the EE."?  This wording permits multiple trusted roots.
      In your comment 4, shouldn't "CA certificate" be "hierarchical CA
certificate"?  Surely a Top CA's self-signed certificate is also a "CA
certificate", and your definition excludes it.  Then the sentence "Some
people in the WG believe that a cross certificate is a special kind of CA
certificate." is reversed to "... believe that a hierarchical CA
certificate is a special kind of cross certificate".
      In comment 11, the i.e. should remain "what are the root CA's" rather
than "what are the Top CA's", for the same reason as in comment 12.

            Tom Gindin

Denis Pinkas <[e-mail]>@mail.imc.org on 03/26/2002 12:11:50 PM

Sent by:    [e-mail]


To:    [e-mail]
cc:    Carlisle Adams <[e-mail]>
Subject:    Re: WG Last Call: Roadmap



Comments on the roadmap document draft-ietf-pkix-roadmap-07.txt

(snip)
COMMENT 3. A sentence states: "However, to minimize confusion in this
document, we elect to call this node a "Top CA," and reserve "Root CA" for
the CA directly trusted by the EE". Since an EE may trust more than one Top
CA, shouldn't we say:

"However, to minimize confusion in this document, we elect to call this
node
a "Top CA," and reserve "Root CA" when there is a single CA directly
trusted
by the EE."


COMMENT 4. On page 14. A clarification needs to be done between
cross-certificates and CA certificates. The text currently states:

   A cross-certificate is a PKC issued by one CA to another CA which
   contains a public CA key associated with the private CA signature key
   used for issuing PKCs. Typically, a cross-certificate is used to
   allow client systems or end entities in one administrative domain to
   communicate securely with client systems or end users in another
   administrative domain. Use of a cross-certificate issued from CA_1 to
   CA_2 allows user Alice, who trusts CA_1, to accept a PKC used by Bob,
   which was issued by CA_2. Cross-certificates can also be issued from
   one CA to another CA in the same administrative domain, if required.

I would propose instead the following:

" A CA certificate is a certificate in a hierarchy that is neither a
self-signed certificate, nor an end-entity certificate. [2459bis] does not
make a difference between a CA certificate and a cross certificate since it
defines a cross-certificate as "a certificate issued by one CA to another
CA". Some people in the WG believe that a cross certificate is a special
kind of CA certificate. A cross certificate is issued by a CA under one
Top CA for another CA under a different Top CA. CAs in the same hierarchy
have part of their names imposed by the Top CA or by the CAs under that
Top CAS. When a cross certificate is issued, there is no relationship
between the names of the CAS.

Typically, a cross-certificate is used to allow client systems or end
entities in one administrative domain to communicate securely with client
systems or end users in another administrative domain. Use of a
cross-certificate issued from CA_1 to CA_2 allows user Alice, who trusts
CA_1, to accept a PKC used by Bob, which was issued by CA_2.
Cross-certificates can also be issued from one CA to another CA in the same
administrative domain, if required."


COMMENT 5. On page 15, the text states: "A CRL is a time stamped list
identifying revoked PKCs that is signed by a CA and made freely available
in a public repository."

I would prefer to avoid to use "time-stamped" in that context and thus I
would propose the following wording:

"A CRL is a list that identifies the references of revoked PKCs. This list
contains a date of issue and is signed by a CA and made freely available in
a public repository."


(snip)

COMMENT 11. On page 47. Section 5.5 talks about trust model, but only
consider a single trust point:

"  An important design decision is where a particular EE's trust point
   is located (i.e., where is the EE's Root CA). There are a number of
   models that have been developed and depending on the environment some
   models may be more suited than others. The following provides some
   background on the models."

I would rather propose to change it into:

" An important design decision is, for a given application, where the
particular EE's trust points are located (i.e. what are the Top CAs).
There are a number of models that have been developed and depending on
the environment some models may be more suited than others. The following
provides some background on the models."


COMMENT 12. On page 49. Section 5.5 I would propose to add another model.

5.5.5 Validation policies

Another model considers a set of rules that apply to an application
context.
Every application context may have a different set of rules. When choosing
to use certificates in the context of that application, the EE selects the
set of rules for that context. In a set of rules, one or more Top CAs may
be
trusted, each one may be associated with different constraints, like the
certificate policies that are trusted or the naming constraints that apply.
These constrains may be specified either in self-signed certificates or in
addition to self-signed certificates when they do not incorporate these
constraints. This set of rules is called a validation policy (when
validating a certificate) or a signature policy (when validating a digital
signature).

Regards,

Denis




Received: by above.proper.com (8.11.6/8.11.3) id g2TC3GJ00273 for ietf-pkix-bks; Fri, 29 Mar 2002 04:03:16 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2TC3Fm00269 for <[e-mail]>; Fri, 29 Mar 2002 04:03:15 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09250; Fri, 29 Mar 2002 07:03:13 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-03.txt
Date: Fri, 29 Mar 2002 07:03:13 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Delegated Path Validation and Delegated Path Discovery
                          Protocol Requirements (DPV&DPD-REQ)
	Author(s)	: D. Pinkas, R. Housley
	Filename	: draft-ietf-pkix-dpv-dpd-req-03.txt
	Pages		: 11
	Date		: 28-Mar-02
	
This document specifies the requirements for Delegated Path Validation 
(DPV) and Delegated Path Discovery (DPD) for Public Key Certificates. 
It also specifies the requirements for DPV and DPD policy management.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-req-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-dpv-dpd-req-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-dpv-dpd-req-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.6/8.11.3) id g2SG2vL07031 for ietf-pkix-bks; Thu, 28 Mar 2002 08:02:57 -0800 (PST)
Received: from tweety (pool-151-200-26-46.res.east.verizon.net [151.200.26.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2SG2sm07027 for <[e-mail]>; Thu, 28 Mar 2002 08:02:54 -0800 (PST)
Received: from [192.168.0.12] by tweety (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Thu, 28 Mar 2002 11:02:39 -0500
Message-ID: <[e-mail]>
Date: Thu, 28 Mar 2002 11:02:37 -0500
From: "Sean P. Turner" <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Kurt D. Zeilenga" <[e-mail]>
CC: [e-mail]
Subject: Re: WG Last Call: Roadmap
References: <5.1.0.14.0.20020327222457.02383e78@127.0.0.1>
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>

Kurt,

Wow I can't believe that's been in there that long.  Since this is
information the ID shouldn't be using that language.  There were three
instances of "MUST" and I changed them to must, but it's in the context
of "this other document says that it must ....".  So, I think it still
makes sense.  The other terms weren't used in the document at all.

spt

"Kurt D. Zeilenga" wrote:

> The introduction says:
>   "there are no requirements or specifications in this document"
> but then it uses RFC 2119 requirements language.
>
> Either the use of the RFC 2119 terms should be clarified
> as being not indicative of implementation requirements or
> other terms used.
>
> Kurt




Received: by above.proper.com (8.11.6/8.11.3) id g2SED2229748 for ietf-pkix-bks; Thu, 28 Mar 2002 06:13:02 -0800 (PST)
Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2SED0m29739 for <[e-mail]>; Thu, 28 Mar 2002 06:13:00 -0800 (PST)
Received: from tsg1 ([12.81.71.231]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020328141254.MAQH38.mtiwmhc22.worldnet.att.net@tsg1>; Thu, 28 Mar 2002 14:12:54 +0000
Message-ID: <000e01c1d662$8727dc00$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Miguel Angel Rodriguez" <[e-mail]>
Cc: <[e-mail]>, "vint cerf" <[e-mail]>, <[e-mail]>, "Nick Pope" <[e-mail]>
References: <000201c1d5a6$efeeda20$[e-mail]> <[e-mail]>
Subject: Re: Info on TimeStamp Patents
Date: Thu, 28 Mar 2002 06:11:58 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Someone asked me offline about this as well and the answer I gave them is
that RFC3161 is essentially useless by itself because it is not a standalone
evidentiary model and that any use of the technology in any way probably
violates any number of private and commercially held patents because of the
end-user's need to merge the RFC3161 functionality with numerous components
to make it of ***any*** use whatsoever.

In this particular instance, the problem is that the RFC3161 system is not a
complete evidentiary system and while the primary claim of the recently
struck-down Surety Patent RE34954's may be invalidated, that this does not
mean derivative systems based on other aspects of using the Time Stamp are
not covered under the numerous TS patents already issued including Surety's
RE34954, the Datum/Glassey/McNeil Patent -"Controlling Access to Stored
Information - EP997808A2" and ones by the XML houses for digital document
presentation.

I assure you folks that between the XML receipt people, and McNeil and I,
and those of Surety, and to some extent some of the IBM patents will
constrain most all timestamping methodologies. Not to mention the original
Pitney Bowes document timestamping ones, or any submitted by the Receipt.ORG
people.

But we (I and others) have said this all along this process, so this should
not be news to anyone.

Todd Glassey
----- Original Message -----
From: "Denis Pinkas" <[e-mail]>
To: "Miguel Angel Rodriguez" <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, March 28, 2002 3:32 AM
Subject: Re: Info on TimeStamp Patents


>
>
> > Hi!  Where can I get information on Time Stamp patents?
>
> The information is in the RFC 3161 section 5.
> Intellectual Property Rights
>
> Denis



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2SBWux17873 for ietf-pkix-bks; Thu, 28 Mar 2002 03:32:56 -0800 (PST)
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 g2SBWsm17866 for <[e-mail]>; Thu, 28 Mar 2002 03:32:54 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA12976; Thu, 28 Mar 2002 12:35:15 +0100
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002032812321953:35 ; Thu, 28 Mar 2002 12:32:19 +0100 
Message-ID: <[e-mail]>
Date: Thu, 28 Mar 2002 12:32:17 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Miguel Angel Rodriguez <[e-mail]>
CC: [e-mail]
Subject: Re: Info on TimeStamp Patents
References: <000201c1d5a6$efeeda20$[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 28/03/2002 12:32:19, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 28/03/2002 12:32:51, Serialize complete at 28/03/2002 12:32:51
Content-Transfer-Encoding: 7bit
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>

> Hi!  Where can I get information on Time Stamp patents?

The information is in the RFC 3161 section 5. 
Intellectual Property Rights

Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2S6TCx21760 for ietf-pkix-bks; Wed, 27 Mar 2002 22:29:12 -0800 (PST)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2S6TAm21756 for <[e-mail]>; Wed, 27 Mar 2002 22:29:10 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g2S6TFC70783 for <[e-mail]>; Thu, 28 Mar 2002 06:29:15 GMT (envelope-from [e-mail])
Message-Id: <5.1.0.14.0.20020327222457.02383e78@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 27 Mar 2002 22:29:31 -0800
To: [e-mail]
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: WG Last Call: Roadmap
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>

The introduction says:
  "there are no requirements or specifications in this document"
but then it uses RFC 2119 requirements language.

Either the use of the RFC 2119 terms should be clarified
as being not indicative of implementation requirements or
other terms used.

Kurt



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2RIxoR04935 for ietf-pkix-bks; Wed, 27 Mar 2002 10:59:50 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g2RIxmm04931 for <[e-mail]>; Wed, 27 Mar 2002 10:59:48 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 27 Mar 2002 18:59:02 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id NAA14222 for <[e-mail]>; Wed, 27 Mar 2002 13:58:59 -0500 (EST)
Received: from exno02.dynas.se (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g2RIxmv25105 for <[e-mail]>; Wed, 27 Mar 2002 13:59:49 -0500 (EST)
Received: by exno02.dynas.se with Internet Mail Service (5.5.2653.19) id <GNN5WFYJ>; Wed, 27 Mar 2002 19:59:15 +0100
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.134]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1L4N0; Wed, 27 Mar 2002 13:57:18 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 27 Mar 2002 13:50:03 -0500
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-01.txt
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>

Denis:

I fear that you have missed the point of the logotypes draft 
altogether.  The authors recognize that the introduction needs to be 
expanded, so we may be to blame for any misunderstanding.  To try and clear 
up the misunderstanding, I offer some general observations before 
responding to your specific comments.

The logotype extension will aid in two situations:
	1.  Certificate-based Identification
	2.  Selection of Certificates

In the first case, the need for human recognition depends on the manner in 
which certificates are used and whether certificates need to be visible to 
human users. If certificates are to be used in open environments and in 
applications that bring the user in conscious contact with the result of a 
certificate-based identification process, then human recognition is highly 
relevant, and it may be a necessity.

Most applications provide the human user with an opportunity to view the 
results of a successful certificate-based identification process.  When the 
user takes the steps necessary to view these results, the user is presented 
with a view of a certificate. This solution has two major problems.  First, 
the function to view a certificate is often rather hard to find for a 
non-technical user. Second, the presentation of the certificate is rather 
technical; it is not user friendly. It contains no graphic symbols or 
logotypes to enhance human recognition.

In the second case, there are software applications that expose human users 
to certificates for the selection of a single certificate from a portfolio 
of certificates. In some circumstances, the software application can use 
information within the certificates to determine suitability; however, the 
user must be queried if more than one certificate is suitable. The human 
user must select one of them.

This situation is comparable to a person selecting a suitable plastic card 
from his wallet. In this situation, substantial assistance is provided by 
card color, location, and branding.

In order provide similar support for certificate selection, the users need 
tools to easily recognize and distinguish certificates. Introduction of 
logotypes into certificates provides the necessary graphic.

Now, for your specific comments.

COMMENT 1: Subject logotype.

Currently a "subject organization logotype" is proposed. It definition is 
as follows: "a logotype representing the organization identified in the 
subject name in the certificate".

 From this definition only a single logotype would be allowed for a 
subject. It can make sense to attach more that one logotype to a subject, 
that does not reflect necessarily the organization a user belongs to (e.g. 
an individual is a Red Cross member) so the definition should be changed
to:

"subject logotype" "a logotype representing any characteristic of the 
entity identified in the subject name in the certificate".

RESPONSE 1.

We are allowing a graphical identity of the user to facilitate certificate 
selection or acceptance. We are not trying to graphically represent every 
attribute of the user.  We certainly do not want to overwhelm the designers 
of graphic user interfaces.  We need to keep it simple.

COMMENT 2: Issuer logotype.

Currently an "issuer organization logotype" is proposed. It definition is 
as follows: "a logotype representing the organization identified as part of 
the issuer name in the certificate".

 From this definition a single logotype would be allowed for an issuer. It 
can make sense to attach more that one logotype to an issuer, that does not 
reflect necessarily the organization an issuer belongs to (e.g. an issuer 
may support a "Privacy Policy" and be a member from two different trade 
associations), so the definition should be changed to:

"issuer logotype: a logotype representing any characteristic of the issuer 
identified as part of the issuer name in the certificate".

RESPONSE 2.

Again, we are allowing a graphical identity of the user to facilitate 
certificate selection or acceptance. We are not trying to graphically 
represent every attribute of the issuer.

COMMENT 3: The "concept logotype", also renamed "community logotype" during 
the last IETF meeting or " shared community logotype" in the minutes from 
the same meeting is more hazy.

The current text states:" Many issuers may use the concept logotypes to 
co-brand with a global concept in order to gain global recognition of its 
local service provision. This type of concept branding is very common in 
credit card business where local independent card issuers issue cards 
within a globally branded concept (such as VISA and MasterCard)".

The current text also states: " the relationship between the issuer and 
either the issuer  organization logotype or the concept logotype".

A logotype is adding "human processable" information to enhance the 
properties of an already existing field from a certificate. To this respect 
it is sensible to add one (or more) logotypes that characterizes the issuer 
and the subject. The real question is to which field the "concept
logotype / community logotype / shared community logotype" relates.

It may relate :
   - either to the issuer, to state that an issuer belongs to some group, or
   - to the certificate policy to state that the policy under which the
     certificate is issued obeys to some rules imposed by the organization
     whose logo is referenced.

This leads to two possible ways:
    1) only consider two logotypes: issuer logotype and subject logotypes.
    2) consider three logotypes: issuer logotypes, subject logotypes and
       policy logotypes.

I would favor the former, but would have no major problem to go with the 
later. In that case the policy logotype would be defined as follows:

"Policy logotype: a logotype representing any characteristic of the 
certificate policy under which the certificate is issued".

RESPONSE 3.

Policy implies the wrong connotation. We are not trying to graphically 
represent a certificate policy or anything about how the certificate was 
issued. The community (or concept) logotype simply allows CA to enter into 
collective branding relationships.

I suppose that a large group that share a common security policy could 
register a logo for that policy and use it as a community logo.  While this 
was not the model that we considered, it certainly is accommodated.


COMMENT 4: Logotypes are not "claimed" by the issuer, but always *verified* 
to some extend by the issuer. The current text is misleading:

    "The relationship between the subject organization and the subject
    organization logotype and the relationship between the issuer and
    either the issuer organization logotype or the concept logotype, are
    relationships *claimed* by the issuer."

RESPONSE 4.

The issuer is responsible for the verification of anything that is included 
in the certificate.  After all, the issuer signature covers it.  Thus, the 
issuer is claiming that the logotypes are appropriate.

COMMENT 5: During the meeting, it has been proposed to add a small image of 
the logotype in the certificate itself. In this WG we always have had a 
concern about the size of the certificate, so that it can be lodged in some 
small devices. So I would not favor to allow such provision in a
extension standardized by this WG.

RESPONSE 5.

There are environments where the client cannot access the Internet until 
after the certificate is used.  Consider certificate-based authentication 
to an ISP.  A small logotype in the certificate could be useful to aid 
certificate selection in this situation.  The inclusion of a small logotype 
is, of course, optional.

COMMENT 6: It should be made clear that this extension in non-critical.

RESPONSE 6.

Agree.  The logotype extension was never intended to be critical.

COMMENT 7: The document includes many typos to be corrected.

RESPONSE 7.

We will make every effort to correct them before the next draft is published.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2RFndp25359 for ietf-pkix-bks; Wed, 27 Mar 2002 07:49:39 -0800 (PST)
Received: from web.seguridata.com (seguridata02.terra.net.mx [200.4.103.226]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2RFnbm25347 for <[e-mail]>; Wed, 27 Mar 2002 07:49:37 -0800 (PST)
Received: from MarsXP ([192.168.0.166]) by web.seguridata.com (Post.Office MTA v3.5.3 release 223 ID# 517-61027U100L2S100V35) with ESMTP id com for <[e-mail]>; Wed, 27 Mar 2002 09:58:01 -0600
From: [e-mail] (Miguel Angel Rodriguez)
To: <[e-mail]>
Subject: Info on TimeStamp Patents
Date: Wed, 27 Mar 2002 09:49:10 -0600
Message-ID: <000201c1d5a6$efeeda20$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C1D574.A5546A20"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
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>

This is a multi-part message in MIME format.

------=_NextPart_000_0003_01C1D574.A5546A20
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi!  Where can I get information on Time Stamp patents?
 
Miguel A Rodriguez
SeguriDATA
Mexico

------=_NextPart_000_0003_01C1D574.A5546A20
Content-Type: text/html;
	charset="us-ascii"
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=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@01C1D574.A53919F0">
<!--[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:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
span.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;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:35.4pt;
	mso-footer-margin:35.4pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:36.0pt'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hi!<span style=3D'mso-spacerun:yes'>&nbsp; =
</span>Where can I
get information on Time Stamp patents?<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'>Miguel A Rodriguez<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'>SeguriDATA<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'>Mexico<o:p></o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0003_01C1D574.A5546A20--



Received: by above.proper.com (8.11.6/8.11.3) id g2RCBwI11395 for ietf-pkix-bks; Wed, 27 Mar 2002 04:11:58 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2RCBsm11385 for <[e-mail]>; Wed, 27 Mar 2002 04:11:54 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA06058; Wed, 27 Mar 2002 13:11:53 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 27 Mar 2002 13:11:53 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id NAA15134; Wed, 27 Mar 2002 13:11:51 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id NAA01385; Wed, 27 Mar 2002 13:11:51 +0100 (MET)
Date: Wed, 27 Mar 2002 13:11:51 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: RE: OpenEvidence
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> Could you forward the legal conditions (controlling use of the 
> "open source") agreed with the Commission concerning how 
> others may use the results of the funding, as produced by 
> the consortium members?

The current contract says: 

  All software will be available under an open source licence.
  At least, a licence with equivalent conditions as in the
  OPENSSL licence will be used, in order to promote a large
  distribution of the software as well in other open source
  projects, but also for other environments, while maintaining 
  a high visibility of the original contributors. 

Any suggestions are welcome. 




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2RA2Jf01623 for ietf-pkix-bks; Wed, 27 Mar 2002 02:02:19 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2RA2Gm01618 for <[e-mail]>; Wed, 27 Mar 2002 02:02:16 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id LAA05648; Wed, 27 Mar 2002 11:02:12 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 27 Mar 2002 11:02:13 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id LAA14899; Wed, 27 Mar 2002 11:02:11 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id LAA01343; Wed, 27 Mar 2002 11:02:11 +0100 (MET)
Date: Wed, 27 Mar 2002 11:02:11 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: WG Last Call: Roadmap
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>

> 
> All of your comments are accepted unaltered.  BTW - it was the IETF44 where the TSP
> IP issues were addressed (according to the minutes).
> 
This reminds me that I have send a comment privately: 

I propose a replacement of the text concerning dvcs composed
from the actual content of the RFC. 

Thanks for consideration.
Peter


  - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Data 
     Certification Server Protocols (RFC 3029) 
    
   DESCRIPTION:

   This document describes a general Data Validation and Certification
   Server (DVCS) and the protocols to be used when communicating with
   it.  The Data Validation and Certification Server is a Trusted Third
   Party (TTP) that can be used as one component in building reliable
   non-repudiation services.

   Useful Data Validation and Certification Server responsibilities in a
   PKI are to assert the validity of signed documents, public key
   certificates, and the possession or existence of data.

   As a result of the validation, a DVCS generates a Data Validation
   Certificate (DVC).  The data validation certificate can be used for
   constructing evidence of non-repudiation relating to the validity and
   correctness of an entity's claim to possess data, the validity and
   revocation status of an entity's public key certificate and the 
   validity and correctness of a digitally signed document.

   The presence of a data validation certificate supports
   non-repudiation by providing evidence that a digitally signed
   document or public key certificate was valid at the time indicated in
   the DVC.

   A DVC validating a public key certificate can for example be used
   even after the public key certificate expires and its revocation
   information is no longer or not easily available.  Determining the
   validity of a DVC is assumed to be a simpler task, for example, if
   the population of DVCS is significantly smaller than the population
   of public key certificate owners.

   The production of a data validation certificate in response to a
   signed request for validation of a signed document or public key
   certificate also provides evidence that due diligence was performed
   by the requester in validating a digital signature or public key
   certificate.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2R0Rul24004 for ietf-pkix-bks; Tue, 26 Mar 2002 16:27:56 -0800 (PST)
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 g2R0Rsm24000 for <[e-mail]>; Tue, 26 Mar 2002 16:27:54 -0800 (PST)
Received: from tsg1 ([12.81.64.19]) by mtiwmhc21.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020327002748.LOLT24238.mtiwmhc21.worldnet.att.net@tsg1>; Wed, 27 Mar 2002 00:27:48 +0000
Message-ID: <001301c1d526$21093690$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Carlisle Adams" <[e-mail]>, "'Denis Pinkas'" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: IP issues re Timestamp Patents.
Date: Tue, 26 Mar 2002 16:24:01 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C1D4E2.A371B4C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_000C_01C1D4E2.A371B4C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: IP issues re Timestamp Patents.OK Carlisle, your response below to =
the question was to a different question. The totality of the question =
was  are any timestamping patents out there that are waiting to explode, =
and the answer is yes there are.=20

You answered the original question with a piece of pertinent =
timestamping history regarding the litigation that you folks fought and =
won against Surety over their claim to own every form of digitally =
signing time data. And that was not the subject of the question.

This question was is there a protocol that could be patented or a patent =
process in place such that it would effect the use of the RFC3161 =
technologies. And the answer is yes. If you need to know the details =
then contact me offline for more details.


Todd
  From: Carlisle Adams=20
  To: 'Denis Pinkas' ; 'todd glassey'=20
  Cc: [e-mail]=20
  Sent: Tuesday, March 26, 2002 2:57 PM
  Subject: RE: IP issues re Timestamp Patents.


  Hi Todd,=20

  I'm not sure what you mean by "This is not completely true."  All the =
text says is that "a federal jury ... held that the claims of the '954 =
Patent covering hash-and-sign timestamping were not new".  It says =
nothing about the other claims of this patent, and nothing about other =
patents.  So, which part is "not completely true"?

  Carlisle.=20



    ----------=20
    From:   todd glassey[SMTP:[e-mail]]=20
    Sent:   Tuesday, March 26, 2002 5:43 PM=20
    To:     Carlisle Adams; 'Denis Pinkas'=20
    Cc:     [e-mail]=20
    Subject:        Re: IP issues re Timestamp Patents.=20

    This is not completely true.  The other claims of the Surety Patent =
were not struck down as were a number of other timebase management and =
control patents that still exist.=20

    For instance is a patent called "Controlling Access to Stored =
Information"  and is listed as EP 997-808 (5-mar-2000). It uses time and =
positioning  information in concert and alone to provide a keying and a =
control system for evidentiary use and that of access control as well.

    =20
    Todd Glassey=20

      ----- Original Message -----=20
      From: Carlisle Adams=20
      To: 'Denis Pinkas'=20
      Cc: [e-mail]=20
      Sent: Tuesday, March 26, 2002 1:23 PM=20
      Subject: RE: WG Last Call: Roadmap=20



      Hello,=20

              ----------=20
      From:   Denis Pinkas[SMTP:[e-mail]]=20
      Sent:   Tuesday, March 26, 2002 12:11 PM=20
      To:     [e-mail]=20
      Cc:     Carlisle Adams=20
      Subject:        Re: WG Last Call: Roadmap=20

              Comments on the roadmap document =
draft-ietf-pkix-roadmap-07.txt=20
       =20

      (...some comments deleted...)=20

              COMMENT 10. On page 28. The story about patents on TSP is =
currently=20
      described as follows:=20

                 "At the Minneapolis IETF meeting, it was disclosed that =
the materials=20
         covered in [TSP] draft may be covered by patent(s). Use of the=20
         material covered by the patent(s) in question has not be =
granted by=20
         the patent holder. Thus, anyone interested in implementing the =
PKIX=20
         [TSP] draft must be aware of this intellectual property issue. =
"=20

              Which IETF meeting in Minneapolis, since we have had three =
meetings in that=20
      location ? Anyway, the description does not capture what happened =
with=20
      Surety and Entrust. During the last IETF 2002 meeting in =
Minneapolis, I have=20
      asked Carlisle to provide a text replacement.=20



      The following text is from a press release issued by Entrust on =
November 9, 1999.  This text may be incorporated into the Roadmap =
document, if people agree with Denis that the current text is =
inadequate.

      Carlisle.=20



      8<---------------------------=20

      In February of 1999, a lawsuit was filed by Surety Technologies, =
Inc., in which Surety alleged that the Entrust, Inc., digital =
timestamping product, Entrust/Timestamp(tm), infringed U.S. Patent Re =
34,954 (the "'954 Patent", a re-issue of U.S. Patent 5,136,647).

      Entrust's product uses a common technique for digital timestamping =
called the hash-and-sign method.=20

      In a verdict returned on November 3, 1999, a federal jury in the =
United States District Court for the Eastern District of Virginia held =
that the claims of the '954 Patent covering hash-and-sign timestamping =
were not new at the time of the purported invention, and further, were =
longstanding as the obvious way to digitally timestamp an electronic =
document.

      With this ruling, the use of hash-and-sign timestamping is now =
open to anyone wishing to implement this technology in products or =
services in the United States.




------=_NextPart_000_000C_01C1D4E2.A371B4C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: IP issues re Timestamp Patents.</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2713.1100" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>OK Carlisle, your response below to the =
question=20
was to a different question. The totality of the question was&nbsp; are =
any=20
timestamping patents out there that are waiting to explode, and the =
answer is=20
yes there are. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>You answered the original question with =
a piece of=20
pertinent timestamping history regarding the litigation that you folks =
fought=20
and won against Surety over their claim to own every form of digitally =
signing=20
time data. And that was not the subject of the question.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>This question was is there a protocol =
that could be=20
patented or a patent process in place such that it would effect the use =
of the=20
RFC3161 technologies. And the answer is yes. If you need to know the =
details=20
then contact me offline for more details.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Todd</FONT><FONT face=3DArial =
size=3D2></FONT></DIV>
<BLOCKQUOTE=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]">Carlisle Adams</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">'Denis Pinkas'</A> ; <A=20
  title=[e-mail]=20
  href=3D"mailto:[e-mail]">'todd glassey'</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">[e-mail]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, March 26, 2002 =
2:57=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: IP issues re =
Timestamp=20
  Patents.</DIV>
  <DIV><BR></DIV>
  <P><FONT face=3D"Times New Roman" color=3D#0000ff size=3D2>Hi =
Todd,</FONT> </P>
  <P><FONT face=3D"Times New Roman" color=3D#0000ff size=3D2>I'm not =
sure what you=20
  mean by "This is not completely true."&nbsp; All the text says is that =
"a=20
  federal jury ... held that</FONT> <FONT face=3D"Times New Roman" =
color=3D#0000ff=20
  size=3D2>the claims of the '954 Patent covering hash-and-sign =
timestamping were=20
  not new</FONT><FONT face=3D"Times New Roman" color=3D#0000ff =
size=3D2>".&nbsp; It=20
  says nothing about the other claims of this patent, and nothing about =
other=20
  patents.&nbsp; So, which part is "not completely true"?</FONT></P>
  <P><FONT face=3D"Times New Roman" color=3D#0000ff =
size=3D2>Carlisle.</FONT> </P><BR>
  <UL>
    <P><FONT face=3D"MS Sans Serif" size=3D2>----------</FONT> =
<BR><B><FONT=20
    face=3D"MS Sans Serif" size=3D2>From:</FONT></B> &nbsp; <FONT=20
    face=3D"MS Sans Serif" size=3D2>todd=20
    glassey[SMTP:[e-mail]]</FONT> <BR><B><FONT=20
    face=3D"MS Sans Serif" size=3D2>Sent:</FONT></B> &nbsp; <FONT=20
    face=3D"MS Sans Serif" size=3D2>Tuesday, March 26, 2002 5:43 =
PM</FONT>=20
    <BR><B><FONT face=3D"MS Sans Serif" size=3D2>To:</FONT></B> =
&nbsp;&nbsp;&nbsp;=20
    <FONT face=3D"MS Sans Serif" size=3D2>Carlisle Adams; 'Denis =
Pinkas'</FONT>=20
    <BR><B><FONT face=3D"MS Sans Serif" size=3D2>Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp;=20
    <FONT face=3D"MS Sans Serif" size=3D2><A=20
    href=3D"mailto:[e-mail]">[e-mail]</A></FONT> =
<BR><B><FONT=20
    face=3D"MS Sans Serif" size=3D2>Subject:</FONT></B>=20
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=3D"MS Sans Serif" =
size=3D2>Re:=20
    IP issues re Timestamp Patents.</FONT> </P>
    <P><FONT face=3DArial size=3D2>This is not completely true.&nbsp; =
The other=20
    claims of the Surety Patent were not struck down as were a number of =
other=20
    timebase management and control patents that still exist.</FONT> =
</P>
    <P><FONT face=3DArial size=3D2>For instance&nbsp;is&nbsp;a patent =
called=20
    "Controlling Access to Stored Information"&nbsp; and is listed =
as&nbsp;EP=20
    997-808 (5-mar-2000). It uses time and positioning&nbsp; information =
in=20
    concert and alone to provide a keying and a control system for =
evidentiary=20
    use and that of access control as well.</FONT></P>
    <P><FONT face=3DArial size=3D2></FONT> <BR><FONT face=3DArial =
size=3D2>Todd=20
    Glassey</FONT> </P>
    <UL>
      <P><FONT face=3DArial>----- Original Message ----- =
</FONT><BR><B><FONT=20
      face=3DArial>From:</FONT></B><FONT face=3DArial></FONT><U> <FONT =
face=3DArial=20
      color=3D#0000ff>Carlisle Adams</FONT></U><FONT face=3DArial>=20
      </FONT><BR><B><FONT face=3DArial>To:</FONT></B><FONT =
face=3DArial></FONT><U>=20
      <FONT face=3DArial color=3D#0000ff>'Denis Pinkas'</FONT></U><FONT =
face=3DArial>=20
      </FONT><BR><B><FONT face=3DArial>Cc:</FONT></B><FONT =
face=3DArial></FONT><U>=20
      <FONT face=3DArial =
color=3D#0000ff>[e-mail]</FONT></U><FONT=20
      face=3DArial> </FONT><BR><B><FONT =
face=3DArial>Sent:</FONT></B><FONT=20
      face=3DArial> Tuesday, March 26, 2002 1:23 PM</FONT> <BR><B><FONT=20
      face=3DArial>Subject:</FONT></B><FONT face=3DArial> RE: WG Last =
Call:=20
      Roadmap</FONT> </P><BR>
      <P><FONT face=3D"Times New Roman" color=3D#0000ff =
size=3D2>Hello,</FONT><FONT=20
      face=3DArial> </FONT></P>
      <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=3D"MS =
Sans Serif"=20
      size=3D2>----------</FONT><FONT face=3DArial> </FONT><BR><B><FONT=20
      face=3D"MS Sans Serif" size=3D2>From:</FONT></B><FONT =
face=3DArial>=20
      &nbsp;</FONT> <FONT face=3D"MS Sans Serif" size=3D2>Denis=20
      Pinkas[SMTP:[e-mail]]</FONT><FONT face=3DArial>=20
      </FONT><BR><B><FONT face=3D"MS Sans Serif" =
size=3D2>Sent:</FONT></B><FONT=20
      face=3DArial> &nbsp;</FONT> <FONT face=3D"MS Sans Serif" =
size=3D2>Tuesday, March=20
      26, 2002 12:11 PM</FONT><FONT face=3DArial> </FONT><BR><B><FONT=20
      face=3D"MS Sans Serif" size=3D2>To:</FONT></B><FONT face=3DArial>=20
      &nbsp;&nbsp;&nbsp;</FONT><U> <FONT face=3D"MS Sans Serif" =
color=3D#0000ff=20
      size=3D2>[e-mail]</FONT></U><FONT face=3DArial> =
</FONT><BR><B><FONT=20
      face=3D"MS Sans Serif" size=3D2>Cc:</FONT></B><FONT face=3DArial>=20
      &nbsp;&nbsp;&nbsp;</FONT> <FONT face=3D"MS Sans Serif" =
size=3D2>Carlisle=20
      Adams</FONT><FONT face=3DArial> </FONT><BR><B><FONT face=3D"MS =
Sans Serif"=20
      size=3D2>Subject:</FONT></B><FONT face=3DArial>=20
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT> <FONT face=3D"MS Sans =
Serif"=20
      size=3D2>Re: WG Last Call: Roadmap</FONT><FONT face=3DArial> =
</FONT></P>
      <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=3DArial=20
      size=3D2>Comments on the roadmap document=20
      draft-ietf-pkix-roadmap-07.txt</FONT><FONT face=3DArial> =
</FONT><BR><FONT=20
      face=3DArial size=3D2>&nbsp;</FONT><FONT face=3DArial> </FONT></P>
      <P><FONT face=3D"Times New Roman" color=3D#0000ff =
size=3D2>(...some comments=20
      deleted...)</FONT><FONT face=3DArial> </FONT></P>
      <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=3DArial=20
      size=3D2>COMMENT 10. On page 28. The story about patents on TSP is =

      currently</FONT><FONT face=3DArial> </FONT><BR><FONT face=3DArial=20
      size=3D2>described as follows:</FONT><FONT face=3DArial> =
</FONT></P>
      <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=3DArial=20
      size=3D2>&nbsp;&nbsp; "At the Minneapolis IETF meeting, it was =
disclosed=20
      that the materials</FONT> <BR><FONT face=3DArial =
size=3D2>&nbsp;&nbsp; covered=20
      in [TSP] draft may be covered by patent(s). Use of the</FONT> =
<BR><FONT=20
      face=3DArial size=3D2>&nbsp;&nbsp; material covered by the =
patent(s) in=20
      question has not be granted by</FONT> <BR><FONT face=3DArial=20
      size=3D2>&nbsp;&nbsp; the patent holder. Thus, anyone interested =
in=20
      implementing the PKIX</FONT> <BR><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;=20
      [TSP] draft must be aware of this intellectual property issue.=20
      "</FONT><FONT face=3DArial> </FONT></P>
      <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=3DArial=20
      size=3D2>Which IETF meeting in Minneapolis, since we have had =
three meetings=20
      in that</FONT><FONT face=3DArial> </FONT><BR><FONT face=3DArial=20
      size=3D2>location ? Anyway, the description does not capture what =
happened=20
      with</FONT><FONT face=3DArial> </FONT><BR><FONT face=3DArial =
size=3D2>Surety and=20
      Entrust. During the last IETF 2002 meeting in Minneapolis, I=20
      have</FONT><FONT face=3DArial> </FONT><BR><FONT face=3DArial =
size=3D2>asked=20
      Carlisle to provide a text replacement.</FONT><FONT face=3DArial>=20
      </FONT></P><BR>
      <P><FONT face=3D"Times New Roman" color=3D#0000ff size=3D2>The =
following text is=20
      from a press release issued by Entrust on November 9, 1999.&nbsp; =
This=20
      text may be incorporated into the Roadmap document, if people =
agree with=20
      Denis that the current text is inadequate.</FONT></P>
      <P><FONT face=3D"Times New Roman" color=3D#0000ff =
size=3D2>Carlisle.</FONT><FONT=20
      face=3DArial> </FONT></P><BR>
      <P><FONT face=3D"Times New Roman" color=3D#0000ff=20
      size=3D2>8&lt;---------------------------</FONT><FONT =
face=3DArial>=20
</FONT></P>
      <P><FONT face=3D"Times New Roman" color=3D#0000ff size=3D2>In =
February of 1999,=20
      a lawsuit was filed by Surety Technologies, Inc., in which Surety =
alleged=20
      that the Entrust, Inc., digital timestamping product,=20
      Entrust/Timestamp(tm), infringed U.S. Patent Re 34,954 (the "'954 =
Patent",=20
      a re-issue of U.S. Patent 5,136,647).</FONT></P>
      <P><FONT face=3D"Times New Roman" color=3D#0000ff =
size=3D2>Entrust's product=20
      uses a common technique for digital timestamping called the =
hash-and-sign=20
      method.</FONT> </P>
      <P><FONT face=3D"Times New Roman" color=3D#0000ff size=3D2>In a =
verdict returned=20
      on November 3, 1999, a federal jury in the United States District =
Court=20
      for the Eastern District of Virginia held that the claims of the =
'954=20
      Patent covering hash-and-sign timestamping were not new at the =
time of the=20
      purported invention, and further, were longstanding as the obvious =
way to=20
      digitally timestamp an electronic document.</FONT></P>
      <P><FONT face=3D"Times New Roman" color=3D#0000ff size=3D2>With =
this ruling, the=20
      use of hash-and-sign timestamping is now open to anyone wishing to =

      implement this technology in products or services in the United=20
      States.</FONT></P><BR></UL></UL></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_000C_01C1D4E2.A371B4C0--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2QNWbm22717 for ietf-pkix-bks; Tue, 26 Mar 2002 15:32:37 -0800 (PST)
Received: from tweety (pool-151-200-26-46.res.east.verizon.net [151.200.26.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2QNWYm22712 for <[e-mail]>; Tue, 26 Mar 2002 15:32:34 -0800 (PST)
Received: from [192.168.0.12] by tweety (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Tue, 26 Mar 2002 18:32:05 -0500
Message-ID: <[e-mail]>
Date: Tue, 26 Mar 2002 18:32:04 -0500
From: "Sean P. Turner" <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: [e-mail]
Subject: Re: WG Last Call: Roadmap
References: <[e-mail]> <[e-mail]> <[e-mail]> <[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>

Denis,

All of your comments are accepted unaltered.  BTW - it was the IETF44 where the TSP
IP issues were addressed (according to the minutes).

spt

Denis Pinkas wrote:

> Comments on the roadmap document draft-ietf-pkix-roadmap-07.txt
>
> > This message initiates a two week Working Group Last Call for "Internet X.509
> > Public Key Infrastructure: Roadmap". The document is available at
>
> >      http://www.ietf.org/internet-drafts/draft-ietf-pkix-roadmap-07.txt
>
> > Assuming successful completion of Last Call, the document will be forwarded for
> > consideration as an Informational track RFC.
>
> First of all. It is a very good and useful document. Nevertheless, a few
> comments.
>
> COMMENT 1. On page 1:
>
> "This draft is being discussed on the 'ietf-smime' mailing list.
> To subscribe, send a message to [e-mail] with
> the single word subscribe in the body of the message."
>
> Now I understand why we got no comment on the PKIX mailing list.
> All comments have certainly been addressed to the SMIME mailing list !!!
>
> :-)
>
> COMMENT 2. Replace "at" by "prior" in expressions referring to Time-Stamping
> in two sentences: "at an instant in time" (page 5) and "at a given time"
> (page 7).
>
> COMMENT 3. A sentence states: "However, to minimize confusion in this
> document, we elect to call this node a "Top CA," and reserve "Root CA" for
> the CA directly trusted by the EE". Since an EE may trust more than one Top
> CA, shouldn't we say:
>
> "However, to minimize confusion in this document, we elect to call this node
> a "Top CA," and reserve "Root CA" when there is a single CA directly trusted
> by the EE."
>
> COMMENT 4. On page 14. A clarification needs to be done between
> cross-certificates and CA certificates. The text currently states:
>
>    A cross-certificate is a PKC issued by one CA to another CA which
>    contains a public CA key associated with the private CA signature key
>    used for issuing PKCs. Typically, a cross-certificate is used to
>    allow client systems or end entities in one administrative domain to
>    communicate securely with client systems or end users in another
>    administrative domain. Use of a cross-certificate issued from CA_1 to
>    CA_2 allows user Alice, who trusts CA_1, to accept a PKC used by Bob,
>    which was issued by CA_2. Cross-certificates can also be issued from
>    one CA to another CA in the same administrative domain, if required.
>
> I would propose instead the following:
>
> " A CA certificate is a certificate in a hierarchy that is neither a
> self-signed certificate, nor an end-entity certificate. [2459bis] does not
> make a difference between a CA certificate and a cross certificate since it
> defines a cross-certificate as "a certificate issued by one CA to another
> CA". Some people in the WG believe that a cross certificate is a special
> kind of CA certificate. A cross certificate is issued by a CA under one
> Top CA for another CA under a different Top CA. CAs in the same hierarchy
> have part of their names imposed by the Top CA or by the CAs under that
> Top CAS. When a cross certificate is issued, there is no relationship
> between the names of the CAS.
>
> Typically, a cross-certificate is used to allow client systems or end
> entities in one administrative domain to communicate securely with client
> systems or end users in another administrative domain. Use of a
> cross-certificate issued from CA_1 to CA_2 allows user Alice, who trusts
> CA_1, to accept a PKC used by Bob, which was issued by CA_2.
> Cross-certificates can also be issued from one CA to another CA in the same
> administrative domain, if required."
>
> COMMENT 5. On page 15, the text states: "A CRL is a time stamped list
> identifying revoked PKCs that is signed by a CA and made freely available
> in a public repository."
>
> I would prefer to avoid to use "time-stamped" in that context and thus I
> would propose the following wording:
>
> "A CRL is a list that identifies the references of revoked PKCs. This list
> contains a date of issue and is signed by a CA and made freely available in
> a public repository."
>
> COMMENT 6. On page 22. Correct a typo. Change "ôRepresentation" by
> "Representation".
>
> COMMENT 7. On page 22. Correct a typo. Change "Certificates.ö" by
> "Certificates."
>
> COMMENT 8. On page 22. Correct a typo. Change "fro" by "from"
>
> COMMENT 9. On page 22. Due to a very recent change of scope of the PI
> document replace "individual" by "entity".
>
> This leads to the following:
>
>      This document defines a new form of name, the
>      permanent identifier, which is a name assigned by an organization,
>      unique within that organization, that singles out a particular
>      entity from all other entities. The permanent identifier is
>      an optional feature that may be used by a CA to indicate that the
>      certificate relates to the same entity even if the name or the
>      affiliation of that entity has changed. The permanent
>      identifier is important in the context of access control and of
>      non-repudiation.
>
> COMMENT 10. On page 28. The story about patents on TSP is currently
> described as follows:
>
>    "At the Minneapolis IETF meeting, it was disclosed that the materials
>    covered in [TSP] draft may be covered by patent(s). Use of the
>    material covered by the patent(s) in question has not be granted by
>    the patent holder. Thus, anyone interested in implementing the PKIX
>    [TSP] draft must be aware of this intellectual property issue. "
>
>
> Which IETF meeting in Minneapolis, since we have had three meetings in that
> location ? Anyway, the description does not capture what happened with
> Surety and Entrust. During the last IETF 2002 meeting in Minneapolis, I have
> asked Carlisle to provide a text replacement.
>
> COMMENT 11. On page 47. Section 5.5 talks about trust model, but only
> consider a single trust point:
>
> "  An important design decision is where a particular EE's trust point
>    is located (i.e., where is the EE's Root CA). There are a number of
>    models that have been developed and depending on the environment some
>    models may be more suited than others. The following provides some
>    background on the models."
>
> I would rather propose to change it into:
>
> " An important design decision is, for a given application, where the
> particular EE's trust points are located (i.e. what are the Top CAs).
> There are a number of models that have been developed and depending on
> the environment some models may be more suited than others. The following
> provides some background on the models."
>
> COMMENT 12. On page 49. Section 5.5 I would propose to add another model.
>
> 5.5.5 Validation policies
>
> Another model considers a set of rules that apply to an application context.
> Every application context may have a different set of rules. When choosing
> to use certificates in the context of that application, the EE selects the
> set of rules for that context. In a set of rules, one or more Top CAs may be
> trusted, each one may be associated with different constraints, like the
> certificate policies that are trusted or the naming constraints that apply.
> These constrains may be specified either in self-signed certificates or in
> addition to self-signed certificates when they do not incorporate these
> constraints. This set of rules is called a validation policy (when
> validating a certificate) or a signature policy (when validating a digital
> signature).
>
> Regards,
>
> Denis




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2QMvNr21717 for ietf-pkix-bks; Tue, 26 Mar 2002 14:57:23 -0800 (PST)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2QMvMm21713 for <[e-mail]>; Tue, 26 Mar 2002 14:57:22 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <HWJM4N08>; Tue, 26 Mar 2002 17:57:19 -0500
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, "'todd glassey'" <[e-mail]>
Cc: [e-mail]
Subject: RE: IP issues re Timestamp Patents.
Date: Tue, 26 Mar 2002 17:57:18 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D519.94B800B0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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_01C1D519.94B800B0
Content-Type: text/plain

Hi Todd,

I'm not sure what you mean by "This is not completely true."  All the text
says is that "a federal jury ... held that the claims of the '954 Patent
covering hash-and-sign timestamping were not new".  It says nothing about
the other claims of this patent, and nothing about other patents.  So, which
part is "not completely true"?

Carlisle.


> ----------
> From: 	todd glassey[SMTP:[e-mail]]
> Sent: 	Tuesday, March 26, 2002 5:43 PM
> To: 	Carlisle Adams; 'Denis Pinkas'
> Cc: 	[e-mail]
> Subject: 	Re: IP issues re Timestamp Patents.
> 
> This is not completely true.  The other claims of the Surety Patent were
> not struck down as were a number of other timebase management and control
> patents that still exist. 
> 
> For instance is a patent called "Controlling Access to Stored Information"
> and is listed as EP 997-808 (5-mar-2000). It uses time and positioning
> information in concert and alone to provide a keying and a control system
> for evidentiary use and that of access control as well.
>  
> Todd Glassey
> 
> 	----- Original Message ----- 
> 	From: Carlisle Adams 
> 	To: 'Denis Pinkas' 
> 	Cc: [e-mail] 
> 	Sent: Tuesday, March 26, 2002 1:23 PM
> 	Subject: RE: WG Last Call: Roadmap
> 
> 
> 	Hello, 
> 
> 		---------- 
> 	From:   Denis Pinkas[SMTP:[e-mail]] 
> 	Sent:   Tuesday, March 26, 2002 12:11 PM 
> 	To:     [e-mail] 
> 	Cc:     Carlisle Adams 
> 	Subject:        Re: WG Last Call: Roadmap 
> 
> 		Comments on the roadmap document
> draft-ietf-pkix-roadmap-07.txt 
> 	  
> 
> 	(...some comments deleted...) 
> 
> 		COMMENT 10. On page 28. The story about patents on TSP is
> currently 
> 	described as follows: 
> 
> 		   "At the Minneapolis IETF meeting, it was disclosed that
> the materials 
> 	   covered in [TSP] draft may be covered by patent(s). Use of the 
> 	   material covered by the patent(s) in question has not be granted
> by 
> 	   the patent holder. Thus, anyone interested in implementing the
> PKIX 
> 	   [TSP] draft must be aware of this intellectual property issue. " 
> 
> 		Which IETF meeting in Minneapolis, since we have had three
> meetings in that 
> 	location ? Anyway, the description does not capture what happened
> with 
> 	Surety and Entrust. During the last IETF 2002 meeting in
> Minneapolis, I have 
> 	asked Carlisle to provide a text replacement. 
> 
> 
> 	The following text is from a press release issued by Entrust on
> November 9, 1999.  This text may be incorporated into the Roadmap
> document, if people agree with Denis that the current text is inadequate.
> 
> 	Carlisle. 
> 
> 
> 	8<--------------------------- 
> 
> 	In February of 1999, a lawsuit was filed by Surety Technologies,
> Inc., in which Surety alleged that the Entrust, Inc., digital timestamping
> product, Entrust/Timestamp(tm), infringed U.S. Patent Re 34,954 (the "'954
> Patent", a re-issue of U.S. Patent 5,136,647).
> 
> 	Entrust's product uses a common technique for digital timestamping
> called the hash-and-sign method. 
> 
> 	In a verdict returned on November 3, 1999, a federal jury in the
> United States District Court for the Eastern District of Virginia held
> that the claims of the '954 Patent covering hash-and-sign timestamping
> were not new at the time of the purported invention, and further, were
> longstanding as the obvious way to digitally timestamp an electronic
> document.
> 
> 	With this ruling, the use of hash-and-sign timestamping is now open
> to anyone wishing to implement this technology in products or services in
> the United States.
> 
> 

------_=_NextPart_001_01C1D519.94B800B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: IP issues re Timestamp Patents.</TITLE>
</HEAD>
<BODY>

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

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">I'm not =
sure what you mean by &quot;This is not completely true.&quot;&nbsp; =
All the text says is that &quot;a federal jury ... held that</FONT> =
<FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">the claims of =
the '954 Patent covering hash-and-sign timestamping were not =
new</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&quot;.&nbsp; It says nothing about the other claims of this =
patent, and nothing about other patents.&nbsp; So, which part is =
&quot;not completely true&quot;?</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">todd =
glassey[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, March 26, 2002 5:43 =
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">Carlisle =
Adams; 'Denis Pinkas'</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</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: IP issues re Timestamp Patents.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">This is not completely true.=A0 The =
other claims of the Surety Patent were not struck down as were a number =
of other timebase management and control patents that still =
exist.</FONT> </P>

<P><FONT SIZE=3D2 FACE=3D"Arial">For instance=A0is=A0a patent called =
&quot;Controlling Access to Stored Information&quot;=A0 and is listed =
as=A0EP 997-808 (5-mar-2000). It uses time and positioning=A0 =
information in concert and alone to provide a keying and a control =
system for evidentiary use and that of access control as =
well.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">=A0</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Todd Glassey</FONT>
</P>
<UL>
<P><FONT FACE=3D"Arial">----- Original Message ----- </FONT>
<BR><B><FONT FACE=3D"Arial">From:</FONT></B><FONT =
FACE=3D"Arial"></FONT><U> <FONT COLOR=3D"#0000FF" =
FACE=3D"Arial">Carlisle Adams</FONT></U><FONT FACE=3D"Arial"> </FONT>
<BR><B><FONT FACE=3D"Arial">To:</FONT></B><FONT =
FACE=3D"Arial"></FONT><U> <FONT COLOR=3D"#0000FF" FACE=3D"Arial">'Denis =
Pinkas'</FONT></U><FONT FACE=3D"Arial"> </FONT>
<BR><B><FONT FACE=3D"Arial">Cc:</FONT></B><FONT =
FACE=3D"Arial"></FONT><U> <FONT COLOR=3D"#0000FF" =
FACE=3D"Arial">[e-mail]</FONT></U><FONT FACE=3D"Arial"> =
</FONT>
<BR><B><FONT FACE=3D"Arial">Sent:</FONT></B><FONT FACE=3D"Arial"> =
Tuesday, March 26, 2002 1:23 PM</FONT>
<BR><B><FONT FACE=3D"Arial">Subject:</FONT></B><FONT FACE=3D"Arial"> =
RE: WG Last Call: Roadmap</FONT>
</P>
<BR>

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

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS =
Sans Serif">----------</FONT><FONT FACE=3D"Arial"> </FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B><FONT =
FACE=3D"Arial"> =A0</FONT> <FONT SIZE=3D2 FACE=3D"MS Sans Serif">Denis =
Pinkas[SMTP:[e-mail]]</FONT><FONT FACE=3D"Arial"> </FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B><FONT =
FACE=3D"Arial"> =A0</FONT> <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">Tuesday, March 26, 2002 12:11 PM</FONT><FONT FACE=3D"Arial"> =
</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B><FONT =
FACE=3D"Arial"> =A0=A0=A0</FONT><U> <FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"MS Sans Serif">[e-mail]</FONT></U><FONT =
FACE=3D"Arial"> </FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B><FONT =
FACE=3D"Arial"> =A0=A0=A0</FONT> <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">Carlisle Adams</FONT><FONT FACE=3D"Arial"> </FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B><FONT =
FACE=3D"Arial"> =A0=A0=A0=A0=A0=A0</FONT> <FONT SIZE=3D2 FACE=3D"MS =
Sans Serif">Re: WG Last Call: Roadmap</FONT><FONT FACE=3D"Arial"> =
</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Comments on the roadmap document =
draft-ietf-pkix-roadmap-07.txt</FONT><FONT FACE=3D"Arial"> </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">=A0</FONT><FONT FACE=3D"Arial"> =
</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">(...some =
comments deleted...)</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">COMMENT 10. On page 28. The story about patents on TSP =
is currently</FONT><FONT FACE=3D"Arial"> </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">described as follows:</FONT><FONT =
FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">=A0=A0 &quot;At the Minneapolis IETF meeting, it was =
disclosed that the materials</FONT>=20
<BR><FONT SIZE=3D2 FACE=3D"Arial">=A0=A0 covered in [TSP] draft may be =
covered by patent(s). Use of the</FONT>=20
<BR><FONT SIZE=3D2 FACE=3D"Arial">=A0=A0 material covered by the =
patent(s) in question has not be granted by</FONT>=20
<BR><FONT SIZE=3D2 FACE=3D"Arial">=A0=A0 the patent holder. Thus, =
anyone interested in implementing the PKIX</FONT>=20
<BR><FONT SIZE=3D2 FACE=3D"Arial">=A0=A0 [TSP] draft must be aware of =
this intellectual property issue. &quot;</FONT><FONT FACE=3D"Arial"> =
</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Which IETF meeting in Minneapolis, since we have had =
three meetings in that</FONT><FONT FACE=3D"Arial"> </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">location ? Anyway, the description =
does not capture what happened with</FONT><FONT FACE=3D"Arial"> </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Surety and Entrust. During the last =
IETF 2002 meeting in Minneapolis, I have</FONT><FONT FACE=3D"Arial"> =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">asked Carlisle to provide a text =
replacement.</FONT><FONT FACE=3D"Arial"> </FONT>
</P>
<BR>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">The =
following text is from a press release issued by Entrust on November 9, =
1999.=A0 This text may be incorporated into the Roadmap document, if =
people agree with Denis that the current text is inadequate.</FONT></P>

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

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">8&lt;---------------------------</FONT><FONT FACE=3D"Arial"> =
</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">In =
February of 1999, a lawsuit was filed by Surety Technologies, Inc., in =
which Surety alleged that the Entrust, Inc., digital timestamping =
product, Entrust/Timestamp(tm), infringed U.S. Patent Re 34,954 (the =
&quot;'954 Patent&quot;, a re-issue of U.S. Patent =
5,136,647).</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Entrust's =
product uses a common technique for digital timestamping called the =
hash-and-sign method.</FONT>=20
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">In a =
verdict returned on November 3, 1999, a federal jury in the United =
States District Court for the Eastern District of Virginia held that =
the claims of the '954 Patent covering hash-and-sign timestamping were =
not new at the time of the purported invention, and further, were =
longstanding as the obvious way to digitally timestamp an electronic =
document.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">With this =
ruling, the use of hash-and-sign timestamping is now open to anyone =
wishing to implement this technology in products or services in the =
United States.</FONT></P>
<BR>
</UL></UL>
</BODY>
</HTML>
------_=_NextPart_001_01C1D519.94B800B0--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2QMisd21394 for ietf-pkix-bks; Tue, 26 Mar 2002 14:44:54 -0800 (PST)
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 g2QMiqm21390 for <[e-mail]>; Tue, 26 Mar 2002 14:44:52 -0800 (PST)
Received: from tsg1 ([12.81.78.2]) by mtiwmhc21.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020326224437.IDOE24238.mtiwmhc21.worldnet.att.net@tsg1>; Tue, 26 Mar 2002 22:44:37 +0000
Message-ID: <030a01c1d517$b6fb9670$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Carlisle Adams" <[e-mail]>, "'Denis Pinkas'" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: IP issues re Timestamp Patents.
Date: Tue, 26 Mar 2002 14:43:55 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0307_01C1D4D4.A7DABC90"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0307_01C1D4D4.A7DABC90
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: WG Last Call: RoadmapThis is not completely true.  The other claims =
of the Surety Patent were not struck down as were a number of other =
timebase management and control patents that still exist.=20

For instance is a patent called "Controlling Access to Stored =
Information"  and is listed as EP 997-808 (5-mar-2000). It uses time and =
positioning  information in concert and alone to provide a keying and a =
control system for evidentiary use and that of access control as well.

Todd Glassey
  ----- Original Message -----=20
  From: Carlisle Adams=20
  To: 'Denis Pinkas'=20
  Cc: [e-mail]=20
  Sent: Tuesday, March 26, 2002 1:23 PM
  Subject: RE: WG Last Call: Roadmap


  Hello,=20

    ----------=20
    From:   Denis Pinkas[SMTP:[e-mail]]=20
    Sent:   Tuesday, March 26, 2002 12:11 PM=20
    To:     [e-mail]=20
    Cc:     Carlisle Adams=20
    Subject:        Re: WG Last Call: Roadmap=20

    Comments on the roadmap document draft-ietf-pkix-roadmap-07.txt=20
     =20

  (...some comments deleted...)=20

    COMMENT 10. On page 28. The story about patents on TSP is currently=20
    described as follows:=20

       "At the Minneapolis IETF meeting, it was disclosed that the =
materials=20
       covered in [TSP] draft may be covered by patent(s). Use of the=20
       material covered by the patent(s) in question has not be granted =
by=20
       the patent holder. Thus, anyone interested in implementing the =
PKIX=20
       [TSP] draft must be aware of this intellectual property issue. "=20

    Which IETF meeting in Minneapolis, since we have had three meetings =
in that=20
    location ? Anyway, the description does not capture what happened =
with=20
    Surety and Entrust. During the last IETF 2002 meeting in =
Minneapolis, I have=20
    asked Carlisle to provide a text replacement.=20

  =20
  The following text is from a press release issued by Entrust on =
November 9, 1999.  This text may be incorporated into the Roadmap =
document, if people agree with Denis that the current text is =
inadequate.

  Carlisle.=20



  8<---------------------------=20

  In February of 1999, a lawsuit was filed by Surety Technologies, Inc., =
in which Surety alleged that the Entrust, Inc., digital timestamping =
product, Entrust/Timestamp(tm), infringed U.S. Patent Re 34,954 (the =
"'954 Patent", a re-issue of U.S. Patent 5,136,647).

  Entrust's product uses a common technique for digital timestamping =
called the hash-and-sign method.=20

  In a verdict returned on November 3, 1999, a federal jury in the =
United States District Court for the Eastern District of Virginia held =
that the claims of the '954 Patent covering hash-and-sign timestamping =
were not new at the time of the purported invention, and further, were =
longstanding as the obvious way to digitally timestamp an electronic =
document.

  With this ruling, the use of hash-and-sign timestamping is now open to =
anyone wishing to implement this technology in products or services in =
the United States.


------=_NextPart_000_0307_01C1D4D4.A7DABC90
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: WG Last Call: Roadmap</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2713.1100" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>This is not completely true.&nbsp; The =
other claims=20
of the Surety Patent were not struck down as were a number of other =
timebase=20
management and control patents that still exist. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2><BR>For instance&nbsp;is&nbsp;a patent =
called=20
"Controlling Access to Stored Information"&nbsp; and is listed =
as&nbsp;EP=20
997-808 (5-mar-2000). It uses time and positioning&nbsp; information in =
concert=20
and alone to provide a keying and a control system for evidentiary use =
and that=20
of access control as well.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Todd Glassey</FONT></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 style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <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]">Carlisle Adams</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">'Denis Pinkas'</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">[e-mail]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, March 26, 2002 =
1:23=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: WG Last Call: =
Roadmap</DIV>
  <DIV><BR></DIV>
  <P><FONT face=3D"Times New Roman" color=3D#0000ff =
size=3D2>Hello,</FONT> </P>
  <UL>
    <P><FONT face=3D"MS Sans Serif" size=3D2>----------</FONT> =
<BR><B><FONT=20
    face=3D"MS Sans Serif" size=3D2>From:</FONT></B> &nbsp; <FONT=20
    face=3D"MS Sans Serif" size=3D2>Denis =
Pinkas[SMTP:[e-mail]]</FONT>=20
    <BR><B><FONT face=3D"MS Sans Serif" size=3D2>Sent:</FONT></B> &nbsp; =
<FONT=20
    face=3D"MS Sans Serif" size=3D2>Tuesday, March 26, 2002 12:11 =
PM</FONT>=20
    <BR><B><FONT face=3D"MS Sans Serif" size=3D2>To:</FONT></B> =
&nbsp;&nbsp;&nbsp;=20
    <FONT face=3D"MS Sans Serif" size=3D2><A=20
    href=3D"mailto:[e-mail]">[e-mail]</A></FONT> =
<BR><B><FONT=20
    face=3D"MS Sans Serif" size=3D2>Cc:</FONT></B> &nbsp;&nbsp;&nbsp; =
<FONT=20
    face=3D"MS Sans Serif" size=3D2>Carlisle Adams</FONT> <BR><B><FONT=20
    face=3D"MS Sans Serif" size=3D2>Subject:</FONT></B>=20
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=3D"MS Sans Serif" =
size=3D2>Re:=20
    WG Last Call: Roadmap</FONT> </P>
    <P><FONT face=3DArial size=3D2>Comments on the roadmap document=20
    draft-ietf-pkix-roadmap-07.txt</FONT> <BR><FONT face=3DArial=20
    size=3D2>&nbsp;</FONT> </P></UL>
  <P><FONT face=3D"Times New Roman" color=3D#0000ff size=3D2>(...some =
comments=20
  deleted...)</FONT> </P>
  <UL>
    <P><FONT face=3DArial size=3D2>COMMENT 10. On page 28. The story =
about patents=20
    on TSP is currently</FONT> <BR><FONT face=3DArial size=3D2>described =
as=20
    follows:</FONT> </P>
    <P><FONT face=3DArial size=3D2>&nbsp;&nbsp; "At the Minneapolis IETF =
meeting, it=20
    was disclosed that the materials </FONT><BR><FONT face=3DArial=20
    size=3D2>&nbsp;&nbsp; covered in [TSP] draft may be covered by =
patent(s). Use=20
    of the </FONT><BR><FONT face=3DArial size=3D2>&nbsp;&nbsp; material =
covered by=20
    the patent(s) in question has not be granted by </FONT><BR><FONT =
face=3DArial=20
    size=3D2>&nbsp;&nbsp; the patent holder. Thus, anyone interested in=20
    implementing the PKIX </FONT><BR><FONT face=3DArial =
size=3D2>&nbsp;&nbsp; [TSP]=20
    draft must be aware of this intellectual property issue. "</FONT> =
</P>
    <P><FONT face=3DArial size=3D2>Which IETF meeting in Minneapolis, =
since we have=20
    had three meetings in that</FONT> <BR><FONT face=3DArial =
size=3D2>location ?=20
    Anyway, the description does not capture what happened with</FONT> =
<BR><FONT=20
    face=3DArial size=3D2>Surety and Entrust. During the last IETF 2002 =
meeting in=20
    Minneapolis, I have</FONT> <BR><FONT face=3DArial size=3D2>asked =
Carlisle to=20
    provide a text replacement.</FONT> </P></UL>
  <P><FONT face=3D"Times New Roman" color=3D#0000ff size=3D2></FONT> =
<BR><FONT=20
  face=3D"Times New Roman" color=3D#0000ff size=3D2>The following text =
is from a press=20
  release issued by Entrust on November 9, 1999.&nbsp; This text may be=20
  incorporated into the Roadmap document, if people agree with Denis =
that the=20
  current text is inadequate.</FONT></P>
  <P><FONT face=3D"Times New Roman" color=3D#0000ff =
size=3D2>Carlisle.</FONT> </P><BR>
  <P><FONT face=3D"Times New Roman" color=3D#0000ff=20
  size=3D2>8&lt;---------------------------</FONT> </P>
  <P><FONT face=3D"Times New Roman" color=3D#0000ff size=3D2>In February =
of 1999, a=20
  lawsuit was filed by Surety Technologies, Inc., in which Surety =
alleged that=20
  the Entrust, Inc., digital timestamping product, =
Entrust/Timestamp(tm),=20
  infringed U.S. Patent Re 34,954 (the "'954 Patent", a re-issue of U.S. =
Patent=20
  5,136,647).</FONT></P>
  <P><FONT face=3D"Times New Roman" color=3D#0000ff size=3D2>Entrust's =
product uses a=20
  common technique for digital timestamping called the hash-and-sign =
method.=20
  </FONT></P>
  <P><FONT face=3D"Times New Roman" color=3D#0000ff size=3D2>In a =
verdict returned on=20
  November 3, 1999, a federal jury in the United States District Court =
for the=20
  Eastern District of Virginia held that the claims of the '954 Patent =
covering=20
  hash-and-sign timestamping were not new at the time of the purported=20
  invention, and further, were longstanding as the obvious way to =
digitally=20
  timestamp an electronic document.</FONT></P>
  <P><FONT face=3D"Times New Roman" color=3D#0000ff size=3D2>With this =
ruling, the use=20
  of hash-and-sign timestamping is now open to anyone wishing to =
implement this=20
  technology in products or services in the United=20
States.</FONT></P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0307_01C1D4D4.A7DABC90--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2QLTRX18698 for ietf-pkix-bks; Tue, 26 Mar 2002 13:29:27 -0800 (PST)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2QLTQ418692 for <[e-mail]>; Tue, 26 Mar 2002 13:29:26 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Tue, 26 Mar 2002 13:27:48 -0800 (PST)
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, 26 Mar 2002 13:27:47 -0800 (PST)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <HP2ZAZRM>; Tue, 26 Mar 2002 13:29:22 -0800
Content-return: allowed
Date: Tue, 26 Mar 2002 13:29:17 -0800
From: Peter Williams <[e-mail]>
Subject: RE: OpenEvidence
To: "'Peter Sylvester'" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Out of interest, is the EC paying for an open source
implementation of the part that enables centralized key 
escrow/management of key encryption certificates via the DVCS 
cert validation service? I think this is a cool idea,
personally. I dont want key escrow policy enforced via certs,
but enforcement via cert validation is fine; this is a lovely
example of the power of TTP-based validation policys
to assert a non-CA-based control model.

Could you forward the legal conditions (controlling use of the 
"open source") agreed with the Commission concerning how 
others may use the results of the funding, as produced by 
the consortium members?

I love the fact that IESG issues an RFC for a validation
service/policy that essentially enables a non-CA "online"
TTP to essentially issue and distribute key encryption certs
(as a side-effect of generating NR-grade validation evidence)
where such certs are just one example of a DVCS being
used to distribute a control-attribute. That this
is clearly backed by two mainline vendors (Entrust and Baltimore)
give alot of credibility to the basis of using online validation
services as the infastructure for executing authorization-based control 
policies.

This design may have little or no relevance in the US 
government-influenced circles (or anyone else who has built a 
pure, cert/CRL-based infrastructure) but this design could well suit 
the multi-national needs of European e-government where the 
are a multitude of overlapping transaction controls, for a 
myriad of different regulated businesses. Much of the
Identrus-experience in operating a first generation large-scale
validation infrastructure can probably be brought into play, to
augment the baseline DVCS, which is missing some scalability 
features.

Well Done!

-----Original Message-----
From: Peter Sylvester [mailto:[e-mail]]
Sent: Tuesday, March 26, 2002 9:38 AM
To: [e-mail]
Cc: [e-mail]
Subject: OpenEvidence



Hello,

I am happy to inform you that he EU-Commission has signed
the contrat for the project OPEN-EVIDENCE today.

As some might already know, part of the deliverables 
are open source implementations of RFCs 3029 and 3061.

The partners are: C&A Italy, Cybernetica Estonia, 
EdelWeb France and Speos Belgium.

The official project begin is April 1st 2002. ;-)

Stay tuned.  

Regards
Peter Sylvester -- EdelWeb


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2QLOCA18255 for ietf-pkix-bks; Tue, 26 Mar 2002 13:24:12 -0800 (PST)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2QLOB418251 for <[e-mail]>; Tue, 26 Mar 2002 13:24:11 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <HWJM4LR7>; Tue, 26 Mar 2002 16:23:58 -0500
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>
Cc: [e-mail]
Subject: RE: WG Last Call: Roadmap
Date: Tue, 26 Mar 2002 16:23:57 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D50C.89D3AF80"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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_01C1D50C.89D3AF80
Content-Type: text/plain;
	charset="iso-8859-1"

Hello,

> ----------
> From: 	Denis Pinkas[SMTP:[e-mail]]
> Sent: 	Tuesday, March 26, 2002 12:11 PM
> To: 	[e-mail]
> Cc: 	Carlisle Adams
> Subject: 	Re: WG Last Call: Roadmap
> 
> Comments on the roadmap document draft-ietf-pkix-roadmap-07.txt
>  
(...some comments deleted...)

> COMMENT 10. On page 28. The story about patents on TSP is currently
> described as follows:
> 
>    "At the Minneapolis IETF meeting, it was disclosed that the materials 
>    covered in [TSP] draft may be covered by patent(s). Use of the 
>    material covered by the patent(s) in question has not be granted by 
>    the patent holder. Thus, anyone interested in implementing the PKIX 
>    [TSP] draft must be aware of this intellectual property issue. "
> 
> Which IETF meeting in Minneapolis, since we have had three meetings in
> that
> location ? Anyway, the description does not capture what happened with
> Surety and Entrust. During the last IETF 2002 meeting in Minneapolis, I
> have
> asked Carlisle to provide a text replacement.
 
The following text is from a press release issued by Entrust on November 9,
1999.  This text may be incorporated into the Roadmap document, if people
agree with Denis that the current text is inadequate.

Carlisle.


8<---------------------------

In February of 1999, a lawsuit was filed by Surety Technologies, Inc., in
which Surety alleged that the Entrust, Inc., digital timestamping product,
Entrust/Timestamp(tm), infringed U.S. Patent Re 34,954 (the "'954 Patent", a
re-issue of U.S. Patent 5,136,647).

Entrust's product uses a common technique for digital timestamping called
the hash-and-sign method. 

In a verdict returned on November 3, 1999, a federal jury in the United
States District Court for the Eastern District of Virginia held that the
claims of the '954 Patent covering hash-and-sign timestamping were not new
at the time of the purported invention, and further, were longstanding as
the obvious way to digitally timestamp an electronic document.

With this ruling, the use of hash-and-sign timestamping is now open to
anyone wishing to implement this technology in products or services in the
United States.


------_=_NextPart_001_01C1D50C.89D3AF80
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: WG Last Call: Roadmap</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Hello,</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">Denis =
Pinkas[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, March 26, 2002 12:11 =
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]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans Serif">Carlisle =
Adams</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: WG Last Call: Roadmap</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Comments on the roadmap document =
draft-ietf-pkix-roadmap-07.txt</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">(...some =
comments deleted...)</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">COMMENT 10. On page 28. The story =
about patents on TSP is currently</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">described as follows:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; &quot;At the Minneapolis =
IETF meeting, it was disclosed that the materials </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; covered in [TSP] draft =
may be covered by patent(s). Use of the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; material covered by the =
patent(s) in question has not be granted by </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; the patent holder. Thus, =
anyone interested in implementing the PKIX </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; [TSP] draft must be =
aware of this intellectual property issue. &quot;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Which IETF meeting in Minneapolis, =
since we have had three meetings in that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">location ? Anyway, the description =
does not capture what happened with</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Surety and Entrust. During the last =
IETF 2002 meeting in Minneapolis, I have</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">asked Carlisle to provide a text =
replacement.</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">The =
following text is from a press release issued by Entrust on November 9, =
1999.&nbsp; This text may be incorporated into the Roadmap document, if =
people agree with Denis that the current text is inadequate.</FONT></P>

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

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">8&lt;---------------------------</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">In =
February of 1999, a lawsuit was filed by Surety Technologies, Inc., in =
which Surety alleged that the Entrust, Inc., digital timestamping =
product, Entrust/Timestamp(tm), infringed U.S. Patent Re 34,954 (the =
&quot;'954 Patent&quot;, a re-issue of U.S. Patent =
5,136,647).</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Entrust's =
product uses a common technique for digital timestamping called the =
hash-and-sign method. </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">In a =
verdict returned on November 3, 1999, a federal jury in the United =
States District Court for the Eastern District of Virginia held that =
the claims of the '954 Patent covering hash-and-sign timestamping were =
not new at the time of the purported invention, and further, were =
longstanding as the obvious way to digitally timestamp an electronic =
document.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">With this =
ruling, the use of hash-and-sign timestamping is now open to anyone =
wishing to implement this technology in products or services in the =
United States.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01C1D50C.89D3AF80--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2QJeIL14840 for ietf-pkix-bks; Tue, 26 Mar 2002 11:40:18 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2QJeF414835 for <[e-mail]>; Tue, 26 Mar 2002 11:40:16 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA02968 for <[e-mail]>; Tue, 26 Mar 2002 20:40:17 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 26 Mar 2002 20:40:17 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id UAA12319 for <[e-mail]>; Tue, 26 Mar 2002 20:40:16 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id UAA01083 for [e-mail]; Tue, 26 Mar 2002 20:40:15 +0100 (MET)
Date: Tue, 26 Mar 2002 20:40:15 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: OpenEvidence 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sorry for this message, I was informed in private
mail that my previous message contains an error. 

The second number should be 3161. 

Peter


Network Working Group                                           C. Adams
Request for Comments: 3161                                       Entrust
Category: Standards Track                                        P. Cain
                                                                     BBN
                                                               D. Pinkas
                                                                Integris
                                                           R. Zuccherato
                                                                 Entrust
                                                             August 2001


                Internet X.509 Public Key Infrastructure
                       Time-Stamp Protocol (TSP)

Network Working Group                                           C. Adams
Request for Comments: 3029                          Entrust Technologies
Category: Experimental                                      P. Sylvester
                                     EdelWeb SA - Groupe ON-X Consulting
                                                            M. Zolotarev
                                      Baltimore Technologies Pty Limited
                                                           R. Zuccherato
                                                    Entrust Technologies
                                                           February 2001


                Internet X.509 Public Key Infrastructure
           Data Validation and Certification Server Protocols

Peter

----- 
                                                                       

Hello,

I am happy to inform you that he EU-Commission has signed
the contrat for the project OPEN-EVIDENCE today.

As some might already know, part of the deliverables
are open source implementations of RFCs 3029 and 3061.


The partners are: C&A Italy, Cybernetica Estonia,
EdelWeb France and Speos Belgium.

The official project begin is April 1st 2002. ;-)

Stay tuned.

Regards
Peter Sylvester -- EdelWeb


=




----- End Included Message -----



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2QHcUc07937 for ietf-pkix-bks; Tue, 26 Mar 2002 09:38:30 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2QHcS407933 for <[e-mail]>; Tue, 26 Mar 2002 09:38:28 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA02453; Tue, 26 Mar 2002 18:38:28 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 26 Mar 2002 18:38:29 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id SAA11829; Tue, 26 Mar 2002 18:38:28 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA01052; Tue, 26 Mar 2002 18:38:27 +0100 (MET)
Date: Tue, 26 Mar 2002 18:38:27 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: OpenEvidence
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>

Hello,

I am happy to inform you that he EU-Commission has signed
the contrat for the project OPEN-EVIDENCE today.

As some might already know, part of the deliverables 
are open source implementations of RFCs 3029 and 3061.

The partners are: C&A Italy, Cybernetica Estonia, 
EdelWeb France and Speos Belgium.

The official project begin is April 1st 2002. ;-)

Stay tuned.  

Regards
Peter Sylvester -- EdelWeb


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2QHCUj05869 for ietf-pkix-bks; Tue, 26 Mar 2002 09:12:30 -0800 (PST)
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 g2QHCS405861 for <[e-mail]>; Tue, 26 Mar 2002 09:12:28 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA25400; Tue, 26 Mar 2002 18:14:50 +0100
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002032618115819:467 ; Tue, 26 Mar 2002 18:11:58 +0100 
Message-ID: <[e-mail]>
Date: Tue, 26 Mar 2002 18:11:50 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [e-mail]
CC: Carlisle Adams <[e-mail]>
Subject: Re: WG Last Call: Roadmap
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 26/03/2002 18:11:58, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 26/03/2002 18:12:30, Serialize complete at 26/03/2002 18:12:30
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g2QHCT405865
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Comments on the roadmap document draft-ietf-pkix-roadmap-07.txt
 
> This message initiates a two week Working Group Last Call for "Internet X.509
> Public Key Infrastructure: Roadmap". The document is available at
 
>      http://www.ietf.org/internet-drafts/draft-ietf-pkix-roadmap-07.txt
 
> Assuming successful completion of Last Call, the document will be forwarded for
> consideration as an Informational track RFC.

First of all. It is a very good and useful document. Nevertheless, a few
comments.

COMMENT 1. On page 1: 

"This draft is being discussed on the 'ietf-smime' mailing list. 
To subscribe, send a message to [e-mail] with 
the single word subscribe in the body of the message."

Now I understand why we got no comment on the PKIX mailing list. 
All comments have certainly been addressed to the SMIME mailing list !!!

:-)


COMMENT 2. Replace "at" by "prior" in expressions referring to Time-Stamping
in two sentences: "at an instant in time" (page 5) and "at a given time"
(page 7).


COMMENT 3. A sentence states: "However, to minimize confusion in this
document, we elect to call this node a "Top CA," and reserve "Root CA" for
the CA directly trusted by the EE". Since an EE may trust more than one Top
CA, shouldn't we say:

"However, to minimize confusion in this document, we elect to call this node
a "Top CA," and reserve "Root CA" when there is a single CA directly trusted
by the EE."


COMMENT 4. On page 14. A clarification needs to be done between
cross-certificates and CA certificates. The text currently states:

   A cross-certificate is a PKC issued by one CA to another CA which 
   contains a public CA key associated with the private CA signature key 
   used for issuing PKCs. Typically, a cross-certificate is used to 
   allow client systems or end entities in one administrative domain to 
   communicate securely with client systems or end users in another 
   administrative domain. Use of a cross-certificate issued from CA_1 to 
   CA_2 allows user Alice, who trusts CA_1, to accept a PKC used by Bob, 
   which was issued by CA_2. Cross-certificates can also be issued from 
   one CA to another CA in the same administrative domain, if required. 

I would propose instead the following:

" A CA certificate is a certificate in a hierarchy that is neither a
self-signed certificate, nor an end-entity certificate. [2459bis] does not
make a difference between a CA certificate and a cross certificate since it
defines a cross-certificate as "a certificate issued by one CA to another
CA". Some people in the WG believe that a cross certificate is a special
kind of CA certificate. A cross certificate is issued by a CA under one 
Top CA for another CA under a different Top CA. CAs in the same hierarchy 
have part of their names imposed by the Top CA or by the CAs under that 
Top CAS. When a cross certificate is issued, there is no relationship 
between the names of the CAS. 
 
Typically, a cross-certificate is used to allow client systems or end
entities in one administrative domain to communicate securely with client
systems or end users in another administrative domain. Use of a
cross-certificate issued from CA_1 to CA_2 allows user Alice, who trusts
CA_1, to accept a PKC used by Bob, which was issued by CA_2.
Cross-certificates can also be issued from one CA to another CA in the same
administrative domain, if required."


COMMENT 5. On page 15, the text states: "A CRL is a time stamped list
identifying revoked PKCs that is signed by a CA and made freely available 
in a public repository."

I would prefer to avoid to use "time-stamped" in that context and thus I
would propose the following wording:

"A CRL is a list that identifies the references of revoked PKCs. This list
contains a date of issue and is signed by a CA and made freely available in
a public repository."


COMMENT 6. On page 22. Correct a typo. Change "ôRepresentation" by
"Representation".


COMMENT 7. On page 22. Correct a typo. Change "Certificates.ö" by
"Certificates." 


COMMENT 8. On page 22. Correct a typo. Change "fro" by "from"


COMMENT 9. On page 22. Due to a very recent change of scope of the PI
document replace "individual" by "entity".

This leads to the following:

     This document defines a new form of name, the 
     permanent identifier, which is a name assigned by an organization, 
     unique within that organization, that singles out a particular 
     entity from all other entities. The permanent identifier is 
     an optional feature that may be used by a CA to indicate that the 
     certificate relates to the same entity even if the name or the 
     affiliation of that entity has changed. The permanent 
     identifier is important in the context of access control and of 
     non-repudiation.


COMMENT 10. On page 28. The story about patents on TSP is currently
described as follows:

   "At the Minneapolis IETF meeting, it was disclosed that the materials 
   covered in [TSP] draft may be covered by patent(s). Use of the 
   material covered by the patent(s) in question has not be granted by 
   the patent holder. Thus, anyone interested in implementing the PKIX 
   [TSP] draft must be aware of this intellectual property issue. "

 
Which IETF meeting in Minneapolis, since we have had three meetings in that
location ? Anyway, the description does not capture what happened with
Surety and Entrust. During the last IETF 2002 meeting in Minneapolis, I have
asked Carlisle to provide a text replacement.


COMMENT 11. On page 47. Section 5.5 talks about trust model, but only
consider a single trust point:

"  An important design decision is where a particular EE's trust point 
   is located (i.e., where is the EE's Root CA). There are a number of 
   models that have been developed and depending on the environment some 
   models may be more suited than others. The following provides some 
   background on the models."

I would rather propose to change it into:

" An important design decision is, for a given application, where the
particular EE's trust points are located (i.e. what are the Top CAs). 
There are a number of models that have been developed and depending on 
the environment some models may be more suited than others. The following
provides some background on the models."


COMMENT 12. On page 49. Section 5.5 I would propose to add another model.

5.5.5 Validation policies

Another model considers a set of rules that apply to an application context.
Every application context may have a different set of rules. When choosing
to use certificates in the context of that application, the EE selects the
set of rules for that context. In a set of rules, one or more Top CAs may be
trusted, each one may be associated with different constraints, like the
certificate policies that are trusted or the naming constraints that apply.
These constrains may be specified either in self-signed certificates or in
addition to self-signed certificates when they do not incorporate these
constraints. This set of rules is called a validation policy (when
validating a certificate) or a signature policy (when validating a digital
signature).

Regards,

Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2QEGn124374 for ietf-pkix-bks; Tue, 26 Mar 2002 06:16:49 -0800 (PST)
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 g2QEGl424370 for <[e-mail]>; Tue, 26 Mar 2002 06:16:47 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA24846; Tue, 26 Mar 2002 15:19:06 +0100
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002032615161543:436 ; Tue, 26 Mar 2002 15:16:15 +0100 
Message-ID: <[e-mail]>
Date: Tue, 26 Mar 2002 15:16:14 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Sharon Boeyen <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Attribute Certificates and Privilege Policy
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 26/03/2002 15:16:15, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 26/03/2002 15:16:45, Serialize complete at 26/03/2002 15:16:45
Content-Transfer-Encoding: 7bit
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>

Sharon,

> Just a couple of points to add:
> 
> The 509 PMI framework does not have any equivalent to
> cross-certification defined (it was included in early drafts
> but dropped from the spec prior to approval). The model is
> really addressing environments where the SOA and the verifier
> are in the same "security domain" and does not really address
> any cross-domain issues. 

You got one point: the issue is to allow for more than trust anchor.
The other point is to allow different levels of verification of the
attributes for the same AA.

> Verifiers are expected to be configured
> with a trusted copy of their SOA public key as they are today for
> trust anchors in PMI. The verifier trusts the SOA as the ultimate
> source of authority for a set of privileges.

This is too restrictive. Verifiers are expected to be configured 
with a validation policy, that includes more than one trust anchor.

Verifiers may also be configured for a single domain to only consider
attributes that are highly verified.

> If there are requirements to enhance the 509 model, those
> requirements can certainly be submitted to the 509 work by PKIX.

So be it.

> From a process standpoint there is no problem, the liaisons
> already exist and we've worked successfully on other topics
> through this channel, regardless of who agrees or disagrees with the
> specific topic.
 
> From my own personal standpoint, I'm not yet convinced of the requirement.

Please, take a look at http://www.imc.org/draft-ietf-pkix-dpv-dpd-req even
if it does not address Attribute Certificates, but the concepts for
validating an Attribute Certificate would be similar. We are not including
them in this document yet, as there is a need to clarify the use of
Attribute Certificates in the general case (more than one root trusted).
 
> the arguments seem to be that we need it for PMI because we use it for PKI
> or we need it to cover liability issues. The liability issue seems much less
> convincing when you recognize that the 509 PMI model does NOT include any
> inter-domain cross-certification equivalent. Documenting your own
> liability for internal applications isn't very interesting.

This has first a relationship with trust, which thenafter includes a
relationship with liability.

Denis

> Sharon
> 
> 
> -----Original Message-----
> From: Peter Williams [mailto:[e-mail]]
> Sent: Friday, March 15, 2002 6:49 PM
> To: 'Denis Pinkas'
> Cc: '[e-mail]'
> Subject: RE: Attribute Certificates and Privilege Policy
> 
> I dont see how privilege policy, as defined by ISO,
> has any equivalency relation to validation policy - as
> an architect speaking from a company that was
> conceived to deploy and has deployed over a hundred
> operational validation servers and associated validation
> policies in the world - for probably every major PKI
> vendors' system, and probably 50% of all operational
> commercial-grade PKIs!
> 
> Validation policies are the expression in some rule form
> of the risk management controls a RP uses to *Accept*
> a cert path, beyond the rules built into the simplistic path
> processing algorithm specified by ISO for
> trust chains *validation*; acceptance and validation
> are very different processes, especially in well written
> CPSs mapping technology onto law principles. ValiCert
> must have built now 10 quite-different validation policys, for
> various military projects and banking groups.
> 
> Whilst ISO rules for PKI trust chain processing
> properly arrange for inteoperability and navigation of trust
> domains (a valid ISO issue), validation policies address the
> risks applications face when PKI fails, PKI signals need to be
> ignored/overridden, redundacy of PKI chains, or PKI is used t
> o assist privilege-based control systems - whose purposes fall outside
> the scope of ISO PKI/PMI frameworks, or IETF profiles
> thereof.
> 
> In practice, privilege policy is already deployed worldwide, in
> two forms. Java 2 enables
> relying parties to sign and use an executable-form "AC", that limits
> privilege acceptance for privileges asserted by loading-code,
> using privilege-policy rule expressions that are
> expressed as executable code, selected and downloaded by the
> target system. Microsoft  Win32 OS's TCB does something similar
> since 5  years ago, using other signalling
> and enforcement techniques, that leverages a little of the
> Authenticode standardization in 2459, and other
> PKI-based techniques properly not addressed by PKIX.
> 
> Validation policies are, in contrast, all about validation of
> certificate chains, PKI and PMI varieties. AS we learned
> from the authoritative editor of X.509, the ISO intended
> that privilege policy enforcement has little or nothing
> to do with AC delegation path processing, and nothing
> whatsoever to do with PKI path processing. Validation
> policies are exclusively associated with the PKI
> and/or PMI chain processing.
> 
> I asked the question, is privilege policy enforcement
> PART OF path processing. Sharon indicated that it
> is not, though ISO wording and titling of X.509 sections
> 16.x.y could be improved. Hence validation policies
> are not equivalent in basis to privilege policies.
> 
> AS privilege policy and validation policy do take
> the perspective of relying parties, there
> is some limited consistency in that shared
> perspective, to be fair to Denis.
> 
> If ISO decide that, contrary to current intepretation
> by the editor of the ISO position, that privilege
> policy enforcement IS A PART OF path processing,
> then we could possibly agree on there being
> some equivalency basis.
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Friday, March 15, 2002 9:50 AM
> To: Sharon Boeyen
> Cc: '[e-mail]'
> Subject: Re: Attribute Certificates and Privilege Policy
> 
> Sharon,
> 
> Yes, this is indeed a very long e-mail. Mine will be shorter.
> 
> Shortly speaking, the "privilege policy" is the equivalent of a
> "validation policy" (see the DPV requ. draft availmable from
> http://www.imc.org/draft-ietf-pkix-dpv-dpd-req), but it is NOT
> the equivalent of a certification policy.
> 
> You said: "In terms of 'why no certificate policy' - there was no need
> identified for an equivalent".
> 
> For CAs there are different levels of verification of the identity
> presented
> at the time of registration. This level is "visible" through the
> certificate
> policy.
> 
> I do not see why we should not draw a parallel with attributes, where for
> AAs there would be different levels of verification of the attributes
> presented at the time of registration. This level would be "visible"
> through
> the "attribute policy".
> 
> A validation policy (i.e. privilege policy using the ISO terminology) may
> consider that some attribute policies are adequate and that some others
> are
> not.
> 
> Otherwise, the single way to trust is to use the name of the AA.
> 
> If an AA supports different "attribute policies", it would have to change
> its
> name, each time. :-(
> 
> Thus I see a good reason to have an equivalent.
> 
> Regards,
> 
> Denis
> 
> > I'll try to address all the questions I've seen re the 509 aspects of
> this
> > discussion. (Sorry this is rather long, but I found this
> >
> > easier than trying to respond to each message).
> >
> > I think Peter has identified at least one part of 509 that could benefit
> 
> > from some editorial clarification.
> >
> > Clause 16 "Privilege path processing procedure" may be more appropriate
> > titled "Privilege assertion processing procedure".
> >
> > Each paragraph in 16.1 could probably use subtitles to clarify what's
> > really going on. The paragraphs in this section are basically
> >
> > a list of each of the checks that need to be done before an asserted
> > privilege can be granted to a claimant.
> > - Para 1 is doing a "validation" on each of the attribute certificates
> in
> > the path. This is just checking the signatures, using the
> >
> > PKI path validation steps as if you were checking the signature on a
> > signed form - the details are in clause 10 of the PKI section.
> >
> > - Para 2 is a check to ensure the claimant's willingness to use that
> > attribute cert for the context - no standard steps for this
> >
> > check are defined.
> > - Para 3 is the revocation status check - no details req'd
> > - Para 4 is the check for whether the asserted privilege is valid for
> the
> > time of interest - no details req'd
> > - Para 5 is checking any constraints imposed by the issuer of the AC on
> > the set of permitted targets - no details req'd
> > - Para 6 is the checks for roles and of delegation. Note that 16.2 is
> > merely the details associated with the role check and
> >
> > 16.3 is merely the details assoiated with the delegation check.
> > - Para 7 is the privilege policy check against the asserted privilege
> > together with the other inputs (target sensitivity,
> >
> > environmental variables) and checking any constraints on privilege
> policy
> > imposed by the issuer.
> >
> > So this complete set of steps comprise the processing that needs to be
> > done to assess a privilege assertion. Some of these
> > relate to paths (Para 1 is processing of a public-key certification path
> 
> > to verify the signature on the attribute cert and
> > Para 6 along with 16.3 is processing of a delegation path of attribute
> > certificates to determine whether or not the delegation
> > itself is authorized and valid. As part of the processing of a
> delegation
> > path, note that the signature on EACH attribute
> > certificate in the path needs to be verified, so again the public-key
> path
> > validation is used for that purpose). I wanted to
> > try to clarify this because asking if something is part of "path
> > validation" is not as easy to answer as it would be if
> > we were talking about PKI instead of PMI.
> >
> > The privilege policy is the basis for determining the acceptance of an
> > attribute certificate (at least from a policy perspective).
> >
> > It is processed by a verifier as one of the steps in assessing a
> privilege
> > assertion, but it is not strictly part of either
> > public-key certification path processing done for signature verification
> 
> > or part of delegation path processing for verifying
> > delegation.
> >
> > Many aspects of privlege policy were not standardized in 509, including
> > its syntax, who can write them etc, how does
> > a verifier know which one to use etc. Some of these were deferred, e.g.
> > syntax. Note however, that in OASIS, the XACML
> > working group is now defining a standard XML syntax for access control
> > policy. Some material from the sample syntaxes
> > in the X.509 informative annex were input to the XACML work so folks
> > interested in privilege policy may find that work
> > interesting as well. As for how the verifier knows which privilege
> policy
> > to use - that is left to the implementation. In
> > some cases a target may always work with a single privilege policy and
> it
> > may be created by the local SOA . There
> > are hooks to tie privilege policies to attributes for which an SOA
> assigns
> > privileges (the attributeDescriptor in 15.3.2.2 and
> > there is also directory syntax to store them, but no standardized way
> for
> > a verifier to determine which to use. However a local
> > trusted SOA would obviously be one possible source of privilege
> policies.
> >
> > Regarding the acceptablePrivilegePolicies extension, a verifier is
> always
> > assessing a privilege assertion with respect to
> > a specific privilege policy as per para 7 in 14.1. In the absence of the
> 
> > acceptablePrivilegePolicies extension, the verifier
> > merely assess the assertion with respect to the privilege policy it is
> > working with (out of band / local means for determining
> > which privilege policy the verifier operates with - likely greatly
> > determined by the target). If the acceptablePrivilegePolicies
> > extension is present, then the verifier needs to check whether the
> > privilege policy it is operating under is one of the ones
> > listed as acceptable in that extension. If it is, then the verifier
> > proceeds normally. If it is not, the verifier stops and the privilege
> > asserter is not given access.
> >
> > The privilege policy is the set of rules that determine acceptability of
> 
> > an asserted privilege. A primary difference between
> > that and certificate policy is that certificate policy is tied to a
> > certificate and defines acceptable uses for that certificate,
> > while privilege policy is associated with a verifier and the target that
> 
> > is in question and determines which privilege assertions
> > are appropriate. So, things like usage constraints, dollar limits, time
> > constraints, name constraints - all those things would
> > be appropriate for inclusion in a privilege policy. I'm not convinced
> > about liability limits though, because privilegePolicy must
> > be machine processable as it is processed dynamically at assertion
> > assessment time. Liability limits don't seem like they
> > would easily lend themselves to this.
> >
> > In terms of 'why no certificate policy' - there was no need identified
> for
> > an equivalent. A verifier trusts an SOA as the
> > ultimate source of authority for assignment of a set of privileges.
> That's
> > the authorization issue I mentioned earlier.
> >
> > If delegation is done, then the checks for ensuring that is authorized
> are
> > part of the delegation path processing
> > procedure. If an AA (SOA or delegated AA) wishes to constrain the policy
> 
> > under which an AC is used, it can do
> > so through the acceptablePrivilegePolicies extension. As for certificate
> 
> > policies, they are used when verifying the
> > signature on the attribute certificates as well as when verifying the
> > signature on any transaction associated with
> > the specific assertion of privilege being made by the claimant. So
> > certificate policies do factor into the overall
> > validation for any given transaction, but are not part of the privilege
> > assertion assessment.
> >
> > I hope this addresses the questions that were raised by Denis, Chris and
> 
> > Peter - if not I'm sure you'll let me know :-).
> >
> > In terms of 509 clarifications, if people think some defect work is
> needed
> > there, please let me know.
> >
> > FYI, I'm going to try to get all my editing tasks from the recent X.509
> > meeting completed and provide a brief summary
> > of the meeting to this list prior to the PKIX meeting. There are a
> couple
> > of current issues we're working on with respect
> > to SOAs that PMI folks might be interested in.
> >
> > Again, apologies for the length of the message.
> > Sharon
> >
> > Sharon Boeyen
> > Principal, Advanced Security
> > Tel: [phone]
> > www.entrust.com
> >
> > Entrust, Inc.
> > Securing the Internet


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2QDfiA22656 for ietf-pkix-bks; Tue, 26 Mar 2002 05:41:44 -0800 (PST)
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 g2QDfg422652 for <[e-mail]>; Tue, 26 Mar 2002 05:41:43 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA30086 for <[e-mail]>; Tue, 26 Mar 2002 14:44:03 +0100
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002032614411044:423 ; Tue, 26 Mar 2002 14:41:10 +0100 
Message-ID: <[e-mail]>
Date: Tue, 26 Mar 2002 14:41:09 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-01.txt
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 26/03/2002 14:41:10, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 26/03/2002 14:41:42, Serialize complete at 26/03/2002 14:41:42
Content-Transfer-Encoding: 7bit
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>

Comments on draft-ietf-pkix-logotypes-01.txt

There was no time available during the last meeting for comments. 
So here are my comments.


COMMENT 1: Subject logotype. 

Currently a "subject organization logotype" is proposed. It definition is as
follows: "a logotype representing the organization identified in the subject
name in the certificate".

>From this definition only a single logotype would be allowed for a subject.
It can make sense to attach more that one logotype to a subject, that does
not reflect necessarily the organization a user belongs to (e.g. an
individual is a Red Cross member) so the definition should be changed to:

"subject logotype" "a logotype representing any characteristic of the entity
identified in the subject name in the certificate".


COMMENT 2: Issuer logotype.

Currently an "issuer organization logotype" is proposed. It definition is as
follows: "a logotype representing the organization identified as part of the
issuer name in the certificate".

>From this definition a single logotype would be allowed for an issuer. It
can make sense to attach more that one logotype to an issuer, that does not
reflect necessarily the organization an issuer belongs to (e.g. an issuer
may support a "Privacy Policy" and be a member from two different trade
associations), so the definition should be changed to:

"issuer logotype: a logotype representing any characteristic of the issuer
identified as part of the issuer name in the certificate".


COMMENT 3: The "concept logotype", also renamed "community logotype" during
the last IETF meeting or " shared community logotype" in the minutes from
the same meeting is more hazy.

The current text states:" Many issuers may use the concept logotypes to
co-brand with a global concept in order to gain global recognition of its
local service provision. This type of concept branding is very common in
credit card business where local independent card issuers issue cards within
a globally branded concept (such as VISA and MasterCard)".

The current text also states: " the relationship between the issuer and
either the issuer organization logotype or the concept logotype".

A logotype is adding "human processable" information to enhance the
properties of an already existing field from a certificate. To this respect
it is sensible to add one (or more) logotypes that characterizes the issuer
and the subject. The real question is to which field the "concept logotype /
community logotype / shared community logotype" relates.

It may relate :

  - either to the issuer, to state that an issuer belongs to some group, or 

  - to the certificate policy to state that the policy under which the
    certificate is issued obeys to some rules imposed by the organization 
    whose logo is referenced.

This leads to two possible ways:

   1) only consider two logotypes: issuer logotype and subject logotypes.
   2) consider three logotypes: issuer logotypes, subject logotypes and 
      policy logotypes.

I would favor the former, but would have no major problem to go with the
later. In that case the policy logotype would be defined as follows:

"Policy logotype: a logotype representing any characteristic of the
certificate policy under which the certificate is issued".


COMMENT 4: Logotypes are not "claimed" by the issuer, but always *verified*
to some extend by the issuer. The current text is misleading: 

   "The relationship between the subject organization and the subject
   organization logotype and the relationship between the issuer and
   either the issuer organization logotype or the concept logotype, are
   relationships *claimed* by the issuer."


COMMENT 5: During the meeting, it has been proposed to add a small image of
the logotype in the certificate itself. In this WG we always have had a
concern about the size of the certificate, so that it can be lodged in some
small devices. So I would not favor to allow such provision in a extension
standardized by this WG.


COMMENT 6: It should be made clear that this extension in non-critical.


COMMENT 7: The document includes many typos to be corrected.


Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2PIG8515785 for ietf-pkix-bks; Mon, 25 Mar 2002 10:16:08 -0800 (PST)
Received: from wfhqex03.gfgsi.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2PIG8415781 for <[e-mail]>; Mon, 25 Mar 2002 10:16:08 -0800 (PST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Subject: v1.3 R10 Enhanced SNACC Freeware Now Available
Date: Mon, 25 Mar 2002 13:16:01 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: v1.3 R10 Enhanced SNACC Freeware Now Available
Thread-Index: AcHUKNh2i8U3gwBJS3uA143QFn4OIw==
From: "Pawling, John" <[e-mail]>
To: "ietf-pkix@imc. org (E-mail)" <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g2PIG8415782
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

Getronics Government Solutions has delivered the v1.3 R10 Enhanced
SNACC (eSNACC) Abstract Syntax Notation One (ASN.1) Compiler,
C++ library and C library source code and binaries tested on the 
Linux, Sun Solaris 2.8 and Microsoft Windows NT/98/2000/XP operating
systems.  The eSNACC software is freely available to everyone from:
<http://www.getronicsgov.com/hot/snacc_home.htm>.  The v1.3 R10
eSNACC release fixes significant bugs present in the previous
releases.

The eSNACC ASN.1 software can be used to ASN.1 encode and decode
objects.  In past releases, Getronics improved the eSNACC C++ 
library to implement the Distinguished Encoding Rules (DER), 
support large ASN.1 INTEGERs, and improve memory usage.    


v1.3 R10 eSNACC enhancements (compared to v1.3 R8 and R9 releases):

1) We corrected the eSNACC ASN.1 C and C++ libraries to properly
implement the sorting of SET OF components as specified in the 1997
X.690 DER requirements.  The eSNACC ASN.1 C++ library was incorrectly 
ignoring the tag and length of each component when determining 
their order.  The bug was present in the v1.3 R7, v1.3 R8, and 
v1.3 R9 releases of the eSNACC ASN.1 C++ library.  This bug caused
interoperability problems with correct DER implementations.  For 
example, this bug caused the S/MIME Freeware Library (SFL) (that
uses the eSNACC ASN.1 C++ library) to report signature verification 
problems when attempting to verify valid signed S/MIME messages.   

2) We corrected several bugs in the eSNACC ASN.1 C++ and C  
libraries that we discovered when testing them using the Simple
Network Management Protocol (SNMP) v1 test suite developed by the
University of Oulu.  The bugs were all error handling problems that
occurred when each ASN.1 library attempted to decode invalidly 
encoded indefinite lengths on primitive types.  These were all bugs
in the original SNACC code.  We used the v1.3 R10 eSNACC ASN.1 C++ 
and C libraries to successfully process all 18,000 test cases in 
the SNMPv1 Oulu test suite.  

3) We fixed a bug in CSM_Buffer::Write(...) (sm_buffer.cpp file)
that resulted in a significant decrease in the time required to
ASN.1 decode objects greater than 1MB in size.


We tested the v1.3 R10 eSNACC release with the v2.0.1 S/MIME
Freeware Library (SFL) (with patch files applied) available 
from <http://www.getronicsgov.com/hot/sfl_home.htm> that 
uses the eSNACC ASN.1 software to encode and decode the IETF 
S/MIME v3 Cryptographic Message Syntax (RFC 2630) and Enhanced
Security Services for S/MIME (RFC 2634) security protocol.  

We tested the v1.3 R10 eSNACC release with the freeware v2.0.1
Certificate Management Library (CML) (no patch files required) 
available from  <http://www.getronicsgov.com/hot/cml_home.htm> 
that uses the eSNACC ASN.1 software to encode and decode X.509 
certificates, attribute certificates and Certificate Revocation 
Lists as specified in the 2000 X.509 Recommendation.

We tested the v1.3 R10 eSNACC release with the freeware v2.0.1
Access Control Library (ACL) (no patch files required to use
v1.3 R10 eSNACC release) available from
<http://www.getronicsgov.com/hot/acl_home.htm>.  The ACL uses
the eSNACC ASN.1 software to encode and decode security
labels and other objects (such as Security Policy Information 
Files) required to provide rule based access control as 
specified in SDN.801.

The eSNACC ASN.1 software implements the majority of the 
ASN.1 encoding/decoding rules as specified in the 1988 X.209 
Recommendation.  It implements the DER as specified in the 1997 
X.690 Recommendation.  It does not support all of the latest ASN.1
features, but there are strategies that allow it to be used to 
produce ASN.1 hex encodings that are identical to those produced by
ASN.1 libraries that do support the latest ASN.1 features.  Also note
that many of the PKIX specs, such as RFC 2459 and RFC 2630, include 
1988-compliant ASN.1 syntax modules which can be compiled using the
eSNACC compiler.

The eSNACC ASN.1 library is totally unencumbered as stated 
in the Enhanced SNACC Software Public License.  All source code
for the eSNACC software is being provided at no cost and with no
financial limitations regarding its use and distribution.  
Organizations can use the eSNACC software without paying
any royalties or licensing fees.  

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

We welcome all feedback regarding the eSNACC software.
If bugs are reported, then we will investigate each reported
bug and, if required, will produce a patch or an updated
release of the software to repair the bug. 

This release announcement was sent to several mail lists,
but please send all messages regarding the eSNACC 
software to the imc-snacc mail list ONLY.  Please do not send 
messages regarding the eSNACC software to any of the 
IETF mail lists.  We will respond to all messages sent to the
imc-snacc 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 g2PGu1C10233 for ietf-pkix-bks; Mon, 25 Mar 2002 08:56:01 -0800 (PST)
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 g2PGtx410229 for <[e-mail]>; Mon, 25 Mar 2002 08:55:59 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA17900; Mon, 25 Mar 2002 11:55:18 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100309b8c503fd1977@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 25 Mar 2002 11:49:01 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: draft PKIX meeting minutes
Cc: [e-mail]
Content-Type: multipart/alternative; boundary="============_-1195047083==_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>

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

At 11:42 AM +0100 3/25/02, Stefan Kelm wrote:
>Folks,
>
>>  Document Status Overview
>>	The PKIX Working Group has twenty eight current I-Ds.  Three
>>  I-Ds (Certificate Profile, Public Key Algorithms, and Attribute
>>  Certificate Profile) are in the RFC editors queue for standards track.
>>  Three specifications are in WG Last Call (DPD/DPV Requirements, the
>>  Roadmap and CP/CPS Framework).  All three are projected as Informational
>>  RFCs.  OCSP and the results of interoperability testing have been
>>  forwarded to the ADs for consideration for Draft.  Two additional I-Ds
>
>I haven't been able to find anything in the archive: have the
>results of interop testing been published anywhere yet?
>
>Cheers,
>
>	Stefan.

I have attached the interop test results document that we submitted 
to the IESG in support of advancement. I don't recall whether it was 
posted to the list previously, but since we will need to prepare 
similar test documents for other standards as we continue, this is an 
example of the style of document one might prepare.

Steve
-------

                                                             R. Hurst
                                                             ValiCert
                                                      	    A. Malpani
                                                             ValiCert
                                                             S. Henson
                                                             Celocom
                                                             A. Grant
                                                             Computer Associates

                 X.509 Internet Public Key Infrastructure
                Online Certificate Status Protocol -- OCSP
                         Interoperability Summary

1.    Abstract

       This document summarizes the interoperability resulting from testing
       Various OCSP implementations for compliance and interoperability.

       All tests covered in this document were derived from the OCSP RFC
       [RFC2560].


1.1   Interoperability Results
   
       Results will be specified in the following format:

        Impl. #1         Impl. #1                     Impl. #2
        ------------------------------------------------------
        [ ]              [ ]                          [ ]

       Each implementation evaluated will be given one of the following
       "ratings":

        [?]	Unknown
        [x]	Implemented and interoperates with at least one
                 other known implementation included in this report.
        [-]	Not implemented


1.2   Implementations included in testing

       In this report the following products were included:

  	* ValiCert Enterprise VA 4.2
  	* Computer Associates eTrust OCSPro
  	* OpenSSL SNAP 08-30-2001

       Primary contact for each Implementation includes:

  	* ValiCert              Ryan Hurst      [e-mail]
  	* Computer Associates   Alistair Grant  [e-mail]
  	* OpenSSL               Dr S. Henson    [e-mail]

1.3   Result summary

       It was found that all three implementations were interoperable, in
       all cases tested, additionally it was found that these
       implementations were "compliant" with the OCSP RFC.

Hurst                   OCSP Interoperability Summary            [Page 2]


1.3   Tools used in testing

       Several tools were used while performing testing, these included:
    
  	* Computer Associates - ocspc
  	* ValiCert - vatest
  	* openssl - ocsp
  	* Peter Gutmanns - dumpasn1
  	* Hobits - netcat (nc)

1.4   Responders used in testing

       A variety of responders were used in testing, these included public
       and private responders.


2      Client Generation Request Generation Results

2.1    A Client MAY support the checking of a responder certificate
        for revocation as per section 4.2.2.2.1

     
2.1.1  A Client MAY check the ocsp-nocheck extension to determine
        if a responder certificate is to be checked for revocation as per
        section.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]

2.1.2  A Client MAY determine the responder certificate status
        using the CRL Distribution Point extension in the responder
        certificate.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [-]              [-]                          [-]

2.1.3  A Client MAY determine the responder certificate status
        using the Authoritative Information Access extension in the
        responder certificate.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]

2.1.4  A Client MAY determine the responder certificate status
        using a client configured location and mechanism.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]





Hurst                   OCSP Interoperability Summary            [Page 3]

2.2    Client SHALL support including the ServiceLocator extension
        with its requests as per sections 3.1, 4.2.2.2.1 and 4.4.6

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]


2.3    Clients MUST support sending "unsigned" OCSP requests as
        per Appendix C


        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]  


2.4    Clients MUST support the RSAwithSHA1 signature suite as per
        section 4.3

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]  

2.5    Clients SHALL support the response type of BasicOCSPResponse
        as per section 4.2.1

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]  
     
2.6    Clients MAY support including a nonce in requests as per
        section 4.4.1

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]     
     
2.7    Clients MAY with to include the "Acceptable Response Types" it
        supports within its requests as per section 4.4.3

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [-]              [-]                          [-]       
     













Hurst                   OCSP Interoperability Summary            [Page 4]


3      Server Request Processing Results

3.1    In error conditions it is possible for a responder to return a
        unsigned error response.
	 
3.1.1  Server MAY handle incorrectly formatted requests by returning
        the error "malformedRequest" as per section 2.3 in the OCSP RFC.
        This case was reproduced by generating a valid OCSP request and
        modifying a single bit of that request
        to contain a bogus value.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]

3.1.2  Server MAY return the error "internalError" when it encounters
        an internal error as per section 2.3 in the OCSP RFC.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]

3.1.3  Server MAY return the error of "tryLater" to indicate
        that the service exists, but is temporarily unable to respond
        as per section 2.3 of the OCSP RFC.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [?]              [?]                          [?]

3.1.4  Server MAY return the error of "sigRequired" to notify
        a client that it requires responses to be signed.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]
     
3.2.1  Servers MUST support http as a transport

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x] 

3.2.2  Servers MAY support https as a transport

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]
     
3.2.3  Servers SHOULD support HTTP POSTs

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]




Hurst                   OCSP Interoperability Summary            [Page 5]


4      Server Response Generation Results

4.1    Server SHOULD be capable of generating responses for multiple CertIDs

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]


4.2    Responses include several time dependant values, these values
        are documented in section 2.4 of the OCSP RFC.

4.2.1  Server SHOULD include a response validity interval as per section
        2.2 and 2.4 of the OCSP RFC.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]

4.2.2  Server MUST include the producedAt extension as per section 2.4
        of the OCSP RFC.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]

4.3.1  Server MUST be capable of returning definitive response of "good"
        as per section 2.2 of the OCSP RFC.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]

4.3.2  Server MUST be capable of returning definitive response of "revoked"
        as per section 2.2 of the OCSP RFC.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]

4.3.3  Server MUST be capable of returning definitive response of unknown
        as per section 2.2 of the OCSP RFC.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]

4.4    Server MAY support the optional pre-production of responses
        as per section 2.5 of the OCSP RFC.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [-]              [-]                          [-]
     


Hurst                   OCSP Interoperability Summary            [Page 6]


4.5    Server MAY support the optional "CA Key Compromise" scenario as per
        section 2.7 of the OCSP RFC.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [-]              [x]                          [-]

4.6    Server MAY support including a nonce in responses as per section
        4.4.1

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x] 



4.7    Server MAY support including the optional CrlID (CRL References)
        extension in responses as per section 4.4.2

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [-]              [-]                          [-]
     
4.8    Server MAY support including the optional "CRL Entry Extensions"
        in responses as per section 4.4.5

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]
     
4.9    Servers MUST support sending responses of type: BasicOCSPResponse

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]  
     
4.10   Servers MUST support identification of responder byName

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x] 

4.11   Servers SHOULD support identification of responder by keyId

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x] 










Hurst                   OCSP Interoperability Summary            [Page 7]


5      Client Response Processing Results

5.1    Verification Trust Models

5.1.1  Clients MUST support verification of CA Signed results as per section
        2.2 in the OCSP RFC.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]

5.1.2  Clients MUST support verification of responses signed by a directly
        trusted responder as per section 2.2 of the OCSP RFC.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]

5.1.3  Clients MUST support verification of responses signed by a CA
        designated responder as per section 2.2 and 2.6 of the OCSP RFC.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]

5.2    Error cases

5.2.1  Clients MUST support processing of malformedRequest error responses
        as per section 2.3 of the OCSP RFC. This test was produced by
        sending the Verisign OCSP responder a signed OCSP request.
        at the time of testing this responder is known not to support
        signed requests, as such it will respond in this matter.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]


5.2.2  Clients MUST support processing of internalError error responses
        as per section 2.3 of the OCSP RFC.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x] 

5.2.3  Clients MUST support processing of tryLater error responses
        as per section 2.3 of the OCSP RFC. Support in this case denotes
        successfully handling the error, not necessarily trying again.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]





Hurst                   OCSP Interoperability Summary            [Page 8]


5.2.4  Clients MUST support processing of sigRequired error responses
        as per section 2.3 of the OCSP RFC.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]
        
5.2.5  Clients MUST support processing of unauthorized error responses
        as per section 2.3 of the OCSP RFC.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]

5.3.1  Clients MUST support http transport

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]

5.3.2  Clients MAY support https transport

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]
      
5.3.3  Client supports http POSTs

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]

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

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: draft PKIX meeting minutes</title></head><body>
<div>At 11:42 AM +0100 3/25/02, Stefan Kelm wrote:</div>
<blockquote type="cite" cite>Folks,<br>
<br>
&gt; Document Status Overview<br>
&gt;<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>The PKIX
Working Group has twenty eight current I-Ds.&nbsp; Three<br>
&gt; I-Ds (Certificate Profile, Public Key Algorithms, and
Attribute<br>
&gt; Certificate Profile) are in the RFC editors queue for standards
track.<br>
&gt; Three specifications are in WG Last Call (DPD/DPV Requirements,
the<br>
&gt; Roadmap and CP/CPS Framework).&nbsp; All three are projected as
Informational<br>
&gt; RFCs.&nbsp; OCSP and the results of interoperability testing have
been<br>
&gt; forwarded to the ADs for consideration for Draft.&nbsp; Two
additional I-Ds<br>
<br>
I haven't been able to find anything in the archive: have the<br>
results of interop testing been published anywhere yet?<br>
<br>
Cheers,<br>
</blockquote>
<blockquote type="cite"
cite><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>Stefan.</blockquote>
<div><br></div>
<div>I have attached the interop test results document that we
submitted to the IESG in support of advancement. I don't recall
whether it was posted to the list previously, but since we will need
to prepare similar test documents for other standards as we continue,
this is an example of the style of document one might prepare.</div>
<div><br></div>
<div>Steve</div>
<div>-------</div>
<div><br></div>
<div><font face="Courier" size="+2"
color="#000000"
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp; R. Hurst<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp; ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<x-tab
>&nbsp;&nbsp; </x-tab>&nbsp;&nbsp;&nbsp; A. Malpani<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp; ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp; S. Henson<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp; Celocom<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp; A. Grant<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp; Computer Associates<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp; X.509 Internet Public Key
Infrastructure<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; Online Certificate Status Protocol --
OCSP<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Interoperability Summary<br>
<br>
1.&nbsp;&nbsp;&nbsp; Abstract<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This document summarizes the
interoperability resulting from testing<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Various OCSP implementations for
compliance and interoperability.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; All tests covered in this document were
derived from the OCSP RFC<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [RFC2560].<br>
<br>
<br>
1.1&nbsp;&nbsp; Interoperability Results<br>
&nbsp;&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Results will be specified in the
following format:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Impl.
#1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Impl.
#1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Impl.
#2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [
]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp; [
]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [ ]<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Each implementation evaluated will be
given one of the following<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;ratings&quot;:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [?]<x-tab>&nbsp;
</x-tab>Unknown<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Implemented and
interoperates with at least one<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp; other known implementation included
in this report.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [-]<x-tab>&nbsp;&nbsp;&nbsp;
</x-tab>Not implemented<br>
<br>
<br>
1.2&nbsp;&nbsp; Implementations included in testing<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In this report the following products
were included:<br>
<br>
&nbsp;<x-tab>&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>* ValiCert Enterprise VA
4.2<br>
&nbsp;<x-tab>&nbsp;&nbsp; </x-tab>* Computer Associates eTrust
OCSPro<br>
&nbsp;<x-tab>&nbsp;&nbsp;&nbsp; </x-tab>* OpenSSL SNAP 08-30-2001<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Primary contact for each Implementation
includes:<br>
<br>
&nbsp;<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>*
ValiCert&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; Ryan Hurst&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[e-mail]<br>
&nbsp;<x-tab>&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>* Computer
Associates&nbsp;&nbsp; Alistair Grant&nbsp; [e-mail]<br>
&nbsp;<x-tab>&nbsp; </x-tab>*
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp; Dr S. Henson&nbsp;&nbsp;&nbsp;
[e-mail]<br>
<br>
1.3&nbsp;&nbsp; Result summary<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; It was found that all three
implementations were interoperable, in<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; all cases tested, additionally it was
found that these<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; implementations were &quot;compliant&quot;
with the OCSP RFC.<br>
<br>
Hurst&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OCSP
Interoperability
Summary&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[Page 2]<br>
&nbsp;<br>
<br>
1.3&nbsp;&nbsp; Tools used in testing<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Several tools were used while
performing testing, these included:<br>
&nbsp;&nbsp;&nbsp;<br>
&nbsp;<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>* Computer
Associates - ocspc<br>
&nbsp;<x-tab>&nbsp; </x-tab>* ValiCert - vatest<br>
&nbsp;<x-tab>&nbsp;&nbsp;&nbsp; </x-tab>* openssl - ocsp<br>
&nbsp;<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>* Peter
Gutmanns - dumpasn1<br>
&nbsp;<x-tab>&nbsp;&nbsp;&nbsp; </x-tab>* Hobits - netcat (nc)<br>
<x-tab>&nbsp; </x-tab><br>
1.4&nbsp;&nbsp; Responders used in testing<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A variety of responders were used in
testing, these included public<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and private responders.<br>
<x-tab>&nbsp; </x-tab><br>
<br>
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Client Generation Request Generation
Results<br>
<br>
2.1&nbsp;&nbsp;&nbsp; A Client MAY support the checking of a responder
certificate<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for revocation as per section
4.2.2.2.1<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;<br>
2.1.1&nbsp; A Client MAY check the ocsp-nocheck extension to
determine<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if a responder certificate is to
be checked for revocation as per</font></div>
<div><font face="Courier" size="+2"
color="#000000">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; section.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]<br>
<br>
2.1.2&nbsp; A Client MAY determine the responder certificate
status<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; using the CRL Distribution Point
extension in the responder<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; certificate.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[-]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[-]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [-]<br>
<br>
2.1.3&nbsp; A Client MAY determine the responder certificate
status<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; using the Authoritative
Information Access extension in the<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; responder certificate.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]<br>
<br>
2.1.4&nbsp; A Client MAY determine the responder certificate
status<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; using a client configured
location and mechanism.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]<br>
<br>
<br>
<br>
<br>
<br>
Hurst&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OCSP
Interoperability
Summary&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[Page 3]<br>
&nbsp;<br>
2.2&nbsp;&nbsp;&nbsp; Client SHALL support including the
ServiceLocator extension<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; with its requests as per sections
3.1, 4.2.2.2.1 and 4.4.6<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]<br>
<br>
<br>
2.3&nbsp;&nbsp;&nbsp; Clients MUST support sending &quot;unsigned&quot;
OCSP requests as<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; per Appendix C<br>
<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]&nbsp;&nbsp;<br>
<br>
<br>
2.4&nbsp;&nbsp;&nbsp; Clients MUST support the RSAwithSHA1 signature
suite as per<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; section 4.3<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]&nbsp;&nbsp;<br>
<br>
2.5&nbsp;&nbsp;&nbsp; Clients SHALL support the response type of
BasicOCSPResponse<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; as per section 4.2.1<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]&nbsp;&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;<br>
2.6&nbsp;&nbsp;&nbsp; Clients MAY support including a nonce in
requests as per<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; section 4.4.1<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;<br>
2.7&nbsp;&nbsp;&nbsp; Clients MAY with to include the &quot;Acceptable
Response Types&quot; it<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; supports within its requests as
per section 4.4.3<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[-]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[-]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;
[-]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Hurst&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OCSP
Interoperability
Summary&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[Page 4]<br>
&nbsp;<br>
<br>
3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Server Request Processing Results<br>
<br>
3.1&nbsp;&nbsp;&nbsp; In error conditions it is possible for a
responder to return a<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; unsigned error response.<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>&nbsp;<br>
3.1.1&nbsp; Server MAY handle incorrectly formatted requests by
returning<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the error &quot;malformedRequest&quot;
as per section 2.3 in the OCSP RFC.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This case was reproduced by
generating a valid OCSP request and<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; modifying a single bit of that
request<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to contain a bogus value.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]<br>
<br>
3.1.2&nbsp; Server MAY return the error &quot;internalError&quot; when
it encounters<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; an internal error as per section
2.3 in the OCSP RFC.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]<br>
<br>
3.1.3&nbsp; Server MAY return the error of &quot;tryLater&quot; to
indicate<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; that the service exists, but is
temporarily unable to respond</font></div>
<div><font face="Courier" size="+2"
color="#000000">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; as per section
2.3 of the OCSP RFC.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[?]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[?]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [?]<br>
<br>
3.1.4&nbsp; Server MAY return the error of &quot;sigRequired&quot; to
notify<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a client that it requires
responses to be signed.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]<br>
&nbsp;&nbsp;&nbsp;&nbsp;<br>
3.2.1&nbsp; Servers MUST support http as a transport<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]&nbsp;<br>
<br>
3.2.2&nbsp; Servers MAY support https as a transport<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]<br>
&nbsp;&nbsp;&nbsp;&nbsp;<br>
3.2.3&nbsp; Servers SHOULD support HTTP POSTs<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]<br>
<br>
<br>
<br>
<br>
Hurst&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OCSP
Interoperability
Summary&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[Page 5]<br>
&nbsp;<br>
<br>
4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Server Response Generation Results<br>
&nbsp;<br>
4.1&nbsp;&nbsp;&nbsp; Server SHOULD be capable of generating responses
for multiple CertIDs<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]<br>
<br>
<br>
4.2&nbsp;&nbsp;&nbsp; Responses include several time dependant values,
these values<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; are documented in section 2.4 of
the OCSP RFC.<br>
<br>
4.2.1&nbsp; Server SHOULD include a response validity interval as per
section<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2.2 and 2.4 of the OCSP RFC.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]<br>
<br>
4.2.2&nbsp; Server MUST include the producedAt extension as per
section 2.4<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of the OCSP RFC.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]<br>
<br>
4.3.1&nbsp; Server MUST be capable of returning definitive response of
&quot;good&quot;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; as per section 2.2 of the OCSP
RFC.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]<br>
<br>
4.3.2&nbsp; Server MUST be capable of returning definitive response of
&quot;revoked&quot;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; as per section 2.2 of the OCSP
RFC.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]<br>
<br>
4.3.3&nbsp; Server MUST be capable of returning definitive response of
unknown<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; as per section 2.2 of the OCSP
RFC.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]<br>
<br>
4.4&nbsp;&nbsp;&nbsp; Server MAY support the optional pre-production
of responses<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; as per section 2.5 of the OCSP
RFC.<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[-]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[-]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [-]<br>
&nbsp;&nbsp;&nbsp;&nbsp;<br>
<br>
<br>
Hurst&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OCSP
Interoperability
Summary&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[Page 6]<br>
&nbsp;<br>
<br>
4.5&nbsp;&nbsp;&nbsp; Server MAY support the optional &quot;CA Key
Compromise&quot; scenario as per<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; section 2.7 of the OCSP RFC.<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[-]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [-]<br>
<br>
4.6&nbsp;&nbsp;&nbsp; Server MAY support including a nonce in
responses as per section<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4.4.1<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]&nbsp;</font></div>
<div><font face="Courier" size="+2" color="#000000"><br>
<br>
<br>
4.7&nbsp;&nbsp;&nbsp; Server MAY support including the optional CrlID
(CRL References)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; extension in responses as per
section 4.4.2<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[-]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[-]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [-]<br>
&nbsp;&nbsp;&nbsp;&nbsp;<br>
4.8&nbsp;&nbsp;&nbsp; Server MAY support including the optional
&quot;CRL Entry Extensions&quot;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in responses as per section
4.4.5<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]<br>
&nbsp;&nbsp;&nbsp;&nbsp;<br>
4.9&nbsp;&nbsp;&nbsp; Servers MUST support sending responses of type:
BasicOCSPResponse<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]&nbsp;&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;<br>
4.10&nbsp;&nbsp; Servers MUST support identification of responder
byName<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]&nbsp;<br>
&nbsp;<br>
4.11&nbsp;&nbsp; Servers SHOULD support identification of responder by
keyId<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]&nbsp;<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Hurst&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OCSP
Interoperability
Summary&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[Page 7]<br>
&nbsp;<br>
<br>
5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Client Response Processing Results<br>
<br>
5.1&nbsp;&nbsp;&nbsp; Verification Trust Models<br>
<br>
5.1.1&nbsp; Clients MUST support verification of CA Signed results as
per section<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2.2 in the OCSP RFC.<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]<br>
<br>
5.1.2&nbsp; Clients MUST support verification of responses signed by a
directly<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; trusted responder as per section
2.2 of the OCSP RFC.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]<br>
<br>
5.1.3&nbsp; Clients MUST support verification of responses signed by a
CA<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; designated responder as per
section 2.2 and 2.6 of the OCSP RFC.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]<br>
<br>
5.2&nbsp;&nbsp;&nbsp; Error cases<br>
<br>
5.2.1&nbsp; Clients MUST support processing of malformedRequest error
responses<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; as per section 2.3 of the OCSP
RFC. This test was produced by<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sending the Verisign OCSP
responder a signed OCSP request.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; at the time of testing this
responder is known not to support<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; signed requests, as such it will
respond in this matter.<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]<br>
&nbsp;<br>
&nbsp;<br>
5.2.2&nbsp; Clients MUST support processing of internalError error
responses<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; as per section 2.3 of the OCSP
RFC.<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]&nbsp;<br>
<br>
5.2.3&nbsp; Clients MUST support processing of tryLater error
responses<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; as per section 2.3 of the OCSP
RFC. Support in this case denotes<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; successfully handling the error,
not necessarily trying again.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]<br>
&nbsp;<br>
<br>
<br>
<br>
<br>
Hurst&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OCSP
Interoperability
Summary&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[Page 8]<br>
&nbsp;<br>
<br>
5.2.4&nbsp; Clients MUST support processing of sigRequired error
responses<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; as per section 2.3 of the OCSP
RFC.<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</font></div>
<div><font face="Courier" size="+2" color="#000000">5.2.5&nbsp;
Clients MUST support processing of unauthorized error responses<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; as per section 2.3 of the OCSP
RFC.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]<br>
<br>
5.3.1&nbsp; Clients MUST support http transport<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]<br>
<br>
5.3.2&nbsp; Clients MAY support https transport<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
5.3.3&nbsp; Client supports http POSTs<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OpenSSL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Computer
Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValiCert<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;
[x]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; [x]</font><br>
<font face="Courier" size="+2" color="#000000"></font></div>
</body>
</html>
--============_-1195047083==_ma============--


Received: by above.proper.com (8.11.6/8.11.3) id g2PG4KV06214 for ietf-pkix-bks; Mon, 25 Mar 2002 08:04:20 -0800 (PST)
Received: from tiznit.digitaldelivery.com ([205.162.170.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2PG4G406202 for <[e-mail]>; Mon, 25 Mar 2002 08:04:16 -0800 (PST)
Received: by TIZNIT with Internet Mail Service (5.5.2653.19) id <GZN77440>; Mon, 25 Mar 2002 11:04:13 -0500
Message-ID: <C734DAA35F96D511A7BD0002B33B3A052CDFBB@TIZNIT>
From: Scott Mustard <[e-mail]>
To: "PKIX (E-mail)" <[e-mail]>
Subject: RE: TSP interoperability testing
Date: Mon, 25 Mar 2002 11:04:12 -0500
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>

We moved our IBM 4758 based StampServer to tssdemo2.datum.com .  We should
have another platform at tssdemo3.datum.com available soon.  If anyone has
problems with the attribute cert or anything else with our StampServers let
me know.

- Scott

-----Original Message-----
From: Scott Mustard [mailto:[e-mail]]
Sent: Tuesday, January 08, 2002 2:47 PM
To: PKIX (E-mail)
Subject: RE: Progression of RFC 3161 (TSP) to Draft Standard



Datum's StampServer is available for test at 64.241.183.87.  If your request
includes the certReq field set to true, the time-stamp token will include an
attribute certificate in addition to the required TSA certificate.  Some
decoders cannot handle attribute certificates in the certificate list.  If
you have a problem decoding our response, we can supply the ASN.1 definition
for attribute certificates and for our timing-metrics attribute.


Regards,


Scott Mustard

Datum - Trusted Time Division
http://www.datum.com/tt/
10 Maguire Road Suite 120
Lexington, MA 02421-3110


Received: by above.proper.com (8.11.6/8.11.3) id g2PDHfq22757 for ietf-pkix-bks; Mon, 25 Mar 2002 05:17:41 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2PDHd422753 for <[e-mail]>; Mon, 25 Mar 2002 05:17:39 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08896; Mon, 25 Mar 2002 08:17:27 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-pr-tsa-00.txt
Date: Mon, 25 Mar 2002 08:17:27 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Policy Requirements for Time-Stamping Authorities
	Author(s)	: D. Pinkas, J. Ross
	Filename	: draft-ietf-pkix-pr-tsa-00.txt
	Pages		: 39
	Date		: 20-Mar-02
	
This document specifies policy requirements relating to the 
operation of Time-stamping Authorities (TSAs). It defines policy 
requirements on the operation and management practices of TSAs such 
that subscribers and relying parties may have confidence in the 
operation of the time-stamping services.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-pr-tsa-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-pr-tsa-00.txt

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2PAhLf12787 for ietf-pkix-bks; Mon, 25 Mar 2002 02:43:21 -0800 (PST)
Received: from rom.antech.de (dns.antech.de [194.45.12.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2PAhJ412780 for <[e-mail]>; Mon, 25 Mar 2002 02:43:20 -0800 (PST)
Received: from Serbius.secorvo.de (kasiski.secorvo.de [194.45.12.203]) by rom.antech.de (8.9.3/8.9.3) with ESMTP id LAA27183 for <[e-mail]>; Mon, 25 Mar 2002 11:46:47 +0100
Message-Id: <[e-mail]>
From: "Stefan Kelm" <[e-mail]>
Organization: Secorvo Security Consulting GmbH
To: [e-mail]
Date: Mon, 25 Mar 2002 11:42:54 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: draft PKIX meeting minutes
Reply-to: [e-mail]
In-reply-to: <p0510030ab8bfc641e2c0@[166.63.186.31]>
X-mailer: Pegasus Mail for Win32 (v3.12b)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

> Document Status Overview
> 	The PKIX Working Group has twenty eight current I-Ds.  Three
> I-Ds (Certificate Profile, Public Key Algorithms, and Attribute
> Certificate Profile) are in the RFC editors queue for standards track.
> Three specifications are in WG Last Call (DPD/DPV Requirements, the
> Roadmap and CP/CPS Framework).  All three are projected as Informational
> RFCs.  OCSP and the results of interoperability testing have been
> forwarded to the ADs for consideration for Draft.  Two additional I-Ds

I haven't been able to find anything in the archive: have the
results of interop testing been published anywhere yet?

Cheers,

	Stefan.

-------------------------------------------------------
Dipl.-Inform. Stefan Kelm
Security Consultant

Secorvo Security Consulting GmbH
Albert-Nestler-Strasse 9, D-76131 Karlsruhe

Tel. [phone], Fax [phone]
E-Mail [e-mail], http://www.secorvo.de
-------------------------------------------------------
PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2MD8Ea00438 for ietf-pkix-bks; Fri, 22 Mar 2002 05:08:14 -0800 (PST)
Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2MD8C400434 for <[e-mail]>; Fri, 22 Mar 2002 05:08:13 -0800 (PST)
Received: from fwd01.sul.t-online.de  by mailout01.sul.t-online.com with smtp  id 16oOm7-0003Ba-03; Fri, 22 Mar 2002 14:08:07 +0100
Received: from junker.stroeder.com (520010731148-0001@[217.1.21.74]) by fmrl01.sul.t-online.com with esmtp id 16oOlz-1qn5ouC; Fri, 22 Mar 2002 14:07:59 +0100
Received: from stroeder.com (junker [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id D97D0157287; Fri, 22 Mar 2002 14:07:57 +0100 (CET)
Message-ID: <[e-mail]>
Date: Fri, 22 Mar 2002 14:07:57 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
Reply-To: [e-mail]
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020310
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: Vesa Suontama <[e-mail]>
Cc: [e-mail]
Subject: Re: OCKID - question about the format
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
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>

Vesa Suontama wrote:
 >
 > Just one comment about OCKID draft. I think the idea is good: There
 > should be a standard way to represent the hash of the PKI objects.

I concur.

 > However, I do not like the idea of using the base32 conversion in
 > converting the binary to ASCII. Numerous programs already out there just
 > use the hex presentation of the SHA-1 hash. See for example, MS
 > certificate viewer in Windows, Netscape, SSH Sentinel, etc.
 >
 > I suggest that the OCKID would also use the plain HEX representation of
 > the SHA-1 hash. This would make the ID's provided by the programs
 > already out there compatible with OCKID.

I strongly agree. I would additionally like to provide the MD5 hash of the 
certificates (like Netscape does). Maybe with a prefix describing the hash 
algorithm.

SHA1-CC48-7D7A A622-8613-E997

Ciao, Michael.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2LJg9d28813 for ietf-pkix-bks; Thu, 21 Mar 2002 11:42:09 -0800 (PST)
Received: from geos.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2LJg8428805 for <[e-mail]>; Thu, 21 Mar 2002 11:42:08 -0800 (PST)
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 g2LJg7P06136; Thu, 21 Mar 2002 11:42:07 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, <[e-mail]>
Subject: RE: draft PKIX meeting minutes
Date: Thu, 21 Mar 2002 11:39:29 -0800
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: <p0510030ab8bfc641e2c0@[166.63.186.31]>
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>

Steve, Denis:

Wish I could've been there.  The minutes seem to suggest a
transition to a binary yes/no design vs. the trinary
yes/no/unknown approach resolved on the list.  Am I misreading
the minutes?

Mike


DPV/DPD Requirements Status - Denis Pinkas (Integris)
. . . only yes or no returned, with status code for no.




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2LHOq120889 for ietf-pkix-bks; Thu, 21 Mar 2002 09:24:52 -0800 (PST)
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 g2LHOo420885 for <[e-mail]>; Thu, 21 Mar 2002 09:24:50 -0800 (PST)
Received: from [166.63.186.31] (SSH.BBN.COM [192.1.50.70]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA09782 for <[e-mail]>; Thu, 21 Mar 2002 12:24:46 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@127.0.0.1
Message-Id: <p0510030ab8bfc641e2c0@[166.63.186.31]>
Date: Thu, 21 Mar 2002 12:19:14 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: draft PKIX meeting minutes
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>

PKIX WG Meeting 12/11/01

Edited by Steve Kent

Chairs: Stephen Kent <[e-mail]>, Tim Polk <[e-mail]>

The PKIX WG met once during the 53nd IETF. A total of approximately 145
individuals participated in the meeting. All presentations were
accompanied by slides, copies of which will be posted along with
these minutes.


Tim Polk began with a review of the agenda. Two brief presentations
on non-working group IDs were added to the end, if time permits.

Document Status Overview
	The PKIX Working Group has twenty eight current I-Ds.  Three
I-Ds (Certificate Profile, Public Key Algorithms, and Attribute
Certificate Profile) are in the RFC editors queue for standards track.
Three specifications are in WG Last Call (DPD/DPV Requirements, the
Roadmap and CP/CPS Framework).  All three are projected as Informational
RFCs.  OCSP and the results of interoperability testing have been
forwarded to the ADs for consideration for Draft.  Two additional I-Ds
(CMP and CRMF) are ready to progress to Draft, but Tim Polk and Bob
Moskowitz need to document the CMP/CRMF interoperability testing.
Three CMC specifications (Structure, Transport, and Compliance)
are projected to reach WG Last Call before Yokohama.

       Progression of the PKIX LDAPv3 Schema has been identified as
a priority by the LDAP (v3) Revision working group.  They have requested
that the scope of the PKIX schema document be expanded to include key
information from LDAP v2 documnets that are slated to move to historic
later this year.  The editor has agreed to add the information and
hopes to complete the document before Yokohoma.  This timeline satisfies
the LDAP (v3) Revision WG requirements.

      The Supplemental Public Key Algorithms specification is currently on
hold.  NIST has not published the extended DSA to specify key sizes greater
than 1024 bits.  OIDs have not been assigned for signature algorithms using
SHA-256, SHA-384, or SHA-512.  Finally, the WG chairs have asked the area
directors for guidance on the suitability of lattice-based algorithms for
the Internet PKI.  As these issues are resolved, that document will be
pursued actively again.

DPV/DPD Requirements Status - Denis Pinkas (Integris)
	WG last call now completed. 25+ comments, all being addressed
in revisions underway. Major issues resolved: moved Policy Definition
Requirements (PDP) section to another document, removed "cautionary
period" text, made various changes to remove text that specifies
mechanisms as opposed to requirements, retained mandatory policy
reference but also allows policy parameters to be passed in the
request, only yes or no returned, with status code for no.

SCVP - Ambarish Malpani (ValiCert)
	Incorporating changes based on received comments and will
make changes to match changes in requirements spec. several other
minor changes. A new version will be issued too.

OCSP Update - Ambarish Malpani (ValiCert)
	Interoperability testing done to satisfy progression
requirements. A number of minor clarifications have been made as part
of the progression revisions, as well as a change to make RSA (vs.
DSA) mandatory.

ACRMF & ACMC - Peter Yee (RSA)
	New drafts (issued after SLC meeting) that address attribute
certificate management requirements, i.e., paralleling CRMF and CMC.
ACMC added features to CMC to accommodate ACs. CRMF required fewer
changes to accommodate ACs.

OCKID - Paul Hoffman (IMC/VPNC)
	This new ID specifies a format for human readable data,
distributed out of band, to be used to verify self-signed
certificates or raw keys. It can be used in many contexts to help
distribute trust anchors, OCSP responder credentials, etc. the value
is a 100-bit truncated SHA-1 hash. The spec calls for validation of
the certificate contents vs. the specification of the certificate
type as indicated by the user. This is a possible IPR issue here, a
possible Entrust patent from the WAP Forum. Carlisle Adams will
investigate and report to the mailing list.

Policy Requirements for TSAs - Denis Pinkas (Integris)
	This document is from ETSI and is proposed for publication as
an Informational RFC. It describes various security policies and
procedures for operation of a TSA.

TSP Interoperability Testing - Denis Pinkas (Integris)
	Collection of data from many folks testing TSP client and
server implementations, in support of progression of the TSP RFC
(3161). Note that what is needed here is not just anecdotal evidence
of interoperability, but rather a detailed testing of all the
mandatory features (MUSTS and SHOULDS), including error conditions
resulting from malformed requests and responses.

Permanent Identifiers - Denis Pinkas (Integris)
	Now at version 3, with a number of changes from the previous
drafts, based on extensive, recent discussions on the list. The draft
specifies the format for a new alternative name type (OtherName). The
PI consists of two components: the ID for the owner of the ID space,
and then the ID itself. Presentation explains how the PI is different
from serialNumber and subjectUniqueID attributes.

Proxy Certificates - Steve Tuecke (ANL)
	Motivation for proxy certificates is to name and authenticate
entities that are acting on behalf of users, so as to use this
authenticated name as an input to an access control procedure. Proxy
certificates solves this problem by creating a name for the proxy
that is derived from the user's name, and a means of expressing
limitations on the proxy's access.  Problem is that the proposed
extension would require a change to the validation procedure, and
that would constitute a significant change to the existing standard
and introduce added complexity for all compliant implementations.
Alternatives more recently explored include having users acts as CAs
to issue appropriate certificates, use of ACs, etc.

Logotypes - Stefan Santesson (AddTrust)
	Russ Housley and Trevor Freeman added to editorial team.
Second draft now online. Proposal calls for a new extension that can
represent 3 styles of logotype: issuer organization, subject
organization, and shared community.  Logotype represented by a hash
and URI, pointing to a graphic. Other options being explored include
use in ACs, option for in certificate storage of a reduced resolution
image, standards for image size and format.

RFC 3039 (QC) Updates - Stefan Santesson (AddTrust)
	Will clarify scope of document, also allow use of DS bit with
NR bit in KeyUsage, etc. Relationship to PI work should be explored
as these changes to the QC document are examined.


Non-PKIX Items

Using DNS for X.509 Certificate Storage- Jakob Schlyter (Carlstedt R&T)
	Focus on publishing CA certificates in DNS in CERT record.
Use issuerAltName to lookup in DNS. Use DNSSEC to verify self-signed
certificates. For non-self signed certificates, this is just a
repository proposal, analogous to what was proposed earlier. Will
require examination to determine how this attempt to bridge between
DNSSEC and PKI. Not clear what status is appropriate for this, and
how we should coordinate with DNSSEC WG.

LDAP v3 Schema for X.509 Certificates - Peter Gietz
	Goal of this work is to address limitations associated with
applications dealing with multi-valued PKI attributes in LDAP. The
proposal creates an additional tier of directory entries with
(searchable) attributes that allow existing LDAP clients to search
for and retrieve the "right" certificate. This document defines the
schema for such entries.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2LGWi918080 for ietf-pkix-bks; Thu, 21 Mar 2002 08:32:44 -0800 (PST)
Received: from emerald.lightlink.com (emerald.lightlink.com [205.232.34.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2LGWh418076 for <[e-mail]>; Thu, 21 Mar 2002 08:32:43 -0800 (PST)
Received: from [209.216.70.29] (perm70-29.ij.net [209.216.70.29] (may be forged)) by emerald.lightlink.com (8.8.8/8.8.8) with SMTP id LAA13272; Thu, 21 Mar 2002 11:32:23 -0500
From: "Christopher S. Francis" <[e-mail]>
To: "Sharon Boeyen" <[e-mail]>, "'Peter Williams'" <[e-mail]>, "'Denis Pinkas'" <[e-mail]>
Cc: <[e-mail]>
Received: from no.name.available by [209.216.70.29] via smtpd (for smtp.lightlink.com [205.232.34.14]) with SMTP; 21 Mar 2002 16:38:54 UT
Subject: RE: Attribute Certificates and Privilege Policy
Date: Thu, 21 Mar 2002 11:32:23 -0500
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_004B_01C1D0CC.11E79520"
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 V6.00.2600.0000
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>

This is a multi-part message in MIME format.

------=_NextPart_000_004B_01C1D0CC.11E79520
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Sharon,
=20
I=92m confused about why you are tying the need for an attribute =
authority to issue certificates under more than one =91attribute =
certificate policy=92 to cross certification.
=20
It=92s simple matter of allowing a single AA to issue certificates under =
more than one policy, depending on the level of verification they =
perform with respect to the asserted attributes.  It may not make a =
whole lot of sense to operate that way if the attributes being asserted =
are for clearance authorizations, but as I understand it, attribute =
certificates as supposed to be more generic than that.  If I=92m wrong =
about that, please tell me.
=20
Consider the following hypothetical:
A laboratory that calibrates test equipment decides to embrace PKI/PMI =
technology and become an attribute authority.  Instead of putting a =
sticker on the side of the devices they calibrate, they issue an =
attribute certificate.  The =93authorization=94 being granted by the =
attribute certificate is the authorization for the device to operate =
during the period specified by the AC=92s validity period. =20
=20
In this scenario, it seems reasonable that the calibration lab may want =
to offer a few different levels of calibration services, depending on =
the level of testing they perform to calibrate the device.  They might, =
for example, require that devices used for medical/life support =
applications go through a more rigorous calibration procedure.  Maybe =
they want to have different liability levels associated with the =
different types of calibration.
=20
It seems reasonable that the calibration lab (the AA) may want to issue =
different kinds of calibration stickers (the ACs) based on the type of =
calibration that was performed so it can only be held accountable for =
meeting the applicable calibration standards.
=20
In this context, it seems reasonable that the AA may want to issue ACs =
under different policies and provide something in the AC that indicates =
the specific policy under which it was issued.
=20
There=92s no cross certification involved here.
=20
Chris
=20
-----Original Message-----
From: [e-mail] =
[mailto:[e-mail]]On Behalf Of Sharon Boeyen
Sent: Wednesday, March 20, 2002 9:32 AM
To: 'Peter Williams'; 'Denis Pinkas'
Cc: '[e-mail]'
Subject: RE: Attribute Certificates and Privilege Policy
=20
Just a couple of points to add:=20
The 509 PMI framework does not have any equivalent to=20
cross-certification defined (it was included in early drafts=20
but dropped from the spec prior to approval). The model is=20
really addressing environments where the SOA and the verifier=20
are in the same "security domain" and does not really address=20
any cross-domain issues. Verifiers are expected to be configured=20
with a trusted copy of their SOA public key as they are today for=20
trust anchors in PMI. The verifier trusts the SOA as the ultimate=20
source of authority for a set of privileges. =20
If there are requirements to enhance the 509 model, those=20
requirements can certainly be submitted to the 509 work by PKIX.=20
>From a process standpoint there is no problem, the liaisons=20
already exist and we've worked successfully on other topics=20
through this channel, regardless of who agrees or disagrees with the=20
specific topic.=20
>From my own personal standpoint, I'm not yet convinced of the =
requirement.=20
the arguments seem to be that we need it for PMI because we use it for =
PKI or=20
we need it to cover liability issues. The liability issue seems much =
less=20
convincing when you recognize that the 509 PMI model does NOT include =
any=20
inter-domain cross-certification equivalent. Documenting your own =
liability=20
for internal applications isn't very interesting.=20
 =20
Sharon =20
 =20

------=_NextPart_000_004B_01C1D0CC.11E79520
Content-Type: text/html;
	charset="iso-8859-1"
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=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 9">
<meta name=3DOriginator content=3D"Microsoft Word 9">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C1D0CC.10839850">
<title>RE: Attribute Certificates and Privilege Policy</title>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
@font-face
	{font-family:"Comic Sans MS";
	panose-1:3 15 7 2 3 3 2 2 2 4;
	mso-font-charset:0;
	mso-generic-font-family:script;
	mso-font-pitch:variable;
	mso-font-signature:647 0 0 0 159 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;}
 /* 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:"Times New Roman";}
h1
	{mso-style-next:Normal;
	margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:1;
	font-size:16.0pt;
	font-family:Arial;
	mso-font-kerning:16.0pt;
	font-weight:bold;}
p.MsoBodyText, li.MsoBodyText, div.MsoBodyText
	{margin-top:13.2pt;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:1.0in;
	margin-bottom:.0001pt;
	line-height:120%;
	mso-pagination:widow-orphan;
	font-size:11.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-font-kerning:11.0pt;}
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.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p
	{margin-right:0in;
	mso-margin-top-alt:auto;
	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:"Times New Roman";}
p.Heading1NoTOC, li.Heading1NoTOC, div.Heading1NoTOC
	{mso-style-name:"Heading 1 No TOC";
	mso-style-parent:"Heading 1";
	margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	text-align:center;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:1;
	font-size:14.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	mso-font-kerning:14.0pt;
	font-weight:bold;
	mso-bidi-font-weight:normal;}
p.TableText, li.TableText, div.TableText
	{mso-style-name:"Table Text";
	margin-top:3.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	line-height:110%;
	mso-pagination:widow-orphan lines-together;
	font-size:10.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-font-kerning:10.0pt;}
p.TableTextTitle, li.TableTextTitle, div.TableTextTitle
	{mso-style-name:"Table Text Title";
	mso-style-parent:"Table Text";
	margin-top:3.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	line-height:110%;
	mso-pagination:widow-orphan lines-together;
	font-size:10.0pt;
	font-family:Arial;
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	mso-font-kerning:10.0pt;
	font-weight:bold;
	mso-bidi-font-weight:normal;}
span.EmailStyle22
	{mso-style-type:personal-reply;
	mso-ansi-font-size:12.0pt;
	mso-ascii-font-family:"Comic Sans MS";
	mso-hansi-font-family:"Comic Sans MS";
	mso-bidi-font-family:Arial;
	color:navy;}
span.EmailStyle24
	{mso-style-type:personal;
	mso-ansi-font-size:12.0pt;
	mso-ascii-font-family:"Comic Sans MS";
	mso-hansi-font-family:"Comic Sans MS";
	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>
</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><span class=3DEmailStyle22><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans =
MS"'>Sharon,<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle22><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle22><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>I&#8217;m
confused about why you are tying the need for an attribute authority to =
issue
certificates under more than one &#8216;attribute certificate =
policy&#8217; to cross
certification.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle22><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle22><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>It&#8217;s
simple matter of allowing a single AA to issue certificates under more =
than one
policy, depending on the level of verification they perform with respect =
to the
asserted attributes.<span style=3D"mso-spacerun: yes">&nbsp; </span>It =
may not
make a whole lot of sense to operate that way if the attributes being =
asserted
are for clearance authorizations, but as I understand it, attribute
certificates as supposed to be more generic than that. <span
style=3D"mso-spacerun: yes">&nbsp;</span>If I&#8217;m wrong about that, =
please tell me.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle22><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle22><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>Consider
the following hypothetical:<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle24><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>A
laboratory that calibrates test equipment decides to embrace PKI/PMI =
technology
and become an attribute authority.<span style=3D"mso-spacerun: =
yes">&nbsp;
</span>Instead of putting a sticker on the side of the devices they =
calibrate,
they issue an attribute certificate.<span style=3D"mso-spacerun: =
yes">&nbsp;
</span>The &#8220;authorization&#8221; being granted by the attribute =
certificate is the
authorization for the device to operate during the period specified by =
the AC&#8217;s
validity period.<span style=3D"mso-spacerun: yes">&nbsp; =
</span><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle24><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle24><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>In
this scenario, it seems reasonable that the calibration lab may want to =
offer a
few different levels of calibration services, depending on the level of =
testing
they perform to calibrate the device.<span style=3D"mso-spacerun: =
yes">&nbsp;
</span>They might, for example, require that devices used for =
medical/life
support applications go through a more rigorous calibration =
procedure.<span
style=3D"mso-spacerun: yes">&nbsp; </span>Maybe they want to have =
different
liability levels associated with the different types of =
calibration.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle24><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle24><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>It
seems reasonable that the calibration lab (the AA) may want to issue =
different
kinds of calibration stickers (the ACs) based on the type of calibration =
that
was performed so it can only be held accountable for meeting the =
applicable
calibration standards.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle24><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle24><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>In
this context, it seems reasonable that the AA may want to issue ACs =
under
different policies and provide something in the AC that indicates the =
specific
policy under which it was issued.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle24><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle24><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>There&#8217;s
no cross certification involved =
here.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle24><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle24><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans =
MS"'>Chris<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle22><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dblack
face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[e-mail]
[mailto:[e-mail]]<b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Sharon Boeyen<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, March =
20, 2002
9:32 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Peter Williams'; =
'Denis
Pinkas'<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> =
'[e-mail]'<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Attribute
Certificates and Privilege Policy</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'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack face=3D"Times =
New Roman"><span
style=3D'font-size:10.0pt;color:black'>Just a couple of points to =
add:</span></font><font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack face=3D"Times =
New Roman"><span
style=3D'font-size:10.0pt;color:black'>The 509 PMI framework does not =
have any
equivalent to </span></font><font color=3Dblack><span =
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>cross-certification defined (it was included in early =
drafts</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>but dropped from the spec prior to approval). The model is =
</span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>really addressing environments where the SOA and the =
verifier</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>are in the same &quot;security domain&quot; and does not =
really
address</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>any cross-domain issues. Verifiers are expected to be =
configured </span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>with a trusted copy of their SOA public key as they are =
today for </span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>trust anchors in PMI. The verifier trusts the SOA as the =
ultimate</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>source of authority for a set of privileges.&nbsp; =
</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack face=3D"Times =
New Roman"><span
style=3D'font-size:10.0pt;color:black'>If there are requirements to =
enhance the
509 model, those</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>requirements can certainly be submitted to the 509 work by =
PKIX.</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>From a process standpoint there is no problem, the liaisons =
</span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>already exist and we've worked successfully on other topics =
</span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>through this channel, regardless of who agrees or disagrees =
with
the </span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>specific topic. </span></font><font color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack face=3D"Times =
New Roman"><span
style=3D'font-size:10.0pt;color:black'>From my own personal standpoint, =
I'm not
yet convinced of the requirement.</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>the arguments seem to be that we need it for PMI because we =
use it
for PKI or</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>we need it to cover liability issues. The liability issue =
seems
much less</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>convincing when you recognize that the 509 PMI model does =
NOT
include any </span></font><font color=3Dblack><span =
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>inter-domain cross-certification equivalent. Documenting =
your own
liability </span></font><font color=3Dblack><span =
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>for internal applications isn't very interesting. =
</span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Sharon&nbsp; </span></font><font color=3Dblack><span
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;</span></font><font color=3Dblack><span =
style=3D'color:black'> </span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

</div>

</body>

</html>

------=_NextPart_000_004B_01C1D0CC.11E79520--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2KNOHJ14124 for ietf-pkix-bks; Wed, 20 Mar 2002 15:24:17 -0800 (PST)
Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2KNOF414119 for <[e-mail]>; Wed, 20 Mar 2002 15:24:16 -0800 (PST)
Received: from user-2ivf0sb.dialup.mindspring.com ([165.247.131.139] helo=asn-1.com) by blount.mail.mindspring.net with esmtp (Exim 3.33 #1) id 16npR9-0003eN-00; Wed, 20 Mar 2002 18:24:08 -0500
Message-ID: <[e-mail]>
Date: Wed, 20 Mar 2002 18:21:02 -0500
From: Phil Griffin <[e-mail]>
Organization: Griffin Consulting - http://ASN-1.com
X-Mailer: Mozilla 4.73 [en]C-{C-UDP; EBM-SONY1}  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Sharon Boeyen <[e-mail]>
CC: "pkix (E-mail)" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "Hoyt Kesterson (E-mail)" <[e-mail]>, asn1 dev <[e-mail]>, Herb Bertine <[e-mail]>
Subject: Re: 509 Feb/Mar Meeting Summary
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>

> Sharon Boeyen wrote:
> 
> During the recent 509 meeting we addressed the comments received on
> the Working Document on new
> X.509 enhancements, the ballot results on defect resolutions and new
> defect reports.
> The revised WD on 509 enhancements and the defect related documents
> will be available
> shortly from the ftp site maintained by Hoyt Kesterson (he'll send an
> email when they're
> all there). If anyone needs a copy of these in advance of that, please
> let me know. Here is
> a brief summary of the agreements made at the meeting.
> 
> The technical changes to the WD as a result of this meeting are:
> - Issue 6 - the syntax of xmlPrivilegeInfo was changed from OCTET
> STRING to UTF8String

This piece still needs work, as it fails to address
business needs of the ASN.1 XER using community, and
seems to wish to endorse OASIS SAML, a piece of work
not even recognized internationally and based on the
W3C XSD schema, which I've been told by OASIS is 
being harmonized along with many of the other XML
schema contenders into a (if you will) meta schema.

Why Directory leaps out to endorse this schema notation
while it ignores the ASN.1 XML schema is beyond my
comprehension. Just this week, OASIS UBL agreed to
support ASN.1 in its work, and ASN.1 is the primary
XML schema being used in OASIS XML Common Biometric
Format (XCBF), the proposed X9F3 X9.96 XML Cryptographic
Message Syntax, and is being considered for inclusion
in the Time Stamping standard being progressed though
JTC1. SC27.

Phil



> - Issue 13 - the SOA constraint extension was deleted. In its place is
> a new issue on SOA identifier and
>   cross-certification
> - Issue 14 - The old issue regarding multiple roles was deleted. In
> its place is a new issue that defines
>   an attribute and object class for storing privilege policy within
> attribute certificates.
> - Issue 15 - new revocation reason codes. Two earlier proposals (cert
> issued
>   in error and change of revocation reason) will not have new reason
> codes added, but instead
>   additional text was added to clarify how to signal these. Also a new
> question was added to this
>   issue regarding the potential need for a new code to indicate that
> an algorithm is expected to
>   be weak and therefore future revocation of a cert is anticipated.
> - Issue 24 - a new issue added to deal with the general requirements
> to handle addition of
>   new reason codes.
> Issue 25 - a new informative annex regarding client side settings for
> policy for path validation
>   (note this one is related to DR 289)
> 
> In terms of Defect Reports (DR) and Draft Technical Corrigenda (DTC)
> ballots:
> DTC 4 against 4th edition (DR 284,285 & 286) was approved and will be
> published as TC 2
> DTC 11 against 3rd edition (DR 285) was approved and will be published
> as TC 4
> 
> DTC 3 against 4th edition (DR 280, 281 & 282) was revised based on
> ballot comments and
>           will be re-ballotted because of the significant amount of
> change
> 
> There is also a set of new defect reports that were discussed and
> resolutions for these will
> also be sent for ballot. The new DRs are:
> 
> DR 289 on path processing - re acceptable policies
> DR 291 on use of 'encipherment' term in definition of certificates
> DR 294 to replace the DER rules in X.509 with reference to ASN.1 DER
> DR 296 on default distribution points
> DR 297 on CRL issuance requirements
> DR 298 on partioned CRLs
> 
> Sharon
> 
> Sharon Boeyen
> Principal, Advanced Security
> Tel: [phone]
> www.entrust.com
> 
> Entrust, Inc.
> Securing the Internet


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2KISC003816 for ietf-pkix-bks; Wed, 20 Mar 2002 10:28:12 -0800 (PST)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2KISA403811 for <[e-mail]>; Wed, 20 Mar 2002 10:28:10 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <HJ87JAMB>; Wed, 20 Mar 2002 13:27:57 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "pkix (E-mail)" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "Hoyt Kesterson (E-mail)" <[e-mail]>
Subject: 509 Feb/Mar Meeting Summary
Date: Wed, 20 Mar 2002 13:27:56 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D03C.F4CF3540"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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_01C1D03C.F4CF3540
Content-Type: text/plain;
	charset="iso-8859-1"

During the recent 509 meeting we addressed the comments received on the
Working Document on new
X.509 enhancements, the ballot results on defect resolutions and new defect
reports. 
The revised WD on 509 enhancements and the defect related documents will be
available 
shortly from the ftp site maintained by Hoyt Kesterson (he'll send an email
when they're 
all there). If anyone needs a copy of these in advance of that, please let
me know. Here is 
a brief summary of the agreements made at the meeting. 

The technical changes to the WD as a result of this meeting are:
- Issue 6 - the syntax of xmlPrivilegeInfo was changed from OCTET STRING to
UTF8String
- Issue 13 - the SOA constraint extension was deleted. In its place is a new
issue on SOA identifier and 
  cross-certification 
- Issue 14 - The old issue regarding multiple roles was deleted. In its
place is a new issue that defines
  an attribute and object class for storing privilege policy within
attribute certificates.
- Issue 15 - new revocation reason codes. Two earlier proposals (cert issued

  in error and change of revocation reason) will not have new reason codes
added, but instead 
  additional text was added to clarify how to signal these. Also a new
question was added to this 
  issue regarding the potential need for a new code to indicate that an
algorithm is expected to 
  be weak and therefore future revocation of a cert is anticipated.
- Issue 24 - a new issue added to deal with the general requirements to
handle addition of 
  new reason codes. 
Issue 25 - a new informative annex regarding client side settings for policy
for path validation
  (note this one is related to DR 289)

In terms of Defect Reports (DR) and Draft Technical Corrigenda (DTC)
ballots:
DTC 4 against 4th edition (DR 284,285 & 286) was approved and will be
published as TC 2
DTC 11 against 3rd edition (DR 285) was approved and will be published as TC
4

DTC 3 against 4th edition (DR 280, 281 & 282) was revised based on ballot
comments and 
          will be re-ballotted because of the significant amount of change

There is also a set of new defect reports that were discussed and
resolutions for these will 
also be sent for ballot. The new DRs are:

DR 289 on path processing - re acceptable policies
DR 291 on use of 'encipherment' term in definition of certificates
DR 294 to replace the DER rules in X.509 with reference to ASN.1 DER
DR 296 on default distribution points
DR 297 on CRL issuance requirements
DR 298 on partioned CRLs 

Sharon

Sharon Boeyen
Principal, Advanced Security
Tel: [phone] 
www.entrust.com

Entrust, Inc.
Securing the Internet



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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>509 Feb/Mar Meeting Summary</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">During the recent 509 meeting we =
addressed the comments received on the Working Document on new</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">X.509 enhancements, the ballot =
results on defect resolutions and new defect reports. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">The revised WD on 509 enhancements =
and the defect related documents will be available </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">shortly from the ftp site maintained =
by Hoyt Kesterson (he'll send an email when they're </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">all there). If anyone needs a copy of =
these in advance of that, please let me know. Here is </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">a brief summary of the agreements =
made at the meeting. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The technical changes to the WD as a =
result of this meeting are:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">- Issue 6 - the syntax of =
xmlPrivilegeInfo was changed from OCTET STRING to UTF8String</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">- Issue 13 - the SOA constraint =
extension was deleted. In its place is a new issue on SOA identifier =
and </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; cross-certification </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">- Issue 14 - The old issue regarding =
multiple roles was deleted. In its place is a new issue that =
defines</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; an attribute and object class =
for storing privilege policy within attribute certificates.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">- Issue 15 - new revocation reason =
codes. Two earlier proposals (cert issued </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; in error and change of =
revocation reason) will not have new reason codes added, but instead =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; additional text was added to =
clarify how to signal these. Also a new question was added to this =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; issue regarding the potential =
need for a new code to indicate that an algorithm is expected to =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; be weak and therefore future =
revocation of a cert is anticipated.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">- Issue 24 - a new issue added to =
deal with the general requirements to handle addition of </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; new reason codes. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Issue 25 - a new informative annex =
regarding client side settings for policy for path validation</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; (note this one is related to =
DR 289)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In terms of Defect Reports (DR) and =
Draft Technical Corrigenda (DTC) ballots:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">DTC 4 against 4th edition (DR 284,285 =
&amp; 286) was approved and will be published as TC 2</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">DTC 11 against 3rd edition (DR 285) =
was approved and will be published as TC 4</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">DTC 3 against 4th edition (DR 280, 281 =
&amp; 282) was revised based on ballot comments and </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
will be re-ballotted because of the significant amount of change</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">There is also a set of new defect =
reports that were discussed and resolutions for these will </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">also be sent for ballot. The new DRs =
are:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">DR 289 on path processing - re =
acceptable policies</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">DR 291 on use of 'encipherment' term =
in definition of certificates</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">DR 294 to replace the DER rules in =
X.509 with reference to ASN.1 DER</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">DR 296 on default distribution =
points</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">DR 297 on CRL issuance =
requirements</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">DR 298 on partioned CRLs </FONT>
</P>

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

<P><FONT SIZE=3D2 FACE=3D"Courier New">Sharon Boeyen</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Principal, Advanced =
Security</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Tel: [phone] </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">www.entrust.com</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Entrust, Inc.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Securing the Internet</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C1D03C.F4CF3540--


Received: by above.proper.com (8.11.6/8.11.3) id g2KGhso22410 for ietf-pkix-bks; Wed, 20 Mar 2002 08:43:54 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2KGhq422401 for <[e-mail]>; Wed, 20 Mar 2002 08:43:52 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA06648; Wed, 20 Mar 2002 17:43:51 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 20 Mar 2002 17:43:51 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id RAA21131; Wed, 20 Mar 2002 17:43:50 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA28284; Wed, 20 Mar 2002 17:43:50 +0100 (MET)
Date: Wed, 20 Mar 2002 17:43:50 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: WG Last Call: Roadmap
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The text contains:

" At the Minneapolis IETF meeting, it was disclosed that the materials "

It would be nice to indicate the meeting number. 


Received: by above.proper.com (8.11.6/8.11.3) id g2KGY6o20094 for ietf-pkix-bks; Wed, 20 Mar 2002 08:34:06 -0800 (PST)
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 g2KGY5420081 for <[e-mail]>; Wed, 20 Mar 2002 08:34:05 -0800 (PST)
Received: from [166.63.186.188] (SSH.BBN.COM [192.1.50.70]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA14665; Wed, 20 Mar 2002 11:33:47 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@127.0.0.1
Message-Id: <p05100303b8be5427c6a2@[166.63.186.168]>
In-Reply-To: <03e501c1cf98$7ab622e0$020aff0c@tsg1>
References: <[e-mail]> <005c01c1ce80$22054130$020aff0c@tsg1> <p05100300b8bbc109bd96@[128.33.238.54]> <02e801c1ced4$d1f24a30$020aff0c@tsg1> <p05100309b8bd4f95e09d@[166.63.186.168]> <03e501c1cf98$7ab622e0$020aff0c@tsg1>
Date: Wed, 20 Mar 2002 11:32:00 -0500
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: DPD/DPV reqmts strawpoll
Cc: "Peter Sylvester" <[e-mail]>, <[e-mail]>, <[e-mail]>, "vint cerf" <[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>

At 2:50 PM -0800 3/19/02, todd glassey wrote:
>Steve if you cannot take the heat as the chair of the WG then you are in
>the wrong job.
>
>Todd
>

I do tolerate your messages, but most of them waste time and 
contribute nothing to the WG activity. I and many other WG members 
object to that.

Steve


Received: by above.proper.com (8.11.6/8.11.3) id g2KElii08100 for ietf-pkix-bks; Wed, 20 Mar 2002 06:47:44 -0800 (PST)
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 g2KElg408094 for <[e-mail]>; Wed, 20 Mar 2002 06:47:42 -0800 (PST)
Received: from email.nist.gov (localhost [127.0.0.1]) by email.nist.gov (8.12.2/8.12.2) with ESMTP id g2KElgm3026234 for <[e-mail]>; Wed, 20 Mar 2002 09:47:42 -0500 (EST)
Received: (from nobody@localhost) by email.nist.gov (8.12.2/8.12.2/Submit) id g2KElg5w026232 for [e-mail]; Wed, 20 Mar 2002 09:47:42 -0500 (EST)
X-Authentication-Warning: email.nist.gov: nobody set sender to [e-mail] using -f
To: [e-mail]
Subject: WG Last Call: CP and CPS Framework
Message-ID: <[e-mail]>
Date: Wed, 20 Mar 2002 09:47:42 -0500 (EST)
From: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.6
X-Originating-IP: 166.63.190.92
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message initiates a two week Working Group Last Call for "Internet X.509 
Public Key Infrastructure Certificate Policy and Certification Practices 
Framework". The document is available at

http://www.ietf.org/internet-drafts/draft-ietf-pkix-ipki-new-rfc2527-01.txt

Assuming successful completion of Last Call, the document will be forwarded for 
consideration as an Informational track RFC.  The document will obsolete RFC 
2527.


Received: by above.proper.com (8.11.6/8.11.3) id g2KEkpU08068 for ietf-pkix-bks; Wed, 20 Mar 2002 06:46:51 -0800 (PST)
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 g2KEkn408063 for <[e-mail]>; Wed, 20 Mar 2002 06:46:49 -0800 (PST)
Received: from email.nist.gov (localhost [127.0.0.1]) by email.nist.gov (8.12.2/8.12.2) with ESMTP id g2KEkkm3025300 for <[e-mail]>; Wed, 20 Mar 2002 09:46:46 -0500 (EST)
Received: (from nobody@localhost) by email.nist.gov (8.12.2/8.12.2/Submit) id g2KEkkd0025298 for [e-mail]; Wed, 20 Mar 2002 09:46:46 -0500 (EST)
X-Authentication-Warning: email.nist.gov: nobody set sender to [e-mail] using -f
To: [e-mail]
Subject: WG Last Call: Roadmap
Message-ID: <[e-mail]>
Date: Wed, 20 Mar 2002 09:46:46 -0500 (EST)
From: [e-mail]
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.6
X-Originating-IP: 166.63.190.92
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message initiates a two week Working Group Last Call for "Internet X.509 
Public Key Infrastructure: Roadmap". The document is available at

     http://www.ietf.org/internet-drafts/draft-ietf-pkix-roadmap-07.txt

Assuming successful completion of Last Call, the document will be forwarded for 
consideration as an Informational track RFC.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2KEWfh05718 for ietf-pkix-bks; Wed, 20 Mar 2002 06:32:41 -0800 (PST)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2KEWd405710 for <[e-mail]>; Wed, 20 Mar 2002 06:32:40 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <HJ8726QF>; Wed, 20 Mar 2002 09:32:25 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Peter Williams'" <[e-mail]>, "'Denis Pinkas'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Attribute Certificates and Privilege Policy
Date: Wed, 20 Mar 2002 09:32:23 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D01C.0CFC0830"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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_01C1D01C.0CFC0830
Content-Type: text/plain

Just a couple of points to add:

The 509 PMI framework does not have any equivalent to 
cross-certification defined (it was included in early drafts
but dropped from the spec prior to approval). The model is 
really addressing environments where the SOA and the verifier
are in the same "security domain" and does not really address
any cross-domain issues. Verifiers are expected to be configured 
with a trusted copy of their SOA public key as they are today for 
trust anchors in PMI. The verifier trusts the SOA as the ultimate
source of authority for a set of privileges.  

If there are requirements to enhance the 509 model, those
requirements can certainly be submitted to the 509 work by PKIX.
>From a process standpoint there is no problem, the liaisons 
already exist and we've worked successfully on other topics 
through this channel, regardless of who agrees or disagrees with the 
specific topic. 

>From my own personal standpoint, I'm not yet convinced of the requirement.
the arguments seem to be that we need it for PMI because we use it for PKI
or
we need it to cover liability issues. The liability issue seems much less
convincing when you recognize that the 509 PMI model does NOT include any 
inter-domain cross-certification equivalent. Documenting your own liability 
for internal applications isn't very interesting. 
 
Sharon  
 

-----Original Message-----
From: Peter Williams [mailto:[e-mail]]
Sent: Friday, March 15, 2002 6:49 PM
To: 'Denis Pinkas'
Cc: '[e-mail]'
Subject: RE: Attribute Certificates and Privilege Policy



I dont see how privilege policy, as defined by ISO,
has any equivalency relation to validation policy - as
an architect speaking from a company that was
conceived to deploy and has deployed over a hundred 
operational validation servers and associated validation 
policies in the world - for probably every major PKI 
vendors' system, and probably 50% of all operational
commercial-grade PKIs!

Validation policies are the expression in some rule form
of the risk management controls a RP uses to *Accept*
a cert path, beyond the rules built into the simplistic path
processing algorithm specified by ISO for
trust chains *validation*; acceptance and validation
are very different processes, especially in well written
CPSs mapping technology onto law principles. ValiCert
must have built now 10 quite-different validation policys, for 
various military projects and banking groups.

Whilst ISO rules for PKI trust chain processing
properly arrange for inteoperability and navigation of trust 
domains (a valid ISO issue), validation policies address the 
risks applications face when PKI fails, PKI signals need to be 
ignored/overridden, redundacy of PKI chains, or PKI is used t
o assist privilege-based control systems - whose purposes fall outside
the scope of ISO PKI/PMI frameworks, or IETF profiles
thereof.

In practice, privilege policy is already deployed worldwide, in 
two forms. Java 2 enables
relying parties to sign and use an executable-form "AC", that limits
privilege acceptance for privileges asserted by loading-code, 
using privilege-policy rule expressions that are 
expressed as executable code, selected and downloaded by the 
target system. Microsoft  Win32 OS's TCB does something similar 
since 5  years ago, using other signalling 
and enforcement techniques, that leverages a little of the 
Authenticode standardization in 2459, and other
PKI-based techniques properly not addressed by PKIX.

Validation policies are, in contrast, all about validation of 
certificate chains, PKI and PMI varieties. AS we learned
from the authoritative editor of X.509, the ISO intended
that privilege policy enforcement has little or nothing
to do with AC delegation path processing, and nothing
whatsoever to do with PKI path processing. Validation
policies are exclusively associated with the PKI
and/or PMI chain processing.

I asked the question, is privilege policy enforcement
PART OF path processing. Sharon indicated that it
is not, though ISO wording and titling of X.509 sections
16.x.y could be improved. Hence validation policies
are not equivalent in basis to privilege policies.

AS privilege policy and validation policy do take
the perspective of relying parties, there 
is some limited consistency in that shared 
perspective, to be fair to Denis.

If ISO decide that, contrary to current intepretation
by the editor of the ISO position, that privilege
policy enforcement IS A PART OF path processing,
then we could possibly agree on there being
some equivalency basis. 

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Friday, March 15, 2002 9:50 AM
To: Sharon Boeyen
Cc: '[e-mail]'
Subject: Re: Attribute Certificates and Privilege Policy



Sharon,

Yes, this is indeed a very long e-mail. Mine will be shorter.

Shortly speaking, the "privilege policy" is the equivalent of a 
"validation policy" (see the DPV requ. draft availmable from 
http://www.imc.org/draft-ietf-pkix-dpv-dpd-req), but it is NOT 
the equivalent of a certification policy.

You said: "In terms of 'why no certificate policy' - there was no need
identified for an equivalent".

For CAs there are different levels of verification of the identity presented
at the time of registration. This level is "visible" through the certificate
policy.

I do not see why we should not draw a parallel with attributes, where for
AAs there would be different levels of verification of the attributes
presented at the time of registration. This level would be "visible" through
the "attribute policy".

A validation policy (i.e. privilege policy using the ISO terminology) may
consider that some attribute policies are adequate and that some others are
not.

Otherwise, the single way to trust is to use the name of the AA. 

If an AA supports different "attribute policies", it would have to change
its
name, each time. :-(

Thus I see a good reason to have an equivalent.

Regards,

Denis

> I'll try to address all the questions I've seen re the 509 aspects of this
> discussion. (Sorry this is rather long, but I found this
> 
> easier than trying to respond to each message).
> 
> I think Peter has identified at least one part of 509 that could benefit
> from some editorial clarification.
> 
> Clause 16 "Privilege path processing procedure" may be more appropriate
> titled "Privilege assertion processing procedure".
> 
> Each paragraph in 16.1 could probably use subtitles to clarify what's
> really going on. The paragraphs in this section are basically
> 
> a list of each of the checks that need to be done before an asserted
> privilege can be granted to a claimant.
> - Para 1 is doing a "validation" on each of the attribute certificates in
> the path. This is just checking the signatures, using the
> 
> PKI path validation steps as if you were checking the signature on a
> signed form - the details are in clause 10 of the PKI section.
> 
> - Para 2 is a check to ensure the claimant's willingness to use that
> attribute cert for the context - no standard steps for this
> 
> check are defined.
> - Para 3 is the revocation status check - no details req'd
> - Para 4 is the check for whether the asserted privilege is valid for the
> time of interest - no details req'd
> - Para 5 is checking any constraints imposed by the issuer of the AC on
> the set of permitted targets - no details req'd
> - Para 6 is the checks for roles and of delegation. Note that 16.2 is
> merely the details associated with the role check and
> 
> 16.3 is merely the details assoiated with the delegation check.
> - Para 7 is the privilege policy check against the asserted privilege
> together with the other inputs (target sensitivity,
> 
> environmental variables) and checking any constraints on privilege policy
> imposed by the issuer.
> 
> So this complete set of steps comprise the processing that needs to be
> done to assess a privilege assertion. Some of these
> relate to paths (Para 1 is processing of a public-key certification path
> to verify the signature on the attribute cert and
> Para 6 along with 16.3 is processing of a delegation path of attribute
> certificates to determine whether or not the delegation
> itself is authorized and valid. As part of the processing of a delegation
> path, note that the signature on EACH attribute
> certificate in the path needs to be verified, so again the public-key path
> validation is used for that purpose). I wanted to
> try to clarify this because asking if something is part of "path
> validation" is not as easy to answer as it would be if
> we were talking about PKI instead of PMI.
> 
> The privilege policy is the basis for determining the acceptance of an
> attribute certificate (at least from a policy perspective).
> 
> It is processed by a verifier as one of the steps in assessing a privilege
> assertion, but it is not strictly part of either
> public-key certification path processing done for signature verification
> or part of delegation path processing for verifying
> delegation.
> 
> Many aspects of privlege policy were not standardized in 509, including
> its syntax, who can write them etc, how does
> a verifier know which one to use etc. Some of these were deferred, e.g.
> syntax. Note however, that in OASIS, the XACML
> working group is now defining a standard XML syntax for access control
> policy. Some material from the sample syntaxes
> in the X.509 informative annex were input to the XACML work so folks
> interested in privilege policy may find that work
> interesting as well. As for how the verifier knows which privilege policy
> to use - that is left to the implementation. In
> some cases a target may always work with a single privilege policy and it
> may be created by the local SOA . There
> are hooks to tie privilege policies to attributes for which an SOA assigns
> privileges (the attributeDescriptor in 15.3.2.2 and
> there is also directory syntax to store them, but no standardized way for
> a verifier to determine which to use. However a local
> trusted SOA would obviously be one possible source of privilege policies.
> 
> Regarding the acceptablePrivilegePolicies extension, a verifier is always
> assessing a privilege assertion with respect to
> a specific privilege policy as per para 7 in 14.1. In the absence of the
> acceptablePrivilegePolicies extension, the verifier
> merely assess the assertion with respect to the privilege policy it is
> working with (out of band / local means for determining
> which privilege policy the verifier operates with - likely greatly
> determined by the target). If the acceptablePrivilegePolicies
> extension is present, then the verifier needs to check whether the
> privilege policy it is operating under is one of the ones
> listed as acceptable in that extension. If it is, then the verifier
> proceeds normally. If it is not, the verifier stops and the privilege
> asserter is not given access.
> 
> The privilege policy is the set of rules that determine acceptability of
> an asserted privilege. A primary difference between
> that and certificate policy is that certificate policy is tied to a
> certificate and defines acceptable uses for that certificate,
> while privilege policy is associated with a verifier and the target that
> is in question and determines which privilege assertions
> are appropriate. So, things like usage constraints, dollar limits, time
> constraints, name constraints - all those things would
> be appropriate for inclusion in a privilege policy. I'm not convinced
> about liability limits though, because privilegePolicy must
> be machine processable as it is processed dynamically at assertion
> assessment time. Liability limits don't seem like they
> would easily lend themselves to this.
> 
> In terms of 'why no certificate policy' - there was no need identified for
> an equivalent. A verifier trusts an SOA as the
> ultimate source of authority for assignment of a set of privileges. That's
> the authorization issue I mentioned earlier.
> 
> If delegation is done, then the checks for ensuring that is authorized are
> part of the delegation path processing
> procedure. If an AA (SOA or delegated AA) wishes to constrain the policy
> under which an AC is used, it can do
> so through the acceptablePrivilegePolicies extension. As for certificate
> policies, they are used when verifying the
> signature on the attribute certificates as well as when verifying the
> signature on any transaction associated with
> the specific assertion of privilege being made by the claimant. So
> certificate policies do factor into the overall
> validation for any given transaction, but are not part of the privilege
> assertion assessment.
> 
> I hope this addresses the questions that were raised by Denis, Chris and
> Peter - if not I'm sure you'll let me know :-).
> 
> In terms of 509 clarifications, if people think some defect work is needed
> there, please let me know.
> 
> FYI, I'm going to try to get all my editing tasks from the recent X.509
> meeting completed and provide a brief summary
> of the meeting to this list prior to the PKIX meeting. There are a couple
> of current issues we're working on with respect
> to SOAs that PMI folks might be interested in.
> 
> Again, apologies for the length of the message.
> Sharon
> 
> Sharon Boeyen
> Principal, Advanced Security
> Tel: [phone]
> www.entrust.com
> 
> Entrust, Inc.
> Securing the Internet

------_=_NextPart_001_01C1D01C.0CFC0830
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.2653.12">
<TITLE>RE: Attribute Certificates and Privilege Policy</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Just a couple of points to add:</FONT>
</P>

<P><FONT SIZE=2>The 509 PMI framework does not have any equivalent to </FONT>
<BR><FONT SIZE=2>cross-certification defined (it was included in early drafts</FONT>
<BR><FONT SIZE=2>but dropped from the spec prior to approval). The model is </FONT>
<BR><FONT SIZE=2>really addressing environments where the SOA and the verifier</FONT>
<BR><FONT SIZE=2>are in the same &quot;security domain&quot; and does not really address</FONT>
<BR><FONT SIZE=2>any cross-domain issues. Verifiers are expected to be configured </FONT>
<BR><FONT SIZE=2>with a trusted copy of their SOA public key as they are today for </FONT>
<BR><FONT SIZE=2>trust anchors in PMI. The verifier trusts the SOA as the ultimate</FONT>
<BR><FONT SIZE=2>source of authority for a set of privileges.&nbsp; </FONT>
</P>

<P><FONT SIZE=2>If there are requirements to enhance the 509 model, those</FONT>
<BR><FONT SIZE=2>requirements can certainly be submitted to the 509 work by PKIX.</FONT>
<BR><FONT SIZE=2>From a process standpoint there is no problem, the liaisons </FONT>
<BR><FONT SIZE=2>already exist and we've worked successfully on other topics </FONT>
<BR><FONT SIZE=2>through this channel, regardless of who agrees or disagrees with the </FONT>
<BR><FONT SIZE=2>specific topic. </FONT>
</P>

<P><FONT SIZE=2>From my own personal standpoint, I'm not yet convinced of the requirement.</FONT>
<BR><FONT SIZE=2>the arguments seem to be that we need it for PMI because we use it for PKI or</FONT>
<BR><FONT SIZE=2>we need it to cover liability issues. The liability issue seems much less</FONT>
<BR><FONT SIZE=2>convincing when you recognize that the 509 PMI model does NOT include any </FONT>
<BR><FONT SIZE=2>inter-domain cross-certification equivalent. Documenting your own liability </FONT>
<BR><FONT SIZE=2>for internal applications isn't very interesting. </FONT>
<BR><FONT SIZE=2>&nbsp;</FONT>
<BR><FONT SIZE=2>Sharon&nbsp; </FONT>
<BR><FONT SIZE=2>&nbsp;</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Peter Williams [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>Sent: Friday, March 15, 2002 6:49 PM</FONT>
<BR><FONT SIZE=2>To: 'Denis Pinkas'</FONT>
<BR><FONT SIZE=2>Cc: '[e-mail]'</FONT>
<BR><FONT SIZE=2>Subject: RE: Attribute Certificates and Privilege Policy</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=2>I dont see how privilege policy, as defined by ISO,</FONT>
<BR><FONT SIZE=2>has any equivalency relation to validation policy - as</FONT>
<BR><FONT SIZE=2>an architect speaking from a company that was</FONT>
<BR><FONT SIZE=2>conceived to deploy and has deployed over a hundred </FONT>
<BR><FONT SIZE=2>operational validation servers and associated validation </FONT>
<BR><FONT SIZE=2>policies in the world - for probably every major PKI </FONT>
<BR><FONT SIZE=2>vendors' system, and probably 50% of all operational</FONT>
<BR><FONT SIZE=2>commercial-grade PKIs!</FONT>
</P>

<P><FONT SIZE=2>Validation policies are the expression in some rule form</FONT>
<BR><FONT SIZE=2>of the risk management controls a RP uses to *Accept*</FONT>
<BR><FONT SIZE=2>a cert path, beyond the rules built into the simplistic path</FONT>
<BR><FONT SIZE=2>processing algorithm specified by ISO for</FONT>
<BR><FONT SIZE=2>trust chains *validation*; acceptance and validation</FONT>
<BR><FONT SIZE=2>are very different processes, especially in well written</FONT>
<BR><FONT SIZE=2>CPSs mapping technology onto law principles. ValiCert</FONT>
<BR><FONT SIZE=2>must have built now 10 quite-different validation policys, for </FONT>
<BR><FONT SIZE=2>various military projects and banking groups.</FONT>
</P>

<P><FONT SIZE=2>Whilst ISO rules for PKI trust chain processing</FONT>
<BR><FONT SIZE=2>properly arrange for inteoperability and navigation of trust </FONT>
<BR><FONT SIZE=2>domains (a valid ISO issue), validation policies address the </FONT>
<BR><FONT SIZE=2>risks applications face when PKI fails, PKI signals need to be </FONT>
<BR><FONT SIZE=2>ignored/overridden, redundacy of PKI chains, or PKI is used t</FONT>
<BR><FONT SIZE=2>o assist privilege-based control systems - whose purposes fall outside</FONT>
<BR><FONT SIZE=2>the scope of ISO PKI/PMI frameworks, or IETF profiles</FONT>
<BR><FONT SIZE=2>thereof.</FONT>
</P>

<P><FONT SIZE=2>In practice, privilege policy is already deployed worldwide, in </FONT>
<BR><FONT SIZE=2>two forms. Java 2 enables</FONT>
<BR><FONT SIZE=2>relying parties to sign and use an executable-form &quot;AC&quot;, that limits</FONT>
<BR><FONT SIZE=2>privilege acceptance for privileges asserted by loading-code, </FONT>
<BR><FONT SIZE=2>using privilege-policy rule expressions that are </FONT>
<BR><FONT SIZE=2>expressed as executable code, selected and downloaded by the </FONT>
<BR><FONT SIZE=2>target system. Microsoft&nbsp; Win32 OS's TCB does something similar </FONT>
<BR><FONT SIZE=2>since 5&nbsp; years ago, using other signalling </FONT>
<BR><FONT SIZE=2>and enforcement techniques, that leverages a little of the </FONT>
<BR><FONT SIZE=2>Authenticode standardization in 2459, and other</FONT>
<BR><FONT SIZE=2>PKI-based techniques properly not addressed by PKIX.</FONT>
</P>

<P><FONT SIZE=2>Validation policies are, in contrast, all about validation of </FONT>
<BR><FONT SIZE=2>certificate chains, PKI and PMI varieties. AS we learned</FONT>
<BR><FONT SIZE=2>from the authoritative editor of X.509, the ISO intended</FONT>
<BR><FONT SIZE=2>that privilege policy enforcement has little or nothing</FONT>
<BR><FONT SIZE=2>to do with AC delegation path processing, and nothing</FONT>
<BR><FONT SIZE=2>whatsoever to do with PKI path processing. Validation</FONT>
<BR><FONT SIZE=2>policies are exclusively associated with the PKI</FONT>
<BR><FONT SIZE=2>and/or PMI chain processing.</FONT>
</P>

<P><FONT SIZE=2>I asked the question, is privilege policy enforcement</FONT>
<BR><FONT SIZE=2>PART OF path processing. Sharon indicated that it</FONT>
<BR><FONT SIZE=2>is not, though ISO wording and titling of X.509 sections</FONT>
<BR><FONT SIZE=2>16.x.y could be improved. Hence validation policies</FONT>
<BR><FONT SIZE=2>are not equivalent in basis to privilege policies.</FONT>
</P>

<P><FONT SIZE=2>AS privilege policy and validation policy do take</FONT>
<BR><FONT SIZE=2>the perspective of relying parties, there </FONT>
<BR><FONT SIZE=2>is some limited consistency in that shared </FONT>
<BR><FONT SIZE=2>perspective, to be fair to Denis.</FONT>
</P>

<P><FONT SIZE=2>If ISO decide that, contrary to current intepretation</FONT>
<BR><FONT SIZE=2>by the editor of the ISO position, that privilege</FONT>
<BR><FONT SIZE=2>policy enforcement IS A PART OF path processing,</FONT>
<BR><FONT SIZE=2>then we could possibly agree on there being</FONT>
<BR><FONT SIZE=2>some equivalency basis. </FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Denis Pinkas [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>Sent: Friday, March 15, 2002 9:50 AM</FONT>
<BR><FONT SIZE=2>To: Sharon Boeyen</FONT>
<BR><FONT SIZE=2>Cc: '[e-mail]'</FONT>
<BR><FONT SIZE=2>Subject: Re: Attribute Certificates and Privilege Policy</FONT>
</P>
<BR>
<BR>

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

<P><FONT SIZE=2>Yes, this is indeed a very long e-mail. Mine will be shorter.</FONT>
</P>

<P><FONT SIZE=2>Shortly speaking, the &quot;privilege policy&quot; is the equivalent of a </FONT>
<BR><FONT SIZE=2>&quot;validation policy&quot; (see the DPV requ. draft availmable from </FONT>
<BR><FONT SIZE=2><A HREF="http://www.imc.org/draft-ietf-pkix-dpv-dpd-req" TARGET="_blank">http://www.imc.org/draft-ietf-pkix-dpv-dpd-req</A>), but it is NOT </FONT>
<BR><FONT SIZE=2>the equivalent of a certification policy.</FONT>
</P>

<P><FONT SIZE=2>You said: &quot;In terms of 'why no certificate policy' - there was no need</FONT>
<BR><FONT SIZE=2>identified for an equivalent&quot;.</FONT>
</P>

<P><FONT SIZE=2>For CAs there are different levels of verification of the identity presented</FONT>
<BR><FONT SIZE=2>at the time of registration. This level is &quot;visible&quot; through the certificate</FONT>
<BR><FONT SIZE=2>policy.</FONT>
</P>

<P><FONT SIZE=2>I do not see why we should not draw a parallel with attributes, where for</FONT>
<BR><FONT SIZE=2>AAs there would be different levels of verification of the attributes</FONT>
<BR><FONT SIZE=2>presented at the time of registration. This level would be &quot;visible&quot; through</FONT>
<BR><FONT SIZE=2>the &quot;attribute policy&quot;.</FONT>
</P>

<P><FONT SIZE=2>A validation policy (i.e. privilege policy using the ISO terminology) may</FONT>
<BR><FONT SIZE=2>consider that some attribute policies are adequate and that some others are</FONT>
<BR><FONT SIZE=2>not.</FONT>
</P>

<P><FONT SIZE=2>Otherwise, the single way to trust is to use the name of the AA. </FONT>
</P>

<P><FONT SIZE=2>If an AA supports different &quot;attribute policies&quot;, it would have to change</FONT>
<BR><FONT SIZE=2>its</FONT>
<BR><FONT SIZE=2>name, each time. :-(</FONT>
</P>

<P><FONT SIZE=2>Thus I see a good reason to have an equivalent.</FONT>
</P>

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

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

<P><FONT SIZE=2>&gt; I'll try to address all the questions I've seen re the 509 aspects of this</FONT>
<BR><FONT SIZE=2>&gt; discussion. (Sorry this is rather long, but I found this</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; easier than trying to respond to each message).</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I think Peter has identified at least one part of 509 that could benefit</FONT>
<BR><FONT SIZE=2>&gt; from some editorial clarification.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Clause 16 &quot;Privilege path processing procedure&quot; may be more appropriate</FONT>
<BR><FONT SIZE=2>&gt; titled &quot;Privilege assertion processing procedure&quot;.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Each paragraph in 16.1 could probably use subtitles to clarify what's</FONT>
<BR><FONT SIZE=2>&gt; really going on. The paragraphs in this section are basically</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; a list of each of the checks that need to be done before an asserted</FONT>
<BR><FONT SIZE=2>&gt; privilege can be granted to a claimant.</FONT>
<BR><FONT SIZE=2>&gt; - Para 1 is doing a &quot;validation&quot; on each of the attribute certificates in</FONT>
<BR><FONT SIZE=2>&gt; the path. This is just checking the signatures, using the</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; PKI path validation steps as if you were checking the signature on a</FONT>
<BR><FONT SIZE=2>&gt; signed form - the details are in clause 10 of the PKI section.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; - Para 2 is a check to ensure the claimant's willingness to use that</FONT>
<BR><FONT SIZE=2>&gt; attribute cert for the context - no standard steps for this</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; check are defined.</FONT>
<BR><FONT SIZE=2>&gt; - Para 3 is the revocation status check - no details req'd</FONT>
<BR><FONT SIZE=2>&gt; - Para 4 is the check for whether the asserted privilege is valid for the</FONT>
<BR><FONT SIZE=2>&gt; time of interest - no details req'd</FONT>
<BR><FONT SIZE=2>&gt; - Para 5 is checking any constraints imposed by the issuer of the AC on</FONT>
<BR><FONT SIZE=2>&gt; the set of permitted targets - no details req'd</FONT>
<BR><FONT SIZE=2>&gt; - Para 6 is the checks for roles and of delegation. Note that 16.2 is</FONT>
<BR><FONT SIZE=2>&gt; merely the details associated with the role check and</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; 16.3 is merely the details assoiated with the delegation check.</FONT>
<BR><FONT SIZE=2>&gt; - Para 7 is the privilege policy check against the asserted privilege</FONT>
<BR><FONT SIZE=2>&gt; together with the other inputs (target sensitivity,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; environmental variables) and checking any constraints on privilege policy</FONT>
<BR><FONT SIZE=2>&gt; imposed by the issuer.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; So this complete set of steps comprise the processing that needs to be</FONT>
<BR><FONT SIZE=2>&gt; done to assess a privilege assertion. Some of these</FONT>
<BR><FONT SIZE=2>&gt; relate to paths (Para 1 is processing of a public-key certification path</FONT>
<BR><FONT SIZE=2>&gt; to verify the signature on the attribute cert and</FONT>
<BR><FONT SIZE=2>&gt; Para 6 along with 16.3 is processing of a delegation path of attribute</FONT>
<BR><FONT SIZE=2>&gt; certificates to determine whether or not the delegation</FONT>
<BR><FONT SIZE=2>&gt; itself is authorized and valid. As part of the processing of a delegation</FONT>
<BR><FONT SIZE=2>&gt; path, note that the signature on EACH attribute</FONT>
<BR><FONT SIZE=2>&gt; certificate in the path needs to be verified, so again the public-key path</FONT>
<BR><FONT SIZE=2>&gt; validation is used for that purpose). I wanted to</FONT>
<BR><FONT SIZE=2>&gt; try to clarify this because asking if something is part of &quot;path</FONT>
<BR><FONT SIZE=2>&gt; validation&quot; is not as easy to answer as it would be if</FONT>
<BR><FONT SIZE=2>&gt; we were talking about PKI instead of PMI.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; The privilege policy is the basis for determining the acceptance of an</FONT>
<BR><FONT SIZE=2>&gt; attribute certificate (at least from a policy perspective).</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; It is processed by a verifier as one of the steps in assessing a privilege</FONT>
<BR><FONT SIZE=2>&gt; assertion, but it is not strictly part of either</FONT>
<BR><FONT SIZE=2>&gt; public-key certification path processing done for signature verification</FONT>
<BR><FONT SIZE=2>&gt; or part of delegation path processing for verifying</FONT>
<BR><FONT SIZE=2>&gt; delegation.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Many aspects of privlege policy were not standardized in 509, including</FONT>
<BR><FONT SIZE=2>&gt; its syntax, who can write them etc, how does</FONT>
<BR><FONT SIZE=2>&gt; a verifier know which one to use etc. Some of these were deferred, e.g.</FONT>
<BR><FONT SIZE=2>&gt; syntax. Note however, that in OASIS, the XACML</FONT>
<BR><FONT SIZE=2>&gt; working group is now defining a standard XML syntax for access control</FONT>
<BR><FONT SIZE=2>&gt; policy. Some material from the sample syntaxes</FONT>
<BR><FONT SIZE=2>&gt; in the X.509 informative annex were input to the XACML work so folks</FONT>
<BR><FONT SIZE=2>&gt; interested in privilege policy may find that work</FONT>
<BR><FONT SIZE=2>&gt; interesting as well. As for how the verifier knows which privilege policy</FONT>
<BR><FONT SIZE=2>&gt; to use - that is left to the implementation. In</FONT>
<BR><FONT SIZE=2>&gt; some cases a target may always work with a single privilege policy and it</FONT>
<BR><FONT SIZE=2>&gt; may be created by the local SOA . There</FONT>
<BR><FONT SIZE=2>&gt; are hooks to tie privilege policies to attributes for which an SOA assigns</FONT>
<BR><FONT SIZE=2>&gt; privileges (the attributeDescriptor in 15.3.2.2 and</FONT>
<BR><FONT SIZE=2>&gt; there is also directory syntax to store them, but no standardized way for</FONT>
<BR><FONT SIZE=2>&gt; a verifier to determine which to use. However a local</FONT>
<BR><FONT SIZE=2>&gt; trusted SOA would obviously be one possible source of privilege policies.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Regarding the acceptablePrivilegePolicies extension, a verifier is always</FONT>
<BR><FONT SIZE=2>&gt; assessing a privilege assertion with respect to</FONT>
<BR><FONT SIZE=2>&gt; a specific privilege policy as per para 7 in 14.1. In the absence of the</FONT>
<BR><FONT SIZE=2>&gt; acceptablePrivilegePolicies extension, the verifier</FONT>
<BR><FONT SIZE=2>&gt; merely assess the assertion with respect to the privilege policy it is</FONT>
<BR><FONT SIZE=2>&gt; working with (out of band / local means for determining</FONT>
<BR><FONT SIZE=2>&gt; which privilege policy the verifier operates with - likely greatly</FONT>
<BR><FONT SIZE=2>&gt; determined by the target). If the acceptablePrivilegePolicies</FONT>
<BR><FONT SIZE=2>&gt; extension is present, then the verifier needs to check whether the</FONT>
<BR><FONT SIZE=2>&gt; privilege policy it is operating under is one of the ones</FONT>
<BR><FONT SIZE=2>&gt; listed as acceptable in that extension. If it is, then the verifier</FONT>
<BR><FONT SIZE=2>&gt; proceeds normally. If it is not, the verifier stops and the privilege</FONT>
<BR><FONT SIZE=2>&gt; asserter is not given access.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; The privilege policy is the set of rules that determine acceptability of</FONT>
<BR><FONT SIZE=2>&gt; an asserted privilege. A primary difference between</FONT>
<BR><FONT SIZE=2>&gt; that and certificate policy is that certificate policy is tied to a</FONT>
<BR><FONT SIZE=2>&gt; certificate and defines acceptable uses for that certificate,</FONT>
<BR><FONT SIZE=2>&gt; while privilege policy is associated with a verifier and the target that</FONT>
<BR><FONT SIZE=2>&gt; is in question and determines which privilege assertions</FONT>
<BR><FONT SIZE=2>&gt; are appropriate. So, things like usage constraints, dollar limits, time</FONT>
<BR><FONT SIZE=2>&gt; constraints, name constraints - all those things would</FONT>
<BR><FONT SIZE=2>&gt; be appropriate for inclusion in a privilege policy. I'm not convinced</FONT>
<BR><FONT SIZE=2>&gt; about liability limits though, because privilegePolicy must</FONT>
<BR><FONT SIZE=2>&gt; be machine processable as it is processed dynamically at assertion</FONT>
<BR><FONT SIZE=2>&gt; assessment time. Liability limits don't seem like they</FONT>
<BR><FONT SIZE=2>&gt; would easily lend themselves to this.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; In terms of 'why no certificate policy' - there was no need identified for</FONT>
<BR><FONT SIZE=2>&gt; an equivalent. A verifier trusts an SOA as the</FONT>
<BR><FONT SIZE=2>&gt; ultimate source of authority for assignment of a set of privileges. That's</FONT>
<BR><FONT SIZE=2>&gt; the authorization issue I mentioned earlier.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; If delegation is done, then the checks for ensuring that is authorized are</FONT>
<BR><FONT SIZE=2>&gt; part of the delegation path processing</FONT>
<BR><FONT SIZE=2>&gt; procedure. If an AA (SOA or delegated AA) wishes to constrain the policy</FONT>
<BR><FONT SIZE=2>&gt; under which an AC is used, it can do</FONT>
<BR><FONT SIZE=2>&gt; so through the acceptablePrivilegePolicies extension. As for certificate</FONT>
<BR><FONT SIZE=2>&gt; policies, they are used when verifying the</FONT>
<BR><FONT SIZE=2>&gt; signature on the attribute certificates as well as when verifying the</FONT>
<BR><FONT SIZE=2>&gt; signature on any transaction associated with</FONT>
<BR><FONT SIZE=2>&gt; the specific assertion of privilege being made by the claimant. So</FONT>
<BR><FONT SIZE=2>&gt; certificate policies do factor into the overall</FONT>
<BR><FONT SIZE=2>&gt; validation for any given transaction, but are not part of the privilege</FONT>
<BR><FONT SIZE=2>&gt; assertion assessment.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I hope this addresses the questions that were raised by Denis, Chris and</FONT>
<BR><FONT SIZE=2>&gt; Peter - if not I'm sure you'll let me know :-).</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; In terms of 509 clarifications, if people think some defect work is needed</FONT>
<BR><FONT SIZE=2>&gt; there, please let me know.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; FYI, I'm going to try to get all my editing tasks from the recent X.509</FONT>
<BR><FONT SIZE=2>&gt; meeting completed and provide a brief summary</FONT>
<BR><FONT SIZE=2>&gt; of the meeting to this list prior to the PKIX meeting. There are a couple</FONT>
<BR><FONT SIZE=2>&gt; of current issues we're working on with respect</FONT>
<BR><FONT SIZE=2>&gt; to SOAs that PMI folks might be interested in.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Again, apologies for the length of the message.</FONT>
<BR><FONT SIZE=2>&gt; Sharon</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Sharon Boeyen</FONT>
<BR><FONT SIZE=2>&gt; Principal, Advanced Security</FONT>
<BR><FONT SIZE=2>&gt; Tel: [phone]</FONT>
<BR><FONT SIZE=2>&gt; www.entrust.com</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Entrust, Inc.</FONT>
<BR><FONT SIZE=2>&gt; Securing the Internet</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1D01C.0CFC0830--


Received: by above.proper.com (8.11.6/8.11.3) id g2KDoWo01854 for ietf-pkix-bks; Wed, 20 Mar 2002 05:50:32 -0800 (PST)
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 g2KDoU401847 for <[e-mail]>; Wed, 20 Mar 2002 05:50:31 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id g2KDm7l25545 for <[e-mail]>; Wed, 20 Mar 2002 08:48:07 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 20 Mar 2002 08:51:47 -0500
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: Candidate for moving OCSP to a Draft Standard
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>

Mike and Ambarish,

I agree with the MUST as a code-level requirement, I am concerned
only about deployment.  To avoid potential confusion, how about
using the "capable" text in the standard:

    CAs that support an OCSP service, either hosted locally or
    provided by an Authorized Responder, MUST be capable of
    including a value for a uniformResourceIndicator ...

Thanks for the clarification,
Dave




Michael Myers wrote:
> 
> Dave,
> 
> Is your issue one of deployment or code-level implementation?
> Because my intent was to drive into existence functionality that
> MAY be deployed on an as-needed basis.  Note the text "provide
> for".  That doesn't mean you have to use that functionality.  It
> means that the server you use MUST be capable of such.
> 
> Mike


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2K0gSQ08475 for ietf-pkix-bks; Tue, 19 Mar 2002 16:42:28 -0800 (PST)
Received: from localhost.custodium.com ([216.241.20.228]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2K0gL408466 for <[e-mail]>; Tue, 19 Mar 2002 16:42:24 -0800 (PST)
Received: from ropazo ([192.168.4.100]) by localhost.custodium.com (8.12.2/8.12.2) with SMTP id g2K0eXvW018272; Tue, 19 Mar 2002 20:40:49 -0400
From: "Roberto Opazo Gazmuri" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, <[e-mail]>
Subject: RE: Updating RFC 3039 - and its impact on PI
Date: Tue, 19 Mar 2002 20:35:01 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 1 (Highest)
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: High
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
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>

Stefan,

I see 2 different points here:

1.- In witch context should we discuss a PI solution?
I believe the PI document is well justified and this discussion is proving
that.

2.- Should we use DN or GN to codify PIs?
This point was analysed previously. I my opinion there are good reasons to
prefer GN:
  a)	DNs are overloaded enough and especially de subject field, this field
should be as international as it is possible. A PI is typically a locally
assigned value, so it is not a good idea to put it in the subject.
  b)	One person could have many PIs of different type, like passport number,
security number, client number and another passport number (double
nationality or a passport number assigned for commercial purposes).
  c)	One PI value identifies an entity by it self, so it not natural to put
this value in a Directory Information Tree, because this will be always a 2
levels tree.
  d)	In essence, a PI is another way to call an entity, so it is very
natural to use OtherName in SubjectAltName extension.

Best regards,

Roberto Opazo

> -----Mensaje original-----
> De: [e-mail] [mailto:[e-mail]]En
> nombre de Stefan Santesson
> Enviado el: martes, 19 de marzo de 2002 12:27
> Para: [e-mail]
> Asunto: RE: Updating RFC 3039 - and its impact on PI
>
>
>
> Maybe I should clarify myself.
>
> I believe that many of the functionality aspects, that PI was design to
> meet, is achieved by defining semantics of data stored in DN attributes.
>
> I just want to invite people who think they need the PI solution to see
> what they can do with attribute semantics and open the discussion to
> suggestions that would further improve this solution.
>
> Maybe this would reduce the need for a separate PI solution to the extent
> where its just not justified to make YAP. But I remain open to that issue.
>
> /Stefan
>
>
> At 17:36 2002-03-15 -0400, Roberto Opazo Gazmuri wrote:
>
> > > > Finally I believe that a revision of RFC 3039 should include
> > > > considerations to avoid the need for a PI extension
> according to the PI
> > > > draft.
> > > >
> > > > I can't see that the PI draft accomplish anything that RFC
> 3039 doesn't
> > > > already solve, or at least would solve after revision.
> > >
> > > The revised document will not be able to solve what the PI
> document covers
> > > since the PI document applies to *any entity* whereas the
> revised RFC 3039
> > > document is planned to apply only to *personal ID
> certificates*. Maybe the
> > > revised RFC 3039 could take advantage and refer to the PI document.
> > >
> >
> >I agree.
> >
> >The PI purpose is important enough to be in an independent discussion and
> >RFC, even considering than QC could be modified to apply to any entity.
> >
> >Best regards,
> >
> >Roberto



Received: by above.proper.com (8.11.6/8.11.3) id g2K0QXR08126 for ietf-pkix-bks; Tue, 19 Mar 2002 16:26:33 -0800 (PST)
Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2K0QV408122 for <[e-mail]>; Tue, 19 Mar 2002 16:26:32 -0800 (PST)
Received: by aspams52.ca.com with Internet Mail Service (5.5.2655.55) id <G3TPZX37>; Wed, 20 Mar 2002 11:25:51 +1100
Message-ID: <[e-mail]>
From: "Ramsay, Ron" <[e-mail]>
To: jim <[e-mail]>, todd glassey <[e-mail]>
Cc: Stephen Kent <[e-mail]>, Peter Sylvester <[e-mail]>, [e-mail], [e-mail], vint cerf <[e-mail]>, [e-mail]
Subject: RE: DPD/DPV reqmts strawpoll
Date: Wed, 20 Mar 2002 11:26:12 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
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>

I disagree. I find it vexatious. I have stopped taking any interest in it as
the level of content is extremely low and the noise extremely high. If there
was anything of value it should be very easy to write a simple email to list
the valid points. Where anyone has attempted to do this, others (and here I
am thinking of only one other) have once again raised irrelevant items and
conducted a personal attack.

Do yourselves a favour or live by yourselves!

Ron (I am not listening - I have may hands over my ears - i am yelling that
I cannot hear!)

-----Original Message-----
From: jim [mailto:[e-mail]]
Sent: Tuesday, 19 March 2002 12:19
To: todd glassey
Cc: Stephen Kent; Peter Sylvester; [e-mail]; [e-mail]; vint
cerf; [e-mail]
Subject: Re: DPD/DPV reqmts strawpoll



Since checks and balances are a healthy thing, I would be very opposed to
taking
any action against Todd.  I think he has been bringing up valid points that
need
to be considered before any action can or should be taken.  The open dialog
is
healthy, but I do wish that all would refrain from making or taking things
personally.
Jim

todd glassey wrote:

> Steve you chair is not a throne. really its not.
>
> T.
> ----- Original Message -----
> From: "Stephen Kent" <[e-mail]>
> To: "todd glassey" <[e-mail]>
> Cc: "Peter Sylvester" <[e-mail]>; <[e-mail]>;
> <[e-mail]>; "vint cerf" <[e-mail]>;
<[e-mail]>
> Sent: Monday, March 18, 2002 9:57 AM
> Subject: Re: DPD/DPV reqmts strawpoll
>
> > At 5:23 AM -0800 3/18/02, todd glassey wrote:
> > >I would hate to think that the WG Chairs used any kind of Email
> Blacklisting
> > >or other Blacklisting processes - that would be blatantly a problem for
> the
> > >ruling class here.
> > >
> > >Todd
> > >
> >
> > Two observations:
> >
> > First, as Peter later noted, he was making a tongue in cheek comment
> > re blacklisting.
> >
> > Second, if you were more familiar with IETF history you might be
> > aware of rare instances where individuals have been banned from
> > mailing lists due to persistent, egregious behavior. Your behavior
> > has not yet reached a point where such measures are warranted, but
> > you're working on it.
> >
> > Steve
> >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2JNYTh06515 for ietf-pkix-bks; Tue, 19 Mar 2002 15:34:29 -0800 (PST)
Received: from geos.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2JNYR406511 for <[e-mail]>; Tue, 19 Mar 2002 15:34:27 -0800 (PST)
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 g2JNYKA10610; Tue, 19 Mar 2002 15:34:21 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "David P. Kemp" <[e-mail]>, <[e-mail]>
Subject: RE: Candidate for moving OCSP to a Draft Standard
Date: Tue, 19 Mar 2002 15:31:43 -0800
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>

Dave,

Is your issue one of deployment or code-level implementation?
Because my intent was to drive into existence functionality that
MAY be deployed on an as-needed basis.  Note the text "provide
for".  That doesn't mean you have to use that functionality.  It
means that the server you use MUST be capable of such.

Mike


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of
> David P. Kemp
> Sent: Tuesday, March 19, 2002 1:16 PM
> To: '[e-mail]'
> Subject: Re: Candidate for moving OCSP to a Draft Standard
>
>
>
> Ambarish,
>
> Section 3.1 of RFC 2560 (unchanged in draft -03)
> includes the following:
>
>    CAs that support an OCSP service, either hosted
> locally or provided
>    by an Authorized Responder, MUST provide for the
> inclusion of a value
>    for a uniformResourceIndicator (URI)
> accessLocation and the OID value
>    id-ad-ocsp for the accessMethod in the
> AccessDescription SEQUENCE.
>
> This requirement prohibits local elements (i.e. LAN
> administrators) from
> operating Authorized Responders, because every LAN
> URI would have to be
> included in every EE certificate.  There are
> potentially hundreds or
> thousands of local elements that may wish to operate
> Authorized Responders
> (although I expect that isn't part of your business
> model :-), and it
> would be completely impractical to list them all in
> each EE certificate.
>
> From a security perspective, the thing that
> distinguishes a Trusted
> Responder from an Authorized Responder is the
> existence of the delegation
> certificate described in section 2.6.  AIA is an
> operational convenience
> that allows clients to find responders without
> needing additional
> configuration information.  It (AIA) is not security-critical.
>
> I request that the MUST in section 3.1 be changed to
> MAY.  Leaving it
> at MUST imposes a severe and unnecessary restriction
> on the possible
> operational scenarios.
>
> Regards,
> Dave
>
>
>
>
> Ambarish Malpani wrote:
> >
> > Hi Guys,
> >     Here is a candidate for moving OCSP to a Draft
> Standard. There
> > are no changes in the bytes that go across the wire
> - basically all
> > clarifications.
> >
> > A list of all the changes between this document and
> RFC 2560 are
> > in Appendix D (reproduced here).
> >
> > I hope we can get to the Draft Standard state
> before this IETF.
> >
> > Regards,
> > Ambarish
>



Received: by above.proper.com (8.11.6/8.11.3) id g2JN2F705789 for ietf-pkix-bks; Tue, 19 Mar 2002 15:02:15 -0800 (PST)
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 g2JN2D405785 for <[e-mail]>; Tue, 19 Mar 2002 15:02:13 -0800 (PST)
Received: from tsg1 ([12.81.64.18]) by mtiwmhc21.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020319225049.MDBR780.mtiwmhc21.worldnet.att.net@tsg1>; Tue, 19 Mar 2002 22:50:49 +0000
Message-ID: <03e501c1cf98$7ab622e0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: "Peter Sylvester" <[e-mail]>, <[e-mail]>, <[e-mail]>, "vint cerf" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <005c01c1ce80$22054130$020aff0c@tsg1> <p05100300b8bbc109bd96@[128.33.238.54]> <02e801c1ced4$d1f24a30$020aff0c@tsg1> <p05100309b8bd4f95e09d@[166.63.186.168]>
Subject: Re: DPD/DPV reqmts strawpoll
Date: Tue, 19 Mar 2002 14:50:31 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve if you cannot take the heat as the chair of the WG then you are in
the wrong job.


Todd

----- Original Message -----
From: "Stephen Kent" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: "Peter Sylvester" <[e-mail]>; <[e-mail]>;
<[e-mail]>; "vint cerf" <[e-mail]>; <[e-mail]>
Sent: Tuesday, March 19, 2002 12:27 PM
Subject: Re: DPD/DPV reqmts strawpoll


> At 3:29 PM -0800 3/18/02, todd glassey wrote:
> >Steve you chair is not a throne. really its not.
> >
> >T.
>
> Was this intended to be a meaningful communication, or just another
> annoying message?
>
> Steve
>



Received: by above.proper.com (8.11.6/8.11.3) id g2JMrjp05593 for ietf-pkix-bks; Tue, 19 Mar 2002 14:53:45 -0800 (PST)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2JMrj405588 for <[e-mail]>; Tue, 19 Mar 2002 14:53:45 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Tue, 19 Mar 2002 14:52:27 -0800 (PST)
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, 19 Mar 2002 14:52:27 -0800 (PST)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <GK1PRDGB>; Tue, 19 Mar 2002 14:53:19 -0800
Content-return: allowed
Date: Tue, 19 Mar 2002 14:53:18 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: Candidate for moving OCSP to a Draft Standard
To: "'David P. Kemp'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Dave,
     I believe all the requirement states is that CAs MUST allow
for the extension to be included in certs. It doesn't say that
the CA must actually actually put that extension in issued certs.

So the CA software will let you put the extension. You can choose
to issue certs without the extension.

Do you 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: David P. Kemp [mailto:[e-mail]]
> Sent: Tuesday, March 19, 2002 1:16 PM
> To: '[e-mail]'
> Subject: Re: Candidate for moving OCSP to a Draft Standard
> 
> 
> 
> Ambarish,
> 
> Section 3.1 of RFC 2560 (unchanged in draft -03) includes the 
> following:
> 
>    CAs that support an OCSP service, either hosted locally or provided
>    by an Authorized Responder, MUST provide for the inclusion 
> of a value
>    for a uniformResourceIndicator (URI) accessLocation and 
> the OID value
>    id-ad-ocsp for the accessMethod in the AccessDescription SEQUENCE.
> 
> This requirement prohibits local elements (i.e. LAN 
> administrators) from
> operating Authorized Responders, because every LAN URI would 
> have to be
> included in every EE certificate.  There are potentially hundreds or
> thousands of local elements that may wish to operate 
> Authorized Responders
> (although I expect that isn't part of your business model :-), and it
> would be completely impractical to list them all in each EE 
> certificate.
> 
> From a security perspective, the thing that distinguishes a Trusted
> Responder from an Authorized Responder is the existence of 
> the delegation
> certificate described in section 2.6.  AIA is an operational 
> convenience
> that allows clients to find responders without needing additional
> configuration information.  It (AIA) is not security-critical.
> 
> I request that the MUST in section 3.1 be changed to MAY.  Leaving it
> at MUST imposes a severe and unnecessary restriction on the possible
> operational scenarios.
> 
> Regards,
> Dave
> 
> 
> 
> 
> Ambarish Malpani wrote:
> > 
> > Hi Guys,
> >     Here is a candidate for moving OCSP to a Draft Standard. There
> > are no changes in the bytes that go across the wire - basically all
> > clarifications.
> > 
> > A list of all the changes between this document and RFC 2560 are
> > in Appendix D (reproduced here).
> > 
> > I hope we can get to the Draft Standard state before this IETF.
> > 
> > Regards,
> > Ambarish
> 


Received: by above.proper.com (8.11.6/8.11.3) id g2JMNjD04978 for ietf-pkix-bks; Tue, 19 Mar 2002 14:23:45 -0800 (PST)
Received: from fw.hel.fi.ssh.com (fw.hel.fi.ssh.com [193.64.193.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2JMNg404974 for <[e-mail]>; Tue, 19 Mar 2002 14:23:43 -0800 (PST)
Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.27) with SMTP id g2JMNiT14860 for <[e-mail]>; Wed, 20 Mar 2002 00:23:44 +0200 (EET)
Received: (qmail 20531 invoked from network); 19 Mar 2002 22:23:44 -0000
Received: from unknown (HELO BACH) ([10.1.0.48]) (envelope-sender <[e-mail]>) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for <[e-mail]>; 19 Mar 2002 22:23:44 -0000
From: "Vesa Suontama" <[e-mail]>
To: <[e-mail]>
Subject: OCKID - question about the format
Date: Tue, 19 Mar 2002 16:18:27 -0600
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
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 V6.00.2600.0000
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g2JMNh404975
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul, 

Just one comment about OCKID draft. I think the idea is good: There should be a standard way to represent the hash of the PKI objects. 

However, I do not like the idea of using the base32 conversion in converting the binary to ASCII. Numerous programs already out there just use the hex presentation of the SHA-1 hash. See for example, MS certificate viewer in Windows, Netscape, SSH Sentinel, etc. 

I suggest that the OCKID would also use the plain HEX representation of the SHA-1 hash. This would make the ID's provided by the programs already out there compatible with OCKID. 

The only drawback of this is that you need 24 characters instead of 20 (and probably one for the extra dash). 

E.g the example you provided in the draft would become CC48-7D7A A622-8613-E997 instead of 3TEH-48XG-ELDB-H4NZ. 

The change would also simplify the draft and the implementation. 

What was your motivation for re-inventing the wheel?

Vesa

---
 Vesa Suontama <[e-mail]>     Tel: [phone]
                                     Fax: [phone]
 SSH Communications Security Corp    Fredrikinkatu 42
 http://www.ssh.com                  FIN-00100 Helsinki, Finland



Received: by above.proper.com (8.11.6/8.11.3) id g2JLJoE03347 for ietf-pkix-bks; Tue, 19 Mar 2002 13:19:50 -0800 (PST)
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 g2JLJn403343 for <[e-mail]>; Tue, 19 Mar 2002 13:19:49 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id g2JLHVN10572 for <[e-mail]>; Tue, 19 Mar 2002 16:17:31 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 19 Mar 2002 16:15:51 -0500
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]'" <[e-mail]>
Subject: Re: Candidate for moving OCSP to a Draft Standard
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>

Ambarish,

Section 3.1 of RFC 2560 (unchanged in draft -03) includes the following:

   CAs that support an OCSP service, either hosted locally or provided
   by an Authorized Responder, MUST provide for the inclusion of a value
   for a uniformResourceIndicator (URI) accessLocation and the OID value
   id-ad-ocsp for the accessMethod in the AccessDescription SEQUENCE.

This requirement prohibits local elements (i.e. LAN administrators) from
operating Authorized Responders, because every LAN URI would have to be
included in every EE certificate.  There are potentially hundreds or
thousands of local elements that may wish to operate Authorized Responders
(although I expect that isn't part of your business model :-), and it
would be completely impractical to list them all in each EE certificate.

>From a security perspective, the thing that distinguishes a Trusted
Responder from an Authorized Responder is the existence of the delegation
certificate described in section 2.6.  AIA is an operational convenience
that allows clients to find responders without needing additional
configuration information.  It (AIA) is not security-critical.

I request that the MUST in section 3.1 be changed to MAY.  Leaving it
at MUST imposes a severe and unnecessary restriction on the possible
operational scenarios.

Regards,
Dave




Ambarish Malpani wrote:
> 
> Hi Guys,
>     Here is a candidate for moving OCSP to a Draft Standard. There
> are no changes in the bytes that go across the wire - basically all
> clarifications.
> 
> A list of all the changes between this document and RFC 2560 are
> in Appendix D (reproduced here).
> 
> I hope we can get to the Draft Standard state before this IETF.
> 
> Regards,
> Ambarish


Received: by above.proper.com (8.11.6/8.11.3) id g2JKkmR02648 for ietf-pkix-bks; Tue, 19 Mar 2002 12:46:48 -0800 (PST)
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 g2JKkl402644 for <[e-mail]>; Tue, 19 Mar 2002 12:46:47 -0800 (PST)
Received: from [166.63.186.168] (SSH.BBN.COM [192.1.50.70]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA02403; Tue, 19 Mar 2002 15:46:30 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@127.0.0.1
Message-Id: <p05100309b8bd4f95e09d@[166.63.186.168]>
In-Reply-To: <02e801c1ced4$d1f24a30$020aff0c@tsg1>
References: <[e-mail]> <005c01c1ce80$22054130$020aff0c@tsg1> <p05100300b8bbc109bd96@[128.33.238.54]> <02e801c1ced4$d1f24a30$020aff0c@tsg1>
Date: Tue, 19 Mar 2002 15:27:43 -0500
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: DPD/DPV reqmts strawpoll
Cc: "Peter Sylvester" <[e-mail]>, <[e-mail]>, <[e-mail]>, "vint cerf" <[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>

At 3:29 PM -0800 3/18/02, todd glassey wrote:
>Steve you chair is not a throne. really its not.
>
>T.

Was this intended to be a meaningful communication, or just another 
annoying message?

Steve


Received: by above.proper.com (8.11.6/8.11.3) id g2JISGE26551 for ietf-pkix-bks; Tue, 19 Mar 2002 10:28:16 -0800 (PST)
Received: from maila.telia.com (maila.telia.com [194.22.194.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2JISF426547 for <[e-mail]>; Tue, 19 Mar 2002 10:28:15 -0800 (PST)
Received: from arport (t7o69p42.telia.com [213.65.46.42]) by maila.telia.com (8.11.6/8.11.6) with SMTP id g2JISGr01939; Tue, 19 Mar 2002 19:28:16 +0100 (CET)
Message-ID: <000f01c1cf73$94db1920$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, "Stefan Santesson" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: Updating RFC 3039 - and its impact on PI
Date: Tue, 19 Mar 2002 19:26:26 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,
As you probably know well, I have advocated (for about 2 years),
that a PI extension should indeed contain an OID or similar to point
out what DN attributes (usually one) contain the unique data.  This
means that existing DN schemes (containing the PI-data) can be kept
and the extension added "silently".  This so called "migration solution"
has been banned by [*censored*], who claim that this "habit" creates
bad DNs (DITs?) and must be stopped, in the same way as rcf822 names,
that still are deprecated by son-of-2459 authors in spite of being de-facto
standard.  So I give you little chance to get support for existing practices
and market.  I have already tried that route...

Regarding 3039, I think whatever mechanism PKIX may come up with,
it is rather a son-of-2459 or independent topic we are dealing with as
PIs has uses outside of personal certificates.

/anders

----- Original Message ----- 
From: "Stefan Santesson" <[e-mail]>
To: <[e-mail]>
Sent: Tuesday, March 19, 2002 17:26
Subject: RE: Updating RFC 3039 - and its impact on PI



Maybe I should clarify myself.

I believe that many of the functionality aspects, that PI was design to 
meet, is achieved by defining semantics of data stored in DN attributes.

I just want to invite people who think they need the PI solution to see 
what they can do with attribute semantics and open the discussion to 
suggestions that would further improve this solution.

Maybe this would reduce the need for a separate PI solution to the extent 
where its just not justified to make YAP. But I remain open to that issue.

/Stefan


At 17:36 2002-03-15 -0400, Roberto Opazo Gazmuri wrote:

> > > Finally I believe that a revision of RFC 3039 should include
> > > considerations to avoid the need for a PI extension according to the PI
> > > draft.
> > >
> > > I can't see that the PI draft accomplish anything that RFC 3039 doesn't
> > > already solve, or at least would solve after revision.
> >
> > The revised document will not be able to solve what the PI document covers
> > since the PI document applies to *any entity* whereas the revised RFC 3039
> > document is planned to apply only to *personal ID certificates*. Maybe the
> > revised RFC 3039 could take advantage and refer to the PI document.
> >
>
>I agree.
>
>The PI purpose is important enough to be in an independent discussion and
>RFC, even considering than QC could be modified to apply to any entity.
>
>Best regards,
>
>Roberto




Received: by above.proper.com (8.11.6/8.11.3) id g2JGgOS20528 for ietf-pkix-bks; Tue, 19 Mar 2002 08:42:24 -0800 (PST)
Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2JGgM420524 for <[e-mail]>; Tue, 19 Mar 2002 08:42:22 -0800 (PST)
Received: from stsIBMT20.addtrust.com ([166.63.189.169]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 19 Mar 2002 17:42:18 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 19 Mar 2002 17:26:41 +0100
To: <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RE: Updating RFC 3039 - and its impact on PI
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 19 Mar 2002 16:42:18.0601 (UTC) FILETIME=[08998590:01C1CF65]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Maybe I should clarify myself.

I believe that many of the functionality aspects, that PI was design to 
meet, is achieved by defining semantics of data stored in DN attributes.

I just want to invite people who think they need the PI solution to see 
what they can do with attribute semantics and open the discussion to 
suggestions that would further improve this solution.

Maybe this would reduce the need for a separate PI solution to the extent 
where its just not justified to make YAP. But I remain open to that issue.

/Stefan


At 17:36 2002-03-15 -0400, Roberto Opazo Gazmuri wrote:

> > > Finally I believe that a revision of RFC 3039 should include
> > > considerations to avoid the need for a PI extension according to the PI
> > > draft.
> > >
> > > I can't see that the PI draft accomplish anything that RFC 3039 doesn't
> > > already solve, or at least would solve after revision.
> >
> > The revised document will not be able to solve what the PI document covers
> > since the PI document applies to *any entity* whereas the revised RFC 3039
> > document is planned to apply only to *personal ID certificates*. Maybe the
> > revised RFC 3039 could take advantage and refer to the PI document.
> >
>
>I agree.
>
>The PI purpose is important enough to be in an independent discussion and
>RFC, even considering than QC could be modified to apply to any entity.
>
>Best regards,
>
>Roberto



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2JEEh211388 for ietf-pkix-bks; Tue, 19 Mar 2002 06:14:43 -0800 (PST)
Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2JEEf411381 for <[e-mail]>; Tue, 19 Mar 2002 06:14:41 -0800 (PST)
Received: from stsIBMT20.addtrust.com ([12.162.212.200]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 19 Mar 2002 15:14:20 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 19 Mar 2002 15:14:22 +0100
To: "Tom Gindin" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: Updating RFC 3039 - and its impact on PI
Cc: Denis Pinkas <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 19 Mar 2002 14:14:20.0914 (UTC) FILETIME=[5D15FD20:01C1CF50]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom,

I disagree and agree. The meaning was that the OID itself would define what 
attribute it was defining semantics for. As such it does also identify the 
attribute.

But I agree that there are no mechanism to know what attributes that are 
involved if you don't know the OID

I'm not sure what should happen. As long as this function define semantics 
for attributes, I'm open to changes of its syntax.

Further I don't know any one that uses this feature yet. But I have come 
across applications where it would be very useful.

/Stefan

At 20:23 2002-03-15 -0500, Tom Gindin wrote:


>       Stefan:
>
>       Are you proposing that the syntax of attribute semantics be changed
>from RFC 3039 or not?  The syntax in RFC 3039 does not seem sufficient to
>replace PI since it fails to bind registration authorities (and multiple
>ones are permitted within it) to attributes directly.  Is anyone using this
>at present?
>       Furthermore, binding this function to QC's would, by itself, make the
>feature less useful than PI's.  Publishing it there is a different matter.
>
>             Tom Gindin
>
>
>Stefan Santesson <[e-mail]>@mail.imc.org on 03/15/2002 06:52:54
>PM
>
>Sent by:    [e-mail]
>
>
>To:    Denis Pinkas <[e-mail]>
>cc:    [e-mail]
>Subject:    Re: Updating RFC 3039 - and its impact on PI
>
>
>
>Denis,
>
>I will be more specific but I didn't want to take up to much space in the
>start of the discussion
>
>I'm not ready to suggest text replacement right now but the key usage
>restriction should go and at least allow, without any restriction,
>combination of digital signature AND non-repudiation.
>
>For attribute semantics I think today that any such declaration has nothing
>
>to do with any legal statements concerning qualified certificates. Having
>that function in its current extension is to me a defect. If you want me to
>
>be more specific I have to owe you but I wont' have trouble to come up with
>
>examples and reasons.
>
>I will also rise these problems with ETSI.
>
>This was just an initiation of the discussion and I expect to discuss more
>with you and others at Minneapolis.
>
>Especially concerning assassination of PI :-)
>
>/Stefan
>
>At 15:03 2002-03-15 +0100, Denis Pinkas wrote:
>
> >Stefan,
> >
> >See some comments below:
> >
> > > As author and implementer of RFC 3039 and in the light of practical
> > > experience with RFC 3039, I think we should be ready to revise this RFC
> > > and handle some defects.
> > >
> > > The defects I have recorded so far are:
> > >
> > > 1) Key usage
> > > The key usage bit non-repudiation SHOULD NOT be set together with any
> > > other key usage according to RFC 3039. This has caused a lot of
>confusion
> > > and this "SHOULD NOT" statement is not compatible with existing
>reality.
> >
> >Could you be more explicit about a suggested text replacement ?
> >
> > > 2) Attribute semantics
> > > This function to define semantics for attributes included in the
>subject
> > > field is very useful and it covers almost everything that the current
>PI
> > > draft wants to solve.
> >
> >Could you be more specific ?
> >
> > > The problem is that this function is part of the
> > > qcStatements extension which it should not be. Firstly due to the fact
> > > that this statement has nothing to do with the intent of this extension
> > > and secondly because criticality setting for this function get mixed up
> > > with completely unrelated stuff in its current form.
> >
> > > 3) Usage and purpose
> > > RFC 3039 is the only RFC defining structure of a personal ID
>certificate.
> > > This should not be limited just to Qualified certificates. It should be
> > > more clear that this RFC is useful for any personal ID certificate.
>Also
> > > non-qualified ones.
> >
> >Fine.
> >
> > > Finally I believe that a revision of RFC 3039 should include
> > > considerations to avoid the need for a PI extension according to the PI
> > > draft.
> > >
> > > I can't see that the PI draft accomplish anything that RFC 3039 doesn't
> > > already solve, or at least would solve after revision.
> >
> >The revised document will not be able to solve what the PI document covers
> >since the PI document applies to *any entity* whereas the revised RFC 3039
> >document is planned to apply only to *personal ID certificates*. Maybe the
> >revised RFC 3039 could take advantage and refer to the PI document.
> >
> > > The only exception is the function to define an identifier completely
> > > independent of the subject name.
> >
> >Thank you for noticing this difference.
> >
> >Regards,
> >
> >Denis
> >
> > > I would tough argue that the total case with all aspects on
> > > the table probably doesn't justify another feature for that and that
>there
> > > are other ways to solve this within the realm of X.509 and PKIX
>standards.
> >
> > > I still believe that a creative revision of RFC 3039 could be made to
> > > cover what we need in this area. And I also recall this as an initially
> > > defined possibility laid down for the PI work.
> >
> > > /Stefan



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2J1IiV16750 for ietf-pkix-bks; Mon, 18 Mar 2002 17:18:44 -0800 (PST)
Received: from cumin.apnic.net (cumin.apnic.net [202.12.29.59]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2J1Ig416745 for <[e-mail]>; Mon, 18 Mar 2002 17:18:42 -0800 (PST)
Received: from SANJAYA (as-sanjaya.apnic.net [202.12.29.217]) by cumin.apnic.net (8.12.1/8.12.1) with SMTP id g2J1IhHa015147 for <[e-mail]>; Tue, 19 Mar 2002 11:18:43 +1000
Message-ID: <016701c1cee4$034e1a00$d91d0cca@SANJAYA>
From: "Sanjaya" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: draft-ietf-pkix-x509-ipaddr-as-extn-00.txt
Date: Tue, 19 Mar 2002 11:18:44 +1000
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 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Scanned-By: MIMEDefang 2.1 (www dot roaringpenguin dot com slash mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi all,
I'd like to make 2 comments on this draft:

1. The term 'ownership of address space' is not used in RIR community.
    It implies that the address space is permanently given to somebody,
while
    in fact it is only temporarily allocated/assigned while the user still
has
    a relation with the registry (contract with an ISP or a membership with
RIR).
    Could we replace it with 'delegated to', 'allocated to', or 'assigned
to'?
    Also 'stewardship' is probably better than 'ownership' (it implies
responsibility
    as well).

2. The use of attribute certificate (AC) for this purpose is also
appropriate.
    We can just add an attribute certificate whenever a new allocation is
    made, rather than revoking the PKC and create a new one with
    the new allocation added in the extension.
    However, for practical purpose (speed of authentication and authori-
    sation, for example), it make sense to attach the extension in an PKC.
    With this consideration, I propose that we add a profile of an AC as
part
    of this draft to ensure consistency in both approach, and to allow
flexibility
    in the implementation.

Cheers,
Sanjaya
Project Manager
APNIC




Received: by above.proper.com (8.11.6/8.11.3) id g2J1G5e16691 for ietf-pkix-bks; Mon, 18 Mar 2002 17:16:05 -0800 (PST)
Received: from mail.cablespeed.com (mail.cablespeed.com [216.45.96.99]) by above.proper.com (8.11.6/8.11.3) with SMTP id g2J1G4416686 for <[e-mail]>; Mon, 18 Mar 2002 17:16:04 -0800 (PST)
Received: (qmail 27824 invoked by uid 0); 19 Mar 2002 01:16:01 -0000
Received: from unknown (HELO cablespeed.com) (216.45.82.31) by 0 with SMTP; 19 Mar 2002 01:16:01 -0000
Message-ID: <[e-mail]>
Date: Mon, 18 Mar 2002 20:18:55 -0500
From: jim <[e-mail]>
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I)
X-Accept-Language: en
MIME-Version: 1.0
To: todd glassey <[e-mail]>
CC: Stephen Kent <[e-mail]>, Peter Sylvester <[e-mail]>, [e-mail], [e-mail], vint cerf <[e-mail]>, [e-mail]
Subject: Re: DPD/DPV reqmts strawpoll
References: <[e-mail]> <005c01c1ce80$22054130$020aff0c@tsg1> <p05100300b8bbc109bd96@[128.33.238.54]> <02e801c1ced4$d1f24a30$020aff0c@tsg1>
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>

Since checks and balances are a healthy thing, I would be very opposed to taking
any action against Todd.  I think he has been bringing up valid points that need
to be considered before any action can or should be taken.  The open dialog is
healthy, but I do wish that all would refrain from making or taking things
personally.
Jim

todd glassey wrote:

> Steve you chair is not a throne. really its not.
>
> T.
> ----- Original Message -----
> From: "Stephen Kent" <[e-mail]>
> To: "todd glassey" <[e-mail]>
> Cc: "Peter Sylvester" <[e-mail]>; <[e-mail]>;
> <[e-mail]>; "vint cerf" <[e-mail]>; <[e-mail]>
> Sent: Monday, March 18, 2002 9:57 AM
> Subject: Re: DPD/DPV reqmts strawpoll
>
> > At 5:23 AM -0800 3/18/02, todd glassey wrote:
> > >I would hate to think that the WG Chairs used any kind of Email
> Blacklisting
> > >or other Blacklisting processes - that would be blatantly a problem for
> the
> > >ruling class here.
> > >
> > >Todd
> > >
> >
> > Two observations:
> >
> > First, as Peter later noted, he was making a tongue in cheek comment
> > re blacklisting.
> >
> > Second, if you were more familiar with IETF history you might be
> > aware of rare instances where individuals have been banned from
> > mailing lists due to persistent, egregious behavior. Your behavior
> > has not yet reached a point where such measures are warranted, but
> > you're working on it.
> >
> > Steve
> >



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2INUCR14216 for ietf-pkix-bks; Mon, 18 Mar 2002 15:30:12 -0800 (PST)
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 g2INUA414210 for <[e-mail]>; Mon, 18 Mar 2002 15:30:10 -0800 (PST)
Received: from tsg1 ([12.81.78.48]) by mtiwmhc21.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020318233007.TZPF19351.mtiwmhc21.worldnet.att.net@tsg1>; Mon, 18 Mar 2002 23:30:07 +0000
Message-ID: <02e801c1ced4$d1f24a30$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: "Peter Sylvester" <[e-mail]>, <[e-mail]>, <[e-mail]>, "vint cerf" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <005c01c1ce80$22054130$020aff0c@tsg1> <p05100300b8bbc109bd96@[128.33.238.54]>
Subject: Re: DPD/DPV reqmts strawpoll
Date: Mon, 18 Mar 2002 15:29:56 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve you chair is not a throne. really its not.

T.
----- Original Message -----
From: "Stephen Kent" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: "Peter Sylvester" <[e-mail]>; <[e-mail]>;
<[e-mail]>; "vint cerf" <[e-mail]>; <[e-mail]>
Sent: Monday, March 18, 2002 9:57 AM
Subject: Re: DPD/DPV reqmts strawpoll


> At 5:23 AM -0800 3/18/02, todd glassey wrote:
> >I would hate to think that the WG Chairs used any kind of Email
Blacklisting
> >or other Blacklisting processes - that would be blatantly a problem for
the
> >ruling class here.
> >
> >Todd
> >
>
> Two observations:
>
> First, as Peter later noted, he was making a tongue in cheek comment
> re blacklisting.
>
> Second, if you were more familiar with IETF history you might be
> aware of rare instances where individuals have been banned from
> mailing lists due to persistent, egregious behavior. Your behavior
> has not yet reached a point where such measures are warranted, but
> you're working on it.
>
> Steve
>



Received: by above.proper.com (8.11.6/8.11.3) id g2IN2tq13499 for ietf-pkix-bks; Mon, 18 Mar 2002 15:02:55 -0800 (PST)
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 g2IN2r413495 for <[e-mail]>; Mon, 18 Mar 2002 15:02:53 -0800 (PST)
Received: from [166.63.189.50] (SSH.BBN.COM [192.1.50.70]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA01200; Mon, 18 Mar 2002 18:01:17 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@127.0.0.1 (Unverified)
Message-Id: <p05100300b8bbc109bd96@[128.33.238.54]>
In-Reply-To: <005c01c1ce80$22054130$020aff0c@tsg1>
References: <[e-mail]> <005c01c1ce80$22054130$020aff0c@tsg1>
Date: Mon, 18 Mar 2002 12:57:56 -0500
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: DPD/DPV reqmts strawpoll
Cc: "Peter Sylvester" <[e-mail]>, <[e-mail]>, <[e-mail]>, "vint cerf" <[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>

At 5:23 AM -0800 3/18/02, todd glassey wrote:
>I would hate to think that the WG Chairs used any kind of Email Blacklisting
>or other Blacklisting processes - that would be blatantly a problem for the
>ruling class here.
>
>Todd
>

Two observations:

First, as Peter later noted, he was making a tongue in cheek comment 
re blacklisting.

Second, if you were more familiar with IETF history you might be 
aware of rare instances where individuals have been banned from 
mailing lists due to persistent, egregious behavior. Your behavior 
has not yet reached a point where such measures are warranted, but 
you're working on it.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2IM7GB12147 for ietf-pkix-bks; Mon, 18 Mar 2002 14:07:16 -0800 (PST)
Received: from nyc02.smtp.stsn.com (p8.usnyc1.stsn.com [199.106.216.8]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2IM7E412142 for <[e-mail]>; Mon, 18 Mar 2002 14:07:14 -0800 (PST)
Received: from host66160 ([10.0.227.134]) by nyc02.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 18 Mar 2002 17:13:10 -0700
Message-ID: <008201c1ceca$21f7fb20$86e3000a@host66160>
Reply-To: "Yuriy Dzambasow" <[e-mail]>
From: "Yuriy Dzambasow" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "pkix" <[e-mail]>
References: <[e-mail]>
Subject: Re: DPD/DPV reqmts
Date: Mon, 18 Mar 2002 17:13:26 -0500
Organization: Digital Signature Trust
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-OriginalArrivalTime: 19 Mar 2002 00:13:10.0578 (UTC) FILETIME=[DA6BE120:01C1CEDA]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

Thank you for responding and for agreeing to incorporate some of my
comments.  I have some additional responses below.

Yuriy


..snip...

>
> [COMMENT 19]
>
> 1) Recommend deleting the 2nd paragraph on page 5 (Section 5) for the
> following reasons:
>         - the first sentence attempts to qualify the preceding paragraph,
> and in my
> opinion, adds no additional value
>         - the second sentence contains redundant information already
defined
> two
> paragraphs above
>
> [Answer 19]
>
> The second paragraph on page 5 (Section 5) is:
>
> Clients MUST be able to specify whether they want, in addition to the
> certification path, the revocation information associated with the
> path, for the end-entity certificate only, for the CA certificates
> only or for both.
>
> This text is not redundant. You are certainly pointing to another
paragraph.
> Next time, please provide a short extract.

Sorry about that.  The text in question is the following, which is defined
in Section 5:

"The client needs to be able to limit the number of paths returned.
Therefore the client MUST be able to indicate the maximum number of
certification paths that SHOULD be returned (provided that they can be
found). If the number is not specified, that number defaults to one.

The paths that are returned may need to match some additional local
controls done by the client, e.g. verifying some certificate
extensions.

The returned paths may not be appropriate to the client when it
locally applies additional tests. Instead of asking one by one the
paths (which would require state information at the server), the
client specifies with every request the maximum number of paths
to be returned."

It's the 3rd paragraph that I recommend deleting for the reasons I provided
earlier.

...snip...

>
> [COMMENT 23]
>
> 1) Why does DPD say that it is OK to pass some policy parameters within a
> DPD request if the policy is simple enough (section 5), but just the
> opposite is said for DPV (section 4)?  I would think that a simple policy
> could be adhered to as well for DPV, and that the parameter specification
> could occur within the DPV request.
>
> [Answer 23]
>
> The document does not provide details about what means "simple". However
the
> idea is the following: when there is a single root, with no constraints
> (unless contained in the self-signed certificate itself) and when any CRL
> status information is acceptable, then the policy can be considered as
> simple. Specific checks on the end-certificate are always done locally.
>
> With DPV the policy has to say which CRL information is necessary for each
> leg. But the most important is that checks on the end-certificate have to
be
> done remotely and specifying them is that not simple.

I disagree.  A client can merely provide a root certificate and a policy ID,
and the server can do everything else to respond to a DPV request.  In this
scenario, the additional policy parameters have been defined locally at the
server (e.g., which CRL information to use for each leg of the certificate.)
I still believe it is appropriate for a client to specify this simple policy
information (i.e., root cert and policy ID) within the DPV request.

...snip...

>
> [COMMENT 25]
>
> 3) Section 8:  I think it would be helpful to break out the PDP
requirements
> section into two areas:
>
> 1) requirements around the coordination of a validation/path discovery
> policy
> between a client and a server to support the validation/path discovery for
> a given certificate; and
>
> 2) requirements around defining an authorized policy at a server (e.g.,
used
> by security managers).
>
> This makes it clear that PDP can be used in two distinct ways.
>
> [Answer 25]
>
> PDP only addresses the later. It is unclear what is being requested for
the
> first area. Please explain.

In section 8 it says, "Usually, these request/response pairs will be used by
security managers to register the policies to be used by ordinary clients,
such as those
within an organization for use with various applications."

It is this paragraph that made me believe that PDP would be used by clients
as well as security managers.  Hence, my comment.

...snip...



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2IHhU902971 for ietf-pkix-bks; Mon, 18 Mar 2002 09:43:30 -0800 (PST)
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 g2IHhS402966 for <[e-mail]>; Mon, 18 Mar 2002 09:43:28 -0800 (PST)
Received: from tsg1 ([12.81.70.164]) by mtiwmhc21.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020318174324.IEXP19351.mtiwmhc21.worldnet.att.net@tsg1>; Mon, 18 Mar 2002 17:43:24 +0000
Message-ID: <012f01c1cea4$63df1fd0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Otto Mueller" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: <draft-ietf-pkix-pi-03.txt>
Date: Mon, 18 Mar 2002 09:43:17 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I would second this proposal.

T.
----- Original Message -----
From: "Otto Mueller" <[e-mail]>
To: <[e-mail]>
Sent: Monday, March 18, 2002 7:33 AM
Subject: WG: <draft-ietf-pkix-pi-03.txt>

-----Ursprüngliche Nachricht-----
Von: Otto Mueller [mailto:[e-mail]]
Gesendet: Monday, March 18, 2002 3:58 PM
An: [e-mail]
Cc: MESROPIAN, Andre; THIENOT, Alain; MUELLER, Adrian
Betreff: <draft-ietf-pkix-pi-03.txt>


Dear D. Pinkas and T. Gindin,
We have read with great interest the Draft PKIX Standard for Permanent
identifiers. According to our experience with PKI, there is a real demand
for such identifiers.
Schemes according to ISO-6523 may be allocated with an ICD (= OID under the
arc 1.3.). This fits perfectly into this new standard. Therefore we suggest
to add a new annex to your draft. If you feel that it sounds to much like an
advertisement for the EDIRA association feel free to change it.
We suggest the following:
"
B.3. Using an ICD (International Code Designator) from British Standards
Institution

Organizations running a scheme according to ISO-6523 (standard for
identification and registration of organization identification schemes) may
apply for an ICD value. An ICD value is equivalent to an OID under the arc
{iso (1) org(3)}. Registration Authority for ICD values is BSI (British
Standards Institution). For registration, a "Sponsoring Authority" has to
vouch for the applying organization. An example of such a Sponsoring
Authority is the EDIRA Association (EDI/EC Registration Authority, web:
http://www.edira.org, email:[e-mail]). Registration is not free.
BSI maintains a list of all issued ICDs (ICD-list.htm) which is stored at
http://xw2k.sdct.itl.nist.gov/l8/Website-pages/draft.htm
"

Regards,
Adrian Mueller EDIRA Webmaster
Otto Mueller EDIRA Chairman





Received: by above.proper.com (8.11.6/8.11.3) id g2IG9D625488 for ietf-pkix-bks; Mon, 18 Mar 2002 08:09:13 -0800 (PST)
Received: from [165.227.249.20] (the [166.63.187.194] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2IG9A425480; Mon, 18 Mar 2002 08:09:10 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05101410b8bbc0d1e37a@[165.227.249.20]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 18 Mar 2002 08:07:31 -0800
To: "Sean P. Turner" <[e-mail]>, PKIX <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: OCKID Question?
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>

At 8:52 AM +1200 3/18/02, Sean P. Turner wrote:
>I'm just
>curious why the only choices included are the EE, CA, AA, and bare key.

Because those were what I had thought of

>There are other things that you trust in the PKIX realm like OCSP
>responders.

Sounds good; I can add it.

>   If the trouble was trying to profile it so that you'd know
>it was and OCSP responder  you could look for id-kp-OCSPSigning OBJECT
>IDENTIFIER ::= {id-kp 9} in extended key usage.  I'm sure there are
>others but that's the one that popped to the top.

If there are others, please send them to me or the PKIX mailing list.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2IFbJR21443 for ietf-pkix-bks; Mon, 18 Mar 2002 07:37:19 -0800 (PST)
Received: from smtp.vtx.ch (smtp1.vtx.ch [212.147.0.55]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2IFbH421439 for <[e-mail]>; Mon, 18 Mar 2002 07:37:17 -0800 (PST)
Received: from DRIQ5R5E5R3723 (unknown [212.147.70.133]) by smtp.vtx.ch (VTX Services) with SMTP id 05640FBE1 for <[e-mail]>; Mon, 18 Mar 2002 16:37:07 +0100 (CET)
From: "Otto Mueller" <[e-mail]>
To: <[e-mail]>
Subject: WG: <draft-ietf-pkix-pi-03.txt>
Date: Mon, 18 Mar 2002 16:33:40 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
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.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----Ursprüngliche Nachricht-----
Von: Otto Mueller [mailto:[e-mail]]
Gesendet: Monday, March 18, 2002 3:58 PM
An: [e-mail]
Cc: MESROPIAN, Andre; THIENOT, Alain; MUELLER, Adrian
Betreff: <draft-ietf-pkix-pi-03.txt>


Dear D. Pinkas and T. Gindin,
We have read with great interest the Draft PKIX Standard for Permanent
identifiers. According to our experience with PKI, there is a real demand
for such identifiers.
Schemes according to ISO-6523 may be allocated with an ICD (= OID under the
arc 1.3.). This fits perfectly into this new standard. Therefore we suggest
to add a new annex to your draft. If you feel that it sounds to much like an
advertisement for the EDIRA association feel free to change it.
We suggest the following:
"
B.3. Using an ICD (International Code Designator) from British Standards
Institution

Organizations running a scheme according to ISO-6523 (standard for
identification and registration of organization identification schemes) may
apply for an ICD value. An ICD value is equivalent to an OID under the arc
{iso (1) org(3)}. Registration Authority for ICD values is BSI (British
Standards Institution). For registration, a "Sponsoring Authority" has to
vouch for the applying organization. An example of such a Sponsoring
Authority is the EDIRA Association (EDI/EC Registration Authority, web:
http://www.edira.org, email:[e-mail]). Registration is not free.
BSI maintains a list of all issued ICDs (ICD-list.htm) which is stored at
http://xw2k.sdct.itl.nist.gov/l8/Website-pages/draft.htm
"

Regards,
	Adrian Mueller	EDIRA Webmaster
	Otto Mueller	EDIRA Chairman




Received: by above.proper.com (8.11.6/8.11.3) id g2IEqZN20081 for ietf-pkix-bks; Mon, 18 Mar 2002 06:52:35 -0800 (PST)
Received: from noc-e.ietf53.cw.net (noc-e.ietf53.cw.net [166.63.177.40]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2IEqX420074; Mon, 18 Mar 2002 06:52:33 -0800 (PST)
Received: from ieca.com (tweety.ietf53.cw.net [166.63.188.103]) by noc-e.ietf53.cw.net (Postfix) with ESMTP id 1EA506A90D; Mon, 18 Mar 2002 10:37:05 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Mon, 18 Mar 2002 08:52:48 +1200
From: "Sean P. Turner" <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: PKIX <[e-mail]>
Cc: "Hoffman, Paul" <[e-mail]>
Subject: OCKID Question?
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>

Paul,

I had a read of the OCKID draft - what a novel concept :)  I'm just
curious why the only choices included are the EE, CA, AA, and bare key.
There are other things that you trust in the PKIX realm like OCSP
responders.  If the trouble was trying to profile it so that you'd know
it was and OCSP responder  you could look for id-kp-OCSPSigning OBJECT
IDENTIFIER ::= {id-kp 9} in extended key usage.  I'm sure there are
others but that's the one that popped to the top.

Cheers,

spt




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2IDO8m13446 for ietf-pkix-bks; Mon, 18 Mar 2002 05:24:08 -0800 (PST)
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 g2IDO6413441 for <[e-mail]>; Mon, 18 Mar 2002 05:24:06 -0800 (PST)
Received: from tsg1 ([12.81.70.164]) by mtiwmhc21.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020318132351.ZZQN19351.mtiwmhc21.worldnet.att.net@tsg1>; Mon, 18 Mar 2002 13:23:51 +0000
Message-ID: <005c01c1ce80$22054130$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: "vint cerf" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: DPD/DPV reqmts strawpoll
Date: Mon, 18 Mar 2002 05:23:44 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I would hate to think that the WG Chairs used any kind of Email Blacklisting
or other Blacklisting processes - that would be blatantly a problem for the
ruling class here.

Todd

----- Original Message -----
From: "Peter Sylvester" <[e-mail]>
To: <[e-mail]>; <[e-mail]>; <[e-mail]>;
<[e-mail]>
Sent: Monday, March 18, 2002 1:56 AM
Subject: Re: DPD/DPV reqmts strawpoll


>
>
>
> > I may be on their black list.
>
> In a private mail I was informed that this statement
> can be easily misunderstood.
>
> I should have added some kind of smiley here.
> No harm intended and thanks to Steve for his immediate response.
> Peter
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2ID72912523 for ietf-pkix-bks; Mon, 18 Mar 2002 05:07:02 -0800 (PST)
Received: from fep13-svc.tin.it (mta13-acc.tin.it [212.216.176.44]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2ID70412518 for <[e-mail]>; Mon, 18 Mar 2002 05:07:00 -0800 (PST)
Received: from skossa.andxor.it ([62.211.197.113]) by fep13-svc.tin.it (InterMail vM.4.01.03.13 201-229-121-113) with ESMTP id <[e-mail]>; Mon, 18 Mar 2002 14:06:49 +0100
Received: (from tho@localhost) by skossa.andxor.it (8.11.3/8.11.3) id g2ID5ur02632; Mon, 18 Mar 2002 14:05:56 +0100 (CET) (envelope-from tho)
Date: Mon, 18 Mar 2002 14:05:56 +0100
From: tho <[e-mail]>
To: Denis Pinkas <[e-mail]>, Peter Sylvester <[e-mail]>, [e-mail], Andrea Caccia <[e-mail]>, Stefan Kraxberger <[e-mail]>, [e-mail], [e-mail], Peter Gutmann <[e-mail]>, Raffaello Galli <[e-mail]>, Romano Pedroli <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: Re: TSP interoperability testing
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Fri, Mar 15, 2002 at 03:02:30PM +0100
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>

On Fri, Mar 15, 2002 at 03:02:30PM +0100, Denis Pinkas wrote:
> Thomas (and all the TSP list)
> 
> On January 8, I thanked you for taking the lead of the testing, but until
> now, I have not seen any result, according to RFC 2026.

Denis, I've posted the first tranche of results with regard to my test vector 
on Jan 10 (i.e. iaik, sia, datum, c&a, politecnico di torino, edelweb).

Very little feedback I have seen.

on Jan 17 I've posted the results of cryptoapps implementation's testing and 
in that occasion I've also asked questions that weren't never answered - in 
particular the one about an available (non-buggy) CMS verfier without which 
it is not possible to test the very heart of the protocol.
(the problem being the id-ct-TSTInfo eContentType which is not supported by 
the entirety of CMS client software in my hard disk)

I have been active in the last months in trying to weave the web between the
TSP implementers, in testing (and feedbacking about that) a number of client 
and server implementations, but unfortunately it seems it has not been much
useful...

> On February 18, I have sent a table for helping, but until now, no one has
> indicated that he had started to fill in the matrix.

<polemic>
it seems you are suffering the same problem I've experienced ;-)
</polemic>

joking aside, without a CMS verifier I can't complete the testing activity
but self-certifying my TSP server implementation (i.e. I temporarily break
rfc3161 specs by replacing id-ct-TSTInfo with id-Data in my server's code 
just to verify the signature upon TSTInfo).

If you are interested in an incomplete testing documentation or in a 
*self-certified* one I can for sure send you my results.

Regards, Thomas
--


Received: by above.proper.com (8.11.6/8.11.3) id g2I9ufu28221 for ietf-pkix-bks; Mon, 18 Mar 2002 01:56:41 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2I9ud428217 for <[e-mail]>; Mon, 18 Mar 2002 01:56:39 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id KAA23236; Mon, 18 Mar 2002 10:56:37 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 18 Mar 2002 10:56:38 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id KAA11228; Mon, 18 Mar 2002 10:56:36 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id KAA27364; Mon, 18 Mar 2002 10:56:35 +0100 (MET)
Date: Mon, 18 Mar 2002 10:56:35 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: DPD/DPV reqmts strawpoll
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> I may be on their black list.

In a private mail I was informed that this statement
can be easily misunderstood. 

I should have added some kind of smiley here. 
No harm intended and thanks to Steve for his immediate response.
Peter


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2I8IIF13381 for ietf-pkix-bks; Mon, 18 Mar 2002 00:18:18 -0800 (PST)
Received: from gateway.secude.com (linux.secude.com [141.12.207.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2I8IH413371 for <[e-mail]>; Mon, 18 Mar 2002 00:18:17 -0800 (PST)
Received: from remus.secude.com (remus.intranet.secude.com [192.168.2.2]) by gateway.secude.com (Postfix) with ESMTP id 37AF28EB3; Mon, 18 Mar 2002 09:18:11 +0100 (CET)
Received: from secude.com (obelix.intranet.secude.com [192.168.1.3]) by remus.secude.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id GX1TNXCC; Mon, 18 Mar 2002 09:18:10 +0100
Message-ID: <[e-mail]>
Date: Mon, 18 Mar 2002 09:20:46 +0100
From: Petra Barzin <[e-mail]>
X-Mailer: Mozilla 4.73 [de]C-CCK-MCD DT  (Win95; U)
X-Accept-Language: de
MIME-Version: 1.0
To: Peter Williams <[e-mail]>
Cc: [e-mail]
Subject: Re: DPD/DPV reqmts: hash of the request
References: <[e-mail]>
Content-Type: text/html; 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>

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Peter,
<p>as far as I know, OCSP doesn't support the hash of the request in its
<br>responses but it uses nonces to bind the response back to the request.
<br>The use of nonces is up to the client but if the client includes a
nonce
<br>in his request the server CANNOT use pre-calculated OCSP responses!
<p>Quotation of OCSP:
<blockquote TYPE=CITE>
<pre>If a nonce is included in a request, then the&nbsp;&nbsp;
response MUST contain the same nonce. Responses&nbsp;&nbsp;
without the same nonce MUST NOT be trusted.</pre>
</blockquote>

<p><br>Of course, most of the content of an OCSP answer (except of the
nonce)
<br>can be pre-calculated. But the same is true for DPD/DPV. You can
<br>cache validation results and re-use this information. But you cannot
<br>pre-produce the whole answer. So it's exactly the same as with OCSP!
<p>Petra
<br>&nbsp;
<p>Peter Williams schrieb:
<blockquote TYPE=CITE>Can you state a rationale why DPV/DPD
<br>design on the issue should be different to the
<br>OCSP design on the same issue?
<p>OCSP supports pre-calculated OCSP responses,
<br>based on OCSP relaying certificate status information
<br>from a repository.
<p>Why should DPV not support pre-calculation
<br>of one or more sets of validation policy rules against
<br>a chain of certificates?
<p>Is there a basis for believing that DPV protocol
<br>is more vulnerable that OCSP protocol in respect
<br>of the known risks of using pre-calculated (i.e. cached)
<br>results?
<p>Accessing a historical repository of DPV results
<br>will be quite common, I expectm in support of NR.
<br>Periodically,
<br>the operator will calculate for a large
<br>number of certificates with historical
<br>certificate status what the validation policy
<br>would have been, if evaluated at that historical
<br>point in time.
<p>-----Original Message-----
<br>From: Petra Barzin [<a href="mailto:[e-mail]">mailto:[e-mail]</a>]
<br>Sent: Wednesday, March 06, 2002 1:37 PM
<br>To: Michael Myers
<br>Cc: Housley, Russ; [e-mail]; [e-mail]
<br>Subject: Re: DPD/DPV reqmts: hash of the request
<p>Mike,
<p>do I understand you correctly, that you propose to mark the
<br>requirement (binding the response back to the request) as
<br>optional and leave it up to the implementation of the DPV
<br>client and server to realize this binding?
<br>I'm afraid this will lead to unnecessary interoperability problems
<br>between implementations of a DPV client and server, e.g. if a
<br>client implementation requires this binding, but it's not implemented
<br>at the server. If we feel that the binding adds value to the protocol
<br>- and I think it does - we should mandate its use! You can still
<br>cache the information and re-use them, you just cannot preproduce
<br>the whole response.
<p>Petra
<p>Michael Myers schrieb:
<p>> Petra,
<br>>
<br>> In my opinion we should enable the practice by ensuring the
<br>> capability is in running code but not mandate its use in all
<br>> circumstances.&nbsp; Do you find this approach acceptable?
<br>>
<br>> Mike
<br>>
<br>> > -----Original Message-----
<br>> > From: Petra Barzin [<a href="mailto:[e-mail]">mailto:[e-mail]</a>]
<br>> > Sent: Tuesday, March 05, 2002 12:17 PM
<br>> > To: Housley, Russ
<br>> > Cc: '[e-mail] '; '[e-mail] ';
<br>> > [e-mail]
<br>> > Subject: Re: DPD/DPV reqmts: hash of the request
<br>> >
<br>> >
<br>> > Yes, the requirement is to bind the response back to
<br>> > the request!
<br>> > Sorry for the technical discussion at this point.
<br>> > I'd see the requirement as a MUST, but I can see
<br>> > Michael's concern
<br>> > that it prevents the use of pre-produced responses.
<br>> > But I think it is very important that the sender of a
<br>> > DPV request
<br>> > is able to match the received response to his request
<br>> > in order to
<br>> > make sure that no man in the middle changed his
<br>> > validation request.
<br>> >
<br>> > - Petra
<br>> >
<br>> > "Housley, Russ" schrieb:
<br>> >
<br>> > > In my opinion, the requirement is to bind the
<br>> > respponse back to the request.
<br>> > > Two obvious was to accomplish this binding are to
<br>> > include all of the fields
<br>> > > of the request in the response and to include a
<br>> > hash of the request in the
<br>> > > response.&nbsp; Since we are working on the requirements
<br>> > doucment, we should
<br>> > > stict to requirements, not mechanisms for
<br>> > implementing the requirements.
<br>> > >
<br>> > > Russ
<br>> > >
<br>> > > -----Original Message-----
<br>> > > From: Petra Barzin
<br>> > > To: [e-mail]
<br>> > > Cc: [e-mail]
<br>> > > Sent: 3/3/02 3:48 PM
<br>> > > Subject: DPD/DPV reqmts: hash of the request
<br>> > >
<br>> > > Denis,
<br>> > >
<br>> > > I don't see why you differentiate between signed
<br>> > and authenticated
<br>> > > responses. The same is true for signed responses:
<br>> > either the hash of
<br>> > > the request or the important elements from the
<br>> > request must be present.
<br>> > > In order to test the response against what has been
<br>> > requested the client
<br>> > >
<br>> > > has to keep his request or at least the hash of his request.
<br>> > >
<br>> > > The advantage of a hash - instead of copying all
<br>> > important elements
<br>> > > from the request -&nbsp; is:
<br>> > > (a) that the response will be smaller and
<br>> > > (b) adding a new important element to the request
<br>> > doesn't require a
<br>> > > change of the response.
<br>> > >
<br>> > > - a hash of the request MUST be included in the response.
<br>> > >
<br>> > >&nbsp;&nbsp; This may allow the client to check if his request
<br>> > was maliciously
<br>> > >
<br>> > >&nbsp;&nbsp; modified (if the response is signed) and helps to
<br>> > associate the
<br>> > >
<br>> > >&nbsp;&nbsp; response with his request when using
<br>> > connectionless protocols.
<br>> > >
<br>> > >&nbsp;&nbsp; [Answer 1] The requirements are different whether
<br>> > the requester simply
<br>> > > wants
<br>> > >
<br>> > >&nbsp;&nbsp; an authenticated response or a signed response.
<br>> > For a signed response
<br>> > > the
<br>> > >
<br>> > >&nbsp;&nbsp; inclusion of the important elements from the
<br>> > request is needed, so
<br>> > > that a
<br>> > >
<br>> > >&nbsp;&nbsp; response can be individually tested against what
<br>> > has been requested.
<br>> > > For an
<br>> > >
<br>> > >&nbsp;&nbsp; authenticated response, the hash of the request
<br>> > is sufficient. To
<br>> > > summarize:
<br>> > >
<br>> > >&nbsp;&nbsp; - for signed responses, the important elements
<br>> > from the request
<br>> > >
<br>> > >&nbsp;&nbsp;&nbsp;&nbsp; must be present.
<br>> > >
<br>> > >&nbsp;&nbsp; - for authenticated responses, either the hash of
<br>> > the request or the
<br>> > >
<br>> > >&nbsp;&nbsp;&nbsp;&nbsp; important elements from the request must
be present.
<br>> > >
<br>> > > - Petra
<br>> >
<br>> ></blockquote>
</html>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2G3TsD21990 for ietf-pkix-bks; Fri, 15 Mar 2002 19:29:54 -0800 (PST)
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 g2G3Tk421985 for <[e-mail]>; Fri, 15 Mar 2002 19:29:52 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz ([e-mail] [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id QAA17412; Sat, 16 Mar 2002 16:29:44 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id QAA39851; Sat, 16 Mar 2002 16:29:44 +1300 (NZDT) (sender [e-mail])
Date: Sat, 16 Mar 2002 16:29:44 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Candidate for moving OCSP to a Draft Standard
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>

Juergen Brauckmann <[e-mail]> writes:

>In the ISISMTT stuff there is a similar OCSP extension which is intended to
>allow the server to send the hash of the certificatein question back to the
>client.
>
>The problem with a simple boolean is IMO that it's not sure whether server and
>client are talking about the same certificate.

I gave up on all the strange identifiers which people keep inventing for certs
in PKI protocols and just put an ESSCertID in all my requests (OCSP, CMP, etc
etc), which solves the problem nicely :-).

>If we worry about certificates with a valid signature that may not be issued
>by a CA, than it should be possible for the client to check somehow that the
>server knows not only about a certificate which happen to have an IssuerDN and
>a serialnumber identical to that the client has, but that is entirely
>identical to it. This can be achieved by a server which sends a hash of a
>certificate back to the client, and the client then checking this hash.

That's another way of doing it... I went for the client-supplied-hash because
then the responder can be implemented as a straight lookup in an in-memory hash
table, which is extremely fast and efficient.

>In a normal PKIX way of doing status checking and path validation, you don't
>need to worry about never issued certificates.

You do for CMP, which speculatively issues certs to EEs.

(You also have the problem that if you design a system in which you wish away
 certain hard security problems, you end up in serious trouble if any of those
 problems do ever occur.  I'd rather be paranoid and cover all the angles, even
 the ones which should never occur).

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2G1O8719785 for ietf-pkix-bks; Fri, 15 Mar 2002 17:24:08 -0800 (PST)
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 g2G1O6419781 for <[e-mail]>; Fri, 15 Mar 2002 17:24:06 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.us.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id UAA153822; Fri, 15 Mar 2002 20:20:44 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g2G1O0S206690; Fri, 15 Mar 2002 20:24:01 -0500
Importance: Normal
Sensitivity: 
Subject: Re: Updating RFC 3039 - and its impact on PI
To: Stefan Santesson <[e-mail]>
Cc: Denis Pinkas <[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: Fri, 15 Mar 2002 20:23:52 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.9a |January 28, 2002) at 03/15/2002 08:24:02 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>

      Stefan:

      Are you proposing that the syntax of attribute semantics be changed
from RFC 3039 or not?  The syntax in RFC 3039 does not seem sufficient to
replace PI since it fails to bind registration authorities (and multiple
ones are permitted within it) to attributes directly.  Is anyone using this
at present?
      Furthermore, binding this function to QC's would, by itself, make the
feature less useful than PI's.  Publishing it there is a different matter.

            Tom Gindin


Stefan Santesson <[e-mail]>@mail.imc.org on 03/15/2002 06:52:54
PM

Sent by:    [e-mail]


To:    Denis Pinkas <[e-mail]>
cc:    [e-mail]
Subject:    Re: Updating RFC 3039 - and its impact on PI



Denis,

I will be more specific but I didn't want to take up to much space in the
start of the discussion

I'm not ready to suggest text replacement right now but the key usage
restriction should go and at least allow, without any restriction,
combination of digital signature AND non-repudiation.

For attribute semantics I think today that any such declaration has nothing

to do with any legal statements concerning qualified certificates. Having
that function in its current extension is to me a defect. If you want me to

be more specific I have to owe you but I wont' have trouble to come up with

examples and reasons.

I will also rise these problems with ETSI.

This was just an initiation of the discussion and I expect to discuss more
with you and others at Minneapolis.

Especially concerning assassination of PI :-)

/Stefan

At 15:03 2002-03-15 +0100, Denis Pinkas wrote:

>Stefan,
>
>See some comments below:
>
> > As author and implementer of RFC 3039 and in the light of practical
> > experience with RFC 3039, I think we should be ready to revise this RFC
> > and handle some defects.
> >
> > The defects I have recorded so far are:
> >
> > 1) Key usage
> > The key usage bit non-repudiation SHOULD NOT be set together with any
> > other key usage according to RFC 3039. This has caused a lot of
confusion
> > and this "SHOULD NOT" statement is not compatible with existing
reality.
>
>Could you be more explicit about a suggested text replacement ?
>
> > 2) Attribute semantics
> > This function to define semantics for attributes included in the
subject
> > field is very useful and it covers almost everything that the current
PI
> > draft wants to solve.
>
>Could you be more specific ?
>
> > The problem is that this function is part of the
> > qcStatements extension which it should not be. Firstly due to the fact
> > that this statement has nothing to do with the intent of this extension
> > and secondly because criticality setting for this function get mixed up
> > with completely unrelated stuff in its current form.
>
> > 3) Usage and purpose
> > RFC 3039 is the only RFC defining structure of a personal ID
certificate.
> > This should not be limited just to Qualified certificates. It should be
> > more clear that this RFC is useful for any personal ID certificate.
Also
> > non-qualified ones.
>
>Fine.
>
> > Finally I believe that a revision of RFC 3039 should include
> > considerations to avoid the need for a PI extension according to the PI
> > draft.
> >
> > I can't see that the PI draft accomplish anything that RFC 3039 doesn't
> > already solve, or at least would solve after revision.
>
>The revised document will not be able to solve what the PI document covers
>since the PI document applies to *any entity* whereas the revised RFC 3039
>document is planned to apply only to *personal ID certificates*. Maybe the
>revised RFC 3039 could take advantage and refer to the PI document.
>
> > The only exception is the function to define an identifier completely
> > independent of the subject name.
>
>Thank you for noticing this difference.
>
>Regards,
>
>Denis
>
> > I would tough argue that the total case with all aspects on
> > the table probably doesn't justify another feature for that and that
there
> > are other ways to solve this within the realm of X.509 and PKIX
standards.
>
> > I still believe that a creative revision of RFC 3039 could be made to
> > cover what we need in this area. And I also recall this as an initially
> > defined possibility laid down for the PI work.
>
> > /Stefan







Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2G0Ype18948 for ietf-pkix-bks; Fri, 15 Mar 2002 16:34:51 -0800 (PST)
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 g2G0Yn418944 for <[e-mail]>; Fri, 15 Mar 2002 16:34:49 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA04699; Fri, 15 Mar 2002 19:34:35 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100319b8b8408c9171@[128.89.88.34]>
In-Reply-To: <01b701c1cc78$695c8f20$020aff0c@tsg1>
References: <[e-mail]> <01b701c1cc78$695c8f20$020aff0c@tsg1>
Date: Fri, 15 Mar 2002 19:33:05 -0500
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: TSP interoperability testing
Cc: "Peter Sylvester" <[e-mail]>, <[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>

At 3:23 PM -0800 3/15/02, todd glassey wrote:
>Mr. Kent - when did you do this and isn't there an issue of propriety  in
>this decision?

Todd,

The requirement for progression of an RFC is that we document 
interoperability among at least two independent implementations of 
the protocol in question. The documentation is provided by the folks 
who have performed the testing, usually folks who have implemented 
the protocol, and thus this is typically a distributed activity. 
That's what has happened here. The PKIX list has received numerous 
accounts of TSP testing experiences from a number of implementors of 
TSP clients and servers over several months. I asked Denis, as the 
RFC author, to collect the received info and construct the required 
documentation for submission to the IESG. This is exactly what we did 
for OCSP recently; I believe Ambarish led that effort and he too was 
an author of the relevant RFC.

I see no problem with this approach in general, given the diverse set 
of folks who typically provide the inputs.  I would worry of we had 
only a couple of implementations of a protocol and there might be 
some concern re collusion, but that is not the case for TSP, since it 
is a simple protocol and thus not hard to implement for either the 
client or server side.  Bigger protocols pose more of a problem in 
terms of the scope of interoperability testing and diversity of 
implementations.

Steve



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2G0IU518635 for ietf-pkix-bks; Fri, 15 Mar 2002 16:18:30 -0800 (PST)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2G0IS418631 for <[e-mail]>; Fri, 15 Mar 2002 16:18:28 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 15 Mar 2002 16:17:23 -0800 (PST)
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, 15 Mar 2002 16:17:23 -0800 (PST)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <GK1PQ440>; Fri, 15 Mar 2002 16:18:16 -0800
Content-return: allowed
Date: Fri, 15 Mar 2002 16:18:09 -0800
From: Peter Williams <[e-mail]>
Subject: RE: Attribute Certificates and Privilege Policy
To: "'Christopher S. Francis'" <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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>

IETF has a simple choice to make
in my view, in its profiling of X.509 
PMI.

It either contiues to bastardize the PMI into
an "attribute-cert framework", for
sending DoD and NATO clearances
around with those S/MIME implementations
doing MAC, 

Or,


It use PMI for real **privilege** management, not 
conveying  "attributes" about PKI subjects
under some ambiguous control model,
neeing ambiguous CPSs to establish meaning.

Currently, there is no evidence of any real
use of "Privilege" in IETF's profiling of 
the PMI. Its just using the AC as a syntax for 
expressing attributes about subjects. ACPROF
doesnt even call an AA an AA, it calls
it an AC issuer, presumably so folks are not
bound to the ISO semantics of AAs and SOAs.

Whilst DOD in DMS S/MIME does have real privileges
to be managed, which are not mere authorization
attributes representing clearnaces, they dont seem
to surface much in ACPROF's implied control and
issuing model.

Peter.
-----Original Message-----
From: Christopher S. Francis [mailto:[e-mail]]
Sent: Friday, March 15, 2002 11:58 AM
To: Denis Pinkas; Sharon Boeyen
Cc: [e-mail]
Subject: RE: Attribute Certificates and Privilege Policy



I concur with Denis.  It seems entirely reasonable that an AA may want to
apply different levels of verification of the attributes presented in the
ACs that it issues.

Just as commercial CAs issue PK certificates under various policies,
charging higher prices for higher levels of assurance, an Attribute
Authority may want to issue ACs under various policies, with different
levels of assurance based on the level of verification of the asserted
attributes.

Chris

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Denis Pinkas
Sent: Friday, March 15, 2002 12:50 PM
To: Sharon Boeyen
Cc: '[e-mail]'
Subject: Re: Attribute Certificates and Privilege Policy


Sharon,

Yes, this is indeed a very long e-mail. Mine will be shorter.

Shortly speaking, the "privilege policy" is the equivalent of a
"validation policy" (see the DPV requ. draft availmable from
http://www.imc.org/draft-ietf-pkix-dpv-dpd-req), but it is NOT
the equivalent of a certification policy.

You said: "In terms of 'why no certificate policy' - there was no need
identified for an equivalent".

For CAs there are different levels of verification of the identity presented
at the time of registration. This level is "visible" through the certificate
policy.

I do not see why we should not draw a parallel with attributes, where for
AAs there would be different levels of verification of the attributes
presented at the time of registration. This level would be "visible" through
the "attribute policy".

A validation policy (i.e. privilege policy using the ISO terminology) may
consider that some attribute policies are adequate and that some others are
not.

Otherwise, the single way to trust is to use the name of the AA.

If an AA supports different "attribute policies", it would have to change
its
name, each time. :-(

Thus I see a good reason to have an equivalent.

Regards,

Denis




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2FNqv717912 for ietf-pkix-bks; Fri, 15 Mar 2002 15:52:57 -0800 (PST)
Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2FNqt417908 for <[e-mail]>; Fri, 15 Mar 2002 15:52:56 -0800 (PST)
Received: from stsIBMT20.addtrust.com ([213.64.1.64]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.2966); Sat, 16 Mar 2002 00:52:52 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Sat, 16 Mar 2002 00:52:54 +0100
To: Denis Pinkas <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: Updating RFC 3039 - and its impact on PI
Cc: [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: 15 Mar 2002 23:52:52.0937 (UTC) FILETIME=[85695B90:01C1CC7C]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

I will be more specific but I didn't want to take up to much space in the 
start of the discussion

I'm not ready to suggest text replacement right now but the key usage 
restriction should go and at least allow, without any restriction, 
combination of digital signature AND non-repudiation.

For attribute semantics I think today that any such declaration has nothing 
to do with any legal statements concerning qualified certificates. Having 
that function in its current extension is to me a defect. If you want me to 
be more specific I have to owe you but I wont' have trouble to come up with 
examples and reasons.

I will also rise these problems with ETSI.

This was just an initiation of the discussion and I expect to discuss more 
with you and others at Minneapolis.

Especially concerning assassination of PI :-)

/Stefan

At 15:03 2002-03-15 +0100, Denis Pinkas wrote:

>Stefan,
>
>See some comments below:
>
> > As author and implementer of RFC 3039 and in the light of practical
> > experience with RFC 3039, I think we should be ready to revise this RFC
> > and handle some defects.
> >
> > The defects I have recorded so far are:
> >
> > 1) Key usage
> > The key usage bit non-repudiation SHOULD NOT be set together with any
> > other key usage according to RFC 3039. This has caused a lot of confusion
> > and this "SHOULD NOT" statement is not compatible with existing reality.
>
>Could you be more explicit about a suggested text replacement ?
>
> > 2) Attribute semantics
> > This function to define semantics for attributes included in the subject
> > field is very useful and it covers almost everything that the current PI
> > draft wants to solve.
>
>Could you be more specific ?
>
> > The problem is that this function is part of the
> > qcStatements extension which it should not be. Firstly due to the fact
> > that this statement has nothing to do with the intent of this extension
> > and secondly because criticality setting for this function get mixed up
> > with completely unrelated stuff in its current form.
>
> > 3) Usage and purpose
> > RFC 3039 is the only RFC defining structure of a personal ID certificate.
> > This should not be limited just to Qualified certificates. It should be
> > more clear that this RFC is useful for any personal ID certificate. Also
> > non-qualified ones.
>
>Fine.
>
> > Finally I believe that a revision of RFC 3039 should include
> > considerations to avoid the need for a PI extension according to the PI
> > draft.
> >
> > I can't see that the PI draft accomplish anything that RFC 3039 doesn't
> > already solve, or at least would solve after revision.
>
>The revised document will not be able to solve what the PI document covers
>since the PI document applies to *any entity* whereas the revised RFC 3039
>document is planned to apply only to *personal ID certificates*. Maybe the
>revised RFC 3039 could take advantage and refer to the PI document.
>
> > The only exception is the function to define an identifier completely
> > independent of the subject name.
>
>Thank you for noticing this difference.
>
>Regards,
>
>Denis
>
> > I would tough argue that the total case with all aspects on
> > the table probably doesn't justify another feature for that and that there
> > are other ways to solve this within the realm of X.509 and PKIX standards.
>
> > I still believe that a creative revision of RFC 3039 could be made to
> > cover what we need in this area. And I also recall this as an initially
> > defined possibility laid down for the PI work.
>
> > /Stefan



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2FNnni17853 for ietf-pkix-bks; Fri, 15 Mar 2002 15:49:49 -0800 (PST)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2FNnl417848 for <[e-mail]>; Fri, 15 Mar 2002 15:49:47 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 15 Mar 2002 15:48:42 -0800 (PST)
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, 15 Mar 2002 15:48:42 -0800 (PST)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <GK1PQ4PG>; Fri, 15 Mar 2002 15:49:35 -0800
Content-return: allowed
Date: Fri, 15 Mar 2002 15:49:26 -0800
From: Peter Williams <[e-mail]>
Subject: RE: Attribute Certificates and Privilege Policy
To: "'Denis Pinkas'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I dont see how privilege policy, as defined by ISO,
has any equivalency relation to validation policy - as
an architect speaking from a company that was
conceived to deploy and has deployed over a hundred 
operational validation servers and associated validation 
policies in the world - for probably every major PKI 
vendors' system, and probably 50% of all operational
commercial-grade PKIs!

Validation policies are the expression in some rule form
of the risk management controls a RP uses to *Accept*
a cert path, beyond the rules built into the simplistic path
processing algorithm specified by ISO for
trust chains *validation*; acceptance and validation
are very different processes, especially in well written
CPSs mapping technology onto law principles. ValiCert
must have built now 10 quite-different validation policys, for 
various military projects and banking groups.

Whilst ISO rules for PKI trust chain processing
properly arrange for inteoperability and navigation of trust 
domains (a valid ISO issue), validation policies address the 
risks applications face when PKI fails, PKI signals need to be 
ignored/overridden, redundacy of PKI chains, or PKI is used t
o assist privilege-based control systems - whose purposes fall outside
the scope of ISO PKI/PMI frameworks, or IETF profiles
thereof.

In practice, privilege policy is already deployed worldwide, in 
two forms. Java 2 enables
relying parties to sign and use an executable-form "AC", that limits
privilege acceptance for privileges asserted by loading-code, 
using privilege-policy rule expressions that are 
expressed as executable code, selected and downloaded by the 
target system. Microsoft  Win32 OS's TCB does something similar 
since 5  years ago, using other signalling 
and enforcement techniques, that leverages a little of the 
Authenticode standardization in 2459, and other
PKI-based techniques properly not addressed by PKIX.

Validation policies are, in contrast, all about validation of 
certificate chains, PKI and PMI varieties. AS we learned
from the authoritative editor of X.509, the ISO intended
that privilege policy enforcement has little or nothing
to do with AC delegation path processing, and nothing
whatsoever to do with PKI path processing. Validation
policies are exclusively associated with the PKI
and/or PMI chain processing.

I asked the question, is privilege policy enforcement
PART OF path processing. Sharon indicated that it
is not, though ISO wording and titling of X.509 sections
16.x.y could be improved. Hence validation policies
are not equivalent in basis to privilege policies.

AS privilege policy and validation policy do take
the perspective of relying parties, there 
is some limited consistency in that shared 
perspective, to be fair to Denis.

If ISO decide that, contrary to current intepretation
by the editor of the ISO position, that privilege
policy enforcement IS A PART OF path processing,
then we could possibly agree on there being
some equivalency basis. 

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Friday, March 15, 2002 9:50 AM
To: Sharon Boeyen
Cc: '[e-mail]'
Subject: Re: Attribute Certificates and Privilege Policy



Sharon,

Yes, this is indeed a very long e-mail. Mine will be shorter.

Shortly speaking, the "privilege policy" is the equivalent of a 
"validation policy" (see the DPV requ. draft availmable from 
http://www.imc.org/draft-ietf-pkix-dpv-dpd-req), but it is NOT 
the equivalent of a certification policy.

You said: "In terms of 'why no certificate policy' - there was no need
identified for an equivalent".

For CAs there are different levels of verification of the identity presented
at the time of registration. This level is "visible" through the certificate
policy.

I do not see why we should not draw a parallel with attributes, where for
AAs there would be different levels of verification of the attributes
presented at the time of registration. This level would be "visible" through
the "attribute policy".

A validation policy (i.e. privilege policy using the ISO terminology) may
consider that some attribute policies are adequate and that some others are
not.

Otherwise, the single way to trust is to use the name of the AA. 

If an AA supports different "attribute policies", it would have to change
its
name, each time. :-(

Thus I see a good reason to have an equivalent.

Regards,

Denis

> I'll try to address all the questions I've seen re the 509 aspects of this
> discussion. (Sorry this is rather long, but I found this
> 
> easier than trying to respond to each message).
> 
> I think Peter has identified at least one part of 509 that could benefit
> from some editorial clarification.
> 
> Clause 16 "Privilege path processing procedure" may be more appropriate
> titled "Privilege assertion processing procedure".
> 
> Each paragraph in 16.1 could probably use subtitles to clarify what's
> really going on. The paragraphs in this section are basically
> 
> a list of each of the checks that need to be done before an asserted
> privilege can be granted to a claimant.
> - Para 1 is doing a "validation" on each of the attribute certificates in
> the path. This is just checking the signatures, using the
> 
> PKI path validation steps as if you were checking the signature on a
> signed form - the details are in clause 10 of the PKI section.
> 
> - Para 2 is a check to ensure the claimant's willingness to use that
> attribute cert for the context - no standard steps for this
> 
> check are defined.
> - Para 3 is the revocation status check - no details req'd
> - Para 4 is the check for whether the asserted privilege is valid for the
> time of interest - no details req'd
> - Para 5 is checking any constraints imposed by the issuer of the AC on
> the set of permitted targets - no details req'd
> - Para 6 is the checks for roles and of delegation. Note that 16.2 is
> merely the details associated with the role check and
> 
> 16.3 is merely the details assoiated with the delegation check.
> - Para 7 is the privilege policy check against the asserted privilege
> together with the other inputs (target sensitivity,
> 
> environmental variables) and checking any constraints on privilege policy
> imposed by the issuer.
> 
> So this complete set of steps comprise the processing that needs to be
> done to assess a privilege assertion. Some of these
> relate to paths (Para 1 is processing of a public-key certification path
> to verify the signature on the attribute cert and
> Para 6 along with 16.3 is processing of a delegation path of attribute
> certificates to determine whether or not the delegation
> itself is authorized and valid. As part of the processing of a delegation
> path, note that the signature on EACH attribute
> certificate in the path needs to be verified, so again the public-key path
> validation is used for that purpose). I wanted to
> try to clarify this because asking if something is part of "path
> validation" is not as easy to answer as it would be if
> we were talking about PKI instead of PMI.
> 
> The privilege policy is the basis for determining the acceptance of an
> attribute certificate (at least from a policy perspective).
> 
> It is processed by a verifier as one of the steps in assessing a privilege
> assertion, but it is not strictly part of either
> public-key certification path processing done for signature verification
> or part of delegation path processing for verifying
> delegation.
> 
> Many aspects of privlege policy were not standardized in 509, including
> its syntax, who can write them etc, how does
> a verifier know which one to use etc. Some of these were deferred, e.g.
> syntax. Note however, that in OASIS, the XACML
> working group is now defining a standard XML syntax for access control
> policy. Some material from the sample syntaxes
> in the X.509 informative annex were input to the XACML work so folks
> interested in privilege policy may find that work
> interesting as well. As for how the verifier knows which privilege policy
> to use - that is left to the implementation. In
> some cases a target may always work with a single privilege policy and it
> may be created by the local SOA . There
> are hooks to tie privilege policies to attributes for which an SOA assigns
> privileges (the attributeDescriptor in 15.3.2.2 and
> there is also directory syntax to store them, but no standardized way for
> a verifier to determine which to use. However a local
> trusted SOA would obviously be one possible source of privilege policies.
> 
> Regarding the acceptablePrivilegePolicies extension, a verifier is always
> assessing a privilege assertion with respect to
> a specific privilege policy as per para 7 in 14.1. In the absence of the
> acceptablePrivilegePolicies extension, the verifier
> merely assess the assertion with respect to the privilege policy it is
> working with (out of band / local means for determining
> which privilege policy the verifier operates with - likely greatly
> determined by the target). If the acceptablePrivilegePolicies
> extension is present, then the verifier needs to check whether the
> privilege policy it is operating under is one of the ones
> listed as acceptable in that extension. If it is, then the verifier
> proceeds normally. If it is not, the verifier stops and the privilege
> asserter is not given access.
> 
> The privilege policy is the set of rules that determine acceptability of
> an asserted privilege. A primary difference between
> that and certificate policy is that certificate policy is tied to a
> certificate and defines acceptable uses for that certificate,
> while privilege policy is associated with a verifier and the target that
> is in question and determines which privilege assertions
> are appropriate. So, things like usage constraints, dollar limits, time
> constraints, name constraints - all those things would
> be appropriate for inclusion in a privilege policy. I'm not convinced
> about liability limits though, because privilegePolicy must
> be machine processable as it is processed dynamically at assertion
> assessment time. Liability limits don't seem like they
> would easily lend themselves to this.
> 
> In terms of 'why no certificate policy' - there was no need identified for
> an equivalent. A verifier trusts an SOA as the
> ultimate source of authority for assignment of a set of privileges. That's
> the authorization issue I mentioned earlier.
> 
> If delegation is done, then the checks for ensuring that is authorized are
> part of the delegation path processing
> procedure. If an AA (SOA or delegated AA) wishes to constrain the policy
> under which an AC is used, it can do
> so through the acceptablePrivilegePolicies extension. As for certificate
> policies, they are used when verifying the
> signature on the attribute certificates as well as when verifying the
> signature on any transaction associated with
> the specific assertion of privilege being made by the claimant. So
> certificate policies do factor into the overall
> validation for any given transaction, but are not part of the privilege
> assertion assessment.
> 
> I hope this addresses the questions that were raised by Denis, Chris and
> Peter - if not I'm sure you'll let me know :-).
> 
> In terms of 509 clarifications, if people think some defect work is needed
> there, please let me know.
> 
> FYI, I'm going to try to get all my editing tasks from the recent X.509
> meeting completed and provide a brief summary
> of the meeting to this list prior to the PKIX meeting. There are a couple
> of current issues we're working on with respect
> to SOAs that PMI folks might be interested in.
> 
> Again, apologies for the length of the message.
> Sharon
> 
> Sharon Boeyen
> Principal, Advanced Security
> Tel: [phone]
> www.entrust.com
> 
> Entrust, Inc.
> Securing the Internet


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2FNNkm17367 for ietf-pkix-bks; Fri, 15 Mar 2002 15:23:46 -0800 (PST)
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 g2FNNi417363 for <[e-mail]>; Fri, 15 Mar 2002 15:23:44 -0800 (PST)
Received: from tsg1 ([12.81.72.13]) by mtiwmhc21.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020315232330.WIQK19351.mtiwmhc21.worldnet.att.net@tsg1>; Fri, 15 Mar 2002 23:23:30 +0000
Message-ID: <01b701c1cc78$695c8f20$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, "Stephen Kent" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: TSP interoperability testing
Date: Fri, 15 Mar 2002 15:23:26 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mr. Kent - when did you do this and isn't there an issue of propriety  in
this decision?

Todd Glassey
----- Original Message -----
From: "Peter Sylvester" <[e-mail]>
To: <[e-mail]>; <[e-mail]>;
<[e-mail]>; <[e-mail]>;
<[e-mail]>; <[e-mail]>; <[e-mail]>;
<[e-mail]>; <[e-mail]>; <[e-mail]>;
<[e-mail]>; <[e-mail]>; <[e-mail]>;
<[e-mail]>
Cc: <[e-mail]>
Sent: Friday, March 15, 2002 12:21 PM
Subject: Re: TSP interoperability testing


>
>
> Denis,
>
> although I cannot speak for Thomas with whom I
> will most like share very soon some interesting
> open source activity: You just experience a delay
> caused by some administrational and postal
> problems postponing the begin of the EU project
> openevidence.
>
> Peter
>
>
> > Date: Fri, 15 Mar 2002 15:02:30 +0100
> > From: Denis Pinkas <[e-mail]>
> > Organization: Integris. A Bull Company
> > To: tho <[e-mail]>, Peter Sylvester
<[e-mail]>,
> >         Peter Gutmann <[e-mail]>,
> >         Taglialagamba Bianca <[e-mail]>,
> >         Andrea Caccia <[e-mail]>, Antonio Lioy
<[e-mail]>,
> >         [e-mail], [e-mail],
[e-mail],
> >         [e-mail], [e-mail], [e-mail],
> >         [e-mail]
> > Subject: TSP interoperability testing
> >
> > Thomas (and all the TSP list)
> >
> > On January 8, I thanked you for taking the lead of the testing, but
until
> > now, I have not seen any result, according to RFC 2026.
> >
> > On February 18, I have sent a table for helping, but until now, no one
has
> > indicated that he had started to fill in the matrix.
> >
> > I attach again the document.
> >
> > FYI, I got delegation for the PKIX chair (Steve Kent) for "documenting
the
> > specific implementations which qualify the specification for Draft or
> > Internet Standard status along with documentation about testing of the
> > interoperation of these implementations".
> >
> > Unless the table is filed in, the TSP document cannot move to "Draft
> > Standard".
> >
> > Regards,
> >
> > Denis
> >
> > Note: Please always use "TSP" in any of your messages so that they can
be
> > searched more easily.
> >
> >
> > > Tho,
> > >
> > > Thank you for taking the lead of the interoperability testing. You
proposal
> > > sounds very good. However, I would suggest that you continue detailed
> > > discussions on this topic by using the direct e-mail addresses of the
> > > implementers (that I have used by removing the pkix e-mail list
address) and
> > > thus not copy the whole PKIX mailing list. I would be pleased to stay
on
> > > this smaller list since I am interested to follow it.
> > >
> > > Regards,
> > >
> > > Denis
> > >
> > >
> > > > hello everybody,
> > > > in trying to organize some interop testing between all the publicly
available
> > > > rfc3161 implementations I have begun sketching down a set of test
vectors and
> > > > I'd like to discuss the matter with you ;-)
> > > >
> > > > the first (TSRQ-G_i) is made up of correctly formatted TimeStampReqs
which
> > > > we expect to be fulfilled by the TSA.
> > > > Starting from a very basic request, we make vary some parameters:
> > > >
> > > >   o TSRQ-G_001 -> basic request (none of the optional fields)
> > > >   o TSRQ-G_002 -> TSRQ-G_001 + nonce
> > > >   o TSRQ-G_003 -> TSRQ-G_001 + reqPolicy{=one supported by the
actual TSA}
> > > >   o TSRQ-G_004 -> TSRQ-G_001 + certReq=TRUE
> > > >   ... other
> > > >
> > > >   for all these TimeStampReqs we expect to get the signed receipt of
the
> > > >   TSTInfo back from the TSA (which must be then verified in the many
ways
> > > >   stated by the rfc)
> > > >
> > > > the second (TSRQ-E_i) is a vector of malformed (in a number of ways)
> > > > TimeStampReqs:
> > > >
> > > >   o TSRQ-E_001 -> bad asn.1 encoding (expected badDataFormat)
> > > >   o TSRQ-E_002 -> policy id not recognized (expected
unacceptedPolicy)
> > > >   o TSRQ-E_003 -> weak or unknown hash algorithm (expected badAlg)
> > > >   o TSRQ-E_004 -> wrong protocol version (expected badRequest or
badDataFormat)
> > > >   o TSRQ-E_005 -> length mismatch in messageImprint (expected
badDataFormat)
> > > >   o TSRQ-E_006 -> unrecognized extension (expected
unacceptedExtension)
> > > >   ... other
> > > >
> > > > the third (SBP-E_i) is `Socket Based Protocol' specific (really
there should
> > > > be one of these vectors for each of the transport protocols
including HTTP,
> > > > SMTP, etc. but for now we can start with `Socket Based Protocol'
which seems
> > > > to be the most widely deployed) and consists of the following:
> > > >
> > > >   o SBP-E_001 -> packet with pollRep flag set
> > > >   o SBP-E_002 -> packet with pollReq flag set
> > > >   o SBP-E_003 -> packet with negPollRep flag set
> > > >   o SBP-E_004 -> packet with partialMsgRep flag set
> > > >   o SBP-E_005 -> packet with finalMsgRep flag set
> > > >   o SBP-E_006 -> packet with errorMsgRep flag set
> > > >
> > > >   for all those above we expect a rejection with failInfo=badRequest
> > > >
> > > >   o SBP-E_007 -> packet with length discrepancy (or a similar trick
to
> > > >                  test if there is a time-out mechanism on I/O)
> > > >   ... other
> > > >
> > > > I have just tried to use this framework for testing against my own
> > > > implementation, the one from SIA and Peter Sylvester's (no SBP-E_i
for him
> > > > since the exposed interface is HTTP) and I've found it quite useful
as it
> > > > offers an _unified_ approach and the possibility to automate the
procedure.
> > > >
> > > > Surely we can go more in-depth than this, and in fact this is just a
starting
> > > > point.
> > > >
> > > > tho



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2FLjcX15416 for ietf-pkix-bks; Fri, 15 Mar 2002 13:45:38 -0800 (PST)
Received: from localhost.custodium.com ([216.241.20.228]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2FLjP415410 for <[e-mail]>; Fri, 15 Mar 2002 13:45:26 -0800 (PST)
Received: from ropazo ([192.168.4.100]) by localhost.custodium.com (8.12.2/8.12.2) with SMTP id g2FLfgvW020808; Fri, 15 Mar 2002 17:42:11 -0400
From: "Roberto Opazo Gazmuri" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Updating RFC 3039 - and its impact on PI
Date: Fri, 15 Mar 2002 17:36:17 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 1 (Highest)
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-reply-to: <[e-mail]>
Importance: High
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > Finally I believe that a revision of RFC 3039 should include
> > considerations to avoid the need for a PI extension according to the PI
> > draft.
> >
> > I can't see that the PI draft accomplish anything that RFC 3039 doesn't
> > already solve, or at least would solve after revision.
>
> The revised document will not be able to solve what the PI document covers
> since the PI document applies to *any entity* whereas the revised RFC 3039
> document is planned to apply only to *personal ID certificates*. Maybe the
> revised RFC 3039 could take advantage and refer to the PI document.
>

I agree.

The PI purpose is important enough to be in an independent discussion and
RFC, even considering than QC could be modified to apply to any entity.

Best regards,

Roberto



Received: by above.proper.com (8.11.6/8.11.3) id g2FKw6x14453 for ietf-pkix-bks; Fri, 15 Mar 2002 12:58:06 -0800 (PST)
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 g2FKw5414449 for <[e-mail]>; Fri, 15 Mar 2002 12:58:05 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA15926; Fri, 15 Mar 2002 15:57:53 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0510030ab8b80d8f9692@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 15 Mar 2002 15:52:49 -0500
To: Peter Sylvester <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: DPD/DPV reqmts strawpoll
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>

At 9:08 PM +0100 3/15/02, Peter Sylvester wrote:
>Dear group, dear chairmen,
>
>About two weeks ago ago I had asked the chairs of the group to
>initiate a strawpoll.
>
>I tried to contact them in two private mail asking whether
>I followed the correct procedure or not, i.e., asking them.
>
>Since then, I have not heard an answer.
>I may be on their black list.
>
>So be it.
>Peter

Peter,

You are not on my blacklist; heck, I even read all of Todd's messages :-)

Sorry for not responding earlier, but I've been out of town in 
meetings for much of the last two weeks, sometimes with limited 
e-mail connectivity.

I looked through my PKIX e-mail and I could not locate a specific 
message stating for what question you were requesting a straw poll. I 
may have misfiled it. Is the topic the status of "cautionary period" 
in the DPV/DPD requirements document? Please let me know so we can 
proceed.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2FKQc213748 for ietf-pkix-bks; Fri, 15 Mar 2002 12:26:38 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2FKQG413738 for <[e-mail]>; Fri, 15 Mar 2002 12:26:17 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id VAA16254; Fri, 15 Mar 2002 21:21:10 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 15 Mar 2002 21:21:10 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id VAA04957; Fri, 15 Mar 2002 21:21:07 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id VAA26477; Fri, 15 Mar 2002 21:21:06 +0100 (MET)
Date: Fri, 15 Mar 2002 21:21:06 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: TSP interoperability testing
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>

Denis, 

although I cannot speak for Thomas with whom I
will most like share very soon some interesting
open source activity: You just experience a delay
caused by some administrational and postal 
problems postponing the begin of the EU project 
openevidence. 
 
Peter
 

> Date: Fri, 15 Mar 2002 15:02:30 +0100
> From: Denis Pinkas <[e-mail]>
> Organization: Integris. A Bull Company
> To: tho <[e-mail]>, Peter Sylvester <[e-mail]>,
>         Peter Gutmann <[e-mail]>,
>         Taglialagamba Bianca <[e-mail]>,
>         Andrea Caccia <[e-mail]>, Antonio Lioy <[e-mail]>,
>         [e-mail], [e-mail], [e-mail],
>         [e-mail], [e-mail], [e-mail],
>         [e-mail]
> Subject: TSP interoperability testing
> 
> Thomas (and all the TSP list)
> 
> On January 8, I thanked you for taking the lead of the testing, but until
> now, I have not seen any result, according to RFC 2026.
> 
> On February 18, I have sent a table for helping, but until now, no one has
> indicated that he had started to fill in the matrix.
> 
> I attach again the document.
> 
> FYI, I got delegation for the PKIX chair (Steve Kent) for "documenting the
> specific implementations which qualify the specification for Draft or
> Internet Standard status along with documentation about testing of the
> interoperation of these implementations".
> 
> Unless the table is filed in, the TSP document cannot move to "Draft
> Standard". 
> 
> Regards,
> 
> Denis
> 
> Note: Please always use "TSP" in any of your messages so that they can be
> searched more easily.
> 
>  
> > Tho,
> > 
> > Thank you for taking the lead of the interoperability testing. You proposal
> > sounds very good. However, I would suggest that you continue detailed
> > discussions on this topic by using the direct e-mail addresses of the
> > implementers (that I have used by removing the pkix e-mail list address) and
> > thus not copy the whole PKIX mailing list. I would be pleased to stay on
> > this smaller list since I am interested to follow it.
> > 
> > Regards,
> > 
> > Denis
> > 
> > 
> > > hello everybody,
> > > in trying to organize some interop testing between all the publicly available
> > > rfc3161 implementations I have begun sketching down a set of test vectors and
> > > I'd like to discuss the matter with you ;-)
> > >
> > > the first (TSRQ-G_i) is made up of correctly formatted TimeStampReqs which
> > > we expect to be fulfilled by the TSA.
> > > Starting from a very basic request, we make vary some parameters:
> > >
> > >   o TSRQ-G_001 -> basic request (none of the optional fields)
> > >   o TSRQ-G_002 -> TSRQ-G_001 + nonce
> > >   o TSRQ-G_003 -> TSRQ-G_001 + reqPolicy{=one supported by the actual TSA}
> > >   o TSRQ-G_004 -> TSRQ-G_001 + certReq=TRUE
> > >   ... other
> > >
> > >   for all these TimeStampReqs we expect to get the signed receipt of the
> > >   TSTInfo back from the TSA (which must be then verified in the many ways
> > >   stated by the rfc)
> > >
> > > the second (TSRQ-E_i) is a vector of malformed (in a number of ways)
> > > TimeStampReqs:
> > >
> > >   o TSRQ-E_001 -> bad asn.1 encoding (expected badDataFormat)
> > >   o TSRQ-E_002 -> policy id not recognized (expected unacceptedPolicy)
> > >   o TSRQ-E_003 -> weak or unknown hash algorithm (expected badAlg)
> > >   o TSRQ-E_004 -> wrong protocol version (expected badRequest or badDataFormat)
> > >   o TSRQ-E_005 -> length mismatch in messageImprint (expected badDataFormat)
> > >   o TSRQ-E_006 -> unrecognized extension (expected unacceptedExtension)
> > >   ... other
> > >
> > > the third (SBP-E_i) is `Socket Based Protocol' specific (really there should
> > > be one of these vectors for each of the transport protocols including HTTP,
> > > SMTP, etc. but for now we can start with `Socket Based Protocol' which seems
> > > to be the most widely deployed) and consists of the following:
> > >
> > >   o SBP-E_001 -> packet with pollRep flag set
> > >   o SBP-E_002 -> packet with pollReq flag set
> > >   o SBP-E_003 -> packet with negPollRep flag set
> > >   o SBP-E_004 -> packet with partialMsgRep flag set
> > >   o SBP-E_005 -> packet with finalMsgRep flag set
> > >   o SBP-E_006 -> packet with errorMsgRep flag set
> > >
> > >   for all those above we expect a rejection with failInfo=badRequest
> > >
> > >   o SBP-E_007 -> packet with length discrepancy (or a similar trick to
> > >                  test if there is a time-out mechanism on I/O)
> > >   ... other
> > >
> > > I have just tried to use this framework for testing against my own
> > > implementation, the one from SIA and Peter Sylvester's (no SBP-E_i for him
> > > since the exposed interface is HTTP) and I've found it quite useful as it
> > > offers an _unified_ approach and the possibility to automate the procedure.
> > >
> > > Surely we can go more in-depth than this, and in fact this is just a starting
> > > point.
> > >
> > > tho


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2FK8ts12982 for ietf-pkix-bks; Fri, 15 Mar 2002 12:08:55 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2FK8r412977 for <[e-mail]>; Fri, 15 Mar 2002 12:08:53 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id VAA16219; Fri, 15 Mar 2002 21:08:55 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 15 Mar 2002 21:08:55 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id VAA04922; Fri, 15 Mar 2002 21:08:53 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id VAA26474; Fri, 15 Mar 2002 21:08:52 +0100 (MET)
Date: Fri, 15 Mar 2002 21:08:52 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: DPD/DPV reqmts strawpoll
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear group, dear chairmen,

About two weeks ago ago I had asked the chairs of the group to
initiate a strawpoll.

I tried to contact them in two private mail asking whether
I followed the correct procedure or not, i.e., asking them.

Since then, I have not heard an answer. 
I may be on their black list.

So be it.
Peter



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2FK2lc12862 for ietf-pkix-bks; Fri, 15 Mar 2002 12:02:47 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2FK2j412857 for <[e-mail]>; Fri, 15 Mar 2002 12:02:45 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id VAA16184; Fri, 15 Mar 2002 21:02:46 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 15 Mar 2002 21:02:46 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id VAA04885; Fri, 15 Mar 2002 21:02:45 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id VAA26467; Fri, 15 Mar 2002 21:02:45 +0100 (MET)
Date: Fri, 15 Mar 2002 21:02:45 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: DPD/DPV reqmts
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Some other remarks to the 'additional answers'.


> 
> [Additional Answer 5]
> 
> Authentication of the service before sending a request is not performed in
> similar protocols like OCSP. There is no particular reason to do so for this
> protocol.

Wrong, my dear Sir Denis Pinkas: 

! A.1.1 Request

   ...
!                         Where privacy is
!   a requirement, OCSP transactions exchanged using HTTP MAY be
!   protected using either TLS/SSL or some other lower layer protocol.

Unless, of course, if Thou thinkest that privacy does not include
authentication of the partner ... 

> 
> [Additional Answer 6]
> 
> There is no requirement on the protocol to support confidentiality. In the
> same way OCSP does not support confidentiality at the level of the protocol,
> but can support it at the transport level.


It seems that You don't understand. The requirement is there is
a privacy requirement, and the protocol designers should "provide"
or "use some means". A protocol can always respond to a
requirement by oits own means or use other services. 

Of course, as Thou hast said elsewhere, You might consider this
a extremely obvious, thus omitted.

> 
> [Additional Answer 7]
> 
> It is unclear what requirement is being addressed and what kind of treatment
> would be done with such an identity field.
This is not unclear, did Thou omittest 'for me'?

The requirement addressed is similar to the one in TSP that led
to the inclusing of a field tsa in the response. 

There is a difference of a 'declaration of identity' and 
authenticating it or deducing an identity from some authentication
means.  
 
> 
> [Additional Answer 8]
> 
> There are no requirement for relying nor referrals. We are not going to jump
> into the complexity of protocols like DAP(Directory Access Protocol). Note
> also that in addition to the YES/NO/DONTKNOW authenticable answer, the path
> elements may be returned.

May You (Denis) please avoid to use the word "We" in an ambiguous way.
Who is "We"?  How do these 'We" decide what?   

There is a requirement, similar as for OCSP caches,
that server just relays a request to another. This had been
discussed several times, the differences had only been to
what degree the relaying should become visible; whether one
server can rewrite/resigns the answers of another etc. 
Relaying via cache is an obvious feature in many OCSP implementation,
how do they protect itself against loops between two servers? 

Denis, it seems to me that You are confusing 
"I don't understand how to respond a requirement" 
with "there is no requirement". 

There is a requirement (at least I see one) that 
depending on a policy a server must return all reasons that 
contributed to his decision. And this may contain that it has
obtained a DPV response for a CA cert.  

> [Additional Answer 9]
> 
> As already said, there has been plenty of discussion on the list regarding
> the number of states.  People clearly want the fewest possible number.

You are confusing 'necessary' and 'useful'. 



Peter
PS: I always thought that 'You' is the correct polite way to address
to a specific person or a group, whilst 'you' just means somethng
limilar to 'one' in sentences like 'one might not want to implement this'.





Received: by above.proper.com (8.11.6/8.11.3) id g2FJwco12789 for ietf-pkix-bks; Fri, 15 Mar 2002 11:58:38 -0800 (PST)
Received: from emerald.lightlink.com (emerald.lightlink.com [205.232.34.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2FJwb412784 for <[e-mail]>; Fri, 15 Mar 2002 11:58:37 -0800 (PST)
Received: from [209.216.70.29] (perm70-29.ij.net [209.216.70.29] (may be forged)) by emerald.lightlink.com (8.8.8/8.8.8) with SMTP id OAA15069; Fri, 15 Mar 2002 14:58:14 -0500
From: "Christopher S. Francis" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Sharon Boeyen" <[e-mail]>
Cc: <[e-mail]>
Received: from no.name.available by [209.216.70.29] via smtpd (for smtp.lightlink.com [205.232.34.14]) with SMTP; 15 Mar 2002 20:05:23 UT
Subject: RE: Attribute Certificates and Privilege Policy
Date: Fri, 15 Mar 2002 14:58:13 -0500
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 V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I concur with Denis.  It seems entirely reasonable that an AA may want to
apply different levels of verification of the attributes presented in the
ACs that it issues.

Just as commercial CAs issue PK certificates under various policies,
charging higher prices for higher levels of assurance, an Attribute
Authority may want to issue ACs under various policies, with different
levels of assurance based on the level of verification of the asserted
attributes.

Chris

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Denis Pinkas
Sent: Friday, March 15, 2002 12:50 PM
To: Sharon Boeyen
Cc: '[e-mail]'
Subject: Re: Attribute Certificates and Privilege Policy


Sharon,

Yes, this is indeed a very long e-mail. Mine will be shorter.

Shortly speaking, the "privilege policy" is the equivalent of a
"validation policy" (see the DPV requ. draft availmable from
http://www.imc.org/draft-ietf-pkix-dpv-dpd-req), but it is NOT
the equivalent of a certification policy.

You said: "In terms of 'why no certificate policy' - there was no need
identified for an equivalent".

For CAs there are different levels of verification of the identity presented
at the time of registration. This level is "visible" through the certificate
policy.

I do not see why we should not draw a parallel with attributes, where for
AAs there would be different levels of verification of the attributes
presented at the time of registration. This level would be "visible" through
the "attribute policy".

A validation policy (i.e. privilege policy using the ISO terminology) may
consider that some attribute policies are adequate and that some others are
not.

Otherwise, the single way to trust is to use the name of the AA.

If an AA supports different "attribute policies", it would have to change
its
name, each time. :-(

Thus I see a good reason to have an equivalent.

Regards,

Denis





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2FIGSc08559 for ietf-pkix-bks; Fri, 15 Mar 2002 10:16:28 -0800 (PST)
Received: from geos.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2FIGR408555 for <[e-mail]>; Fri, 15 Mar 2002 10:16:27 -0800 (PST)
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 g2FIGFA09368; Fri, 15 Mar 2002 10:16:15 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "pkix" <[e-mail]>
Subject: RE: DPD/DPV reqmts
Date: Fri, 15 Mar 2002 10:13:39 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-reply-to: <[e-mail]>
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>

Denis,

For those of us unable to attend the Minneapolis session, given
the abundance of comments and proposed text may we assume that
the WG will be provided a -03 some time after that session?

Mike



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

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Denis Pinkas
> Sent: Friday, March 15, 2002 8:09 AM
> To: pkix
> Subject: DPD/DPV reqmts
>
>
>
> To the list,
>
> You will find hereafter additional responses to the
> comments raised during
> the WG last call. In any case for further
> discussions, please indicate first
> the comment number. This was not done by Petra and
> thus does not make the
> task easy. Also do not use separate e-mails.
>
> [About COMMENT 1]
>
> >From Petra Barzin <[e-mail]>
>
> I don't see why you differentiate between signed and
> authenticated
> responses.
>
> The same is true for signed responses: either the hash of
> the request or the important elements from the
> request must be present.
> In order to test the response against what has been
> requested the client
> has to keep his request or at least the hash of his request.
>
> The advantage of a hash - instead of copying all
> important elements
> from the request -  is:
>
> (a) that the response will be smaller and
> (b) adding a new important element to the request
> doesn't require a
> change of the response.
>
>   - a hash of the request MUST be included in the response.
>     This may allow the client to check if his request
> was maliciously
>     modified (if the response is signed) and helps to
> associate the
>     response with his request when using
> connectionless protocols.
>
> [Answer 1] The requirements are different whether the
> requester simply
> wants an authenticated response or a signed response.
> For a signed response
> the inclusion of the important elements from the
> request is needed, so that
> a response can be individually tested against what
> has been requested. For
> an authenticated response, the hash of the request is
> sufficient. To
> summarize:
>
>     - for signed responses, the important elements
> from the request
>       must be present.
>
>     - for authenticated responses, either the hash of
> the request or the
>       important elements from the request must be present.
>
> [Additional Answer 1]
>
> Two answers:
>
> 1) Signed answer may be individually re-verified,
> while authenticated
> answers may depend on a context that cannot
> necessarily be reconstructed
> later on. If signed answers are used for
> authenticated responses, then there
> is no more difference, but here we indicate
> requirements, not solutions.
>
> 2) The most important is to be able to use a signed
> response alone. If the
> signed response only contains the hash of the
> request, then the request must
> also be kept to know what the question was. A format
> for concatenating the
> request with the signed response would then be necessary.
>
> So, contradictory to what Peter(Sylvester) said,
> copying the request in the
> response, or just including its hash is not a
> protocol designers
> prerogative.
>
>
> [About COMMENT 2]
>
> yes, indeed. There is a contradiction. My last
> sentence should be:
> The random number doesn't have to be repeated in the response
> *because* the response contains a hash of the request.
>
> I don't understand your last comment. The client does
> not compute
> the hash over all the fields from the response but
> from his request!
>
> > - a random number MAY be included in the request.
> > This allows replay protection when the client has no clock.
> > The random number doesn't have to be repeated in
> the response
> > if the response contains a hash of the request.
> >
> > [Answer 2] Replay protection is so obvious that it
> has been omitted. We
> > could certainly add some text. The nonce
> cryptographically binds a request
> > and a response to prevent replay attacks. However
> when you say: "The random
> > number doesn't have to be repeated in the response
> *if* the response
> > contains a hash of the request". This sentence is
> in contradiction with your
> > first comment where you say: "a hash of the request
> MUST be included in the
> > response". A choice needs to me made.  :-)
> >
> > I believe that the nonce should be in the response
> as well, just because it
> > is easier for the client to compute the hash over
> all the fields from the
> > response instead of saying: "after the item X, I
> need to copy the nonce from
> > the request".
>
> [Additional Answer 2]
>
> At this time we have not agreed to always include the
> hash of the request.
> So if the hash is not there, then the random number
> must be there. See also
> the argumentation about comment 1 above.
>
>
> >From Peter Sylvester
>
> Most of the previous responses have been prepared
> collaboratively by the two
> co-editors: Russ and myself. Therefor, I would kindly
> ask to Peter Sylvester
> to avoid to use "you", in particular with a capital Y
> in words like "You" or
> "Your".
>
> [About COMMENT 5]
>
> > - a method to authenticate a server before sending
> any request
> >    (for example this can be achieved by SSL).
> >    (Another example would be using encryption.)
>
> > [Answer 5]. This is covered under the following
> wording: "In order to be
> > able to be confident that the validation of the
> certificate has correctly
> > been done, the client only requires an
> authenticated response". No change is
> > necessary.
>
> This statement covers authentication of a response, I
> am asking for
> authentication of the service before sending a
> request. Regarding
> your response to the next comment, yes, this can be
> implemented by
> a transport mechanism, but there is still a requirement.
>
> [Additional Answer 5]
>
> Authentication of the service before sending a
> request is not performed in
> similar protocols like OCSP. There is no particular
> reason to do so for this
> protocol.
>
> [About COMMENT 6]
>
> > - a method to ensure confidentiality of the transport.
>
> > [Answer 6] There is nothing here in that protocol
> that mandates
> > confidentiality like protecting the value of a
> private key or a secret key.
> > The transport can provide confidentiality in
> support of environments that do
> > not wish to reveal requests or responses contents,
> e.g. using TLS or S/MIME.
>
> Basically You agree that there is a requirement for
> confidentiality. Whether
> it can be supported by a transport mechanism is a solution.
>
> > No change is necessary.
>
> I Disagree.
>
> [Additional Answer 6]
>
> There is no requirement on the protocol to support
> confidentiality. In the
> same way OCSP does not support confidentiality at the
> level of the protocol,
> but can support it at the transport level.
>
> [About COMMENT 7]
>
> > - a method that client and server provide their identity
> >    in the requests and responses: 'You, the client X, has
> >    asked me, the server Y, the following question, and
> >    I, the server Y, with the help of server Z respond.'
>
> > This allows to be able to determine the
> participating entities
> > without having access to whatever particular authentication
> > method information.
>
> > [Answer 7] Actually, we already include the
> identity of the server in the
> > response. The request could also be optionally
> signed. This allows
> > the server to authenticate the client, and this
> authentication allows the
> > server to only support a selective community if
> desired. An option to be
> > able to sign the request may be added.
>
> > The following requirements may be used for example
> in case of
> > validation of an encryption certificate before usage.
>
> There is a difference between authentication and
> identification.
> The request is that the identification is independant from the
> authentication methods and the transports.
>
> A signing entity (the one identified in a signer info
> or a certificate)
> may or may not be the same as the one declared in the
> request/response.
> you may have separation of roles or other situations.
>
> "The President of the United States declares, ...
> signed by JWB".
>
> Another example is in relaying as follows:
>
> Your company service declares that I can use Your
> encryption cert,
> and the response is signed by my local service.
>
> [Additional Answer 7]
>
> It is unclear what requirement is being addressed and
> what kind of treatment
> would be done with such an identity field.
>
>
> [About COMMENT 8]
>
> > One may resume the relaying requirements into one:
>
> > - The protocol MUST provide a means to allow
> (visible) relaying
> >    of requests and responses.
>
> > - Relaying requirements:
>
> > - depending on policy, a server may just impersonate another
> >    server, i.e., take the responses of another
> server, and create
> >    its own response out of them.
>
> > - a server should be able to include the response
> of a relayed
> >    server into his response.
>
> > - a server should be able to simple add another
> authentication
> >    scheme to a response from another server (for example by
> >    using a second signature or a counter signature.)
>
> > - a server that acts as a relay should be able to
> tell to the
> >    next server that it is acting on behalf of a end
> user, and
> >    the final server should be able to note this in
> the response.
>
> > - For relaying, the protocol MUST provide an efficient means
> >    to detect loops.
>
> > [Answer 8] Clients trust some dedicated servers.
> They don't care how the
> > information that is provided has been established:
> there is a single server
> > that is responsible: the one which provides the
> answer. If the response is
> > signed by the expected private key, then it is
> acceptable, otherwise it is
> > not. There are not requirements for chaining or
> referral services. Relaying
> > between servers is not the topic of this document.
> No change is necessary.
>
> There is already a requirement that a service returns
> all information
> obtained from other services. There may be OCSP
> responses, crls, etc.
> Relaying
> of one request (for example of an encryption
> certificate before its usage)
> to
> another DPV service seems a possible implementation.
>
> If I would follow Your logic, then the DPV server
> never needs to return
> anything else than a authenticable YES/NO/DONTKNOW.
>
> There are requirements for relaying etc.
>
> [Additional Answer 8]
>
> There are no requirement for relying nor referrals.
> We are not going to jump
> into the complexity of protocols like DAP(Directory
> Access Protocol). Note
> also that in addition to the YES/NO/DONTKNOW
> authenticable answer, the path
> elements may be returned.
>
>
> [About COMMENT 9]
>
> > - Requirements for incomplete answers:
>
> > - a server may indicate an incomplete response,
> >    and provide a method to update the response later.
>
> > [Answer 9] This would create the maintenance of
> state information which
> > should be avoided. There has been plenty of
> discussion on the list regarding
> > the number of states.  People clearly want the
> fewest possible number. The
> > client may query again later on. No change is necessary.
>
> You are accepting the requirement as such but You
> propose not to
> include it in the document because of some
> implementation detail.
>
> You always have state in a server (maintaing a TCP
> connection for example.)
>
> The fact that this requirement requires some
> particular feature in
> an implementation does not mean that the requirement
> doesn't exist.
>
> It does neither mean that a particular implementation
> of the protocol
> MUST implement for example given a first online
> response and sending
> a later mail.
>
> [Additional Answer 9]
>
> As already said, there has been plenty of discussion
> on the list regarding
> the number of states.  People clearly want the fewest
> possible number.
>
>
> From: Yuriy Dzambasow" <[e-mail]>
>
> Some additional comments.  I have separated them into
> the following
> categories: editorial and technical.
>
> Editorial (at least I am assuming these are editorial):
>
> [COMMENT 19]
>
> 1) Recommend deleting the 2nd paragraph on page 5
> (Section 5) for the
> following reasons:
>         - the first sentence attempts to qualify the
> preceding paragraph,
> and in my
> opinion, adds no additional value
>         - the second sentence contains redundant
> information already defined
> two
> paragraphs above
>
> [Answer 19]
>
> The second paragraph on page 5 (Section 5) is:
>
> Clients MUST be able to specify whether they want, in
> addition to the
> certification path, the revocation information
> associated with the
> path, for the end-entity certificate only, for the CA
> certificates
> only or for both.
>
> This text is not redundant. You are certainly
> pointing to another paragraph.
> Next time, please provide a short extract.
>
> [COMMENT 20]
>
> 2) In section 5, 3rd paragraph it says, "...In that
> case it is acceptable to
> pass the parameters from the path discovery policy
> with each individual
> request, i.e. a set of trust anchors..."  Please
> change the "i.e." to "e.g."
>
> [Answer 20]
>
> OK.
>
> [COMMENT 21]
>
> 3) Section 8, first paragraph: The text states that a
> client can use a
> request/response pair to define to a server a
> "..validation policy and/or a
> path discovery policy..."  Please change "and/or" to "or".
>
> [Answer 21]
>
> OK.
>
> [COMMENT 22]
>
> 4) Change title of 8.1.1 to Certification Path
> Requirements, so that it is
> consistent with the text in section 8.1, item 1.
>
> [Answer 22]
>
> OK.
>
> Technical:
>
> Most of my comments have been addressed (or are being
> addressed on previous
> threads).  I have these three additional comments:
>
> [COMMENT 23]
>
> 1) Why does DPD say that it is OK to pass some policy
> parameters within a
> DPD request if the policy is simple enough (section
> 5), but just the
> opposite is said for DPV (section 4)?  I would think
> that a simple policy
> could be adhered to as well for DPV, and that the
> parameter specification
> could occur within the DPV request.
>
> [Answer 23]
>
> The document does not provide details about what
> means "simple". However the
> idea is the following: when there is a single root,
> with no constraints
> (unless contained in the self-signed certificate
> itself) and when any CRL
> status information is acceptable, then the policy can
> be considered as
> simple. Specific checks on the end-certificate are
> always done locally.
>
> With DPV the policy has to say which CRL information
> is necessary for each
> leg. But the most important is that checks on the
> end-certificate have to be
> done remotely and specifying them is that not simple.
>
> [COMMENT 24]
>
> 2) For DPD responses (page 5), why do the first three
> response types say,
> "...according to the path discovery policy...", while
> the last response type
> says, "...according to the path discovery
> criteria..."?  What is the
> difference between policy and criteria?  If there is
> no difference, then I
> recommend changing "criteria" to "policy".
>
> [Answer 24]
>
> OK.
>
> [COMMENT 25]
>
> 3) Section 8:  I think it would be helpful to break
> out the PDP requirements
> section into two areas:
>
> 1) requirements around the coordination of a
> validation/path discovery
> policy
> between a client and a server to support the
> validation/path discovery for
> a given certificate; and
>
> 2) requirements around defining an authorized policy
> at a server (e.g., used
> by security managers).
>
> This makes it clear that PDP can be used in two distinct ways.
>
> [Answer 25]
>
> PDP only addresses the later. It is unclear what is
> being requested for the
> first area. Please explain.
>
>
> >From Petra Barzin <[e-mail]>
>
> [COMMENT 26]
>
> I would propose the following:
>
> - add one more sentence to section 6:
>
> The protocol SHALL allow clients to obtain the identifier and
> definition of a specific, the default or all of the
> policies supported
> by the server by using another additional
> request/response pair.
>
> [Answer 26]
>
> Not all policies have a definition that can be given
> back (e.g. when locally
> defined). However the identifier (e.g. OID) of the
> policy can always be
> given back. So I would propose to change the sentence
> as follows:
>
> "The protocol SHALL allow clients to obtain the
> references for a specific,
> the default or all of the policies supported by the
> server by using an
> additional request/response pair."
>
> [COMMENT 27]
>
> - and add another section after the PDP requirements:
>
> Policy Retrieval Protocol (PRP) requirements
> In order to archive the validation result of a
> certificate, it MAY be
> necessary to combine it with the used validation
> policy. In some
> cases the client MAY want to get an overview of all validation
> policies supported by the server. Both reasons result
> in the following
> requirements for the Policy Retrieval Protocol :
>
> * return a specific validation policy definition
> * return the default validation policy definition
> incl. its identifier
> * return all validation policy definitions incl.
> their identifiers
> * return max. number of validation policy definitions
> incl. their
> identifiers
> * return max. number of validation policy identifiers
>
> The last two requirements are especially useful for
> thin clients with
> small display facilities.
>
> [Answer 27]
>
> What you propose should be restricted to policies
> defined with the PDP
> protocol. I would prefer to retrieve one by one the
> policies. So using first
> the result of the previous responses, mandated by
> section 6, I would
> propose the following text for a new section 9:
>
> Policy Retrieval Protocol (PRP) requirements
>
> This protocol will allow to obtain the details of a
> policy provided that it
> has been previously defined using PDP. Thus by
> providing an identifier, the
> request will include the definition of the policy, as
> originally provided.
>
> Regards,
>
> Denis
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2FHotM07650 for ietf-pkix-bks; Fri, 15 Mar 2002 09:50:55 -0800 (PST)
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 g2FHor407646 for <[e-mail]>; Fri, 15 Mar 2002 09:50:53 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA22274; Fri, 15 Mar 2002 18:53:02 +0100
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002031518502067:198 ; Fri, 15 Mar 2002 18:50:20 +0100 
Message-ID: <[e-mail]>
Date: Fri, 15 Mar 2002 18:50:19 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Sharon Boeyen <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Attribute Certificates and Privilege Policy
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 15/03/2002 18:50:20, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 15/03/2002 18:50:52, Serialize complete at 15/03/2002 18:50:52
Content-Transfer-Encoding: 7bit
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>

Sharon,

Yes, this is indeed a very long e-mail. Mine will be shorter.

Shortly speaking, the "privilege policy" is the equivalent of a 
"validation policy" (see the DPV requ. draft availmable from 
http://www.imc.org/draft-ietf-pkix-dpv-dpd-req), but it is NOT 
the equivalent of a certification policy.

You said: "In terms of 'why no certificate policy' - there was no need
identified for an equivalent".

For CAs there are different levels of verification of the identity presented
at the time of registration. This level is "visible" through the certificate
policy.

I do not see why we should not draw a parallel with attributes, where for
AAs there would be different levels of verification of the attributes
presented at the time of registration. This level would be "visible" through
the "attribute policy".

A validation policy (i.e. privilege policy using the ISO terminology) may
consider that some attribute policies are adequate and that some others are
not.

Otherwise, the single way to trust is to use the name of the AA. 

If an AA supports different "attribute policies", it would have to change
its
name, each time. :-(

Thus I see a good reason to have an equivalent.

Regards,

Denis

> I'll try to address all the questions I've seen re the 509 aspects of this
> discussion. (Sorry this is rather long, but I found this
> 
> easier than trying to respond to each message).
> 
> I think Peter has identified at least one part of 509 that could benefit
> from some editorial clarification.
> 
> Clause 16 "Privilege path processing procedure" may be more appropriate
> titled "Privilege assertion processing procedure".
> 
> Each paragraph in 16.1 could probably use subtitles to clarify what's
> really going on. The paragraphs in this section are basically
> 
> a list of each of the checks that need to be done before an asserted
> privilege can be granted to a claimant.
> - Para 1 is doing a "validation" on each of the attribute certificates in
> the path. This is just checking the signatures, using the
> 
> PKI path validation steps as if you were checking the signature on a
> signed form - the details are in clause 10 of the PKI section.
> 
> - Para 2 is a check to ensure the claimant's willingness to use that
> attribute cert for the context - no standard steps for this
> 
> check are defined.
> - Para 3 is the revocation status check - no details req'd
> - Para 4 is the check for whether the asserted privilege is valid for the
> time of interest - no details req'd
> - Para 5 is checking any constraints imposed by the issuer of the AC on
> the set of permitted targets - no details req'd
> - Para 6 is the checks for roles and of delegation. Note that 16.2 is
> merely the details associated with the role check and
> 
> 16.3 is merely the details assoiated with the delegation check.
> - Para 7 is the privilege policy check against the asserted privilege
> together with the other inputs (target sensitivity,
> 
> environmental variables) and checking any constraints on privilege policy
> imposed by the issuer.
> 
> So this complete set of steps comprise the processing that needs to be
> done to assess a privilege assertion. Some of these
> relate to paths (Para 1 is processing of a public-key certification path
> to verify the signature on the attribute cert and
> Para 6 along with 16.3 is processing of a delegation path of attribute
> certificates to determine whether or not the delegation
> itself is authorized and valid. As part of the processing of a delegation
> path, note that the signature on EACH attribute
> certificate in the path needs to be verified, so again the public-key path
> validation is used for that purpose). I wanted to
> try to clarify this because asking if something is part of "path
> validation" is not as easy to answer as it would be if
> we were talking about PKI instead of PMI.
> 
> The privilege policy is the basis for determining the acceptance of an
> attribute certificate (at least from a policy perspective).
> 
> It is processed by a verifier as one of the steps in assessing a privilege
> assertion, but it is not strictly part of either
> public-key certification path processing done for signature verification
> or part of delegation path processing for verifying
> delegation.
> 
> Many aspects of privlege policy were not standardized in 509, including
> its syntax, who can write them etc, how does
> a verifier know which one to use etc. Some of these were deferred, e.g.
> syntax. Note however, that in OASIS, the XACML
> working group is now defining a standard XML syntax for access control
> policy. Some material from the sample syntaxes
> in the X.509 informative annex were input to the XACML work so folks
> interested in privilege policy may find that work
> interesting as well. As for how the verifier knows which privilege policy
> to use - that is left to the implementation. In
> some cases a target may always work with a single privilege policy and it
> may be created by the local SOA . There
> are hooks to tie privilege policies to attributes for which an SOA assigns
> privileges (the attributeDescriptor in 15.3.2.2 and
> there is also directory syntax to store them, but no standardized way for
> a verifier to determine which to use. However a local
> trusted SOA would obviously be one possible source of privilege policies.
> 
> Regarding the acceptablePrivilegePolicies extension, a verifier is always
> assessing a privilege assertion with respect to
> a specific privilege policy as per para 7 in 14.1. In the absence of the
> acceptablePrivilegePolicies extension, the verifier
> merely assess the assertion with respect to the privilege policy it is
> working with (out of band / local means for determining
> which privilege policy the verifier operates with - likely greatly
> determined by the target). If the acceptablePrivilegePolicies
> extension is present, then the verifier needs to check whether the
> privilege policy it is operating under is one of the ones
> listed as acceptable in that extension. If it is, then the verifier
> proceeds normally. If it is not, the verifier stops and the privilege
> asserter is not given access.
> 
> The privilege policy is the set of rules that determine acceptability of
> an asserted privilege. A primary difference between
> that and certificate policy is that certificate policy is tied to a
> certificate and defines acceptable uses for that certificate,
> while privilege policy is associated with a verifier and the target that
> is in question and determines which privilege assertions
> are appropriate. So, things like usage constraints, dollar limits, time
> constraints, name constraints - all those things would
> be appropriate for inclusion in a privilege policy. I'm not convinced
> about liability limits though, because privilegePolicy must
> be machine processable as it is processed dynamically at assertion
> assessment time. Liability limits don't seem like they
> would easily lend themselves to this.
> 
> In terms of 'why no certificate policy' - there was no need identified for
> an equivalent. A verifier trusts an SOA as the
> ultimate source of authority for assignment of a set of privileges. That's
> the authorization issue I mentioned earlier.
> 
> If delegation is done, then the checks for ensuring that is authorized are
> part of the delegation path processing
> procedure. If an AA (SOA or delegated AA) wishes to constrain the policy
> under which an AC is used, it can do
> so through the acceptablePrivilegePolicies extension. As for certificate
> policies, they are used when verifying the
> signature on the attribute certificates as well as when verifying the
> signature on any transaction associated with
> the specific assertion of privilege being made by the claimant. So
> certificate policies do factor into the overall
> validation for any given transaction, but are not part of the privilege
> assertion assessment.
> 
> I hope this addresses the questions that were raised by Denis, Chris and
> Peter - if not I'm sure you'll let me know :-).
> 
> In terms of 509 clarifications, if people think some defect work is needed
> there, please let me know.
> 
> FYI, I'm going to try to get all my editing tasks from the recent X.509
> meeting completed and provide a brief summary
> of the meeting to this list prior to the PKIX meeting. There are a couple
> of current issues we're working on with respect
> to SOAs that PMI folks might be interested in.
> 
> Again, apologies for the length of the message.
> Sharon
> 
> Sharon Boeyen
> Principal, Advanced Security
> Tel: [phone]
> www.entrust.com
> 
> Entrust, Inc.
> Securing the Internet


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2FG9pa01631 for ietf-pkix-bks; Fri, 15 Mar 2002 08:09:51 -0800 (PST)
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 g2FG9n401626 for <[e-mail]>; Fri, 15 Mar 2002 08:09:49 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA23998 for <[e-mail]>; Fri, 15 Mar 2002 17:12:00 +0100
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002031517091878:186 ; Fri, 15 Mar 2002 17:09:18 +0100 
Message-ID: <[e-mail]>
Date: Fri, 15 Mar 2002 17:09:17 +0100
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]>
Subject: DPD/DPV reqmts
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 15/03/2002 17:09:19, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 15/03/2002 17:09:50, Serialize complete at 15/03/2002 17:09:50
Content-Transfer-Encoding: 7bit
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>

To the list,

You will find hereafter additional responses to the comments raised during
the WG last call. In any case for further discussions, please indicate first
the comment number. This was not done by Petra and thus does not make the
task easy. Also do not use separate e-mails.

[About COMMENT 1]

>From Petra Barzin <[e-mail]>

I don't see why you differentiate between signed and authenticated 
responses. 

The same is true for signed responses: either the hash of 
the request or the important elements from the request must be present. 
In order to test the response against what has been requested the client 
has to keep his request or at least the hash of his request. 

The advantage of a hash - instead of copying all important elements 
from the request -  is: 

(a) that the response will be smaller and 
(b) adding a new important element to the request doesn't require a 
change of the response. 

  - a hash of the request MUST be included in the response.
    This may allow the client to check if his request was maliciously
    modified (if the response is signed) and helps to associate the
    response with his request when using connectionless protocols.

[Answer 1] The requirements are different whether the requester simply
wants an authenticated response or a signed response. For a signed response
the inclusion of the important elements from the request is needed, so that
a response can be individually tested against what has been requested. For
an authenticated response, the hash of the request is sufficient. To
summarize:

    - for signed responses, the important elements from the request
      must be present.

    - for authenticated responses, either the hash of the request or the
      important elements from the request must be present.

[Additional Answer 1]

Two answers:

1) Signed answer may be individually re-verified, while authenticated
answers may depend on a context that cannot necessarily be reconstructed
later on. If signed answers are used for authenticated responses, then there
is no more difference, but here we indicate requirements, not solutions.

2) The most important is to be able to use a signed response alone. If the
signed response only contains the hash of the request, then the request must
also be kept to know what the question was. A format for concatenating the
request with the signed response would then be necessary.

So, contradictory to what Peter(Sylvester) said, copying the request in the
response, or just including its hash is not a protocol designers
prerogative.


[About COMMENT 2]

yes, indeed. There is a contradiction. My last sentence should be:
The random number doesn't have to be repeated in the response
*because* the response contains a hash of the request.

I don't understand your last comment. The client does not compute
the hash over all the fields from the response but from his request!

> - a random number MAY be included in the request.
> This allows replay protection when the client has no clock.
> The random number doesn't have to be repeated in the response
> if the response contains a hash of the request.
>
> [Answer 2] Replay protection is so obvious that it has been omitted. We
> could certainly add some text. The nonce cryptographically binds a request
> and a response to prevent replay attacks. However when you say: "The random
> number doesn't have to be repeated in the response *if* the response
> contains a hash of the request". This sentence is in contradiction with your
> first comment where you say: "a hash of the request MUST be included in the
> response". A choice needs to me made.  :-)
>
> I believe that the nonce should be in the response as well, just because it
> is easier for the client to compute the hash over all the fields from the
> response instead of saying: "after the item X, I need to copy the nonce from
> the request".

[Additional Answer 2]

At this time we have not agreed to always include the hash of the request.
So if the hash is not there, then the random number must be there. See also
the argumentation about comment 1 above.


>From Peter Sylvester

Most of the previous responses have been prepared collaboratively by the two
co-editors: Russ and myself. Therefor, I would kindly ask to Peter Sylvester
to avoid to use "you", in particular with a capital Y in words like "You" or
"Your".

[About COMMENT 5]

> - a method to authenticate a server before sending any request
>    (for example this can be achieved by SSL).
>    (Another example would be using encryption.)

> [Answer 5]. This is covered under the following wording: "In order to be
> able to be confident that the validation of the certificate has correctly
> been done, the client only requires an authenticated response". No change is
> necessary.

This statement covers authentication of a response, I am asking for
authentication of the service before sending a request. Regarding
your response to the next comment, yes, this can be implemented by
a transport mechanism, but there is still a requirement. 

[Additional Answer 5]

Authentication of the service before sending a request is not performed in
similar protocols like OCSP. There is no particular reason to do so for this
protocol.

[About COMMENT 6]

> - a method to ensure confidentiality of the transport.

> [Answer 6] There is nothing here in that protocol that mandates
> confidentiality like protecting the value of a private key or a secret key.
> The transport can provide confidentiality in support of environments that do
> not wish to reveal requests or responses contents, e.g. using TLS or S/MIME.

Basically You agree that there is a requirement for confidentiality. Whether
it can be supported by a transport mechanism is a solution. 

> No change is necessary.

I Disagree.

[Additional Answer 6]

There is no requirement on the protocol to support confidentiality. In the
same way OCSP does not support confidentiality at the level of the protocol,
but can support it at the transport level.

[About COMMENT 7]

> - a method that client and server provide their identity
>    in the requests and responses: 'You, the client X, has
>    asked me, the server Y, the following question, and
>    I, the server Y, with the help of server Z respond.'

> This allows to be able to determine the participating entities
> without having access to whatever particular authentication
> method information.

> [Answer 7] Actually, we already include the identity of the server in the
> response. The request could also be optionally signed. This allows 
> the server to authenticate the client, and this authentication allows the 
> server to only support a selective community if desired. An option to be
> able to sign the request may be added.

> The following requirements may be used for example in case of
> validation of an encryption certificate before usage.

There is a difference between authentication and identification.
The request is that the identification is independant from the
authentication methods and the transports. 

A signing entity (the one identified in a signer info or a certificate)
may or may not be the same as the one declared in the request/response.
you may have separation of roles or other situations. 

"The President of the United States declares, ... signed by JWB".

Another example is in relaying as follows: 

Your company service declares that I can use Your encryption cert,
and the response is signed by my local service. 

[Additional Answer 7]

It is unclear what requirement is being addressed and what kind of treatment
would be done with such an identity field.


[About COMMENT 8]

> One may resume the relaying requirements into one:

> - The protocol MUST provide a means to allow (visible) relaying
>    of requests and responses.

> - Relaying requirements:

> - depending on policy, a server may just impersonate another
>    server, i.e., take the responses of another server, and create
>    its own response out of them.

> - a server should be able to include the response of a relayed
>    server into his response.

> - a server should be able to simple add another authentication
>    scheme to a response from another server (for example by
>    using a second signature or a counter signature.)

> - a server that acts as a relay should be able to tell to the
>    next server that it is acting on behalf of a end user, and
>    the final server should be able to note this in the response.

> - For relaying, the protocol MUST provide an efficient means
>    to detect loops.

> [Answer 8] Clients trust some dedicated servers. They don't care how the
> information that is provided has been established: there is a single server
> that is responsible: the one which provides the answer. If the response is
> signed by the expected private key, then it is acceptable, otherwise it is
> not. There are not requirements for chaining or referral services. Relaying
> between servers is not the topic of this document. No change is necessary.

There is already a requirement that a service returns all information
obtained from other services. There may be OCSP responses, crls, etc.
Relaying 
of one request (for example of an encryption certificate before its usage)
to 
another DPV service seems a possible implementation. 

If I would follow Your logic, then the DPV server never needs to return
anything else than a authenticable YES/NO/DONTKNOW. 

There are requirements for relaying etc. 

[Additional Answer 8]

There are no requirement for relying nor referrals. We are not going to jump
into the complexity of protocols like DAP(Directory Access Protocol). Note
also that in addition to the YES/NO/DONTKNOW authenticable answer, the path
elements may be returned.


[About COMMENT 9]

> - Requirements for incomplete answers:

> - a server may indicate an incomplete response,
>    and provide a method to update the response later.

> [Answer 9] This would create the maintenance of state information which
> should be avoided. There has been plenty of discussion on the list regarding
> the number of states.  People clearly want the fewest possible number. The
> client may query again later on. No change is necessary.

You are accepting the requirement as such but You propose not to 
include it in the document because of some implementation detail. 

You always have state in a server (maintaing a TCP connection for example.)

The fact that this requirement requires some particular feature in
an implementation does not mean that the requirement doesn't exist.

It does neither mean that a particular implementation of the protocol
MUST implement for example given a first online response and sending
a later mail. 

[Additional Answer 9]

As already said, there has been plenty of discussion on the list regarding
the number of states.  People clearly want the fewest possible number.


From: Yuriy Dzambasow" <[e-mail]>

Some additional comments.  I have separated them into the following
categories: editorial and technical.

Editorial (at least I am assuming these are editorial):

[COMMENT 19]

1) Recommend deleting the 2nd paragraph on page 5 (Section 5) for the
following reasons:
        - the first sentence attempts to qualify the preceding paragraph,
and in my
opinion, adds no additional value
        - the second sentence contains redundant information already defined
two
paragraphs above

[Answer 19]

The second paragraph on page 5 (Section 5) is:

Clients MUST be able to specify whether they want, in addition to the 
certification path, the revocation information associated with the 
path, for the end-entity certificate only, for the CA certificates 
only or for both.

This text is not redundant. You are certainly pointing to another paragraph.
Next time, please provide a short extract.

[COMMENT 20]

2) In section 5, 3rd paragraph it says, "...In that case it is acceptable to
pass the parameters from the path discovery policy with each individual
request, i.e. a set of trust anchors..."  Please change the "i.e." to "e.g."

[Answer 20]

OK.

[COMMENT 21]

3) Section 8, first paragraph: The text states that a client can use a
request/response pair to define to a server a "..validation policy and/or a
path discovery policy..."  Please change "and/or" to "or".

[Answer 21]

OK.

[COMMENT 22]

4) Change title of 8.1.1 to Certification Path Requirements, so that it is
consistent with the text in section 8.1, item 1.

[Answer 22]

OK.

Technical:

Most of my comments have been addressed (or are being addressed on previous
threads).  I have these three additional comments:

[COMMENT 23]

1) Why does DPD say that it is OK to pass some policy parameters within a
DPD request if the policy is simple enough (section 5), but just the
opposite is said for DPV (section 4)?  I would think that a simple policy
could be adhered to as well for DPV, and that the parameter specification
could occur within the DPV request.

[Answer 23]

The document does not provide details about what means "simple". However the
idea is the following: when there is a single root, with no constraints
(unless contained in the self-signed certificate itself) and when any CRL
status information is acceptable, then the policy can be considered as
simple. Specific checks on the end-certificate are always done locally.

With DPV the policy has to say which CRL information is necessary for each
leg. But the most important is that checks on the end-certificate have to be
done remotely and specifying them is that not simple.

[COMMENT 24]

2) For DPD responses (page 5), why do the first three response types say,
"...according to the path discovery policy...", while the last response type
says, "...according to the path discovery criteria..."?  What is the
difference between policy and criteria?  If there is no difference, then I
recommend changing "criteria" to "policy".

[Answer 24]

OK.

[COMMENT 25]

3) Section 8:  I think it would be helpful to break out the PDP requirements
section into two areas: 

1) requirements around the coordination of a validation/path discovery
policy
between a client and a server to support the validation/path discovery for 
a given certificate; and 

2) requirements around defining an authorized policy at a server (e.g., used 
by security managers).  

This makes it clear that PDP can be used in two distinct ways.

[Answer 25]

PDP only addresses the later. It is unclear what is being requested for the
first area. Please explain.


>From Petra Barzin <[e-mail]>

[COMMENT 26]

I would propose the following:

- add one more sentence to section 6:

The protocol SHALL allow clients to obtain the identifier and
definition of a specific, the default or all of the policies supported
by the server by using another additional request/response pair.

[Answer 26]

Not all policies have a definition that can be given back (e.g. when locally
defined). However the identifier (e.g. OID) of the policy can always be
given back. So I would propose to change the sentence as follows:

"The protocol SHALL allow clients to obtain the references for a specific,
the default or all of the policies supported by the server by using an
additional request/response pair."

[COMMENT 27]

- and add another section after the PDP requirements:

Policy Retrieval Protocol (PRP) requirements
In order to archive the validation result of a certificate, it MAY be
necessary to combine it with the used validation policy. In some
cases the client MAY want to get an overview of all validation
policies supported by the server. Both reasons result in the following
requirements for the Policy Retrieval Protocol :

* return a specific validation policy definition
* return the default validation policy definition incl. its identifier
* return all validation policy definitions incl. their identifiers
* return max. number of validation policy definitions incl. their
identifiers
* return max. number of validation policy identifiers

The last two requirements are especially useful for thin clients with
small display facilities.

[Answer 27]

What you propose should be restricted to policies defined with the PDP
protocol. I would prefer to retrieve one by one the policies. So using first
the result of the previous responses, mandated by section 6, I would
propose the following text for a new section 9: 

Policy Retrieval Protocol (PRP) requirements

This protocol will allow to obtain the details of a policy provided that it
has been previously defined using PDP. Thus by providing an identifier, the
request will include the definition of the policy, as originally provided.

Regards,

Denis


Received: by above.proper.com (8.11.6/8.11.3) id g2FE5Jo24051 for ietf-pkix-bks; Fri, 15 Mar 2002 06:05:19 -0800 (PST)
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 g2FE5H424046 for <[e-mail]>; Fri, 15 Mar 2002 06:05:17 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA20780; Fri, 15 Mar 2002 15:07:25 +0100
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002031515040502:161 ; Fri, 15 Mar 2002 15:04:05 +0100 
Message-ID: <[e-mail]>
Date: Fri, 15 Mar 2002 15:03:56 +0100
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: [e-mail]
Subject: Re: Updating RFC 3039 - and its impact on PI
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 15/03/2002 15:04:05, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 15/03/2002 15:05:15, Serialize complete at 15/03/2002 15:05:15
Content-Transfer-Encoding: 7bit
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>

Stefan,

See some comments below:
 
> As author and implementer of RFC 3039 and in the light of practical
> experience with RFC 3039, I think we should be ready to revise this RFC
> and handle some defects.
> 
> The defects I have recorded so far are:
> 
> 1) Key usage
> The key usage bit non-repudiation SHOULD NOT be set together with any
> other key usage according to RFC 3039. This has caused a lot of confusion
> and this "SHOULD NOT" statement is not compatible with existing reality.

Could you be more explicit about a suggested text replacement ?

> 2) Attribute semantics
> This function to define semantics for attributes included in the subject
> field is very useful and it covers almost everything that the current PI
> draft wants to solve. 

Could you be more specific ?

> The problem is that this function is part of the
> qcStatements extension which it should not be. Firstly due to the fact
> that this statement has nothing to do with the intent of this extension
> and secondly because criticality setting for this function get mixed up
> with completely unrelated stuff in its current form.
 
> 3) Usage and purpose
> RFC 3039 is the only RFC defining structure of a personal ID certificate.
> This should not be limited just to Qualified certificates. It should be
> more clear that this RFC is useful for any personal ID certificate. Also
> non-qualified ones.

Fine.
 
> Finally I believe that a revision of RFC 3039 should include
> considerations to avoid the need for a PI extension according to the PI
> draft.
> 
> I can't see that the PI draft accomplish anything that RFC 3039 doesn't
> already solve, or at least would solve after revision. 

The revised document will not be able to solve what the PI document covers
since the PI document applies to *any entity* whereas the revised RFC 3039
document is planned to apply only to *personal ID certificates*. Maybe the
revised RFC 3039 could take advantage and refer to the PI document.

> The only exception is the function to define an identifier completely 
> independent of the subject name. 

Thank you for noticing this difference.

Regards,

Denis

> I would tough argue that the total case with all aspects on
> the table probably doesn't justify another feature for that and that there
> are other ways to solve this within the realm of X.509 and PKIX standards.
 
> I still believe that a creative revision of RFC 3039 could be made to
> cover what we need in this area. And I also recall this as an initially
> defined possibility laid down for the PI work.
 
> /Stefan


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2FAQKv12137 for ietf-pkix-bks; Fri, 15 Mar 2002 02:26:20 -0800 (PST)
Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2FAQH412132 for <[e-mail]>; Fri, 15 Mar 2002 02:26:18 -0800 (PST)
Received: from stsIBMT20.addtrust.com ([192.168.101.114]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 15 Mar 2002 11:26:06 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 15 Mar 2002 11:25:40 +0100
To: [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Updating RFC 3039 - and its impact on PI
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_74642179==_.ALT"
X-OriginalArrivalTime: 15 Mar 2002 10:26:06.0937 (UTC) FILETIME=[D12FEC90:01C1CC0B]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

As author and implementer of RFC 3039 and in the light of practical 
experience with RFC 3039, I think we should be ready to revise this RFC and 
handle some defects.

The defects I have recorded so far are:

1) Key usage
The key usage bit non-repudiation SHOULD NOT be set together with any other 
key usage according to RFC 3039. This has caused a lot of confusion and 
this "SHOULD NOT" statement is not compatible with existing reality.

2) Attribute semantics
This function to define semantics for attributes included in the subject 
field is very useful and it covers almost everything that the current PI 
draft wants to solve. The problem is that this function is part of the 
qcStatements extension which it should not be. Firstly due to the fact that 
this statement has nothing to do with the intent of this extension and 
secondly because criticality setting for this function get mixed up with 
completely unrelated stuff in its current form.

3) Usage and purpose
RFC 3039 is the only RFC defining structure of a personal ID certificate. 
This should not be limited just to Qualified certificates. It should be 
more clear that this RFC is useful for any personal ID certificate. Also 
non-qualified ones.

Finally I believe that a revision of RFC 3039 should include considerations 
to avoid the need for a PI extension according to the PI draft.

I can't see that the PI draft accomplish anything that RFC 3039 doesn't 
already solve, or at least would solve after revision. The only exception 
is the function to define an identifier completely independent of the 
subject name. I would tough argue that the total case with all aspects on 
the table probably doesn't justify another feature for that and that there 
are other ways to solve this within the realm of X.509 and PKIX standards.

I still believe that a creative revision of RFC 3039 could be made to cover 
what we need in this area. And I also recall this as an initially defined 
possibility laid down for the PI work.

/Stefan



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

<html>
As author and implementer of RFC 3039 and in the light of practical
experience with RFC 3039, I think we should be ready to revise this RFC
and handle some defects.<br><br>
The defects I have recorded so far are:<br><br>
1) Key usage<br>
The key usage bit non-repudiation SHOULD NOT be set together with any
other key usage according to RFC 3039. This has caused a lot of confusion
and this &quot;SHOULD NOT&quot; statement is not compatible with existing
reality.<br><br>
2) Attribute semantics<br>
This function to define semantics for attributes included in the subject
field is very useful and it covers almost everything that the current PI
draft wants to solve. The problem is that this function is part of the
qcStatements extension which it should not be. Firstly due to the fact
that this statement has nothing to do with the intent of this extension
and secondly because criticality setting for this function get mixed up
with completely unrelated stuff in its current form.<br><br>
3) Usage and purpose<br>
RFC 3039 is the only RFC defining structure of a personal ID certificate.
This should not be limited just to Qualified certificates. It should be
more clear that this RFC is useful for any personal ID certificate. Also
non-qualified ones.<br><br>
Finally I believe that a revision of RFC 3039 should include
considerations to avoid the need for a PI extension according to the PI
draft.<br><br>
I can't see that the PI draft accomplish anything that RFC 3039 doesn't
already solve, or at least would solve after revision. The only exception
is the function to define an identifier completely independent of the
subject name. I would tough argue that the total case with all aspects on
the table probably doesn't justify another feature for that and that
there are other ways to solve this within the realm of X.509 and PKIX
standards.<br><br>
I still believe that a creative revision of RFC 3039 could be made to
cover what we need in this area. And I also recall this as an initially
defined possibility laid down for the PI work.<br><br>
/Stefan<br><br>
<br>
</html>

--=====================_74642179==_.ALT--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2EJ9ve20041 for ietf-pkix-bks; Thu, 14 Mar 2002 11:09:57 -0800 (PST)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2EJ9t420037 for <[e-mail]>; Thu, 14 Mar 2002 11:09:55 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <G8SL0LC4>; Thu, 14 Mar 2002 14:09:52 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Attribute Certificates and Privilege Policy
Date: Thu, 14 Mar 2002 14:09:49 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CB8B.D04FD4F0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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_01C1CB8B.D04FD4F0
Content-Type: text/plain;
	charset="iso-8859-1"

I'll try to address all the questions I've seen re the 509 aspects of this
discussion. (Sorry this is rather long, but I found this 
easier than trying to respond to each message).

I think Peter has identified at least one part of 509 that could benefit
from some editorial clarification. 

Clause 16 "Privilege path processing procedure" may be more appropriate
titled "Privilege assertion processing procedure".
Each paragraph in 16.1 could probably use subtitles to clarify what's really
going on. The paragraphs in this section are basically 
a list of each of the checks that need to be done before an asserted
privilege can be granted to a claimant. 
- Para 1 is doing a "validation" on each of the attribute certificates in
the path. This is just checking the signatures, using the 
PKI path validation steps as if you were checking the signature on a signed
form - the details are in clause 10 of the PKI section. 
- Para 2 is a check to ensure the claimant's willingness to use that
attribute cert for the context - no standard steps for this 
check are defined.
- Para 3 is the revocation status check - no details req'd
- Para 4 is the check for whether the asserted privilege is valid for the
time of interest - no details req'd
- Para 5 is checking any constraints imposed by the issuer of the AC on the
set of permitted targets - no details req'd
- Para 6 is the checks for roles and of delegation. Note that 16.2 is merely
the details associated with the role check and 
16.3 is merely the details assoiated with the delegation check.
- Para 7 is the privilege policy check against the asserted privilege
together with the other inputs (target sensitivity, 
environmental variables) and checking any constraints on privilege policy
imposed by the issuer.

So this complete set of steps comprise the processing that needs to be done
to assess a privilege assertion. Some of these
relate to paths (Para 1 is processing of a public-key certification path to
verify the signature on the attribute cert and 
Para 6 along with 16.3 is processing of a delegation path of attribute
certificates to determine whether or not the delegation 
itself is authorized and valid. As part of the processing of a delegation
path, note that the signature on EACH attribute 
certificate in the path needs to be verified, so again the public-key path
validation is used for that purpose). I wanted to 
try to clarify this because asking if something is part of "path validation"
is not as easy to answer as it would be if 
we were talking about PKI instead of PMI.  

The privilege policy is the basis for determining the acceptance of an
attribute certificate (at least from a policy perspective).
It is processed by a verifier as one of the steps in assessing a privilege
assertion, but it is not strictly part of either 
public-key certification path processing done for signature verification or
part of delegation path processing for verifying 
delegation. 

Many aspects of privlege policy were not standardized in 509, including its
syntax, who can write them etc, how does 
a verifier know which one to use etc. Some of these were deferred, e.g.
syntax. Note however, that in OASIS, the XACML 
working group is now defining a standard XML syntax for access control
policy. Some material from the sample syntaxes 
in the X.509 informative annex were input to the XACML work so folks
interested in privilege policy may find that work 
interesting as well. As for how the verifier knows which privilege policy to
use - that is left to the implementation. In 
some cases a target may always work with a single privilege policy and it
may be created by the local SOA . There 
are hooks to tie privilege policies to attributes for which an SOA assigns
privileges (the attributeDescriptor in 15.3.2.2 and 
there is also directory syntax to store them, but no standardized way for a
verifier to determine which to use. However a local
trusted SOA would obviously be one possible source of privilege policies. 

Regarding the acceptablePrivilegePolicies extension, a verifier is always
assessing a privilege assertion with respect to 
a specific privilege policy as per para 7 in 14.1. In the absence of the
acceptablePrivilegePolicies extension, the verifier 
merely assess the assertion with respect to the privilege policy it is
working with (out of band / local means for determining
which privilege policy the verifier operates with - likely greatly
determined by the target). If the acceptablePrivilegePolicies 
extension is present, then the verifier needs to check whether the privilege
policy it is operating under is one of the ones 
listed as acceptable in that extension. If it is, then the verifier proceeds
normally. If it is not, the verifier stops and the privilege
asserter is not given access. 

The privilege policy is the set of rules that determine acceptability of an
asserted privilege. A primary difference between 
that and certificate policy is that certificate policy is tied to a
certificate and defines acceptable uses for that certificate, 
while privilege policy is associated with a verifier and the target that is
in question and determines which privilege assertions
are appropriate. So, things like usage constraints, dollar limits, time
constraints, name constraints - all those things would 
be appropriate for inclusion in a privilege policy. I'm not convinced about
liability limits though, because privilegePolicy must
be machine processable as it is processed dynamically at assertion
assessment time. Liability limits don't seem like they 
would easily lend themselves to this. 

In terms of 'why no certificate policy' - there was no need identified for
an equivalent. A verifier trusts an SOA as the 
ultimate source of authority for assignment of a set of privileges. That's
the authorization issue I mentioned earlier. 
If delegation is done, then the checks for ensuring that is authorized are
part of the delegation path processing 
procedure. If an AA (SOA or delegated AA) wishes to constrain the policy
under which an AC is used, it can do 
so through the acceptablePrivilegePolicies extension. As for certificate
policies, they are used when verifying the 
signature on the attribute certificates as well as when verifying the
signature on any transaction associated with 
the specific assertion of privilege being made by the claimant. So
certificate policies do factor into the overall 
validation for any given transaction, but are not part of the privilege
assertion assessment.

I hope this addresses the questions that were raised by Denis, Chris and
Peter - if not I'm sure you'll let me know :-). 

In terms of 509 clarifications, if people think some defect work is needed
there, please let me know. 

FYI, I'm going to try to get all my editing tasks from the recent X.509
meeting completed and provide a brief summary 
of the meeting to this list prior to the PKIX meeting. There are a couple of
current issues we're working on with respect 
to SOAs that PMI folks might be interested in.

Again, apologies for the length of the message.
Sharon 

Sharon Boeyen
Principal, Advanced Security
Tel: [phone] 
www.entrust.com

Entrust, Inc.
Securing the Internet



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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>Attribute Certificates and Privilege Policy</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">I'll try to address all the questions =
I've seen re the 509 aspects of this discussion. (Sorry this is rather =
long, but I found this </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">easier than trying to respond to each =
message).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I think Peter has identified at least =
one part of 509 that could benefit from some editorial clarification. =
</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Clause 16 &quot;Privilege path =
processing procedure&quot; may be more appropriate titled =
&quot;Privilege assertion processing procedure&quot;.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Each paragraph in 16.1 could probably =
use subtitles to clarify what's really going on. The paragraphs in this =
section are basically </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">a list of each of the checks that need =
to be done before an asserted privilege can be granted to a claimant. =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">- Para 1 is doing a =
&quot;validation&quot; on each of the attribute certificates in the =
path. This is just checking the signatures, using the </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">PKI path validation steps as if you =
were checking the signature on a signed form - the details are in =
clause 10 of the PKI section. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">- Para 2 is a check to ensure the =
claimant's willingness to use that attribute cert for the context - no =
standard steps for this </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">check are defined.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">- Para 3 is the revocation status =
check - no details req'd</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">- Para 4 is the check for whether the =
asserted privilege is valid for the time of interest - no details =
req'd</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">- Para 5 is checking any constraints =
imposed by the issuer of the AC on the set of permitted targets - no =
details req'd</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">- Para 6 is the checks for roles and =
of delegation. Note that 16.2 is merely the details associated with the =
role check and </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">16.3 is merely the details assoiated =
with the delegation check.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">- Para 7 is the privilege policy =
check against the asserted privilege together with the other inputs =
(target sensitivity, </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">environmental variables) and checking =
any constraints on privilege policy imposed by the issuer.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">So this complete set of steps comprise =
the processing that needs to be done to assess a privilege assertion. =
Some of these</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">relate to paths (Para 1 is processing =
of a public-key certification path to verify the signature on the =
attribute cert and </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Para 6 along with 16.3 is processing =
of a delegation path of attribute certificates to determine whether or =
not the delegation </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">itself is authorized and valid. As =
part of the processing of a delegation path, note that the signature on =
EACH attribute </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">certificate in the path needs to be =
verified, so again the public-key path validation is used for that =
purpose). I wanted to </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">try to clarify this because asking if =
something is part of &quot;path validation&quot; is not as easy to =
answer as it would be if </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">we were talking about PKI instead of =
PMI.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The privilege policy is the basis for =
determining the acceptance of an attribute certificate (at least from a =
policy perspective).</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">It is processed by a verifier as one =
of the steps in assessing a privilege assertion, but it is not strictly =
part of either </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">public-key certification path =
processing done for signature verification or part of delegation path =
processing for verifying </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">delegation. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Many aspects of privlege policy were =
not standardized in 509, including its syntax, who can write them etc, =
how does </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">a verifier know which one to use etc. =
Some of these were deferred, e.g. syntax. Note however, that in OASIS, =
the XACML </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">working group is now defining a =
standard XML syntax for access control policy. Some material from the =
sample syntaxes </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">in the X.509 informative annex were =
input to the XACML work so folks interested in privilege policy may =
find that work </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">interesting as well. As for how the =
verifier knows which privilege policy to use - that is left to the =
implementation. In </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">some cases a target may always work =
with a single privilege policy and it may be created by the local SOA . =
There </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">are hooks to tie privilege policies =
to attributes for which an SOA assigns privileges (the =
attributeDescriptor in 15.3.2.2 and </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">there is also directory syntax to =
store them, but no standardized way for a verifier to determine which =
to use. However a local</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">trusted SOA would obviously be one =
possible source of privilege policies. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regarding the =
acceptablePrivilegePolicies extension, a verifier is always assessing a =
privilege assertion with respect to </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">a specific privilege policy as per =
para 7 in 14.1. In the absence of the acceptablePrivilegePolicies =
extension, the verifier </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">merely assess the assertion with =
respect to the privilege policy it is working with (out of band / local =
means for determining</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">which privilege policy the verifier =
operates with - likely greatly determined by the target). If the =
acceptablePrivilegePolicies </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">extension is present, then the =
verifier needs to check whether the privilege policy it is operating =
under is one of the ones </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">listed as acceptable in that =
extension. If it is, then the verifier proceeds normally. If it is not, =
the verifier stops and the privilege</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">asserter is not given access. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The privilege policy is the set of =
rules that determine acceptability of an asserted privilege. A primary =
difference between </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">that and certificate policy is that =
certificate policy is tied to a certificate and defines acceptable uses =
for that certificate, </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">while privilege policy is associated =
with a verifier and the target that is in question and determines which =
privilege assertions</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">are appropriate. So, things like usage =
constraints, dollar limits, time constraints, name constraints - all =
those things would </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">be appropriate for inclusion in a =
privilege policy. I'm not convinced about liability limits though, =
because privilegePolicy must</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">be machine processable as it is =
processed dynamically at assertion assessment time. Liability limits =
don't seem like they </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">would easily lend themselves to this. =
</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In terms of 'why no certificate =
policy' - there was no need identified for an equivalent. A verifier =
trusts an SOA as the </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">ultimate source of authority for =
assignment of a set of privileges. That's the authorization issue I =
mentioned earlier. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">If delegation is done, then the checks =
for ensuring that is authorized are part of the delegation path =
processing </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">procedure. If an AA (SOA or delegated =
AA) wishes to constrain the policy under which an AC is used, it can do =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">so through the =
acceptablePrivilegePolicies extension. As for certificate policies, =
they are used when verifying the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">signature on the attribute =
certificates as well as when verifying the signature on any transaction =
associated with </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the specific assertion of privilege =
being made by the claimant. So certificate policies do factor into the =
overall </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">validation for any given transaction, =
but are not part of the privilege assertion assessment.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I hope this addresses the questions =
that were raised by Denis, Chris and Peter - if not I'm sure you'll let =
me know :-). </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In terms of 509 clarifications, if =
people think some defect work is needed there, please let me know. =
</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">FYI, I'm going to try to get all my =
editing tasks from the recent X.509 meeting completed and provide a =
brief summary </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">of the meeting to this list prior to =
the PKIX meeting. There are a couple of current issues we're working on =
with respect </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">to SOAs that PMI folks might be =
interested in.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Again, apologies for the length of the =
message.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Sharon </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Sharon Boeyen</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Principal, Advanced =
Security</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Tel: [phone] </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">www.entrust.com</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Entrust, Inc.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Securing the Internet</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C1CB8B.D04FD4F0--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2EIqBc18737 for ietf-pkix-bks; Thu, 14 Mar 2002 10:52:11 -0800 (PST)
Received: from cisco.com (pita.cisco.com [171.71.68.13]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2EIqA418731; Thu, 14 Mar 2002 10:52:10 -0800 (PST)
Received: from pritikinw2k (dhcp-171-71-73-22.cisco.com [171.71.73.22]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id KAA18867; Thu, 14 Mar 2002 10:51:30 -0800 (PST)
From: "Max Pritikin" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Paul Hoffman / IMC" <[e-mail]>
Cc: "pkix" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-okid-01.txt
Date: Thu, 14 Mar 2002 10:49:49 -0800
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.2910.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Possibly the end user MUST be informed of the new trust anchor and MUST have
the bulleted items *available* for inspection but only MAY be actually
informed of them.

Thus Paul's point is addressed; that the information is important and really
must be examined and handled -- implementors are coerced into paying
attention to it ("MUST be available"). Denis is correct though that many
users will only be confused by the additional information and thus they only
examine it when needed.

	- Max

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Denis Pinkas
> Sent: Thursday, March 14, 2002 10:04 AM
> To: Paul Hoffman / IMC
> Cc: pkix
> Subject: Re: I-D ACTION:draft-ietf-pkix-okid-01.txt
>
>
>
> Paul,
>
> Thank you for your *very* quick answer.
>
> (some text deleted)
>
> > So, here is where we get into the discussion of enforcing good
> > security policy. My wording had the bulleted list as MUSTs. You have
> > reduced them past SHOULD to MAY. The result of this is that few
> > implementations will tell end users the effects of what they are
> > doing (a SHOULD would probably do more).
> >
> > I think this reduction is dangerous in that it does not tell the end
> > user enough about the effects of her or his actions; other people
> > would say that it is not our responsibility to insist on telling the
> > end user this.
> >
> > Quite frankly, there are probably lots of implementors who use PKIX
> > toolkits who don't realize all the ramifications of using a trust
> > anchor are. Forcing them to tell their users will make them much more
> > aware of their responsibility.
>
> Many people do not have your or my education in PKI. They are told to
> install a new root. They only need to know how to install it
> properly. They
> do not even know which key they are installing. They got a URL where to
> fetch the self-sigend certificate and then must be sure that what they get
> matches the hash. That's all. They have not the simplest idea of
> what means:
>
>  - the policies used by the issuer of this certificate to issue
> subordinate
>    certificates,
>
>  - the basic constraints placed on the issuer of this certificate,
>
>  - the depth of subordinate chain that can be issued under this
> certificate,
>
>  - the types of names for which the issuer of this certificate can create
>    certificates,
>
>  - the policy constraints placed on the issuer of this certificate.
>
> I believe that the debate should now be between SHOULD and MAY.
>
> Denis
>
>
>
> > --Paul Hoffman, Director
> > --Internet Mail Consortium
>



Received: by above.proper.com (8.11.6/8.11.3) id g2EI49h17036 for ietf-pkix-bks; Thu, 14 Mar 2002 10:04:09 -0800 (PST)
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 g2EI47417030; Thu, 14 Mar 2002 10:04:07 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id TAA26146; Thu, 14 Mar 2002 19:06:18 +0100
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002031419033769:80 ; Thu, 14 Mar 2002 19:03:37 +0100 
Message-ID: <[e-mail]>
Date: Thu, 14 Mar 2002 19:03:36 +0100
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: Paul Hoffman / IMC <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-01.txt
References: <[e-mail]> <[e-mail]> <p05101408b8b68f1955ce@[165.227.249.20]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 14/03/2002 19:03:37, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 14/03/2002 19:04:09, Serialize complete at 14/03/2002 19:04:09
Content-Transfer-Encoding: 7bit
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>

Paul,

Thank you for your *very* quick answer.

(some text deleted)
 
> So, here is where we get into the discussion of enforcing good
> security policy. My wording had the bulleted list as MUSTs. You have
> reduced them past SHOULD to MAY. The result of this is that few
> implementations will tell end users the effects of what they are
> doing (a SHOULD would probably do more).
> 
> I think this reduction is dangerous in that it does not tell the end
> user enough about the effects of her or his actions; other people
> would say that it is not our responsibility to insist on telling the
> end user this.
> 
> Quite frankly, there are probably lots of implementors who use PKIX
> toolkits who don't realize all the ramifications of using a trust
> anchor are. Forcing them to tell their users will make them much more
> aware of their responsibility.

Many people do not have your or my education in PKI. They are told to
install a new root. They only need to know how to install it properly. They
do not even know which key they are installing. They got a URL where to
fetch the self-sigend certificate and then must be sure that what they get
matches the hash. That's all. They have not the simplest idea of what means:

 - the policies used by the issuer of this certificate to issue subordinate
   certificates,

 - the basic constraints placed on the issuer of this certificate, 

 - the depth of subordinate chain that can be issued under this certificate,
 
 - the types of names for which the issuer of this certificate can create
   certificates,
  
 - the policy constraints placed on the issuer of this certificate.

I believe that the debate should now be between SHOULD and MAY.

Denis


 
> --Paul Hoffman, Director
> --Internet Mail Consortium


Received: by above.proper.com (8.11.6/8.11.3) id g2EHgJZ16451 for ietf-pkix-bks; Thu, 14 Mar 2002 09:42:19 -0800 (PST)
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2EHgG416443; Thu, 14 Mar 2002 09:42:16 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05101408b8b68f1955ce@[165.227.249.20]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Thu, 14 Mar 2002 09:42:13 -0800
To: Denis Pinkas <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-01.txt
Cc: 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>

At 6:19 PM +0100 3/14/02, Denis Pinkas wrote:
>1. Editorial. Choose either OKID or OCKID.
>    I don't care as long as there is a single acronym.

Yipes! I thought I had done it everywhere except in the draft name; 
turns out I missed a bunch. (And I left it in the draft name so I 
didn't have to recycle at -00...).

>Hence I would propose a text along the following:
>
>"Because the result of matching the OCKID to the CA certificate is that the
>certificate will now become a trust anchor, the system MUST inform the user
>that the certificate has become a trust anchor.
>
>The system SHOULD give the user a method for later removing the trust in the
>CA certificate.
>
>It MAY provide additional information to the user like:
>
>- The policies used by the issuer of this certificate to issue subordinate
>certificates ([PKIX] section 4.2.1.5)
>
>- The basic constraints placed on the issuer of this certificate, such as
>the depth of subordinate chain that can be issued under this certificate
>([PKIX] section 4.2.1.10)
>
>- The types of names for which the issuer of this certificate can create
>certificates ([PKIX] section 4.2.1.11)
>
>- The policy constraints placed on the issuer of this certificate ([PKIX]
>section 4.2.1.12)
>
>The system SHOULD also check whether the certificate is properly signed,
>that is, that the public key in the certificate is in fact correctly
>verifies the contents of the certificate."

So, here is where we get into the discussion of enforcing good 
security policy. My wording had the bulleted list as MUSTs. You have 
reduced them past SHOULD to MAY. The result of this is that few 
implementations will tell end users the effects of what they are 
doing (a SHOULD would probably do more).

I think this reduction is dangerous in that it does not tell the end 
user enough about the effects of her or his actions; other people 
would say that it is not our responsibility to insist on telling the 
end user this.

Quite frankly, there are probably lots of implementors who use PKIX 
toolkits who don't realize all the ramifications of using a trust 
anchor are. Forcing them to tell their users will make them much more 
aware of their responsibility.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2EHK2O16005 for ietf-pkix-bks; Thu, 14 Mar 2002 09:20:02 -0800 (PST)
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 g2EHJx415996; Thu, 14 Mar 2002 09:20:00 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA25838; Thu, 14 Mar 2002 18:22:07 +0100
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002031418193600:77 ; Thu, 14 Mar 2002 18:19:36 +0100 
Message-ID: <[e-mail]>
Date: Thu, 14 Mar 2002 18:19:03 +0100
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: Paul Hoffman <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-01.txt
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 14/03/2002 18:19:36, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 14/03/2002 18:19:59, Serialize complete at 14/03/2002 18:19:59
Content-Transfer-Encoding: 7bit
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>

Paul,

You made quite a good job, with this new specification since the hash is now
computed over the whole certificate instead of the public key only.

A few comments:

1. Editorial. Choose either OKID or OCKID. 
   I don't care as long as there is a single acronym.

2. I have some concerns with section 4 when it states:

Because the result of matching the OCKID to the CA certificate is that
the certificate will now become a trust anchor, the system MUST inform
the user of each of the following: 

- That the certificate has become a trust anchor

- The policies used by the issuer of this certificate to issue
subordinate certificates ([PKIX] section 4.2.1.5)

- The basic constraints placed on the issuer of this certificate, such
as the depth of subordinate chain that can be issued under this
certificate ([PKIX] section 4.2.1.10)

- The types of names for which the issuer of this certificate can create
certificates ([PKIX] section 4.2.1.11)

- The policy constraints placed on the issuer of this certificate
([PKIX] section 4.2.1.12)

The system SHOULD give the user a method for later removing the trust in
the CA certificate. The system MUST also check whether the certificate
is properly signed, that is, that the public key in the certificate is
in fact correctly verifies the contents of the certificate.

End of extract.

In most cases the user will only verify that the intended hash matches the
computed hash and will install the self-signed certificates. Controls like
checking the signature of the certificate may be recommanded but should not
be mandatory.

Hence I would propose a text along the following:

"Because the result of matching the OCKID to the CA certificate is that the
certificate will now become a trust anchor, the system MUST inform the user
that the certificate has become a trust anchor.

The system SHOULD give the user a method for later removing the trust in the
CA certificate. 

It MAY provide additional information to the user like:

- The policies used by the issuer of this certificate to issue subordinate
certificates ([PKIX] section 4.2.1.5)

- The basic constraints placed on the issuer of this certificate, such as
the depth of subordinate chain that can be issued under this certificate
([PKIX] section 4.2.1.10)

- The types of names for which the issuer of this certificate can create
certificates ([PKIX] section 4.2.1.11)

- The policy constraints placed on the issuer of this certificate ([PKIX]
section 4.2.1.12)

The system SHOULD also check whether the certificate is properly signed,
that is, that the public key in the certificate is in fact correctly
verifies the contents of the certificate."

Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2DKfNO19630 for ietf-pkix-bks; Wed, 13 Mar 2002 12:41:23 -0800 (PST)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2DKfL419626 for <[e-mail]>; Wed, 13 Mar 2002 12:41:21 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 13 Mar 2002 12:40:22 -0800 (PST)
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, 13 Mar 2002 12:40:21 -0800 (PST)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <GK1PQHKZ>; Wed, 13 Mar 2002 12:41:14 -0800
Content-return: allowed
Date: Wed, 13 Mar 2002 12:41:14 -0800
From: Peter Williams <[e-mail]>
Subject: RE: Attribute Certificate Policy??
To: "'Sharon Boeyen'" <[e-mail]>, Ietf-Pkix <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: multipart/alternative; boundary="Boundary_(ID_JMqEt03LiC3dil9v29hn7A)"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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_JMqEt03LiC3dil9v29hn7A)
Content-type: text/plain

 Sharon,
 
I find your writing the clearest of any architect in PKIX, by far,
and always consistent with simple readings of the international
standards actually say. You always attempt to
adopt the model being specified, rather than contort language 
via profiling to perhaps enable the international standards to addresses 
something else. Whilst a standard is insufficient
if you have to ask an author/editor what it means, I seek
a clear opinion on one issue raised in your mail to PKIX
on the topic of attribute certificate policy and privilege
policies.
 
The opinion issue concerns the "acceptablePrivilegePolicies extension" which
must be absent in a conforming PKIX AC.
 
Question:
 
Does the X.509 standard mean that one should/may evaluate privilege
assertions as valid (against
some privilege policys) in the ABSENCE of acceptablePrivilelge Policies?
 
-------------
 
 
Now I have a point of confusion (being a pretty ignorant soul who
has learned alot in the last week and is very
excited now with PMI given privilege policies) if a verfier 
does indeed evaluate privilege policies:
 
Given your commentary on the authority model of SOA/AAs, and the absence
by design of an AA issuer's certification policy/practice, how does
one determine which privilege policies to apply?
 
Of is the ambiguity of privilege policy requirement there by design,
in the absence of acceptablePrivilegePolicy Extension: that is, its
a relying party matter to select the policies to be applied?
 
 
 
 
 

--Boundary_(ID_JMqEt03LiC3dil9v29hn7A)
Content-type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<TITLE>RE: Attribute Certificate Policy??</TITLE>

<META content="MSHTML 5.00.3103.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
class=025272920-13032002>&nbsp;<SPAN 
class=025272920-13032002>Sharon,</SPAN></SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
class=025272920-13032002><SPAN 
class=025272920-13032002></SPAN></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
class=025272920-13032002><SPAN class=025272920-13032002>I find your writing the 
clearest of any architect in PKIX, by 
far,</SPAN></SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
class=025272920-13032002><SPAN class=025272920-13032002>and 
always</SPAN></SPAN></FONT></FONT></FONT><FONT color=#0000ff face=Arial 
size=2><SPAN class=025272920-13032002> consistent with simple readings of the 
international</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=025272920-13032002>standards actually say. You always attempt 
to</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=025272920-13032002>adopt 
the model being specified, rather than contort 
language&nbsp;</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=025272920-13032002>via 
profiling to perhaps enable&nbsp;the international standards to addresses 
</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=025272920-13032002>something else. Whilst a standard is 
insufficient</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=025272920-13032002>if you 
have to ask an author/editor what it means, I seek</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=025272920-13032002>a 
clear opinion on one issue raised in your mail to PKIX</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=025272920-13032002>on&nbsp;the topic of attribute certificate policy and 
privilege</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=025272920-13032002>policies.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=025272920-13032002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=025272920-13032002>The 
opinion issue&nbsp;concerns the "acceptablePrivilegePolicies extension" 
which</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=025272920-13032002>must 
be absent in a conforming PKIX AC.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=025272920-13032002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=025272920-13032002>Question:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=025272920-13032002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=025272920-13032002>Does 
the X.509 standard mean that one should/may&nbsp;evaluate privilege assertions 
as valid (against</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=025272920-13032002>some 
privilege policys) in the ABSENCE of acceptablePrivilelge 
Policies?</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=025272920-13032002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=025272920-13032002>-------------</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=025272920-13032002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=025272920-13032002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=025272920-13032002>Now I 
have a point of confusion (being a pretty ignorant soul who</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=025272920-13032002>has 
learned alot in the last week and is very</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=025272920-13032002>excited now with PMI given privilege policies) if 
</SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
class=025272920-13032002>a verfier </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=025272920-13032002>does</SPAN></FONT><FONT color=#0000ff face=Arial 
size=2><SPAN class=025272920-13032002> indeed evaluate privilege 
policies:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=025272920-13032002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=025272920-13032002></SPAN></FONT><FONT color=#0000ff face=Arial 
size=2><SPAN class=025272920-13032002>Given your commentary on the authority 
model of SOA/AAs, and the absence</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=025272920-13032002>by 
design of an AA issuer's certification policy/practice, how 
does</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=025272920-13032002>one 
determine which&nbsp;</SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
class=025272920-13032002>privilege policies to apply?</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=025272920-13032002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=025272920-13032002>Of is 
the ambiguity of privilege policy requirement there by 
design,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=025272920-13032002>in the 
absence of acceptablePrivilegePolicy Extension: that is, its</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=025272920-13032002>a 
relying party </SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
class=025272920-13032002>matter to select the policies to be 
applied?</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=025272920-13032002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=025272920-13032002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=025272920-13032002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=025272920-13032002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=025272920-13032002></SPAN></FONT>&nbsp;</DIV></BODY></HTML>

--Boundary_(ID_JMqEt03LiC3dil9v29hn7A)--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2DJUIK17922 for ietf-pkix-bks; Wed, 13 Mar 2002 11:30:18 -0800 (PST)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2DJU9417906 for <[e-mail]>; Wed, 13 Mar 2002 11:30:17 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 13 Mar 2002 11:28:59 -0800 (PST)
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, 13 Mar 2002 11:28:59 -0800 (PST)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <GK1PQG94>; Wed, 13 Mar 2002 11:29:52 -0800
Content-return: allowed
Date: Wed, 13 Mar 2002 11:29:51 -0800
From: Peter Williams <[e-mail]>
Subject: RE: Privilege policy (was Re: I-D ACTION:draft-ietf-pkix-acrmf-01	.txt)
To: "'Steve Hanna'" <[e-mail]>
Cc: "'Yee, Peter'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I suspect that the only confusion that is relevant is summarized
in the following question and commentary:

(Q) Does one perform the tests laid down by the privilege 
policies(s) *during* AC path processing, or not?

if an AC is "valid" this implies that the relevant
privilege assertions DID INDEED MEET the rules of the relevant privilege 
policy(s). The last implication is another way of asking the 
question (Q), in functional  form. The function is always true 
for a true antededent if path processing for a valid chain itself 
evaluates (validly asserted) privileges against their 
privilege policies and environment values.

(Obviously Roberto's simple example of signing limit enforcement via
PMI is just a case of a privilege assertion  and corresponding
sufficiency determination  where the transacations signing-amount (the 
environment var value) would be judged against the privilege policy 
of the bank/payment-card (which presumably says, the AC-privilege 
assertion is invalid if signing amount > signing limit. Obviously thge
policy could be more complex, and track cumulative limits, with
greater use of env vars.

To PKIX and ACPROF:

This issue of where privilege policy is enforced affects the design of 
a certified AC path processing module, or a DPV server addressing AC 
path evaluation. For this issue, it makes no difference under 
X.509 conformance whether the path has one or more 
elements. Let us assume one element:

(1) If privilege asssertion sufficiency tests are performed *during* 
path validation, then
the privilege policy(s) and enviornment vars must
be passed TO the module/server FROM the client, where
the client normally collected the privilege policies from
the bank's directory; and where environment var values are 
obivously established (obviously)

(2) If the path processing module only performs trivial authentication
of AC chains re PKI, but does not enforce the privilege policies,
then one assumes that the client of the AC path processing
module/server enforces the privilege policys. In this case, a path 
processing RESULT from the module/server of valid DOES NOT satisfy
X.509 16.1; the Path is only "partially evaluated" at
that point.

X.509 16: "The role processing procedure and delegation processing procedure

are done prior to the determination of whether or not the asserted
privileges 
are sufficient for the context of use within the basic procedure." suggests
(to me very clearly, but inevitably not clearly to Denis) along with the 
context that  "AC path processing itself" must determine whether or not 
the asserted privileges are sufificent for the context of us. That is, if a 
DPV server is faced with path processing an AC, it must perform perform the
determination of sufficiency.

Both ACPROF and DPV requirements I-Ds are critically insufficient on
this issue, is  my comment to IETF. The fix is to align both
with X.509 PMI 16.1, basic processing of ACs, as REQUIRED
for X.509 conformance.

-----Original Message-----
From: Steve Hanna [mailto:[e-mail]]
Sent: Tuesday, March 12, 2002 7:10 AM
To: Peter Williams
Cc: 'Yee, Peter'; '[e-mail]'; '[e-mail]'
Subject: Re: Privilege policy (was Re: I-D
ACTION:draft-ietf-pkix-acrmf-01.txt)


There seems to be some ongoing confusion about privilege
policy, as defined in X.509. Privilege policy determines
whether the privileges of a privilege holder are sufficient.
An access control list is one example of a privilege policy.

Although ACPROF does not mention privilege policy, I believe
that there's an unstated assumption that after an AC has
been validated it may be used in access control decisions
or for other purposes. It is at this point that privilege
policy enters the picture.

The only place in X.509 AC validation where privilege policy
is involved in is where the acceptable privilege policies
extension is present. In that case, the verifier must
check that the OID for the privilege policy it's planning
to use is included in the list of OIDs in the extension.
However, ACPROF does not support this extension. Therefore,
there is no need for it to worry about privilege policy.

-Steve

Peter Williams wrote:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-ac509prof-09.txt
> 
> describes a set of AC verification rules, when an AC chain
> has one element.
> 
> X.509 16.1 defines the "basic path processing" requirements
> for processing "a single AC". X.509 16 is clear that 16.1
> is REQUIRED for the case of processing a single AC.
> 
> Peter, a question (Q): What is the relationship between
> "privilege policy" (as used in X.509 16.1) and ACPROF section
> 5 "Attribute Certificate validation?"
> 
> I dont believe profiles can remove the X.509 requirement
> to follow X.509 16.1 when validating an AC. As ACPROF makes no
> mention of privilege policy, we have to assume that
> X.509 16.1 controls, and that conforming implementations
> MUST implement the privilege policy enforcement
> requirements.
> 
> A reasonable answer to the question (Q) is that
> "validating right-to-use" a privilege is not the same
> thing as "validating an AC" - even though these two ideas
> are intertwined in the international standard, section 16.1.
> Hence, privilege policy matters fall outside the scope of ACPROF
> and IETF.
> 
> If this latter case is your thinking, then of course
> designers of conforming implementations must
> look to X509 for control when validating actual
> privilege *assertion* at privilege "use" time.
> 
> If we could clearup that ACPROF does not control
> validation of privilege *assertion*, this would
> be valuable. Privlege assertion within a lifetime
> is of course what matters and what makes ACs
> viable. Validating the privilege assertion
> can of course be critically important to
> the application's security policy.
> 
> Peter.
> 
> -----Original Message-----
> From: Yee, Peter [mailto:[e-mail]]
> Sent: Monday, March 11, 2002 2:23 PM
> To: '[e-mail]'
> Cc: '[e-mail]'
> Subject: RE: I-D ACTION:draft-ietf-pkix-acrmf-01.txt
> 
> >I recognize that [ACPROF], the Internet Attribute Certificate Profile,
does
> >not currently recommend the use of delegation and AC chains as specified
in
> >the X.509 standard [X.509-2000], however I would hope that your Internet
> >Draft [ACRMF] on Attribute Certificate Request Message Format will not
> >preclude it.
> 
> Yes, I would call that an oversight on my part.  I have to admit that
> sometimes I think of ACs within the limited scope of ACPROF.
>


Received: by above.proper.com (8.11.6/8.11.3) id g2DEDsb00746 for ietf-pkix-bks; Wed, 13 Mar 2002 06:13:54 -0800 (PST)
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 g2DEDq400740 for <[e-mail]>; Wed, 13 Mar 2002 06:13:53 -0800 (PST)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.12.2/8.12.2) with ESMTP id g2DEDllp023601 for <[e-mail]>; Wed, 13 Mar 2002 09:13:48 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 13 Mar 2002 09:12:23 -0500
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: Agenda for 53rd IETF
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>

Folks,

For those who will be in Minneapolis, I have appended our agenda to this 
message.  As usual, we have a full agenda.  *If* we run on time, we will 
run five minutes over... I forgot to allot five minutes to myself for 
document status.

As a result, I hope to start our session promptly at 1:00 on Wednesday.  I 
figured that deserved a warning message to the list!  I look forward to 
seeing you all there.

Thanks,

Tim Polk

----------------- PKIX WG agenda, 53rd IETF ----------------------

PKIX WG (pkix-wg)

WEDNESDAY, March 20 at 1300-1500
=================================

CHAIR: Stephen Kent <[e-mail]>, Tim Polk <[e-mail]>

AGENDA:

I. Document Status Review (5 min.)              Tim Polk (NIST)

II. DPD/DPV Requirements and Protocol

	a. DPV Requirements Status (10 min.)    Denis Pinkas (Bull)	

	b. SCVP (20 min.)                       Ambarish Malpani (ValiCert)

III. OCSP update (5 Min.)                       Ambarish Malpani (ValiCert)	

IV. New Specifications

	a. ACRMF and ACMC (15 min.)             Peter Yee (RSA)

	b. OCKID (10 min.)                      Paul Hoffman (IMC/VPNC)

c. Policy requirements for TSAs (5 min.)        Denis Pinkas (Bull)		
	
V. Ongoing Specifications

	a. TSP interoperability testing update  Denis Pinkas (Bull)
	and anticipated to TSP (10 min.)	

	b. Permanent Identifiers (10 min.)      Denis Pinkas (Bull)	

	c. Proxy Certificates (10 min.)         Steve Tuecke (ANL)

	d. Logotypes (5 min.)                   Stefan Santesson (AddTrust)

VI. Personal drafts

	a. DNS as X.509 PKIX Certificate        Jakob Schlyter (Carlstedt R&T)
	Storage (10 min.)		

	b. An LDAPv3 Schema for X.509           Peter Gietz (DAASI)
	Certificates (10 min.)		





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2CIi9H19037 for ietf-pkix-bks; Tue, 12 Mar 2002 10:44:09 -0800 (PST)
Received: from emerald.lightlink.com (emerald.lightlink.com [205.232.34.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2CIi8419033 for <[e-mail]>; Tue, 12 Mar 2002 10:44:08 -0800 (PST)
Received: from [209.216.70.29] (perm70-29.ij.net [209.216.70.29] (may be forged)) by emerald.lightlink.com (8.8.8/8.8.8) with SMTP id NAA13605; Tue, 12 Mar 2002 13:44:02 -0500
From: "Christopher S. Francis" <[e-mail]>
To: "Sharon Boeyen" <[e-mail]>, "Ietf-Pkix" <[e-mail]>
Cc: "500 list \(E-mail\)" <[e-mail]>
Received: from no.name.available by [209.216.70.29] via smtpd (for smtp.lightlink.com [205.232.34.14]) with SMTP; 12 Mar 2002 18:51:32 UT
Subject: RE: Attribute Certificate Policy??
Date: Tue, 12 Mar 2002 13:44:02 -0500
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E7_01C1C9CB.F8228340"
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 V6.00.2600.0000
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>

This is a multi-part message in MIME format.

------=_NextPart_000_00E7_01C1C9CB.F8228340
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thank you Sharon.  I was hoping you=92d weigh in on this.
=20
=85snip
Unlike PKI, the "authority" to issue the attribute certificate in the =
first place,=20
was viewed as the primary factor in determining whether or not to accept =
an asserted=20
privilege. As such the ability to identify and validate this authority =
was the=20
direction the PMI work took, rather than to assess the policies of an =
issuer to=20
determine if an AC came from an 'acceptable issuer'. SOA identification =
and the=20
delegation path process, and associated AC extensions) are the mechanism =
for doing that.=20
=85end snip
What concerns me about this approach is that it seems plausible that the =
AAs themselves may want to put something in the certificate that clearly =
and unambiguously links the certificate to a policy document that =
identifies things like usage constraints and liability limits associated =
with the assertion of whatever privilege is being granted.  This is =
especially true if an AA issues ACs under more than one policy =85.. say =
for example with varying degrees of liability, depending on the =
applicable practices and procedures.
In any case, if I understand you correctly it seems that the =
acceptablePrivilegePolicies extension would be an appropriate place for =
the AA to impose constraints such as those referenced above.  I=92m not =
a lawyer, so I=92m not even sure it=92s necessary from a legal stand =
point, but I hope to get some more insight into that aspect shortly.
Chris
>From my own personal (non editor) viewpoint:=20
In terms of the two policy types David identified in his email, the 509 =
PMI attempts=20
to deal with the former (which allows AAs to impose constraints on the =
use of=20
ACs issued) through specific extensions in ACs (e.g. acceptable =
privilege=20
policies, target information, time specification etc) and with the =
latter (which=20
allows target side constraints to be imposed on the set of ACs that can =
be used for=20
a given application/transaction) through privilege policy. 509 does =
include=20
hooks for linking privilege policy to the use of att certs and does =
provide means=20
for storing them in directories but does not standardize a syntax for =
these=20
(two sample syntaxes are partially documented in an informative annex, =
but=20
nothing is standardized).=20
I agree with Steve Farrell that it is premature to add anything along =
the lines=20
of certificatePolicies extension to attribute certificates and I =
personally don't see=20
this as a requirement for the PMI model, at least not as currently =
defined in 509.=20
Cheers,=20
Sharon=20
=20
-----Original Message-----=20
From: David Chadwick [ mailto:[e-mail]]=20
Sent: Thursday, March 07, 2002 5:19 PM=20
To: [e-mail]=20
Cc: Christopher S. Francis; Housley, Russ; Ietf-Pkix=20
Subject: Re: Attribute Certificate Policy??=20
=20
Hi All=20
Having implemented a policy based attribute certificate infrastructure=20
(see www.permis.org and sec.isi.salford.ac.uk/permis for more details) I =

have a few comments to make to this thread.=20
Firstly, there can be a requirement to limit the use of ACs to specific=20
authorisation policies. In our implementation, each authorisation=20
policy, or access decision policy (cf ISO 10181-3) is given a unique=20
OID.=20
Secondly, we currently dont have an AC extension to put policy OIDs in,=20
since the policy extension is only meant to be used with PK certs and=20
not AC certs. So you would need to update X.509 if you are talking about =

putting policy extensions in ACs=20
Thirdly, there are two policies that are potentially of interest for=20
ACs. So maybe two policy extensions are needed. The first is the policy=20
of the AA that issued the AC (what the AC should be used for), and the=20
second is the authorisation policy controlling the target that is=20
accepting ACs as credentials/permissions for the access (which ACs the=20
target can accept). In PERMIS we are only concerned about the latter,=20
whereas I think the PKIX thread is more concerned about the former. But=20
consider this. University degrees, Microsoft Certified Engineer, ISO=20
9000 certified, Visa cards etc. can all be issued electronically as ACs, =

signed by the issuing institution. The holder can present these=20
privilege ACs to any electronic target in order to try to gain access.=20
So typically an issuer does not try to limit the targets at which the=20
ACs are deemed to be valid and useful privileges. (A university does not =

say where its degrees can be used.) It is the target administrator that=20
decides which ACs it will trust and this is built into its target access =

decision policy (will Org X accept degrees from Univ Y). Clearly a=20
target (administrator) may wish to consult the issuing policy, if one=20
exists, before trusting particular AAs, and so a pointer to this in each =

AC could be useful (e.g Visa might place restrictions on which targets=20
can use its electronic credit cards). Parts of the issuing policy are=20
already in the AC for example, whether delegation is allowed or not. If=20
the issuer does try to limit the target policies that are applicable to=20
an AC, it will need to know about the target policies before issuing the =

certificates, which might typically be difficult to achieve.=20
My suggestion would be to steer clear of the existing policies=20
extension, which is defined for use with PKCerts, and to define new AC=20
extensions if ones are needed (they can clearly have the same syntax as=20
the existing policy extension, but give them new extension OIDs). This=20
more or less agrees with Stephen's email below=20
David=20
=20
Stephen Farrell wrote:=20
>=20
> Chris,=20
>=20
> I'd be against the idea of proposing this as an update to the AC =
profile=20
> for the following reasons:=20
>=20
> - The profile is in the rfc editor's queue only awaiting son-of-2359 =
to=20
>   be processed and such an update would require a re-set back to WG =
last=20
>   call (a matter of months!)=20
> - I don't believe that the use of policy OIDs in ACs is at all well=20
>   understood and therefore I'd argue to omit it from the profile (one=20
>   of the things we tried to do with the AC profile was to only include =

>   suff that we were pretty sure could work)=20
> - There may be entirely different policy considerations to address,=20
>   depending on the context for the use of ACs (e.g. supporting roles =
for=20
>   long-term signatures vs roles for access control).=20
>=20
> So, while I'd welcome work starting on this - for both process and=20
> technical reasons I believe the way to handle it is to write things up =
in=20
> a separate I-D. At some point in the future (say if the AC profile =
were=20
> being cycled at proposed standard), the two things could be merged if=20
> appropriate.=20
>=20
> Regards,=20
> Stephen.=20
>=20
> "Christopher S. Francis" wrote:=20
> >=20
> > Sure.  I can pursue it.  Since I don't spend a lot of time here, I'm =
not=20
> > exactly sure what the appropriate process is, but what I have in =
mind is to=20
> > do the following:=20
> >=20
> > 1) Get some clarification from ANSI and whoever else has an opinion =
on=20
> > whether X.509 offers an extension that is intended to be used to =
carry=20
> > certificate policy information in attribute certificates.  Perhaps=20
> > certificatePolicies, perhaps acceptablePrivilegePolicies, perhaps =
they had=20
> > something else in mind.=20
> > 2) Depending on what I find out, propose an update to the PKIX =
attribute=20
> > certificate profile that includes an extension to ACs to hold policy =

> > information about the issuing authority.=20
> >=20
> > Based on your earlier responses, I understand that a =
certificatePolicies=20
> > extension could be included in an AC as long as it is marked =
non-critical,=20
> > but it that's only because *anything* can be included as an =
extension if=20
> > it's marked non-critical.  It seems to me there should be something =
specific=20
> > in the profile to address the issue of certificate policy.=20
> >=20
> > Chris=20
> > -----Original Message-----=20
> > From: [e-mail] [ =
mailto:[e-mail]]On=20
> > Behalf Of Housley, Russ=20
> > Sent: Wednesday, March 06, 2002 11:02 AM=20
> > To: Christopher S. Francis=20
> > Cc: Ietf-Pkix=20
> > Subject: Re: Attribute Certificate Policy??=20
> >=20
> > Chris:=20
> >=20
> > I am not aware of any work in this area.  You can take the lead.=20
> >=20
> > Russ=20
> >=20
> > At 05:41 PM 3/5/2002 -0500, Christopher S. Francis wrote:=20
> >=20
> > >Is there a defined mechanism to specify something analogous to a=20
> > >certificate policy in an attribute certificate?=20
> > >=20
> > >=20
> > >=20
> > >In reviewing the PKIX AC profile, I see that the syntax of the =
attributes=20
> > >field is defined by the AttributeType OID, but rather than syntax =
per se,=20
> > >I m looking for a way to specify the particular set of policies,=20
> > >practices, and procedures that the attribute authority was =
operating under=20
> > >when it issued the attribute certificate.  Seems like this would be =

> > >important to relying parties.=20
> > >=20
> > >=20
> > >=20
> > >X.509 includes an acceptablePrivilegePolicies extension that seems =
like it=20
> > >might to the job, but it was apparently profiled out by PKIX.=20
> > >=20
> > >=20
> > >=20
> > >Chris Francis=20
> > >=20
> > >=20
> > >=20
> > >=20
>=20
> --=20
> ____________________________________________________________=20
> Stephen Farrell=20
> Baltimore Technologies,   tel: (direct line) [phone]=20
> 39 Parkgate Street,                     fax: [phone]=20
> Dublin 8.                mailto:[e-mail]=20
> Ireland                             http://www.baltimore.com=20
--=20
*****************************************************************=20
David W. Chadwick, BSc PhD=20
Professor of Information Systems Security=20
IS Institute, University of Salford, Salford M5 4WT=20
Tel: [phone]  Fax [phone]=20
Mobile: [phone]=20
Email: [e-mail]=20
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm=20
Research Projects: http://sec.isi.salford.ac.uk=20
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm=20
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm=20
Entrust key validation string: MLJ9-DU5T-HV8J=20
PGP Key ID is 0xBC238DE5=20
*****************************************************************=20

------=_NextPart_000_00E7_01C1C9CB.F8228340
Content-Type: text/html;
	charset="iso-8859-1"
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=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 9">
<meta name=3DOriginator content=3D"Microsoft Word 9">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C1C9CB.F668EC60">
<title>RE: Attribute Certificate Policy??</title>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
@font-face
	{font-family:"Comic Sans MS";
	panose-1:3 15 7 2 3 3 2 2 2 4;
	mso-font-charset:0;
	mso-generic-font-family:script;
	mso-font-pitch:variable;
	mso-font-signature:647 0 0 0 159 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:"Times New Roman";}
h1
	{mso-style-next:Normal;
	margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:1;
	font-size:16.0pt;
	font-family:Arial;
	mso-font-kerning:16.0pt;
	font-weight:bold;}
p.MsoBodyText, li.MsoBodyText, div.MsoBodyText
	{margin-top:13.2pt;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:1.0in;
	margin-bottom:.0001pt;
	line-height:120%;
	mso-pagination:widow-orphan;
	font-size:11.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-font-kerning:11.0pt;}
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.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p
	{margin-right:0in;
	mso-margin-top-alt:auto;
	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:"Times New Roman";}
p.Heading1NoTOC, li.Heading1NoTOC, div.Heading1NoTOC
	{mso-style-name:"Heading 1 No TOC";
	mso-style-parent:"Heading 1";
	margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	text-align:center;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:1;
	font-size:14.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	mso-font-kerning:14.0pt;
	font-weight:bold;
	mso-bidi-font-weight:normal;}
p.TableText, li.TableText, div.TableText
	{mso-style-name:"Table Text";
	margin-top:3.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	line-height:110%;
	mso-pagination:widow-orphan lines-together;
	font-size:10.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-font-kerning:10.0pt;}
p.TableTextTitle, li.TableTextTitle, div.TableTextTitle
	{mso-style-name:"Table Text Title";
	mso-style-parent:"Table Text";
	margin-top:3.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	line-height:110%;
	mso-pagination:widow-orphan lines-together;
	font-size:10.0pt;
	font-family:Arial;
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	mso-font-kerning:10.0pt;
	font-weight:bold;
	mso-bidi-font-weight:normal;}
span.EmailStyle22
	{mso-style-type:personal-reply;
	mso-ansi-font-size:12.0pt;
	mso-ascii-font-family:"Comic Sans MS";
	mso-hansi-font-family:"Comic Sans MS";
	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>
</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><span class=3DEmailStyle22><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>Thank
you Sharon.<span style=3D"mso-spacerun: yes">&nbsp; </span>I was hoping =
you&#8217;d
weigh in on this.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle22><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle22><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans =
MS"'>&#8230;snip<o:p></o:p></span></font></span></p>

<p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack face=3D"Times =
New Roman"><span
style=3D'font-size:10.0pt;color:black'>Unlike PKI, the =
&quot;authority&quot; to
issue the attribute certificate in the first place, </span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>was viewed as the primary factor in determining whether or =
not to
accept an asserted </span></font><font color=3Dblack><span =
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>privilege. As such the ability to identify and validate =
this
authority was the </span></font><font color=3Dblack><span =
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>direction the PMI work took, rather than to assess the =
policies of
an issuer to </span></font><font color=3Dblack><span =
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>determine if an AC came from an 'acceptable issuer'. SOA
identification and the </span></font><font color=3Dblack><span =
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>delegation path process, and associated AC extensions) are =
the
mechanism for doing that.</span></font><font color=3Dblack><span
style=3D'color:black'> </span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p><span class=3DEmailStyle22><font size=3D3 color=3Dnavy face=3D"Comic =
Sans MS"><span
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>&#8230;end =
snip<o:p></o:p></span></font></span></p>

<p><span class=3DEmailStyle22><font size=3D3 color=3Dnavy face=3D"Comic =
Sans MS"><span
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>What concerns me =
about
this approach is that it seems plausible that the AAs themselves may =
want to
put something in the certificate that clearly and unambiguously links =
the
certificate to a policy document that identifies things like usage =
constraints
and liability limits associated with the assertion of whatever privilege =
is being
granted.<span style=3D"mso-spacerun: yes">&nbsp; </span>This is =
especially true
if an AA issues ACs under more than one policy &#8230;.. say for example =
with varying
degrees of liability, depending on the applicable practices and =
procedures.<o:p></o:p></span></font></span></p>

<p><span class=3DEmailStyle22><font size=3D3 color=3Dnavy face=3D"Comic =
Sans MS"><span
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>In any case, if I
understand you correctly it seems that the acceptablePrivilegePolicies
extension would be an appropriate place for the AA to impose constraints =
such
as those referenced above.<span style=3D"mso-spacerun: yes">&nbsp; =
</span>I&#8217;m not
a lawyer, so I&#8217;m not even sure it&#8217;s necessary from a legal =
stand point, but I
hope to get some more insight into that aspect =
shortly.<o:p></o:p></span></font></span></p>

<p><span class=3DEmailStyle22><font size=3D3 color=3Dnavy face=3D"Comic =
Sans MS"><span
style=3D'font-size:12.0pt;font-family:"Comic Sans =
MS"'>Chris<o:p></o:p></span></font></span></p>

<p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack face=3D"Times =
New Roman"><span
style=3D'font-size:10.0pt;color:black'>From my own personal (non editor)
viewpoint:</span></font><font color=3Dblack><span style=3D'color:black'> =
</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack face=3D"Times =
New Roman"><span
style=3D'font-size:10.0pt;color:black'>In terms of the two policy types =
David
identified in his email, the 509 PMI attempts</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>to deal with the former (which allows AAs to impose =
constraints on
the use of </span></font><font color=3Dblack><span =
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>ACs issued) through specific extensions in ACs (e.g. =
acceptable
privilege</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>policies, target information, time specification etc) and =
with the
latter (which </span></font><font color=3Dblack><span =
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>allows target side constraints to be imposed on the set of =
ACs
that can be used for </span></font><font color=3Dblack><span =
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>a given application/transaction) through privilege policy. =
509
does include </span></font><font color=3Dblack><span =
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>hooks for linking privilege policy to the use of att certs =
and
does provide means </span></font><font color=3Dblack><span =
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>for storing them in directories but does not standardize a =
syntax
for these </span></font><font color=3Dblack><span =
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>(two sample syntaxes are partially documented in an =
informative
annex, but </span></font><font color=3Dblack><span =
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>nothing is standardized). </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack face=3D"Times =
New Roman"><span
style=3D'font-size:10.0pt;color:black'>I agree with Steve Farrell that =
it is
premature to add anything along the lines </span></font><font =
color=3Dblack><span
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>of certificatePolicies extension to attribute certificates =
and I
personally don't see</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>this as a requirement for the PMI model, at least not as =
currently
defined in 509.</span></font><font color=3Dblack><span =
style=3D'color:black'> </span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

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

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack face=3D"Times =
New Roman"><span
style=3D'font-size:10.0pt;color:black'>-----Original =
Message-----</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>From: David Chadwick [<a =
href=3D"mailto:[e-mail]">mailto:[e-mail]=
.uk</a>]</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Sent: Thursday, March 07, 2002 5:19 PM</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>To: [e-mail]</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Cc: Christopher S. Francis; Housley, Russ; =
Ietf-Pkix</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Subject: Re: Attribute Certificate =
Policy??</span></font><font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack face=3D"Times =
New Roman"><span
style=3D'font-size:10.0pt;color:black'>Hi All</span></font><font =
color=3Dblack><span
style=3D'color:black'> </span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack face=3D"Times =
New Roman"><span
style=3D'font-size:10.0pt;color:black'>Having implemented a policy based
attribute certificate infrastructure</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>(see www.permis.org and sec.isi.salford.ac.uk/permis for =
more
details) I</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>have a few comments to make to this =
thread.</span></font><font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack face=3D"Times =
New Roman"><span
style=3D'font-size:10.0pt;color:black'>Firstly, there can be a =
requirement to
limit the use of ACs to specific</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>authorisation policies. In our implementation, each =
authorisation</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>policy, or access decision policy (cf ISO 10181-3) is given =
a
unique</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>OID. </span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack face=3D"Times =
New Roman"><span
style=3D'font-size:10.0pt;color:black'>Secondly, we currently dont have =
an AC
extension to put policy OIDs in,</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>since the policy extension is only meant to be used with PK =
certs
and</span></font><font color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>not AC certs. So you would need to update X.509 if you are =
talking
about</span></font><font color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>putting policy extensions in ACs</span></font><font =
color=3Dblack><span
style=3D'color:black'> </span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack face=3D"Times =
New Roman"><span
style=3D'font-size:10.0pt;color:black'>Thirdly, there are two policies =
that are
potentially of interest for</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>ACs. So maybe two policy extensions are needed. The first =
is the
policy</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>of the AA that issued the AC (what the AC should be used =
for), and
the</span></font><font color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>second is the authorisation policy controlling the target =
that is</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>accepting ACs as credentials/permissions for the access =
(which ACs
the</span></font><font color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>target can accept). In PERMIS we are only concerned about =
the
latter,</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>whereas I think the PKIX thread is more concerned about the
former. But</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>consider this. University degrees, Microsoft Certified =
Engineer,
ISO</span></font><font color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>9000 certified, Visa cards etc. can all be issued =
electronically
as ACs,</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>signed by the issuing institution. The holder can present =
these</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>privilege ACs to any electronic target in order to try to =
gain
access.</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>So typically an issuer does not try to limit the targets at =
which
the</span></font><font color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>ACs are deemed to be valid and useful privileges. (A =
university
does not</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>say where its degrees can be used.) It is the target =
administrator
that</span></font><font color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>decides which ACs it will trust and this is built into its =
target
access</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>decision policy (will Org X accept degrees from Univ Y). =
Clearly a</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>target (administrator) may wish to consult the issuing =
policy, if
one</span></font><font color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>exists, before trusting particular AAs, and so a pointer to =
this
in each</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>AC could be useful (e.g Visa might place restrictions on =
which
targets</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>can use its electronic credit cards). Parts of the issuing =
policy
are</span></font><font color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>already in the AC for example, whether delegation is =
allowed or
not. If</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>the issuer does try to limit the target policies that are
applicable to</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>an AC, it will need to know about the target policies =
before
issuing the</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>certificates, which might typically be difficult to =
achieve.</span></font><font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack face=3D"Times =
New Roman"><span
style=3D'font-size:10.0pt;color:black'>My suggestion would be to steer =
clear of
the existing policies</span></font><font color=3Dblack><span =
style=3D'color:black'>
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>extension, which is defined for use with PKCerts, and to =
define
new AC</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>extensions if ones are needed (they can clearly have the =
same
syntax as</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>the existing policy extension, but give them new extension =
OIDs).
This</span></font><font color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>more or less agrees with Stephen's email =
below</span></font><font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack face=3D"Times =
New Roman"><span
style=3D'font-size:10.0pt;color:black'>David</span></font><font =
color=3Dblack><span
style=3D'color:black'> </span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack face=3D"Times =
New Roman"><span
style=3D'font-size:10.0pt;color:black'>Stephen Farrell =
wrote:</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; </span></font><font color=3Dblack><span =
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; Chris,</span></font><font color=3Dblack><span =
style=3D'color:
black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; </span></font><font color=3Dblack><span =
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; I'd be against the idea of proposing this as an update =
to the
AC profile</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; for the following reasons:</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; </span></font><font color=3Dblack><span =
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; - The profile is in the rfc editor's queue only =
awaiting
son-of-2359 to</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt;&nbsp;&nbsp; be processed and such an update would =
require a
re-set back to WG last</span></font><font color=3Dblack><span =
style=3D'color:black'>
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt;&nbsp;&nbsp; call (a matter of =
months!)</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; - I don't believe that the use of policy OIDs in ACs =
is at
all well</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt;&nbsp;&nbsp; understood and therefore I'd argue to omit =
it
from the profile (one</span></font><font color=3Dblack><span =
style=3D'color:black'>
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt;&nbsp;&nbsp; of the things we tried to do with the AC =
profile
was to only include</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt;&nbsp;&nbsp; suff that we were pretty sure could =
work)</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; - There may be entirely different policy =
considerations to
address,</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt;&nbsp;&nbsp; depending on the context for the use of =
ACs (e.g.
supporting roles for</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt;&nbsp;&nbsp; long-term signatures vs roles for access
control).</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; </span></font><font color=3Dblack><span =
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; So, while I'd welcome work starting on this - for both
process and</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; technical reasons I believe the way to handle it is to =
write
things up in</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; a separate I-D. At some point in the future (say if =
the AC
profile were</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; being cycled at proposed standard), the two things =
could be
merged if</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; appropriate.</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; </span></font><font color=3Dblack><span =
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; Regards,</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; Stephen.</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; </span></font><font color=3Dblack><span =
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &quot;Christopher S. Francis&quot; =
wrote:</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt;</span></font><font color=3Dblack><span =
style=3D'color:black'>
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; Sure.&nbsp; I can pursue it.&nbsp; Since I don't =
spend a
lot of time here, I'm not</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; exactly sure what the appropriate process is, but =
what I
have in mind is to</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; do the following:</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt;</span></font><font color=3Dblack><span =
style=3D'color:black'>
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; 1) Get some clarification from ANSI and whoever =
else has
an opinion on</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; whether X.509 offers an extension that is =
intended to be
used to carry</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; certificate policy information in attribute =
certificates.&nbsp;
Perhaps</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; certificatePolicies, perhaps
acceptablePrivilegePolicies, perhaps they had</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; something else in mind.</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; 2) Depending on what I find out, propose an =
update to
the PKIX attribute</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; certificate profile that includes an extension to =
ACs to
hold policy</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; information about the issuing =
authority.</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt;</span></font><font color=3Dblack><span =
style=3D'color:black'>
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; Based on your earlier responses, I understand =
that a
certificatePolicies</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; extension could be included in an AC as long as =
it is
marked non-critical,</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; but it that's only because *anything* can be =
included as
an extension if</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; it's marked non-critical.&nbsp; It seems to me =
there
should be something specific</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; in the profile to address the issue of =
certificate
policy.</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt;</span></font><font color=3Dblack><span =
style=3D'color:black'>
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; Chris</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; -----Original Message-----</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; From: [e-mail] [<a
href=3D"mailto:[e-mail]">mailto:owner-ietf-pkix@mail.=
imc.org</a>]On</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; Behalf Of Housley, Russ</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; Sent: Wednesday, March 06, 2002 11:02 =
AM</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; To: Christopher S. Francis</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; Cc: Ietf-Pkix</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; Subject: Re: Attribute Certificate =
Policy??</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt;</span></font><font color=3Dblack><span =
style=3D'color:black'>
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; Chris:</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt;</span></font><font color=3Dblack><span =
style=3D'color:black'>
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; I am not aware of any work in this area.&nbsp; =
You can
take the lead.</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt;</span></font><font color=3Dblack><span =
style=3D'color:black'>
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; Russ</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt;</span></font><font color=3Dblack><span =
style=3D'color:black'>
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; At 05:41 PM 3/5/2002 -0500, Christopher S. =
Francis
wrote:</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt;</span></font><font color=3Dblack><span =
style=3D'color:black'>
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; &gt;Is there a defined mechanism to specify =
something
analogous to a</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; &gt;certificate policy in an attribute =
certificate?</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; &gt;</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; &gt;</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; &gt;</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; &gt;In reviewing the PKIX AC profile, I see that =
the
syntax of the attributes</span></font><font color=3Dblack><span =
style=3D'color:
black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; &gt;field is defined by the AttributeType OID, =
but
rather than syntax per se,</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; &gt;I m looking for a way to specify the =
particular set
of policies,</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; &gt;practices, and procedures that the attribute
authority was operating under</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; &gt;when it issued the attribute =
certificate.&nbsp;
Seems like this would be</span></font><font color=3Dblack><span =
style=3D'color:
black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; &gt;important to relying =
parties.</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; &gt;</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; &gt;</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; &gt;</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; &gt;X.509 includes an acceptablePrivilegePolicies
extension that seems like it</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; &gt;might to the job, but it was apparently =
profiled out
by PKIX.</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; &gt;</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; &gt;</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; &gt;</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; &gt;Chris Francis</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; &gt;</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; &gt;</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; &gt;</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; &gt; &gt;</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; </span></font><font color=3Dblack><span =
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; --</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; =
____________________________________________________________</span></font=
><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; Stephen Farrell</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; Baltimore Technologies,&nbsp;&nbsp; tel: (direct line) =
+353 1
881 6716</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; 39 Parkgate
Street,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
fax: [phone]</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt; Dublin
8.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;
<a =
href=3D"mailto:[e-mail]">mailto:stephen.farrell@balti=
more.ie</a></span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&gt;
Ireland&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href=3D"http://www.baltimore.com" =
target=3D"_blank">http://www.baltimore.com</a></span></font><font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack face=3D"Times =
New Roman"><span
style=3D'font-size:10.0pt;color:black'>-- </span></font><font =
color=3Dblack><span
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>************************************************************=
*****</span></font><font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack face=3D"Times =
New Roman"><span
style=3D'font-size:10.0pt;color:black'>David W. Chadwick, BSc =
PhD</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Professor of Information Systems =
Security</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>IS Institute, University of Salford, Salford M5 =
4WT</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Tel: [phone]&nbsp; Fax [phone] =
8169</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Mobile: [phone]</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Email: [e-mail]</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Home Page:&nbsp; <a
href=3D"http://www.salford.ac.uk/its024/chadwick.htm" =
target=3D"_blank">http://www.salford.ac.uk/its024/chadwick.htm</a></span>=
</font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Research Projects: <a href=3D"http://sec.isi.salford.ac.uk"
target=3D"_blank">http://sec.isi.salford.ac.uk</a></span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Understanding X.500:&nbsp; <a
href=3D"http://www.salford.ac.uk/its024/X500.htm" =
target=3D"_blank">http://www.salford.ac.uk/its024/X500.htm</a></span></fo=
nt><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>X.500/LDAP Seminars: <a
href=3D"http://www.salford.ac.uk/its024/seminars.htm" =
target=3D"_blank">http://www.salford.ac.uk/its024/seminars.htm</a></span>=
</font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Entrust key validation string: =
MLJ9-DU5T-HV8J</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>PGP Key ID is 0xBC238DE5</span></font><font =
color=3Dblack><span
style=3D'color:black'> </span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack face=3D"Times =
New Roman"><span
style=3D'font-size:10.0pt;color:black'>**********************************=
*******************************</span></font><font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

</div>

</body>

</html>

------=_NextPart_000_00E7_01C1C9CB.F8228340--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2CHpKZ16539 for ietf-pkix-bks; Tue, 12 Mar 2002 09:51:20 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2CHpI416533 for <[e-mail]>; Tue, 12 Mar 2002 09:51:18 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA19149 for <[e-mail]>; Tue, 12 Mar 2002 18:51:18 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 12 Mar 2002 18:51:18 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id SAA21036 for <[e-mail]>; Tue, 12 Mar 2002 18:51:17 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA25122 for [e-mail]; Tue, 12 Mar 2002 18:51:17 +0100 (MET)
Date: Tue, 12 Mar 2002 18:51:17 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RFC 3029 update
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

several people has informed the authors of RFC 3029 that
the document contains some errors in the ASN.1 definitions. 

Indeed, some nice bugs have not been caught even in pilot
implementations. 

in order to avoid that other implementors hit the
same problems, here a summary :

Current text has:

     PathProcInput ::= SEQUENCE {
        acceptablePolicySet          SEQUENCE SIZE (1..MAX) OF
                                        PolicyInformation,
        inhibitPolicyMapping         BOOLEAN DEFAULT FALSE,
        explicitPolicyReqd           BOOLEAN DEFAULT FALSE }

This should be:

     PathProcInput ::= SEQUENCE {
        acceptablePolicySet          SEQUENCE SIZE (1..MAX) OF
                                        PolicyInformation,
        inhibitPolicyMapping         BOOLEAN DEFAULT FALSE,
        explicitPolicyReqd           [0] BOOLEAN DEFAULT FALSE ,    
        inhibitAnyPolicy             [1] BOOLEAN DEFAULT FALSE }

Current text has: 

   Data ::= CHOICE {
         message           OCTET STRING ,
         messageImprint    DigestInfo,
         certs             SEQUENCE SIZE (1..MAX) OF
                               TargetEtcChain
   }

This should be:

   Data ::= CHOICE {
         message           OCTET STRING ,
         messageImprint    DigestInfo,
         certs             [0] SEQUENCE SIZE (1..MAX) OF
                               TargetEtcChain
   }

Current text has: 

   CertEtcToken ::= CHOICE {

        certificate                  [0] IMPLICIT Certificate ,
        esscertid                    [1] ESSCertId ,
        pkistatus                    [2] IMPLICIT PKIStatusInfo ,
        assertion                    [3] ContentInfo ,
        crl                          [4] IMPLICIT CertificateList,
        ocspcertstatus               [5] IMPLICIT CertStatus,
        oscpcertid                   [6] IMPLICIT CertId ,
        oscpresponse                 [7] IMPLICIT OCSPResponse,
        capabilities                 [8] SMIMECapabilities,
        extension                    Extension }

This should be:

   CertEtcToken ::= CHOICE {

        certificate                  [0] IMPLICIT Certificate ,
        esscertid                    [1] ESSCertId ,
        pkistatus                    [2] IMPLICIT PKIStatusInfo ,
        assertion                    [3] ContentInfo ,
        crl                          [4] IMPLICIT CertificateList,
        ocspcertstatus               [5] CertStatus,
        oscpcertid                   [6] IMPLICIT CertID ,
        oscpresponse                 [7] IMPLICIT OCSPResponse,
        capabilities                 [8] SMIMECapabilities,
        extension                    Extension }


Correcting the errors and missing parts in the IMPORTS list are
left as an exercise to the friendly implementors.

I am using the occasion to remind also that I consider the

   - Validation of Public Key Certificates (vpkc).

(also incorrectly identified as cpkc)

as a candidate protocol for DPV/DPD. 

I have been saying this since long time for DPV. 
The differences between this part DVCS and another candidate 
are getting smaller and smaller, I would say at least 90% 
overlap. 

Peter Sylvester


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2CHFOt15180 for ietf-pkix-bks; Tue, 12 Mar 2002 09:15:24 -0800 (PST)
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 g2CHFM415176 for <[e-mail]>; Tue, 12 Mar 2002 09:15:22 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA20700; Tue, 12 Mar 2002 18:17:27 +0100
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002031218151457:384 ; Tue, 12 Mar 2002 18:15:14 +0100 
Message-ID: <[e-mail]>
Date: Tue, 12 Mar 2002 18:15:44 +0100
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]>, "500 list (E-mail)" <[e-mail]>
Subject: Re: Attribute Certificate Policy??
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 12/03/2002 18:15:14, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 12/03/2002 18:15:20, Serialize complete at 12/03/2002 18:15:20
Content-Transfer-Encoding: 7bit
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>

Sharon,

Thank you for daring to jump into the discussion.
Your editor view seems to be consistent with your personal view. :-)

> I offer my views on the current 509 text in this area (for those who may
> not know, I am the editor of X.509). Specifically 509 does state that the
> certificatePolicies extension can ONLY be used in public-key certificates 
> and not in attribute certs.

> This was a deliberate and explicit agreement made during discussion on the
> PMI model for X.509 that as defined in the 4th edition (2000) of X.509.

AAs can issue attributes certificates by making more or less verifications
on the attributes that are granted by them, in the same way like CAs can
issue public key certificates by making more or less verifications on the
identifiers that are granted by them. If I understand the model correctly,
there is no way by simply looking into an AC which "policy" has been used to
issue the AC.

The implication is that AAs can only be trusted by their name, and thus it
will not possible, for example, to trust all the AAs that are issuing ACs -
laid down under one root key - under a given (attribute) policy. 

I have difficulties to understand why the deliberate choice of not having
the equivalent of a certificate policy has been made and the arguments
presented below are not crystal clear to me.

Would you try to explain again ?

Regards,

Denis

 
> Unlike PKI, the "authority" to issue the attribute certificate in the
> first place, was viewed as the primary factor in determining whether or 
> not to accept an asserted privilege. As such the ability to identify and 
> validate this authority was the direction the PMI work took, rather than 
> to assess the policies of an issuer to determine if an AC came from an 
> 'acceptable issuer'. SOA identification and the delegation path process, 
> and associated AC extensions) are the mechanism for doing that.
> 
> However, there was also a requirement to, in the PMI, constrain the
> public-key certificate(s) that could be used to authenticate an AC holder. 
> 509 provides two ways to do this. First, a specific public-key cert can 
> be required, by using the issuerSerial mode for identifying the holder. 
> Second, the acceptableCertPolicies extension can be used to require that 
> all subsequent privilege asserters must be authenticated with a public-key 
> certificate under a specified certificate policy.
> 
> Unlike PKI where a lot of emphasis was placed on ensuring that the
> issuer was issuing under policies of interest (as there really isn't an
> equivalent in PKI to determining the 'authoritative' issuer), the emphasis 
> for PMI was on ensuring that the issuer was 'authorized' to assign the 
> privilege to the holder and on enabling privilege policy specifications 
> to define the rules for target use of ACs.
> 
> I hope that helps explain the 509 standard in this area. I copied the
> directory group on this as the 509 participants are part of that list and 
> I expect some of them will correct anything I got wrong and have additional 
> views as well :-).
> 
> Note that if PKIX identifies requirements that are not met by 509, as
> always we want to work together on those, but we would want to ensure 
> they are solid requirements.
> 
> --------------
> 
> From my own personal (non editor) viewpoint:
> 
> In terms of the two policy types David identified in his email, the 509
> PMI attempts to deal with the former (which allows AAs to impose constraints 
> on the use of ACs issued) through specific extensions in ACs (e.g. acceptable 
> privilege policies, target information, time specification etc) and with the 
> latter (which allows target side constraints to be imposed on the set of ACs 
> that can be used for a given application/transaction) through privilege policy.
> 509 does include hooks for linking privilege policy to the use of att certs and 
> does provide means for storing them in directories but does not standardize 
> a syntax for these (two sample syntaxes are partially documented in an 
> informative annex, but nothing is standardized).
> 
> I agree with Steve Farrell that it is premature to add anything along the
> lines of certificatePolicies extension to attribute certificates and 
> I personally don't see this as a requirement for the PMI model, at least not 
> as currently defined in 509.
> 
> Cheers,
> Sharon
> 
> -----Original Message-----
> From: David Chadwick [mailto:[e-mail]]
> Sent: Thursday, March 07, 2002 5:19 PM
> To: [e-mail]
> Cc: Christopher S. Francis; Housley, Russ; Ietf-Pkix
> Subject: Re: Attribute Certificate Policy??
> 
> Hi All
> 
> Having implemented a policy based attribute certificate infrastructure
> (see www.permis.org and sec.isi.salford.ac.uk/permis for more details) I
> have a few comments to make to this thread.
> 
> Firstly, there can be a requirement to limit the use of ACs to specific
> authorisation policies. In our implementation, each authorisation
> policy, or access decision policy (cf ISO 10181-3) is given a unique
> OID.
> 
> Secondly, we currently dont have an AC extension to put policy OIDs in,
> since the policy extension is only meant to be used with PK certs and
> not AC certs. So you would need to update X.509 if you are talking about
> putting policy extensions in ACs
> 
> Thirdly, there are two policies that are potentially of interest for
> ACs. So maybe two policy extensions are needed. The first is the policy
> of the AA that issued the AC (what the AC should be used for), and the
> second is the authorisation policy controlling the target that is
> accepting ACs as credentials/permissions for the access (which ACs the
> target can accept). In PERMIS we are only concerned about the latter,
> whereas I think the PKIX thread is more concerned about the former. But
> consider this. University degrees, Microsoft Certified Engineer, ISO
> 9000 certified, Visa cards etc. can all be issued electronically as ACs,
> signed by the issuing institution. The holder can present these
> privilege ACs to any electronic target in order to try to gain access.
> So typically an issuer does not try to limit the targets at which the
> ACs are deemed to be valid and useful privileges. (A university does not
> say where its degrees can be used.) It is the target administrator that
> decides which ACs it will trust and this is built into its target access
> decision policy (will Org X accept degrees from Univ Y). Clearly a
> target (administrator) may wish to consult the issuing policy, if one
> exists, before trusting particular AAs, and so a pointer to this in each
> AC could be useful (e.g Visa might place restrictions on which targets
> can use its electronic credit cards). Parts of the issuing policy are
> already in the AC for example, whether delegation is allowed or not. If
> the issuer does try to limit the target policies that are applicable to
> an AC, it will need to know about the target policies before issuing the
> certificates, which might typically be difficult to achieve.
> 
> My suggestion would be to steer clear of the existing policies
> extension, which is defined for use with PKCerts, and to define new AC
> extensions if ones are needed (they can clearly have the same syntax as
> the existing policy extension, but give them new extension OIDs). This
> more or less agrees with Stephen's email below
> 
> David
> 
> Stephen Farrell wrote:
> >
> > Chris,
> >
> > I'd be against the idea of proposing this as an update to the AC profile
> 
> > for the following reasons:
> >
> > - The profile is in the rfc editor's queue only awaiting son-of-2359 to
> >   be processed and such an update would require a re-set back to WG last
> 
> >   call (a matter of months!)
> > - I don't believe that the use of policy OIDs in ACs is at all well
> >   understood and therefore I'd argue to omit it from the profile (one
> >   of the things we tried to do with the AC profile was to only include
> >   suff that we were pretty sure could work)
> > - There may be entirely different policy considerations to address,
> >   depending on the context for the use of ACs (e.g. supporting roles for
> 
> >   long-term signatures vs roles for access control).
> >
> > So, while I'd welcome work starting on this - for both process and
> > technical reasons I believe the way to handle it is to write things up
> in
> > a separate I-D. At some point in the future (say if the AC profile were
> > being cycled at proposed standard), the two things could be merged if
> > appropriate.
> >
> > Regards,
> > Stephen.
> >
> > "Christopher S. Francis" wrote:
> > >
> > > Sure.  I can pursue it.  Since I don't spend a lot of time here, I'm
> not
> > > exactly sure what the appropriate process is, but what I have in mind
> is to
> > > do the following:
> > >
> > > 1) Get some clarification from ANSI and whoever else has an opinion on
> 
> > > whether X.509 offers an extension that is intended to be used to carry
> 
> > > certificate policy information in attribute certificates.  Perhaps
> > > certificatePolicies, perhaps acceptablePrivilegePolicies, perhaps they
> had
> > > something else in mind.
> > > 2) Depending on what I find out, propose an update to the PKIX
> attribute
> > > certificate profile that includes an extension to ACs to hold policy
> > > information about the issuing authority.
> > >
> > > Based on your earlier responses, I understand that a
> certificatePolicies
> > > extension could be included in an AC as long as it is marked
> non-critical,
> > > but it that's only because *anything* can be included as an extension
> if
> > > it's marked non-critical.  It seems to me there should be something
> specific
> > > in the profile to address the issue of certificate policy.
> > >
> > > Chris
> > > -----Original Message-----
> > > From: [e-mail]
> [mailto:[e-mail]]On
> > > Behalf Of Housley, Russ
> > > Sent: Wednesday, March 06, 2002 11:02 AM
> > > To: Christopher S. Francis
> > > Cc: Ietf-Pkix
> > > Subject: Re: Attribute Certificate Policy??
> > >
> > > Chris:
> > >
> > > I am not aware of any work in this area.  You can take the lead.
> > >
> > > Russ
> > >
> > > At 05:41 PM 3/5/2002 -0500, Christopher S. Francis wrote:
> > >
> > > >Is there a defined mechanism to specify something analogous to a
> > > >certificate policy in an attribute certificate?
> > > >
> > > >
> > > >
> > > >In reviewing the PKIX AC profile, I see that the syntax of the
> attributes
> > > >field is defined by the AttributeType OID, but rather than syntax per
> se,
> > > >I m looking for a way to specify the particular set of policies,
> > > >practices, and procedures that the attribute authority was operating
> under
> > > >when it issued the attribute certificate.  Seems like this would be
> > > >important to relying parties.
> > > >
> > > >
> > > >
> > > >X.509 includes an acceptablePrivilegePolicies extension that seems
> like it
> > > >might to the job, but it was apparently profiled out by PKIX.
> > > >
> > > >
> > > >
> > > >Chris Francis
> > > >
> > > >
> > > >
> > > >
> >
> > --
> > ____________________________________________________________
> > Stephen Farrell
> > Baltimore Technologies,   tel: (direct line) [phone]
> > 39 Parkgate Street,                     fax: [phone]
> > Dublin 8.                mailto:[e-mail]
> > Ireland                             http://www.baltimore.com
> 
> --
> *****************************************************************
> 
> David W. Chadwick, BSc PhD
> Professor of Information Systems Security
> IS Institute, University of Salford, Salford M5 4WT
> Tel: [phone]  Fax [phone]
> Mobile: [phone]
> Email: [e-mail]
> Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
> Research Projects: http://sec.isi.salford.ac.uk
> Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
> X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
> Entrust key validation string: MLJ9-DU5T-HV8J
> PGP Key ID is 0xBC238DE5
> 
> *****************************************************************


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2CG2Co09427 for ietf-pkix-bks; Tue, 12 Mar 2002 08:02:12 -0800 (PST)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2CG2A409423 for <[e-mail]>; Tue, 12 Mar 2002 08:02:10 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <GZ3RQ19Y>; Tue, 12 Mar 2002 11:04:46 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: Ietf-Pkix <[e-mail]>
Cc: "500 list (E-mail)" <[e-mail]>
Subject: RE: Attribute Certificate Policy??
Date: Tue, 12 Mar 2002 11:02:05 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C9DF.41815710"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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_01C1C9DF.41815710
Content-Type: text/plain


I offer my views on the current 509 text in this area (for those who may not
know, I 
am the editor of X.509). Specifically 509 does state that the
certificatePolicies
extension can ONLY be used in public-key certificates and not in attribute
certs.
This was a deliberate and explicit agreement made during discussion on the
PMI 
model for X.509 that as defined in the 4th edition (2000) of X.509.

Unlike PKI, the "authority" to issue the attribute certificate in the first
place, 
was viewed as the primary factor in determining whether or not to accept an
asserted 
privilege. As such the ability to identify and validate this authority was
the 
direction the PMI work took, rather than to assess the policies of an issuer
to 
determine if an AC came from an 'acceptable issuer'. SOA identification and
the 
delegation path process, and associated AC extensions) are the mechanism for
doing that.

However, there was also a requirement to, in the PMI, constrain the
public-key 
certificate(s) that could be used to authenticate an AC holder. 509 provides
two 
ways to do this. First, a specific public-key cert can be required, by using
the 
issuerSerial mode for identifying the holder. Second, the
acceptableCertPolicies 
extension can be used to require that all subsequent privilege asserters
must be 
authenticated with a public-key certificate under a specified certificate
policy.

Unlike PKI where a lot of emphasis was placed on ensuring that the 
issuer was issuing under policies of interest (as there really isn't an
equivalent
in PKI to determining the 'authoritative' issuer), the emphasis for PMI was
on ensuring 
that the issuer was 'authorized' to assign the privilege to the holder and
on enabling
privilege policy specifications to define the rules for target use of ACs. 

I hope that helps explain the 509 standard in this area. I copied the
directory group
on this as the 509 participants are part of that list and I expect some of
them will 
correct anything I got wrong and have additional views as well :-). 

Note that if PKIX identifies requirements that are not met by 509, as always
we want 
to work together on those, but we would want to ensure they are solid
requirements. 

--------------

>From my own personal (non editor) viewpoint:

In terms of the two policy types David identified in his email, the 509 PMI
attempts
to deal with the former (which allows AAs to impose constraints on the use
of 
ACs issued) through specific extensions in ACs (e.g. acceptable privilege
policies, target information, time specification etc) and with the latter
(which 
allows target side constraints to be imposed on the set of ACs that can be
used for 
a given application/transaction) through privilege policy. 509 does include 
hooks for linking privilege policy to the use of att certs and does provide
means 
for storing them in directories but does not standardize a syntax for these 
(two sample syntaxes are partially documented in an informative annex, but 
nothing is standardized). 

I agree with Steve Farrell that it is premature to add anything along the
lines 
of certificatePolicies extension to attribute certificates and I personally
don't see
this as a requirement for the PMI model, at least not as currently defined
in 509.

Cheers,
Sharon 


-----Original Message-----
From: David Chadwick [mailto:[e-mail]]
Sent: Thursday, March 07, 2002 5:19 PM
To: [e-mail]
Cc: Christopher S. Francis; Housley, Russ; Ietf-Pkix
Subject: Re: Attribute Certificate Policy??


Hi All

Having implemented a policy based attribute certificate infrastructure
(see www.permis.org and sec.isi.salford.ac.uk/permis for more details) I
have a few comments to make to this thread.

Firstly, there can be a requirement to limit the use of ACs to specific
authorisation policies. In our implementation, each authorisation
policy, or access decision policy (cf ISO 10181-3) is given a unique
OID. 

Secondly, we currently dont have an AC extension to put policy OIDs in,
since the policy extension is only meant to be used with PK certs and
not AC certs. So you would need to update X.509 if you are talking about
putting policy extensions in ACs

Thirdly, there are two policies that are potentially of interest for
ACs. So maybe two policy extensions are needed. The first is the policy
of the AA that issued the AC (what the AC should be used for), and the
second is the authorisation policy controlling the target that is
accepting ACs as credentials/permissions for the access (which ACs the
target can accept). In PERMIS we are only concerned about the latter,
whereas I think the PKIX thread is more concerned about the former. But
consider this. University degrees, Microsoft Certified Engineer, ISO
9000 certified, Visa cards etc. can all be issued electronically as ACs,
signed by the issuing institution. The holder can present these
privilege ACs to any electronic target in order to try to gain access.
So typically an issuer does not try to limit the targets at which the
ACs are deemed to be valid and useful privileges. (A university does not
say where its degrees can be used.) It is the target administrator that
decides which ACs it will trust and this is built into its target access
decision policy (will Org X accept degrees from Univ Y). Clearly a
target (administrator) may wish to consult the issuing policy, if one
exists, before trusting particular AAs, and so a pointer to this in each
AC could be useful (e.g Visa might place restrictions on which targets
can use its electronic credit cards). Parts of the issuing policy are
already in the AC for example, whether delegation is allowed or not. If
the issuer does try to limit the target policies that are applicable to
an AC, it will need to know about the target policies before issuing the
certificates, which might typically be difficult to achieve.

My suggestion would be to steer clear of the existing policies
extension, which is defined for use with PKCerts, and to define new AC
extensions if ones are needed (they can clearly have the same syntax as
the existing policy extension, but give them new extension OIDs). This
more or less agrees with Stephen's email below

David


Stephen Farrell wrote:
> 
> Chris,
> 
> I'd be against the idea of proposing this as an update to the AC profile
> for the following reasons:
> 
> - The profile is in the rfc editor's queue only awaiting son-of-2359 to
>   be processed and such an update would require a re-set back to WG last
>   call (a matter of months!)
> - I don't believe that the use of policy OIDs in ACs is at all well
>   understood and therefore I'd argue to omit it from the profile (one
>   of the things we tried to do with the AC profile was to only include
>   suff that we were pretty sure could work)
> - There may be entirely different policy considerations to address,
>   depending on the context for the use of ACs (e.g. supporting roles for
>   long-term signatures vs roles for access control).
> 
> So, while I'd welcome work starting on this - for both process and
> technical reasons I believe the way to handle it is to write things up in
> a separate I-D. At some point in the future (say if the AC profile were
> being cycled at proposed standard), the two things could be merged if
> appropriate.
> 
> Regards,
> Stephen.
> 
> "Christopher S. Francis" wrote:
> >
> > Sure.  I can pursue it.  Since I don't spend a lot of time here, I'm not
> > exactly sure what the appropriate process is, but what I have in mind is
to
> > do the following:
> >
> > 1) Get some clarification from ANSI and whoever else has an opinion on
> > whether X.509 offers an extension that is intended to be used to carry
> > certificate policy information in attribute certificates.  Perhaps
> > certificatePolicies, perhaps acceptablePrivilegePolicies, perhaps they
had
> > something else in mind.
> > 2) Depending on what I find out, propose an update to the PKIX attribute
> > certificate profile that includes an extension to ACs to hold policy
> > information about the issuing authority.
> >
> > Based on your earlier responses, I understand that a certificatePolicies
> > extension could be included in an AC as long as it is marked
non-critical,
> > but it that's only because *anything* can be included as an extension if
> > it's marked non-critical.  It seems to me there should be something
specific
> > in the profile to address the issue of certificate policy.
> >
> > Chris
> > -----Original Message-----
> > From: [e-mail]
[mailto:[e-mail]]On
> > Behalf Of Housley, Russ
> > Sent: Wednesday, March 06, 2002 11:02 AM
> > To: Christopher S. Francis
> > Cc: Ietf-Pkix
> > Subject: Re: Attribute Certificate Policy??
> >
> > Chris:
> >
> > I am not aware of any work in this area.  You can take the lead.
> >
> > Russ
> >
> > At 05:41 PM 3/5/2002 -0500, Christopher S. Francis wrote:
> >
> > >Is there a defined mechanism to specify something analogous to a
> > >certificate policy in an attribute certificate?
> > >
> > >
> > >
> > >In reviewing the PKIX AC profile, I see that the syntax of the
attributes
> > >field is defined by the AttributeType OID, but rather than syntax per
se,
> > >I m looking for a way to specify the particular set of policies,
> > >practices, and procedures that the attribute authority was operating
under
> > >when it issued the attribute certificate.  Seems like this would be
> > >important to relying parties.
> > >
> > >
> > >
> > >X.509 includes an acceptablePrivilegePolicies extension that seems like
it
> > >might to the job, but it was apparently profiled out by PKIX.
> > >
> > >
> > >
> > >Chris Francis
> > >
> > >
> > >
> > >
> 
> --
> ____________________________________________________________
> Stephen Farrell
> Baltimore Technologies,   tel: (direct line) [phone]
> 39 Parkgate Street,                     fax: [phone]
> Dublin 8.                mailto:[e-mail]
> Ireland                             http://www.baltimore.com

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

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

*****************************************************************

------_=_NextPart_001_01C1C9DF.41815710
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.2653.12">
<TITLE>RE: Attribute Certificate Policy??</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=2>I offer my views on the current 509 text in this area (for those who may not know, I </FONT>
<BR><FONT SIZE=2>am the editor of X.509). Specifically 509 does state that the certificatePolicies</FONT>
<BR><FONT SIZE=2>extension can ONLY be used in public-key certificates and not in attribute certs.</FONT>
<BR><FONT SIZE=2>This was a deliberate and explicit agreement made during discussion on the PMI </FONT>
<BR><FONT SIZE=2>model for X.509 that as defined in the 4th edition (2000) of X.509.</FONT>
</P>

<P><FONT SIZE=2>Unlike PKI, the &quot;authority&quot; to issue the attribute certificate in the first place, </FONT>
<BR><FONT SIZE=2>was viewed as the primary factor in determining whether or not to accept an asserted </FONT>
<BR><FONT SIZE=2>privilege. As such the ability to identify and validate this authority was the </FONT>
<BR><FONT SIZE=2>direction the PMI work took, rather than to assess the policies of an issuer to </FONT>
<BR><FONT SIZE=2>determine if an AC came from an 'acceptable issuer'. SOA identification and the </FONT>
<BR><FONT SIZE=2>delegation path process, and associated AC extensions) are the mechanism for doing that.</FONT>
</P>

<P><FONT SIZE=2>However, there was also a requirement to, in the PMI, constrain the public-key </FONT>
<BR><FONT SIZE=2>certificate(s) that could be used to authenticate an AC holder. 509 provides two </FONT>
<BR><FONT SIZE=2>ways to do this. First, a specific public-key cert can be required, by using the </FONT>
<BR><FONT SIZE=2>issuerSerial mode for identifying the holder. Second, the acceptableCertPolicies </FONT>
<BR><FONT SIZE=2>extension can be used to require that all subsequent privilege asserters must be </FONT>
<BR><FONT SIZE=2>authenticated with a public-key certificate under a specified certificate policy.</FONT>
</P>

<P><FONT SIZE=2>Unlike PKI where a lot of emphasis was placed on ensuring that the </FONT>
<BR><FONT SIZE=2>issuer was issuing under policies of interest (as there really isn't an equivalent</FONT>
<BR><FONT SIZE=2>in PKI to determining the 'authoritative' issuer), the emphasis for PMI was on ensuring </FONT>
<BR><FONT SIZE=2>that the issuer was 'authorized' to assign the privilege to the holder and on enabling</FONT>
<BR><FONT SIZE=2>privilege policy specifications to define the rules for target use of ACs. </FONT>
</P>

<P><FONT SIZE=2>I hope that helps explain the 509 standard in this area. I copied the directory group</FONT>
<BR><FONT SIZE=2>on this as the 509 participants are part of that list and I expect some of them will </FONT>
<BR><FONT SIZE=2>correct anything I got wrong and have additional views as well :-). </FONT>
</P>

<P><FONT SIZE=2>Note that if PKIX identifies requirements that are not met by 509, as always we want </FONT>
<BR><FONT SIZE=2>to work together on those, but we would want to ensure they are solid requirements. </FONT>
</P>

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

<P><FONT SIZE=2>From my own personal (non editor) viewpoint:</FONT>
</P>

<P><FONT SIZE=2>In terms of the two policy types David identified in his email, the 509 PMI attempts</FONT>
<BR><FONT SIZE=2>to deal with the former (which allows AAs to impose constraints on the use of </FONT>
<BR><FONT SIZE=2>ACs issued) through specific extensions in ACs (e.g. acceptable privilege</FONT>
<BR><FONT SIZE=2>policies, target information, time specification etc) and with the latter (which </FONT>
<BR><FONT SIZE=2>allows target side constraints to be imposed on the set of ACs that can be used for </FONT>
<BR><FONT SIZE=2>a given application/transaction) through privilege policy. 509 does include </FONT>
<BR><FONT SIZE=2>hooks for linking privilege policy to the use of att certs and does provide means </FONT>
<BR><FONT SIZE=2>for storing them in directories but does not standardize a syntax for these </FONT>
<BR><FONT SIZE=2>(two sample syntaxes are partially documented in an informative annex, but </FONT>
<BR><FONT SIZE=2>nothing is standardized). </FONT>
</P>

<P><FONT SIZE=2>I agree with Steve Farrell that it is premature to add anything along the lines </FONT>
<BR><FONT SIZE=2>of certificatePolicies extension to attribute certificates and I personally don't see</FONT>
<BR><FONT SIZE=2>this as a requirement for the PMI model, at least not as currently defined in 509.</FONT>
</P>

<P><FONT SIZE=2>Cheers,</FONT>
<BR><FONT SIZE=2>Sharon </FONT>
</P>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: David Chadwick [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>Sent: Thursday, March 07, 2002 5:19 PM</FONT>
<BR><FONT SIZE=2>To: [e-mail]</FONT>
<BR><FONT SIZE=2>Cc: Christopher S. Francis; Housley, Russ; Ietf-Pkix</FONT>
<BR><FONT SIZE=2>Subject: Re: Attribute Certificate Policy??</FONT>
</P>
<BR>

<P><FONT SIZE=2>Hi All</FONT>
</P>

<P><FONT SIZE=2>Having implemented a policy based attribute certificate infrastructure</FONT>
<BR><FONT SIZE=2>(see www.permis.org and sec.isi.salford.ac.uk/permis for more details) I</FONT>
<BR><FONT SIZE=2>have a few comments to make to this thread.</FONT>
</P>

<P><FONT SIZE=2>Firstly, there can be a requirement to limit the use of ACs to specific</FONT>
<BR><FONT SIZE=2>authorisation policies. In our implementation, each authorisation</FONT>
<BR><FONT SIZE=2>policy, or access decision policy (cf ISO 10181-3) is given a unique</FONT>
<BR><FONT SIZE=2>OID. </FONT>
</P>

<P><FONT SIZE=2>Secondly, we currently dont have an AC extension to put policy OIDs in,</FONT>
<BR><FONT SIZE=2>since the policy extension is only meant to be used with PK certs and</FONT>
<BR><FONT SIZE=2>not AC certs. So you would need to update X.509 if you are talking about</FONT>
<BR><FONT SIZE=2>putting policy extensions in ACs</FONT>
</P>

<P><FONT SIZE=2>Thirdly, there are two policies that are potentially of interest for</FONT>
<BR><FONT SIZE=2>ACs. So maybe two policy extensions are needed. The first is the policy</FONT>
<BR><FONT SIZE=2>of the AA that issued the AC (what the AC should be used for), and the</FONT>
<BR><FONT SIZE=2>second is the authorisation policy controlling the target that is</FONT>
<BR><FONT SIZE=2>accepting ACs as credentials/permissions for the access (which ACs the</FONT>
<BR><FONT SIZE=2>target can accept). In PERMIS we are only concerned about the latter,</FONT>
<BR><FONT SIZE=2>whereas I think the PKIX thread is more concerned about the former. But</FONT>
<BR><FONT SIZE=2>consider this. University degrees, Microsoft Certified Engineer, ISO</FONT>
<BR><FONT SIZE=2>9000 certified, Visa cards etc. can all be issued electronically as ACs,</FONT>
<BR><FONT SIZE=2>signed by the issuing institution. The holder can present these</FONT>
<BR><FONT SIZE=2>privilege ACs to any electronic target in order to try to gain access.</FONT>
<BR><FONT SIZE=2>So typically an issuer does not try to limit the targets at which the</FONT>
<BR><FONT SIZE=2>ACs are deemed to be valid and useful privileges. (A university does not</FONT>
<BR><FONT SIZE=2>say where its degrees can be used.) It is the target administrator that</FONT>
<BR><FONT SIZE=2>decides which ACs it will trust and this is built into its target access</FONT>
<BR><FONT SIZE=2>decision policy (will Org X accept degrees from Univ Y). Clearly a</FONT>
<BR><FONT SIZE=2>target (administrator) may wish to consult the issuing policy, if one</FONT>
<BR><FONT SIZE=2>exists, before trusting particular AAs, and so a pointer to this in each</FONT>
<BR><FONT SIZE=2>AC could be useful (e.g Visa might place restrictions on which targets</FONT>
<BR><FONT SIZE=2>can use its electronic credit cards). Parts of the issuing policy are</FONT>
<BR><FONT SIZE=2>already in the AC for example, whether delegation is allowed or not. If</FONT>
<BR><FONT SIZE=2>the issuer does try to limit the target policies that are applicable to</FONT>
<BR><FONT SIZE=2>an AC, it will need to know about the target policies before issuing the</FONT>
<BR><FONT SIZE=2>certificates, which might typically be difficult to achieve.</FONT>
</P>

<P><FONT SIZE=2>My suggestion would be to steer clear of the existing policies</FONT>
<BR><FONT SIZE=2>extension, which is defined for use with PKCerts, and to define new AC</FONT>
<BR><FONT SIZE=2>extensions if ones are needed (they can clearly have the same syntax as</FONT>
<BR><FONT SIZE=2>the existing policy extension, but give them new extension OIDs). This</FONT>
<BR><FONT SIZE=2>more or less agrees with Stephen's email below</FONT>
</P>

<P><FONT SIZE=2>David</FONT>
</P>
<BR>

<P><FONT SIZE=2>Stephen Farrell wrote:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Chris,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I'd be against the idea of proposing this as an update to the AC profile</FONT>
<BR><FONT SIZE=2>&gt; for the following reasons:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; - The profile is in the rfc editor's queue only awaiting son-of-2359 to</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; be processed and such an update would require a re-set back to WG last</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; call (a matter of months!)</FONT>
<BR><FONT SIZE=2>&gt; - I don't believe that the use of policy OIDs in ACs is at all well</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; understood and therefore I'd argue to omit it from the profile (one</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; of the things we tried to do with the AC profile was to only include</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; suff that we were pretty sure could work)</FONT>
<BR><FONT SIZE=2>&gt; - There may be entirely different policy considerations to address,</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; depending on the context for the use of ACs (e.g. supporting roles for</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; long-term signatures vs roles for access control).</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; So, while I'd welcome work starting on this - for both process and</FONT>
<BR><FONT SIZE=2>&gt; technical reasons I believe the way to handle it is to write things up in</FONT>
<BR><FONT SIZE=2>&gt; a separate I-D. At some point in the future (say if the AC profile were</FONT>
<BR><FONT SIZE=2>&gt; being cycled at proposed standard), the two things could be merged if</FONT>
<BR><FONT SIZE=2>&gt; appropriate.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Regards,</FONT>
<BR><FONT SIZE=2>&gt; Stephen.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &quot;Christopher S. Francis&quot; wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Sure.&nbsp; I can pursue it.&nbsp; Since I don't spend a lot of time here, I'm not</FONT>
<BR><FONT SIZE=2>&gt; &gt; exactly sure what the appropriate process is, but what I have in mind is to</FONT>
<BR><FONT SIZE=2>&gt; &gt; do the following:</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; 1) Get some clarification from ANSI and whoever else has an opinion on</FONT>
<BR><FONT SIZE=2>&gt; &gt; whether X.509 offers an extension that is intended to be used to carry</FONT>
<BR><FONT SIZE=2>&gt; &gt; certificate policy information in attribute certificates.&nbsp; Perhaps</FONT>
<BR><FONT SIZE=2>&gt; &gt; certificatePolicies, perhaps acceptablePrivilegePolicies, perhaps they had</FONT>
<BR><FONT SIZE=2>&gt; &gt; something else in mind.</FONT>
<BR><FONT SIZE=2>&gt; &gt; 2) Depending on what I find out, propose an update to the PKIX attribute</FONT>
<BR><FONT SIZE=2>&gt; &gt; certificate profile that includes an extension to ACs to hold policy</FONT>
<BR><FONT SIZE=2>&gt; &gt; information about the issuing authority.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Based on your earlier responses, I understand that a certificatePolicies</FONT>
<BR><FONT SIZE=2>&gt; &gt; extension could be included in an AC as long as it is marked non-critical,</FONT>
<BR><FONT SIZE=2>&gt; &gt; but it that's only because *anything* can be included as an extension if</FONT>
<BR><FONT SIZE=2>&gt; &gt; it's marked non-critical.&nbsp; It seems to me there should be something specific</FONT>
<BR><FONT SIZE=2>&gt; &gt; in the profile to address the issue of certificate policy.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Chris</FONT>
<BR><FONT SIZE=2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; &gt; From: [e-mail] [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]On</FONT>
<BR><FONT SIZE=2>&gt; &gt; Behalf Of Housley, Russ</FONT>
<BR><FONT SIZE=2>&gt; &gt; Sent: Wednesday, March 06, 2002 11:02 AM</FONT>
<BR><FONT SIZE=2>&gt; &gt; To: Christopher S. Francis</FONT>
<BR><FONT SIZE=2>&gt; &gt; Cc: Ietf-Pkix</FONT>
<BR><FONT SIZE=2>&gt; &gt; Subject: Re: Attribute Certificate Policy??</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Chris:</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; I am not aware of any work in this area.&nbsp; You can take the lead.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Russ</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; At 05:41 PM 3/5/2002 -0500, Christopher S. Francis wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;Is there a defined mechanism to specify something analogous to a</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;certificate policy in an attribute certificate?</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;In reviewing the PKIX AC profile, I see that the syntax of the attributes</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;field is defined by the AttributeType OID, but rather than syntax per se,</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;I m looking for a way to specify the particular set of policies,</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;practices, and procedures that the attribute authority was operating under</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;when it issued the attribute certificate.&nbsp; Seems like this would be</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;important to relying parties.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;X.509 includes an acceptablePrivilegePolicies extension that seems like it</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;might to the job, but it was apparently profiled out by PKIX.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;Chris Francis</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &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; Stephen Farrell</FONT>
<BR><FONT SIZE=2>&gt; Baltimore Technologies,&nbsp;&nbsp; tel: (direct line) [phone]</FONT>
<BR><FONT SIZE=2>&gt; 39 Parkgate Street,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fax: [phone]</FONT>
<BR><FONT SIZE=2>&gt; Dublin 8.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A HREF="mailto:[e-mail]">mailto:[e-mail]</A></FONT>
<BR><FONT SIZE=2>&gt; Ireland&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A HREF="http://www.baltimore.com" TARGET="_blank">http://www.baltimore.com</A></FONT>
</P>

<P><FONT SIZE=2>-- </FONT>
<BR><FONT SIZE=2>*****************************************************************</FONT>
</P>

<P><FONT SIZE=2>David W. Chadwick, BSc PhD</FONT>
<BR><FONT SIZE=2>Professor of Information Systems Security</FONT>
<BR><FONT SIZE=2>IS Institute, University of Salford, Salford M5 4WT</FONT>
<BR><FONT SIZE=2>Tel: [phone]&nbsp; Fax [phone]</FONT>
<BR><FONT SIZE=2>Mobile: [phone]</FONT>
<BR><FONT SIZE=2>Email: [e-mail]</FONT>
<BR><FONT SIZE=2>Home Page:&nbsp; <A HREF="http://www.salford.ac.uk/its024/chadwick.htm" TARGET="_blank">http://www.salford.ac.uk/its024/chadwick.htm</A></FONT>
<BR><FONT SIZE=2>Research Projects: <A HREF="http://sec.isi.salford.ac.uk" TARGET="_blank">http://sec.isi.salford.ac.uk</A></FONT>
<BR><FONT SIZE=2>Understanding X.500:&nbsp; <A HREF="http://www.salford.ac.uk/its024/X500.htm" TARGET="_blank">http://www.salford.ac.uk/its024/X500.htm</A></FONT>
<BR><FONT SIZE=2>X.500/LDAP Seminars: <A HREF="http://www.salford.ac.uk/its024/seminars.htm" TARGET="_blank">http://www.salford.ac.uk/its024/seminars.htm</A></FONT>
<BR><FONT SIZE=2>Entrust key validation string: MLJ9-DU5T-HV8J</FONT>
<BR><FONT SIZE=2>PGP Key ID is 0xBC238DE5</FONT>
</P>

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

</BODY>
</HTML>
------_=_NextPart_001_01C1C9DF.41815710--


Received: by above.proper.com (8.11.6/8.11.3) id g2CFVVF07111 for ietf-pkix-bks; Tue, 12 Mar 2002 07:31:31 -0800 (PST)
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 g2CFVU407106 for <[e-mail]>; Tue, 12 Mar 2002 07:31:30 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA14656; Tue, 12 Mar 2002 16:33:28 +0100
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002031215510902:365 ; Tue, 12 Mar 2002 15:51:09 +0100 
Message-ID: <[e-mail]>
Date: Tue, 12 Mar 2002 15:51:40 +0100
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: "Christopher S. Francis" <[e-mail]>
CC: "Housley, Russ" <[e-mail]>, Ietf-Pkix <[e-mail]>
Subject: Re: Attribute Certificate Policy??
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 12/03/2002 15:51:09, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 12/03/2002 16:31:22, Serialize complete at 12/03/2002 16:31:22
Content-Transfer-Encoding: 7bit
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>

Russ, Chris and all,

> I am not aware of any work in this area.  You can take the lead.

ETSI is currently performing some preparatory work to identify what is 
specific/different from a Certification Policy.

Thenafter, ETSI will be addressing the topic: "Policy Requirements for
Attribute Authorities" (i.e. the set of practices and procedures that an
Attribute Authority should observe when issuing Attribute Certificates).

Any input on this topic will be appreciated and can be sent directly to me. 
I will take care of them within the ETSI group. 

Denis


> Russ
> 
> At 05:41 PM 3/5/2002 -0500, Christopher S. Francis wrote:
> 
> >Is there a defined mechanism to specify something analogous to a
> >certificate policy in an attribute certificate?
> >
> >
> >
> >In reviewing the PKIX AC profile, I see that the syntax of the attributes
> >field is defined by the AttributeType OID, but rather than syntax per se,
> >I m looking for a way to specify the particular set of policies,
> >practices, and procedures that the attribute authority was operating under
> >when it issued the attribute certificate.  Seems like this would be
> >important to relying parties.
> >
> >
> >
> >X.509 includes an acceptablePrivilegePolicies extension that seems like it
> >might to the job, but it was apparently profiled out by PKIX.
> >
> >
> >
> >Chris Francis
> >
> >
> >
> >


Received: by above.proper.com (8.11.6/8.11.3) id g2CFV6B07102 for ietf-pkix-bks; Tue, 12 Mar 2002 07:31:06 -0800 (PST)
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 g2CFV5407098 for <[e-mail]>; Tue, 12 Mar 2002 07:31:05 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA14646 for <[e-mail]>; Tue, 12 Mar 2002 16:33:11 +0100
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002031215481401:364 ; Tue, 12 Mar 2002 15:48:14 +0100 
Message-ID: <[e-mail]>
Date: Tue, 12 Mar 2002 15:48:45 +0100
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]>
Subject: draft-ietf-pkix-pr-tsa-00.txt
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 12/03/2002 15:48:14, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 12/03/2002 16:31:05, Serialize complete at 12/03/2002 16:31:05
Content-Transfer-Encoding: 7bit
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>

Since the dead line for placing this document on the web server has been
missed, this document is advertised directly to the PKIX mailing list and
will be placed on the IETF web server after the Minneapolis meeting.

This draft is a work item of the Public-Key Infrastructure (X.509) Working
Group of the IETF.

        Title           : Policy Requirements for Time-Stamping Authorities
        Author(s)       : D. Pinkas, J. Ross.
        Filename        : draft-ietf-pkix-pr-tsa-00.txt
        Pages           : 39
        Date            : 12-Mar-02

   This document specifies policy requirements relating to the 
   operation of Time-stamping Authorities (TSAs). It defines policy 
   requirements on the operation and management practices of TSAs such 
   that subscribers and relying parties may have confidence in the 
   operation of the time-stamping services.

   A temporary URL for this Internet-Draft is:
   http://www.secstan.co.uk/Downloads/PR-TSA-00.txt

   The contents of this Informational RFC is technically equivalent to
   ETSI TS 102 023 V1.1.1 (2002-01) [TS 102023] which can be found at:
   http://portal.etsi.org/sec/ts_102023v010101p.pdf


Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2CFCbL06609 for ietf-pkix-bks; Tue, 12 Mar 2002 07:12:37 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2CFCW406605 for <[e-mail]>; Tue, 12 Mar 2002 07:12:32 -0800 (PST)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26551; Tue, 12 Mar 2002 08:12:28 -0700 (MST)
Received: from sun.com (dhcp75-167 [129.148.75.167]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.2) with ESMTP id KAA00472; Tue, 12 Mar 2002 10:12:27 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 12 Mar 2002 10:09:36 -0500
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Williams <[e-mail]>
CC: "'Yee, Peter'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: Privilege policy (was Re: I-D ACTION:draft-ietf-pkix-acrmf-01.txt)
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>

There seems to be some ongoing confusion about privilege
policy, as defined in X.509. Privilege policy determines
whether the privileges of a privilege holder are sufficient.
An access control list is one example of a privilege policy.

Although ACPROF does not mention privilege policy, I believe
that there's an unstated assumption that after an AC has
been validated it may be used in access control decisions
or for other purposes. It is at this point that privilege
policy enters the picture.

The only place in X.509 AC validation where privilege policy
is involved in is where the acceptable privilege policies
extension is present. In that case, the verifier must
check that the OID for the privilege policy it's planning
to use is included in the list of OIDs in the extension.
However, ACPROF does not support this extension. Therefore,
there is no need for it to worry about privilege policy.

-Steve

Peter Williams wrote:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-ac509prof-09.txt
> 
> describes a set of AC verification rules, when an AC chain
> has one element.
> 
> X.509 16.1 defines the "basic path processing" requirements
> for processing "a single AC". X.509 16 is clear that 16.1
> is REQUIRED for the case of processing a single AC.
> 
> Peter, a question (Q): What is the relationship between
> "privilege policy" (as used in X.509 16.1) and ACPROF section
> 5 "Attribute Certificate validation?"
> 
> I dont believe profiles can remove the X.509 requirement
> to follow X.509 16.1 when validating an AC. As ACPROF makes no
> mention of privilege policy, we have to assume that
> X.509 16.1 controls, and that conforming implementations
> MUST implement the privilege policy enforcement
> requirements.
> 
> A reasonable answer to the question (Q) is that
> "validating right-to-use" a privilege is not the same
> thing as "validating an AC" - even though these two ideas
> are intertwined in the international standard, section 16.1.
> Hence, privilege policy matters fall outside the scope of ACPROF
> and IETF.
> 
> If this latter case is your thinking, then of course
> designers of conforming implementations must
> look to X509 for control when validating actual
> privilege *assertion* at privilege "use" time.
> 
> If we could clearup that ACPROF does not control
> validation of privilege *assertion*, this would
> be valuable. Privlege assertion within a lifetime
> is of course what matters and what makes ACs
> viable. Validating the privilege assertion
> can of course be critically important to
> the application's security policy.
> 
> Peter.
> 
> -----Original Message-----
> From: Yee, Peter [mailto:[e-mail]]
> Sent: Monday, March 11, 2002 2:23 PM
> To: '[e-mail]'
> Cc: '[e-mail]'
> Subject: RE: I-D ACTION:draft-ietf-pkix-acrmf-01.txt
> 
> >I recognize that [ACPROF], the Internet Attribute Certificate Profile, does
> >not currently recommend the use of delegation and AC chains as specified in
> >the X.509 standard [X.509-2000], however I would hope that your Internet
> >Draft [ACRMF] on Attribute Certificate Request Message Format will not
> >preclude it.
> 
> Yes, I would call that an oversight on my part.  I have to admit that
> sometimes I think of ACs within the limited scope of ACPROF.
>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2C13PG04043 for ietf-pkix-bks; Mon, 11 Mar 2002 17:03:25 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g2C13N804033 for <[e-mail]>; Mon, 11 Mar 2002 17:03:23 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 12 Mar 2002 01:02:55 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id UAA09401; Mon, 11 Mar 2002 20:02:58 -0500 (EST)
Received: from exrsa01.rsa.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g2C13P523718; Mon, 11 Mar 2002 20:03:25 -0500 (EST)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2653.19) id <FVAZD1LM>; Mon, 11 Mar 2002 17:09:53 -0800
Message-ID: <D516C97A440DD31197640008C7EBBE4701B27E31@EXRSA02>
From: "Yee, Peter" <[e-mail]>
To: "'Dr S N Henson'" <[e-mail]>, PKIX-List <[e-mail]>
Subject: RE: Q: Where should do I put a max amount in a X.509v3 certificat e?
Date: Mon, 11 Mar 2002 17:03:23 -0800
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>

Dr S N Henson wrote
>"Yee, Peter" wrote:

>> Sure, I'm glossing over the plethora of software that actually
>> supports ACs, but most of the other suggestions aren't implemented
>> either. :-)

>ACs might be more widely supported if a few public examples of them
>and their usage existed. I had a long search a while ago and couldn't
>find a single sample.

Working on it.  You didn't think I posted my attribute certificate drafts
for fun, did you. :-)

						-Peter Yee
						[e-mail]



Received: by above.proper.com (8.11.6/8.11.3) id g2BNiY002140 for ietf-pkix-bks; Mon, 11 Mar 2002 15:44:34 -0800 (PST)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2BNiW802135 for <[e-mail]>; Mon, 11 Mar 2002 15:44:32 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Mon, 11 Mar 2002 15:43:39 -0800 (PST)
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, 11 Mar 2002 15:43:39 -0800 (PST)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <GK1PP7VF>; Mon, 11 Mar 2002 15:44:29 -0800
Content-return: allowed
Date: Mon, 11 Mar 2002 15:44:22 -0800
From: Peter Williams <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-acrmf-01.txt
To: "'Yee, Peter'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain;	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>

http://www.ietf.org/internet-drafts/draft-ietf-pkix-ac509prof-09.txt

describes a set of AC verification rules, when an AC chain
has one element.

X.509 16.1 defines the "basic path processing" requirements
for processing "a single AC". X.509 16 is clear that 16.1
is REQUIRED for the case of processing a single AC.

Peter, a question (Q): What is the relationship between 
"privilege policy" (as used in X.509 16.1) and ACPROF section 
5 "Attribute Certificate validation?"

I dont believe profiles can remove the X.509 requirement
to follow X.509 16.1 when validating an AC. As ACPROF makes no 
mention of privilege policy, we have to assume that
X.509 16.1 controls, and that conforming implementations
MUST implement the privilege policy enforcement
requirements.

A reasonable answer to the question (Q) is that 
"validating right-to-use" a privilege is not the same 
thing as "validating an AC" - even though these two ideas 
are intertwined in the international standard, section 16.1.
Hence, privilege policy matters fall outside the scope of ACPROF
and IETF.

If this latter case is your thinking, then of course
designers of conforming implementations must
look to X509 for control when validating actual 
privilege *assertion* at privilege "use" time.

If we could clearup that ACPROF does not control
validation of privilege *assertion*, this would
be valuable. Privlege assertion within a lifetime 
is of course what matters and what makes ACs 
viable. Validating the privilege assertion 
can of course be critically important to
the application's security policy.

Peter.


-----Original Message-----
From: Yee, Peter [mailto:[e-mail]]
Sent: Monday, March 11, 2002 2:23 PM
To: '[e-mail]'
Cc: '[e-mail]'
Subject: RE: I-D ACTION:draft-ietf-pkix-acrmf-01.txt



>I recognize that [ACPROF], the Internet Attribute Certificate Profile, does
>not currently recommend the use of delegation and AC chains as specified in
>the X.509 standard [X.509-2000], however I would hope that your Internet
>Draft [ACRMF] on Attribute Certificate Request Message Format will not
>preclude it.

Yes, I would call that an oversight on my part.  I have to admit that
sometimes I think of ACs within the limited scope of ACPROF.
 


Received: by above.proper.com (8.11.6/8.11.3) id g2BNg6w02071 for ietf-pkix-bks; Mon, 11 Mar 2002 15:42:06 -0800 (PST)
Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2BNg4802067 for <[e-mail]>; Mon, 11 Mar 2002 15:42:04 -0800 (PST)
Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=gemplus.com) by anchor-post-31.mail.demon.net with esmtp (Exim 3.35 #1) id 16kZQc-000B7z-0V for [e-mail]; Mon, 11 Mar 2002 23:42:06 +0000
Message-ID: <[e-mail]>
Date: Mon, 11 Mar 2002 23:47:19 +0000
From: Dr S N Henson <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: PKIX-List <[e-mail]>
Subject: Re: Q: Where should do I put a max amount in a X.509v3 certificate?
References: <D516C97A440DD31197640008C7EBBE4701B27E0F@EXRSA02>
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>

"Yee, Peter" wrote:
> 
> Sure, I'm glossing over the plethora of software that actually
> supports ACs, but most of the other suggestions aren't implemented
> either. :-)
> 

ACs might be more widely supported if some a few public examples of them
and their usage existed. I had a long search a while ago and couldn't
find a single sample. 

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [e-mail] 
Senior crypto engineer, Gemplus: http://www.gemplus.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 g2BMPtN00171 for ietf-pkix-bks; Mon, 11 Mar 2002 14:25:55 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g2BMPr800167 for <[e-mail]>; Mon, 11 Mar 2002 14:25:53 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 11 Mar 2002 22:25:25 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id RAA00479 for <[e-mail]>; Mon, 11 Mar 2002 17:25:28 -0500 (EST)
Received: from exrsa01.rsa.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g2BMPte11425 for <[e-mail]>; Mon, 11 Mar 2002 17:25:55 -0500 (EST)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2653.19) id <FVAZDD0B>; Mon, 11 Mar 2002 14:25:54 -0800
Message-ID: <D516C97A440DD31197640008C7EBBE4701B27E2A@EXRSA02>
From: "Yee, Peter" <[e-mail]>
To: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-acmc-01.txt
Date: Mon, 11 Mar 2002 14:32:22 -0800
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>

I promised Stephen Farrell that I would include a means to provide
functionality similar to LAAP in ACMC (issuing ACs according to
a pre-agreed policy).  The text for that change didn't make it into
the version I sent to the I-D reposter just before the deadline, so I'm
sending it to the list.  The following text replaces the last paragraph
in Section 4.3 (Attribute Modification Handling Control Attribute):

       When attributes are to be issued according to a given profile or
       policy, the requester MAY send requested attributes and their
       values or omit them.  If values are supplied, the AA may modify
       these values within the bounds of the policy.  If the attributes
       are omitted in the request, the AA supplies a permissible set of
       attributes and values as dictated by the policy.  If the policy
       identifier (attrModPolicy) is not explicitly noted, then the
       policy is taken to be a pre-agreed default policy.

I also made the policy identifier OPTIONAL in order to support this mode.

As always, comments are welcome.

						-Peter Yee
						[e-mail]

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]]
>Sent: Thursday, March 07, 2002 3:58 AM
>Cc: [e-mail]
>Subject: I-D ACTION:draft-ietf-pkix-acmc-01.txt
>
>
>A New Internet-Draft is available from the on-line 
>Internet-Drafts directories.
>This draft is a work item of the Public-Key Infrastructure 
>(X.509) Working Group of the IETF.
>
>	Title		: Attribute Certificate Management 
>Messages over CMS
>	Author(s)	: P. Yee
>	Filename	: draft-ietf-pkix-acmc-01.txt
>	Pages		: 10
>	Date		: 06-Mar-02
>	
>This document specifies modifications to the Certificate Management
>Messages over CMS specification ([CMCbis]) to permit the management
>of attribute certificates.  This document does not stand alone, but
>must be used in conjunction with [CMCbis].  It is expected that the
>modifications proposed here will also be used in conjunction with the
>Attribute Certificate Request Message Format specification ([ACRMF]).
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-pkix-acmc-01.txt
>
>To remove yourself from the IETF Announcement list, send a message to 
>ietf-announce-request with the word unsubscribe in the body of 
>the message.
>
>Internet-Drafts are also available by anonymous FTP. Login 
>with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>	"get draft-ietf-pkix-acmc-01.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html 
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>	[e-mail].
>In the body type:
>	"FILE /internet-drafts/draft-ietf-pkix-acmc-01.txt".
>	
>NOTE:	The mail server at ietf.org can return the document in
>	MIME-encoded form by using the "mpack" utility.  To use this
>	feature, insert the command "ENCODING mime" before the "FILE"
>	command.  To decode the response(s), you will need "munpack" or
>	a MIME-compliant mail reader.  Different MIME-compliant 
>mail readers
>	exhibit different behavior, especially when dealing with
>	"multipart" MIME messages (i.e. documents which have been split
>	up into multiple messages), so check your local documentation on
>	how to manipulate these messages.
>		
>		
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>


Received: by above.proper.com (8.11.6/8.11.3) id g2BMGMp29788 for ietf-pkix-bks; Mon, 11 Mar 2002 14:16:22 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g2BMGK829783 for <[e-mail]>; Mon, 11 Mar 2002 14:16:20 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 11 Mar 2002 22:15:52 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id RAA29653; Mon, 11 Mar 2002 17:15:56 -0500 (EST)
Received: from exrsa01.rsa.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g2BMGMf10352; Mon, 11 Mar 2002 17:16:22 -0500 (EST)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2653.19) id <FVAZDD9G>; Mon, 11 Mar 2002 14:16:20 -0800
Message-ID: <D516C97A440DD31197640008C7EBBE4701B27E29@EXRSA02>
From: "Yee, Peter" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-acrmf-01.txt
Date: Mon, 11 Mar 2002 14:22:49 -0800
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>

>I recognize that [ACPROF], the Internet Attribute Certificate Profile, does
>not currently recommend the use of delegation and AC chains as specified in
>the X.509 standard [X.509-2000], however I would hope that your Internet
>Draft [ACRMF] on Attribute Certificate Request Message Format will not
>preclude it.

Yes, I would call that an oversight on my part.  I have to admit that
sometimes I think of ACs within the limited scope of ACPROF.

>More specifically, to not preclude this I would suggest that Section 5.2 on
>the "OldCert ID Control" should not just be specifying the certificate to
be
>replaced, but in addition it should able to be used to specify the higher
>certificate in the AC chain from which privileges are delegated.  This
would
>then ensure that delegation through an AA is also supported in the future.

>What do you think?

Sounds feasible to me.  Do you have a proposed syntax, or would something
like
a pair of certificates (old certificate and "delegator" suffice)?  [I'm sure
Phil G. will pop in here now with some proper syntax. :-)]

							-Peter Yee
							[e-mail]

>Feel free to distribute this comment and your response on the mailing list
>since I am not currently a member of the PKIX list, but only monitor its
>status on the web site.
>
>Best regards,
>
>Francois
>---------------------------------
>Francois Rousseau
>IT Standards, Senior Advisor - CSE
>Conseiller Superieur, Normes TI - CST
>[e-mail]
>[phone]
>Edward Drake Building
>1500 Bronson, Ottawa, Ontario, K1G 3Z4


Received: by above.proper.com (8.11.6/8.11.3) id g2BLwSZ29088 for ietf-pkix-bks; Mon, 11 Mar 2002 13:58:28 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g2BLwL829081 for <[e-mail]>; Mon, 11 Mar 2002 13:58:26 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 11 Mar 2002 21:57:53 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA28154; Mon, 11 Mar 2002 16:57:57 -0500 (EST)
Received: from exrsa01.rsa.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g2BLwNK08328; Mon, 11 Mar 2002 16:58:23 -0500 (EST)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2653.19) id <FVAZDD8H>; Mon, 11 Mar 2002 13:58:21 -0800
Message-ID: <D516C97A440DD31197640008C7EBBE4701B27E28@EXRSA02>
From: "Yee, Peter" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Q: Where should do I put a max amount in a X.509v3 certificat e?
Date: Mon, 11 Mar 2002 14:04:50 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g2BLwQ829085
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have to agree with Michael on this point -- although we're having an
interesting discussion on the technical means by which a purchase limit
can be accomplished, if we're getting down to the case at hand, Roberto
needs to specify many things, among them:

   o  Is the limit delegated?
   o  By whom?
   o  Does the lifetime in which the limit may be used correspond to
      the lifetime of the PKC of the "user" of the purchase limit, or
      to some other period?
   o  Does the purchase limit need to be understood within an open or
      closed community?
   o  Is the CA authoritative for more than name-to-key bindings?

I'm sure there are other questions to ask.  Without answering them, we're
sort of stuck talking in generalized terms.

						-Peter Yee
						[e-mail]

>From: Michael Ströder [mailto:[e-mail]]
>Sent: Monday, March 11, 2002 6:55 AM
>Subject: Re: Q: Where should do I put a max amount in a X.509v3
certificate?
>
>I'd suggest to thoroughly discuss a business model first before thinking 
>about technical aspects (not on PKIX list off course). From some discussion

>I remember that most drafts for something like this just didn't fit into
how 
>financial institutions are working (although the institutions were
committed 
>to use this particular PKI ;-).
>
>So defining technical specifications was completely useless because there 
>was no working business model behind it.

>Ciao, Michael.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2BLpO928933 for ietf-pkix-bks; Mon, 11 Mar 2002 13:51:24 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g2BLpM828929 for <[e-mail]>; Mon, 11 Mar 2002 13:51:22 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 11 Mar 2002 21:50:54 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA27463; Mon, 11 Mar 2002 16:50:56 -0500 (EST)
Received: from exrsa01.rsa.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g2BLpMW07371; Mon, 11 Mar 2002 16:51:23 -0500 (EST)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2653.19) id <FVAZDD7Y>; Mon, 11 Mar 2002 13:51:21 -0800
Received: from sdtihq24.securid.com (sdtihq24.securitydynamics.com [192.80.211.5]) by exrsa01.rsa.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FVAZDDD3; Mon, 11 Mar 2002 08:54:58 -0800
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA28805 for <[e-mail]>; Mon, 11 Mar 2002 11:48:01 -0500 (EST)
Received: from vulcani.rsasecurity.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with SMTP id g2BGmOw27108 for <[e-mail]>; Mon, 11 Mar 2002 11:48:25 -0500 (EST)
Received: from [131.136.196.7] by vulcani.rsasecurity.com via smtpd (for [192.80.211.4]) with SMTP; 11 Mar 2002 16:47:53 UT
From: "Yee, Peter" <[e-mail]>
To: "PKIX (Grupo de la IETF)" <[e-mail]>
Cc: [e-mail]
Message-ID: <[e-mail]>
Subject: RE: Q: Where should do I put a max amount in a X.509v3 certificat e?
Date: Mon, 11 Mar 2002 11:48:30 -0500
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>

Since this topic is generating a fair number or interesting responses, I'm
forwarding this message from Francois Rousseau to the list.  Make sure you
include him on any response so he gets a direct copy of the e-mail (he's
not currently subscribed to PKIX).  Thanks.

							-Peter Yee
							[e-mail]

----------------------------------------------------------------------------

Tom,

I totally agree with Peter's suggestion on this one since this was the whole
reason for adding the Signing Certificate Attribute within the Enhanced
Security Services for S/MIME [RFC2634].  It was meant to bound an attribute
certificate to a signed transaction as required here by Roberto.  If the
authorized max amount will change more often than the private signing key of
the individual, than attribute certificates are certainly more interesting
than the using a policy qualifier, private extension, or the subject
directory attribute.

Feel free to distribute this comment and your response on the mailing list
since I am not currently a member of the PKIX list, but only monitor its
status on the web site.

Regards,

Francois
---------------------------------
Francois Rousseau
IT Standards, Senior Advisor - CSE
Conseiller Superieur, Normes TI - CST
[e-mail]
[phone]
Edward Drake Building
1500 Bronson, Ottawa, Ontario, K1G 3Z4


> From: "Tom Gindin" <[e-mail]>
>
>      Peter:
>
>      Since this "purchase limit" is intended as a constraint on signed
> orders, and those are signed by PKC's rather than AC's, the constraint
> needs to go into the PKC.  I also don't think the syntax is very complex
> (currency designator and amount - the only choice you need to make is
> whether to encode amount as Numeric String, Integer, or Real).
> PolicyQualifier would make the most sense if it weren't for the conflict
> between the existing use of criticality in CertificatePolicies and its use
> for this feature.  If PolicyQualifiers are to remain deprecated for uses
> like these, IMHO the only places for these to go are a new extension or
> SubjectAltName OTHER-NAME, and it really isn't a naming attribute.
>       Does profiling a new extension in new-part1 make sense?
>
>            Tom Gindin
>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2BLfA128641 for ietf-pkix-bks; Mon, 11 Mar 2002 13:41:10 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g2BLf8828637 for <[e-mail]>; Mon, 11 Mar 2002 13:41:08 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 11 Mar 2002 21:40:40 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA26379; Mon, 11 Mar 2002 16:40:43 -0500 (EST)
Received: from exrsa01.rsa.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g2BLf9X05928; Mon, 11 Mar 2002 16:41:10 -0500 (EST)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2653.19) id <FVAZDD7D>; Mon, 11 Mar 2002 13:47:38 -0800
Message-ID: <D516C97A440DD31197640008C7EBBE4701B27E26@EXRSA02>
From: "Yee, Peter" <[e-mail]>
To: "'Tom Gindin'" <[e-mail]>
Cc: "PKIX (Grupo de la IETF)" <[e-mail]>
Subject: RE: Q: Where should do I put a max amount in a X.509v3 certificat e?
Date: Mon, 11 Mar 2002 13:47:36 -0800
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>

Tom,
	I wasn't suggesting that complexity was the hangup in implementing
a purchase limit in either PKCs or ACs -- simply that most commercial
products don't deal with many "unusual" extensions.

	I'll also agree with others who note that tying a hard limit in
to an identity certificate is likely to result in expiration of these
certificates unless used in very constained cases -- those with limits
that don't change and where the authorization to use those limits matches
the lifetime of the identity certificate.  Those constraints seem
artificially
narrow to me.  Certainly, if you can find an application that works within
those limits (and others), then putting the purchase limit in the PKC has
its
merits.

						-Peter

>From: Tom Gindin [mailto:[e-mail]]
>Sent: Monday, March 11, 2002 4:33 AM
>Subject: RE: Q: Where should do I put a max amount in a X.509v3
certificate?
>
>
>
>      Peter:
>
>      Since this "purchase limit" is intended as a constraint on signed
>orders, and those are signed by PKC's rather than AC's, the constraint
>needs to go into the PKC.  I also don't think the syntax is very complex
>(currency designator and amount - the only choice you need to make is
>whether to encode amount as Numeric String, Integer, or Real).
>PolicyQualifier would make the most sense if it weren't for the conflict
>between the existing use of criticality in CertificatePolicies and its use
>for this feature.  If PolicyQualifiers are to remain deprecated for uses
>like these, IMHO the only places for these to go are a new extension or
>SubjectAltName OTHER-NAME, and it really isn't a naming attribute.
>      Does profiling a new extension in new-part1 make sense?
>
>            Tom Gindin>


Received: by above.proper.com (8.11.6/8.11.3) id g2BLUW528317 for ietf-pkix-bks; Mon, 11 Mar 2002 13:30:32 -0800 (PST)
Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2BLUU828309; Mon, 11 Mar 2002 13:30:30 -0800 (PST)
Received: from arport (t4o69p52.telia.com [62.20.145.172]) by maile.telia.com (8.11.6/8.11.6) with SMTP id g2BLQNu01634; Mon, 11 Mar 2002 22:26:23 +0100 (CET)
Message-ID: <001b01c1c943$2a692450$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: "PKIX \(Grupo de la IETF\)" <[e-mail]>, <[e-mail]>, "Yee, Peter" <[e-mail]>, "Roberto Opazo Gazmuri" <[e-mail]>, "Tom Gindin" <[e-mail]>, "'Tim Polk'" <[e-mail]>
References: <[e-mail]>
Subject: Re: Q: Where should do I put a max amount in a X.509v3 certificat	e?
Date: Mon, 11 Mar 2002 22:24:43 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Lynn,
Your posting supports my general belief that it does not make much sense to put any
"information" in a PKC except for the bare-bones minimum needed to identify the entity.
This is why "employee certificates" is an equally problematic idea, as putting transaction
limits in certificates.  Employment data changes quickly, your identity does not.

Anders


----- Original Message -----
From: <[e-mail]>
To: <[e-mail]>
Cc: "PKIX (Grupo de la IETF)" <[e-mail]>; <[e-mail]>; "Yee, Peter" <[e-mail]>; "Roberto
Opazo Gazmuri" <[e-mail]>; "Tom Gindin" <[e-mail]>; "'Tim Polk'" <[e-mail]>
Sent: Monday, March 11, 2002 19:03
Subject: Re: Q: Where should do I put a max amount in a X.509v3 certificat e?




I believe that the "purchase limit" idea was to emulate the "signing limit"
checks of, at least pre-80s (if not earlier) ... effectively having some
value to limit various kinds of fraud and exploits in an offline
transaction environment.

Sometime in the '60s, they started to discover these type of controls was
being circumvented by things like multiple operations ... and so started
the migration to online transactions that could support aggregation,
velocity, rate, etc. Moving to an online transaction paradigm in the '70s &
'80s  (real time, aggregation, velocity, rate, etc) started to make the
offline, credential "signing limit" paradigm redundant and superfulous.



[e-mail] on 3/11/2002 7:10 am wrote:


Tom,

>       Since this "purchase limit" is intended as a constraint on signed
> orders, and those are signed by PKC's rather than AC's, the constraint
> needs to go into the PKC.

That's wrong (even ignoring the careless language). The requirement is
presumably that the amount is somehow attested to by an authority.
That doesn't distinguish an AC-based from a PKC-based solution.

>       Does profiling a new extension in new-part1 make sense?

IMO, No - and not until there'll be a *lot* of RP s/w that pays
attention.

Stephen.


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








Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2BLPac28166 for ietf-pkix-bks; Mon, 11 Mar 2002 13:25:36 -0800 (PST)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2BLPZ828161 for <[e-mail]>; Mon, 11 Mar 2002 13:25:35 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Mon, 11 Mar 2002 13:24:41 -0800 (PST)
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, 11 Mar 2002 13:24:41 -0800 (PST)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <GK1PP67K>; Mon, 11 Mar 2002 13:25:31 -0800
Content-return: allowed
Date: Mon, 11 Mar 2002 13:25:29 -0800
From: Peter Williams <[e-mail]>
Subject: RE: Q: Where should do I put a max amount in a X.509v3 certificat	e?
To: "Yee, Peter" <[e-mail]>
Cc: "PKIX (Grupo de la IETF)" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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>

In practice, people are modifying the PK-cert borne
authorization via the OCSP response, whose extension 
contains a form of (unsigned) AC. Once AC syntax becomes
popular, the trend will be to express the
privilege in AC syntax, rather than adhoc. For
now, folks need something that works. As cert
validation need not use any source of revocation
notices, one needs base authorization in
the PK cert, and a properly defined privilege
scheme that controls how one processes privileges
from two sources, one of which is the PK cert. (essentially, 
follow the X.509 rules on controlling privlege delegation, when
using the PK cert's subjectDirectoryAttributes for 
base privilege expression)

-----Original Message-----
From: Michael Myers [mailto:[e-mail]]
Sent: Monday, March 11, 2002 12:17 PM
To: Tom Gindin; [e-mail]
Cc: Yee, Peter; 'Tim Polk'; Roberto Opazo Gazmuri; PKIX (Grupo de la
IETF)
Subject: RE: Q: Where should do I put a max amount in a X.509v3
certificat e?



Tom, all:

Perhaps the following design principle is well understood but in
the context of this thread I think it bears repeating.  Namely,
the more authorization type attributes bound into a PK cert, the
more likely that PK cert will be revoked prior to its
expiration.  Hence ACs.

Mike


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2BKkj527227 for ietf-pkix-bks; Mon, 11 Mar 2002 12:46:45 -0800 (PST)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com ([204.124.248.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2BKkh827216 for <[e-mail]>; Mon, 11 Mar 2002 12:46:43 -0800 (PST)
Subject: Re: Q: Where should do I put a max amount in a X.509v3 certificate?
To: Dale Gustafson <[e-mail]>
Cc: "PKIX (Grupo de la IETF)" <[e-mail]>, [e-mail], "Yee, Peter" <[e-mail]>, Roberto Opazo Gazmuri <[e-mail]>, "'Tim Polk'" <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Mon, 11 Mar 2002 13:44:26 -0700
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 03/11/2002 03:44:20 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>

not just a matter of churning the certificate credential as the "signing
limit" is changed .... but also a return to pre-80s offline transactions
where there is no aggregation (month to date, qtr to date, year to date),
velocity, rate, acceleration, SKU-based limits (pencils, gasoline, tires,
computers), MCC-based limits, etc.

... aka even simple credit limit or daily limit ... isn't single
transaction value but aggregation of transactions.

credential/certificate limits like checks with signing value limits was
old-fashion, offline, non-electronic solution ... but much of the
infrastructure has moved to online with minimum of simple real-time
aggregation making the old fashion offline credential/certificate limits
superfulous and redundant.

random refs:
http://www.garlic.com/~lynn/aadsmail.htm#fraud Human Nature ... a little
cross-posting
http://www.garlic.com/~lynn/aadsmail.htm#law dbts: More on law vs economics
http://www.garlic.com/~lynn/aadsmore.htm#hcrl3 Huge CRLs
http://www.garlic.com/~lynn/aadsmore.htm#killer1 Killer PKI Applications
http://www.garlic.com/~lynn/aadsm3.htm#kiss7 KISS for PKIX. (Was: RE: ASN.1
vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm4.htm#01 superfulous & redundant (addenda)
http://www.garlic.com/~lynn/aadsm5.htm#spki4 Simple PKI
http://www.garlic.com/~lynn/aadsm6.htm#ppsem3 Payment Processing Seminars
http://www.garlic.com/~lynn/aadsm6.htm#pcards2 The end of P-Cards?
(addenda)
http://www.garlic.com/~lynn/aadsm7.htm#auth Who or what to authenticate?
http://www.garlic.com/~lynn/aadsm7.htm#auth2 Who or what to authenticate?
(addenda)
http://www.garlic.com/~lynn/aadsm9.htm#cfppki3 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm9.htm#cfppki4 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm9.htm#cfppki8 CFP: PKI research workshop
http://www.garlic.com/~lynn/aepay6.htm#pkimort2 problem with the death of
X.509 PKI (forwarded)
http://www.garlic.com/~lynn/aepay10.htm#8 FSTC to Validate WAP 1.2.1
Specification for Mobile Commerce
http://www.garlic.com/~lynn/2000.html#37 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/99.html#228 Attacks on a PKI
http://www.garlic.com/~lynn/99.html#238 Attacks on a PKI
http://www.garlic.com/~lynn/aadsm10.htm#limit Q: Where should do I put a
max amount in a X.509v3 certificat e?



[e-mail] on 3/11/2002 8:26 am wrote:


Hi Peter,

Actually, similar things are suggested in "Planning for PKI, Best
Practices for deploying the PKI" by Russ Housley and Tim Polk -- see the
section subtitled "Attribute Certificates", pp 274 - 277.  Note that the
entire chapter is titled "Future Developments" so, presumably, one needs
to proceed with appropriate caution.

In any event, the rationale for placing such an attribute within a
separate Attribute Certificate is clearly spelled out:

1) a Certification Authority is most likely "not authoritative" for this
kind of information

2) this kind of information is also likely to change frequently which
would cause highly undesirable certificate churn if included in x.509 v3
ID certificates.

In contrast, an application-specific attribute could be certified by an
authoritative AA and carried in an Attribute Certificate.  The AC is
defined as an extension of a suitable ID certificate.  Such would be
necessary but perhaps not sufficient for general use of ACs to convey
application-specific user priviledges.  For example, since much attribute
information is not disclosed outside a well-defined group of relying
parties, there would also need to be a (general purpose?) mechanism to
limit access to AC information exchanged.

Best Regards,

Dale Gustafson






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2BKKrw26447 for ietf-pkix-bks; Mon, 11 Mar 2002 12:20:53 -0800 (PST)
Received: from geos.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2BKKp826443 for <[e-mail]>; Mon, 11 Mar 2002 12:20:51 -0800 (PST)
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 g2BKK2b19436; Mon, 11 Mar 2002 12:20:02 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "Tom Gindin" <[e-mail]>, <[e-mail]>
Cc: "Yee, Peter" <[e-mail]>, "'Tim Polk'" <[e-mail]>, "Roberto Opazo Gazmuri" <[e-mail]>, "PKIX \(Grupo de la IETF\)" <[e-mail]>
Subject: RE: Q: Where should do I put a max amount in a X.509v3 certificat	e?
Date: Mon, 11 Mar 2002 12:17:29 -0800
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>

Tom, all:

Perhaps the following design principle is well understood but in
the context of this thread I think it bears repeating.  Namely,
the more authorization type attributes bound into a PK cert, the
more likely that PK cert will be revoked prior to its
expiration.  Hence ACs.

Mike



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2BJvEh25619 for ietf-pkix-bks; Mon, 11 Mar 2002 11:57:14 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g2BJv8825607 for <[e-mail]>; Mon, 11 Mar 2002 11:57:08 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 11 Mar 2002 19:56:40 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA16719; Mon, 11 Mar 2002 14:56:43 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g2BJv9k22543; Mon, 11 Mar 2002 14:57:09 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <GNRVJCD2>; Mon, 11 Mar 2002 14:54:55 -0500
Message-ID: <[e-mail]>
From: "Housley, Russ" <[e-mail]>
To: "'Tom Gindin '" <[e-mail]>, "Yee, Peter" <[e-mail]>
Cc: "''Tim Polk' '" <[e-mail]>, "'Roberto Opazo Gazmuri '" <[e-mail]>, "'PKIX (Grupo de la IETF) '" <[e-mail]>
Subject: RE: Q: Where should do I put a max amount in a X.509v3 certificat e?
Date: Mon, 11 Mar 2002 14:56:51 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
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>

Money is very complicated.  We should not try to invent our own syntax to
specify monetary amounts.  I suggest we steal one that is already in use:

     -- CurrencyAmount specifies the currency and a monetary value.
     -- Currency codes are defined in ISO 4217.  The monetary value
     -- is: amount * (10 ** amtExp10), and the exponent MUST be the
     -- minor unit of currency specified in ISO 4217.

     CurrencyAmount  ::=  SEQUENCE  {
       currency             INTEGER (1..999),
       amount               INTEGER (0..MAX),
       amtExp10             INTEGER (0..MAX)  }

Russ 

-----Original Message-----
From: Tom Gindin
To: Yee, Peter
Cc: 'Tim Polk'; Roberto Opazo Gazmuri; PKIX (Grupo de la IETF)
Sent: 3/11/02 7:32 AM
Subject: RE: Q: Where should do I put a max amount in a X.509v3 certificat
e?



      Peter:

      Since this "purchase limit" is intended as a constraint on signed
orders, and those are signed by PKC's rather than AC's, the constraint
needs to go into the PKC.  I also don't think the syntax is very complex
(currency designator and amount - the only choice you need to make is
whether to encode amount as Numeric String, Integer, or Real).
PolicyQualifier would make the most sense if it weren't for the conflict
between the existing use of criticality in CertificatePolicies and its
use
for this feature.  If PolicyQualifiers are to remain deprecated for uses
like these, IMHO the only places for these to go are a new extension or
SubjectAltName OTHER-NAME, and it really isn't a naming attribute.
      Does profiling a new extension in new-part1 make sense?

            Tom Gindin


"Yee, Peter" <[e-mail]>@mail.imc.org on 03/08/2002 02:45:51
PM

Sent by:    [e-mail]


To:    "'Tim Polk'" <[e-mail]>, Roberto Opazo Gazmuri
       <[e-mail]>
cc:    "PKIX (Grupo de la IETF)" <[e-mail]>
Subject:    RE: Q: Where should do I put a max amount in a X.509v3
       certificat e?



Tim suggests using a policy qualifier, private extension, or
subject directory attribute.  (And OCSP, with which I really have
to disagree respectfully).  I'll offer another alternative: attribute
certificates.  These seem to be a natural fit and were suggested for
just such a purpose.

Sure, I'm glossing over the plethora of software that actually
supports ACs, but most of the other suggestions aren't implemented
either. :-)


-Peter Yee

[e-mail]






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2BJ2ou21976 for ietf-pkix-bks; Mon, 11 Mar 2002 11:02:50 -0800 (PST)
Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2BJ2n821968 for <[e-mail]>; Mon, 11 Mar 2002 11:02:49 -0800 (PST)
Received: from tsg1 ([12.81.86.57]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020311190245.YCGT13933.mtiwmhc22.worldnet.att.net@tsg1>; Mon, 11 Mar 2002 19:02:45 +0000
Message-ID: <00e101c1c92f$533b84e0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: <[e-mail]>
Cc: "LISTS - IETF-PKIX" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: Q: Where should do I put a max amount in a X.509v3 certificate?
Date: Mon, 11 Mar 2002 11:02:42 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I would propose that there are a number of simple functions or
representational Data Structures to represent these various things missing
from PKIX.  Further that this WG has a number of common points of service or
functionality between a number of protocols and that for whatever reason
that have been ignored till now.

What I suggest that we need is a standard form of:

    1)    representing a light-weight token that can convey a statement as
to policy or indemnity limits

    2)    representing a token that in and of itself is cash or can carry
cash

    3)    representing status of a verification event. - This would be a
common calling form and return messaging for all PKIX routines. Maybe
something like a CDSA top-end for the PKIX protocols.

Todd

----- Original Message -----
From: "Michael Ströder" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, March 11, 2002 6:55 AM
Subject: Re: Q: Where should do I put a max amount in a X.509v3 certificate?


>
> Tom Gindin wrote:
> >
> >       Since this "purchase limit" is intended as a constraint on signed
> > orders, and those are signed by PKC's rather than AC's, the constraint
> > needs to go into the PKC.  I also don't think the syntax is very complex
>
> I'd suggest to thoroughly discuss a business model first before thinking
> about technical aspects (not on PKIX list off course). From some
discussion
> I remember that most drafts for something like this just didn't fit into
how
> financial institutions are working (although the institutions were
committed
> to use this particular PKI ;-).
>
> So defining technical specifications was completely useless because there
> was no working business model behind it.
>
> Ciao, Michael.
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2BI6fr19899 for ietf-pkix-bks; Mon, 11 Mar 2002 10:06:41 -0800 (PST)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com ([204.124.248.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2BI6d819894 for <[e-mail]>; Mon, 11 Mar 2002 10:06:39 -0800 (PST)
Subject: Re: Q: Where should do I put a max amount in a X.509v3 certificat	e?
To: [e-mail]
Cc: "PKIX (Grupo de la IETF)" <[e-mail]>, [e-mail], "Yee, Peter" <[e-mail]>, Roberto Opazo Gazmuri <[e-mail]>, Tom Gindin <[e-mail]>, "'Tim Polk'" <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Mon, 11 Mar 2002 11:03:32 -0700
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 03/11/2002 01:04:16 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>

I believe that the "purchase limit" idea was to emulate the "signing limit"
checks of, at least pre-80s (if not earlier) ... effectively having some
value to limit various kinds of fraud and exploits in an offline
transaction environment.

Sometime in the '60s, they started to discover these type of controls was
being circumvented by things like multiple operations ... and so started
the migration to online transactions that could support aggregation,
velocity, rate, etc. Moving to an online transaction paradigm in the '70s &
'80s  (real time, aggregation, velocity, rate, etc) started to make the
offline, credential "signing limit" paradigm redundant and superfulous.



[e-mail] on 3/11/2002 7:10 am wrote:


Tom,

>       Since this "purchase limit" is intended as a constraint on signed
> orders, and those are signed by PKC's rather than AC's, the constraint
> needs to go into the PKC.

That's wrong (even ignoring the careless language). The requirement is
presumably that the amount is somehow attested to by an authority.
That doesn't distinguish an AC-based from a PKC-based solution.

>       Does profiling a new extension in new-part1 make sense?

IMO, No - and not until there'll be a *lot* of RP s/w that pays
attention.

Stephen.


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






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2BHLVl18319 for ietf-pkix-bks; Mon, 11 Mar 2002 09:21:31 -0800 (PST)
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 g2BHLT818312 for <[e-mail]>; Mon, 11 Mar 2002 09:21:30 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.us.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA35570 for <[e-mail]>; Mon, 11 Mar 2002 12:18:07 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g2BHLNF35738 for <[e-mail]>; Mon, 11 Mar 2002 12:21:23 -0500
Importance: Normal
Sensitivity: 
Subject: RE: Q: Where should do I put a max amount in a X.509v3 certificat	e?
To: [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Mon, 11 Mar 2002 12:21:22 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.9a |January 28, 2002) at 03/11/2002 12:21:25 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>

      The following contribution to this discussion is being posted on
behalf of Francois Rousseau.

---------------------- Forwarded by Tom Gindin/Watson/IBM on 03/11/2002
12:20 PM ---------------------------

[e-mail] on 03/11/2002 11:48:30 AM

To:    Tom Gindin/Watson/IBM@IBMUS
cc:    [e-mail], [e-mail], [e-mail],
       [e-mail]
Subject:    RE: Q: Where should do I put a max amount in a X.509v3
       certificat e?


Tom,

I totally agree with Peter's suggestion on this one since this was the
whole
reason for adding the Signing Certificate Attribute within the Enhanced
Security Services for S/MIME [RFC2634].  It was meant to bound an attribute
certificate to a signed transaction as required here by Roberto.  If the
authorized max amount will change more often than the private signing key
of
the individual, than attribute certificates are certainly more interesting
than the using a policy qualifier, private extension, or the subject
directory attribute.

Feel free to distribute this comment and your response on the mailing list
since I am not currently a member of the PKIX list, but only monitor its
status on the web site.

Regards,

Francois
---------------------------------
Francois Rousseau
IT Standards, Senior Advisor - CSE
Conseiller Superieur, Normes TI - CST
[e-mail]
[phone]
Edward Drake Building
1500 Bronson, Ottawa, Ontario, K1G 3Z4


> From: "Tom Gindin" <[e-mail]>
>
>      Peter:
>
>      Since this "purchase limit" is intended as a constraint on signed
> orders, and those are signed by PKC's rather than AC's, the constraint
> needs to go into the PKC.  I also don't think the syntax is very complex
> (currency designator and amount - the only choice you need to make is
> whether to encode amount as Numeric String, Integer, or Real).
> PolicyQualifier would make the most sense if it weren't for the conflict
> between the existing use of criticality in CertificatePolicies and its
use
> for this feature.  If PolicyQualifiers are to remain deprecated for uses
> like these, IMHO the only places for these to go are a new extension or
> SubjectAltName OTHER-NAME, and it really isn't a naming attribute.
>       Does profiling a new extension in new-part1 make sense?
>
>            Tom Gindin
>






Received: by above.proper.com (8.11.6/8.11.3) id g2BHKG818255 for ietf-pkix-bks; Mon, 11 Mar 2002 09:20:16 -0800 (PST)
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 g2BHKC818250 for <[e-mail]>; Mon, 11 Mar 2002 09:20:12 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.us.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA412320; Mon, 11 Mar 2002 12:16:41 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g2BHJtF56034; Mon, 11 Mar 2002 12:19:56 -0500
Importance: Normal
Sensitivity: 
Subject: Re: Q: Where should do I put a max amount in a X.509v3 certificat	e?
To: [e-mail]
Cc: "Yee, Peter" <[e-mail]>, "'Tim Polk'" <[e-mail]>, Roberto Opazo Gazmuri <[e-mail]>, "PKIX (Grupo de la IETF)" <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Mon, 11 Mar 2002 12:19:52 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.9a |January 28, 2002) at 03/11/2002 12:19:57 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>

      If the signed document is formatted using CMS or PKCS#7, there is no
defined AA with authority to set a limit such as this, while there is a CA.
Francois Rousseau, in a separate communication which will be posted to the
group as well, points out that RFC 2634's signingCertificate attribute can
bind a signature to an AC.  I think that the optional nature of that
attribute leaves the PKC as a preferable location.  In view of Juergen
Brauckman's posting, there is certainly no reason for any new objects to be
defined in conflict with ETSI's definitions.  The only other issue I can
see is whether there is any reason for non-QC's to have a separate
extension to carry monetaryLimit without incorporating the qcStatements
extension.

            Tom Gindin

Stephen Farrell <[e-mail]> on 03/11/2002 09:10:08 AM

Please respond to [e-mail]

To:    Tom Gindin/Watson/IBM@IBMUS
cc:    "Yee, Peter" <[e-mail]>, "'Tim Polk'"
       <[e-mail]>, Roberto Opazo Gazmuri <[e-mail]>, "PKIX
       (Grupo de la IETF)" <[e-mail]>
Subject:    Re: Q: Where should do I put a max amount in a X.509v3
       certificat e?



Tom,

>       Since this "purchase limit" is intended as a constraint on signed
> orders, and those are signed by PKC's rather than AC's, the constraint
> needs to go into the PKC.

That's wrong (even ignoring the careless language). The requirement is
presumably that the amount is somehow attested to by an authority.
That doesn't distinguish an AC-based from a PKC-based solution.

>       Does profiling a new extension in new-part1 make sense?

IMO, No - and not until there'll be a *lot* of RP s/w that pays
attention.

Stephen.


--
____________________________________________________________
Stephen Farrell

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






Received: by above.proper.com (8.11.6/8.11.3) id g2BGEG712659 for ietf-pkix-bks; Mon, 11 Mar 2002 08:14:16 -0800 (PST)
Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2BGEE812655 for <[e-mail]>; Mon, 11 Mar 2002 08:14:14 -0800 (PST)
Received: from fwd09.sul.t-online.de  by mailout11.sul.t-online.com with smtp  id 16kRDE-0000w1-06; Mon, 11 Mar 2002 15:55:44 +0100
Received: from junker.stroeder.com (520010731148-0001@[62.224.168.127]) by fmrl09.sul.t-online.com with esmtp id 16kRD2-0kQEueC; Mon, 11 Mar 2002 15:55:32 +0100
Received: from stroeder.com (junker [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id F30BA15754D for <[e-mail]>; Mon, 11 Mar 2002 15:55:22 +0100 (CET)
Message-ID: <[e-mail]>
Date: Mon, 11 Mar 2002 15:55:22 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
Reply-To: [e-mail]
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8+) Gecko/20020228
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
Cc: [e-mail]
Subject: Re: Q: Where should do I put a max amount in a X.509v3 certificate?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
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>

Tom Gindin wrote:
> 
>       Since this "purchase limit" is intended as a constraint on signed
> orders, and those are signed by PKC's rather than AC's, the constraint
> needs to go into the PKC.  I also don't think the syntax is very complex

I'd suggest to thoroughly discuss a business model first before thinking 
about technical aspects (not on PKIX list off course). From some discussion 
I remember that most drafts for something like this just didn't fit into how 
financial institutions are working (although the institutions were committed 
to use this particular PKI ;-).

So defining technical specifications was completely useless because there 
was no working business model behind it.

Ciao, Michael.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2BFNDw06627 for ietf-pkix-bks; Mon, 11 Mar 2002 07:23:13 -0800 (PST)
Received: from mnmai05.mn.mediaone.net (mnmai05.mn.ipsvc.net [24.131.1.59]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2BFNC806623 for <[e-mail]>; Mon, 11 Mar 2002 07:23:12 -0800 (PST)
Received: from mediaone.net (c-66-41-28-90.mn.client2.attbi.com [66.41.28.90]) by mnmai05.mn.mediaone.net (8.11.1/8.11.1) with ESMTP id g2BFNHb29648; Mon, 11 Mar 2002 10:23:17 -0500 (EST)
Message-ID: <[e-mail]>
Date: Mon, 11 Mar 2002 09:26:34 -0600
From: Dale Gustafson <[e-mail]>
X-Mailer: Mozilla 4.78 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Yee, Peter" <[e-mail]>
CC: "'Tim Polk'" <[e-mail]>, Roberto Opazo Gazmuri <[e-mail]>, "PKIX (Grupo de la IETF)" <[e-mail]>
Subject: Re: Q: Where should do I put a max amount in a X.509v3 certificate?
References: <D516C97A440DD31197640008C7EBBE4701B27E0F@EXRSA02>
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>

Hi Peter,

Actually, similar things are suggested in "Planning for PKI, Best
Practices for deploying the PKI" by Russ Housley and Tim Polk -- see the
section subtitled "Attribute Certificates", pp 274 - 277.  Note that the
entire chapter is titled "Future Developments" so, presumably, one needs
to proceed with appropriate caution.

In any event, the rationale for placing such an attribute within a
separate Attribute Certificate is clearly spelled out:

1) a Certification Authority is most likely "not authoritative" for this
kind of information

2) this kind of information is also likely to change frequently which
would cause highly undesirable certificate churn if included in x.509 v3
ID certificates.

In contrast, an application-specific attribute could be certified by an
authoritative AA and carried in an Attribute Certificate.  The AC is
defined as an extension of a suitable ID certificate.  Such would be
necessary but perhaps not sufficient for general use of ACs to convey
application-specific user priviledges.  For example, since much attribute
information is not disclosed outside a well-defined group of relying
parties, there would also need to be a (general purpose?) mechanism to
limit access to AC information exchanged.

Best Regards,

Dale Gustafson



"Yee, Peter" wrote:

> Tim suggests using a policy qualifier, private extension, or
> subject directory attribute.  (And OCSP, with which I really have
> to disagree respectfully).  I'll offer another alternative: attribute
> certificates.  These seem to be a natural fit and were suggested for
> just such a purpose.
>
> Sure, I'm glossing over the plethora of software that actually
> supports ACs, but most of the other suggestions aren't implemented
> either. :-)
>
>                                                 -Peter Yee
>                                                 [e-mail]



Received: by above.proper.com (8.11.6/8.11.3) id g2BFCbC06307 for ietf-pkix-bks; Mon, 11 Mar 2002 07:12:37 -0800 (PST)
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 g2BFCZ806302 for <[e-mail]>; Mon, 11 Mar 2002 07:12:35 -0800 (PST)
Received: from tsg1 ([12.81.86.57]) by mtiwmhc21.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020311151230.KZRT28073.mtiwmhc21.worldnet.att.net@tsg1>; Mon, 11 Mar 2002 15:12:30 +0000
Message-ID: <001901c1c90f$29dce780$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Juergen Brauckmann" <[e-mail]>, "Roberto Opazo Gazmuri" <[e-mail]>, "PKIX \(Grupo de la IETF\)" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: Q: Where should do I put a max amount in a X.509v3 certificat	e?
Date: Mon, 11 Mar 2002 07:12:28 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

So perhaps PKIX should embrace this structure as a basic method of
representing a monetary value.  The more we all come to structural agreement
about what our variously protocols are to do, the easier it will be to make
the interoperable.

Todd

>
> ETSI has an monetaryLimit statemtent for use with the qCStatement
> extension defined in RFC3039.
>
> The ETSI document id is "ETSI TS 101 862 V1.2.1". The document can be
> obtained from pda.etsi.org, but basically it goes like this:
>
> MonetaryValue::= SEQUENCE {
> currency Iso4217CurrencyCode,
> amount INTEGER,
> exponent INTEGER}
> -- value = amount * 10^exponent
>
> Iso4217CurrencyCode ::= CHOICE {
> alphabetic PrintableString (SIZE 3), -- Recommended
> numeric INTEGER (1..999) }
> -- Alphabetic or numeric currency code as defined in ISO 4217
> -- It is recommended that the Alphabetic form is used

The only thing it doesn't support is an internal "Policy Of Use" statement
or OID. That means that anything that uses this financial value designator
may need a larger container structure to contain the Policy

>
> Regards
>     Juergen



Received: by above.proper.com (8.11.6/8.11.3) id g2BEA8C00674 for ietf-pkix-bks; Mon, 11 Mar 2002 06:10:08 -0800 (PST)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2BEA3800670 for <[e-mail]>; Mon, 11 Mar 2002 06:10:04 -0800 (PST)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g2BEA2J03631 for <[e-mail]>; Mon, 11 Mar 2002 14:10:02 GMT
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]> for <[e-mail]>; Mon, 11 Mar 2002 14:05:00 +0000
Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id OAA23798; Mon, 11 Mar 2002 14:09:58 GMT
Message-ID: <[e-mail]>
Date: Mon, 11 Mar 2002 14:10:08 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Gindin <[e-mail]>
CC: "Yee, Peter" <[e-mail]>, "'Tim Polk'" <[e-mail]>, Roberto Opazo Gazmuri <[e-mail]>, "PKIX (Grupo de la IETF)" <[e-mail]>
Subject: Re: Q: Where should do I put a max amount in a X.509v3 certificat	e?
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>

Tom,

>       Since this "purchase limit" is intended as a constraint on signed
> orders, and those are signed by PKC's rather than AC's, the constraint
> needs to go into the PKC.  

That's wrong (even ignoring the careless language). The requirement is
presumably that the amount is somehow attested to by an authority.
That doesn't distinguish an AC-based from a PKC-based solution.

>       Does profiling a new extension in new-part1 make sense?

IMO, No - and not until there'll be a *lot* of RP s/w that pays 
attention.

Stephen.


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


Received: by above.proper.com (8.11.6/8.11.3) id g2BE3NT00561 for ietf-pkix-bks; Mon, 11 Mar 2002 06:03:23 -0800 (PST)
Received: from mystic2.trustcenter.de (mystic2.trustcenter.de [193.194.157.50]) by above.proper.com (8.11.6/8.11.3) with SMTP id g2BE3K800557 for <[e-mail]>; Mon, 11 Mar 2002 06:03:21 -0800 (PST)
Received: by mystic2.trustcenter.de; id PAA02011; Mon, 11 Mar 2002 15:02:18 +0100
Received: from nodnsquery(192.168.200.233) by mystic2.trustcenter.de via smap (V5.0) id xma002009; Mon, 11 Mar 02 15:01:32 +0100
Received: from trustcenter.de (titan.trustcenter.de [192.168.200.244]) by venus.trustcenter.de (8.11.0/8.11.0) with ESMTP id g2BE1sV10211; Mon, 11 Mar 2002 15:01:54 +0100 (MET)
Message-ID: <[e-mail]>
Date: Mon, 11 Mar 2002 15:01:54 +0100
From: Juergen Brauckmann <[e-mail]>
Organization: TC TrustCenter AG
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Roberto Opazo Gazmuri <[e-mail]>, "PKIX (Grupo de la IETF)" <[e-mail]>
Subject: Re: Q: Where should do I put a max amount in a X.509v3 certificat	e?
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>

Hello.

Tom Gindin wrote:
>       Since this "purchase limit" is intended as a constraint on signed
> orders, and those are signed by PKC's rather than AC's, the constraint
> needs to go into the PKC.  I also don't think the syntax is very complex
> (currency designator and amount - the only choice you need to make is
> whether to encode amount as Numeric String, Integer, or Real).

ETSI has an monetaryLimit statemtent for use with the qCStatement
extension defined in RFC3039.

The ETSI document id is "ETSI TS 101 862 V1.2.1". The document can be
obtained from pda.etsi.org, but basically it goes like this:

MonetaryValue::= SEQUENCE {
currency Iso4217CurrencyCode,
amount INTEGER,
exponent INTEGER}
-- value = amount * 10^exponent

Iso4217CurrencyCode ::= CHOICE {
	alphabetic PrintableString (SIZE 3), -- Recommended
	numeric INTEGER (1..999) }
-- Alphabetic or numeric currency code as defined in ISO 4217
-- It is recommended that the Alphabetic form is used

Regards
    Juergen


Received: by above.proper.com (8.11.6/8.11.3) id g2BCXBk26790 for ietf-pkix-bks; Mon, 11 Mar 2002 04:33:11 -0800 (PST)
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 g2BCX4826785 for <[e-mail]>; Mon, 11 Mar 2002 04:33:05 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.us.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id HAA228610; Mon, 11 Mar 2002 07:29:38 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g2BCWsF83164; Mon, 11 Mar 2002 07:32:54 -0500
Importance: Normal
Sensitivity: 
Subject: RE: Q: Where should do I put a max amount in a X.509v3 certificat	e?
To: "Yee, Peter" <[e-mail]>
Cc: "'Tim Polk'" <[e-mail]>, Roberto Opazo Gazmuri <[e-mail]>, "PKIX (Grupo de la IETF)" <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Mon, 11 Mar 2002 07:32:48 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.9a |January 28, 2002) at 03/11/2002 07:32:56 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>

      Peter:

      Since this "purchase limit" is intended as a constraint on signed
orders, and those are signed by PKC's rather than AC's, the constraint
needs to go into the PKC.  I also don't think the syntax is very complex
(currency designator and amount - the only choice you need to make is
whether to encode amount as Numeric String, Integer, or Real).
PolicyQualifier would make the most sense if it weren't for the conflict
between the existing use of criticality in CertificatePolicies and its use
for this feature.  If PolicyQualifiers are to remain deprecated for uses
like these, IMHO the only places for these to go are a new extension or
SubjectAltName OTHER-NAME, and it really isn't a naming attribute.
      Does profiling a new extension in new-part1 make sense?

            Tom Gindin


"Yee, Peter" <[e-mail]>@mail.imc.org on 03/08/2002 02:45:51 PM

Sent by:    [e-mail]


To:    "'Tim Polk'" <[e-mail]>, Roberto Opazo Gazmuri
       <[e-mail]>
cc:    "PKIX (Grupo de la IETF)" <[e-mail]>
Subject:    RE: Q: Where should do I put a max amount in a X.509v3
       certificat e?



Tim suggests using a policy qualifier, private extension, or
subject directory attribute.  (And OCSP, with which I really have
to disagree respectfully).  I'll offer another alternative: attribute
certificates.  These seem to be a natural fit and were suggested for
just such a purpose.

Sure, I'm glossing over the plethora of software that actually
supports ACs, but most of the other suggestions aren't implemented
either. :-)


-Peter Yee

[e-mail]







Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g28Lw0J09609 for ietf-pkix-bks; Fri, 8 Mar 2002 13:58:00 -0800 (PST)
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 g28Lvw809605 for <[e-mail]>; Fri, 8 Mar 2002 13:57:58 -0800 (PST)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.12.2/8.12.2) with ESMTP id g28LvxdK010307 for <[e-mail]>; Fri, 8 Mar 2002 16:57:59 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 08 Mar 2002 16:56:38 -0500
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: Draft PKIX Agenda for Minneapolis
In-Reply-To: <D516C97A440DD31197640008C7EBBE4701B27E0F@EXRSA02>
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>

Folks,

PKIX is scheduled for one two hour session from 1-3PM on Wednesday March 
20.  I have put together a draft agenda, which I have appended to the end 
of this message.

I believe the agenda satisfies all requests received to date.  The agenda 
is nearly full, but we can *probably* accommodate one or two more 
topics.  Please let me know *ASAP* if you have requested a slot and I 
overlooked you, or you meant to request a slot but hadn't done so 
yet...  the deadline for WG agendas is Wednesday noon, but I would prefer 
to be early this time.

Thanks,

Tim Polk

-------------------          Draft PKIX agenda for Minneapolis 
---------------------------

PKIX Agenda

I. Document Status Review (5 min.)			Tim Polk (NIST)

II. DPD/DPV Requirements and Protocol

	a. DPV Requirements Status (10 min.)	Denis Pinkas (Integris)	

	b. SCVP (20 min.)				Ambarish Malpani (ValiCert)

III. OCSP update (5 Min.)				Ambarish Malpani (ValiCert)	

IV. New Specifications

	a. ACRMF and ACMC IDs (15 min.)		Peter Yee (RSA)

	b. Policy requirements for TSAs (5 min.)	Denis Pinkas (Integris)		
	
V. Ongoing Specifications

	a. TSP interoperability testing update		Denis Pinkas (Integris)
	and anticipated to TSP (10 min.)	

	b. Permanent Identifiers (10 min.)		Denis Pinkas (Integris)	

	c. Proxy Certificates (10 min.)		Steve Tuecke (ANL)

	d. Logotypes (5 min.)			Stefan Santesson (AddTrust)

VI. Personal drafts

	a. DNS as X.509 PKIX Certificate		Jakob Schlyter (Carlstedt R&T)
	Storage (10 min.)		

	b. An LDAPv3 Schema for X.509		Peter Gietz (DAASI)
	Certificates (10 min.)		




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g28JjtG06775 for ietf-pkix-bks; Fri, 8 Mar 2002 11:45:55 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g28Jjr806770 for <[e-mail]>; Fri, 8 Mar 2002 11:45:53 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 8 Mar 2002 19:45:28 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA12087; Fri, 8 Mar 2002 14:45:32 -0500 (EST)
Received: from exrsa01.rsa.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g28Jjrv20775; Fri, 8 Mar 2002 14:45:53 -0500 (EST)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2653.19) id <FVAZDATN>; Fri, 8 Mar 2002 11:52:19 -0800
Message-ID: <D516C97A440DD31197640008C7EBBE4701B27E0F@EXRSA02>
From: "Yee, Peter" <[e-mail]>
To: "'Tim Polk'" <[e-mail]>, Roberto Opazo Gazmuri <[e-mail]>
Cc: "PKIX (Grupo de la IETF)" <[e-mail]>
Subject: RE: Q: Where should do I put a max amount in a X.509v3 certificat e?
Date: Fri, 8 Mar 2002 11:45:51 -0800 
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>

Tim suggests using a policy qualifier, private extension, or
subject directory attribute.  (And OCSP, with which I really have
to disagree respectfully).  I'll offer another alternative: attribute
certificates.  These seem to be a natural fit and were suggested for
just such a purpose.

Sure, I'm glossing over the plethora of software that actually
supports ACs, but most of the other suggestions aren't implemented
either. :-)

						-Peter Yee
						[e-mail]



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g28FdL323821 for ietf-pkix-bks; Fri, 8 Mar 2002 07:39:21 -0800 (PST)
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 g28FdJ823817 for <[e-mail]>; Fri, 8 Mar 2002 07:39:19 -0800 (PST)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.12.2/8.12.2) with ESMTP id g28FdIdK012815; Fri, 8 Mar 2002 10:39:19 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 08 Mar 2002 10:37:47 -0500
To: "Roberto Opazo Gazmuri" <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: Re: Q: Where should do I put a max amount in a X.509v3 certificate?
Cc: "PKIX \(Grupo de la IETF\)" <[e-mail]>
In-Reply-To: <p05100307b8a990962b6a@[128.89.88.34]>
References: <[e-mail]> <[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>

At 04:00 PM 3/4/02 -0500, Stephen Kent wrote:

>At 1:50 PM -0300 3/3/02, Roberto Opazo Gazmuri wrote:
>>IETF-PXIX:
>>
>>I would like to ask the WG opinion about "the correct" place to indicate
>>that a certificate should not be used to validate electronic signatures for
>>a mount over a determined maximum.
>>
>>Here we are delegating in de RP the responsibility of validating the
>>certificate content to see if there is a limit and I have not seen a good
>>place to put this information. We need to indicate:
>>1.- There is a general limit, not for a specific transaction type
>>2.- The mount of the limit
>>3.- The type of money in witch the mount is expressed
>>
>>Is there a standard extension for that?
>>
>>Thanks,
>>
>>Opazo, Roberto ([e-mail])
>>CEO - www.acepta.com
>>Certification Authority for Chile
>
>There is no standard extension for conveying this info.  One might use the 
>policy ID field and policy qualifiers to represent this info in a machine 
>readable fashion, but we have generally advised folks to not use the 
>policy qualifier field.
>
>Steve

Roberto,

The first question is "what is the range of uses for your 
certificates"?  Will they only be used in context of the maximum dollar 
amount, or do you expect them to be used for S/MIME, TLS, or IPsec?  Will 
they be used in a closed community - the same one that understands the 
maximum amount information - or will the community that uses the amount 
information be one of several that use the certificate?

As Steve has said, a standard method for representing the maximum amount 
hasn't been established.  Several possibilities exist; each has a different 
impact on interoperability.

(1)  It *could* be represented in a policy qualifier, although I must say I 
find that option personally distasteful.  You could place the information 
in a private qualifier, or perhaps the user notice qualifier would 
work.  Either way, you shouldn't expect other communities to accept that 
policy for their applications.  If you want interoperability, you would 
need to place multiple policies in the certificate, and represent the 
amount information in the qualifier associated with one of the certificate 
policies.

(2) It *could* be represented in a private extension.  As long as those 
extensions are non-critical, that shouldn't hinder interoperability.

(3) It might be possible to use the subject directory attributes extension 
to convey the information.  (I am not sure if a maximum amount directory 
attribute has already been established.)   Since it is always non-critical, 
this shouldn't impact interoperability.

Regardless of the path you choose, an off-the-shelf client will not 
understand the reliance information.  To support the application(s) that 
will process this information, you may need to develop a custom plug-in.

The real question is "Should that information be in the certificate?"  This 
kind of information may change over the life of a certificate.

IMHO, this is a really good place to use OCSP.  You could use the OCSP 
response to convey the most current reliance amount to relying parties that 
need the information.  Relying parties that don't care (e.g., an S/MIME 
client) can still use OCSP to get status information without requesting the 
maximum amount information.

Tim Polk


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g28ASQM04430 for ietf-pkix-bks; Fri, 8 Mar 2002 02:28:26 -0800 (PST)
Received: from srv-mail.fst.it ([208.164.5.212]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g28ASO804421 for <[e-mail]>; Fri, 8 Mar 2002 02:28:25 -0800 (PST)
Received: by srv-mail.fst.it with Internet Mail Service (5.5.2653.19) id <FNPBMKQY>; Fri, 8 Mar 2002 11:25:52 +0100
Message-ID: <[e-mail]>
From: Massimiliano Farris <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: new test TSA available
Date: Fri, 8 Mar 2002 11:25:42 +0100 
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>

Hi everyone,
There's a new TSA available at:
  ricerca.fst.it (213.255.37.86)
  Port 318 
compliant with RFC 3161.
The TSA is based on the socket based protocol 
and it is an experimental service which runs 
single-threaded.

We have also developed a time-stamp client (MFC),
a freeware software which allows you:
  -  create a time-stamp request from a selected file;
  -  request the time-stamp to any TSA offering socket
     based interface;
  -  view/save on disk the time-stamp received from the TSA;
  -  verify the time-stamp;

You can download the software from http://ricerca.fst.it

Please contact [e-mail] for suggestions/comments.

Massimiliano

--
Massimiliano Farris
Fst s.r.l.
System Integration & Software Development
Tel:    [phone]
Fax:    [phone]
e-mail: [e-mail]
web:    http://ricerca.fst.it



Received: by above.proper.com (8.11.6/8.11.3) id g289pYJ00866 for ietf-pkix-bks; Fri, 8 Mar 2002 01:51:34 -0800 (PST)
Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g289pV800860 for <[e-mail]>; Fri, 8 Mar 2002 01:51:31 -0800 (PST)
Received: from mailgate4.nec.co.jp ([10.7.69.197]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g289pNX23834 for <[e-mail]>; Fri, 8 Mar 2002 18:51:23 +0900 (JST)
Received: from mailsv.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g289pHR24624; Fri, 8 Mar 2002 18:51:18 +0900 (JST)
Received: from vcheck1.nes.nec.co.jp (vcheck1.nes.nec.co.jp [10.108.16.71]) by mailsv.nec.co.jp (8.11.6/3.7W-MAILSV-NEC) with ESMTP id g289oh808137; Fri, 8 Mar 2002 18:50:58 +0900 (JST)
Received: from mailsv.nnes.nec.co.jp (localhost [127.0.0.1]) by vcheck1.nes.nec.co.jp (8.9.3/3.7W-02/27/02) with ESMTP id SAA11686; Fri, 8 Mar 2002 18:50:42 +0900 (JST)
Received: (from root@localhost) by mailsv.nnes.nec.co.jp (8.9.3/3.7W-01/17/01) id SAA27624; Fri, 8 Mar 2002 18:50:41 +0900 (JST)
Received: from nocsv1.dv4.nnes.nec.co.jp (mailsv.dv4.nnes.nec.co.jp [10.109.24.11]) by mailsv.nnes.nec.co.jp (8.9.3/3.7W-01/17/01) with ESMTP id SAA27621; Fri, 8 Mar 2002 18:50:41 +0900 (JST)
Received: from ECPC10 ([10.109.23.201]) by nocsv1.dv4.nnes.nec.co.jp (8.9.3/3.7Wdv4-mb1.0) with ESMTP id SAA53793; Fri, 8 Mar 2002 18:50:40 +0900 (JST)
Date: Fri, 08 Mar 2002 18:50:40 +0900
From: hisayuki IWANISHI <[e-mail]>
To: [e-mail]
Subject: Re: TSP interop test (NEC)
Reply-To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.00.06
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

One Correction, on my previous message,

> We found that there was a TSA which returned normal timeStampToken with
> its own policy as a response of TimeStampReq  with inadequate policy. We
> excepted the "unacceptedPolicy error response" on this case.
We EXPECTED the..

My Apologies

Hisayuki


---
Hisayuki IWANISHI
NEC Corporation /
4th Operations Unit, NEC System Technologies, Ltd.
Hiroshima Japan


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g289GJp26429 for ietf-pkix-bks; Fri, 8 Mar 2002 01:16:19 -0800 (PST)
Received: from TYO202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.247.6.41]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g289GH826423 for <[e-mail]>; Fri, 8 Mar 2002 01:16:18 -0800 (PST)
Received: from mailgate4.nec.co.jp ([10.7.69.197]) by TYO202.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g289GGe23720 for <[e-mail]>; Fri, 8 Mar 2002 18:16:16 +0900 (JST)
Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g289GDR21366; Fri, 8 Mar 2002 18:16:13 +0900 (JST)
Received: from vcheck1.nes.nec.co.jp (vcheck1.nes.nec.co.jp [10.108.16.71]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id g289GCB15559; Fri, 8 Mar 2002 18:16:13 +0900 (JST)
Received: from mailsv.nnes.nec.co.jp (localhost [127.0.0.1]) by vcheck1.nes.nec.co.jp (8.9.3/3.7W-02/27/02) with ESMTP id SAA05772; Fri, 8 Mar 2002 18:16:12 +0900 (JST)
Received: (from root@localhost) by mailsv.nnes.nec.co.jp (8.9.3/3.7W-01/17/01) id SAA24369; Fri, 8 Mar 2002 18:16:11 +0900 (JST)
Received: from nocsv1.dv4.nnes.nec.co.jp (mailsv.dv4.nnes.nec.co.jp [10.109.24.11]) by mailsv.nnes.nec.co.jp (8.9.3/3.7W-01/17/01) with ESMTP id SAA24366; Fri, 8 Mar 2002 18:16:11 +0900 (JST)
Received: from ECPC10 ([10.109.23.201]) by nocsv1.dv4.nnes.nec.co.jp (8.9.3/3.7Wdv4-mb1.0) with ESMTP id SAA52726; Fri, 8 Mar 2002 18:16:10 +0900 (JST)
Date: Fri, 08 Mar 2002 18:16:10 +0900
From: hisayuki IWANISHI <[e-mail]>
To: [e-mail]
Subject: TSP interop test (NEC)
Reply-To: [e-mail]
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.00.06
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear all,

We , NEC tries to access to the test TSAs using our original developed
TSP clients. I report that we got following results with each TSAs.

TSP client
  - sent TimeStampReq and receive timeStampToken
    included in the TimeStampResp
  - decode the timeStampToken
  - verify the value of the messageImprint
  - verify the value of the nonce
  - confirm that the timeStampToken had the policy
  - confirm the timeliness of the time in the timeStampToken
  - sent bad-formatted TemeStampReq and receive
    the badDataFormat error response

We omitted to:
  - verify the signature of the SignaedData(CMS)
  - verify the SignedData(CMS)'s certificate path
    (described in the RFC2459 or its later drafts)
  - verify the extensions of the TSTInfo


We found that there was a TSA which returned normal timeStampToken with
its own policy as a response of TimeStampReq  with inadequate policy. We
excepted the "unacceptedPolicy error response" on this case.




Regards,
Hisayuki

---
Hisayuki IWANISHI
NEC Corporation /
4th Operations Unit, NEC System Technologies, Ltd.
Hiroshima Japan




SERVER                    HTTP          TCP
------------------------+----------+----------+
SIA
host=193.203.230.166        n/s       SUCCESS
port=318
policyid=1.3.135.1.2.0
------------------------+----------+----------+
EdelWeb
url=
http://www.edelweb.fr/    SUCCESS      n/s
cgi-bin/service-tsp
policyid=
1.3.6.1.4.1.5309.1.2.2
------------------------+----------+----------+
CNSG
host=tsp.test.polito.it
port=318                    n/s       SUCCESS
policyid=0.0
------------------------+----------+----------+
C&A
host=195.223.2.6
port=3318
policyid=0.4.0.1.1.1      SUCCESS     SUCCESS
url=
http://195.223.2.6:8080/
timestamp
------------------------+----------+----------+

n/s= Not Supported.




Received: by above.proper.com (8.11.6/8.11.3) id g280QX223564 for ietf-pkix-bks; Thu, 7 Mar 2002 16:26:33 -0800 (PST)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g280QV823560 for <[e-mail]>; Thu, 7 Mar 2002 16:26:31 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Thu, 7 Mar 2002 16:25:50 -0800 (PST)
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, 07 Mar 2002 16:25:50 -0800 (PST)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <GK1PPNBS>; Thu, 07 Mar 2002 16:26:28 -0800
Content-return: allowed
Date: Thu, 07 Mar 2002 16:26:24 -0800
From: Peter Williams <[e-mail]>
Subject: RE: Attribute Certificate Policy??
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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>

Summary:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-req-02.txt
7.1 seems seems insufficient to address PMI elements of remote
validation.

Note:

The topic of AA-cert policies and delegation path validation caused
me to review DPV requirements, for X.509 cert paths that contain
AA-issued privileges.(see X.509 13.2)

Though the PKIX profile of X.509 may not really address privileges that 
are represented in a public-key cert's subjectDirectoryAttribute extension,
the X.509-quality requirements for handling such a case of privlege 
management seem clear.

As described in X.509: "Privilege policy" rule execution is  required, when 
an  assertion of the privilege is made via subjectDirectoryAttribute, for
a cert issued by a combined CA/AA. The verifier (e.g. DPV server) MUST check
the delegation/certification path using each privilege-specific 
determination process, during (public-key) certificate path processing.
(X.509 16.3)

Ok, this means that a DPV server must also be able to handle this case,
and therefore "validation policy" must be defined to be include all 
"privilege policies" relevant to an evaluated cert chain. Hence
the definition in the IETF DPV/DPD requirements document
is somewhat insufficient, as it does not address this
X.509-imposed requirement.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g27NFK721540 for ietf-pkix-bks; Thu, 7 Mar 2002 15:15:20 -0800 (PST)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g27NFJ821536 for <[e-mail]>; Thu, 7 Mar 2002 15:15:19 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Thu, 7 Mar 2002 15:14:38 -0800 (PST)
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, 07 Mar 2002 15:14:37 -0800 (PST)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <GK1PPMSJ>; Thu, 07 Mar 2002 15:15:16 -0800
Content-return: allowed
Date: Thu, 07 Mar 2002 15:15:12 -0800
From: Peter Williams <[e-mail]>
Subject: RE: Attribute Certificate Policy??
To: "'David A. Cooper'" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Im not sure I agree with David Chadwick that
X.509 needs to be involved to address the
needs of AA cert issuing policies.

Why not?

Relying parties ARE REQUIRED by X.509 to obtain
privilege policy, when doing AA path processing.
AA path processing requires handling the privilege
policy-defined constraints.

"The privilege verifier must also determine whether or not the privileges
being asserted are sufficient for the context of
use. The privilege policy establishes the rules for making this
determination and includes specification of any
environmental variables that need to be considered. The privileges asserted,
including those resulting from the role
procedure in 16.2 and the delegation procedure in 16.3 and any relevant
environmental variables (e.g. time of day or
current account balance) are compared against the privilege policy to
determine whether or not they are sufficient for the
context of use."

Relying parties are also required to:
"ensure that the delegator was authorized to delegate the 
privilege they own and" However authorization checking is
not a part of "privilege policy", as far as I can tell
from what the standard actually states.

I see no reason why an SOA-defined privilege, whose verification
of assertion is subject to the X.509 delegation path processing rules ,
cannot be 
defined as the "use of the rights and asumption of the oblitations defined
in 
an AA's CPS" I see no reason why the privilege assertion cannot be: 
cite a set of "AA-policy OIDs", where that set of OID  is just an 
SOA-defined privilege for the delegation path.

As with any privilege, under the privilege policy,
such an SOA_defined privilege would require handling under 
environment-specific processing rules, as defined by the SOA. These 
can be defined as: also evaluate a delgation path under the cert 
policy and cert policy mapping constraints rules used
in evaluating certification paths. 

I dont thinkg either X.509 or IETF needs to be involved (i.e.
we have to wait another 2 years) to do  this. It would be nice if IETF 
defined such a privilege type, but  nothing stops any SOA doing so. It 
doesnt seem to require an AA cert extension; a privilege definition
is sufficient.  

-----Original Message-----
From: David A. Cooper [mailto:[e-mail]]
Sent: Thursday, March 07, 2002 12:53 PM
To: [e-mail]
Subject: RE: Attribute Certificate Policy??




I just want to point out that X.509 states that the certificatePolicies
extension is only to be used in public-key certificates.

The first sentences in section 8 of X.509 state: "The certificate extensions
defined in this clause are for use with public-key certificates, unless
otherwise stated. Extensions for use with attribute certificates are defined
in clause 15." There is nothing in section 8.2.2.6 on the
certificatePolicies extension stating that the extension may be used in an
attribute certificate, so its use is limited to public-key certificates.

I don't know what mechanisms, if any, are defined in X.509 to provide policy
information about attribute certificates, but perhaps someone who is more
familiar with that standard can provide some insight.

Dave

At 01:15 PM 3/7/02 -0500, Christopher S. Francis wrote:

>Yuriy,
>
>Hmm.... You certainly have more experience in this area than I do.  In
>actual practice what you say may indeed be the case.  I based my comments
on
>what I read in X.509.
>
> >From X.509 section 8.2.2.6 on the certificate policies extension:
>
>"If the extension is flagged critical, it indicates that the certificate
>shall only be used for the purpose, and in accordance with the rules
implied
>by one of the indicated certificate policies.  The rules of a particular
>policy may require the certificate-using system to process the qualifier
>value in a particular way.
>
>If the extension is flagged non-critical, use of this extension does not
>necessarily constrain use of the certificate to the policies listed.
>However, a certificate user may require a particular policy to be present
in
>order to use the certificate (see 10).  Policy qualifiers may, at the
option
>of the certificate user, be processed or ignored."
>
>Chris
>
>-----Original Message-----
>From: Yuriy Dzambasow [mailto:[e-mail]]
>Sent: Thursday, March 07, 2002 12:29 PM
>To: Christopher S. Francis; Housley, Russ
>Cc: Ietf-Pkix
>Subject: RE: Attribute Certificate Policy??
>
>
>Chris:
>
>...snip...
>
> >
> > In some environments, I believe that an AA might in fact want to make
the
> > certificatePolicies extension critical, especially if there is legal
> > liability involved.  By making the extension critical it says that
relying
> > parties are required to accept the terms documented in the AA's CPS
before
> > relying on the authorizations granted in the certificate.
> >
> > Chris
>
>Marking an extension critical has nothing to do with accepting terms in CPs
>and CPSs.  Things like relying party agreements address this issue.
>
>Yuriy
>
>...snip...



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g27MG9C20178 for ietf-pkix-bks; Thu, 7 Mar 2002 14:16:09 -0800 (PST)
Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g27MG7820174 for <[e-mail]>; Thu, 7 Mar 2002 14:16:07 -0800 (PST)
Received: from salford.ac.uk ([213.107.136.109]) by mta03-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <[e-mail]>; Thu, 7 Mar 2002 22:16:08 +0000
Message-ID: <[e-mail]>
Date: Thu, 07 Mar 2002 22:19:17 +0000
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: "Christopher S. Francis" <[e-mail]>, "Housley, Russ" <[e-mail]>, Ietf-Pkix <[e-mail]>
Subject: Re: Attribute Certificate Policy??
References: <[e-mail]> <[e-mail]>
Content-Type: multipart/mixed; boundary="------------ECB8A3E677B15342126FD682"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Hi All

Having implemented a policy based attribute certificate infrastructure
(see www.permis.org and sec.isi.salford.ac.uk/permis for more details) I
have a few comments to make to this thread.

Firstly, there can be a requirement to limit the use of ACs to specific
authorisation policies. In our implementation, each authorisation
policy, or access decision policy (cf ISO 10181-3) is given a unique
OID. 

Secondly, we currently dont have an AC extension to put policy OIDs in,
since the policy extension is only meant to be used with PK certs and
not AC certs. So you would need to update X.509 if you are talking about
putting policy extensions in ACs

Thirdly, there are two policies that are potentially of interest for
ACs. So maybe two policy extensions are needed. The first is the policy
of the AA that issued the AC (what the AC should be used for), and the
second is the authorisation policy controlling the target that is
accepting ACs as credentials/permissions for the access (which ACs the
target can accept). In PERMIS we are only concerned about the latter,
whereas I think the PKIX thread is more concerned about the former. But
consider this. University degrees, Microsoft Certified Engineer, ISO
9000 certified, Visa cards etc. can all be issued electronically as ACs,
signed by the issuing institution. The holder can present these
privilege ACs to any electronic target in order to try to gain access.
So typically an issuer does not try to limit the targets at which the
ACs are deemed to be valid and useful privileges. (A university does not
say where its degrees can be used.) It is the target administrator that
decides which ACs it will trust and this is built into its target access
decision policy (will Org X accept degrees from Univ Y). Clearly a
target (administrator) may wish to consult the issuing policy, if one
exists, before trusting particular AAs, and so a pointer to this in each
AC could be useful (e.g Visa might place restrictions on which targets
can use its electronic credit cards). Parts of the issuing policy are
already in the AC for example, whether delegation is allowed or not. If
the issuer does try to limit the target policies that are applicable to
an AC, it will need to know about the target policies before issuing the
certificates, which might typically be difficult to achieve.

My suggestion would be to steer clear of the existing policies
extension, which is defined for use with PKCerts, and to define new AC
extensions if ones are needed (they can clearly have the same syntax as
the existing policy extension, but give them new extension OIDs). This
more or less agrees with Stephen's email below

David


Stephen Farrell wrote:
> 
> Chris,
> 
> I'd be against the idea of proposing this as an update to the AC profile
> for the following reasons:
> 
> - The profile is in the rfc editor's queue only awaiting son-of-2359 to
>   be processed and such an update would require a re-set back to WG last
>   call (a matter of months!)
> - I don't believe that the use of policy OIDs in ACs is at all well
>   understood and therefore I'd argue to omit it from the profile (one
>   of the things we tried to do with the AC profile was to only include
>   suff that we were pretty sure could work)
> - There may be entirely different policy considerations to address,
>   depending on the context for the use of ACs (e.g. supporting roles for
>   long-term signatures vs roles for access control).
> 
> So, while I'd welcome work starting on this - for both process and
> technical reasons I believe the way to handle it is to write things up in
> a separate I-D. At some point in the future (say if the AC profile were
> being cycled at proposed standard), the two things could be merged if
> appropriate.
> 
> Regards,
> Stephen.
> 
> "Christopher S. Francis" wrote:
> >
> > Sure.  I can pursue it.  Since I don't spend a lot of time here, I'm not
> > exactly sure what the appropriate process is, but what I have in mind is to
> > do the following:
> >
> > 1) Get some clarification from ANSI and whoever else has an opinion on
> > whether X.509 offers an extension that is intended to be used to carry
> > certificate policy information in attribute certificates.  Perhaps
> > certificatePolicies, perhaps acceptablePrivilegePolicies, perhaps they had
> > something else in mind.
> > 2) Depending on what I find out, propose an update to the PKIX attribute
> > certificate profile that includes an extension to ACs to hold policy
> > information about the issuing authority.
> >
> > Based on your earlier responses, I understand that a certificatePolicies
> > extension could be included in an AC as long as it is marked non-critical,
> > but it that's only because *anything* can be included as an extension if
> > it's marked non-critical.  It seems to me there should be something specific
> > in the profile to address the issue of certificate policy.
> >
> > Chris
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]On
> > Behalf Of Housley, Russ
> > Sent: Wednesday, March 06, 2002 11:02 AM
> > To: Christopher S. Francis
> > Cc: Ietf-Pkix
> > Subject: Re: Attribute Certificate Policy??
> >
> > Chris:
> >
> > I am not aware of any work in this area.  You can take the lead.
> >
> > Russ
> >
> > At 05:41 PM 3/5/2002 -0500, Christopher S. Francis wrote:
> >
> > >Is there a defined mechanism to specify something analogous to a
> > >certificate policy in an attribute certificate?
> > >
> > >
> > >
> > >In reviewing the PKIX AC profile, I see that the syntax of the attributes
> > >field is defined by the AttributeType OID, but rather than syntax per se,
> > >I m looking for a way to specify the particular set of policies,
> > >practices, and procedures that the attribute authority was operating under
> > >when it issued the attribute certificate.  Seems like this would be
> > >important to relying parties.
> > >
> > >
> > >
> > >X.509 includes an acceptablePrivilegePolicies extension that seems like it
> > >might to the job, but it was apparently profiled out by PKIX.
> > >
> > >
> > >
> > >Chris Francis
> > >
> > >
> > >
> > >
> 
> --
> ____________________________________________________________
> Stephen Farrell
> Baltimore Technologies,   tel: (direct line) [phone]
> 39 Parkgate Street,                     fax: [phone]
> Dublin 8.                mailto:[e-mail]
> Ireland                             http://www.baltimore.com

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

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

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

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------ECB8A3E677B15342126FD682--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g27Ks0Q17970 for ietf-pkix-bks; Thu, 7 Mar 2002 12:54:00 -0800 (PST)
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 g27Krx817963 for <[e-mail]>; Thu, 7 Mar 2002 12:53:59 -0800 (PST)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.12.2/8.12.2) with ESMTP id g27KrxdK021037 for <[e-mail]>; Thu, 7 Mar 2002 15:54:00 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Thu, 07 Mar 2002 15:53:13 -0500
To: [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: RE: Attribute Certificate Policy??
In-Reply-To: <[e-mail] m>
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>

I just want to point out that X.509 states that the certificatePolicies extension is only to be used in public-key certificates.

The first sentences in section 8 of X.509 state: "The certificate extensions defined in this clause are for use with public-key certificates, unless otherwise stated. Extensions for use with attribute certificates are defined in clause 15." There is nothing in section 8.2.2.6 on the certificatePolicies extension stating that the extension may be used in an attribute certificate, so its use is limited to public-key certificates.

I don't know what mechanisms, if any, are defined in X.509 to provide policy information about attribute certificates, but perhaps someone who is more familiar with that standard can provide some insight.

Dave

At 01:15 PM 3/7/02 -0500, Christopher S. Francis wrote:

>Yuriy,
>
>Hmm.... You certainly have more experience in this area than I do.  In
>actual practice what you say may indeed be the case.  I based my comments on
>what I read in X.509.
>
> >From X.509 section 8.2.2.6 on the certificate policies extension:
>
>"If the extension is flagged critical, it indicates that the certificate
>shall only be used for the purpose, and in accordance with the rules implied
>by one of the indicated certificate policies.  The rules of a particular
>policy may require the certificate-using system to process the qualifier
>value in a particular way.
>
>If the extension is flagged non-critical, use of this extension does not
>necessarily constrain use of the certificate to the policies listed.
>However, a certificate user may require a particular policy to be present in
>order to use the certificate (see 10).  Policy qualifiers may, at the option
>of the certificate user, be processed or ignored."
>
>Chris
>
>-----Original Message-----
>From: Yuriy Dzambasow [mailto:[e-mail]]
>Sent: Thursday, March 07, 2002 12:29 PM
>To: Christopher S. Francis; Housley, Russ
>Cc: Ietf-Pkix
>Subject: RE: Attribute Certificate Policy??
>
>
>Chris:
>
>...snip...
>
> >
> > In some environments, I believe that an AA might in fact want to make the
> > certificatePolicies extension critical, especially if there is legal
> > liability involved.  By making the extension critical it says that relying
> > parties are required to accept the terms documented in the AA's CPS before
> > relying on the authorizations granted in the certificate.
> >
> > Chris
>
>Marking an extension critical has nothing to do with accepting terms in CPs
>and CPSs.  Things like relying party agreements address this issue.
>
>Yuriy
>
>...snip...




Received: by above.proper.com (8.11.6/8.11.3) id g27JfGo15171 for ietf-pkix-bks; Thu, 7 Mar 2002 11:41:16 -0800 (PST)
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 g27JfE815165; Thu, 7 Mar 2002 11:41:14 -0800 (PST)
Received: from tsg1 ([12.81.70.34]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020307194100.RPQU11747.mtiwmhc23.worldnet.att.net@tsg1>; Thu, 7 Mar 2002 19:41:00 +0000
Message-ID: <000c01c1c60f$f4274d30$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "todd glassey" <[e-mail]>, "Paul Hoffman / IMC" <[e-mail]>, "LISTS - IETF-PKIX" <[e-mail]>, <[e-mail]>
References: <00f901c1c5f5$141a93b0$020aff0c@tsg1>
Subject: Re: POLICTCAL THREAD: Fw: Hello. looking 4 info on Poisson group.
Date: Thu, 7 Mar 2002 11:40:34 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

My apologies to the group for inundating you with this. I should have sent
it OOB.

T.
----- Original Message -----
From: "todd glassey" <[e-mail]>
To: "Paul Hoffman / IMC" <[e-mail]>; "LISTS - IETF-PKIX"
<[e-mail]>; <[e-mail]>
Sent: Thursday, March 07, 2002 8:28 AM
Subject: POLICTCAL THREAD: Fw: Hello. looking 4 info on Poisson group.


>
> Paul remember that nasty note you sent me re: that POISSON and POISED are
> the place for my motions, and here is the commentary from Harald
Alvestrand
> regarding that closure of that WG which seems to invalidate your
commentary
> to me.   Hmmmmm.
>
> Todd
>
> ----- Original Message -----
> From: "Harald Alvestrand" <[e-mail]>
> To: "chiari mario" <[e-mail]>; <[e-mail]>
> Sent: Thursday, March 07, 2002 7:35 AM
> Subject: Re: Hello. looking 4 info on Poisson group.
>
>
> >
> >
> > --On mandag, mars 04, 2002 15:59:41 +0100 chiari mario
> > <[e-mail]> wrote:
> >
> > > Hello,
> > >
> > >
> > > sorry to bother. I am looking for info on the POISSON ietf working
group
> > > (as it is quoted on RFC 2727, pag.13).
> > >
> > > However, the POISSON doesn't seem listed on
> > > http://www.ietf.org/html.charters/wg-dir.html.
> >
> > The POISSON working group was closed a few months ago.
> > There is a link "Concluded working groups" off the main WG page; while
> > POISSON appears to have falllen off, you will find the charter under
> >
> > http://www.ietf.org/html.charters/OLD/poisson-charter.html
> >
> > >
> > > I am trying to trace all the reference on the relationship between
ISOC
> > > and IETF (and related entities, as IAB)
> >
> > :-)
> >
> > >
> > >
> > > Any help is appreciate.
> > >
> > > Thanks Regards
> > > mario chiari
> > >
> >
> >
> >
>



Received: by above.proper.com (8.11.6/8.11.3) id g27ItJm13844 for ietf-pkix-bks; Thu, 7 Mar 2002 10:55:19 -0800 (PST)
Received: from OHTHREE.jjj-i.com (homer.ntru.com [208.252.42.180]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g27ItI813840 for <[e-mail]>; Thu, 7 Mar 2002 10:55:19 -0800 (PST)
Received: by OHTHREE.jjj-i.com with Internet Mail Service (5.5.2650.21) id <1T7XDK9X>; Thu, 7 Mar 2002 13:38:05 -0500
Message-ID: <[e-mail]>
From: "Singer, Ari" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-pkalgs-supp-01.txt
Date: Thu, 7 Mar 2002 13:38:03 -0500 
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>

Hi, Stephen.

> Its called "supplemental algorithms" but only contains details 
> about ntru related stuff. If its intended to contain other 
> algorithms, then I'd like to know roughly what they are or when 
> to expect to see them. If not, then truth-in-advertising would 
> suggest "s/supplemental/ntru/g".

Yes.  That is a good observation.  NIST asked me to include information
about their new SHA algorithms and the revised DSA whenever that is ready.
When the information for the new algorithms are available they will be
included.  Also, once the new SHA algorithms are available, I will be
including OIDs and other additional information related to the use of the
other public key algorithms with the new hash algorithms.  So, as you say,
currently the only text in there relates to the NTRU algorithms and their
use with the new (and old) SHA algorithms, but I expect to be adding more
(non-NTRU) material shortly.

If anyone has any ideas for more text that should go into the document, let
me know and I will include that as well.

Cheers,
Ari

Ari Singer, Principal Engineer
NTRU
5 Burlington Woods
Burlington, MA 01803
Main: [phone]
Personal: [phone]
Fax: [phone]



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g27IfZf13435 for ietf-pkix-bks; Thu, 7 Mar 2002 10:41:35 -0800 (PST)
Received: from dtctxexchims04.ins.com ([208.164.93.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g27IfX813426 for <[e-mail]>; Thu, 7 Mar 2002 10:41:33 -0800 (PST)
Received: by dtctxexch3.ins.com with Internet Mail Service (5.5.2653.19) id <G1PF9QHB>; Thu, 7 Mar 2002 12:41:25 -0600
Received: from young1_roger.lucent.com (YOUNG1_ROGER [135.119.115.65]) by dtctxexchims04.ins.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G1PF9QG0; Thu, 7 Mar 2002 12:41:19 -0600
From: Roger Younglove <[e-mail]>
To: "Housley, Russ" <[e-mail]>, "Christopher S. Francis" <[e-mail]>
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 07 Mar 2002 13:41:31 -0500
Subject: Re: Attribute Certificate Policy??
In-Reply-To: <[e-mail] .com>
References: <[e-mail]> <[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>

I am a member of the Science and Technology Committee of the American Bar 
Assoc. and we are very aware of the CP and CPS liability issues. Having an 
AC CP OID even non-critical would provide the liability protection as long 
as the Relying Party agreement stated the meaning of the OID.  I must 
inform you that I am not a lawyer but I have worked with the best in this 
field over the last five years. Randy Sabett at Cooley is one of them.
At 10:11 AM 03/07/2002, Housley, Russ wrote:

>Chris:
>
>Perhaps we can get some of the American Bar Assoc people to comment on the 
>CP and CPS issues.  I suspect that we will need to go through an 
>educational phase before we get any useful feedaback.  Perhaps they have 
>been looking at it and we are just unaware...
>
>Russ
>
>At 02:53 PM 3/7/2002 +0000, Stephen Farrell wrote:
>
>>Chris,
>>
>>I'd be against the idea of proposing this as an update to the AC profile
>>for the following reasons:
>>
>>- The profile is in the rfc editor's queue only awaiting son-of-2359 to
>>   be processed and such an update would require a re-set back to WG last
>>   call (a matter of months!)
>>- I don't believe that the use of policy OIDs in ACs is at all well
>>   understood and therefore I'd argue to omit it from the profile (one
>>   of the things we tried to do with the AC profile was to only include
>>   suff that we were pretty sure could work)
>>- There may be entirely different policy considerations to address,
>>   depending on the context for the use of ACs (e.g. supporting roles for
>>   long-term signatures vs roles for access control).
>>
>>So, while I'd welcome work starting on this - for both process and
>>technical reasons I believe the way to handle it is to write things up in
>>a separate I-D. At some point in the future (say if the AC profile were
>>being cycled at proposed standard), the two things could be merged if
>>appropriate.
>>
>>Regards,
>>Stephen.
>>
>>
>>"Christopher S. Francis" wrote:
>> >
>> > Sure.  I can pursue it.  Since I don't spend a lot of time here, I'm not
>> > exactly sure what the appropriate process is, but what I have in mind 
>> is to
>> > do the following:
>> >
>> > 1) Get some clarification from ANSI and whoever else has an opinion on
>> > whether X.509 offers an extension that is intended to be used to carry
>> > certificate policy information in attribute certificates.  Perhaps
>> > certificatePolicies, perhaps acceptablePrivilegePolicies, perhaps they had
>> > something else in mind.
>> > 2) Depending on what I find out, propose an update to the PKIX attribute
>> > certificate profile that includes an extension to ACs to hold policy
>> > information about the issuing authority.
>> >
>> > Based on your earlier responses, I understand that a certificatePolicies
>> > extension could be included in an AC as long as it is marked non-critical,
>> > but it that's only because *anything* can be included as an extension if
>> > it's marked non-critical.  It seems to me there should be something 
>> specific
>> > in the profile to address the issue of certificate policy.
>> >
>> > Chris
>> > -----Original Message-----
>> > From: [e-mail] [mailto:[e-mail]]On
>> > Behalf Of Housley, Russ
>> > Sent: Wednesday, March 06, 2002 11:02 AM
>> > To: Christopher S. Francis
>> > Cc: Ietf-Pkix
>> > Subject: Re: Attribute Certificate Policy??
>> >
>> > Chris:
>> >
>> > I am not aware of any work in this area.  You can take the lead.
>> >
>> > Russ
>> >
>> > At 05:41 PM 3/5/2002 -0500, Christopher S. Francis wrote:
>> >
>> > >Is there a defined mechanism to specify something analogous to a
>> > >certificate policy in an attribute certificate?
>> > >
>> > >
>> > >
>> > >In reviewing the PKIX AC profile, I see that the syntax of the attributes
>> > >field is defined by the AttributeType OID, but rather than syntax per se,
>> > >I m looking for a way to specify the particular set of policies,
>> > >practices, and procedures that the attribute authority was operating 
>> under
>> > >when it issued the attribute certificate.  Seems like this would be
>> > >important to relying parties.
>> > >
>> > >
>> > >
>> > >X.509 includes an acceptablePrivilegePolicies extension that seems 
>> like it
>> > >might to the job, but it was apparently profiled out by PKIX.
>> > >
>> > >
>> > >
>> > >Chris Francis
>> > >
>> > >
>> > >
>> > >
>>
>>--
>>____________________________________________________________
>>Stephen Farrell
>>Baltimore Technologies,   tel: (direct line) [phone]
>>39 Parkgate Street,                     fax: [phone]
>>Dublin 8.                mailto:[e-mail]
>>Ireland                             http://www.baltimore.com

--------
TTFN
Roger W. Younglove, CISSP
Distinguished Member of Consulting Staff
Lucent Worldwide Services--Information Security
100 Galleria Officentre, Ste. 220
Southfield, MI 48034-8428
Numeric page: 888.935.6755
E-mail page:
[e-mail]
eFax number: 413.425.5368



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g27IMCB11730 for ietf-pkix-bks; Thu, 7 Mar 2002 10:22:12 -0800 (PST)
Received: from emerald.lightlink.com (emerald.lightlink.com [205.232.34.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g27IMB811726 for <[e-mail]>; Thu, 7 Mar 2002 10:22:11 -0800 (PST)
Received: from [209.216.70.29] (perm70-29.ij.net [209.216.70.29] (may be forged)) by emerald.lightlink.com (8.8.8/8.8.8) with SMTP id NAA26473; Thu, 7 Mar 2002 13:22:10 -0500
From: "Christopher S. Francis" <[e-mail]>
To: "Housley, Russ" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Received: from no.name.available by [209.216.70.29] via smtpd (for smtp.lightlink.com [205.232.34.14]) with SMTP; 7 Mar 2002 18:29:57 UT
Subject: RE: Attribute Certificate Policy??
Date: Thu, 7 Mar 2002 13:22:09 -0500
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 V6.00.2600.0000
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>

Russ,

I would welcome the opportunity to work with someone at the ABA on this if
you have a contact there.  Let me know how I can help.

Chris
-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Thursday, March 07, 2002 10:12 AM
To: Christopher S. Francis
Cc: [e-mail]; [e-mail]
Subject: Re: Attribute Certificate Policy??

Chris:

Perhaps we can get some of the American Bar Assoc people to comment on the
CP and CPS issues.  I suspect that we will need to go through an
educational phase before we get any useful feedaback.  Perhaps they have
been looking at it and we are just unaware...

Russ

At 02:53 PM 3/7/2002 +0000, Stephen Farrell wrote:

>Chris,
>
>I'd be against the idea of proposing this as an update to the AC profile
>for the following reasons:
>
>- The profile is in the rfc editor's queue only awaiting son-of-2359 to
>   be processed and such an update would require a re-set back to WG last
>   call (a matter of months!)
>- I don't believe that the use of policy OIDs in ACs is at all well
>   understood and therefore I'd argue to omit it from the profile (one
>   of the things we tried to do with the AC profile was to only include
>   suff that we were pretty sure could work)
>- There may be entirely different policy considerations to address,
>   depending on the context for the use of ACs (e.g. supporting roles for
>   long-term signatures vs roles for access control).
>
>So, while I'd welcome work starting on this - for both process and
>technical reasons I believe the way to handle it is to write things up in
>a separate I-D. At some point in the future (say if the AC profile were
>being cycled at proposed standard), the two things could be merged if
>appropriate.
>
>Regards,
>Stephen.
>
>
>"Christopher S. Francis" wrote:
> >
> > Sure.  I can pursue it.  Since I don't spend a lot of time here, I'm not
> > exactly sure what the appropriate process is, but what I have in mind is
to
> > do the following:
> >
> > 1) Get some clarification from ANSI and whoever else has an opinion on
> > whether X.509 offers an extension that is intended to be used to carry
> > certificate policy information in attribute certificates.  Perhaps
> > certificatePolicies, perhaps acceptablePrivilegePolicies, perhaps they
had
> > something else in mind.
> > 2) Depending on what I find out, propose an update to the PKIX attribute
> > certificate profile that includes an extension to ACs to hold policy
> > information about the issuing authority.
> >
> > Based on your earlier responses, I understand that a certificatePolicies
> > extension could be included in an AC as long as it is marked
non-critical,
> > but it that's only because *anything* can be included as an extension if
> > it's marked non-critical.  It seems to me there should be something
> specific
> > in the profile to address the issue of certificate policy.
> >
> > Chris
> > -----Original Message-----
> > From: [e-mail]
[mailto:[e-mail]]On
> > Behalf Of Housley, Russ
> > Sent: Wednesday, March 06, 2002 11:02 AM
> > To: Christopher S. Francis
> > Cc: Ietf-Pkix
> > Subject: Re: Attribute Certificate Policy??
> >
> > Chris:
> >
> > I am not aware of any work in this area.  You can take the lead.
> >
> > Russ
> >
> > At 05:41 PM 3/5/2002 -0500, Christopher S. Francis wrote:
> >
> > >Is there a defined mechanism to specify something analogous to a
> > >certificate policy in an attribute certificate?
> > >
> > >
> > >
> > >In reviewing the PKIX AC profile, I see that the syntax of the
attributes
> > >field is defined by the AttributeType OID, but rather than syntax per
se,
> > >I m looking for a way to specify the particular set of policies,
> > >practices, and procedures that the attribute authority was operating
under
> > >when it issued the attribute certificate.  Seems like this would be
> > >important to relying parties.
> > >
> > >
> > >
> > >X.509 includes an acceptablePrivilegePolicies extension that seems like
it
> > >might to the job, but it was apparently profiled out by PKIX.
> > >
> > >
> > >
> > >Chris Francis
> > >
> > >
> > >
> > >
>
>--
>____________________________________________________________
>Stephen Farrell
>Baltimore Technologies,   tel: (direct line) [phone]
>39 Parkgate Street,                     fax: [phone]
>Dublin 8.                mailto:[e-mail]
>Ireland                             http://www.baltimore.com



Received: by above.proper.com (8.11.6/8.11.3) id g27IFtQ11083 for ietf-pkix-bks; Thu, 7 Mar 2002 10:15:55 -0800 (PST)
Received: from emerald.lightlink.com (emerald.lightlink.com [205.232.34.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g27IFr811078 for <[e-mail]>; Thu, 7 Mar 2002 10:15:53 -0800 (PST)
Received: from [209.216.70.29] (perm70-29.ij.net [209.216.70.29] (may be forged)) by emerald.lightlink.com (8.8.8/8.8.8) with SMTP id NAA23239; Thu, 7 Mar 2002 13:15:42 -0500
From: "Christopher S. Francis" <[e-mail]>
To: <[e-mail]>, "Housley, Russ" <[e-mail]>
Cc: "Ietf-Pkix" <[e-mail]>
Received: from no.name.available by [209.216.70.29] via smtpd (for smtp.lightlink.com [205.232.34.14]) with SMTP; 7 Mar 2002 18:23:29 UT
Subject: RE: Attribute Certificate Policy??
Date: Thu, 7 Mar 2002 13:15:42 -0500
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)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
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>

Yuriy,

Hmm.... You certainly have more experience in this area than I do.  In
actual practice what you say may indeed be the case.  I based my comments on
what I read in X.509.

>From X.509 section 8.2.2.6 on the certificate policies extension:

"If the extension is flagged critical, it indicates that the certificate
shall only be used for the purpose, and in accordance with the rules implied
by one of the indicated certificate policies.  The rules of a particular
policy may require the certificate-using system to process the qualifier
value in a particular way.

If the extension is flagged non-critical, use of this extension does not
necessarily constrain use of the certificate to the policies listed.
However, a certificate user may require a particular policy to be present in
order to use the certificate (see 10).  Policy qualifiers may, at the option
of the certificate user, be processed or ignored."

Chris

-----Original Message-----
From: Yuriy Dzambasow [mailto:[e-mail]]
Sent: Thursday, March 07, 2002 12:29 PM
To: Christopher S. Francis; Housley, Russ
Cc: Ietf-Pkix
Subject: RE: Attribute Certificate Policy??


Chris:

...snip...

>
> In some environments, I believe that an AA might in fact want to make the
> certificatePolicies extension critical, especially if there is legal
> liability involved.  By making the extension critical it says that relying
> parties are required to accept the terms documented in the AA's CPS before
> relying on the authorizations granted in the certificate.
>
> Chris

Marking an extension critical has nothing to do with accepting terms in CPs
and CPSs.  Things like relying party agreements address this issue.

Yuriy

...snip...



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g27HTxT08786 for ietf-pkix-bks; Thu, 7 Mar 2002 09:29:59 -0800 (PST)
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 g27HTv808782 for <[e-mail]>; Thu, 7 Mar 2002 09:29:57 -0800 (PST)
Received: from smtp.digsigtrust.com by smtp1.digsigtrust.com  with ESMTP id g27HTra06312; Thu, 7 Mar 2002 10:29:53 -0700 (MST)
Received: from cc474623a (chr152dhcp1050.chrchv01.md.comcast.net [68.33.156.26]) by smtp.digsigtrust.com with SMTP id g27HROk28592; Thu, 7 Mar 2002 10:27:24 -0700 (MST)
Reply-To: <[e-mail]>
From: "Yuriy Dzambasow" <[e-mail]>
To: "Christopher S. Francis" <[e-mail]>, "Housley, Russ" <[e-mail]>
Cc: "Ietf-Pkix" <[e-mail]>
Subject: RE: Attribute Certificate Policy??
Date: Thu, 7 Mar 2002 12:28:40 -0500
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]>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
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>

Chris:

...snip...

>
> In some environments, I believe that an AA might in fact want to make the
> certificatePolicies extension critical, especially if there is legal
> liability involved.  By making the extension critical it says that relying
> parties are required to accept the terms documented in the AA's CPS before
> relying on the authorizations granted in the certificate.
>
> Chris

Marking an extension critical has nothing to do with accepting terms in CPs
and CPSs.  Things like relying party agreements address this issue.

Yuriy

...snip...



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g27GXTT06579 for ietf-pkix-bks; Thu, 7 Mar 2002 08:33:29 -0800 (PST)
Received: from worldtalk1.cooley.com (smtp-pebbles-wtalk.cooley.com [204.253.195.206]) by above.proper.com (8.11.6/8.11.3) with SMTP id g27GXR806575 for <[e-mail]>; Thu, 7 Mar 2002 08:33:27 -0800 (PST)
Received: from 10.11.50.23 by worldtalk1.cooley.com with ESMTP ( WorldSecure Server SMTP Relay(WSS) v4.5); Thu, 07 Mar 2002 08:33:12 -0800
X-Server-Uuid: c4da1ae6-7048-11d2-bc8e-00a083360239
Received: by reexchange.cooley.com with Internet Mail Service ( 5.5.2653.19) id <1X3CJ16K>; Thu, 7 Mar 2002 11:35:38 -0500
Message-ID: <[e-mail]>
From: "Sabett, Randy" <[e-mail]>
To: "'Housley, Russ '" <[e-mail]>, "'Christopher S. Francis '" <[e-mail]>
cc: "'[e-mail] '" <[e-mail]>, "Sabett, Randy" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Attribute Certificate Policy??
Date: Thu, 7 Mar 2002 11:35:34 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-WSS-ID: 109949CD104125-01-03
Content-Type: text/plain;  charset=iso-8859-1
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>

All:

I have been following this thread over the past couple of days; many
interesting issues.

I plan to discuss with the full ABA Information Security Committee
leadership during our next call (they are copied on this email as well).
It's not something at which we have been actively looking, but it is
certainly something we could consider.

Regards,

R.
_______________________________ 
Randy V. Sabett, J.D., CISSP 
Cooley Godward LLP 
One Freedom Square, Reston Town Center 
11951 Freedom Drive 
Reston, VA  20190-5601 
Direct:         703.456.8137 
Main:           703.456.8000 
Cell:           703.597.6521 
Fax:            703.456.8100 
E-Mail: [e-mail] 
http://www.cooley.com 
http://www.cooley.com/practice_and_people.ixe?section=Attorney+Biographies&i
d=SABETTRV
Broomfield * Kirkland * Menlo Park * Palo Alto * Reston * San Diego * San
Francisco 

-----Original Message-----
From: Housley, Russ
To: Christopher S. Francis
Cc: [e-mail]; [e-mail]
Sent: 3/7/2002 10:11 AM
Subject: Re: Attribute Certificate Policy??

Chris:

Perhaps we can get some of the American Bar Assoc people to comment on
the 
CP and CPS issues.  I suspect that we will need to go through an 
educational phase before we get any useful feedaback.  Perhaps they have

been looking at it and we are just unaware...

Russ

At 02:53 PM 3/7/2002 +0000, Stephen Farrell wrote:

>Chris,
>
>I'd be against the idea of proposing this as an update to the AC
profile
>for the following reasons:
>
>- The profile is in the rfc editor's queue only awaiting son-of-2359 to
>   be processed and such an update would require a re-set back to WG
last
>   call (a matter of months!)
>- I don't believe that the use of policy OIDs in ACs is at all well
>   understood and therefore I'd argue to omit it from the profile (one
>   of the things we tried to do with the AC profile was to only include
>   suff that we were pretty sure could work)
>- There may be entirely different policy considerations to address,
>   depending on the context for the use of ACs (e.g. supporting roles
for
>   long-term signatures vs roles for access control).
>
>So, while I'd welcome work starting on this - for both process and
>technical reasons I believe the way to handle it is to write things up
in
>a separate I-D. At some point in the future (say if the AC profile were
>being cycled at proposed standard), the two things could be merged if
>appropriate.
>
>Regards,
>Stephen.
>
>
>"Christopher S. Francis" wrote:
> >
> > Sure.  I can pursue it.  Since I don't spend a lot of time here, I'm
not
> > exactly sure what the appropriate process is, but what I have in
mind is to
> > do the following:
> >
> > 1) Get some clarification from ANSI and whoever else has an opinion
on
> > whether X.509 offers an extension that is intended to be used to
carry
> > certificate policy information in attribute certificates.  Perhaps
> > certificatePolicies, perhaps acceptablePrivilegePolicies, perhaps
they had
> > something else in mind.
> > 2) Depending on what I find out, propose an update to the PKIX
attribute
> > certificate profile that includes an extension to ACs to hold policy
> > information about the issuing authority.
> >
> > Based on your earlier responses, I understand that a
certificatePolicies
> > extension could be included in an AC as long as it is marked
non-critical,
> > but it that's only because *anything* can be included as an
extension if
> > it's marked non-critical.  It seems to me there should be something 
> specific
> > in the profile to address the issue of certificate policy.
> >
> > Chris
> > -----Original Message-----
> > From: [e-mail]
[mailto:[e-mail]]On
> > Behalf Of Housley, Russ
> > Sent: Wednesday, March 06, 2002 11:02 AM
> > To: Christopher S. Francis
> > Cc: Ietf-Pkix
> > Subject: Re: Attribute Certificate Policy??
> >
> > Chris:
> >
> > I am not aware of any work in this area.  You can take the lead.
> >
> > Russ
> >
> > At 05:41 PM 3/5/2002 -0500, Christopher S. Francis wrote:
> >
> > >Is there a defined mechanism to specify something analogous to a
> > >certificate policy in an attribute certificate?
> > >
> > >
> > >
> > >In reviewing the PKIX AC profile, I see that the syntax of the
attributes
> > >field is defined by the AttributeType OID, but rather than syntax
per se,
> > >I m looking for a way to specify the particular set of policies,
> > >practices, and procedures that the attribute authority was
operating under
> > >when it issued the attribute certificate.  Seems like this would be
> > >important to relying parties.
> > >
> > >
> > >
> > >X.509 includes an acceptablePrivilegePolicies extension that seems
like it
> > >might to the job, but it was apparently profiled out by PKIX.
> > >
> > >
> > >
> > >Chris Francis
> > >
> > >
> > >
> > >
>
>--
>____________________________________________________________
>Stephen Farrell
>Baltimore Technologies,   tel: (direct line) [phone]
>39 Parkgate Street,                     fax: [phone]
>Dublin 8.                mailto:[e-mail]
>Ireland                             http://www.baltimore.com

=======================================================
This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message




Received: by above.proper.com (8.11.6/8.11.3) id g27GShk06463 for ietf-pkix-bks; Thu, 7 Mar 2002 08:28:43 -0800 (PST)
Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g27GSf806455; Thu, 7 Mar 2002 08:28:41 -0800 (PST)
Received: from tsg1 ([12.81.70.34]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020307162836.JNRX13933.mtiwmhc22.worldnet.att.net@tsg1>; Thu, 7 Mar 2002 16:28:36 +0000
Message-ID: <00f901c1c5f5$141a93b0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Paul Hoffman / IMC" <[e-mail]>, "LISTS - IETF-PKIX" <[e-mail]>, <[e-mail]>
Subject: POLICTCAL THREAD: Fw: Hello. looking 4 info on Poisson group.
Date: Thu, 7 Mar 2002 08:28:12 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul remember that nasty note you sent me re: that POISSON and POISED are
the place for my motions, and here is the commentary from Harald Alvestrand
regarding that closure of that WG which seems to invalidate your commentary
to me.   Hmmmmm.

Todd

----- Original Message -----
From: "Harald Alvestrand" <[e-mail]>
To: "chiari mario" <[e-mail]>; <[e-mail]>
Sent: Thursday, March 07, 2002 7:35 AM
Subject: Re: Hello. looking 4 info on Poisson group.


>
>
> --On mandag, mars 04, 2002 15:59:41 +0100 chiari mario
> <[e-mail]> wrote:
>
> > Hello,
> >
> >
> > sorry to bother. I am looking for info on the POISSON ietf working group
> > (as it is quoted on RFC 2727, pag.13).
> >
> > However, the POISSON doesn't seem listed on
> > http://www.ietf.org/html.charters/wg-dir.html.
>
> The POISSON working group was closed a few months ago.
> There is a link "Concluded working groups" off the main WG page; while
> POISSON appears to have falllen off, you will find the charter under
>
> http://www.ietf.org/html.charters/OLD/poisson-charter.html
>
> >
> > I am trying to trace all the reference on the relationship between ISOC
> > and IETF (and related entities, as IAB)
>
> :-)
>
> >
> >
> > Any help is appreciate.
> >
> > Thanks Regards
> > mario chiari
> >
>
>
>



Received: by above.proper.com (8.11.6/8.11.3) id g27GN1V05636 for ietf-pkix-bks; Thu, 7 Mar 2002 08:23:01 -0800 (PST)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g27GMw805628 for <[e-mail]>; Thu, 7 Mar 2002 08:22:59 -0800 (PST)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g27GMxJ01195 for <[e-mail]>; Thu, 7 Mar 2002 16:22:59 GMT
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]> for <[e-mail]>; Thu, 7 Mar 2002 16:18:00 +0000
Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id QAA01723; Thu, 7 Mar 2002 16:22:57 GMT
Message-ID: <[e-mail]>
Date: Thu, 07 Mar 2002 16:23:03 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-pkalgs-supp-01.txt
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>

Russ,

"Housley, Russ" wrote:
> I think the idea is to provide the OIDs and associated syntax for
> additional public key algorithms.  Right now it only has the NTRU
> algorithms, but others could be added too.

Sure they could. But which/when? I don't recall any suggestions
of this sort, but then my memory is pretty bad sometimes.
 
> In the S/MIME WG, we have many algorithm documents.  For example:
>          Use of the IDEA Encryption Algorithm in CMS
>          Use of the CAST-128 Encryption Algorithm in CMS
>          Use of the KEA and SKIPJACK Algorithms in CMS
>          Use of the AES Encryption Algorithm and RSA-OAEP
>                   Key Transport in CMS
>          Use of ECC Algorithms in CMS
> 
> Perhaps a similar naming approach should be adopted.

I'd agree that its probably better to do that if there's 
only going to be ntru in this draft.

Cheers,
Stephen.


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


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g27GHwJ04647 for ietf-pkix-bks; Thu, 7 Mar 2002 08:17:58 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g27GHu804639 for <[e-mail]>; Thu, 7 Mar 2002 08:17:56 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 7 Mar 2002 16:17:31 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA17395 for <[e-mail]>; Thu, 7 Mar 2002 11:17:36 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g27GHr906976 for <[e-mail]>; Thu, 7 Mar 2002 11:17:53 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <GNRVHV2G>; Thu, 7 Mar 2002 11:15:41 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.121]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GNRVHV2A; Thu, 7 Mar 2002 11:15:37 -0500
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 07 Mar 2002 11:17:47 -0500
Subject: Re: I-D ACTION:draft-ietf-pkix-pkalgs-supp-01.txt
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>

Steve:

I think the idea is to provide the OIDs and associated syntax for 
additional public key algorithms.  Right now it only has the NTRU 
algorithms, but others could be added too.

In the S/MIME WG, we have many algorithm documents.  For example:
         Use of the IDEA Encryption Algorithm in CMS
         Use of the CAST-128 Encryption Algorithm in CMS
         Use of the KEA and SKIPJACK Algorithms in CMS
         Use of the AES Encryption Algorithm and RSA-OAEP
                  Key Transport in CMS
         Use of ECC Algorithms in CMS

Perhaps a similar naming approach should be adopted.

Russ

At 12:36 PM 3/7/2002 +0000, Stephen Farrell wrote:


>Can someone refresh my memory as to the intent of this draft?
>
>Its called "supplemental algorithms" but only contains details
>about ntru related stuff. If its intended to contain other
>algorithms, then I'd like to know roughly what they are or when
>to expect to see them. If not, then truth-in-advertising would
>suggest "s/supplemental/ntru/g".
>
>Thanks,
>Stephen.
>
>[e-mail] wrote:
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> > This draft is a work item of the Public-Key Infrastructure (X.509) 
> Working Group of the IETF.
> >
> >         Title           : Supplemental Algorithms and Identifiers for the
> >                           Internet X.509 Public Key Infrastructure 
> Certificate
> >                           and CRL Profile
> >         Author(s)       : A. Singer, W. Whyte
> >         Filename        : draft-ietf-pkix-pkalgs-supp-01.txt
> >         Pages           : 23
> >         Date            : 05-Mar-02
> >
> > This document specifies algorithm identifiers and ASN.1 encoding
> > formats for digital signatures and subject public keys, including
> > NTRUSign digital signatures and NTRUEncrypt and NTRUSign subject
> > public keys used in the Internet X.509 Public Key Infrastructure
> > (PKI).
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-pkix-pkalgs-supp-01.txt
> >
> > To remove yourself from the IETF Announcement list, send a message to
> > ietf-announce-request with the word unsubscribe in the body of the message.
> >
> > Internet-Drafts are also available by anonymous FTP. Login with the 
> username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> >         "get draft-ietf-pkix-pkalgs-supp-01.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> >         [e-mail].
> > In the body type:
> >         "FILE /internet-drafts/draft-ietf-pkix-pkalgs-supp-01.txt".
> >
> > NOTE:   The mail server at ietf.org can return the document in
> >         MIME-encoded form by using the "mpack" utility.  To use this
> >         feature, insert the command "ENCODING mime" before the "FILE"
> >         command.  To decode the response(s), you will need "munpack" or
> >         a MIME-compliant mail reader.  Different MIME-compliant mail 
> readers
> >         exhibit different behavior, especially when dealing with
> >         "multipart" MIME messages (i.e. documents which have been split
> >         up into multiple messages), so check your local documentation on
> >         how to manipulate these messages.
> >
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >
> > 
> ----------------------------------------------------------------------------------------------------
> > Content-Type: text/plain
> > Content-ID:     <[e-mail]>
>
>--
>____________________________________________________________
>Stephen Farrell
>Baltimore Technologies,   tel: (direct line) [phone]
>39 Parkgate Street,                     fax: [phone]
>Dublin 8.                mailto:[e-mail]
>Ireland                             http://www.baltimore.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g27FCBc29455 for ietf-pkix-bks; Thu, 7 Mar 2002 07:12:11 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g27FC9829450 for <[e-mail]>; Thu, 7 Mar 2002 07:12:10 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 7 Mar 2002 15:11:45 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA09892; Thu, 7 Mar 2002 10:11:47 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g27FC6D26595; Thu, 7 Mar 2002 10:12:07 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <GNRVHTZ3>; Thu, 7 Mar 2002 10:09:53 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.122]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GNRVHTZN; Thu, 7 Mar 2002 10:09:50 -0500
From: "Housley, Russ" <[e-mail]>
To: "Christopher S. Francis" <[e-mail]>
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 07 Mar 2002 10:11:58 -0500
Subject: Re: Attribute Certificate Policy??
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>

Chris:

Perhaps we can get some of the American Bar Assoc people to comment on the 
CP and CPS issues.  I suspect that we will need to go through an 
educational phase before we get any useful feedaback.  Perhaps they have 
been looking at it and we are just unaware...

Russ

At 02:53 PM 3/7/2002 +0000, Stephen Farrell wrote:

>Chris,
>
>I'd be against the idea of proposing this as an update to the AC profile
>for the following reasons:
>
>- The profile is in the rfc editor's queue only awaiting son-of-2359 to
>   be processed and such an update would require a re-set back to WG last
>   call (a matter of months!)
>- I don't believe that the use of policy OIDs in ACs is at all well
>   understood and therefore I'd argue to omit it from the profile (one
>   of the things we tried to do with the AC profile was to only include
>   suff that we were pretty sure could work)
>- There may be entirely different policy considerations to address,
>   depending on the context for the use of ACs (e.g. supporting roles for
>   long-term signatures vs roles for access control).
>
>So, while I'd welcome work starting on this - for both process and
>technical reasons I believe the way to handle it is to write things up in
>a separate I-D. At some point in the future (say if the AC profile were
>being cycled at proposed standard), the two things could be merged if
>appropriate.
>
>Regards,
>Stephen.
>
>
>"Christopher S. Francis" wrote:
> >
> > Sure.  I can pursue it.  Since I don't spend a lot of time here, I'm not
> > exactly sure what the appropriate process is, but what I have in mind is to
> > do the following:
> >
> > 1) Get some clarification from ANSI and whoever else has an opinion on
> > whether X.509 offers an extension that is intended to be used to carry
> > certificate policy information in attribute certificates.  Perhaps
> > certificatePolicies, perhaps acceptablePrivilegePolicies, perhaps they had
> > something else in mind.
> > 2) Depending on what I find out, propose an update to the PKIX attribute
> > certificate profile that includes an extension to ACs to hold policy
> > information about the issuing authority.
> >
> > Based on your earlier responses, I understand that a certificatePolicies
> > extension could be included in an AC as long as it is marked non-critical,
> > but it that's only because *anything* can be included as an extension if
> > it's marked non-critical.  It seems to me there should be something 
> specific
> > in the profile to address the issue of certificate policy.
> >
> > Chris
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]On
> > Behalf Of Housley, Russ
> > Sent: Wednesday, March 06, 2002 11:02 AM
> > To: Christopher S. Francis
> > Cc: Ietf-Pkix
> > Subject: Re: Attribute Certificate Policy??
> >
> > Chris:
> >
> > I am not aware of any work in this area.  You can take the lead.
> >
> > Russ
> >
> > At 05:41 PM 3/5/2002 -0500, Christopher S. Francis wrote:
> >
> > >Is there a defined mechanism to specify something analogous to a
> > >certificate policy in an attribute certificate?
> > >
> > >
> > >
> > >In reviewing the PKIX AC profile, I see that the syntax of the attributes
> > >field is defined by the AttributeType OID, but rather than syntax per se,
> > >I m looking for a way to specify the particular set of policies,
> > >practices, and procedures that the attribute authority was operating under
> > >when it issued the attribute certificate.  Seems like this would be
> > >important to relying parties.
> > >
> > >
> > >
> > >X.509 includes an acceptablePrivilegePolicies extension that seems like it
> > >might to the job, but it was apparently profiled out by PKIX.
> > >
> > >
> > >
> > >Chris Francis
> > >
> > >
> > >
> > >
>
>--
>____________________________________________________________
>Stephen Farrell
>Baltimore Technologies,   tel: (direct line) [phone]
>39 Parkgate Street,                     fax: [phone]
>Dublin 8.                mailto:[e-mail]
>Ireland                             http://www.baltimore.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g27ExRN28870 for ietf-pkix-bks; Thu, 7 Mar 2002 06:59:27 -0800 (PST)
Received: from emerald.lightlink.com (emerald.lightlink.com [205.232.34.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g27ExQ828866 for <[e-mail]>; Thu, 7 Mar 2002 06:59:26 -0800 (PST)
Received: from [209.216.70.29] (perm70-29.ij.net [209.216.70.29] (may be forged)) by emerald.lightlink.com (8.8.8/8.8.8) with SMTP id JAA14645; Thu, 7 Mar 2002 09:59:23 -0500
From: "Christopher S. Francis" <[e-mail]>
To: "Housley, Russ" <[e-mail]>
Cc: "Ietf-Pkix" <[e-mail]>
Received: from no.name.available by [209.216.70.29] via smtpd (for smtp.lightlink.com [205.232.34.14]) with SMTP; 7 Mar 2002 15:07:10 UT
Subject: RE: Attribute Certificate Policy??
Date: Thu, 7 Mar 2002 09:59:22 -0500
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 V6.00.2600.0000
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>

Russ,

An AA CPS would include many of the same things that would be present in a
CA's CPS.  These would include things like: community and applicability for
the ACs issued, statements of liability, issuer/end-entity/relying party
obligations, restrictions on usage of the AC, technical security controls
for the AA's signing key, etc.

In some environments, I believe that an AA might in fact want to make the
certificatePolicies extension critical, especially if there is legal
liability involved.  By making the extension critical it says that relying
parties are required to accept the terms documented in the AA's CPS before
relying on the authorizations granted in the certificate.

Chris


-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Thursday, March 07, 2002 9:21 AM
To: Christopher S. Francis
Cc: Ietf-Pkix
Subject: RE: Attribute Certificate Policy??

Chris:

I think that certificatePolicies is the correct extension to use.  The
profile does not need to be updated unless you think that there is a reason
to mark it critical.

What goes the the CP and CPS for an AA?

Russ

At 08:57 AM 3/7/2002 -0500, Christopher S. Francis wrote:
>Sure.  I can pursue it.  Since I don't spend a lot of time here, I'm not
>exactly sure what the appropriate process is, but what I have in mind is to
>do the following:
>
>1) Get some clarification from ANSI and whoever else has an opinion on
>whether X.509 offers an extension that is intended to be used to carry
>certificate policy information in attribute certificates.  Perhaps
>certificatePolicies, perhaps acceptablePrivilegePolicies, perhaps they had
>something else in mind.
>2) Depending on what I find out, propose an update to the PKIX attribute
>certificate profile that includes an extension to ACs to hold policy
>information about the issuing authority.
>
>Based on your earlier responses, I understand that a certificatePolicies
>extension could be included in an AC as long as it is marked non-critical,
>but it that's only because *anything* can be included as an extension if
>it's marked non-critical.  It seems to me there should be something
specific
>in the profile to address the issue of certificate policy.
>
>Chris
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]]On
>Behalf Of Housley, Russ
>Sent: Wednesday, March 06, 2002 11:02 AM
>To: Christopher S. Francis
>Cc: Ietf-Pkix
>Subject: Re: Attribute Certificate Policy??
>
>
>Chris:
>
>I am not aware of any work in this area.  You can take the lead.
>
>Russ
>
>
>At 05:41 PM 3/5/2002 -0500, Christopher S. Francis wrote:
>
> >Is there a defined mechanism to specify something analogous to a
> >certificate policy in an attribute certificate?
> >
> >
> >
> >In reviewing the PKIX AC profile, I see that the syntax of the attributes
> >field is defined by the AttributeType OID, but rather than syntax per se,
> >I m looking for a way to specify the particular set of policies,
> >practices, and procedures that the attribute authority was operating
under
> >when it issued the attribute certificate.  Seems like this would be
> >important to relying parties.
> >
> >
> >
> >X.509 includes an acceptablePrivilegePolicies extension that seems like
it
> >might to the job, but it was apparently profiled out by PKIX.
> >
> >
> >
> >Chris Francis
> >
> >
> >
> >



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g27Er0628741 for ietf-pkix-bks; Thu, 7 Mar 2002 06:53:00 -0800 (PST)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g27Eqw828735 for <[e-mail]>; Thu, 7 Mar 2002 06:52:58 -0800 (PST)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g27EqwJ29916 for <[e-mail]>; Thu, 7 Mar 2002 14:52:58 GMT
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]> for <[e-mail]>; Thu, 7 Mar 2002 14:47:59 +0000
Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id OAA32019; Thu, 7 Mar 2002 14:52:54 GMT
Message-ID: <[e-mail]>
Date: Thu, 07 Mar 2002 14:53:00 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Christopher S. Francis" <[e-mail]>
CC: "Housley, Russ" <[e-mail]>, Ietf-Pkix <[e-mail]>
Subject: Re: Attribute Certificate Policy??
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>

Chris,

I'd be against the idea of proposing this as an update to the AC profile
for the following reasons:

- The profile is in the rfc editor's queue only awaiting son-of-2359 to
  be processed and such an update would require a re-set back to WG last
  call (a matter of months!)
- I don't believe that the use of policy OIDs in ACs is at all well 
  understood and therefore I'd argue to omit it from the profile (one
  of the things we tried to do with the AC profile was to only include
  suff that we were pretty sure could work)
- There may be entirely different policy considerations to address, 
  depending on the context for the use of ACs (e.g. supporting roles for 
  long-term signatures vs roles for access control). 
  
So, while I'd welcome work starting on this - for both process and
technical reasons I believe the way to handle it is to write things up in 
a separate I-D. At some point in the future (say if the AC profile were
being cycled at proposed standard), the two things could be merged if
appropriate.

Regards,
Stephen.


"Christopher S. Francis" wrote:
> 
> Sure.  I can pursue it.  Since I don't spend a lot of time here, I'm not
> exactly sure what the appropriate process is, but what I have in mind is to
> do the following:
> 
> 1) Get some clarification from ANSI and whoever else has an opinion on
> whether X.509 offers an extension that is intended to be used to carry
> certificate policy information in attribute certificates.  Perhaps
> certificatePolicies, perhaps acceptablePrivilegePolicies, perhaps they had
> something else in mind.
> 2) Depending on what I find out, propose an update to the PKIX attribute
> certificate profile that includes an extension to ACs to hold policy
> information about the issuing authority.
> 
> Based on your earlier responses, I understand that a certificatePolicies
> extension could be included in an AC as long as it is marked non-critical,
> but it that's only because *anything* can be included as an extension if
> it's marked non-critical.  It seems to me there should be something specific
> in the profile to address the issue of certificate policy.
> 
> Chris
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Housley, Russ
> Sent: Wednesday, March 06, 2002 11:02 AM
> To: Christopher S. Francis
> Cc: Ietf-Pkix
> Subject: Re: Attribute Certificate Policy??
> 
> Chris:
> 
> I am not aware of any work in this area.  You can take the lead.
> 
> Russ
> 
> At 05:41 PM 3/5/2002 -0500, Christopher S. Francis wrote:
> 
> >Is there a defined mechanism to specify something analogous to a
> >certificate policy in an attribute certificate?
> >
> >
> >
> >In reviewing the PKIX AC profile, I see that the syntax of the attributes
> >field is defined by the AttributeType OID, but rather than syntax per se,
> >I m looking for a way to specify the particular set of policies,
> >practices, and procedures that the attribute authority was operating under
> >when it issued the attribute certificate.  Seems like this would be
> >important to relying parties.
> >
> >
> >
> >X.509 includes an acceptablePrivilegePolicies extension that seems like it
> >might to the job, but it was apparently profiled out by PKIX.
> >
> >
> >
> >Chris Francis
> >
> >
> >
> >

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


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g27EZ4Y28003 for ietf-pkix-bks; Thu, 7 Mar 2002 06:35:04 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g27EZ2827999 for <[e-mail]>; Thu, 7 Mar 2002 06:35:02 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 7 Mar 2002 14:34:37 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA05838 for <[e-mail]>; Thu, 7 Mar 2002 09:34:42 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g27EZ1i21197 for <[e-mail]>; Thu, 7 Mar 2002 09:35:01 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <GNRVHTCC>; Thu, 7 Mar 2002 09:32:48 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.122]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GNRVHTB8; Thu, 7 Mar 2002 09:32:45 -0500
From: "Housley, Russ" <[e-mail]>
To: "Christopher S. Francis" <[e-mail]>
Cc: Ietf-Pkix <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 07 Mar 2002 09:21:15 -0500
Subject: RE: Attribute Certificate Policy??
In-Reply-To: <[e-mail] m>
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>

Chris:

I think that certificatePolicies is the correct extension to use.  The 
profile does not need to be updated unless you think that there is a reason 
to mark it critical.

What goes the the CP and CPS for an AA?

Russ

At 08:57 AM 3/7/2002 -0500, Christopher S. Francis wrote:
>Sure.  I can pursue it.  Since I don't spend a lot of time here, I'm not
>exactly sure what the appropriate process is, but what I have in mind is to
>do the following:
>
>1) Get some clarification from ANSI and whoever else has an opinion on
>whether X.509 offers an extension that is intended to be used to carry
>certificate policy information in attribute certificates.  Perhaps
>certificatePolicies, perhaps acceptablePrivilegePolicies, perhaps they had
>something else in mind.
>2) Depending on what I find out, propose an update to the PKIX attribute
>certificate profile that includes an extension to ACs to hold policy
>information about the issuing authority.
>
>Based on your earlier responses, I understand that a certificatePolicies
>extension could be included in an AC as long as it is marked non-critical,
>but it that's only because *anything* can be included as an extension if
>it's marked non-critical.  It seems to me there should be something specific
>in the profile to address the issue of certificate policy.
>
>Chris
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]]On
>Behalf Of Housley, Russ
>Sent: Wednesday, March 06, 2002 11:02 AM
>To: Christopher S. Francis
>Cc: Ietf-Pkix
>Subject: Re: Attribute Certificate Policy??
>
>
>Chris:
>
>I am not aware of any work in this area.  You can take the lead.
>
>Russ
>
>
>At 05:41 PM 3/5/2002 -0500, Christopher S. Francis wrote:
>
> >Is there a defined mechanism to specify something analogous to a
> >certificate policy in an attribute certificate?
> >
> >
> >
> >In reviewing the PKIX AC profile, I see that the syntax of the attributes
> >field is defined by the AttributeType OID, but rather than syntax per se,
> >I m looking for a way to specify the particular set of policies,
> >practices, and procedures that the attribute authority was operating under
> >when it issued the attribute certificate.  Seems like this would be
> >important to relying parties.
> >
> >
> >
> >X.509 includes an acceptablePrivilegePolicies extension that seems like it
> >might to the job, but it was apparently profiled out by PKIX.
> >
> >
> >
> >Chris Francis
> >
> >
> >
> >


Received: by above.proper.com (8.11.6/8.11.3) id g27EEEH27477 for ietf-pkix-bks; Thu, 7 Mar 2002 06:14:14 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g27EEC827473 for <[e-mail]>; Thu, 7 Mar 2002 06:14:12 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA28238; Thu, 7 Mar 2002 15:13:40 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Thu, 7 Mar 2002 15:13:40 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id PAA02815; Thu, 7 Mar 2002 15:13:31 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA23028; Thu, 7 Mar 2002 15:13:30 +0100 (MET)
Date: Thu, 7 Mar 2002 15:13:30 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: DPD/DPV reqmts: hash of the request
Cc: [e-mail], [e-mail], [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>

> Mike,
> 
> do I understand you correctly, that you propose to mark the
> requirement (binding the response back to the request) as
> optional and leave it up to the implementation of the DPV
> client and server to realize this binding?
No. a server always has an implemention and MUST react on
whatever the client desires (or not, if policy does not allow this).

> I'm afraid this will lead to unnecessary interoperability problems
> between implementations of a DPV client and server, e.g. if a
> client implementation requires this binding, but it's not implemented
Your concern probably does not apply for this particular case, 
but rather to another set of policy related request that a server
may make, if the protocol allows to add almost arbitrary indications
defined by a completely open set of OIDs for example of what a
client can request.


> at the server. If we feel that the binding adds value to the protocol
> - and I think it does - we should mandate its use! You can still
> cache the information and re-use them, you just cannot preproduce
> the whole response.
The requirement is to mandate a correct reaction if used by a client.
Indeed, as already said, one can preproduce some information but
maybe not the complete response.

Peter


Received: by above.proper.com (8.11.6/8.11.3) id g27Dw6326411 for ietf-pkix-bks; Thu, 7 Mar 2002 05:58:06 -0800 (PST)
Received: from emerald.lightlink.com (emerald.lightlink.com [205.232.34.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g27Dw4826403 for <[e-mail]>; Thu, 7 Mar 2002 05:58:05 -0800 (PST)
Received: from [209.216.70.29] (perm70-29.ij.net [209.216.70.29] (may be forged)) by emerald.lightlink.com (8.8.8/8.8.8) with SMTP id IAA14902; Thu, 7 Mar 2002 08:57:49 -0500
From: "Christopher S. Francis" <[e-mail]>
To: "Housley, Russ" <[e-mail]>
Cc: "Ietf-Pkix" <[e-mail]>
Received: from no.name.available by [209.216.70.29] via smtpd (for smtp.lightlink.com [205.232.34.14]) with SMTP; 7 Mar 2002 14:05:36 UT
Subject: RE: Attribute Certificate Policy??
Date: Thu, 7 Mar 2002 08:57:48 -0500
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 V6.00.2600.0000
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>

Sure.  I can pursue it.  Since I don't spend a lot of time here, I'm not
exactly sure what the appropriate process is, but what I have in mind is to
do the following:

1) Get some clarification from ANSI and whoever else has an opinion on
whether X.509 offers an extension that is intended to be used to carry
certificate policy information in attribute certificates.  Perhaps
certificatePolicies, perhaps acceptablePrivilegePolicies, perhaps they had
something else in mind.
2) Depending on what I find out, propose an update to the PKIX attribute
certificate profile that includes an extension to ACs to hold policy
information about the issuing authority.

Based on your earlier responses, I understand that a certificatePolicies
extension could be included in an AC as long as it is marked non-critical,
but it that's only because *anything* can be included as an extension if
it's marked non-critical.  It seems to me there should be something specific
in the profile to address the issue of certificate policy.

Chris
-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Housley, Russ
Sent: Wednesday, March 06, 2002 11:02 AM
To: Christopher S. Francis
Cc: Ietf-Pkix
Subject: Re: Attribute Certificate Policy??


Chris:

I am not aware of any work in this area.  You can take the lead.

Russ


At 05:41 PM 3/5/2002 -0500, Christopher S. Francis wrote:

>Is there a defined mechanism to specify something analogous to a
>certificate policy in an attribute certificate?
>
>
>
>In reviewing the PKIX AC profile, I see that the syntax of the attributes
>field is defined by the AttributeType OID, but rather than syntax per se,
>I m looking for a way to specify the particular set of policies,
>practices, and procedures that the attribute authority was operating under
>when it issued the attribute certificate.  Seems like this would be
>important to relying parties.
>
>
>
>X.509 includes an acceptablePrivilegePolicies extension that seems like it
>might to the job, but it was apparently profiled out by PKIX.
>
>
>
>Chris Francis
>
>
>
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g27Ca4719711 for ietf-pkix-bks; Thu, 7 Mar 2002 04:36:04 -0800 (PST)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g27Ca2819704 for <[e-mail]>; Thu, 7 Mar 2002 04:36:02 -0800 (PST)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g27Ca2J26710 for <[e-mail]>; Thu, 7 Mar 2002 12:36:02 GMT
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]> for <[e-mail]>; Thu, 7 Mar 2002 12:31:02 +0000
Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id MAA29915 for <[e-mail]>; Thu, 7 Mar 2002 12:35:58 GMT
Message-ID: <[e-mail]>
Date: Thu, 07 Mar 2002 12:36:05 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-pkalgs-supp-01.txt
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>

Can someone refresh my memory as to the intent of this draft? 

Its called "supplemental algorithms" but only contains details 
about ntru related stuff. If its intended to contain other 
algorithms, then I'd like to know roughly what they are or when 
to expect to see them. If not, then truth-in-advertising would 
suggest "s/supplemental/ntru/g".

Thanks,
Stephen.

[e-mail] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.
> 
>         Title           : Supplemental Algorithms and Identifiers for the
>                           Internet X.509 Public Key Infrastructure Certificate
>                           and CRL Profile
>         Author(s)       : A. Singer, W. Whyte
>         Filename        : draft-ietf-pkix-pkalgs-supp-01.txt
>         Pages           : 23
>         Date            : 05-Mar-02
> 
> This document specifies algorithm identifiers and ASN.1 encoding
> formats for digital signatures and subject public keys, including
> NTRUSign digital signatures and NTRUEncrypt and NTRUSign subject
> public keys used in the Internet X.509 Public Key Infrastructure
> (PKI).
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-pkalgs-supp-01.txt
> 
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the message.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>         "get draft-ietf-pkix-pkalgs-supp-01.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
>         [e-mail].
> In the body type:
>         "FILE /internet-drafts/draft-ietf-pkix-pkalgs-supp-01.txt".
> 
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
> 
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
>   ----------------------------------------------------------------------------------------------------
> Content-Type: text/plain
> Content-ID:     <[e-mail]>

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


Received: by above.proper.com (8.11.6/8.11.3) id g27BwXp17990 for ietf-pkix-bks; Thu, 7 Mar 2002 03:58:33 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g27BwW817984 for <[e-mail]>; Thu, 7 Mar 2002 03:58:32 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18457; Thu, 7 Mar 2002 06:58:29 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-scvp-08.txt
Date: Thu, 07 Mar 2002 06:58:29 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Simple Certificate Validation Protocol (SCVP)
	Author(s)	: A. Malpani, R. Housley, T. Freeman
	Filename	: draft-ietf-pkix-scvp-08.txt
	Pages		: 
	Date		: 06-Mar-02
	
The SCVP protocol allows a client to offload certificate handling to a
server. The server can give a variety of valuable information about
the certificate, such as whether or not the certificate is valid, a
certification path to a trust anchor, and so on. SCVP has many
purposes, including simplifying client implementations and allowing
companies to centralize their trust and policy management.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-scvp-08.txt

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

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

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.6/8.11.3) id g27BwS817982 for ietf-pkix-bks; Thu, 7 Mar 2002 03:58:28 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g27BwR817977 for <[e-mail]>; Thu, 7 Mar 2002 03:58:28 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18445; Thu, 7 Mar 2002 06:58:25 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-proxy-02.txt
Date: Thu, 07 Mar 2002 06:58:25 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Proxy 
                          Certificate Profile
	Author(s)	: S. Tuecke et al.
	Filename	: draft-ietf-pkix-proxy-02.txt
	Pages		: 37
	Date		: 06-Mar-02
	
This document forms a certificate profile for Proxy Certificates, 
based on X.509 PKI certificates as defined in draft-ietf-pkix-new-
part1-08.txt (the draft update to RFC 2459), for use in the 
Internet.  The term Proxy Certificate is used to describe a 
certificate that is derived from, and signed by, a normal X.509 
Public Key End Entity Certificate or by another Proxy Certificate 
for the purpose of providing restricted impersonation within a PKI 
based authentication system.  This draft replaces draft-ietf-pkix-
impersonation-00.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-proxy-02.txt

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

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

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.6/8.11.3) id g27BwRu17975 for ietf-pkix-bks; Thu, 7 Mar 2002 03:58:27 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g27BwQ817971 for <[e-mail]>; Thu, 7 Mar 2002 03:58:26 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18406; Thu, 7 Mar 2002 06:58:11 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-acrmf-01.txt
Date: Thu, 07 Mar 2002 06:58:11 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Attribute Certificate Request Message Format
	Author(s)	: P. Yee
	Filename	: draft-ietf-pkix-acrmf-01.txt
	Pages		: 8
	Date		: 06-Mar-02
	
The Certificate Request Message Format ([CRMF]) specifies a format
for requesting an X.509 public key certificate from a Certification
Authority (CA), possibly with assistance from an Local Registration
Authority (LRA).  This specification, ACRMF, is modeled on CRMF,
extending similar functionality to requests for X.509 attribute cer-
tificates from Attribute Authorities (AA), possibly via an Attribute
Registration Authority (ARA).

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-acrmf-01.txt

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

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

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.6/8.11.3) id g27BwOL17969 for ietf-pkix-bks; Thu, 7 Mar 2002 03:58:24 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g27BwN817965 for <[e-mail]>; Thu, 7 Mar 2002 03:58:23 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18433; Thu, 7 Mar 2002 06:58:21 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-2797-bis-01.txt
Date: Thu, 07 Mar 2002 06:58:21 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Certificate Management Messages over CMS
	Author(s)	: M. Myers, X. Liu, J. Schaad, J. Weinstein
	Filename	: draft-ietf-pkix-2797-bis-01.txt
	Pages		: 
	Date		: 06-Mar-02
	
This document defines a Certificate Management protocol using CMS
(CMC).  This protocol addresses two immediate needs within the
Internet PKI community:
1. The need for an interface to public key certification products
and    services based on [CMS] and [PKCS10], and
2. The need in [SMIMEV3] for a certificate enrollment protocol for
DSA-signed certificates with Diffie-Hellman public keys.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-2797-bis-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-2797-bis-01.txt

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

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

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.6/8.11.3) id g27BwKt17961 for ietf-pkix-bks; Thu, 7 Mar 2002 03:58:20 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g27BwJ817957 for <[e-mail]>; Thu, 7 Mar 2002 03:58:19 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18421; Thu, 7 Mar 2002 06:58:16 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-cmc-trans-01.txt
Date: Thu, 07 Mar 2002 06:58:16 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: CMC Transport
	Author(s)	: M. Myers, J. Schaad, X. Liu, J. Weinstein
	Filename	: draft-ietf-pkix-cmc-trans-01.txt
	Pages		: 
	Date		: 06-Mar-02
	
This document defines a number of transport mechanisms that are used
to move [CMC] messages.  The transport mechanisms described in this
document are: HTTP, file, mail and TCP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmc-trans-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-cmc-trans-01.txt

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

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

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.6/8.11.3) id g27BwAv17951 for ietf-pkix-bks; Thu, 7 Mar 2002 03:58:10 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g27Bw9817947 for <[e-mail]>; Thu, 7 Mar 2002 03:58:09 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18394; Thu, 7 Mar 2002 06:58:07 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-acmc-01.txt
Date: Thu, 07 Mar 2002 06:58:06 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Attribute Certificate Management Messages over CMS
	Author(s)	: P. Yee
	Filename	: draft-ietf-pkix-acmc-01.txt
	Pages		: 10
	Date		: 06-Mar-02
	
This document specifies modifications to the Certificate Management
Messages over CMS specification ([CMCbis]) to permit the management
of attribute certificates.  This document does not stand alone, but
must be used in conjunction with [CMCbis].  It is expected that the
modifications proposed here will also be used in conjunction with the
Attribute Certificate Request Message Format specification ([ACRMF]).

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-acmc-01.txt

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g26MlWF25371 for ietf-pkix-bks; Wed, 6 Mar 2002 14:47:32 -0800 (PST)
Received: from geos.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g26MlV825367 for <[e-mail]>; Wed, 6 Mar 2002 14:47:31 -0800 (PST)
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 g26MlC218368; Wed, 6 Mar 2002 14:47:12 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "Petra Barzin" <[e-mail]>
Cc: "Housley, Russ" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: DPD/DPV reqmts: hash of the request
Date: Wed, 6 Mar 2002 14:44:41 -0800
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>

Petra,

The proposal is that both client and server are forced to have
this functionality in their code in order to claim compliance,
but that use of the functionality is a local matter.

Peter Sylvester's proposed text had it just about right:  "The
protocol MUST provide a means permitting a client to associate a
response to a request."  The key phrase there is "provide a
means".  In my view, "provide a means" means every client and
every server is functionally capable of one-to-one binding, but
MAY be operated in a fashion that does not support the practice.

This operational flexibility would be most relevant to those
environments who find the latency reduction effects of
pre-produced responses useful to their associated community.
More rigorous environments, such as those you may be
representing, are nonetheless assured that the functionality you
need will be there no matter what implementation you choose to
use.

But given the assurance of implementation compliance, these
issues can be resolved via a simple config file change or
whatever other means is used to control the behavior.  An
obscure Windows registry tweak or whatever.  The important thing
is that the functionality be there to enable that operational
negotiation.  I think that's the best we can do given the
diverse communities we serve.

If however you are advocating for a uniform operational
practice, we should probably strike a new thread on that one.

Mike


> -----Original Message-----
> From: Petra Barzin [mailto:[e-mail]]
> Sent: Wednesday, March 06, 2002 1:37 PM
> To: Michael Myers
> Cc: Housley, Russ; [e-mail]; [e-mail]
> Subject: Re: DPD/DPV reqmts: hash of the request
>
>
> Mike,
>
> do I understand you correctly, that you propose to mark the
> requirement (binding the response back to the request) as
> optional and leave it up to the implementation of the DPV
> client and server to realize this binding?
> I'm afraid this will lead to unnecessary
> interoperability problems
> between implementations of a DPV client and server, e.g. if a
> client implementation requires this binding, but it's
> not implemented
> at the server. If we feel that the binding adds value
> to the protocol
> - and I think it does - we should mandate its use!
> You can still
> cache the information and re-use them, you just
> cannot preproduce
> the whole response.
>
> Petra
>
> Michael Myers schrieb:
>
> > Petra,
> >
> > In my opinion we should enable the practice by ensuring the
> > capability is in running code but not mandate its use in all
> > circumstances.  Do you find this approach acceptable?
> >
> > Mike
> >
> > > -----Original Message-----
> > > From: Petra Barzin [mailto:[e-mail]]
> > > Sent: Tuesday, March 05, 2002 12:17 PM
> > > To: Housley, Russ
> > > Cc: '[e-mail] '; '[e-mail] ';
> > > [e-mail]
> > > Subject: Re: DPD/DPV reqmts: hash of the request
> > >
> > >
> > > Yes, the requirement is to bind the response back to
> > > the request!
> > > Sorry for the technical discussion at this point.
> > > I'd see the requirement as a MUST, but I can see
> > > Michael's concern
> > > that it prevents the use of pre-produced responses.
> > > But I think it is very important that the sender of a
> > > DPV request
> > > is able to match the received response to his request
> > > in order to
> > > make sure that no man in the middle changed his
> > > validation request.
> > >
> > > - Petra
> > >
> > > "Housley, Russ" schrieb:
> > >
> > > > In my opinion, the requirement is to bind the
> > > respponse back to the request.
> > > > Two obvious was to accomplish this binding are to
> > > include all of the fields
> > > > of the request in the response and to include a
> > > hash of the request in the
> > > > response.  Since we are working on the requirements
> > > doucment, we should
> > > > stict to requirements, not mechanisms for
> > > implementing the requirements.
> > > >
> > > > Russ
> > > >
> > > > -----Original Message-----
> > > > From: Petra Barzin
> > > > To: [e-mail]
> > > > Cc: [e-mail]
> > > > Sent: 3/3/02 3:48 PM
> > > > Subject: DPD/DPV reqmts: hash of the request
> > > >
> > > > Denis,
> > > >
> > > > I don't see why you differentiate between signed
> > > and authenticated
> > > > responses. The same is true for signed responses:
> > > either the hash of
> > > > the request or the important elements from the
> > > request must be present.
> > > > In order to test the response against what has been
> > > requested the client
> > > >
> > > > has to keep his request or at least the hash of
> his request.
> > > >
> > > > The advantage of a hash - instead of copying all
> > > important elements
> > > > from the request -  is:
> > > > (a) that the response will be smaller and
> > > > (b) adding a new important element to the request
> > > doesn't require a
> > > > change of the response.
> > > >
> > > > - a hash of the request MUST be included in the
> response.
> > > >
> > > >   This may allow the client to check if his request
> > > was maliciously
> > > >
> > > >   modified (if the response is signed) and helps to
> > > associate the
> > > >
> > > >   response with his request when using
> > > connectionless protocols.
> > > >
> > > >   [Answer 1] The requirements are different whether
> > > the requester simply
> > > > wants
> > > >
> > > >   an authenticated response or a signed response.
> > > For a signed response
> > > > the
> > > >
> > > >   inclusion of the important elements from the
> > > request is needed, so
> > > > that a
> > > >
> > > >   response can be individually tested against what
> > > has been requested.
> > > > For an
> > > >
> > > >   authenticated response, the hash of the request
> > > is sufficient. To
> > > > summarize:
> > > >
> > > >   - for signed responses, the important elements
> > > from the request
> > > >
> > > >     must be present.
> > > >
> > > >   - for authenticated responses, either the hash of
> > > the request or the
> > > >
> > > >     important elements from the request must be present.
> > > >
> > > > - Petra
> > >
> > >
>
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g26MghG25205 for ietf-pkix-bks; Wed, 6 Mar 2002 14:42:43 -0800 (PST)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g26Mgg825201 for <[e-mail]>; Wed, 6 Mar 2002 14:42:42 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 6 Mar 2002 14:42:03 -0800 (PST)
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, 06 Mar 2002 14:42:03 -0800 (PST)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <GK1PPGR1>; Wed, 06 Mar 2002 14:42:38 -0800
Content-return: allowed
Date: Wed, 06 Mar 2002 14:42:37 -0800
From: Peter Williams <[e-mail]>
Subject: RE: DPD/DPV reqmts: hash of the request
To: "'Petra Barzin'" <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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>

Can you state a rationale why DPV/DPD
design on the issue should be different to the 
OCSP design on the same issue? 

OCSP supports pre-calculated OCSP responses,
based on OCSP relaying certificate status information
from a repository.

Why should DPV not support pre-calculation
of one or more sets of validation policy rules against
a chain of certificates?

Is there a basis for believing that DPV protocol 
is more vulnerable that OCSP protocol in respect
of the known risks of using pre-calculated (i.e. cached)
results?

Accessing a historical repository of DPV results
will be quite common, I expectm in support of NR. 
Periodically,
the operator will calculate for a large
number of certificates with historical
certificate status what the validation policy
would have been, if evaluated at that historical
point in time. 

-----Original Message-----
From: Petra Barzin [mailto:[e-mail]]
Sent: Wednesday, March 06, 2002 1:37 PM
To: Michael Myers
Cc: Housley, Russ; [e-mail]; [e-mail]
Subject: Re: DPD/DPV reqmts: hash of the request



Mike,

do I understand you correctly, that you propose to mark the
requirement (binding the response back to the request) as
optional and leave it up to the implementation of the DPV
client and server to realize this binding?
I'm afraid this will lead to unnecessary interoperability problems
between implementations of a DPV client and server, e.g. if a
client implementation requires this binding, but it's not implemented
at the server. If we feel that the binding adds value to the protocol
- and I think it does - we should mandate its use! You can still
cache the information and re-use them, you just cannot preproduce
the whole response.

Petra

Michael Myers schrieb:

> Petra,
>
> In my opinion we should enable the practice by ensuring the
> capability is in running code but not mandate its use in all
> circumstances.  Do you find this approach acceptable?
>
> Mike
>
> > -----Original Message-----
> > From: Petra Barzin [mailto:[e-mail]]
> > Sent: Tuesday, March 05, 2002 12:17 PM
> > To: Housley, Russ
> > Cc: '[e-mail] '; '[e-mail] ';
> > [e-mail]
> > Subject: Re: DPD/DPV reqmts: hash of the request
> >
> >
> > Yes, the requirement is to bind the response back to
> > the request!
> > Sorry for the technical discussion at this point.
> > I'd see the requirement as a MUST, but I can see
> > Michael's concern
> > that it prevents the use of pre-produced responses.
> > But I think it is very important that the sender of a
> > DPV request
> > is able to match the received response to his request
> > in order to
> > make sure that no man in the middle changed his
> > validation request.
> >
> > - Petra
> >
> > "Housley, Russ" schrieb:
> >
> > > In my opinion, the requirement is to bind the
> > respponse back to the request.
> > > Two obvious was to accomplish this binding are to
> > include all of the fields
> > > of the request in the response and to include a
> > hash of the request in the
> > > response.  Since we are working on the requirements
> > doucment, we should
> > > stict to requirements, not mechanisms for
> > implementing the requirements.
> > >
> > > Russ
> > >
> > > -----Original Message-----
> > > From: Petra Barzin
> > > To: [e-mail]
> > > Cc: [e-mail]
> > > Sent: 3/3/02 3:48 PM
> > > Subject: DPD/DPV reqmts: hash of the request
> > >
> > > Denis,
> > >
> > > I don't see why you differentiate between signed
> > and authenticated
> > > responses. The same is true for signed responses:
> > either the hash of
> > > the request or the important elements from the
> > request must be present.
> > > In order to test the response against what has been
> > requested the client
> > >
> > > has to keep his request or at least the hash of his request.
> > >
> > > The advantage of a hash - instead of copying all
> > important elements
> > > from the request -  is:
> > > (a) that the response will be smaller and
> > > (b) adding a new important element to the request
> > doesn't require a
> > > change of the response.
> > >
> > > - a hash of the request MUST be included in the response.
> > >
> > >   This may allow the client to check if his request
> > was maliciously
> > >
> > >   modified (if the response is signed) and helps to
> > associate the
> > >
> > >   response with his request when using
> > connectionless protocols.
> > >
> > >   [Answer 1] The requirements are different whether
> > the requester simply
> > > wants
> > >
> > >   an authenticated response or a signed response.
> > For a signed response
> > > the
> > >
> > >   inclusion of the important elements from the
> > request is needed, so
> > > that a
> > >
> > >   response can be individually tested against what
> > has been requested.
> > > For an
> > >
> > >   authenticated response, the hash of the request
> > is sufficient. To
> > > summarize:
> > >
> > >   - for signed responses, the important elements
> > from the request
> > >
> > >     must be present.
> > >
> > >   - for authenticated responses, either the hash of
> > the request or the
> > >
> > >     important elements from the request must be present.
> > >
> > > - Petra
> >
> >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g26LYEB23538 for ietf-pkix-bks; Wed, 6 Mar 2002 13:34:14 -0800 (PST)
Received: from gateway.secude.com (linux.secude.com [141.12.207.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g26LYD823534 for <[e-mail]>; Wed, 6 Mar 2002 13:34:13 -0800 (PST)
Received: from remus.secude.com (remus.intranet.secude.com [192.168.2.2]) by gateway.secude.com (Postfix) with ESMTP id 5DBE29CFC; Wed,  6 Mar 2002 22:34:10 +0100 (CET)
Received: from secude.com (obelix.intranet.secude.com [192.168.1.3]) by remus.secude.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FFR01H3W; Wed, 6 Mar 2002 22:34:09 +0100
Message-ID: <[e-mail]>
Date: Wed, 06 Mar 2002 22:36:37 +0100
From: Petra Barzin <[e-mail]>
X-Mailer: Mozilla 4.73 [de]C-CCK-MCD DT  (Win95; U)
X-Accept-Language: de
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
Cc: "Housley, Russ" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: DPD/DPV reqmts: hash of the request
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>

Mike,

do I understand you correctly, that you propose to mark the
requirement (binding the response back to the request) as
optional and leave it up to the implementation of the DPV
client and server to realize this binding?
I'm afraid this will lead to unnecessary interoperability problems
between implementations of a DPV client and server, e.g. if a
client implementation requires this binding, but it's not implemented
at the server. If we feel that the binding adds value to the protocol
- and I think it does - we should mandate its use! You can still
cache the information and re-use them, you just cannot preproduce
the whole response.

Petra

Michael Myers schrieb:

> Petra,
>
> In my opinion we should enable the practice by ensuring the
> capability is in running code but not mandate its use in all
> circumstances.  Do you find this approach acceptable?
>
> Mike
>
> > -----Original Message-----
> > From: Petra Barzin [mailto:[e-mail]]
> > Sent: Tuesday, March 05, 2002 12:17 PM
> > To: Housley, Russ
> > Cc: '[e-mail] '; '[e-mail] ';
> > [e-mail]
> > Subject: Re: DPD/DPV reqmts: hash of the request
> >
> >
> > Yes, the requirement is to bind the response back to
> > the request!
> > Sorry for the technical discussion at this point.
> > I'd see the requirement as a MUST, but I can see
> > Michael's concern
> > that it prevents the use of pre-produced responses.
> > But I think it is very important that the sender of a
> > DPV request
> > is able to match the received response to his request
> > in order to
> > make sure that no man in the middle changed his
> > validation request.
> >
> > - Petra
> >
> > "Housley, Russ" schrieb:
> >
> > > In my opinion, the requirement is to bind the
> > respponse back to the request.
> > > Two obvious was to accomplish this binding are to
> > include all of the fields
> > > of the request in the response and to include a
> > hash of the request in the
> > > response.  Since we are working on the requirements
> > doucment, we should
> > > stict to requirements, not mechanisms for
> > implementing the requirements.
> > >
> > > Russ
> > >
> > > -----Original Message-----
> > > From: Petra Barzin
> > > To: [e-mail]
> > > Cc: [e-mail]
> > > Sent: 3/3/02 3:48 PM
> > > Subject: DPD/DPV reqmts: hash of the request
> > >
> > > Denis,
> > >
> > > I don't see why you differentiate between signed
> > and authenticated
> > > responses. The same is true for signed responses:
> > either the hash of
> > > the request or the important elements from the
> > request must be present.
> > > In order to test the response against what has been
> > requested the client
> > >
> > > has to keep his request or at least the hash of his request.
> > >
> > > The advantage of a hash - instead of copying all
> > important elements
> > > from the request -  is:
> > > (a) that the response will be smaller and
> > > (b) adding a new important element to the request
> > doesn't require a
> > > change of the response.
> > >
> > > - a hash of the request MUST be included in the response.
> > >
> > >   This may allow the client to check if his request
> > was maliciously
> > >
> > >   modified (if the response is signed) and helps to
> > associate the
> > >
> > >   response with his request when using
> > connectionless protocols.
> > >
> > >   [Answer 1] The requirements are different whether
> > the requester simply
> > > wants
> > >
> > >   an authenticated response or a signed response.
> > For a signed response
> > > the
> > >
> > >   inclusion of the important elements from the
> > request is needed, so
> > > that a
> > >
> > >   response can be individually tested against what
> > has been requested.
> > > For an
> > >
> > >   authenticated response, the hash of the request
> > is sufficient. To
> > > summarize:
> > >
> > >   - for signed responses, the important elements
> > from the request
> > >
> > >     must be present.
> > >
> > >   - for authenticated responses, either the hash of
> > the request or the
> > >
> > >     important elements from the request must be present.
> > >
> > > - Petra
> >
> >



Received: by above.proper.com (8.11.6/8.11.3) id g26IfqZ18470 for ietf-pkix-bks; Wed, 6 Mar 2002 10:41:52 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g26Ifp818466 for <[e-mail]>; Wed, 6 Mar 2002 10:41:51 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26078; Wed, 6 Mar 2002 13:41:50 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-pkalgs-supp-01.txt
Date: Wed, 06 Mar 2002 13:41:49 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Supplemental Algorithms and Identifiers for the 
                          Internet X.509 Public Key Infrastructure Certificate 
                          and CRL Profile
	Author(s)	: A. Singer, W. Whyte
	Filename	: draft-ietf-pkix-pkalgs-supp-01.txt
	Pages		: 23
	Date		: 05-Mar-02
	
This document specifies algorithm identifiers and ASN.1 encoding 
formats for digital signatures and subject public keys, including 
NTRUSign digital signatures and NTRUEncrypt and NTRUSign subject 
public keys used in the Internet X.509 Public Key Infrastructure 
(PKI).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-pkalgs-supp-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-pkalgs-supp-01.txt

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g26HEYK14239 for ietf-pkix-bks; Wed, 6 Mar 2002 09:14:34 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g26HEW814234 for <[e-mail]>; Wed, 6 Mar 2002 09:14:32 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 6 Mar 2002 17:14:09 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA19881 for <[e-mail]>; Wed, 6 Mar 2002 12:14:13 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g26HEVb01628 for <[e-mail]>; Wed, 6 Mar 2002 12:14:31 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <F4N5P4DH>; Wed, 6 Mar 2002 12:12:19 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.58]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F4N5P4DD; Wed, 6 Mar 2002 12:12:17 -0500
From: "Housley, Russ" <[e-mail]>
To: "Christopher S. Francis" <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 06 Mar 2002 12:14:18 -0500
Subject: RE: Attribute Certificate Policy??
In-Reply-To: <[e-mail] m>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by sdtihq24.securid.com id MAA19881
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<html>
Chris:<br><br>
Including a certificatePolicies extension in an AC is allowed by the PKIX
AC profile, as long as it is marked non-critical.&nbsp; The profile
says:<br><br>
&nbsp;&nbsp; An AC that has no extensions conforms to the profile;
however,<br>
&nbsp;&nbsp; section 4.3 defines the extensions that MAY be used with
this<br>
&nbsp;&nbsp; profile, and whether or not they may be marked critical. If
any<br>
&nbsp;&nbsp; other critical extension is used, then the AC does not
conform to<br>
&nbsp;&nbsp; this profile. However, if any other non-critical extension
is used,<br>
&nbsp;&nbsp; then the AC does conform to this profile.<br><br>
Russ<br><br>
At 10:12 AM 3/6/2002 -0500, Christopher S. Francis wrote:<br><br>
<blockquote type=3Dcite class=3Dcite cite><font face=3D"Comic Sans MS" co=
lor=3D"#000080">Thanks
Zoltan.&nbsp; <br>
</font><br>
<font face=3D"Comic Sans MS" color=3D"#000080">&nbsp;<br>
</font><br>
<font face=3D"Comic Sans MS" color=3D"#000080">I understand that the issu=
ing
authority must produce a CP and a CPS.&nbsp; My problem is, there seems
to be no good place in an attribute certificate to put an OID that
associates the AC with those policies and practices.&nbsp; In Public Key
Certificates, you would put the OID in the certificatePolicies
extension.<br>
</font><br>
<font face=3D"Comic Sans MS" color=3D"#000080">&nbsp;<br>
</font><br>
<font face=3D"Comic Sans MS" color=3D"#000080">Some have suggested that w=
e
include a certificatePolicies extension in the AC, but I m not sure if we
would still have a PKIX compliant AC if we did that.&nbsp; Perhaps we
would as long as we made it non-critical.&nbsp; <br>
</font><br>
<font face=3D"Comic Sans MS" color=3D"#000080">&nbsp;<br>
</font><br>
<font face=3D"Comic Sans MS" color=3D"#000080">Perhaps more importantly,
would such an AC make it past the commonly available decoders that are
out there&amp;..<br>
</font><br>
<font face=3D"Comic Sans MS" color=3D"#000080">&nbsp;<br>
</font><br>
<font face=3D"Comic Sans MS" color=3D"#000080">Chris<br>
</font><br>
<font face=3D"tahoma" size=3D2>-----Original Message-----<br>
<b>From:</b> Zolt=E1n Nochta
[<a href=3D"mailto:[e-mail]" eudora=3D"aut=
ourl">mailto:[e-mail]</a>]<br>
<b>Sent:</b> Wednesday, March 06, 2002 10:02 AM<br>
<b>To:</b> 'Christopher S. Francis'<br>
<b>Subject:</b> AW: Attribute Certificate Policy??<br>
</font><br>
<font face=3D"Times New Roman, Times">&nbsp;<br>
</font><br>
<font face=3D"arial" size=3D2 color=3D"#0000FF">Hi,<br>
</font><br>
<font face=3D"Times New Roman, Times">&nbsp;<br>
</font><br>
<font face=3D"arial" size=3D2 color=3D"#0000FF">such operational practice=
s can
can be a part of the CP and CPS of the issuing authority. However, I
can't help you with a public CPS example that deals with ACs.<br>
</font><br>
<font face=3D"Times New Roman, Times">&nbsp;<br>
</font><br>
<font face=3D"arial" size=3D2 color=3D"#0000FF">Cheers,<br>
</font><br>
<font face=3D"arial" size=3D2 color=3D"#0000FF">Zoltan<br>
</font><br>
<font face=3D"tahoma" size=3D2>-----Urspr=FCngliche Nachricht-----<br>
<b>Von:</b> Christopher S. Francis
[<a href=3D"mailto:[e-mail]" eudora=3D"autourl">mai=
lto:[e-mail]</a>]<br>
<b>Gesendet:</b> Dienstag, 5. M=E4rz 2002 23:41<br>
<b>An:</b> Ietf-Pkix<br>
<b>Betreff:</b> Attribute Certificate Policy??<br>
</font><br>
<font face=3D"Comic Sans MS">Is there a defined mechanism to specify
something analogous to a certificate policy in an attribute
certificate?&nbsp; <br>
</font><br>
<font face=3D"Comic Sans MS">&nbsp;<br>
</font><br>
<font face=3D"Comic Sans MS">In reviewing the PKIX AC profile, I see that
the syntax of the attributes field is defined by the AttributeType OID,
but rather than syntax per se, I m looking for a way to specify the
particular set of policies, practices, and procedures that the attribute
authority was operating under when it issued the attribute
certificate.&nbsp; Seems like this would be important to relying
parties.<br>
</font><br>
<font face=3D"Comic Sans MS">&nbsp;<br>
</font><br>
<font face=3D"Comic Sans MS">X.509 includes an acceptablePrivilegePolicie=
s
extension that seems like it might to the job, but it was apparently
profiled out by PKIX.<br>
</font><br>
<font face=3D"Comic Sans MS">&nbsp;<br>
</font><br>
<font face=3D"Comic Sans MS">Chris Francis<br>
</font><br>
<font face=3D"Comic Sans MS">&nbsp;<br>
</font><br>
<font face=3D"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 g26G2HL09432 for ietf-pkix-bks; Wed, 6 Mar 2002 08:02:17 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g26G2F809423 for <[e-mail]>; Wed, 6 Mar 2002 08:02:16 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 6 Mar 2002 16:01:52 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA11824; Wed, 6 Mar 2002 11:01:57 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g26G2FM20676; Wed, 6 Mar 2002 11:02:15 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <F4N5PSRZ>; Wed, 6 Mar 2002 11:00:03 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.58]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F4N5PSRX; Wed, 6 Mar 2002 10:59:58 -0500
From: "Housley, Russ" <[e-mail]>
To: "Christopher S. Francis" <[e-mail]>
Cc: Ietf-Pkix <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 06 Mar 2002 11:01:43 -0500
Subject: Re: Attribute Certificate Policy??
In-Reply-To: <[e-mail] m>
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>

Chris:

I am not aware of any work in this area.  You can take the lead.

Russ


At 05:41 PM 3/5/2002 -0500, Christopher S. Francis wrote:

>Is there a defined mechanism to specify something analogous to a 
>certificate policy in an attribute certificate?
>
>
>
>In reviewing the PKIX AC profile, I see that the syntax of the attributes 
>field is defined by the AttributeType OID, but rather than syntax per se, 
>I m looking for a way to specify the particular set of policies, 
>practices, and procedures that the attribute authority was operating under 
>when it issued the attribute certificate.  Seems like this would be 
>important to relying parties.
>
>
>
>X.509 includes an acceptablePrivilegePolicies extension that seems like it 
>might to the job, but it was apparently profiled out by PKIX.
>
>
>
>Chris Francis
>
>
>
>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g26FCeB06492 for ietf-pkix-bks; Wed, 6 Mar 2002 07:12:40 -0800 (PST)
Received: from emerald.lightlink.com (emerald.lightlink.com [205.232.34.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g26FCb806488 for <[e-mail]>; Wed, 6 Mar 2002 07:12:38 -0800 (PST)
Received: from [209.216.70.29] (perm70-29.ij.net [209.216.70.29] (may be forged)) by emerald.lightlink.com (8.8.8/8.8.8) with SMTP id KAA26778; Wed, 6 Mar 2002 10:12:34 -0500
From: "Christopher S. Francis" <[e-mail]>
To: =?iso-8859-1?Q?Zolt=E1n_Nochta?= <[e-mail]>
Cc: "Ietf-Pkix" <[e-mail]>
Received: from no.name.available by [209.216.70.29] via smtpd (for smtp.lightlink.com [205.232.34.14]) with SMTP; 6 Mar 2002 15:03:28 UT
Subject: RE: Attribute Certificate Policy??
Date: Wed, 6 Mar 2002 10:12:34 -0500
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D8_01C1C4F7.6EF83110"
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 V6.00.2600.0000
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>

This is a multi-part message in MIME format.

------=_NextPart_000_00D8_01C1C4F7.6EF83110
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thanks Zoltan. =20
=20
I understand that the issuing authority must produce a CP and a CPS.  My =
problem is, there seems to be no good place in an attribute certificate =
to put an OID that associates the AC with those policies and practices.  =
In Public Key Certificates, you would put the OID in the =
certificatePolicies extension.
=20
Some have suggested that we include a certificatePolicies extension in =
the AC, but I=92m not sure if we would still have a =93PKIX compliant=94 =
AC if we did that.  Perhaps we would as long as we made it non-critical. =
=20
=20
Perhaps more importantly, would such an AC make it past the commonly =
available decoders that are out there=85..
=20
Chris
-----Original Message-----
From: Zolt=E1n Nochta [mailto:[e-mail]]
Sent: Wednesday, March 06, 2002 10:02 AM
To: 'Christopher S. Francis'
Subject: AW: Attribute Certificate Policy??
=20
Hi,
=20
such operational practices can can be a part of the CP and CPS of the =
issuing authority. However, I can't help you with a public CPS example =
that deals with ACs.
=20
Cheers,
Zoltan
-----Urspr=FCngliche Nachricht-----
Von: Christopher S. Francis [mailto:[e-mail]]
Gesendet: Dienstag, 5. M=E4rz 2002 23:41
An: Ietf-Pkix
Betreff: Attribute Certificate Policy??
Is there a defined mechanism to specify something analogous to a =
certificate policy in an attribute certificate? =20
=20
In reviewing the PKIX AC profile, I see that the syntax of the =
attributes field is defined by the AttributeType OID, but rather than =
syntax per se, I=92m looking for a way to specify the particular set of =
policies, practices, and procedures that the attribute authority was =
operating under when it issued the attribute certificate.  Seems like =
this would be important to relying parties.
=20
X.509 includes an acceptablePrivilegePolicies extension that seems like =
it might to the job, but it was apparently profiled out by PKIX.
=20
Chris Francis
=20
=20

------=_NextPart_000_00D8_01C1C4F7.6EF83110
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:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 9">
<meta name=3DOriginator content=3D"Microsoft Word 9">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C1C4F7.5D3C6590">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:View>Normal</w:View>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
@font-face
	{font-family:"Comic Sans MS";
	panose-1:3 15 7 2 3 3 2 2 2 4;
	mso-font-charset:0;
	mso-generic-font-family:script;
	mso-font-pitch:variable;
	mso-font-signature:647 0 0 0 159 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;}
 /* 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:"Times New Roman";}
h1
	{mso-style-next:Normal;
	margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	mso-pagination:widow-orphan;
	mso-outline-level:1;
	font-size:16.0pt;
	font-family:Arial;
	mso-font-kerning:16.0pt;}
p.MsoBodyText, li.MsoBodyText, div.MsoBodyText
	{margin-top:13.2pt;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:1.0in;
	margin-bottom:.0001pt;
	line-height:120%;
	mso-pagination:widow-orphan;
	font-size:11.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-font-kerning:11.0pt;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p.Heading1NoTOC, li.Heading1NoTOC, div.Heading1NoTOC
	{mso-style-name:"Heading 1 No TOC";
	mso-style-parent:"Heading 1";
	margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	text-align:center;
	mso-pagination:widow-orphan;
	mso-outline-level:1;
	font-size:14.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	mso-font-kerning:14.0pt;
	font-weight:bold;
	mso-bidi-font-weight:normal;}
p.TableText, li.TableText, div.TableText
	{mso-style-name:"Table Text";
	margin-top:3.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	line-height:110%;
	mso-pagination:widow-orphan lines-together;
	font-size:10.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-font-kerning:10.0pt;}
p.TableTextTitle, li.TableTextTitle, div.TableTextTitle
	{mso-style-name:"Table Text Title";
	mso-style-parent:"Table Text";
	margin-top:3.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	line-height:110%;
	mso-pagination:widow-orphan lines-together;
	font-size:10.0pt;
	font-family:Arial;
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	mso-font-kerning:10.0pt;
	font-weight:bold;
	mso-bidi-font-weight:normal;}
span.EmailStyle22
	{mso-style-type:personal;
	mso-ansi-font-size:12.0pt;
	mso-ascii-font-family:"Comic Sans MS";
	mso-hansi-font-family:"Comic Sans MS";
	mso-bidi-font-family:Arial;
	color:black;}
span.EmailStyle23
	{mso-style-type:personal-reply;
	mso-ansi-font-size:12.0pt;
	mso-ascii-font-family:"Comic Sans MS";
	mso-hansi-font-family:"Comic Sans MS";
	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>
</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><span class=3DEmailStyle23><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>Thanks
Zoltan.<span style=3D"mso-spacerun: yes">&nbsp; =
</span><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle23><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle23><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>I
understand that the issuing authority must produce a CP and a CPS.<span
style=3D"mso-spacerun: yes">&nbsp; </span>My problem is, there seems to =
be no
good place in an attribute certificate to put an OID that associates the =
AC
with those policies and practices.<span style=3D"mso-spacerun: =
yes">&nbsp;
</span>In Public Key Certificates, you would put the OID in the
certificatePolicies extension.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle23><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle23><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>Some
have suggested that we include a certificatePolicies extension in the =
AC, but I&#8217;m
not sure if we would still have a &#8220;PKIX compliant&#8221; AC if we =
did that.<span
style=3D"mso-spacerun: yes">&nbsp; </span>Perhaps we would as long as we =
made it
non-critical.<span style=3D"mso-spacerun: yes">&nbsp; =
</span><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle23><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle23><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>Perhaps
more importantly, would such an AC make it past the commonly available =
decoders
that are out there&#8230;..<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle23><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle23><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans =
MS"'>Chris<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dblack
face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Zolt=E1n Nochta
[mailto:[e-mail]]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, March =
06, 2002
10:02 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Christopher S. =
Francis'<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> AW: Attribute =
Certificate
Policy??</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'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></p>

<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'>Hi,</span></font>=
<font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

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

<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'>such operational
practices can can be a part of the CP and CPS of the issuing authority.
However, I can't help you with a public&nbsp;CPS example that deals with =
ACs.</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

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

<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'>Cheers,</span></f=
ont><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<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'>Zoltan</span></fo=
nt><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;margin-bottom:12.0pt;
margin-left:1.0in'><font size=3D2 color=3Dblack face=3DTahoma><span =
style=3D'font-size:
10.0pt;font-family:Tahoma;color:black'>-----Urspr=FCngliche =
Nachricht-----<br>
<b><span style=3D'font-weight:bold'>Von:</span></b> Christopher S. =
Francis
[mailto:[e-mail]]<br>
<b><span style=3D'font-weight:bold'>Gesendet:</span></b> Dienstag, 5. =
M=E4rz 2002
23:41<br>
<b><span style=3D'font-weight:bold'>An:</span></b> Ietf-Pkix<br>
<b><span style=3D'font-weight:bold'>Betreff:</span></b> Attribute =
Certificate
Policy??</span></font><font color=3Dblack><span =
style=3D'color:black;mso-color-alt:
windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:1.0in'><span =
class=3DEmailStyle22><font
size=3D3 color=3Dblack face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;
font-family:"Comic Sans MS"'>Is there a defined mechanism to specify =
something
analogous to a certificate policy in an attribute certificate?<span
style=3D"mso-spacerun: yes">&nbsp; =
</span><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal style=3D'margin-left:1.0in'><span =
class=3DEmailStyle22><font
size=3D3 color=3Dblack face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;
font-family:"Comic Sans MS"'>&nbsp;<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal style=3D'margin-left:1.0in'><span =
class=3DEmailStyle22><font
size=3D3 color=3Dblack face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;
font-family:"Comic Sans MS"'>In reviewing the PKIX AC profile, I see =
that the
syntax of the attributes field is defined by the AttributeType OID, but =
rather
than syntax per se, I&#8217;m looking for a way to specify the =
particular set of policies,
practices, and procedures that the attribute authority was operating =
under when
it issued the attribute certificate.<span style=3D"mso-spacerun: =
yes">&nbsp;
</span>Seems like this would be important to relying =
parties.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal style=3D'margin-left:1.0in'><span =
class=3DEmailStyle22><font
size=3D3 color=3Dblack face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;
font-family:"Comic Sans MS"'>&nbsp;<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal style=3D'margin-left:1.0in'><span =
class=3DEmailStyle22><font
size=3D3 color=3Dblack face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;
font-family:"Comic Sans MS"'>X.509 includes an =
acceptablePrivilegePolicies
extension that seems like it might to the job, but it was apparently =
profiled
out by PKIX.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal style=3D'margin-left:1.0in'><span =
class=3DEmailStyle22><font
size=3D3 color=3Dblack face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;
font-family:"Comic Sans MS"'>&nbsp;<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal style=3D'margin-left:1.0in'><span =
class=3DEmailStyle22><font
size=3D3 color=3Dblack face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;
font-family:"Comic Sans MS"'>Chris =
Francis<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal style=3D'margin-left:1.0in'><span =
class=3DEmailStyle22><font
size=3D3 color=3Dblack face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;
font-family:"Comic Sans MS"'>&nbsp;<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal style=3D'margin-left:1.0in'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'>&nbsp;</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

</div>

</body>

</html>

------=_NextPart_000_00D8_01C1C4F7.6EF83110--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g260wX407758 for ietf-pkix-bks; Tue, 5 Mar 2002 16:58:33 -0800 (PST)
Received: from geos.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g260wV807754 for <[e-mail]>; Tue, 5 Mar 2002 16:58:31 -0800 (PST)
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 g260wVP29743; Tue, 5 Mar 2002 16:58:31 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "Deacon, Alex" <[e-mail]>, <[e-mail]>
Subject: RE: Validation policy in DPV/DPD rqmts
Date: Tue, 5 Mar 2002 16:56:00 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Alex,

We've agreed that we're now back to {valid, invalid, unknown}.
The notion of "potentially valid" is a client-side
interpretation of the data that MAY be transmitted from the
server to aid the client in assessing this situation.

Mike


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Deacon, Alex
> Sent: Tuesday, March 05, 2002 9:55 AM
> To: '[e-mail]'
> Subject: RE: Validation policy in DPV/DPD rqmts
>
>
>
> All,
>
> My .02 cents after catching up on this very long
> thread.  I'll try to make
> them quick:
>
> * Mandating additional granularity on the current
> "valid, invalid, unknown"
> status is a bad idea IMO.  I would prefer to have
> this requirement removed;
> however if server support for "potentially valid" (or
> sort-of-valid,
> kind-of-valid, whatever) is specified as a MAY (as I
> believe we have
> decided) then I suppose I can live with it.
>
> * Requirements that add additional processing
> requirements on clients is
> also, IMO, a bad idea.  The idea of OCSP/DPD/DPV/etc
> servers is to move
> complexity away from the client.  I'm scared by the
> talk of path validation
> policy negotiation.  Concepts like this will lever
> fly in constrained
> clients such as mobile phones.
>
> * I agree with Mike's wording below on the minimum
> requirements need for a
> server to assert a "valid" status.  Lets make sure we
> have some base/minimum
> assumptions regarding what a server should do, and
> lets make sure it
> reflects the hard work and decisions we made in PKIX
> path processing.
>
> Alex
>
>
> > -----Original Message-----
> > From: Michael Myers [mailto:[e-mail]]
> > Sent: Friday, March 01, 2002 12:30 PM
> > To: Housley, Russ
> > Cc: [e-mail]
> > Subject: RE: Validation policy in DPV/DPD rqmts
> >
> >
> >
> > > -----Original Message-----
> > > From: Housley, Russ
> > > Sent: Friday, March 01, 2002 5:26 AM
> > >
> > > Mike:
> > >
> > > Please post your suggested text.  Based on your
> > > message, it should not need to be more than a
> > > paragraph.  Did I miss something?
> > >
> > > Russ
> >
> > Russ,
> >
> > Here's a first cut.  I suggest inserting this text
> immediately
> > following the identification of the various states
> a DPV server
> > must be capable of producing.
> >
> > Mike
> >
> >
> > Prior to asserting a "valid" status, a DPV server
> SHALL, at a
> > minimum:
> >
> > 1. confirm that, in the time context of the
> request, the subject
> > certificate is (or was) niether revoked nor suspended by the
> > authority that issued the certificate;
> >
> > 2.  confirm that, in the time context of the request, all
> > certificates needed to complete the associated
> validation path
> > are (or were) niether revoked nor suspended, up to
> and including
> > the trust anchor; AND
> >
> > 2.  confirm that the subject certificate and its associated
> > intermediate and trust anchor certificates form a chain that
> > satisifies the path validation algorithm defined by
> RFC 2459 or
> > its successors [PKIX-1].
> >
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g25MfNS04476 for ietf-pkix-bks; Tue, 5 Mar 2002 14:41:23 -0800 (PST)
Received: from emerald.lightlink.com (emerald.lightlink.com [205.232.34.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g25MfM804472 for <[e-mail]>; Tue, 5 Mar 2002 14:41:22 -0800 (PST)
Received: from [209.216.70.29] (perm70-29.ij.net [209.216.70.29] (may be forged)) by emerald.lightlink.com (8.8.8/8.8.8) with SMTP id RAA29625 for <[e-mail]>; Tue, 5 Mar 2002 17:41:23 -0500
From: "Christopher S. Francis" <[e-mail]>
To: "Ietf-Pkix" <[e-mail]>
Received: from no.name.available by [209.216.70.29] via smtpd (for smtp.lightlink.com [205.232.34.14]) with SMTP; 5 Mar 2002 22:32:22 UT
Subject: Attribute Certificate Policy??
Date: Tue, 5 Mar 2002 17:41:23 -0500
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_011D_01C1C46C.F79E18D0"
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 V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_011D_01C1C46C.F79E18D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Is there a defined mechanism to specify something analogous to a =
certificate policy in an attribute certificate? =20
=20
In reviewing the PKIX AC profile, I see that the syntax of the =
attributes field is defined by the AttributeType OID, but rather than =
syntax per se, I=92m looking for a way to specify the particular set of =
policies, practices, and procedures that the attribute authority was =
operating under when it issued the attribute certificate.  Seems like =
this would be important to relying parties.
=20
X.509 includes an acceptablePrivilegePolicies extension that seems like =
it might to the job, but it was apparently profiled out by PKIX.
=20
Chris Francis
=20
=20

------=_NextPart_000_011D_01C1C46C.F79E18D0
Content-Type: text/html;
	charset="iso-8859-1"
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=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 9">
<meta name=3DOriginator content=3D"Microsoft Word 9">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C1C46C.E5E55A90">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:View>Normal</w:View>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
@font-face
	{font-family:"Comic Sans MS";
	panose-1:3 15 7 2 3 3 2 2 2 4;
	mso-font-charset:0;
	mso-generic-font-family:script;
	mso-font-pitch:variable;
	mso-font-signature:647 0 0 0 159 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:"Times New Roman";}
h1
	{mso-style-next:Normal;
	margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:1;
	font-size:16.0pt;
	font-family:Arial;
	mso-font-kerning:16.0pt;}
p.MsoBodyText, li.MsoBodyText, div.MsoBodyText
	{margin-top:13.2pt;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:1.0in;
	margin-bottom:.0001pt;
	line-height:120%;
	mso-pagination:widow-orphan;
	font-size:11.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-font-kerning:11.0pt;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle15
	{mso-style-type:personal-compose;
	mso-ansi-font-size:12.0pt;
	mso-ascii-font-family:"Comic Sans MS";
	mso-hansi-font-family:"Comic Sans MS";
	mso-bidi-font-family:Arial;
	color:black;}
p.Heading1NoTOC, li.Heading1NoTOC, div.Heading1NoTOC
	{mso-style-name:"Heading 1 No TOC";
	mso-style-parent:"Heading 1";
	margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	text-align:center;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:1;
	font-size:14.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	mso-font-kerning:14.0pt;
	font-weight:bold;
	mso-bidi-font-weight:normal;}
p.TableText, li.TableText, div.TableText
	{mso-style-name:"Table Text";
	margin-top:3.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	line-height:110%;
	mso-pagination:widow-orphan lines-together;
	font-size:10.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-font-kerning:10.0pt;}
p.TableTextTitle, li.TableTextTitle, div.TableTextTitle
	{mso-style-name:"Table Text Title";
	mso-style-parent:"Table Text";
	margin-top:3.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	line-height:110%;
	mso-pagination:widow-orphan lines-together;
	font-size:10.0pt;
	font-family:Arial;
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	mso-font-kerning:10.0pt;
	font-weight:bold;
	mso-bidi-font-weight:normal;}
@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>
</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>Is
there a defined mechanism to specify something analogous to a =
certificate
policy in an attribute certificate?<span style=3D"mso-spacerun: =
yes">&nbsp;
</span><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>In
reviewing the PKIX AC profile, I see that the syntax of the attributes =
field is
defined by the AttributeType OID, but rather than syntax per se, =
I&#8217;m looking
for a way to specify the particular set of policies, practices, and =
procedures
that the attribute authority was operating under when it issued the =
attribute
certificate.<span style=3D"mso-spacerun: yes">&nbsp; </span>Seems like =
this would
be important to relying parties.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>X.509
includes an acceptablePrivilegePolicies extension that seems like it =
might to
the job, but it was apparently profiled out by =
PKIX.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>Chris
Francis<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

</div>

</body>

</html>

------=_NextPart_000_011D_01C1C46C.F79E18D0--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g25KWw800397 for ietf-pkix-bks; Tue, 5 Mar 2002 12:32:58 -0800 (PST)
Received: from geos.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g25KWq800392 for <[e-mail]>; Tue, 5 Mar 2002 12:32:56 -0800 (PST)
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 g25KWJ601439; Tue, 5 Mar 2002 12:32:20 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "Petra Barzin" <[e-mail]>, "Housley, Russ" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: DPD/DPV reqmts: hash of the request
Date: Tue, 5 Mar 2002 12:29:48 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>

Petra,

In my opinion we should enable the practice by ensuring the
capability is in running code but not mandate its use in all
circumstances.  Do you find this approach acceptable?

Mike


> -----Original Message-----
> From: Petra Barzin [mailto:[e-mail]]
> Sent: Tuesday, March 05, 2002 12:17 PM
> To: Housley, Russ
> Cc: '[e-mail] '; '[e-mail] ';
> [e-mail]
> Subject: Re: DPD/DPV reqmts: hash of the request
>
>
> Yes, the requirement is to bind the response back to
> the request!
> Sorry for the technical discussion at this point.
> I'd see the requirement as a MUST, but I can see
> Michael's concern
> that it prevents the use of pre-produced responses.
> But I think it is very important that the sender of a
> DPV request
> is able to match the received response to his request
> in order to
> make sure that no man in the middle changed his
> validation request.
>
> - Petra
>
> "Housley, Russ" schrieb:
>
> > In my opinion, the requirement is to bind the
> respponse back to the request.
> > Two obvious was to accomplish this binding are to
> include all of the fields
> > of the request in the response and to include a
> hash of the request in the
> > response.  Since we are working on the requirements
> doucment, we should
> > stict to requirements, not mechanisms for
> implementing the requirements.
> >
> > Russ
> >
> > -----Original Message-----
> > From: Petra Barzin
> > To: [e-mail]
> > Cc: [e-mail]
> > Sent: 3/3/02 3:48 PM
> > Subject: DPD/DPV reqmts: hash of the request
> >
> > Denis,
> >
> > I don't see why you differentiate between signed
> and authenticated
> > responses. The same is true for signed responses:
> either the hash of
> > the request or the important elements from the
> request must be present.
> > In order to test the response against what has been
> requested the client
> >
> > has to keep his request or at least the hash of his request.
> >
> > The advantage of a hash - instead of copying all
> important elements
> > from the request -  is:
> > (a) that the response will be smaller and
> > (b) adding a new important element to the request
> doesn't require a
> > change of the response.
> >
> > - a hash of the request MUST be included in the response.
> >
> >   This may allow the client to check if his request
> was maliciously
> >
> >   modified (if the response is signed) and helps to
> associate the
> >
> >   response with his request when using
> connectionless protocols.
> >
> >   [Answer 1] The requirements are different whether
> the requester simply
> > wants
> >
> >   an authenticated response or a signed response.
> For a signed response
> > the
> >
> >   inclusion of the important elements from the
> request is needed, so
> > that a
> >
> >   response can be individually tested against what
> has been requested.
> > For an
> >
> >   authenticated response, the hash of the request
> is sufficient. To
> > summarize:
> >
> >   - for signed responses, the important elements
> from the request
> >
> >     must be present.
> >
> >   - for authenticated responses, either the hash of
> the request or the
> >
> >     important elements from the request must be present.
> >
> > - Petra
>
>



Received: by above.proper.com (8.11.6/8.11.3) id g25KEvc29947 for ietf-pkix-bks; Tue, 5 Mar 2002 12:14:57 -0800 (PST)
Received: from gateway.secude.com (linux.secude.com [141.12.207.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g25KEt829943 for <[e-mail]>; Tue, 5 Mar 2002 12:14:55 -0800 (PST)
Received: from remus.secude.com (remus.intranet.secude.com [192.168.2.2]) by gateway.secude.com (Postfix) with ESMTP id 508AB9938; Tue,  5 Mar 2002 21:14:52 +0100 (CET)
Received: from secude.com (obelix.intranet.secude.com [192.168.1.3]) by remus.secude.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FFR01G4Z; Tue, 5 Mar 2002 21:14:51 +0100
Message-ID: <[e-mail]>
Date: Tue, 05 Mar 2002 21:17:16 +0100
From: Petra Barzin <[e-mail]>
X-Mailer: Mozilla 4.73 [de]C-CCK-MCD DT  (Win95; U)
X-Accept-Language: de
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
Cc: "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, [e-mail]
Subject: Re: DPD/DPV reqmts: hash of the request
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>

Yes, the requirement is to bind the response back to the request!
Sorry for the technical discussion at this point.
I'd see the requirement as a MUST, but I can see Michael's concern
that it prevents the use of pre-produced responses.
But I think it is very important that the sender of a DPV request
is able to match the received response to his request in order to
make sure that no man in the middle changed his validation request.

- Petra

"Housley, Russ" schrieb:

> In my opinion, the requirement is to bind the respponse back to the request.
> Two obvious was to accomplish this binding are to include all of the fields
> of the request in the response and to include a hash of the request in the
> response.  Since we are working on the requirements doucment, we should
> stict to requirements, not mechanisms for implementing the requirements.
>
> Russ
>
> -----Original Message-----
> From: Petra Barzin
> To: [e-mail]
> Cc: [e-mail]
> Sent: 3/3/02 3:48 PM
> Subject: DPD/DPV reqmts: hash of the request
>
> Denis,
>
> I don't see why you differentiate between signed and authenticated
> responses. The same is true for signed responses: either the hash of
> the request or the important elements from the request must be present.
> In order to test the response against what has been requested the client
>
> has to keep his request or at least the hash of his request.
>
> The advantage of a hash - instead of copying all important elements
> from the request -  is:
> (a) that the response will be smaller and
> (b) adding a new important element to the request doesn't require a
> change of the response.
>
> - a hash of the request MUST be included in the response.
>
>   This may allow the client to check if his request was maliciously
>
>   modified (if the response is signed) and helps to associate the
>
>   response with his request when using connectionless protocols.
>
>   [Answer 1] The requirements are different whether the requester simply
> wants
>
>   an authenticated response or a signed response. For a signed response
> the
>
>   inclusion of the important elements from the request is needed, so
> that a
>
>   response can be individually tested against what has been requested.
> For an
>
>   authenticated response, the hash of the request is sufficient. To
> summarize:
>
>   - for signed responses, the important elements from the request
>
>     must be present.
>
>   - for authenticated responses, either the hash of the request or the
>
>     important elements from the request must be present.
>
> - Petra



Received: by above.proper.com (8.11.6/8.11.3) id g25Hsgs24967 for ietf-pkix-bks; Tue, 5 Mar 2002 09:54:42 -0800 (PST)
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 g25Hsf824963 for <[e-mail]>; Tue, 5 Mar 2002 09:54:41 -0800 (PST)
Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id g25Hp8R16285 for <[e-mail]>; Tue, 5 Mar 2002 09:51:08 -0800 (PST)
Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2653.19) id <15Y13VCS>; Tue, 5 Mar 2002 09:55:51 -0800
Message-ID: <[e-mail]>
From: "Deacon, Alex" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: Validation policy in DPV/DPD rqmts
Date: Tue, 5 Mar 2002 09:55:26 -0800 
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>

All,

My .02 cents after catching up on this very long thread.  I'll try to make
them quick:

* Mandating additional granularity on the current "valid, invalid, unknown"
status is a bad idea IMO.  I would prefer to have this requirement removed;
however if server support for "potentially valid" (or sort-of-valid,
kind-of-valid, whatever) is specified as a MAY (as I believe we have
decided) then I suppose I can live with it.

* Requirements that add additional processing requirements on clients is
also, IMO, a bad idea.  The idea of OCSP/DPD/DPV/etc servers is to move
complexity away from the client.  I'm scared by the talk of path validation
policy negotiation.  Concepts like this will lever fly in constrained
clients such as mobile phones.

* I agree with Mike's wording below on the minimum requirements need for a
server to assert a "valid" status.  Lets make sure we have some base/minimum
assumptions regarding what a server should do, and lets make sure it
reflects the hard work and decisions we made in PKIX path processing.  

Alex


> -----Original Message-----
> From: Michael Myers [mailto:[e-mail]]
> Sent: Friday, March 01, 2002 12:30 PM
> To: Housley, Russ
> Cc: [e-mail]
> Subject: RE: Validation policy in DPV/DPD rqmts
> 
> 
> 
> > -----Original Message-----
> > From: Housley, Russ
> > Sent: Friday, March 01, 2002 5:26 AM
> >
> > Mike:
> >
> > Please post your suggested text.  Based on your
> > message, it should not need to be more than a
> > paragraph.  Did I miss something?
> >
> > Russ
> 
> Russ,
> 
> Here's a first cut.  I suggest inserting this text immediately
> following the identification of the various states a DPV server
> must be capable of producing.
> 
> Mike
> 
> 
> Prior to asserting a "valid" status, a DPV server SHALL, at a
> minimum:
> 
> 1. confirm that, in the time context of the request, the subject
> certificate is (or was) niether revoked nor suspended by the
> authority that issued the certificate;
> 
> 2.  confirm that, in the time context of the request, all
> certificates needed to complete the associated validation path
> are (or were) niether revoked nor suspended, up to and including
> the trust anchor; AND
> 
> 2.  confirm that the subject certificate and its associated
> intermediate and trust anchor certificates form a chain that
> satisifies the path validation algorithm defined by RFC 2459 or
> its successors [PKIX-1].
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g25FqDY17415 for ietf-pkix-bks; Tue, 5 Mar 2002 07:52:13 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g25FqB817411 for <[e-mail]>; Tue, 5 Mar 2002 07:52:11 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id QAA17424; Tue, 5 Mar 2002 16:51:59 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 5 Mar 2002 16:51:59 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id QAA23892; Tue, 5 Mar 2002 16:51:57 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id QAA22254; Tue, 5 Mar 2002 16:51:57 +0100 (MET)
Date: Tue, 5 Mar 2002 16:51:57 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: DPD/DPV reqmts: hash of the request
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>

Russ and Mike,

If the following text for DPV requirements looks 
basically acceptable concerning the bindings
of a request to a response, feel free to correct
my English or whatever. 

Thanks in advance
Peter


- The protocol MUST provide a means permitting a client
  to associate a response to a request. This MAY be achieved
  either by using transport layer mechanisms, or by
  payload information.

- There MUST be a method to allow a client to force a
  specifique response, e.g. by using a nonce. Note, that
  this does not mean that information cannot be cached. 

- If a response contains a binding to some other information,
  e.g. to the original request, the techniques used should
  provide for long term stability, e.g., explicit copying
  of some information, in particular, a response MUST contain
  sufficient information in order to determine what certificate
  path validation had been requested. 




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g25ESxR13372 for ietf-pkix-bks; Tue, 5 Mar 2002 06:28:59 -0800 (PST)
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 g25ESr813363 for <[e-mail]>; Tue, 5 Mar 2002 06:28:53 -0800 (PST)
Received: from smtp.digsigtrust.com by smtp1.digsigtrust.com  with ESMTP id g25ESna21195; Tue, 5 Mar 2002 07:28:49 -0700 (MST)
Received: from cc474623a (chr152dhcp1050.chrchv01.md.comcast.net [68.33.156.26]) by smtp.digsigtrust.com with SMTP id g25EQNk20283; Tue, 5 Mar 2002 07:26:23 -0700 (MST)
Reply-To: <[e-mail]>
From: "Yuriy Dzambasow" <[e-mail]>
To: "Housley, Russ" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: DPV Request Policy Inputs
Date: Tue, 5 Mar 2002 09:27:37 -0500
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]>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
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>

Russ:

>
> Yuriy:
>
> >2. Section 4 3rd paragraph
> >
> >The requirements document should not forbid specification
> >of the policy with a request. If the protocol writers find that
> >specifying the policy (or a subset of the policy) with the
> >request is too burdensome, let them make that decision. Allowing
> >a client to specify a frequently changing part of the policy
> >with every request wouldn't be a bad decision
> >
> >[Denis Answer 11]
> >
> >Validation policies are usually not defined by end-users but by
> >administrators. So why a separate protocol should be used, the
> policy is not
> >locally defined. Clients should not define policies. As we know, policy
> >parameters are quite complex.
> >Yuriy> But clients can specify which trusted roots to use and certain
> >constraints.  I believe it would be beneficial in some cases
> (where policy
> >is easily defined) for a client to specify these things as part of a DPV
> >request, and not have to make a separate PDP request (which is
> more suitable
> >for complex policies).
>
> When I think of policy elements, I think of the inputs to the
> certification
> path validation algorithm in Son-of-2459.  Do you think that the protocol
> needs to include OPTIONAL fields that allow the client to specify all of
> these inputs on a per-request basis?
>
> Russ
>

Yes; however, it probably makes sense to examine the set of inputs defined
in son of 2459.  From section 6.1.1 in draft-ietf-pkix-new-part1-12, the
defined inputs are (followed by my comments):

a) a perspective certification path of length n

I don't believe it makes sense for a client to define this in a request to a
server, as the client probably has no knowledge of certificate path length

b) the current date/time

Rather than the current date/time, allow the client to specify some
specified date/time

c) user-initial-policy-set

Allow the client to specify this to a server.  I know of many environments
where relying parties use policy OIDs to determine a grade/level of
certificate to control access to applications and resources.  The validation
server typically is not aware of these specific relying party policy
requirements, and therefore the relying party client must be able to specify
this to the validation server.

d) trust anchor information

Allow the client to specify this to a server, for obvious reasons.

e) initial-policy-mapping-inhibit

Do not allow a client to specify this to a server, as policy mapping is
typically controlled by higher authorities.

f) initial-explicit-policy

I do not personally see a need for a client to specify this to a server, but
there probably exists a need somewhere.

3) initial-any-policy-inhibit

I do not personally see a need for a client to specify this to a server, but
there probably exists a need somewhere.

To summarize, the date/time, user-initial-policy-set, and trust anchor
information would be useful OPTIONAL parameters to pass from a client to a
server in a DPV/DPD request.

Yuriy



Received: by above.proper.com (8.11.6/8.11.3) id g25E40J12748 for ietf-pkix-bks; Tue, 5 Mar 2002 06:04:00 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g25E3w812742 for <[e-mail]>; Tue, 5 Mar 2002 06:03:58 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 5 Mar 2002 14:03:36 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA23545 for <[e-mail]>; Tue, 5 Mar 2002 09:03:41 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g25E3wP19925 for <[e-mail]>; Tue, 5 Mar 2002 09:03:58 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <F4N539YY>; Tue, 5 Mar 2002 09:01:46 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.4]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F4N539YQ; Tue, 5 Mar 2002 09:01:39 -0500
From: "Housley, Russ" <[e-mail]>
To: Michael Myers <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 05 Mar 2002 08:54:24 -0500
Subject: RE: DPD/DPV reqmts: hash of the request 
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>

Mike:

I understand your points.

What, if any, language would you like to see added to the document?

Russ

At 04:00 PM 3/4/2002 -0800, Michael Myers wrote:

>Russ,
>
>Searched the list but couldn't find the reference although I do
>recall the same.
>
>However, my point is that both RFC2560/OCSP and the SCVP I-D
>enable nonces but don't mandate their use.  While I can't speak
>directly to the SCVP I-D, 2560's cert status envelope makes this
>practice optional in order to enable the pre-production of
>responses while yet enabling more rigorous environments the
>ability to force a direct binding between request and response.
>
>A MUST requirement forcing a one-to-one binding between a DPV
>response and its corresponding request breaks this allowance.  I
>recommend a SHOULD.
>
>Mike
>
>
> > -----Original Message-----
> > From: Housley, Russ [mailto:[e-mail]]
> >
> > They are not in the document, but I recall some email
> > requesting an identifier in the request that could
> > be paired with the same identifier in the response.
> >
> > Russ
> >
> >
> > -----Original Message-----
> > From: Michael Myers
> >
> > What nonce handling requirements?
> >
> > Mike
> >
> > > -----Original Message-----
> > > From: Housley, Russ [mailto:[e-mail]]
> > >
> > > I think that the nonce handling requirements already
> > > prevent this type of processing.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g25DCBU08483 for ietf-pkix-bks; Tue, 5 Mar 2002 05:12:11 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g25DC9808479 for <[e-mail]>; Tue, 5 Mar 2002 05:12:10 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 5 Mar 2002 13:11:47 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA16088 for <[e-mail]>; Tue, 5 Mar 2002 08:11:52 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g25DC8C11078 for <[e-mail]>; Tue, 5 Mar 2002 08:12:08 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <F4N538Q5>; Tue, 5 Mar 2002 08:09:57 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.4]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F4N538Q4; Tue, 5 Mar 2002 08:09:45 -0500
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 04 Mar 2002 08:27:46 -0500
Subject: DPV Request Policy Inputs
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>

Yuriy:

>2. Section 4 3rd paragraph
>
>The requirements document should not forbid specification
>of the policy with a request. If the protocol writers find that
>specifying the policy (or a subset of the policy) with the
>request is too burdensome, let them make that decision. Allowing
>a client to specify a frequently changing part of the policy
>with every request wouldn't be a bad decision
>
>[Denis Answer 11]
>
>Validation policies are usually not defined by end-users but by
>administrators. So why a separate protocol should be used, the policy is not
>locally defined. Clients should not define policies. As we know, policy
>parameters are quite complex.
>Yuriy> But clients can specify which trusted roots to use and certain
>constraints.  I believe it would be beneficial in some cases (where policy
>is easily defined) for a client to specify these things as part of a DPV
>request, and not have to make a separate PDP request (which is more suitable
>for complex policies).

When I think of policy elements, I think of the inputs to the certification 
path validation algorithm in Son-of-2459.  Do you think that the protocol 
needs to include OPTIONAL fields that allow the client to specify all of 
these inputs on a per-request basis?

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g252UoE20988 for ietf-pkix-bks; Mon, 4 Mar 2002 18:30:50 -0800 (PST)
Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g252Um820982 for <[e-mail]>; Mon, 4 Mar 2002 18:30:48 -0800 (PST)
Received: from tsg1 ([12.81.111.159]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020305023045.TKWP13933.mtiwmhc22.worldnet.att.net@tsg1>; Tue, 5 Mar 2002 02:30:45 +0000
Message-ID: <000f01c1c3ed$be9b2a70$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Peter Williams" <[e-mail]>, "Anders Rundgren" <[e-mail]>
Cc: "LISTS - IETF-PKIX" <[e-mail]>
References: <[e-mail]>
Subject: Re: XKMS: Was: Validation policy in DPV/DPD rqmts
Date: Mon, 4 Mar 2002 18:30:39 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

----- Original Message ----- 
From: "Peter Williams" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: "LISTS - IETF-PKIX" <[e-mail]>
Sent: Monday, March 04, 2002 4:26 PM
Subject: RE: XKMS: Was: Validation policy in DPV/DPD rqmts


> 
> PPP over ATM/Ethernet used in broadband DSL contains a nice 
> discovery  protocol. It seems a shame we cant do something 
> a little more useful with PKIX like merge IPSEC/IKE tunnel 
> and channel setup with PPP over "media" discovery modes and 
> perhaps leverage network-discovery techniques to implement 
> the DPV/DPD  requirements in support of IKE tunnels/paths 
> working alongside PPP setup.  
> 
> Effective networking on a large-scale involves merging 
> private and switched level 2 net architectures with the  
> various Internet Layer 3 ISP architectures. US and European 
> Internet backbones are quite different in their 
> connectivity achitectures, of course.  This reality has 
> major impact upon the needs for cert discovery  mechanisms, 
> when cert paths are attempting to help secure virtual  
> tunnels and paths for datagrams in real, bridged level-2 
> networks, where bridges are operated under different govt 
> regulations, have different security policies, tap points 
> for cell-level surveillance, etc, or just have simply 
> different concepts for linking ISPs to form a public 
> infrastructure.
> 
> Rather than bicker about XKMS, lets focus on real needs for 
> PKI, where some world class IETF engineering is required. 
> Fiddling with  ASN.1 and XML msg specs is not the kind of  
> engineering IETF should be overly focusing on. We really 
> need to address bridging and switching problems which have 
> actual requirements  for discovery engineering - 
> requirements that are hard  to address, once we scale IPSEC 
> for real, for real layer 2 nets.  
> 
> If we can make discovery requirements adapt to the network, 
> we could make PKI almost useful to IKE or SSL handshakes, 
> so that cert discovery can actually play a part in net-
> subscriber management, and net-service access control. We 
> really need to ensure cert discovery is not a 
> directory/DNS-function or application function, but a 
> network  function.

Actually it may be that both are needed.

> 
> Surely, part of the  benefit of putting up a discovery 
> service for PKI  applications is enabling the selection of 
> cert paths to select the right security context and 
> mechanism strength for the traffic type at level 2, at  the 
> right QoS, for the bridges and switches and translation 
> tables packets  must cross in practice. We cannot expect 
> applications to know about any of this (everything is just 
> a datagram or a pipe), so we have to focus on the  realtime 
> network to gather real requirements for DPV/DPD behaviour.  

At least with what PKIX has to offer today that is. 

> 
> In conclusion, Anders, IETF could have lots to contribute 
> to a valuable  DPV/DPD protocol. This is not to say that 
> W3C will not do just fine in fashioning an application-
> layer infrastructure using XKMS, and good luck to them and 
> the work. But, we need to focus here on network properties 
> to add any real value. A mix of DPD/DPV with cert policies
> and qualifiers, feels just about the right toolkit
> for all this, to me. The trick is now to formulate 
> actual protocol(s) that implement the abstract protocols
> of the requirement specs.
> 
> Peter.
> 
> 
> ---------
> 
> For historical perspective, if the IETF believed what the "industry" 
> said the major trends were in the past (as widely reported and 
> endorsed by trade magazines and in industry conferences), we would 
> all be communicating via OSI protocols over ATM, or, more recently, 
> over 3G wireless!

bravo!

> 
> Steve



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g250QRH18002 for ietf-pkix-bks; Mon, 4 Mar 2002 16:26:27 -0800 (PST)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g250QQ817998 for <[e-mail]>; Mon, 4 Mar 2002 16:26:26 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Mon, 4 Mar 2002 16:25:51 -0800 (PST)
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, 04 Mar 2002 16:25:50 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2653.19) id <FW60GCM4>; Mon, 04 Mar 2002 16:26:19 -0800
Content-return: allowed
Date: Mon, 04 Mar 2002 16:26:16 -0800
From: Peter Williams <[e-mail]>
Subject: RE: XKMS: Was: Validation policy in DPV/DPD rqmts
To: Anders Rundgren <[e-mail]>
Cc: LISTS - IETF-PKIX <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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>

PPP over ATM/Ethernet used in broadband DSL contains a nice 
discovery  protocol. It seems a shame we cant do something 
a little more useful with PKIX like merge IPSEC/IKE tunnel 
and channel setup with PPP over "media" discovery modes and 
perhaps leverage network-discovery techniques to implement 
the DPV/DPD  requirements in support of IKE tunnels/paths 
working alongside PPP setup.  

Effective networking on a large-scale involves merging 
private and switched level 2 net architectures with the  
various Internet Layer 3 ISP architectures. US and European 
Internet backbones are quite different in their 
connectivity achitectures, of course.  This reality has 
major impact upon the needs for cert discovery  mechanisms, 
when cert paths are attempting to help secure virtual  
tunnels and paths for datagrams in real, bridged level-2 
networks, where bridges are operated under different govt 
regulations, have different security policies, tap points 
for cell-level surveillance, etc, or just have simply 
different concepts for linking ISPs to form a public 
infrastructure.

Rather than bicker about XKMS, lets focus on real needs for 
PKI, where some world class IETF engineering is required. 
Fiddling with  ASN.1 and XML msg specs is not the kind of  
engineering IETF should be overly focusing on. We really 
need to address bridging and switching problems which have 
actual requirements  for discovery engineering - 
requirements that are hard  to address, once we scale IPSEC 
for real, for real layer 2 nets.  

If we can make discovery requirements adapt to the network, 
we could make PKI almost useful to IKE or SSL handshakes, 
so that cert discovery can actually play a part in net-
subscriber management, and net-service access control. We 
really need to ensure cert discovery is not a 
directory/DNS-function or application function, but a 
network  function.

Surely, part of the  benefit of putting up a discovery 
service for PKI  applications is enabling the selection of 
cert paths to select the right security context and 
mechanism strength for the traffic type at level 2, at  the 
right QoS, for the bridges and switches and translation 
tables packets  must cross in practice. We cannot expect 
applications to know about any of this (everything is just 
a datagram or a pipe), so we have to focus on the  realtime 
network to gather real requirements for DPV/DPD behaviour.  

In conclusion, Anders, IETF could have lots to contribute 
to a valuable  DPV/DPD protocol. This is not to say that 
W3C will not do just fine in fashioning an application-
layer infrastructure using XKMS, and good luck to them and 
the work. But, we need to focus here on network properties 
to add any real value. A mix of DPD/DPV with cert policies
and qualifiers, feels just about the right toolkit
for all this, to me. The trick is now to formulate 
actual protocol(s) that implement the abstract protocols
of the requirement specs.

Peter.


---------

For historical perspective, if the IETF believed what the "industry" 
said the major trends were in the past (as widely reported and 
endorsed by trade magazines and in industry conferences), we would 
all be communicating via OSI protocols over ATM, or, more recently, 
over 3G wireless!

Steve


Received: by above.proper.com (8.11.6/8.11.3) id g2502tp17452 for ietf-pkix-bks; Mon, 4 Mar 2002 16:02:55 -0800 (PST)
Received: from geos.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2502r817446 for <[e-mail]>; Mon, 4 Mar 2002 16:02:53 -0800 (PST)
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 g2502pi21321 for <[e-mail]>; Mon, 4 Mar 2002 16:02:52 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: RE: DPD/DPV reqmts: hash of the request 
Date: Mon, 4 Mar 2002 16:00:19 -0800
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>

Russ,

Searched the list but couldn't find the reference although I do
recall the same.

However, my point is that both RFC2560/OCSP and the SCVP I-D
enable nonces but don't mandate their use.  While I can't speak
directly to the SCVP I-D, 2560's cert status envelope makes this
practice optional in order to enable the pre-production of
responses while yet enabling more rigorous environments the
ability to force a direct binding between request and response.

A MUST requirement forcing a one-to-one binding between a DPV
response and its corresponding request breaks this allowance.  I
recommend a SHOULD.

Mike


> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
>
> They are not in the document, but I recall some email
> requesting an identifier in the request that could
> be paired with the same identifier in the response.
>
> Russ
>
>
> -----Original Message-----
> From: Michael Myers
>
> What nonce handling requirements?
>
> Mike
>
> > -----Original Message-----
> > From: Housley, Russ [mailto:[e-mail]]
> >
> > I think that the nonce handling requirements already
> > prevent this type of processing.



Received: by above.proper.com (8.11.6/8.11.3) id g24MMTC14692 for ietf-pkix-bks; Mon, 4 Mar 2002 14:22:29 -0800 (PST)
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 g24MMS814688 for <[e-mail]>; Mon, 4 Mar 2002 14:22:28 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA26059; Mon, 4 Mar 2002 17:22:23 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100308b8a9917d61ad@[128.89.88.34]>
In-Reply-To: <006a01c1c1f4$50ce4180$0500a8c0@arport>
References: <20020228012927.CFKS2951.rwcrmhc53.attbi.com@rwcrwbc57> <04ae01c1c061$5f401340$020aff0c@tsg1> <p05100301b8a3f455959c@[128.89.88.34]> <050101c1c074$e8b722e0$020aff0c@tsg1> <p05100305b8a4171bc0f9@[128.89.88.34]> <054b01c1c09e$646263e0$020aff0c@tsg1> <p05100315b8a4527cb463@[128.89.88.34]> <058c01c1c0ab$2c86d8e0$020aff0c@tsg1> <p05100300b8a467b2b048@[128.89.88.34]> <006a01c1c1f4$50ce4180$0500a8c0@arport>
Date: Mon, 4 Mar 2002 17:14:59 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: XKMS: Was: Validation policy in DPV/DPD rqmts
Cc: "LISTS - 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>

At 3:12 PM +0100 3/2/02, Anders Rundgren wrote:
>Well, if we are going to discuss the validity of certain PKIX work,
>may I question this list how you plan to differentiate DPV/DPD
>with XKMS?
>
>To me it seems that the "industry" have no interest to support two
>similar schemes, so PKIX is probably too late with this proposal as the
>"competitor" is already running.  If the "competitor" lacks some
>features, I think the "industry" will do a "revision", rather than
>begin toiling with something new.  Particularly as the "industry" has
>indicated that they want to work with XML, and only use ASN.1
>where it is necessary for historical reasons like for certificates.
>
>Anders

Anders,

The WG discussed use of XML for DPV/DPD over a year ago and decided 
to pursue the work using ASN.1 syntax. The first version of SCVP 
offered both syntaxes; the current one does not.

As you and I have discussed in the past on the list, PKIX does not 
select work items based on what "the industry" has indicated is the 
future, but rather based on what members of the WG (who are 
individuals, not industry representatives) choose to pursue. As I'm 
sure you know, much of what is promoted as industry trends are really 
marketing/PR efforts by vendors trying to influence other vendors and 
consumers to adopt selected technologies, approaches, etc.  XKMS may 
or may not fall into this category; I don't mean to judge it in the 
context of this discussion. The XKMS authors chose to pursue its 
standardization in another forum, W3C, so it's not something PKIX 
needs to deal with at this time.

For historical perspective, if the IETF believed what the "industry" 
said the major trends were in the past (as widely reported and 
endorsed by trade magazines and in industry conferences), we would 
all be communicating via OSI protocols over ATM, or, more recently, 
over 3G wireless!

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g24L3aM12499 for ietf-pkix-bks; Mon, 4 Mar 2002 13:03:36 -0800 (PST)
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 g24L3Z812494 for <[e-mail]>; Mon, 4 Mar 2002 13:03:35 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA14861; Mon, 4 Mar 2002 16:02:50 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100307b8a990962b6a@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 4 Mar 2002 16:00:18 -0500
To: "Roberto Opazo Gazmuri" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Q: Where should do I put a max mount in a X.509v3 certificate?
Cc: "PKIX \(Grupo de la IETF\)" <[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 g24L3Z812495
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 1:50 PM -0300 3/3/02, Roberto Opazo Gazmuri wrote:
>IETF-PXIX:
>
>I would like to ask the WG opinion about “the correct” place to indicate
>that a certificate should not be used to validate electronic signatures for
>a mount over a determined maximum.
>
>Here we are delegating in de RP the responsibility of validating the
>certificate content to see if there is a limit and I have not seen a good
>place to put this information. We need to indicate:
>1.- There is a general limit, not for a specific transaction type
>2.- The mount of the limit
>3.- The type of money in witch the mount is expressed
>
>Is there a standard extension for that?
>
>Thanks,
>
>Opazo, Roberto ([e-mail])
>CEO - www.acepta.com
>Certification Authority for Chile

There is no standard extension for conveying this info.  One might 
use the policy ID field and policy qualifiers to represent this info 
in a machine readable fashion, but we have generally advised folks to 
not use the policy qualifier field.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g24KpZB12199 for ietf-pkix-bks; Mon, 4 Mar 2002 12:51:35 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g24KpX812195 for <[e-mail]>; Mon, 4 Mar 2002 12:51:33 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 4 Mar 2002 20:51:13 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA06578; Mon, 4 Mar 2002 15:51:18 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g24KpX119792; Mon, 4 Mar 2002 15:51:33 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <F4N53W86>; Mon, 4 Mar 2002 15:49:22 -0500
Message-ID: <[e-mail]>
From: "Housley, Russ" <[e-mail]>
To: "'Michael Myers '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Cc: "'[e-mail] '" <[e-mail]>
Subject: RE: DPD/DPV reqmts: hash of the request 
Date: Mon, 4 Mar 2002 15:51:09 -0500 
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>

Mike:

They are not in the document, bu I recall some email requesting an
indentifier in the request that could be paired with the same identifier in
the response.

Russ
 

-----Original Message-----
From: Michael Myers
To: Housley, Russ; [e-mail]
Cc: [e-mail]
Sent: 3/4/02 2:35 PM
Subject: RE: DPD/DPV reqmts: hash of the request 

Russ,

What nonce handling requirements?

Mike

> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
> Sent: Monday, March 04, 2002 11:18 AM
> To: 'Michael Myers '; '[e-mail] '
> Cc: '[e-mail] '
> Subject: RE: DPD/DPV reqmts: hash of the request 
> 
> 
> Mike:
> 
> I think that the nonce handling requirements already 
> prevent this type of
> processing.
> 
> Russ


Received: by above.proper.com (8.11.6/8.11.3) id g24Jc1O10055 for ietf-pkix-bks; Mon, 4 Mar 2002 11:38:01 -0800 (PST)
Received: from geos.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g24Jc0810051 for <[e-mail]>; Mon, 4 Mar 2002 11:38:00 -0800 (PST)
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 g24Jbsi22172; Mon, 4 Mar 2002 11:37:56 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "Housley, Russ" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: DPD/DPV reqmts: hash of the request 
Date: Mon, 4 Mar 2002 11:35:24 -0800
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>

Russ,

What nonce handling requirements?

Mike

> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
> Sent: Monday, March 04, 2002 11:18 AM
> To: 'Michael Myers '; '[e-mail] '
> Cc: '[e-mail] '
> Subject: RE: DPD/DPV reqmts: hash of the request 
> 
> 
> Mike:
> 
> I think that the nonce handling requirements already 
> prevent this type of
> processing.
> 
> Russ


Received: by above.proper.com (8.11.6/8.11.3) id g24JM6609605 for ietf-pkix-bks; Mon, 4 Mar 2002 11:22:06 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g24JM4809598 for <[e-mail]>; Mon, 4 Mar 2002 11:22:04 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 4 Mar 2002 19:21:44 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA28893; Mon, 4 Mar 2002 14:21:49 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g24JM4m10868; Mon, 4 Mar 2002 14:22:04 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <F4N53VHS>; Mon, 4 Mar 2002 14:19:52 -0500
Message-ID: <[e-mail]>
From: "Housley, Russ" <[e-mail]>
To: "'Peter Sylvester '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Cc: "'[e-mail] '" <[e-mail]>
Subject: RE: DPD/DPV reqmts: hash of the request
Date: Mon, 4 Mar 2002 14:21:45 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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>

Peter:

None of these seem particularly onerous.  However, I am not sure where you
would like to see them incorporated into the document.  Please propose
specific changes.

Russ

-----Original Message-----
From: Peter Sylvester
To: Housley, Russ; [e-mail]
Cc: [e-mail]
Sent: 3/4/02 1:29 PM
Subject: RE: DPD/DPV reqmts: hash of the request

Russ, Mike,


Some thoughts about what could be the meaning of
one or more requirements: 

- A response should contain sufficient information so that by
  looking to them either the original request or something
  equivalent could be determined.

- Given a set of few requests, and a response, it is
  easy to determine the request that corresponds to
  the request. 

- A response should contain sufficient information
  so that it is clear to what "kind of" request it
  refers to. 

Somewhat orthogonal: When does one need to detect this
'binding'. 

- Immediately after getting the response ?
 
- 5 years later ?
 

A probably really bad example would be that a DPV response 
to contain 'yes + CA certificate' 
but no indication of the EE certificate in question.

I think that the protocol should not prohibit too much
the preproduction of results.


Regards
Peter

> 
> Russ,
> 
> This also breaks pre-produced responses, a practice that can
> reduce latency.  Is this collateral effect intended?
> 
> Mike
> 
> > -----Original Message-----
> > From: Housley, Russ
> >
> > In my opinion, the requirement is to bind the
> > response back to the request.
> 
> 


Received: by above.proper.com (8.11.6/8.11.3) id g24JIJA09479 for ietf-pkix-bks; Mon, 4 Mar 2002 11:18:19 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g24JIH809475 for <[e-mail]>; Mon, 4 Mar 2002 11:18:17 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 4 Mar 2002 19:17:57 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA28555; Mon, 4 Mar 2002 14:18:02 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g24JIHQ10472; Mon, 4 Mar 2002 14:18:17 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <F4N53VFD>; Mon, 4 Mar 2002 14:16:06 -0500
Message-ID: <[e-mail]>
From: "Housley, Russ" <[e-mail]>
To: "'Michael Myers '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Cc: "'[e-mail] '" <[e-mail]>
Subject: RE: DPD/DPV reqmts: hash of the request 
Date: Mon, 4 Mar 2002 14:17:59 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
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>

Mike:

I think that the nonce handling requirements already prevent this type of
processing.

Russ


-----Original Message-----
From: Michael Myers
To: Housley, Russ; [e-mail]
Cc: [e-mail]
Sent: 3/4/02 11:54 AM
Subject: RE: DPD/DPV reqmts: hash of the request 


Russ,

This also breaks pre-produced responses, a practice that can
reduce latency.  Is this collateral effect intended?

Mike

> -----Original Message-----
> From: Housley, Russ
>
> In my opinion, the requirement is to bind the
> response back to the request.


Received: by above.proper.com (8.11.6/8.11.3) id g24ITuH08391 for ietf-pkix-bks; Mon, 4 Mar 2002 10:29:56 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g24ITs808387 for <[e-mail]>; Mon, 4 Mar 2002 10:29:54 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA12707; Mon, 4 Mar 2002 19:29:40 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 4 Mar 2002 19:29:41 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id TAA19760; Mon, 4 Mar 2002 19:29:39 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA21873; Mon, 4 Mar 2002 19:29:39 +0100 (MET)
Date: Mon, 4 Mar 2002 19:29:39 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: DPD/DPV reqmts: hash of the request
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>

Russ, Mike,


Some thoughts about what could be the meaning of
one or more requirements: 

- A response should contain sufficient information so that by
  looking to them either the original request or something
  equivalent could be determined.

- Given a set of few requests, and a response, it is
  easy to determine the request that corresponds to
  the request. 

- A response should contain sufficient information
  so that it is clear to what "kind of" request it
  refers to. 

Somewhat orthogonal: When does one need to detect this
'binding'. 

- Immediately after getting the response ?
 
- 5 years later ?
 

A probably really bad example would be that a DPV response 
to contain 'yes + CA certificate' 
but no indication of the EE certificate in question.

I think that the protocol should not prohibit too much
the preproduction of results.


Regards
Peter

> 
> Russ,
> 
> This also breaks pre-produced responses, a practice that can
> reduce latency.  Is this collateral effect intended?
> 
> Mike
> 
> > -----Original Message-----
> > From: Housley, Russ
> >
> > In my opinion, the requirement is to bind the
> > response back to the request.
> 
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g24GvNP03288 for ietf-pkix-bks; Mon, 4 Mar 2002 08:57:23 -0800 (PST)
Received: from geos.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g24GvM803283 for <[e-mail]>; Mon, 4 Mar 2002 08:57:22 -0800 (PST)
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 g24Gv9i03527; Mon, 4 Mar 2002 08:57:09 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "Housley, Russ" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: DPD/DPV reqmts: hash of the request 
Date: Mon, 4 Mar 2002 08:54:40 -0800
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)
In-reply-to: <[e-mail]>
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>

Russ,

This also breaks pre-produced responses, a practice that can
reduce latency.  Is this collateral effect intended?

Mike

> -----Original Message-----
> From: Housley, Russ
>
> In my opinion, the requirement is to bind the
> response back to the request.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g24GORR01866 for ietf-pkix-bks; Mon, 4 Mar 2002 08:24:27 -0800 (PST)
Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g24GOO801862 for <[e-mail]>; Mon, 4 Mar 2002 08:24:25 -0800 (PST)
Received: from tsg1 ([12.81.71.126]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020304162420.WIMG13933.mtiwmhc22.worldnet.att.net@tsg1>; Mon, 4 Mar 2002 16:24:20 +0000
Message-ID: <005d01c1c399$090b9090$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Housley, Russ" <[e-mail]>, "'Roberto Opazo Gazmuri '" <[e-mail]>
Cc: "'IETF-PKIX '" <[e-mail]>
References: <[e-mail]>
Subject: Re: Where should do I put a max mount in a X.509v3 certificate?
Date: Mon, 4 Mar 2002 08:24:15 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree with you and Roberto, Russ - its just that today - there is really
no such thing as a digital coin, which is really what building a reliance
limit into a cert is all about. But I agree that there is an extreme need to
bring this capability to the PKIX arsenal, the question is in a AC or a
general CERT or in some other structure like a TST for instance. I think
this very question also demonstrates why we need a Policy Communications and
Negotiations protocol - and the integrated Time Stamp for evidentiary
purposes.

What I would suggest is that what this has always been about is Transaction
Processing. With that said what we actually need is a way of setting up the
stage and arena for the transaction and then performing and memorializing
it.

We pull that off and PKI will start moving -

Todd

----- Original Message -----
From: "Housley, Russ" <[e-mail]>
To: "'todd glassey '" <[e-mail]>; "'Roberto Opazo
Gazmuri '" <[e-mail]>
Cc: "'IETF-PKIX '" <[e-mail]>
Sent: Monday, March 04, 2002 6:35 AM
Subject: RE: Where should do I put a max mount in a X.509v3 certificate?


> Todd:
>
> While the CP and CPS should surely cover this topic, this is not a very
> useful place to carry this information if you expect automated processing
of
> a transaction.
>
> Roberto:
>
> To the best of my knowledge, no one has defined an extension for this
> information to be placed in the certificate.
>
> Russ
>
> -----Original Message-----
> From: todd glassey
> To: Roberto Opazo Gazmuri
> Cc: LISTS - IETF-PKIX
> Sent: 3/3/02 1:13 PM
> Subject: Re: Where should do I put a max mount in a X.509v3 certificate?
>
>
> Roberto - we went over exactly this thing in the Bar Association's
> Information Security Committee and the place that the liability and
> claimant
> requirements are codified is in a set of documents called the
> Certificate
> Policy Statement (CPS) and Practices Statements (PS). The other side of
> these is the Relying Party Agreement(RPA).  These three documents
> essentially form the of a contract, which is leveraged between the terms
> listed in them.structure
>
> The CPS and PS documents state the constraints of the Certificate and
> how
> the CA operates itself. The RPA is the other half of the picture and
> defines
> the relying party's obligations rights, and procedures for collecting
> against the indemnity provided.
>
> The problem is that there is no real method of communicating stated
> policy
> or negotiating inline. That is to say that without these complex legal,
> and
> externally referenced documents the structure of the x.509 certificate
> cannot by itself instantiate any level of liability per se.
>
> I have suggested several times that that PCP (Policy Communications
> Protocol) is a key missing part of any real Machine-operated PKI
> solution.
> The machines must be given a way of negotiating the specific policies
> and
> constraints under which they will work and they need to do this together
> with the other CA's so that applications can make inline decisions as to
> what they will and wont trust.
>
> By the way, the assigning of a value to an x509 certificate turns it
> into a
> financial token and you would need much more than just this group to
> approve
> of that since there are then legal implications attached that are not
> necessarily apparent.
>
> Todd Glassey
>
> ----- Original Message -----
> From: "Roberto Opazo Gazmuri" <[e-mail]>
> To: "PKIX (Grupo de la IETF)" <[e-mail]>
> Sent: Sunday, March 03, 2002 8:50 AM
> Subject: Q: Where should do I put a max mount in a X.509v3 certificate?
>
>
>
> IETF-PXIX:
>
> I would like to ask the WG opinion about "the correct" place to indicate
> that a certificate should not be used to validate electronic signatures
> for
> a mount over a determined maximum.
>
> Here we are delegating in de RP the responsibility of validating the
> certificate content to see if there is a limit and I have not seen a
> good
> place to put this information. We need to indicate:
> 1.- There is a general limit, not for a specific transaction type
> 2.- The mount of the limit
> 3.- The type of money in witch the mount is expressed
>
> Is there a standard extension for that?
>
> Thanks,
>
> Opazo, Roberto ([e-mail])
> CEO - www.acepta.com
> Certification Authority for Chile
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g24FuKR26523 for ietf-pkix-bks; Mon, 4 Mar 2002 07:56:20 -0800 (PST)
Received: from portal.gmu.edu (portalknot.gmu.edu [129.174.0.8]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g24FuI826510 for <[e-mail]>; Mon, 4 Mar 2002 07:56:18 -0800 (PST)
Received: from phessel ([129.174.244.115]) by portal.gmu.edu (8.8.8/8.8.8) with SMTP id KAA26281; Mon, 4 Mar 2002 10:55:55 -0500 (EST)
Reply-To: <[e-mail]>
From: "Peter Hesse" <[e-mail]>
To: "'todd glassey'" <[e-mail]>, <[e-mail]>
Cc: "'LISTS - IETF-PKIX'" <[e-mail]>
Subject: RE: Political Discussion
Date: Mon, 4 Mar 2002 10:55:57 -0500
Message-ID: <000101c1c395$1372d240$6401a8c0@phessel>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
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: <001a01c1c37f$f7a05f70$020aff0c@tsg1>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Todd,

It is a simple courtesy to change the subject line of the posting when the
subject of the message changes.  It happens quite often.  It has happened a
few times in fairly recent memory in regards to your postings-- subject
lines such as "Changing the IETF (was Re: Validation policy in DPV/DPD
rqmts)" or "Motions before the WG - Was Re: Software for PKI" or "PKIX
reform issues - Was Re: I-D ACTION:draft-ietf-pkix-okid-00.txt".  It
commonly changes in the course of technical discussions as well--subjects
such as "XKMS, Was RE: Software for PKI", or "Copying smart cards.  Was: A
PKI Question: PKCS11-> PKCS12".

I am unsure of what purpose you are trying to achieve by repeatedly posting
calls for the WG co-chair's head in a technical working group.  If there
were significant support for your position, you probably would have heard it
by now.  I will now join the chorus of people asking that you pursue this
via alternate means than posting to this list.  You can, of course, post
whatever you wish--in which case I ask as Michael did that you provide the
common courtesy of a subject line change.

Thanks,

--Peter Hesse

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of todd glassey
> Sent: Monday, March 04, 2002 8:25 AM
> To: [e-mail]
> Cc: LISTS - IETF-PKIX
> Subject: Re: Political Discussion
>
>
>
> So then are you proposing a PKIX etiquette change wherein
> when the subject
> content is going to change on the technical level then the
> RFC822 subject
> should change too.
>
> Just so I am real clear on this  - and  I have to ask -
> should this same
> rule apply to technical changes in a subject thread too or
> only when the
> subject becomes political? Say that someone changes the
> technical aspects of
> a conversation to some other technological discussion  - You
> see because any
> change in any thread can be construed as violating this same
> edict. So where
> do you draw the line?
>
> What I am asking Michael - is how to you would suggest differentiating
> particular technical discussions (i.e ones that you are interested in
> participating in) from any other.
>
> Todd Glassey
> ----- Original Message -----
> From: "Michael Ströder" <[e-mail]>
> To: "todd glassey" <[e-mail]>
> Cc: "LISTS - IETF-PKIX" <[e-mail]>
> Sent: Monday, March 04, 2002 2:34 AM
> Subject: Re: Political Discussion
>
>
> >
> > todd glassey wrote:
> > >
> > > As to a filter - that is the issue with EMail - you never
> know what it
> is
> > > until you open it.
> >
> > I disagree. I strongly suggest that people stay on topic if someone
> started
> > a thread with a certain topic. If the topic changes during
> discussion the
> > subject should be changed. That's the only solution for an efficient
> > handling of discussions on mailing lists.
> >
> > > The problem with a separate political thread address
> > > would be that no one would read it if it sat by itself alone.
> >
> > You're telling us that you want to mix your personal
> political opinions
> into
> > other discussion threads just to make us noticing them?
> With this attitude
> > your postings are getting very close to my kill file.
> >
> > > That is the
> > > problem and the joy of the IETF's architecture.
> >
> > If you want to do politics then be political in the right
> place. Make the
> > IETF or your government/company/whatever aware of what you think the
> problem
> > is. But do not mess up technical discussions!
> >
> > Ciao, Michael.
> >
>
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g24FZJ724263 for ietf-pkix-bks; Mon, 4 Mar 2002 07:35:19 -0800 (PST)
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 g24FZH824257 for <[e-mail]>; Mon, 4 Mar 2002 07:35:17 -0800 (PST)
Received: from smtp.digsigtrust.com by smtp1.digsigtrust.com  with ESMTP id g24FZDa01331; Mon, 4 Mar 2002 08:35:13 -0700 (MST)
Received: from cc474623a (chr152dhcp1050.chrchv01.md.comcast.net [68.33.156.26]) by smtp.digsigtrust.com with SMTP id g24FWkk02747; Mon, 4 Mar 2002 08:32:46 -0700 (MST)
Reply-To: <[e-mail]>
From: "Yuriy Dzambasow" <[e-mail]>
To: "todd glassey" <[e-mail]>, "Petra Barzin" <[e-mail]>
Cc: "PKIX" <[e-mail]>
Subject: RE: Should PDP Be a Separate Specification??
Date: Mon, 4 Mar 2002 10:34:03 -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.2911.0)
In-reply-to: <001301c1c30c$aae4a6a0$020aff0c@tsg1>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
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>

Todd,

I think both DEFINITION and NEGOTIATION could be supported by the same
protocol.  DEFINITION can be used by security managers to define a policy at
a server.  NEGOTIATION can be used between clients and servers to negotiate
a policy that is acceptable to support operations like DPD and DPV.

Yuriy

-----Original Message-----
From: todd glassey [mailto:[e-mail]]
Sent: Sunday, March 03, 2002 6:39 PM
To: Petra Barzin; [e-mail]
Cc: PKIX
Subject: Re: Should PDP Be a Separate Specification??


Petra and Yuri -
Its not so much a Policy Definition Protocol, but a negotiation protocol.
What needs to happen is that some specific POLICY MODELS have to be built
(Stephen notice the Upper Case wording for emphasis :-), and these policy
models need a set of real world event types. From there you can actually
create a protocol that can be used to say:

"hey other end - this is what I have and here is how I want to do it. Can
you accommodate this "event type" and if so under what circumstances?" and
the response from the other end is  either a yes or a no and the terms and
conditions that it will accept or proffer.

This type of automated process wherein the application can negotiate and
make acceptance decisions is exactly what is missing from the PKI
infrastructure of PKIX today. That and the data structure standards, i.e.
the TST's and the like.

This is why timestamping and policy control and communication are so
important and obviously tied directly to each other at the use level.

PKIX's problem is clearly that the tools that it is proffering are not meant
to be used when Humans are not present and that is in my mind a clear error.
The whole point of overlaying human trust processes on top of machines is to
allow us to not have to be involved i the middle of the process.


Todd

----- Original Message -----
From: "Petra Barzin" <[e-mail]>
To: <[e-mail]>
Cc: "PKIX" <[e-mail]>
Sent: Sunday, March 03, 2002 12:11 PM
Subject: Re: Should PDP Be a Separate Specification??


>
> Yes, I agree. It should be a separate document!
>
> - Petra
>
> Yuriy Dzambasow schrieb:
>
> > It seems to me that it would be more beneficial to have a separate
> > requirements document for the Policy Definition Protocol (PDP) defined
in
> > the DPD/DPV requirements document, than to integrate into the DPD/DPV
> > document (which also attempts to address DSV policy requirements).  The
> > benefits of having a separate PDP requirements document are:
> >
> > - it focuses solely on policy definition to support protocols such as
> > DPD/DPV/DSV;
> > - the DPD/DPV/DSV specification can simply reference PDP as needed
> > - change control on the specifications are simplified (i.e., PDP changes
> > don't necessarily force changes to DPD/DPV/DSV)
> >
> > I'd like to hear thoughts from others on this.
> >
> > Yuriy
>




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g24FASg22785 for ietf-pkix-bks; Mon, 4 Mar 2002 07:10:28 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g24FAQ822774; Mon, 4 Mar 2002 07:10:26 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 4 Mar 2002 15:10:05 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA03748; Mon, 4 Mar 2002 10:10:11 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g24FAQp11845; Mon, 4 Mar 2002 10:10:26 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <F4N53Q3H>; Mon, 4 Mar 2002 10:08:15 -0500
Message-ID: <[e-mail]>
From: "Housley, Russ" <[e-mail]>
To: "'Blake Ramsdell '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'Paul Hoffman '" <[e-mail]>
Subject: RE: Comments on okid-01
Date: Mon, 4 Mar 2002 10:10:07 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
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>

Blake:

I would like to preserve the "CA" and "EE" labels.  Since many root
certificates are X.509v1, they do not include an extension that identifies
them as CA certificates.  I think that the ability to mark a X.509V1
certificate as a CA or EE is quite useful.

Russ
 

-----Original Message-----
From: Blake Ramsdell
To: [e-mail]; Paul Hoffman
Sent: 3/1/02 7:06 PM
Subject: Comments on okid-01


Section 2 -- I recommend that both MAY recommendations for receiving
implementations be changed to SHOULD.

Table 1 last column heading is truncated ("Charac" not "Character").

I'm not sure about the utility of the first two characters identifying
the
certificate type (EE vs. CA, specifically).  This creates a binding
between
the intended use of the certificate to the actual contents of the
certificate.  Since the entire certificate is now being hashed, it seems
like it is just another integrity field and does not seem to have any
other
useful purpose.  My worry is that this will introduce conflict for
conforming implementations that might have allowed root keys without the
CA
flag set, but have an OCKID implementation that enforces the check and
forces the user to modify the leading CA to be EE to satisfy the
integrity
check.  If it is desired to include the type identifier for human
reasons,
then I recommend that the comparison against the CA field in the
certificate
be optional, or that a generic certificate identifier be introduced.  I
may
not understand the goals of this identifier, however, so be gentle...

Blake
--
Blake Ramsdell
Brute Squad Labs http://www.brutesquadlabs.com


Received: by above.proper.com (8.11.6/8.11.3) id g24F1Cp21846 for ietf-pkix-bks; Mon, 4 Mar 2002 07:01:12 -0800 (PST)
Received: from nic.crt.se (nic.crt.se [193.12.107.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g24F1B821838 for <[e-mail]>; Mon, 4 Mar 2002 07:01:11 -0800 (PST)
Received: from mail.crt.se (postiljon.crt.se [172.16.1.14]) by nic.crt.se (Postfix) with ESMTP id 737F052A0; Mon,  4 Mar 2002 16:01:10 +0100 (MET)
Received: from crt.se (fonbella.crt.se [172.16.1.169]) by mail.crt.se (Postfix) with ESMTP id 7E95F1DA3; Mon,  4 Mar 2002 16:01:09 +0100 (MET)
Date: Mon, 4 Mar 2002 16:01:09 +0100 (MET)
From: Jakob Schlyter <[e-mail]>
To: IETF PKIX WG <[e-mail]>
Subject: I-D ACTION:draft-schlyter-pkix-dns-01.txt
Message-ID: <[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>

FYI,

	jakob


---------- Forwarded message ----------
Date: Mon, 04 Mar 2002 07:05:01 -0500
From: [e-mail]
To: IETF-Announce:  ;
Subject: I-D ACTION:draft-schlyter-pkix-dns-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: DNS as X.509 PKIX Certificate Storage
	Author(s)	: J. Schlyter, L. Johansson
	Filename	: draft-schlyter-pkix-dns-01.txt
	Pages		: 6
	Date		: 01-Mar-02

A major problem facing PKIX deployment and implementation is the
problem of constructing certificate paths for input to the path
validation algorithm.  This draft describes the use of the DNS as a
certificate store and it's implication for path validation in PKIX.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-schlyter-pkix-dns-01.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

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

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


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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-schlyter-pkix-dns-01.txt".

NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.


Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.







Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g24EZmJ20721 for ietf-pkix-bks; Mon, 4 Mar 2002 06:35:48 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g24EZf820716 for <[e-mail]>; Mon, 4 Mar 2002 06:35:41 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 4 Mar 2002 14:35:19 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA00809; Mon, 4 Mar 2002 09:35:25 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g24EZc108398; Mon, 4 Mar 2002 09:35:38 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <F4N53PZJ>; Mon, 4 Mar 2002 09:33:27 -0500
Message-ID: <[e-mail]>
From: "Housley, Russ" <[e-mail]>
To: "'todd glassey '" <[e-mail]>, "'Roberto Opazo Gazmuri '" <[e-mail]>
Cc: "'IETF-PKIX '" <[e-mail]>
Subject: RE: Where should do I put a max mount in a X.509v3 certificate?
Date: Mon, 4 Mar 2002 09:35:15 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
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>

Todd:

While the CP and CPS should surely cover this topic, this is not a very
useful place to carry this information if you expect automated processing of
a transaction.

Roberto:

To the best of my knowledge, no one has defined an extension for this
information to be placed in the certificate.

Russ 

-----Original Message-----
From: todd glassey
To: Roberto Opazo Gazmuri
Cc: LISTS - IETF-PKIX
Sent: 3/3/02 1:13 PM
Subject: Re: Where should do I put a max mount in a X.509v3 certificate?


Roberto - we went over exactly this thing in the Bar Association's
Information Security Committee and the place that the liability and
claimant
requirements are codified is in a set of documents called the
Certificate
Policy Statement (CPS) and Practices Statements (PS). The other side of
these is the Relying Party Agreement(RPA).  These three documents
essentially form the of a contract, which is leveraged between the terms
listed in them.structure

The CPS and PS documents state the constraints of the Certificate and
how
the CA operates itself. The RPA is the other half of the picture and
defines
the relying party's obligations rights, and procedures for collecting
against the indemnity provided.

The problem is that there is no real method of communicating stated
policy
or negotiating inline. That is to say that without these complex legal,
and
externally referenced documents the structure of the x.509 certificate
cannot by itself instantiate any level of liability per se.

I have suggested several times that that PCP (Policy Communications
Protocol) is a key missing part of any real Machine-operated PKI
solution.
The machines must be given a way of negotiating the specific policies
and
constraints under which they will work and they need to do this together
with the other CA's so that applications can make inline decisions as to
what they will and wont trust.

By the way, the assigning of a value to an x509 certificate turns it
into a
financial token and you would need much more than just this group to
approve
of that since there are then legal implications attached that are not
necessarily apparent.

Todd Glassey

----- Original Message -----
From: "Roberto Opazo Gazmuri" <[e-mail]>
To: "PKIX (Grupo de la IETF)" <[e-mail]>
Sent: Sunday, March 03, 2002 8:50 AM
Subject: Q: Where should do I put a max mount in a X.509v3 certificate?



IETF-PXIX:

I would like to ask the WG opinion about "the correct" place to indicate
that a certificate should not be used to validate electronic signatures
for
a mount over a determined maximum.

Here we are delegating in de RP the responsibility of validating the
certificate content to see if there is a limit and I have not seen a
good
place to put this information. We need to indicate:
1.- There is a general limit, not for a specific transaction type
2.- The mount of the limit
3.- The type of money in witch the mount is expressed

Is there a standard extension for that?

Thanks,

Opazo, Roberto ([e-mail])
CEO - www.acepta.com
Certification Authority for Chile



Received: by above.proper.com (8.11.6/8.11.3) id g24EPsk20489 for ietf-pkix-bks; Mon, 4 Mar 2002 06:25:54 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g24EPl820478 for <[e-mail]>; Mon, 4 Mar 2002 06:25:48 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 4 Mar 2002 14:25:26 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA29961; Mon, 4 Mar 2002 09:25:32 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g24EPjV07468; Mon, 4 Mar 2002 09:25:45 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <F4N53PT3>; Mon, 4 Mar 2002 09:23:33 -0500
Message-ID: <[e-mail]>
From: "Housley, Russ" <[e-mail]>
To: "'Petra Barzin '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Cc: "'[e-mail] '" <[e-mail]>
Subject: RE: DPD/DPV reqmts: hash of the request 
Date: Mon, 4 Mar 2002 09:25:20 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
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>

In my opinion, the requirement is to bind the respponse back to the request.
Two obvious was to accomplish this binding are to include all of the fields
of the request in the response and to include a hash of the request in the
response.  Since we are working on the requirements doucment, we should
stict to requirements, not mechanisms for implementing the requirements.

Russ


-----Original Message-----
From: Petra Barzin
To: [e-mail]
Cc: [e-mail]
Sent: 3/3/02 3:48 PM
Subject: DPD/DPV reqmts: hash of the request 

Denis, 

I don't see why you differentiate between signed and authenticated 
responses. The same is true for signed responses: either the hash of 
the request or the important elements from the request must be present. 
In order to test the response against what has been requested the client

has to keep his request or at least the hash of his request. 


The advantage of a hash - instead of copying all important elements 
from the request -  is: 
(a) that the response will be smaller and 
(b) adding a new important element to the request doesn't require a 
change of the response. 


- a hash of the request MUST be included in the response.

  This may allow the client to check if his request was maliciously

  modified (if the response is signed) and helps to associate the

  response with his request when using connectionless protocols.



  [Answer 1] The requirements are different whether the requester simply
wants

  an authenticated response or a signed response. For a signed response
the

  inclusion of the important elements from the request is needed, so
that a

  response can be individually tested against what has been requested.
For an

  authenticated response, the hash of the request is sufficient. To
summarize:



  - for signed responses, the important elements from the request

    must be present.



  - for authenticated responses, either the hash of the request or the

    important elements from the request must be present.


- Petra



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g24DQm513986 for ietf-pkix-bks; Mon, 4 Mar 2002 05:26:48 -0800 (PST)
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 g24DQl813981 for <[e-mail]>; Mon, 4 Mar 2002 05:26:47 -0800 (PST)
Received: from tsg1 ([12.81.71.126]) by mtiwmhc21.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020304132642.MOEG28073.mtiwmhc21.worldnet.att.net@tsg1>; Mon, 4 Mar 2002 13:26:42 +0000
Message-ID: <002501c1c380$3910b130$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "todd glassey" <[e-mail]>, "Roberto Opazo Gazmuri" <[e-mail]>
Cc: "LISTS - IETF-PKIX" <[e-mail]>
References: <[e-mail]> <046001c1c2df$2dcd0130$020aff0c@tsg1>
Subject: Re: Where should do I put a max mount in a X.509v3 certificate?
Date: Mon, 4 Mar 2002 05:26:38 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

----- Original Message -----
From: "todd glassey" <[e-mail]>
To: "Roberto Opazo Gazmuri" <[e-mail]>
Cc: "LISTS - IETF-PKIX" <[e-mail]>
Sent: Sunday, March 03, 2002 10:13 AM
Subject: Re: Where should do I put a max mount in a X.509v3 certificate?


>
> Roberto - we went over exactly this thing in the Bar Association's
> Information Security Committee and the place that the liability and
claimant
> requirements are codified is in a set of documents called the Certificate
> Policy Statement (CPS) and Practices Statements (PS). The other side of
> these is the Relying Party Agreement(RPA).  These three documents
> essentially form the

structure (sorry for the typo)

of a contract, which is leveraged between the terms
> listed in them.
>
> The CPS and PS documents state the constraints of the Certificate and how
> the CA operates itself. The RPA is the other half of the picture and
defines
> the relying party's obligations rights, and procedures for collecting
> against the indemnity provided.
>
> The problem is that there is no real method of communicating stated policy
> or negotiating inline. That is to say that without these complex legal,
and
> externally referenced documents the structure of the x.509 certificate
> cannot by itself instantiate any level of liability per se.
>
> I have suggested several times that that PCP (Policy Communications
> Protocol) is a key missing part of any real Machine-operated PKI solution.
> The machines must be given a way of negotiating the specific policies and
> constraints under which they will work and they need to do this together
> with the other CA's so that applications can make inline decisions as to
> what they will and wont trust.
>
> By the way, the assigning of a value to an x509 certificate turns it into
a
> financial token and you would need much more than just this group to
approve
> of that since there are then legal implications attached that are not
> necessarily apparent.
>
> Todd Glassey
>
> ----- Original Message -----
> From: "Roberto Opazo Gazmuri" <[e-mail]>
> To: "PKIX (Grupo de la IETF)" <[e-mail]>
> Sent: Sunday, March 03, 2002 8:50 AM
> Subject: Q: Where should do I put a max mount in a X.509v3 certificate?
>
>
>
> IETF-PXIX:
>
> I would like to ask the WG opinion about "the correct" place to indicate
> that a certificate should not be used to validate electronic signatures
for
> a mount over a determined maximum.
>
> Here we are delegating in de RP the responsibility of validating the
> certificate content to see if there is a limit and I have not seen a good
> place to put this information. We need to indicate:
> 1.- There is a general limit, not for a specific transaction type
> 2.- The mount of the limit
> 3.- The type of money in witch the mount is expressed
>
> Is there a standard extension for that?
>
> Thanks,
>
> Opazo, Roberto ([e-mail])
> CEO - www.acepta.com
> Certification Authority for Chile
>
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g24DOxk13932 for ietf-pkix-bks; Mon, 4 Mar 2002 05:24:59 -0800 (PST)
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 g24DOv813927 for <[e-mail]>; Mon, 4 Mar 2002 05:24:57 -0800 (PST)
Received: from tsg1 ([12.81.71.126]) by mtiwmhc21.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020304132452.MMYA28073.mtiwmhc21.worldnet.att.net@tsg1>; Mon, 4 Mar 2002 13:24:52 +0000
Message-ID: <001a01c1c37f$f7a05f70$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: <[e-mail]>
Cc: "LISTS - IETF-PKIX" <[e-mail]>
References: <[e-mail]> <045901c1c2dd$88adb150$020aff0c@tsg1> <[e-mail]>
Subject: Re: Political Discussion
Date: Mon, 4 Mar 2002 05:24:49 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

So then are you proposing a PKIX etiquette change wherein when the subject
content is going to change on the technical level then the RFC822 subject
should change too.

Just so I am real clear on this  - and  I have to ask - should this same
rule apply to technical changes in a subject thread too or only when the
subject becomes political? Say that someone changes the technical aspects of
a conversation to some other technological discussion  - You see because any
change in any thread can be construed as violating this same edict. So where
do you draw the line?

What I am asking Michael - is how to you would suggest differentiating
particular technical discussions (i.e ones that you are interested in
participating in) from any other.

Todd Glassey
----- Original Message -----
From: "Michael Ströder" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: "LISTS - IETF-PKIX" <[e-mail]>
Sent: Monday, March 04, 2002 2:34 AM
Subject: Re: Political Discussion


>
> todd glassey wrote:
> >
> > As to a filter - that is the issue with EMail - you never know what it
is
> > until you open it.
>
> I disagree. I strongly suggest that people stay on topic if someone
started
> a thread with a certain topic. If the topic changes during discussion the
> subject should be changed. That's the only solution for an efficient
> handling of discussions on mailing lists.
>
> > The problem with a separate political thread address
> > would be that no one would read it if it sat by itself alone.
>
> You're telling us that you want to mix your personal political opinions
into
> other discussion threads just to make us noticing them? With this attitude
> your postings are getting very close to my kill file.
>
> > That is the
> > problem and the joy of the IETF's architecture.
>
> If you want to do politics then be political in the right place. Make the
> IETF or your government/company/whatever aware of what you think the
problem
> is. But do not mess up technical discussions!
>
> Ciao, Michael.
>



Received: by above.proper.com (8.11.6/8.11.3) id g24AYh204509 for ietf-pkix-bks; Mon, 4 Mar 2002 02:34:43 -0800 (PST)
Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g24AYf804504 for <[e-mail]>; Mon, 4 Mar 2002 02:34:41 -0800 (PST)
Received: from fwd04.sul.t-online.de  by mailout06.sul.t-online.com with smtp  id 16hpnc-0005UU-07; Mon, 04 Mar 2002 11:34:32 +0100
Received: from junker.stroeder.com (520010731148-0001@[217.1.21.217]) by fmrl04.sul.t-online.com with esmtp id 16hpna-1j7eG8C; Mon, 4 Mar 2002 11:34:30 +0100
Received: from stroeder.com (junker [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 9B00A157535; Mon,  4 Mar 2002 11:34:24 +0100 (CET)
Message-ID: <[e-mail]>
Date: Mon, 04 Mar 2002 11:34:24 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
Reply-To: [e-mail]
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8+) Gecko/20020228
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: todd glassey <[e-mail]>
Cc: LISTS - IETF-PKIX <[e-mail]>
Subject: Re: Political Discussion
References: <[e-mail]> <045901c1c2dd$88adb150$020aff0c@tsg1>
Content-Type: text/plain; charset=us-ascii; format=flowed
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>

todd glassey wrote:
> 
> As to a filter - that is the issue with EMail - you never know what it is
> until you open it.

I disagree. I strongly suggest that people stay on topic if someone started 
a thread with a certain topic. If the topic changes during discussion the 
subject should be changed. That's the only solution for an efficient 
handling of discussions on mailing lists.

> The problem with a separate political thread address
> would be that no one would read it if it sat by itself alone.

You're telling us that you want to mix your personal political opinions into 
other discussion threads just to make us noticing them? With this attitude 
your postings are getting very close to my kill file.

> That is the
> problem and the joy of the IETF's architecture.

If you want to do politics then be political in the right place. Make the 
IETF or your government/company/whatever aware of what you think the problem 
is. But do not mess up technical discussions!

Ciao, Michael.



Received: by above.proper.com (8.11.6/8.11.3) id g249u5Q00891 for ietf-pkix-bks; Mon, 4 Mar 2002 01:56:05 -0800 (PST)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g249u3800884 for <[e-mail]>; Mon, 4 Mar 2002 01:56:03 -0800 (PST)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g249u2J27594 for <[e-mail]>; Mon, 4 Mar 2002 09:56:02 GMT
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]> for <[e-mail]>; Mon, 4 Mar 2002 09:51:05 +0000
Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id JAA04055; Mon, 4 Mar 2002 09:55:59 GMT
Message-ID: <[e-mail]>
Date: Mon, 04 Mar 2002 09:56:04 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Yee, Peter" <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-acrmf-00.txt
References: <D516C97A440DD31197640008C7EBBE4701B27DCD@EXRSA02>
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>

Peter,

Perfect!

Stephen.

"Yee, Peter" wrote:
> 
> Stephen,
> 
> >What I was thinking was that if you did incorporate that nicely then
> >there'd be no need for LAAP anymore (and since no-one seems to want
> >to produce a new LAAP draft that'd be a happy outcome - if someone
> >does, let me know and I'll send you the source).
> 
> ["that" referring to a mechanism to request an AC be issued under a
> pre-agreed policy].
> 
> I'm adding a new control attribute which allows the requester to specify
> how the requested attribute set may be modified by the AA (or LARA).  One
> option will be that the attributes are to be issued according to policy.
> I'm putting in a policy OID carrier, but if that (optional) OID is not
> present, then I'm specifying that the default procedure is to fallback
> to a pre-agreed policy.  A bit hidden in the overall machinations, but
> I believe that would cover the LAAP-usage case.  Would that suffice for
> your needs?
> 
>                                                         -Peter

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


Received: by above.proper.com (8.11.6/8.11.3) id g244WIu28992 for ietf-pkix-bks; Sun, 3 Mar 2002 20:32:18 -0800 (PST)
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 g244WG828988 for <[e-mail]>; Sun, 3 Mar 2002 20:32:16 -0800 (PST)
Received: from tsg1 ([12.81.89.144]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020304043214.HWVY11747.mtiwmhc23.worldnet.att.net@tsg1>; Mon, 4 Mar 2002 04:32:14 +0000
Message-ID: <004a01c1c335$70d5d730$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Rich Salz" <[e-mail]>
Cc: "Roberto Opazo Gazmuri" <[e-mail]>, "Stephen Kent" <[e-mail]>, "LISTS - IETF-PKIX" <[e-mail]>, "Al Arsenault" <[e-mail]>
References: <[e-mail]> <045901c1c2dd$88adb150$020aff0c@tsg1> <[e-mail]>
Subject: Re: Political Discussion
Date: Sun, 3 Mar 2002 20:31:20 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

No Rich - what they would have seen is that there are approximately 10
people that form the core of the PKIX WG and that there is a tendency to let
that process run status quo. You would also find that the records of this
WG's ability to come to completion on any number of protocols has been
fraught with infighting and other "stumbling blocks".

The concept that it took this WG 5+ years to deal with a time stamping
solution is a testimony to this WG's capabilities and its management in
particular. You as an "elder" of the process also bear some responsibility
for that as well. But predominetently its the WG Chairs.

No Rich, this has been about what PKIX has accomplished, what it is trying
to accomplish and what it should accomplish before shutting down as
completed, and I guess that my take is that PKIX's only reason for existing
is for commercial enablement. End-user authentication is already complete so
there is really no purpose in kicking that dead horse.

Todd
----- Original Message -----
From: "Rich Salz" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: "Roberto Opazo Gazmuri" <[e-mail]>; "Stephen Kent"
<[e-mail]>; "LISTS - IETF-PKIX" <[e-mail]>; "Al Arsenault"
<[e-mail]>
Sent: Sunday, March 03, 2002 6:22 PM
Subject: Re: Political Discussion


> > The problem is Roberto that this management team does not want any
criticism
> > of its actions in any form.
>
> That's not accurate.  Stephen, in particular, has spent quite some time
> explaining how and why you're in the minority opinion.  If anything, an
> honest person would have to see that you're the unwilling one.
>
> /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 g242KCp26284 for ietf-pkix-bks; Sun, 3 Mar 2002 18:20:12 -0800 (PST)
Received: from zolera.com ([63.142.188.177]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g242KA826280 for <[e-mail]>; Sun, 3 Mar 2002 18:20:10 -0800 (PST)
Received: from zolera.com (pool-141-154-57-176.bos.east.verizon.net [141.154.57.176]) by zolera.com (8.11.6/8.11.6) with ESMTP id g242JXK26281; Sun, 3 Mar 2002 21:19:33 -0500
Message-ID: <[e-mail]>
Date: Sun, 03 Mar 2002 21:22:18 -0500
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: todd glassey <[e-mail]>
CC: Roberto Opazo Gazmuri <[e-mail]>, Stephen Kent <[e-mail]>, LISTS - IETF-PKIX <[e-mail]>, Al Arsenault <[e-mail]>
Subject: Re: Political Discussion
References: <[e-mail]> <045901c1c2dd$88adb150$020aff0c@tsg1>
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>

> The problem is Roberto that this management team does not want any criticism
> of its actions in any form.

That's not accurate.  Stephen, in particular, has spent quite some time
explaining how and why you're in the minority opinion.  If anything, an
honest person would have to see that you're the unwilling one.

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


Received: by above.proper.com (8.11.6/8.11.3) id g23NeP920334 for ietf-pkix-bks; Sun, 3 Mar 2002 15:40:25 -0800 (PST)
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 g23NeN820328 for <[e-mail]>; Sun, 3 Mar 2002 15:40:23 -0800 (PST)
Received: from tsg1 ([12.81.89.144]) by mtiwmhc21.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020303234020.YWOJ28073.mtiwmhc21.worldnet.att.net@tsg1>; Sun, 3 Mar 2002 23:40:20 +0000
Message-ID: <001301c1c30c$aae4a6a0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Petra Barzin" <[e-mail]>, <[e-mail]>
Cc: "PKIX" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: Should PDP Be a Separate Specification??
Date: Sun, 3 Mar 2002 15:39:29 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Petra and Yuri -
Its not so much a Policy Definition Protocol, but a negotiation protocol.
What needs to happen is that some specific POLICY MODELS have to be built
(Stephen notice the Upper Case wording for emphasis :-), and these policy
models need a set of real world event types. From there you can actually
create a protocol that can be used to say:

"hey other end - this is what I have and here is how I want to do it. Can
you accommodate this "event type" and if so under what circumstances?" and
the response from the other end is  either a yes or a no and the terms and
conditions that it will accept or proffer.

This type of automated process wherein the application can negotiate and
make acceptance decisions is exactly what is missing from the PKI
infrastructure of PKIX today. That and the data structure standards, i.e.
the TST's and the like.

This is why timestamping and policy control and communication are so
important and obviously tied directly to each other at the use level.

PKIX's problem is clearly that the tools that it is proffering are not meant
to be used when Humans are not present and that is in my mind a clear error.
The whole point of overlaying human trust processes on top of machines is to
allow us to not have to be involved i the middle of the process.


Todd

----- Original Message -----
From: "Petra Barzin" <[e-mail]>
To: <[e-mail]>
Cc: "PKIX" <[e-mail]>
Sent: Sunday, March 03, 2002 12:11 PM
Subject: Re: Should PDP Be a Separate Specification??


>
> Yes, I agree. It should be a separate document!
>
> - Petra
>
> Yuriy Dzambasow schrieb:
>
> > It seems to me that it would be more beneficial to have a separate
> > requirements document for the Policy Definition Protocol (PDP) defined
in
> > the DPD/DPV requirements document, than to integrate into the DPD/DPV
> > document (which also attempts to address DSV policy requirements).  The
> > benefits of having a separate PDP requirements document are:
> >
> > - it focuses solely on policy definition to support protocols such as
> > DPD/DPV/DSV;
> > - the DPD/DPV/DSV specification can simply reference PDP as needed
> > - change control on the specifications are simplified (i.e., PDP changes
> > don't necessarily force changes to DPD/DPV/DSV)
> >
> > I'd like to hear thoughts from others on this.
> >
> > Yuriy
>



Received: by above.proper.com (8.11.6/8.11.3) id g23LxRY15151 for ietf-pkix-bks; Sun, 3 Mar 2002 13:59:27 -0800 (PST)
Received: from gateway.secude.com (linux.secude.com [141.12.207.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g23LxQ815147 for <[e-mail]>; Sun, 3 Mar 2002 13:59:26 -0800 (PST)
Received: from remus.secude.com (remus.intranet.secude.com [192.168.2.2]) by gateway.secude.com (Postfix) with ESMTP id D8CCC5274; Sun,  3 Mar 2002 22:59:23 +0100 (CET)
Received: from secude.com (obelix.intranet.secude.com [192.168.1.3]) by remus.secude.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FFR01150; Sun, 3 Mar 2002 22:59:23 +0100
Message-ID: <[e-mail]>
Date: Sun, 03 Mar 2002 23:01:49 +0100
From: Petra Barzin <[e-mail]>
X-Mailer: Mozilla 4.73 [de]C-CCK-MCD DT  (Win95; U)
X-Accept-Language: de
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
Subject: DPD/DPV reqmts: obtain the definition of validation policies
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>

Denis,

I would propose the following:

- add one more sentence to section 6:

The protocol SHALL allow clients to obtain the identifier and
definition of a specific, the default or all of the policies supported
by the server by using another additional request/response pair.

- and add another section after the PDP requirements:

Policy Retrieval Protocol (PRP) requirements
In order to archive the validation result of a certificate, it MAY be
necessary to combine it with the used validation policy. In some
cases the client MAY want to get an overview of all validation
policies supported by the server. Both reasons result in the following
requirements for the Policy Retrieval Protocol :
* return a specific validation policy definition
* return the default validation policy definition incl. its identifier
* return all validation policy definitions incl. their identifiers
* return max. number of validation policy definitions incl. their identifiers
* return max. number of validation policy identifiers

The last two requirements are especially usefull for thin clients with
small display facilities

- Petra

> - add another request/response pair to obtain the definition of a
> specific, the default or all validation policies defined on the server.
> So far only the references of a validation policies can be returned.
> But it might be necessary to retrieve the definition of a validation policy,
> too (e.g. for archiving).
>
> [Answer 4] You did not say where you wanted this addition. The server may
> support validation policies that have been locally set up, so there may not
> be a formal definition that matches the policy. So at least for these one,
> this will be impossible. I would like the current request/response pair to
> be usable,
> without the need to support the request/response pair allowing a remote
> definition of the policy. So I would keep the section 6 unchanged.
>
> However, supporting this as part of section 7 - PDP (Policy Definition
> Protocol) can certainly be considered.



Received: by above.proper.com (8.11.6/8.11.3) id g23LCPf13872 for ietf-pkix-bks; Sun, 3 Mar 2002 13:12:25 -0800 (PST)
Received: from gateway.secude.com (linux.secude.com [141.12.207.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g23LCO813868 for <[e-mail]>; Sun, 3 Mar 2002 13:12:24 -0800 (PST)
Received: from remus.secude.com (remus.intranet.secude.com [192.168.2.2]) by gateway.secude.com (Postfix) with ESMTP id DEBB45275; Sun,  3 Mar 2002 22:12:21 +0100 (CET)
Received: from secude.com (obelix.intranet.secude.com [192.168.1.3]) by remus.secude.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FFR0115J; Sun, 3 Mar 2002 22:12:21 +0100
Message-ID: <[e-mail]>
Date: Sun, 03 Mar 2002 22:14:46 +0100
From: Petra Barzin <[e-mail]>
X-Mailer: Mozilla 4.73 [de]C-CCK-MCD DT  (Win95; U)
X-Accept-Language: de
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
Subject: Re: "Potentially valid" response state in DPV/DPD rqmts I-D
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>

Denis,

I've been thinking of signature validation when I required the algorithm
component of a validation policy. But this is the requirement document
of DPV/DPD. So please ignore it for this document but consider it for
the DSV requirements!

- Petra

the algorithm requirements are not restricted to the public key contained
in the end-entity certificate

> - add one more component to a validation policy: algorithm requirements
> They identify the minimum key length of the signature key or
> untrusted hash- and signature algorithms.
>
> [Answer 3] I guess that you mean requirements only for the public key
> contained in the end-entity certificate to be validated. I am not sure that
> this is relevant. If you trust the certificate policy under which the
> end-entity certificate has been issued, then you trust the CA to certify
> public keys that have the right algorithm and key length. So I believe that
> your concern is already solved by specifying certificate policies.
>



Received: by above.proper.com (8.11.6/8.11.3) id g23L4bV13780 for ietf-pkix-bks; Sun, 3 Mar 2002 13:04:37 -0800 (PST)
Received: from gateway.secude.com (linux.secude.com [141.12.207.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g23L4a813776 for <[e-mail]>; Sun, 3 Mar 2002 13:04:36 -0800 (PST)
Received: from remus.secude.com (remus.intranet.secude.com [192.168.2.2]) by gateway.secude.com (Postfix) with ESMTP id BC0495275; Sun,  3 Mar 2002 22:04:33 +0100 (CET)
Received: from secude.com (obelix.intranet.secude.com [192.168.1.3]) by remus.secude.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FFR0115G; Sun, 3 Mar 2002 22:04:33 +0100
Message-ID: <[e-mail]>
Date: Sun, 03 Mar 2002 22:06:58 +0100
From: Petra Barzin <[e-mail]>
X-Mailer: Mozilla 4.73 [de]C-CCK-MCD DT  (Win95; U)
X-Accept-Language: de
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
Subject: DPD/DPV reqmts: random number
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>

Denis,

yes, indeed. There is a contradiction. My last sentence should be:
The random number doesn't have to be repeated in the response
*because* the response contains a hash of the request.

I don't understand your last comment. The client does not compute
the hash over all the fields from the response but from his request!

- Petra

> - a random number MAY be included in the request.
> This allows replay protection when the client has no clock.
> The random number doesn't have to be repeated in the response
> if the response contains a hash of the request.
>
> [Answer 2] Replay protection is so obvious that it has been omitted. We
> could certainly add some text. The nonce cryptographically binds a request
> and a response to prevent replay attacks. However when you say: "The random
> number doesn't have to be repeated in the response *if* the response
> contains a hash of the request". This sentence is in contradiction with your
> first comment where you say: "a hash of the request MUST be included in the
> response". A choice needs to me made.  :-)
>
> I believe that the nonce should be in the response as well, just because it
> is easier for the client to compute the hash over all the fields from the
> response instead of saying: "after the item X, I need to copy the nonce from
> the request".
>



Received: by above.proper.com (8.11.6/8.11.3) id g23Kk9L13302 for ietf-pkix-bks; Sun, 3 Mar 2002 12:46:09 -0800 (PST)
Received: from gateway.secude.com (linux.secude.com [141.12.207.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g23Kk8813298 for <[e-mail]>; Sun, 3 Mar 2002 12:46:08 -0800 (PST)
Received: from remus.secude.com (remus.intranet.secude.com [192.168.2.2]) by gateway.secude.com (Postfix) with ESMTP id F3A519899; Sun,  3 Mar 2002 21:46:05 +0100 (CET)
Received: from secude.com (obelix.intranet.secude.com [192.168.1.3]) by remus.secude.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FFR011Z5; Sun, 3 Mar 2002 21:46:05 +0100
Message-ID: <[e-mail]>
Date: Sun, 03 Mar 2002 21:48:31 +0100
From: Petra Barzin <[e-mail]>
X-Mailer: Mozilla 4.73 [de]C-CCK-MCD DT  (Win95; U)
X-Accept-Language: de
MIME-Version: 1.0
To: [e-mail]
Cc: [e-mail]
Subject: DPD/DPV reqmts: hash of the request 
Content-Type: text/html; 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>

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Denis,
<p>I don't see why you differentiate between signed and authenticated
<br>responses. The same is true for signed responses: either the hash of
<br>the request or the important elements from the request must be present.
<br>In order to test the response against what has been requested the client
<br>has to keep his request or at least the hash of his request.
<p>The advantage of a hash - instead of copying all important elements
<br>from the request -&nbsp; is:
<br>(a) that the response will be smaller and
<br>(b) adding a new important element to the request doesn't require a
<br>change of the response.
<blockquote TYPE=CITE>
<pre>- a hash of the request MUST be included in the response.
&nbsp; This may allow the client to check if his request was maliciously
&nbsp; modified (if the response is signed) and helps to associate the
&nbsp; response with his request when using connectionless protocols.

&nbsp; [Answer 1] The requirements are different whether the requester simply wants
&nbsp; an authenticated response or a signed response. For a signed response the
&nbsp; inclusion of the important elements from the request is needed, so that a
&nbsp; response can be individually tested against what has been requested. For an
&nbsp; authenticated response, the hash of the request is sufficient. To summarize:

&nbsp; - for signed responses, the important elements from the request
&nbsp;&nbsp;&nbsp; must be present.

&nbsp; - for authenticated responses, either the hash of the request or the
&nbsp;&nbsp;&nbsp; important elements from the request must be present.</pre>
</blockquote>

<p><br>- Petra</html>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g23Kjgt13291 for ietf-pkix-bks; Sun, 3 Mar 2002 12:45:42 -0800 (PST)
Received: from gateway.secude.com (linux.secude.com [141.12.207.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g23Kjf813287 for <[e-mail]>; Sun, 3 Mar 2002 12:45:41 -0800 (PST)
Received: from remus.secude.com (remus.intranet.secude.com [192.168.2.2]) by gateway.secude.com (Postfix) with ESMTP id 846A05275; Sun,  3 Mar 2002 21:45:38 +0100 (CET)
Received: from secude.com (obelix.intranet.secude.com [192.168.1.3]) by remus.secude.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FFR011ZY; Sun, 3 Mar 2002 21:45:37 +0100
Message-ID: <[e-mail]>
Date: Sun, 03 Mar 2002 21:48:03 +0100
From: Petra Barzin <[e-mail]>
X-Mailer: Mozilla 4.73 [de]C-CCK-MCD DT  (Win95; U)
X-Accept-Language: de
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
Subject: Re: "Potentially valid" response state in DPV/DPD rqmts I-D
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>

Denis,

I will discuss the different issues in separate mails and change the
subject of the mails accordingly.

- Petra

Denis Pinkas schrieb:

> Petra and Peter,
>
> Please find below responses to your comments.
>
> COMMENTS FROM PETRA BARZIN
>
> I would like to propose some more requirements to be included
> in the DPV/DPD requirements draft:
>
> [COMMENT 1]
>
> - a hash of the request MUST be included in the response.
> This may allow the client to check if his request was maliciously
> modified (if the response is signed) and helps to associate the
> response with his request when using connectionless protocols.
>
> [Answer 1] The requirements are different whether the requester simply wants
> an authenticated response or a signed response. For a signed response the
> inclusion of the important elements from the request is needed, so that a
> response can be individually tested against what has been requested. For an
> authenticated response, the hash of the request is sufficient. To summarize:
>
> - for signed responses, the important elements from the request
>   must be present.
>
> - for authenticated responses, either the hash of the request or the
>   important elements from the request must be present.
>
> [COMMENT 2]
>
> - a random number MAY be included in the request.
> This allows replay protection when the client has no clock.
> The random number doesn't have to be repeated in the response
> if the response contains a hash of the request.
>
> [Answer 2] Replay protection is so obvious that it has been omitted. We
> could certainly add some text. The nonce cryptographically binds a request
> and a response to prevent replay attacks. However when you say: "The random
> number doesn't have to be repeated in the response *if* the response
> contains a hash of the request". This sentence is in contradiction with your
> first comment where you say: "a hash of the request MUST be included in the
> response". A choice needs to me made.  :-)
>
> I believe that the nonce should be in the response as well, just because it
> is easier for the client to compute the hash over all the fields from the
> response instead of saying: "after the item X, I need to copy the nonce from
> the request".
>
> [COMMENT 3]
>
> - add one more component to a validation policy: algorithm requirements
> They identify the minimum key length of the signature key or
> untrusted hash- and signature algorithms.
>
> [Answer 3] I guess that you mean requirements only for the public key
> contained in the end-entity certificate to be validated. I am not sure that
> this is relevant. If you trust the certificate policy under which the
> end-entity certificate has been issued, then you trust the CA to certify
> public keys that have the right algorithm and key length. So I believe that
> your concern is already solved by specifying certificate policies.
>
> [COMMENT 4]
>
> - add another request/response pair to obtain the definition of a
> specific, the default or all validation policies defined on the server.
> So far only the references of a validation policies can be returned.
> But it might be necessary to retrieve the definition of a validation policy,
> too (e.g. for archiving).
>
> [Answer 4] You did not say where you wanted this addition. The server may
> support validation policies that have been locally set up, so there may not
> be a formal definition that matches the policy. So at least for these one,
> this will be impossible. I would like the current request/response pair to
> be usable,
> without the need to support the request/response pair allowing a remote
> definition of the policy. So I would keep the section 6 unchanged.
>
> However, supporting this as part of section 7 - PDP (Policy Definition
> Protocol) can certainly be considered.
>
> COMMENTS FROM PETER SYLVESTER
>
> There are some comments for DPV that have been ignored.
>
> The last three blocks in chapter 4 talk about security
> requirements, but the following two are not mentioned
> (unless I miss something).
>
> - Security requirements
>
> [COMMENT 5]
>
> - a method to authenticate a server before sending any request
>    (for example this can be achieved by SSL).
>    (Another example would be using encryption.)
>
> [Answer 5]. This is covered under the following wording: "In order to be
> able to be confident that the validation of the certificate has correctly
> been done, the client only requires an authenticated response". No change is
> necessary.
>
> [COMMENT 6]
>
> - a method to ensure confidentiality of the transport.
>
> [Answer 6] There is nothing here in that protocol that mandates
> confidentiality like protecting the value of a private key or a secret key.
> The transport can provide confidentiality in support of environments that do
> not wish to reveal requests or responses contents, e.g. using TLS or S/MIME.
> No change is necessary.
>
> [COMMENT 7]
>
> - a method that client and server provide their identity
>    in the requests and responses: 'You, the client X, has
>    asked me, the server Y, the following question, and
>    I, the server Y, with the help of server Z respond.'
>
> This allows to be able to determine the participating entities
> without having access to whatever particular authentication
> method information.
>
> [Answer 7] Actually, we already include the identity of the server in the
> response. The request could also be optionally signed. This allows
> the server to authenticate the client, and this authentication allows the
> server to only support a selective community if desired. An option to be
> able to sign the request may be added.
>
> The following requirements may be used for example in case of
> validation of an encryption certificate before usage.
>
> [COMMENT 8]
>
> One may resume the relaying requirements into one:
>
> - The protocol MUST provide a means to allow (visible) relaying
>    of requests and responses.
>
> - Relaying requirements:
>
> - depending on policy, a server may just impersonate another
>    server, i.e., take the responses of another server, and create
>    its own response out of them.
>
> - a server should be able to include the response of a relayed
>    server into his response.
>
> - a server should be able to simple add another authentication
>    scheme to a response from another server (for example by
>    using a second signature or a counter signature.)
>
> - a server that acts as a relay should be able to tell to the
>    next server that it is acting on behalf of a end user, and
>    the final server should be able to note this in the response.
>
> - For relaying, the protocol MUST provide an efficient means
>    to detect loops.
>
> [Answer 8] Clients trust some dedicated servers. They don't care how the
> information that is provided has been established: there is a single server
> that is responsible: the one which provides the answer. If the response is
> signed by the expected private key, then it is acceptable, otherwise it is
> not. There are not requirements for chaining or referral services. Relaying
> between
> servers is not the topic of this document. No change is necessary.
>
> [COMMENT 9]
>
> - Requirements for incomplete answers:
>
> - a server may indicate an incomplete response,
>    and provide a method to update the response later.
>
> [Answer 9] This would create the maintenance of state information which
> should be avoided. There has been plenty of discussion on the list regarding
> the number of states.  People clearly want the fewest possible number. The
> client may query again later on. No change is necessary.
>
> Regards,
>
> Denis



Received: by above.proper.com (8.11.6/8.11.3) id g23K9AB12639 for ietf-pkix-bks; Sun, 3 Mar 2002 12:09:10 -0800 (PST)
Received: from gateway.secude.com (linux.secude.com [141.12.207.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g23K99812635 for <[e-mail]>; Sun, 3 Mar 2002 12:09:09 -0800 (PST)
Received: from remus.secude.com (remus.intranet.secude.com [192.168.2.2]) by gateway.secude.com (Postfix) with ESMTP id 9A32A8E69; Sun,  3 Mar 2002 21:09:05 +0100 (CET)
Received: from secude.com (obelix.intranet.secude.com [192.168.1.3]) by remus.secude.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FFR011ZK; Sun, 3 Mar 2002 21:09:04 +0100
Message-ID: <[e-mail]>
Date: Sun, 03 Mar 2002 21:11:30 +0100
From: Petra Barzin <[e-mail]>
X-Mailer: Mozilla 4.73 [de]C-CCK-MCD DT  (Win95; U)
X-Accept-Language: de
MIME-Version: 1.0
To: [e-mail]
Cc: PKIX <[e-mail]>
Subject: Re: Should PDP Be a Separate Specification??
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>

Yes, I agree. It should be a separate document!

- Petra

Yuriy Dzambasow schrieb:

> It seems to me that it would be more beneficial to have a separate
> requirements document for the Policy Definition Protocol (PDP) defined in
> the DPD/DPV requirements document, than to integrate into the DPD/DPV
> document (which also attempts to address DSV policy requirements).  The
> benefits of having a separate PDP requirements document are:
>
> - it focuses solely on policy definition to support protocols such as
> DPD/DPV/DSV;
> - the DPD/DPV/DSV specification can simply reference PDP as needed
> - change control on the specifications are simplified (i.e., PDP changes
> don't necessarily force changes to DPD/DPV/DSV)
>
> I'd like to hear thoughts from others on this.
>
> Yuriy



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g23JVU412138 for ietf-pkix-bks; Sun, 3 Mar 2002 11:31:30 -0800 (PST)
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g23JVS812134 for <[e-mail]>; Sun, 3 Mar 2002 11:31:29 -0800 (PST)
Received: from arport (t2o69p73.telia.com [62.20.144.193]) by mailb.telia.com (8.11.6/8.11.6) with SMTP id g23JV0E24006; Sun, 3 Mar 2002 20:31:00 +0100 (CET)
Message-ID: <000f01c1c2e9$bf944ba0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Roberto Opazo Gazmuri" <[e-mail]>, "PKIX \(Grupo de la IETF\)" <[e-mail]>
References: <[e-mail]>
Subject: Re: Where should do I put a max mount in a X.509v3 certificate?
Date: Sun, 3 Mar 2002 20:29:32 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Roberto,

The "WG" has probably not a unified view of this issue so may I just add my
personal view on this.  Technically there are such policy OIDs although I don't
know where you can get this information.  Now I would like to take the
opportunity to (in a rather "orthogonal" way), say what I think of this idea
in general.

I think that the whole liability issue has infected PKI to an extent that is
unreasonable.  What does a money-limit indicate?  That if a CA has
certified the wrong person, the CA is liable for the entire transaction?

There are many problems with this

-  The biggest risk is actually that the certificate and key was stolen
from the proper owner, and are CAs really prepared to be liable for that?

-  A certificate used for *authentication* may be use to protect things
that does not easily measure in monetary terms.  It could be state-secrets,
your company's latest product-to-be, your latest HIV-test, or it could be used
to open a door to vault filled with gold!    As authentication in spite
of all talk of digital signatures is the PKI "killer application", I think that
these monetary limits are without much *real* value.  Particularly as
account-to-account transactions (in contrast to revealed state-secrets, and
HIV-tests), usually can be undone.

- It is BTW rather dangerous to fake an identity to get a certificate
as your traces are easy to follow compared to physical IDs.

I think that commercial CAs should put a *maximum* liability figure
in the range of $10 000 to $100 000 regardless what the certificate is
used for.  And it should only be valid for certifying incorrect entities.

It is like a lock.  It often is manufactured according to some industry norm,
but that does not guarantee that it protects $1M from a clever thief.  But
it is still worth the $500 if there are no better alternatives around!

If we are talking about CA key compromise, we are probably dealing
with processes like a drug manufacturer killing its clients.

cheers,
Anders


----- Original Message ----- 
From: "Roberto Opazo Gazmuri" <[e-mail]>
To: "PKIX (Grupo de la IETF)" <[e-mail]>
Sent: Sunday, March 03, 2002 17:50
Subject: Q: Where should do I put a max mount in a X.509v3 certificate?



IETF-PXIX:

I would like to ask the WG opinion about "the correct" place to indicate
that a certificate should not be used to validate electronic signatures for
a mount over a determined maximum.

Here we are delegating in de RP the responsibility of validating the
certificate content to see if there is a limit and I have not seen a good
place to put this information. We need to indicate:
1.- There is a general limit, not for a specific transaction type
2.- The mount of the limit
3.- The type of money in witch the mount is expressed

Is there a standard extension for that?

Thanks,

Opazo, Roberto ([e-mail])
CEO - www.acepta.com
Certification Authority for Chile




Received: by above.proper.com (8.11.6/8.11.3) id g23IEmA10038 for ietf-pkix-bks; Sun, 3 Mar 2002 10:14:48 -0800 (PST)
Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g23IEk810030 for <[e-mail]>; Sun, 3 Mar 2002 10:14:46 -0800 (PST)
Received: from tsg1 ([12.81.65.70]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020303181441.UMTC13933.mtiwmhc22.worldnet.att.net@tsg1>; Sun, 3 Mar 2002 18:14:41 +0000
Message-ID: <046001c1c2df$2dcd0130$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Roberto Opazo Gazmuri" <[e-mail]>
Cc: "LISTS - IETF-PKIX" <[e-mail]>
References: <[e-mail]>
Subject: Re: Where should do I put a max mount in a X.509v3 certificate?
Date: Sun, 3 Mar 2002 10:13:52 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Roberto - we went over exactly this thing in the Bar Association's
Information Security Committee and the place that the liability and claimant
requirements are codified is in a set of documents called the Certificate
Policy Statement (CPS) and Practices Statements (PS). The other side of
these is the Relying Party Agreement(RPA).  These three documents
essentially form the of a contract, which is leveraged between the terms
listed in them.structure

The CPS and PS documents state the constraints of the Certificate and how
the CA operates itself. The RPA is the other half of the picture and defines
the relying party's obligations rights, and procedures for collecting
against the indemnity provided.

The problem is that there is no real method of communicating stated policy
or negotiating inline. That is to say that without these complex legal, and
externally referenced documents the structure of the x.509 certificate
cannot by itself instantiate any level of liability per se.

I have suggested several times that that PCP (Policy Communications
Protocol) is a key missing part of any real Machine-operated PKI solution.
The machines must be given a way of negotiating the specific policies and
constraints under which they will work and they need to do this together
with the other CA's so that applications can make inline decisions as to
what they will and wont trust.

By the way, the assigning of a value to an x509 certificate turns it into a
financial token and you would need much more than just this group to approve
of that since there are then legal implications attached that are not
necessarily apparent.

Todd Glassey

----- Original Message -----
From: "Roberto Opazo Gazmuri" <[e-mail]>
To: "PKIX (Grupo de la IETF)" <[e-mail]>
Sent: Sunday, March 03, 2002 8:50 AM
Subject: Q: Where should do I put a max mount in a X.509v3 certificate?



IETF-PXIX:

I would like to ask the WG opinion about "the correct" place to indicate
that a certificate should not be used to validate electronic signatures for
a mount over a determined maximum.

Here we are delegating in de RP the responsibility of validating the
certificate content to see if there is a limit and I have not seen a good
place to put this information. We need to indicate:
1.- There is a general limit, not for a specific transaction type
2.- The mount of the limit
3.- The type of money in witch the mount is expressed

Is there a standard extension for that?

Thanks,

Opazo, Roberto ([e-mail])
CEO - www.acepta.com
Certification Authority for Chile




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g23I32Q09151 for ietf-pkix-bks; Sun, 3 Mar 2002 10:03:02 -0800 (PST)
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 g23I30809147 for <[e-mail]>; Sun, 3 Mar 2002 10:03:00 -0800 (PST)
Received: from tsg1 ([12.81.65.70]) by mtiwmhc21.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020303180255.RLFG28073.mtiwmhc21.worldnet.att.net@tsg1>; Sun, 3 Mar 2002 18:02:55 +0000
Message-ID: <045901c1c2dd$88adb150$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Roberto Opazo Gazmuri" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: "LISTS - IETF-PKIX" <[e-mail]>, "Al Arsenault" <[e-mail]>
References: <[e-mail]>
Subject: Re: Political Discussion
Date: Sun, 3 Mar 2002 10:02:05 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The problem is Roberto that this management team does not want any criticism
of its actions in any form. The bottom line is that they have screwed up by
refusing to pay attention  to how this technology is to be specifically
used, i.e. what it does and doesn't do, and without this element brought
into the mix - all you get is political arguments like the one that you have
asked not to be a part of.

As to a filter - that is the issue with EMail - you never know what it is
until you open it. The problem with a separate political thread address
would be that no one would read it if it sat by itself alone. That is the
problem and the joy of the IETF's architecture.

Todd

----- Original Message -----
From: "Roberto Opazo Gazmuri" <[e-mail]>
To: "todd glassey" <[e-mail]>; "Stephen Kent"
<[e-mail]>
Cc: "LISTS - IETF-PKIX" <[e-mail]>
Sent: Sunday, March 03, 2002 8:19 AM
Subject: Political Discussion


> What is the relation of these comments with DPV/DPD?
>
> I would like to have a chance of a quick filter any time I receive a mail.
> That is the idea of having a list and a thread.
>
> If there is no list for political discussion, I ask you at least to use a
> different tread. Other way you are degrading the level of this discussion.
>
> Political discussion is valid and may be necessary, but I believe "Re:
> Validation policy in DPV/DPD" is not the place for that.
>
> Thanks,
>
> Roberto
>
> > -----Mensaje original-----
> > De: [e-mail] [mailto:[e-mail]]En
> > nombre de todd glassey
> > Enviado el: viernes, 01 de marzo de 2002 17:30
> > Para: Stephen Kent
> > CC: LISTS - IETF-PKIX
> > Asunto: Re: Validation policy in DPV/DPD rqmts
> >
> >
> >
> > Steve this is pointless to argue on this list about. I disagree with
what
> > you are doing and believe that your impressive resume is being wasted in
> > your current role.
> >
> > > I do lots of things, in addition to standards work, but I view
> > > standards activities as important and a worthy use of my time.
> >
> > I would agree.
> >
> > > Also,
> > > I have clients who agree and are willing to pay for me to spend the
> > > time on these activities.
> >
> > Which makes you an obvious resource for an organization like the
> > IETF - its
> > just that you have sat for 7 years here in PKIX and we need some fresh
> > blood.
> >
> > I suggest - and this is not a joke- that we petition the IESG and IAB to
> > make you the "Chief Scientist of the Internet" and create a specific and
> > permanent role for you there. This is not a joke - really it isn't. I
see
> > this as one of the potentially most important roles in the IESG and
IETF.
> > And for you to follow in Vint cerf's or John Postels shoes would
> > be cool to
> > I think...
> >
> > Steve this is not a slam on you personally - of that you are brilliant,
> > there is no doubt, but enough is enough. You nurtured (or kicked and
> > dragged) PKIX from its inception to where it is now, and it needs some
new
> > blood to get it to the next level.
> >
> > > Within BBN I've provided technical
> > > leadership in developing several generations of network security
> > > devices, plus secure e-mail systems, high assurance crypto modules,
> > > CA technology, etc. I also am known as one of the senior Internet
> > > wine experts and engage in serious nature photography, in my spare
> > > time ...
> > >
> >
> > See what I mean.
> >
> > >
> > > These other standards bodies have formal membership requirements and
> > > thus have a basis for voting.  the IETF does not, by its own choice,
> > > vote on these matters.  if you are unhappy with this arrangement,
> > > perhaps you should consider directing your energies to other
> > > standards bodies.
> >
> > No Steve, Sooner or later you will have to admit that this is not 1974
and
> > that what the IETF was founded on was a need to get as many protocols
out
> > there as possible as fast as possible to enable the development of the
> > Internet. The the Internet is a long way from where it was in 1974... no
> > more Honeywell IMPS. This is a key issue now that the internet
> > extends into
> > Millions of homes and virtually every major or even small business in
the
> > mechanized world... (OK so its not all of them yet, but its too
> > many to just
> > ignore).
> >
> > Now the IETF's focus needs to shift to not just producing protocols but
to
> > producing the right ones.  And that's going to take partnering with
other
> > standards orgs formally and getting their input when we design core
> > functionality into the work we do. Its also going to mean getting
> > many more
> > fledging protocols into the shoot, and that is what the current process
> > stifles and that a better disclosure mechanism is needed too. You know
USE
> > MODELS (note that I spelled it in caps just for you, too!).
> >
> > >
> > > >  > If you want to suggest term
> > > >>  limits, bring the topic up on POISED, where the topic is
> > within scope.
> > > >>
> > > >
> > > >I have done exactly that - but POISED has been shut down so I have no
> > choice
> > > >but to bring my petitions for reform of the IETF (and thus
> > this WG) back
> > > >inside this WG...  see the
> > http://www.ietf.org/html.charters/OLD/index.html
> > > >link for evidence of this.
> > > >
> > >
> > > See Paul's message.
> >
> > I have and according the the IETF's website Paul's wrong, the WG is
listed
> > as "completed"
> >
> > Err unless of course its a typo.
> >
> > >
> > > Steve
>
>



Received: by above.proper.com (8.11.6/8.11.3) id g23Gu1n06961 for ietf-pkix-bks; Sun, 3 Mar 2002 08:56:01 -0800 (PST)
Received: from marte.ifxnw.cl (marte.ifxnw.cl [216.241.0.152]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g23Gtw806954 for <[e-mail]>; Sun, 3 Mar 2002 08:55:59 -0800 (PST)
Received: from ropazo (unverified [216.241.20.226]) by marte.ifxnw.cl (Rockliffe SMTPRA 3.4.7) with SMTP id <[e-mail]> for <[e-mail]>; Sun, 3 Mar 2002 13:56:52 -0400
From: "Roberto Opazo Gazmuri" <[e-mail]>
To: "PKIX \(Grupo de la IETF\)" <[e-mail]>
Subject: Q: Where should do I put a max mount in a X.509v3 certificate?
Date: Sun, 3 Mar 2002 13:50:51 -0300
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 1 (Highest)
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: High
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

IETF-PXIX:

I would like to ask the WG opinion about “the correct” place to indicate
that a certificate should not be used to validate electronic signatures for
a mount over a determined maximum.

Here we are delegating in de RP the responsibility of validating the
certificate content to see if there is a limit and I have not seen a good
place to put this information. We need to indicate:
1.- There is a general limit, not for a specific transaction type
2.- The mount of the limit
3.- The type of money in witch the mount is expressed

Is there a standard extension for that?

Thanks,

Opazo, Roberto ([e-mail])
CEO - www.acepta.com
Certification Authority for Chile



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g23GOmN05720 for ietf-pkix-bks; Sun, 3 Mar 2002 08:24:48 -0800 (PST)
Received: from marte.ifxnw.cl (marte.ifxnw.cl [216.241.0.152]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g23GOj805716 for <[e-mail]>; Sun, 3 Mar 2002 08:24:46 -0800 (PST)
Received: from ropazo (unverified [216.241.20.226]) by marte.ifxnw.cl (Rockliffe SMTPRA 3.4.7) with SMTP id <[e-mail]>; Sun, 3 Mar 2002 13:25:27 -0400
From: "Roberto Opazo Gazmuri" <[e-mail]>
To: "todd glassey" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: "LISTS - IETF-PKIX" <[e-mail]>
Subject: Political Discussion
Date: Sun, 3 Mar 2002 13:19:27 -0300
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 1 (Highest)
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <012401c1c15f$ffa74250$020aff0c@tsg1>
Importance: High
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

What is the relation of these comments with DPV/DPD?

I would like to have a chance of a quick filter any time I receive a mail.
That is the idea of having a list and a thread.

If there is no list for political discussion, I ask you at least to use a
different tread. Other way you are degrading the level of this discussion.

Political discussion is valid and may be necessary, but I believe "Re:
Validation policy in DPV/DPD" is not the place for that.

Thanks,

Roberto

> -----Mensaje original-----
> De: [e-mail] [mailto:[e-mail]]En
> nombre de todd glassey
> Enviado el: viernes, 01 de marzo de 2002 17:30
> Para: Stephen Kent
> CC: LISTS - IETF-PKIX
> Asunto: Re: Validation policy in DPV/DPD rqmts
>
>
>
> Steve this is pointless to argue on this list about. I disagree with what
> you are doing and believe that your impressive resume is being wasted in
> your current role.
>
> > I do lots of things, in addition to standards work, but I view
> > standards activities as important and a worthy use of my time.
>
> I would agree.
>
> > Also,
> > I have clients who agree and are willing to pay for me to spend the
> > time on these activities.
>
> Which makes you an obvious resource for an organization like the
> IETF - its
> just that you have sat for 7 years here in PKIX and we need some fresh
> blood.
>
> I suggest - and this is not a joke- that we petition the IESG and IAB to
> make you the "Chief Scientist of the Internet" and create a specific and
> permanent role for you there. This is not a joke - really it isn't. I see
> this as one of the potentially most important roles in the IESG and IETF.
> And for you to follow in Vint cerf's or John Postels shoes would
> be cool to
> I think...
>
> Steve this is not a slam on you personally - of that you are brilliant,
> there is no doubt, but enough is enough. You nurtured (or kicked and
> dragged) PKIX from its inception to where it is now, and it needs some new
> blood to get it to the next level.
>
> > Within BBN I've provided technical
> > leadership in developing several generations of network security
> > devices, plus secure e-mail systems, high assurance crypto modules,
> > CA technology, etc. I also am known as one of the senior Internet
> > wine experts and engage in serious nature photography, in my spare
> > time ...
> >
>
> See what I mean.
>
> >
> > These other standards bodies have formal membership requirements and
> > thus have a basis for voting.  the IETF does not, by its own choice,
> > vote on these matters.  if you are unhappy with this arrangement,
> > perhaps you should consider directing your energies to other
> > standards bodies.
>
> No Steve, Sooner or later you will have to admit that this is not 1974 and
> that what the IETF was founded on was a need to get as many protocols out
> there as possible as fast as possible to enable the development of the
> Internet. The the Internet is a long way from where it was in 1974... no
> more Honeywell IMPS. This is a key issue now that the internet
> extends into
> Millions of homes and virtually every major or even small business in  the
> mechanized world... (OK so its not all of them yet, but its too
> many to just
> ignore).
>
> Now the IETF's focus needs to shift to not just producing protocols but to
> producing the right ones.  And that's going to take partnering with other
> standards orgs formally and getting their input when we design core
> functionality into the work we do. Its also going to mean getting
> many more
> fledging protocols into the shoot, and that is what the current process
> stifles and that a better disclosure mechanism is needed too. You know USE
> MODELS (note that I spelled it in caps just for you, too!).
>
> >
> > >  > If you want to suggest term
> > >>  limits, bring the topic up on POISED, where the topic is
> within scope.
> > >>
> > >
> > >I have done exactly that - but POISED has been shut down so I have no
> choice
> > >but to bring my petitions for reform of the IETF (and thus
> this WG) back
> > >inside this WG...  see the
> http://www.ietf.org/html.charters/OLD/index.html
> > >link for evidence of this.
> > >
> >
> > See Paul's message.
>
> I have and according the the IETF's website Paul's wrong, the WG is listed
> as "completed"
>
> Err unless of course its a typo.
>
> >
> > Steve



Received: by above.proper.com (8.11.6/8.11.3) id g22EEDm10733 for ietf-pkix-bks; Sat, 2 Mar 2002 06:14:13 -0800 (PST)
Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g22EEBG10729 for <[e-mail]>; Sat, 2 Mar 2002 06:14:11 -0800 (PST)
Received: from arport (t4o69p69.telia.com [62.20.145.189]) by mailg.telia.com (8.11.6/8.11.6) with SMTP id g22EE6N22362; Sat, 2 Mar 2002 15:14:06 +0100 (CET)
Message-ID: <006a01c1c1f4$50ce4180$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "todd glassey" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: "LISTS - IETF-PKIX" <[e-mail]>
References: <20020228012927.CFKS2951.rwcrmhc53.attbi.com@rwcrwbc57> <04ae01c1c061$5f401340$020aff0c@tsg1> <p05100301b8a3f455959c@[128.89.88.34]> <050101c1c074$e8b722e0$020aff0c@tsg1> <p05100305b8a4171bc0f9@[128.89.88.34]> <054b01c1c09e$646263e0$020aff0c@tsg1> <p05100315b8a4527cb463@[128.89.88.34]> <058c01c1c0ab$2c86d8e0$020aff0c@tsg1> <p05100300b8a467b2b048@[128.89.88.34]>
Subject: XKMS: Was: Validation policy in DPV/DPD rqmts
Date: Sat, 2 Mar 2002 15:12:40 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Well, if we are going to discuss the validity of certain PKIX work,
may I question this list how you plan to differentiate DPV/DPD
with XKMS?

To me it seems that the "industry" have no interest to support two
similar schemes, so PKIX is probably too late with this proposal as the
"competitor" is already running.  If the "competitor" lacks some
features, I think the "industry" will do a "revision", rather than
begin toiling with something new.  Particularly as the "industry" has
indicated that they want to work with XML, and only use ASN.1
where it is necessary for historical reasons like for certificates.

Anders





Received: by above.proper.com (8.11.6/8.11.3) id g21NwvA15232 for ietf-pkix-bks; Fri, 1 Mar 2002 15:58:57 -0800 (PST)
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g21NwtG15225; Fri, 1 Mar 2002 15:58:55 -0800 (PST)
Received: from DEXTER ([192.168.0.6]) by brutesquadlabs.com with SMTP ; Fri, 1 Mar 2002 16:07:14 -0800
Message-ID: <498730.1015027636484.JavaMail.administrator@highland>
From: "Blake Ramsdell" <[e-mail]>
To: <[e-mail]>, "Paul Hoffman" <[e-mail]>
Subject: Comments on okid-01
Date: Fri, 1 Mar 2002 16:06:45 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Section 2 -- I recommend that both MAY recommendations for receiving
implementations be changed to SHOULD.

Table 1 last column heading is truncated ("Charac" not "Character").

I'm not sure about the utility of the first two characters identifying the
certificate type (EE vs. CA, specifically).  This creates a binding between
the intended use of the certificate to the actual contents of the
certificate.  Since the entire certificate is now being hashed, it seems
like it is just another integrity field and does not seem to have any other
useful purpose.  My worry is that this will introduce conflict for
conforming implementations that might have allowed root keys without the CA
flag set, but have an OCKID implementation that enforces the check and
forces the user to modify the leading CA to be EE to satisfy the integrity
check.  If it is desired to include the type identifier for human reasons,
then I recommend that the comparison against the CA field in the certificate
be optional, or that a generic certificate identifier be introduced.  I may
not understand the goals of this identifier, however, so be gentle...

Blake
--
Blake Ramsdell
Brute Squad Labs http://www.brutesquadlabs.com



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g21MWNu13281 for ietf-pkix-bks; Fri, 1 Mar 2002 14:32:23 -0800 (PST)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g21MWLG13265 for <[e-mail]>; Fri, 1 Mar 2002 14:32:22 -0800 (PST)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <D642DXJD>; Fri, 1 Mar 2002 17:32:19 -0500
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "ietf-pkix@imc. org (E-mail)" <[e-mail]>
Subject: v2.0.1 Certificate Management Library (CML) Now Available
Date: Fri, 1 Mar 2002 17:32:18 -0500 
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>

All,

Getronics Government Solutions has delivered the Version 2.0.1 
Certificate Management Library (CML) for Microsoft Windows, 
Sun Solaris and Linux.  The v2.0.1 CML is freely available
at: <http://www.getronicsgov.com/hot/cml_home.htm>.  The
v2.0.1 CML release fixes bugs present in the v2.0 CML release.

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 v2.0.1 CML is described in the v2.0 CML Application Programming
Interface (API) document.  It implements the 2000 X.509 Recommendation
certification path verification 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.  The v2.0.1 CML Abstract Syntax Notation One (ASN.1)
decodes X.509 Certificates and CRLs.  It requires the v1.3 R8 Enhanced
SNACC ASN.1 software that is freely available from:
<http://www.getronicsgov.com/hot/snacc_home.htm>.

The CML provides robust certificate path building capabilities such
as using cross certificates.  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 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 bugs were fixed in the v2.0.1 CML release 
(compared with the v2.0 release):

1) In PathNode::GetCertTree, pTree->cmCert was not being set to 
NULL prior to calling GetCertStruct.

2) CM_CertPath.cpp: pFreeObj was being freed twice. 

3) pNew->cmCert was not being set to NULL prior to processing.

4) PolicyConstraintsExtension default constructor did not 
initialize it's member variables. 

5) Bug in CML DN string conversion processing.


The following bugs were fixed in the v2.0.1 SRL release 
(compared with the v2.0 release):

1) Modified SRL errors numbers to be different than CML error
numbers, so application can tell which library generated the error.
Delivered v2.0.1 SRL API document to include new error code values.
 
2) Fixed SRL_ChangeLDAPInfo prototype.
 
3) Fixed instance where SRL_DatabaseSearch not checking for NULL DN. 
 
4) SRLi_GetAllCertificatesByType was calling SRL_DatabaseAdd with
wrong type mask on objects collected remotely.

5) Improved handling of LDAP URL Requests

6) SRL_DatabaseAdd was checking for a trusted cert using 
SRL_TRUSTED_CERT_TYPE, when ldap was setting the type to 
SRL_CA_CERT_TYPE. Added check to logic to ensure that the 
SRL_CA_CERT_TYPE cert is a trusted cert.


The following v2.0.1 CML files are available from the CML web page:
1) Windows_CML_Lib_v2.0.1.ZIP: MS Windows Dynamically Linked Libraries 
2) Windows_CM_Tool_v2.0.1.ZIP: CM_Tool executable
3) Solaris_CML_Lib_v2.0.1.tar.Z: Sun Solaris Libraries 
4) Solaris_CM_Tool_v2.0.1.tar.z: CM_Tool for Solaris
5) Linux_CML_Lib_v2.0.1.tar.Z: Linux Libraries
6) Linux_CM_Tool_v2.0.1.tar.z: CM_Tool for Linux
7) CML_source_v2.0.1.tar.Z: Source, including Windows project files 
8) CMAPI_data.tar.Z: Test Certs and CRLs used to test CML


The v2.0 CML API document (CMv2.0api.doc, CMv2.0api.pdf), v2.0.1 SRL API 
document (SRLv2.0.1api.doc, SRLv2.0.1api.pdf), and v2.0.1 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 CTIL API that provides
access to a variety of external crypto libraries.  There is a CTIL for 
each crypto library that maps the generic CTIL API calls to the 
specific calls for that crypto library.  Getronics provides CTILs for
the Microsoft CAPI v2.0, Crypto++, RSA BSAFE, Spyrus SPEX/ and 
FORTEZZA Cryptologic Interface libraries.  Getronics also provides a 
PKCS #11 CTIL that enables PKCS #11-compliant libraries to be used 
with the CML.  The underlying, external crypto libraries are not 
distributed as part of the CML software. 

Getronics has successfully tested the v2.0.1 CML with the SNACC and 
CTIL libraries delivered with the v2.0.1 S/MIME Freeware Library (SFL).  
Source code for the Getronics-developed CTILs is available from 
<http://www.getronicsgov.com/hot/sfl_home.htm>.  

The CML has been successfully tested with the Access Control 
Library (ACL) that is freely available to everyone from: 
<http://www.getronicsgov.com/hot/acl_home.htm>.

The v2.0.1 CML has been successfully used to build and verify 
certificate paths used in the Bridge Certification Authority (BCA)
demonstration which includes cross-certified hierarchical and non-
hierarchical PKIs.  The CML was used to successfully process the
BCA Interoperability Test Suite (BITS) test data available from:
<http://bcatest.atl.getronicsgov.com>.

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.

The CML meets the requirements stated in the SDN.706 Certificate/
CRL Profile required by the U.S. Defense Message System (DMS) 
project.

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: by above.proper.com (8.11.6/8.11.3) id g21LKD811501 for ietf-pkix-bks; Fri, 1 Mar 2002 13:20:13 -0800 (PST)
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 g21LKCG11495 for <[e-mail]>; Fri, 1 Mar 2002 13:20:12 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA28172; Fri, 1 Mar 2002 16:20:04 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100313b8a5a02a3e17@[128.89.88.34]>
In-Reply-To: <012401c1c15f$ffa74250$020aff0c@tsg1>
References: <20020228012927.CFKS2951.rwcrmhc53.attbi.com@rwcrwbc57> <04ae01c1c061$5f401340$020aff0c@tsg1> <p05100301b8a3f455959c@[128.89.88.34]> <050101c1c074$e8b722e0$020aff0c@tsg1> <p05100305b8a4171bc0f9@[128.89.88.34]> <054b01c1c09e$646263e0$020aff0c@tsg1> <p05100315b8a4527cb463@[128.89.88.34]> <058c01c1c0ab$2c86d8e0$020aff0c@tsg1> <p05100300b8a467b2b048@[128.89.88.34]> <012401c1c15f$ffa74250$020aff0c@tsg1>
Date: Fri, 1 Mar 2002 16:17:45 -0500
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Validation policy in DPV/DPD rqmts
Cc: "LISTS - 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>

At 12:30 PM -0800 3/1/02, todd glassey wrote:
>Steve this is pointless to argue on this list about. I disagree with what
>you are doing and believe that your impressive resume is being wasted in
>your current role.

Yes, Todd, it is pointless, so I'll stop responding as of now.

Steve


Received: by above.proper.com (8.11.6/8.11.3) id g21KXSE09433 for ietf-pkix-bks; Fri, 1 Mar 2002 12:33:28 -0800 (PST)
Received: from geos.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g21KXHG09425 for <[e-mail]>; Fri, 1 Mar 2002 12:33:17 -0800 (PST)
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 g21KWxi25468; Fri, 1 Mar 2002 12:32:59 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "Housley, Russ" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Validation policy in DPV/DPD rqmts
Date: Fri, 1 Mar 2002 12:30:29 -0800
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>

> -----Original Message-----
> From: Housley, Russ
> Sent: Friday, March 01, 2002 5:26 AM
>
> Mike:
>
> Please post your suggested text.  Based on your
> message, it should not need to be more than a
> paragraph.  Did I miss something?
>
> Russ

Russ,

Here's a first cut.  I suggest inserting this text immediately
following the identification of the various states a DPV server
must be capable of producing.

Mike


Prior to asserting a "valid" status, a DPV server SHALL, at a
minimum:

1. confirm that, in the time context of the request, the subject
certificate is (or was) niether revoked nor suspended by the
authority that issued the certificate;

2.  confirm that, in the time context of the request, all
certificates needed to complete the associated validation path
are (or were) niether revoked nor suspended, up to and including
the trust anchor; AND

2.  confirm that the subject certificate and its associated
intermediate and trust anchor certificates form a chain that
satisifies the path validation algorithm defined by RFC 2459 or
its successors [PKIX-1].



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g21KVfs09369 for ietf-pkix-bks; Fri, 1 Mar 2002 12:31:41 -0800 (PST)
Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g21KVbG09365 for <[e-mail]>; Fri, 1 Mar 2002 12:31:38 -0800 (PST)
Received: from tsg1 ([12.81.72.156]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020301203132.WOBB13933.mtiwmhc22.worldnet.att.net@tsg1>; Fri, 1 Mar 2002 20:31:32 +0000
Message-ID: <012401c1c15f$ffa74250$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: "LISTS - IETF-PKIX" <[e-mail]>
References: <20020228012927.CFKS2951.rwcrmhc53.attbi.com@rwcrwbc57> <04ae01c1c061$5f401340$020aff0c@tsg1> <p05100301b8a3f455959c@[128.89.88.34]> <050101c1c074$e8b722e0$020aff0c@tsg1> <p05100305b8a4171bc0f9@[128.89.88.34]> <054b01c1c09e$646263e0$020aff0c@tsg1> <p05100315b8a4527cb463@[128.89.88.34]> <058c01c1c0ab$2c86d8e0$020aff0c@tsg1> <p05100300b8a467b2b048@[128.89.88.34]>
Subject: Re: Validation policy in DPV/DPD rqmts
Date: Fri, 1 Mar 2002 12:30:25 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve this is pointless to argue on this list about. I disagree with what
you are doing and believe that your impressive resume is being wasted in
your current role.

> I do lots of things, in addition to standards work, but I view
> standards activities as important and a worthy use of my time.

I would agree.

> Also,
> I have clients who agree and are willing to pay for me to spend the
> time on these activities.

Which makes you an obvious resource for an organization like the IETF - its
just that you have sat for 7 years here in PKIX and we need some fresh
blood.

I suggest - and this is not a joke- that we petition the IESG and IAB to
make you the "Chief Scientist of the Internet" and create a specific and
permanent role for you there. This is not a joke - really it isn't. I see
this as one of the potentially most important roles in the IESG and IETF.
And for you to follow in Vint cerf's or John Postels shoes would be cool to
I think...

Steve this is not a slam on you personally - of that you are brilliant,
there is no doubt, but enough is enough. You nurtured (or kicked and
dragged) PKIX from its inception to where it is now, and it needs some new
blood to get it to the next level.

> Within BBN I've provided technical
> leadership in developing several generations of network security
> devices, plus secure e-mail systems, high assurance crypto modules,
> CA technology, etc. I also am known as one of the senior Internet
> wine experts and engage in serious nature photography, in my spare
> time ...
>

See what I mean.

>
> These other standards bodies have formal membership requirements and
> thus have a basis for voting.  the IETF does not, by its own choice,
> vote on these matters.  if you are unhappy with this arrangement,
> perhaps you should consider directing your energies to other
> standards bodies.

No Steve, Sooner or later you will have to admit that this is not 1974 and
that what the IETF was founded on was a need to get as many protocols out
there as possible as fast as possible to enable the development of the
Internet. The the Internet is a long way from where it was in 1974... no
more Honeywell IMPS. This is a key issue now that the internet extends into
Millions of homes and virtually every major or even small business in  the
mechanized world... (OK so its not all of them yet, but its too many to just
ignore).

Now the IETF's focus needs to shift to not just producing protocols but to
producing the right ones.  And that's going to take partnering with other
standards orgs formally and getting their input when we design core
functionality into the work we do. Its also going to mean getting many more
fledging protocols into the shoot, and that is what the current process
stifles and that a better disclosure mechanism is needed too. You know USE
MODELS (note that I spelled it in caps just for you, too!).

>
> >  > If you want to suggest term
> >>  limits, bring the topic up on POISED, where the topic is within scope.
> >>
> >
> >I have done exactly that - but POISED has been shut down so I have no
choice
> >but to bring my petitions for reform of the IETF (and thus this WG) back
> >inside this WG...  see the
http://www.ietf.org/html.charters/OLD/index.html
> >link for evidence of this.
> >
>
> See Paul's message.

I have and according the the IETF's website Paul's wrong, the WG is listed
as "completed"

Err unless of course its a typo.

>
> Steve



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g21J4jc06857 for ietf-pkix-bks; Fri, 1 Mar 2002 11:04:45 -0800 (PST)
Received: from isis.directory.dfn.de (isis.directory.dfn.de [134.2.217.130]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g21J4hG06853 for <[e-mail]>; Fri, 1 Mar 2002 11:04:43 -0800 (PST)
Received: from daasi.de (mercury.directory.dfn.de [134.2.217.50]) by isis.directory.dfn.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id g21J4gv04302; Fri, 1 Mar 2002 20:04:42 +0100
Message-ID: <[e-mail]>
Date: Fri, 01 Mar 2002 20:04:42 +0100
From: Peter Gietz <[e-mail]>
Organization: DAASI International
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7) Gecko/20011221
X-Accept-Language: en-us
MIME-Version: 1.0
To: [e-mail]
CC: Stephen Kent <[e-mail]>, Tim Polk <[e-mail]>, TERENA Taskforce LDAP Service Deployment <[e-mail]>
Subject: New draft on storing certificates in directories
Content-Type: multipart/mixed; boundary="------------090309080904060108090802"
X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------090309080904060108090802
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable


Hello,

Since quite a while we are dealing with the problem of multiple=20
certificates of one entity. As alternative to the Values Return Filter=20
Control proposed in draft-ietf-ldapext-matchedval-05.txt we propose
a different approach that might be more scalable with respect to widely=20
distributed certificate repositories that are combined by an CIP based=20
indexing service.

We had some discussion on this with Bruce Greenblatt and he might want=20
to join the team of authors.

So here is (a bit late, but hopefully not too late) our draft, which I=20
would very much like to have discussed in Minneapolis. Would it be=20
possible to get a small time slot in the pkix WG?


Cheers,

Peter

--=20
_______________________________________________________________________

Peter Gietz (CEO)
DAASI International GmbH                phone: [phone]
Wilhelmstr. 106                         Fax:   [phone]
D-72074 T=FCbingen                        email: [e-mail]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________

--------------090309080904060108090802
Content-Type: text/plain; charset=ISO-8859-1;
 name="draft-klasen-x509certificate-schema.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline;
 filename="draft-klasen-x509certificate-schema.txt"




Network Working Group                                          N. Klasen
Internet-Draft                                                  P. Gietz
Expires: August 28, 2002                        DAASI International GmbH

                                                       February 27, 2002


                An LDAPv3 Schema for X.509 Certificates
                  draft-klasen-x509certificate-schema

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 28, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document describes an LDAP schema which can be used to implement
   a certificate store for X.509 certificates.  Specifically, a
   structural object class for a X.509 certificate is defined.  Key
   fields of a certificate are stored as normal attributes so that
   applications can easily retrieve the certficates needed for
   encryption or chain building by using basic LDAP search filters.
   Multiple certificates for a single entity can be stored and retrieved

Conventions used in this document



Klasen, et al.           Expires August 28, 2002                [Page 1]
=0C
Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   The following syntax specifications use the augmented Backus-Naur
   Form (ABNF) as described in [RFC2234].

   Schema definitions are provided using LDAPv3 description formats
   [RFC2252].  Definitions provided here are formatted (line wrapped)
   for readability.

Table of Contents

   1.      Introduction . . . . . . . . . . . . . . . . . . . . . . .  4
   2.      Comparison with Values Return Filter Control . . . . . . .  5
   3.      The x509certificate object class and its attribute types .  6
   3.1     Attributes for mandatory fields of an X.509 certificate  .  6
   3.1.1   x509version  . . . . . . . . . . . . . . . . . . . . . . .  6
   3.1.2   serialNumber . . . . . . . . . . . . . . . . . . . . . . .  6
   3.1.3   signatureAlgorithm . . . . . . . . . . . . . . . . . . . .  6
   3.1.4   issuer . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.1.5   validity . . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.1.6   subject  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.1.7   subjectPublicKeyInfoAlgorithm  . . . . . . . . . . . . . .  8
   3.2     Attributes for selected extensions . . . . . . . . . . . .  8
   3.2.1   Subject key identifier extension . . . . . . . . . . . . .  9
   3.2.2   Key usage extension  . . . . . . . . . . . . . . . . . . .  9
   3.2.3   Policy information identifier extension  . . . . . . . . .  9
   3.2.4   Subject alternative name extension . . . . . . . . . . . . 10
   3.2.4.1 Rfc822Name . . . . . . . . . . . . . . . . . . . . . . . . 10
   3.2.4.2 DnsName  . . . . . . . . . . . . . . . . . . . . . . . . . 10
   3.2.4.3 DirectoryName  . . . . . . . . . . . . . . . . . . . . . . 11
   3.2.4.4 UniformResourceIdentifier  . . . . . . . . . . . . . . . . 11
   3.2.4.5 IpAddress  . . . . . . . . . . . . . . . . . . . . . . . . 11
   3.2.4.6 RegisteredID . . . . . . . . . . . . . . . . . . . . . . . 12
   3.2.5   Isssuer alternatvie name extension . . . . . . . . . . . . 12
   3.2.5.1 Rfc822Name . . . . . . . . . . . . . . . . . . . . . . . . 12
   3.2.5.2 DnsName  . . . . . . . . . . . . . . . . . . . . . . . . . 12
   3.2.5.3 DirectoryName  . . . . . . . . . . . . . . . . . . . . . . 13
   3.2.5.4 UniformResourceIdentifier  . . . . . . . . . . . . . . . . 13
   3.2.5.5 IpAddress  . . . . . . . . . . . . . . . . . . . . . . . . 13
   3.2.5.6 RegisteredID . . . . . . . . . . . . . . . . . . . . . . . 14
   3.2.6   Extended key usage extension . . . . . . . . . . . . . . . 14
   3.2.7   CRL distribution points extension  . . . . . . . . . . . . 14
   3.3     Additional attributes  . . . . . . . . . . . . . . . . . . 15
   3.3.1   Email addresses  . . . . . . . . . . . . . . . . . . . . . 15
   3.4     x509certificate object class . . . . . . . . . . . . . . . 15
   4.      DIT Structure and Naming . . . . . . . . . . . . . . . . . 17



Klasen, et al.           Expires August 28, 2002                [Page 2]
=0C
Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002


   5.      Security Considerations  . . . . . . . . . . . . . . . . . 19
   6.      Acknowledgements . . . . . . . . . . . . . . . . . . . . . 20
           References . . . . . . . . . . . . . . . . . . . . . . . . 21
           Authors' Addresses . . . . . . . . . . . . . . . . . . . . 23
   A.      Sample directory entries . . . . . . . . . . . . . . . . . 24
   B.      Sample searches  . . . . . . . . . . . . . . . . . . . . . 27
           Full Copyright Statement . . . . . . . . . . . . . . . . . 28












































Klasen, et al.           Expires August 28, 2002                [Page 3]
=0C
Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002


1. Introduction

   A key component in the wide-spread adoption of a PKI infrastructure
   is the general availabilty of public key and their certificates.
   Today, certificates are often published in an X.500 compliant
   directory service.  These directories are accessed by applications
   using the LDAP v2 [RFC1777] or v3 [RFC2251] protocol.  [RFC2559]
   defines a subset of LDAP v2 operations required for Internet X.509
   Public Key Infrastructure.  An LDAPv2 schema to PKI repository
   objects is specified in [RFC2587], were a set of attribute types and
   auxiliary object classes are defined.  For stroring certficates, the
   "userCertficate" attribute type is used.  All certificates of an
   entity are stored as values in a multi-valued  attribute.  This
   solution has a serious drawback.  In LDAP, the smallest granularity
   of data access is the attribute.  It is not possible to request a
   specific value of an attribute (see also [matchedval]).  The
   directory server will therefore always return the full list of
   certficates of an entry to applications dealing with certificates.
   If the number of certficates for a entity is large this will result
   in considerable overhead.

   This document proposes the use of the x509certificate structural
   object class for storing certficates.  Each certficate will be stored
   in a separate entry in the directory.  Fields of certificates, which
   are needed to identify a certificate and those which are often used
   in searching for an appropriate certificate, are extracted from the
   certificate and stored as attributes of the entry.  Applications can
   thus search for specific certficates with simple LDAP filters.  The
   use of simple attributes also makes a large scale widely distributed
   certificate repository service possible by using an indexing service
   based on the Common Indexing Protocol [RFC2651].




















Klasen, et al.           Expires August 28, 2002                [Page 4]
=0C
Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002


2. Comparison with Values Return Filter Control

   In [matchedval] a control has been defined that allows for only
   certain values of a specified attribute to be returned from a
   matching entry.  In this section, this approach is compared with the
   one proposed in this document.  The major benefit of the Values
   Return Filter Control is that it does not require any changes to the
   DIT.  If a customer has deployed certificate information in such a
   way that individual entries have numerous certificates attached to
   them then the Values Return Filter Control is useful.  While it is a
   simple matter to modify the DIT in such a way that all certificate
   information is removed from the entries, and placed in the container
   directly beneath the entries according to the definitions of this
   specification, it is less simple to simultaneously modify all of the
   applications that depend on certificates being stored in the entry.
   Thus, it may be desirable to duplicate the certificate information,
   by having it appear in the entry, as well as in the container beneath
   the entry for a short period of time, in order to allow for migration
   of the applications to the new LDAP schema.  As in any situation in
   which information is duplicated, great care must be taken in order to
   insure the integrity of the information.

   There are several advantages in using the x509certificate object
   class.  No special matching rules are needed to retrieve a specific
   certificate.  Any field in the certificate can be used in the search
   filter.  Even information that doesn't appear in the certificate can
   be used in a search filter.  It is easier to remove certificates from
   the DIT, since the entire certificate DER encoding does not have to
   be supplied in the modify operation.  Searches that don't need
   extensible matching rules and Values Return Filter Control will
   perform faster.

   Another advantage of the solution proposed here is that it will not
   necessary to modify existing server implementations to support this
   schema.  The extended matching rules proposed in [pkix-ldap-schema]
   would require substantial changes the servers' indexing mechanisms.
   In contrast, servers implementing the x509certificate schema can
   easily levarage their indexing support for standard LDAPv3 syntaxes.













Klasen, et al.           Expires August 28, 2002                [Page 5]
=0C
Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002


3. The x509certificate object class and its attribute types

3.1 Attributes for mandatory fields of an X.509 certificate

3.1.1 x509version

   Version of the encoded certificate.

   ( 1.3.6.1.4.1.10126.1.5.3.1
           NAME 'x509version'
           DESC 'Version of the certificate, X.509(2000) 7, RFC2459 4.1.2=
=2E1'
           EQUALITY integerMatch
           ORDERING integerOrderingMatch
           SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
           SINGLE-VALUE )

   Values of this attribute may either be 0, 1 or 2 correspoding to
   X.509 v1, v2 or v3.

3.1.2 serialNumber

   The serial number is an integer assigned by the CA to each
   certificate.  It is unique for each certificate issued by a given CA
   (i.e., the issuer name and serial number uniquely identify a
   certificate).

   ( 1.3.6.1.4.1.10126.1.5.3.2
   	NAME 'x509serialNumber'
   	DESC 'Unique integer for each cerfiticate issued by a
   	      particular CA, X.509(2000) 7, RFC2459 4.1.2.2'
   	EQUALITY integerMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
   	SINGLE-VALUE )


3.1.3 signatureAlgorithm

   OID identifying the algorithm and hash function used by the CA in
   signing the certificate.

   ( 1.3.6.1.4.1.10126.1.5.3.3
   	NAME 'x509signatureAlgorithm'
   	DESC 'OID of the algorithm and hash function used by the CA in
   	      signing the certificate, X.509(2000) 7, RFC2459 4.1.2.3'
   	EQUALITY objectIdentifierMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
   	SINGLE-VALUE )




Klasen, et al.           Expires August 28, 2002                [Page 6]
=0C
Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002


3.1.4 issuer

   String representation of the issuer's distinguished name.

   ( 1.3.6.1.4.1.10126.1.5.3.4
   	NAME 'x509issuer'
   	DESC 'Distinguished name of the entity who has signed and
   	      issued the certificate, X.509(2000) 7, RFC2459 4.1.2.4'
   	EQUALITY distinguishedNameMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
   	SINGLE-VALUE )

   Values of this attribute type must be encoded according to the syntax
   given in [RFC2253].

3.1.5 validity

   The "validity" attribute in an X.509 certficate consists of an ASN.1
   sequence of two timestamps, which define the begin and end of the
   certficate's validity period.  This sequence has been split up into
   two seperate attributes "x509validityNotBefore" and
   "x509validityNotAfter".  The times are represented in string form as
   defined in [RFC2252].

   ( 1.3.6.1.4.1.10126.1.5.3.5
   	NAME 'x509validityNotBefore'
   	DESC 'Date on which the certificate validity period begins,
   	      X.509(2000) 7, RFC2459 4.1.2.5'
   	EQUALITY generalizedTimeMatch
   	ORDERING generalizedTimeOrderingMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
   	SINGLE-VALUE )


   ( 1.3.6.1.4.1.10126.1.5.3.6
   	NAME 'x509validityNotAfter'
   	DESC 'Date on which the certificate validity period ends,
   	      X.509(2000) 7, RFC2459 4.1.2.5'
   	EQUALITY generalizedTimeMatch
   	ORDERING generalizedTimeOrderingMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
   	SINGLE-VALUE )


3.1.6 subject

   String representation of the subject's distinguished name.




Klasen, et al.           Expires August 28, 2002                [Page 7]
=0C
Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002


   ( 1.3.6.1.4.1.10126.1.5.3.7
   	NAME 'x509subject'
   	DESC 'Distinguished name of the entity associated with this
   	      public-key, X.509(2000) 7, RFC2459 4.1.2.6'
   	EQUALITY distinguishedNameMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
   	SINGLE-VALUE )

   Values of this attribute type must be encoded according to the syntax
   given in [RFC2253].

3.1.7 subjectPublicKeyInfoAlgorithm

   OID of the algorithm of which the certified public key is an instance
   of.

   ( 1.3.6.1.4.1.10126.1.5.3.8
   	NAME 'x509subjectPublicKeyInfoAlgorithm'
   	DESC 'OID of the algorithm which this public key is an
   	      instance of, X.509(2000) 7, RFC2459 4.1.2.7'
   	EQUALITY objectIdentifierMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
   	SINGLE-VALUE )


3.2 Attributes for selected extensions

   As this specification intends to only facilitate applications in
   finding certficates, only those extensions have to be defined that
   might be searched for.  Thus the following extensions described in
   [RFC2459] are not dealt with here:

   o  authority key identifier extension

   o  private key usage period extension

   o  policy mappings extension

   o  subject directory attributes extension

   o  pathLenConstraint of basic constraints extension

   o  name contraints extensions

   o  policy contraints extensions

   o  inhibit any policy extension




Klasen, et al.           Expires August 28, 2002                [Page 8]
=0C
Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002


3.2.1 Subject key identifier extension

   This attribute identifies the public key being certified.  It enables
   distinct keys used by the same subject to be differentiated.

   ( 1.3.6.1.4.1.10126.1.5.3.14
   	NAME 'x509subjectKeyIdentifier'
   	DESC 'Key identifier which must be unique with respect to all
   	      key identifiers for the subject, X.509(2000) 8.2.2.2,
   	      RFC2459 4.2.1.2'
   	EQUALITY octetStringMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
   	SINGLE-VALUE )


3.2.2 Key usage extension

   This attribute defines the purpose (e.g., encipherment, signature,
   certificate signing) of the key contained in the certificate.

   ( 1.3.6.1.4.1.10126.1.5.3.15
   	NAME 'x509keyUsage'
   	DESC 'Purpose for which the certified public key is used,
   	      X.509(2000) 8.2.2.3, RFC2459 4.2.1.3'
   	EQUALITY caseIgnoreMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

   Values of this type are encoded according to the following BNF, so
   that each value corresponds to the respective bit in the ASN.1
   "KeyUsage" bitstring:

   x509keyUsage-value =3D"digitalSignature" / "nonRepudiation" /
   	"keyEncipherment" / "dataEncipherment" / "keyAgreement" /
   	"keyCertSign" / "cRLSign" / "encipherOnly" / "decipherOnly"


3.2.3 Policy information identifier extension

   This attribute contains OIDs which indicate the policy under which
   the certificate has been issued and the purposes for which the
   certificate may be used.










Klasen, et al.           Expires August 28, 2002                [Page 9]
=0C
Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002


   ( 1.3.6.1.4.1.10126.1.5.3.16
   	NAME 'x509policyInformationIdentifier'
   	DESC 'OID which indicates the policy under which the
   	      certificate has been issued and the purposes for which
   	      the certificate may be used, X.509(2000) 8.2.2.6, RFC2459
   	      4.2.1.5'
   	EQUALITY objectIdentifierMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
   	SINGLE-VALUE )


3.2.4 Subject alternative name extension

   The subject alternative names extension allows additional identities
   to be bound to the subject of the certificate.  Separate attribute
   types are defined for all choices of the ASN.1 type "GeneralName"
   exept for "otherName", "x400Address" and "ediPartyName".

3.2.4.1 Rfc822Name

   ( 1.3.6.1.4.1.10126.1.5.3.17
   	NAME 'x509subjectAltNameRfc822Name'
   	DESC 'Internet electronic mail address, X.509(2000) 8.3.2.1,
   	      RFC2459 4.2.1.7'
   	EQUALITY caseIgnoreMatch
   	SUBSTR caseIgnoreSubstringsMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

   Values of this attribute must be encoded accroding to the syntax
   given in [RFC0822].

3.2.4.2 DnsName

   ( 1.3.6.1.4.1.10126.1.5.3.18
   	NAME 'x509subjectAltNameDnsName'
   	DESC 'Internet domain name, X.509(2000) 8.3.2.1, RFC2459
   	      4.2.1.7'
   	EQUALITY caseIgnoreMatch
   	SUBSTR caseIgnoreSubstringsMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

   Values of this attribute must be encoded as Internet domain names in
   accordance with [RFC1035].








Klasen, et al.           Expires August 28, 2002               [Page 10]
=0C
Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002


3.2.4.3 DirectoryName

   ( 1.3.6.1.4.1.10126.1.5.3.19
   	NAME 'x509subjectAltNameDirectoryName'
   	DESC 'Distinguished name, X.509(2000) 8.3.2.1, RFC2459
   	      4.2.1.7'
   	EQUALITY distinguishedNameMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

   Values of this attribute type must be encoded according to the syntax
   given in [RFC2253].

3.2.4.4 UniformResourceIdentifier

   ( 1.3.6.1.4.1.10126.1.5.3.20
   	NAME  'x509subjectAltNameUniformResourceIdentifier'
   	DESC 'Uniform Resource Identifier for the World-Wide Web,
   	      X.509(2000) 8.3.2.1, RFC2459 4.2.1.7'
   	EQUALITY caseExactMatch
   	SUBSTR caseExactSubstringsMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

   Values of this attribute must be encoded according to the syntax
   given in [RFC2396].

3.2.4.5 IpAddress

   ( 1.3.6.1.4.1.10126.1.5.3.21
   	NAME 'x509subjectAltNameIpAddress'
   	DESC 'Internet Protocol address, X.509(2000) 8.3.2.1, RFC2459
   	      4.2.1.7'
   	EQUALITY caseIgnoreMatch
   	SUBSTR caseIgnoreSubstringsMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

   Values of this attribute type must be stored in the syntax given in
   Appendix B of [RFC2373].














Klasen, et al.           Expires August 28, 2002               [Page 11]
=0C
Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002


3.2.4.6 RegisteredID

   ( 1.3.6.1.4.1.10126.1.5.3.22
   	NAME 'x509subjectAltNameRegisteredID'
   	DESC 'OID of any registered object, X.509(2000) 8.3.2.1,
   	      RFC2459 4.2.1.7'
   	EQUALITY objectIdentifierMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )


3.2.5 Isssuer alternatvie name extension

   The issuer alternative names extension allows additional identities
   to be bound to the subject of the certificate.  Separate attribute
   types are defined for all choices of the ASN.1 type "GeneralName"
   exept for "otherName", "x400Address" and "ediPartyName".

3.2.5.1 Rfc822Name

   ( 1.3.6.1.4.1.10126.1.5.3.23
   	NAME 'x509isssuerAltNameRfc822Name'
   	DESC 'Internet electronic mail address, X.509(2000) 8.3.2.2,
   	      RFC2459 4.2.1.8'
   	EQUALITY caseIgnoreMatch
   	SUBSTR caseIgnoreSubstringsMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

   Values of this attribute must be encoded accroding to the syntax
   given in [RFC0822].

3.2.5.2 DnsName

   ( 1.3.6.1.4.1.10126.1.5.3.24
   	NAME 'x509isssuerAltNameDnsName'
   	DESC 'Internet domain name, X.509(2000) 8.3.2.2, RFC2459
   	      4.2.1.8'
   	EQUALITY caseIgnoreMatch
   	SUBSTR caseIgnoreSubstringsMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

   Values of this attribute must be encoded as Internet domain names in
   accordance with [RFC1035].









Klasen, et al.           Expires August 28, 2002               [Page 12]
=0C
Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002


3.2.5.3 DirectoryName

   ( 1.3.6.1.4.1.10126.1.5.3.25
   	NAME 'x509isssuerAltNameDirectoryName'
   	DESC 'Distinguished name, X.509(2000) 8.3.2.2, RFC2459
   	      4.2.1.8'
   	EQUALITY distinguishedNameMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

   Values of this attribute type must be encoded according to the syntax
   given in [RFC2253].

3.2.5.4 UniformResourceIdentifier

   ( 1.3.6.1.4.1.10126.1.5.3.26
   	NAME  'x509isssuerAltNameUniformResourceIdentifier'
   	DESC 'Uniform Resource Identifier for the World-Wide Web,
   	      X.509(2000) 8.3.2.2, RFC2459 4.2.1.8'
   	EQUALITY caseExactMatch
   	SUBSTR caseExactSubstringsMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

   Values of this attribute must be encoded according to the syntax
   given in [RFC2396].

3.2.5.5 IpAddress

   ( 1.3.6.1.4.1.10126.1.5.3.27
   	NAME 'x509isssuerAltNameIpAddress'
   	DESC 'Internet Protocol address, X.509(2000) 8.3.2.2, RFC2459
   	      4.2.1.8'
   	EQUALITY caseIgnoreMatch
   	SUBSTR caseIgnoreSubstringsMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

   Values of this attribute type must be stored in the syntax given in
   Appendix B of [RFC2373].














Klasen, et al.           Expires August 28, 2002               [Page 13]
=0C
Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002


3.2.5.6 RegisteredID

   ( 1.3.6.1.4.1.10126.1.5.3.28
   	NAME 'x509isssuerAltNameRegisteredID'
   	DESC 'OID of any registered object, X.509(2000) 8.3.2.2,
   	      RFC2459 4.2.1.8'
   	EQUALITY objectIdentifierMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )

   registeredID is an identifier of any registered object assigned in
   accordance with ITU-T Rec.  X.660.

3.2.6 Extended key usage extension

   This attribute indicates one or more purposes for which the certified
   public key may be used, in addition to or in place of the basic
   purposes indicated in the "x509keyUsage" attribute.  These purposes
   are identified by their OID.

   ( 1.3.6.1.4.1.10126.1.5.3.30
   	NAME 'x509extKeyUsage'
   	DESC 'Purposes for which the certified public key may be used
   	      (identified by OID), X.509(2000) 8.2.2.4, RFC2459
   	      4.2.1.13'
   	EQUALITY objectIdentifierMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )


3.2.7 CRL distribution points extension

   This attribute identifies how CRL information for this certifacte can
   be obtained.

   ( 1.3.6.1.4.1.10126.1.5.3.31
   	NAME 'x509cRLDistributionPointURI'
   	DESC 'DistributionPointName of type URI, X.509(2000) 8.6.2.1, RFC2459=
 4.2.1.13'
   	EQUALITY caseExactMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

   In this specification, only the "uniformResourceIdentifier" choice of
   "distributionPoint.fullName" field is supported.  If this attribute
   exists in an entry, both the "reasons" and "cRLIssuer" fields MUST be
   absent from the certificate, i.e.  the CRL distributed by the
   distribution point contains revocations for all revocation reasons
   and the CRL issuer is identical to the certificate issuer.

   Values of this attribute must be encoded accroding to the URI syntax
   given in [RFC2396].



Klasen, et al.           Expires August 28, 2002               [Page 14]
=0C
Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002


3.3 Additional attributes

3.3.1 Email addresses

   The "mail" (0.9.2342.19200300.100.1.3) attribute from [RFC2798] is
   used to store the subject's email address.  This attribute MUST be
   populated with the values from a subject alternative name extension
   of type rfc822Name if such an extension is present.  Legacy
   applications conforming to [RFC2312] include an "EmailAddress"
   (1.2.840.113549.1.9.1) attribute in the subject's distinguished name.
   If the subject alternative name extension is absent from the
   certificate, this value MUST be used to populate the "mail"
   attribute.

3.4 x509certificate object class

   This structural object class contains the fields of an X.509
   certificate that are used in searches as attributes.

   ( 1.3.6.1.4.1.10126.1.5.4.2.1
   	NAME 'x509certificate'
   	STRUCTURAL
   	MUST ( x509serialNumber $ x509signatureAlgorithm $ x509issuer $
   		x509validityNotBefore $ x509validityNotAfter $ x509subject $
   		x509subjectPublicKeyInfoAlgorithm )
   	MAY  ( mail $ x509authorityKeyIdentifier $
   		x509authorityCertIssuer $ x509authorityCertSerialNumber $
   		x509subjectKeyIdentifier $ x509keyUsage $
   		x509policyInformationIdentifier $
   		x509subjectAltNameRfc822Name $ x509subjectAltNameDnsName $
   		x509subjectAltNameDirectoryName $ x509subjectAltNameURI $
   		x509subjectAltNameIpAddress $ x509subjectAltNameRegisteredID $
   		x509isssuerAltNameRfc822Name $ x509isssuerAltNameDnsName $
   		x509isssuerAltNameDirectoryName $ x509isssuerAltNameURI $
   		x509isssuerAltNameIpAddress $ x509isssuerAltNameRegisteredID $
   		x509basicConstraintsCa $ x509extKeyUsage $
   		x509cRLDistributionPoint ) )

   Entries of this structural object class MUST also have one of the one
   of the following auxiliary object classes: "pkiUser" or "pkiCA".
   This way the entry can contain the binary certificate in the
   "userCertificate" or "caCertficate" attribute.

   These object classes and attribute types are chosen to allow
   interoperability with older clients.  As defined in [X.509-2000] the
   "pkiUser" and "pkiCA" object classes include the "userCertificate"
   and respectivly "caCertficate" attributes as optional attribute.
   Furthermore, both attributes are multi-valued.  For the purpose of



Klasen, et al.           Expires August 28, 2002               [Page 15]
=0C
Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002


   this specification, each entry with a structural objectclass of
   x509certificate MUST have one and only one value of the
   userCertificate attribute or caCertificate attribute, respectively.
















































Klasen, et al.           Expires August 28, 2002               [Page 16]
=0C
Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002


4. DIT Structure and Naming

   If the schema presented in this document is used to store certficate
   information in a directory that contains entries for organizations,
   persons, services, etc., each certficate belonging to an entity
   SHOULD be stored as a direct subordinate to the entity's entry.  In
   this case, these entries MUST be named by a multi-valued RDN formed
   by the certficate issuer and serial number, as this is the only way
   to enforce unique RDN under the siblings.  This is expressed in the
   following name form:

   ---------------------------------------------------------------------


   ( 1.3.6.1.4.1.10126.1.5.5.1
   	NAME "x509certficate nameform"
   	OC x509certificate
   	MUST ( x509issuer $ x509serial ) )

                          certficate name form

   ---------------------------------------------------------------------

   For public directories of CAs that, besides the data stored in the
   certficates, do not hold any additional data about end entities the
   folloing DIT structure might be preferable.  Entries for certficates
   are stored directly below the issuing CA's entry.  In this case these
   entries SHOULD be named by the certficate serial number.  This is
   expressed in the following name form:

   ---------------------------------------------------------------------


   ( 1.3.6.1.4.1.10126.1.5.5.2
   	NAME "x509certficate alternate nameform"
   	OC x509certificate
   	MUST x509serial )

                     certficate alternate name form

   ---------------------------------------------------------------------

   Care must be taken, when encoding DNs, that contain an x509issuer
   attribute.  Such a value is a string representation according to
   [RFC2253].  These strings contain RFC2253 special characters and must
   therefor be escaped.  For example, the issuer name in a certificate
   may be:




Klasen, et al.           Expires August 28, 2002               [Page 17]
=0C
Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002


   x509issuer: OU=3DVeriSign Trust Network,OU=3D(c) 1998 VeriSign\2c Inc.=
 - For aut
    horized use only,OU=3DClass 1 Public Primary Certification Authority =
- G2,O=3DV
    eriSign\2c Inc.,C=3DUS

   When used in a DN, this will be appear as:

   dn: x509serial=3D123456+x509issuer=3DOU\3dVeriSign Trust Network \2cOU=
\3d(c) 199
    8 VeriSign\5c\2c Inc. - For authorized use only\2cOU\3dClass 1 Public=
 Prima
    ry Certification Authority - G2\2cO\3dVeriSign\5c\2c Inc.\2cC\3dUS,cn=
=3DJoe E
    xample









































Klasen, et al.           Expires August 28, 2002               [Page 18]
=0C
Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002


5. Security Considerations

   Attributes of directory entries are used to provide descriptive
   information about the real-world objects they represent, which can be
   people, organizations or devices.  Most countries have privacy laws
   regarding the publication of information about people.

   Without additional mechanisms such as Operation Signatures [RFC2649]
   which allow a client to verify the origin and integrity of the data
   contained in the attributes defined in this document, a client MUST
   NOT treat this data as authentic.  Clients MUST only use - after
   proper validation - the data which they obtained directly from the
   binary certificate.  Directory administrators MAY deploy ACLs which
   limit access to the attributes defined in this document to search
   filters.

   Transfer of cleartext passwords is strongly discouraged where the
   underlying transport service cannot guarantee confidentiality and may
   result in disclosure of the password to unauthorized parties.

   In order to protect the directory and its contents, strong
   authentication MUST have been used to identify the Client when an
   update operation is requested.




























Klasen, et al.           Expires August 28, 2002               [Page 19]
=0C
Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002


6. Acknowledgements

   This document borrows from a number of IETF documents, including
   [certinfo-schema].

   The authors wish to thank Michael Str=C3=B6der for his significant
   contribution to this document.

   This work is part of the DFN Project "Ausbau und Weiterbetrieb eines
   Directory Kompetenzzentrums" funded by the German ministry of
   research (BMBF).

   This document has been written in XML according to the DTD specified
   in RFC2629.  xml2rfc has been used to generate an RFC2033 compliant
   plain text form.  The XML source and a HTML version are available on
   request.



































Klasen, et al.           Expires August 28, 2002               [Page 20]
=0C
Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002


References

   [RFC0822]           Crocker, D., "Standard for the format of ARPA
                       Internet text messages", STD 11, RFC 822, August
                       1982.

   [RFC1035]           Mockapetris, P., "Domain names - implementation
                       and specification", STD 13, RFC 1035, November
                       1987.

   [RFC1777]           Yeong, W., Howes, T. and S. Kille, "Lightweight
                       Directory Access Protocol", RFC 1777, March 1995.

   [RFC2119]           Bradner, S., "Key words for use in RFCs to
                       Indicate Requirement Levels", BCP 14, RFC 2119,
                       March 1997.

   [RFC2234]           Crocker, D. and P. Overell, "Augmented BNF for
                       Syntax Specifications: ABNF", RFC 2234, November
                       1997.

   [RFC2251]           Wahl, M., Howes, T. and S. Kille, "Lightweight
                       Directory Access Protocol (v3)", RFC 2251,
                       December 1997.

   [RFC2252]           Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
                       "Lightweight Directory Access Protocol (v3):
                       Attribute Syntax Definitions", RFC 2252, December
                       1997.

   [RFC2253]           Wahl, M., Kille, S. and T. Howes, "Lightweight
                       Directory Access Protocol (v3): UTF-8 String
                       Representation of Distinguished Names", RFC 2253,
                       December 1997.

   [RFC2256]           Wahl, M., "A Summary of the X.500(96) User Schema
                       for use with LDAPv3", RFC 2256, December 1997.

   [RFC2312]           Dusse, S., Hoffman, P., Ramsdell, B. and J.
                       Weinstein, "S/MIME Version 2 Certificate
                       Handling", RFC 2312, March 1998.

   [RFC2373]           Hinden, R. and S. Deering, "IP Version 6
                       Addressing Architecture", RFC 2373, July 1998.

   [RFC2396]           Berners-Lee, T., Fielding, R. and L. Masinter,
                       "Uniform Resource Identifiers (URI): Generic
                       Syntax", RFC 2396, August 1998.



Klasen, et al.           Expires August 28, 2002               [Page 21]
=0C
Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002


   [RFC2459]           Housley, R., Ford, W., Polk, T. and D. Solo,
                       "Internet X.509 Public Key Infrastructure
                       Certificate and CRL Profile", RFC 2459, January
                       1999.

   [RFC2559]           Boeyen, S., Howes, T. and P. Richard, "Internet
                       X.509 Public Key Infrastructure Operational
                       Protocols - LDAPv2", RFC 2559, April 1999.

   [RFC2560]           Myers, M., Ankney, R., Malpani, A., Galperin, S.
                       and C. Adams, "X.509 Internet Public Key
                       Infrastructure Online Certificate Status Protocol
                       - OCSP", RFC 2560, June 1999.

   [RFC2587]           Boeyen, S., Howes, T. and P. Richard, "Internet
                       X.509 Public Key Infrastructure LDAPv2 Schema",
                       RFC 2587, June 1999.

   [RFC2649]           Greenblatt, B. and P. Richard, "An LDAP Control
                       and Schema for Holding Operation Signatures", RFC
                       2649, August 1999.

   [RFC2651]           Allen, J. and M. Mealling, "The Architecture of
                       the Common Indexing Protocol (CIP)", RFC 2651,
                       August 1999.

   [RFC2798]           Smith, M., "Definition of the inetOrgPerson LDAP
                       Object Class", RFC 2798, April 2000.

   [X.501-93]          ITU, "Information  Technology  - Open  Systems
                       Interconnection - The  Directory: Models", ITU-T
                       Recommendation   X.501, November 1993.

   [X.509-2000]        ITU, "Information  Technology - Open Systems
                       Interconnection - The  Directory: Public-key and
                       attribute certificate frameworks", ITU-T
                       Recommendation   X.509, March 2000.

   [certinfo-schema]   Greenblatt, B., "LDAP Object Class for Holding
                       Certificate Information", Internet Draft (work in
                       progress), Februar 2000, <http://
                       www.watersprings.org/pub/id/draft-greenblatt-
                       ldap-certinfo-schema-02.txt>.

   [matchedval]        Chadwick, D. and S. Mullan, "Returning Matched
                       Values with LDAPv3", Internet Draft (work in
                       progress), December 2000, <http://
                       www.watersprings.org/pub/id/draft-ietf-ldapext-



Klasen, et al.           Expires August 28, 2002               [Page 22]
=0C
Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002


                       matchedval-05.txt>.

   [pkix-ldap-schema]  Chadwick, D. and S. Legg, "Internet X.509 Public
                       Key Infrastructure - Additional LDAP Schema for
                       PKIs and PMIs", Internet Draft (work in
                       progress), November 2001, <http://
                       www.watersprings.org/pub/id/draft-ietf-pkix-ldap-
                       schema-02.txt>.


Authors' Addresses

   Norbert Klasen
   DAASI International GmbH
   Wilhelmstr. 106
   T=C3=BCbingen  72074
   DE

   EMail: [e-mail]


   Peter Gietz
   DAASI International GmbH
   Wilhelmstr. 106
   T=C3=BCbingen  72074
   DE

   Phone: [phone]
   EMail: [e-mail]
   URI:   http://www.daasi.de/


   Bruce Greenblatt
   DTASI
   6841 Heaton Moor Drive
   San Jose, CA  95119
   US

   Phone: [phone]
   EMail: [e-mail]
   URI:   http://www.dtasi.com/










Klasen, et al.           Expires August 28, 2002               [Page 23]
=0C
Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002


Appendix A. Sample directory entries

   A sample x509certificate directory entry for an intermediate CA in
   LDIF format:

   dn: x509serialNumber=3D4903272,EMAILADDRESS=[e-mail],CN=3D=
DFN Topl
    evel Certification Authority,OU=3DDFN-PCA,OU=3DDFN-CERT GmbH,O=3DDeut=
sches Fo
    rschungsnetz,C=3DDE
   objectclass: x509certficate
   x509version: 2
   x509serialNumber: 4903272
   x509issuer: EMAILADDRESS=[e-mail],CN=3DDFN Toplevel Certif=
icatio
    n Authority,OU=3DDFN-PCA,OU=3DDFN-CERT GmbH,O=3DDeutsches Forschungsn=
etz,C=3DDE
   x509validityNotBefore: 20020110170112Z
   x509validityNotAfter: 20060110170112Z
   x509subject: EMAILADDRESS=[e-mail],OU=3DDAASI CA,O=3DDAASI Intern=
ational
    GmbH,C=3DDE
   x509subjectPublicKeyInfoAlgorithm: 1.2.840.113549.1.1.1
   x509basicConstraintsCa: TRUE
   x509keyUsage: keyCertSign
   x509keyUsage: cRLSign
   x509subjectKeyIdentifier:: 5nrZFpVK4RKfIglqQ4N4JXBS4Bk=3D
   x509cLRdistributionPointURI: http://www.dfn-pca.de/certification/x509/=
g1
    /data/crls/root-ca-crl.crx
   x509cLRdistributionPointURI: http://www.dfn-pca.de/certification/x509/=
g1
    /data/crls/root-ca-crl.crl
   x509policyInformationIdentifier: 1.3.6.1.4.1.11418.300.1.1
   mail: [e-mail]
   objectClass: pkiCa
   caCertificate;binary:: MIIHTTCCBjWgAwIBAgIDStFoMA0GCSqGSIb3DQEBBQUAMIG=
sM
    QswCQYDVQQGEwJERTEhMB8GA1UEChMYRGV1dHNjaGVzIEZvcnNjaHVuZ3NuZXR6MRYwFA=
YD
    VQQLEw1ERk4tQ0VSVCBHbWJIMRAwDgYDVQQLEwdERk4tUENBMS0wKwYDVQQDEyRERk4gV=
G9
    wbGV2ZWwgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmNlcnRp=
Zn
    lAcGNhLmRmbi5kZTAeFw0wMjAxMTAxNzAxMTJaFw0wNjAxMTAxNzAxMTJaMF8xCzAJBgN=
VB
    AYTAkRFMSEwHwYDVQQKExhEQUFTSSBJbnRlcm5hdGlvbmFsIEdtYkgxETAPBgNVBAsTCE=
RB
    QVNJIENBMRowGAYJKoZIhvcNAQkBFgtjYUBkYWFzaS5kZTCCASIwDQYJKoZIhvcNAQEBB=
QA
    DggEPADCCAQoCggEBAKmQBp+Gr28/qlEWjnJoiH3AwmhNEYMRWgXMXMMjM3S4mSmXZ8FZ=
fT
    SPhi5O1zx5nyHecfl01fAO79Kpc6XkOTOl4iKBwu7+DM6my9Iizp2puhOQ6iuuchAIyJQ=
PR
    0lfWAvvW+4n7Nf13Js5qFHvXBDqvgt6fud1l8XZ4nPWBSbs6OnB4EUDlRLx5fdCX2sEPQ=
IN
    Keu0INMtjHI6eGbspmahup0ArPA9RYZVjVq6ZHkh4205/JAhji9KtFifKCztXNTRMba7A=
Hd
    2uS6GbF9+chGLPWGNZKtMhad1SvU7Zlw/ySHkFbBFZMu6x3kAVgwW8gKQa5qSFnMw/WTK=
AT
    JRPekCAwEAAaOCA8IwggO+MA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgEGMB0GA1U=
dD
    gQWBBTmetkWlUrhEp8iCWpDg3glcFLgGTCB2wYDVR0jBIHTMIHQgBQGC/q1+Eh4oyCxCz=
7P
    oNDE0X990KGBsqSBrzCBrDELMAkGA1UEBhMCREUxITAfBgNVBAoTGERldXRzY2hlcyBGb=
3J
    zY2h1bmdzbmV0ejEWMBQGA1UECxMNREZOLUNFUlQgR21iSDEQMA4GA1UECxMHREZOLVBD=
QT
    EtMCsGA1UEAxMkREZOIFRvcGxldmVsIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSEwHwY=
JK
    oZIhvcNAQkBFhJjZXJ0aWZ5QHBjYS5kZm4uZGWCAxXP/TCBpQYDVR0fBIGdMIGaMEugSa=
BH
    hkVodHRwOi8vd3d3LmRmbi1wY2EuZGUvY2VydGlmaWNhdGlvbi94NTA5L2cxL2RhdGEvY=
3J



Klasen, et al.           Expires August 28, 2002               [Page 24]
=0C
Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002


    scy9yb290LWNhLWNybC5jcngwS6BJoEeGRWh0dHA6Ly93d3cuZGZuLXBjYS5kZS9jZXJ0=
aW
    ZpY2F0aW9uL3g1MDkvZzEvZGF0YS9jcmxzL3Jvb3QtY2EtY3JsLmNybDARBglghkgBhvh=
CA
    QEEBAMCAQYwSwYJYIZIAYb4QgEIBD4WPGh0dHA6Ly93d3cuZGZuLXBjYS5kZS9jZXJ0aW=
Zp
    Y2F0aW9uL3BvbGljaWVzL3g1MDlwb2xpY3kuaHRtbDCB+QYJYIZIAYb4QgENBIHrFoHoV=
Gh
    pcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGJ5IHRoZSBERk4tUENBLCB0aGUgVG9wCkxl=
dm
    VsIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IG9mIHRoZSBHZXJtYW4gUmVzZWFyY2gKTmV=
0d
    29yayAoRGV1dHNjaGVzIEZvcnNjaHVuZ3NuZXR6LCBERk4pLgpUaGUga2V5IG93bmVyJ3=
Mg
    aWRlbnRpdHkgd2FzIGF1dGhlbnRpY2F0ZWQgaW4KYWNjb3JkYW5jZSB3aXRoIHRoZSBER=
k4
    tUENBIHg1MDkgUG9saWN5LjA3BglghkgBhvhCAQMEKhYoaHR0cHM6Ly93d3cuZGZuLXBj=
YS
    5kZS9jZ2kvY2hlY2stcmV2LmNnaTBkBgNVHSAEXTBbMFkGCysGAQQB2RqCLAEBMEowSAY=
IK
    wYBBQUHAgEWPGh0dHA6Ly93d3cuZGZuLXBjYS5kZS9jZXJ0aWZpY2F0aW9uL3BvbGljaW=
Vz
    L3g1MDlwb2xpY3kuaHRtbDANBgkqhkiG9w0BAQUFAAOCAQEAU9GmwCW6LwsyHfC241afl=
dq
    j/GULv8mfSkUEpK2OtYU1JAYFzmQx69iweOKHbgXZKZA2Wox+9AydIe98MJCSCOFKYjkz=
gX
    U4fEZbEgnZBo+/1+W2BoB6gFAWy77KVHgimA7AqCcfbObeyCmyfLg1ro8/KpE01OjNr0S=
+E
    fZ3gX9sezjVkCy12HBNQknz/hT2af25UUhyFTcvUY4xvlKAQpla29qyO28sfO93Qhkum6=
SU
    2XPlsKU+3lyqF33Xy84Y2z8ScVlsMuVWbUGtmVshnpT5K91n42pu/f0rLtkZDssEDbcLn=
QD
    LWEz1aUDkLC++4CeFJxC/Dd/SOrE0yR0hNQ=3D

   A sample x509certificate directory entry for an end identity in LDIF
   format:































Klasen, et al.           Expires August 28, 2002               [Page 25]
=0C
Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002


   dn: x509serialNumber=3D1581631808272310054353257112721713,EMAILADDRESS=
=3Dcer
    [e-mail],OU=3DTC TrustCenter Class 1 CA,O=3DTC TrustCe=
nter f
    or Security in Data Networks GmbH,L=3DHamburg,ST=3DHamburg,C=3DDE
   objectclass: x509certficate
   x509version: 2
   x509serialNumber: 1581631808272310054353257112721713
   x509issuer: EMAILADDRESS=[e-mail],OU=3DTC TrustCen=
ter Cl
    ass 1 CA,O=3DTC TrustCenter for Security in Data Networks GmbH,L=3DHa=
mburg,
    ST=3DHamburg,C=3DDE
   x509validityNotBefore: 20011030180757Z
   x509validityNotAfter: 20021030180757Z
   x509subject: EMAILADDRESS=[e-mail],CN=3DNorbert Klase=
n,C=3DDE
   x509subjectPublicKeyInfoAlgorithm: 1.2.840.113549.1.1.1
   mail: [e-mail]
   objectClass: pkiUser
   userCertificate;binary:: MIIDOTCCAqKgAwIBAgIOTfsAAAACxOstmlOu2TEwDQYJK=
oZ
    IhvcNAQEEBQAwgbwxCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQQH=
Ew
    dIYW1idXJnMTowOAYDVQQKEzFUQyBUcnVzdENlbnRlciBmb3IgU2VjdXJpdHkgaW4gRGF=
0Y
    SBOZXR3b3JrcyBHbWJIMSIwIAYDVQQLExlUQyBUcnVzdENlbnRlciBDbGFzcyAxIENBMS=
kw
    JwYJKoZIhvcNAQkBFhpjZXJ0aWZpY2F0ZUB0cnVzdGNlbnRlci5kZTAeFw0wMTEwMzAxO=
DA
    3NTdaFw0wMjEwMzAxODA3NTdaME4xCzAJBgNVBAYTAkRFMRcwFQYDVQQDEw5Ob3JiZXJ0=
IE
    tsYXNlbjEmMCQGCSqGSIb3DQEJARYXbm9yYmVydC5rbGFzZW5AZGFhc2kuZGUwgZ8wDQY=
JK
    oZIhvcNAQEBBQADgY0AMIGJAoGBAL8+XK98p4YjD7Wq7ApmhAN/j2tfVsFCS0ufy12vGp=
Et
    G4ny1tbbBORCJI8vIlDr2/vVTESl6UjzceloVUCib5V855mKUVmLL9Ay4qQLFd4wAoRSP=
Au
    9DkfbR+ygjzaYq+MUKMwaB61sG6911xk/e2/IIq8/IHKrRoYQGmHkaaJpAgMBAAGjgaow=
ga
    cwMwYJYIZIAYb4QgEIBCYWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5=
lc
    zARBglghkgBhvhCAQEEBAMCBaAwXQYJYIZIAYb4QgEDBFAWTmh0dHBzOi8vd3d3LnRydX=
N0
    Y2VudGVyLmRlL2NnaS1iaW4vY2hlY2stcmV2LmNnaS80REZCMDAwMDAwMDJDNEVCMkQ5Q=
TU
    zQUVEOTMxPzANBgkqhkiG9w0BAQQFAAOBgQCrAzuZzLztupeqcHa8OUOcnRuTacMpBEeI=
Cb
    ZMKv6mN9rMYkAxFKerj/yXbdCE8/3X3L00eGj+a8A7PumATiJSfmvYqa4EMZwHC2FFqPx=
Yy
    Aj+xVuSlL5AC4HGHu4SOCp/UJu1xysoD16chOOLpj7+ZWZWLHIjA3zeXwUGl4kFvw=3D=3D=





















Klasen, et al.           Expires August 28, 2002               [Page 26]
=0C
Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002


Appendix B. Sample searches

   This section details how clients should access the certstore.  The
   searches are presented in LDAP URL format.

   Retrieve all certificates for an end entity from a certstore using
   the first DIT structure:

   ldap:///CN=3DNorbert%20Klasen,O=3DDAASI%20International%20GmbH,C=3Dde?=

   	userCertificate;binary?one?(objectClass=3Dx509certificate)

   Find a certificate in a trustcenter's certstore suitable for sending
   an encrypted S/MIME message to "[e-mail]"

   ldap:///O=3DTC%20TrustCenter%20for%20Security%20in%20Data%20Networks
   	%20GmbH,L=3DHamburg,ST=3DHamburg,C=3Dde?userCertificate;binary?sub?
   	(&(objectClass=3Dx509certificate)(mail=[e-mail])
   	 (|(x509keyUsage=3DkeyEncipherment)(x509keyUsage=3DkeyAgreement)
   	   (x509extendedKeyUsage=3D1.3.6.1.5.5.7.3.4)))

   Find a CA certificate by its "subjectKeyIdentifier" obtained from the
   "keyIdentifier" field of the "autorityKeyIdentifier" extension in an
   end entity certificate:

   ldap:///?caCertificate;binary?sub?
   	(&(objectClass=3Dx509certificate)(x509subjectKeyIdentifier=3D%5CE6
   	 %5C7A%5CD9%5C16%5C95%5C4A%5CE1%5C12%5C9F%5C22%5C09%5C6A%5C43%5C83
   	 %5C78%5C25%5C70%5C52%5CE0%5C19))























Klasen, et al.           Expires August 28, 2002               [Page 27]
=0C
Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Klasen, et al.           Expires August 28, 2002               [Page 28]
=0C


--------------090309080904060108090802--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g21IKc804989 for ietf-pkix-bks; Fri, 1 Mar 2002 10:20:38 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g21IKaG04983 for <[e-mail]>; Fri, 1 Mar 2002 10:20:36 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 1 Mar 2002 18:20:19 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id NAA05804; Fri, 1 Mar 2002 13:20:25 -0500 (EST)
Received: from exrsa01.rsa.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g21IKa015889; Fri, 1 Mar 2002 13:20:36 -0500 (EST)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2653.19) id <FVAZCTPS>; Fri, 1 Mar 2002 10:20:35 -0800
Message-ID: <D516C97A440DD31197640008C7EBBE4701B27DCD@EXRSA02>
From: "Yee, Peter" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-acrmf-00.txt
Date: Fri, 1 Mar 2002 10:26:52 -0800 
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>

Stephen,

>What I was thinking was that if you did incorporate that nicely then 
>there'd be no need for LAAP anymore (and since no-one seems to want 
>to produce a new LAAP draft that'd be a happy outcome - if someone
>does, let me know and I'll send you the source).

["that" referring to a mechanism to request an AC be issued under a
pre-agreed policy].

I'm adding a new control attribute which allows the requester to specify
how the requested attribute set may be modified by the AA (or LARA).  One
option will be that the attributes are to be issued according to policy.
I'm putting in a policy OID carrier, but if that (optional) OID is not
present, then I'm specifying that the default procedure is to fallback
to a pre-agreed policy.  A bit hidden in the overall machinations, but
I believe that would cover the LAAP-usage case.  Would that suffice for
your needs?

							-Peter


Received: by above.proper.com (8.11.6/8.11.3) id g21H6X802880 for ietf-pkix-bks; Fri, 1 Mar 2002 09:06:33 -0800 (PST)
Received: from geos.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g21H6VG02875 for <[e-mail]>; Fri, 1 Mar 2002 09:06:31 -0800 (PST)
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 g21H6Mi03656; Fri, 1 Mar 2002 09:06:22 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>, "Housley, Russ" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Validation policy in DPV/DPD rqmts
Date: Fri, 1 Mar 2002 09:03:53 -0800
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)
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>

> -----Original Message-----
> From: Yuriy Dzambasow [mailto:[e-mail]]
>
> Hi Mike,
>
> Although section 7.1 has defined a bunch of MAYs, it
> does say this:
>
> "In order to succeed, one valid certification path
> (i.e., none of the certificates in the path are
> expired or revoked) MUST be found between an
> end-entity certificate and a trust anchor and all
> constraints that apply to the certification path
> MUST be verified."
>
> I think if you say anything more than this you end up
> getting into implementation specific details.

Yuriy,

Probably so on the policy/operational side. It turns out my real
concern has more to do with establishing a floor on the more
algorithmic aspects of path checking, revocation data
referencing and so forth.  Which, at Russ' invitation, I'm
working on at the moment and will later post to the list a
paragraph of proposed text addressing this issue.

Mike




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g21GeaQ00704 for ietf-pkix-bks; Fri, 1 Mar 2002 08:40:36 -0800 (PST)
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 g21GeZG00697 for <[e-mail]>; Fri, 1 Mar 2002 08:40:35 -0800 (PST)
Received: from smtp.digsigtrust.com by smtp1.digsigtrust.com  with ESMTP id g21GeVa01010 for <[e-mail]>; Fri, 1 Mar 2002 09:40:31 -0700 (MST)
Received: from cc474623a (chr152dhcp1050.chrchv01.md.comcast.net [68.33.156.26]) by smtp.digsigtrust.com with SMTP id g21Gc8k03459 for <[e-mail]>; Fri, 1 Mar 2002 09:38:08 -0700 (MST)
Reply-To: <[e-mail]>
From: "Yuriy Dzambasow" <[e-mail]>
To: "PKIX" <[e-mail]>
Subject: Should PDP Be a Separate Specification??
Date: Fri, 1 Mar 2002 11:39:24 -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.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

It seems to me that it would be more beneficial to have a separate
requirements document for the Policy Definition Protocol (PDP) defined in
the DPD/DPV requirements document, than to integrate into the DPD/DPV
document (which also attempts to address DSV policy requirements).  The
benefits of having a separate PDP requirements document are:

- it focuses solely on policy definition to support protocols such as
DPD/DPV/DSV;
- the DPD/DPV/DSV specification can simply reference PDP as needed
- change control on the specifications are simplified (i.e., PDP changes
don't necessarily force changes to DPD/DPV/DSV)

I'd like to hear thoughts from others on this.

Yuriy



Received: by above.proper.com (8.11.6/8.11.3) id g21GU4E00258 for ietf-pkix-bks; Fri, 1 Mar 2002 08:30:04 -0800 (PST)
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 g21GU3G00254 for <[e-mail]>; Fri, 1 Mar 2002 08:30:03 -0800 (PST)
Received: from smtp.digsigtrust.com by smtp1.digsigtrust.com  with ESMTP id g21GTxa00698 for <[e-mail]>; Fri, 1 Mar 2002 09:29:59 -0700 (MST)
Received: from cc474623a (chr152dhcp1050.chrchv01.md.comcast.net [68.33.156.26]) by smtp.digsigtrust.com with SMTP id g21GRYk03202 for <[e-mail]>; Fri, 1 Mar 2002 09:27:34 -0700 (MST)
Reply-To: <[e-mail]>
From: "Yuriy Dzambasow" <[e-mail]>
To: "PKIX" <[e-mail]>
Subject: More Comments on DPD/DPV Requirements
Date: Fri, 1 Mar 2002 11:28:52 -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.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Some additional comments.  I have separated them into the following
categories: editorial and technical.

Editorial (at least I am assuming these are editorial):

1) Recommend deleting the 2nd paragraph on page 5 (Section 5) for the
following reasons:
	- the first sentence attempts to qualify the preceding paragraph, and in my
opinion, adds no additional value
	- the second sentence contains redundant information already defined two
paragraphs above

2) In section 5, 3rd paragraph it says, "...In that case it is acceptable to
pass the parameters from the path discovery policy with each individual
request, i.e. a set of trust anchors..."  Please change the "i.e." to "e.g."

3) Section 8, first paragraph: The text states that a client can use a
request/response pair to define to a server a "..validation policy and/or a
path discovery policy..."  Please change "and/or" to "or".

4) Change title of 8.1.1 to Certification Path Requirements, so that it is
consistent with the text in section 8.1, item 1.

Technical:

Most of my comments have been addressed (or are being addressed on previous
threads).  I have these three additional comments:

1) Why does DPD say that it is OK to pass some policy parameters within a
DPD request if the policy is simple enough (section 5), but just the
opposite is said for DPV (section 4)?  I would think that a simple policy
could be adhered to as well for DPV, and that the parameter specification
could occur within the DPV request.

2) For DPD responses (page 5), why do the first three response types say,
"...according to the path discovery policy...", while the last response type
says, "...according to the path discovery criteria..."?  What is the
difference between policy and criteria?  If there is no difference, then I
recommend changing "criteria" to "policy".

3) Section 8:  I think it would be helpful to break out the PDP requirements
section into two areas: 1) requirements around the coordination of a
validation/path discovery policy between a client and a server to support
the validation/path discovery for a given certificate; and 2) requirements
around defining an authorized policy at a server (e.g., used by security
managers).  This makes it clear that PDP can be used in two distinct ways.





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g21GLeo29566 for ietf-pkix-bks; Fri, 1 Mar 2002 08:21:40 -0800 (PST)
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 g21GLcG29559 for <[e-mail]>; Fri, 1 Mar 2002 08:21:38 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA11242; Fri, 1 Mar 2002 11:21:24 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100300b8a467b2b048@[128.89.88.34]>
In-Reply-To: <058c01c1c0ab$2c86d8e0$020aff0c@tsg1>
References: <20020228012927.CFKS2951.rwcrmhc53.attbi.com@rwcrwbc57> <04ae01c1c061$5f401340$020aff0c@tsg1> <p05100301b8a3f455959c@[128.89.88.34]> <050101c1c074$e8b722e0$020aff0c@tsg1> <p05100305b8a4171bc0f9@[128.89.88.34]> <054b01c1c09e$646263e0$020aff0c@tsg1> <p05100315b8a4527cb463@[128.89.88.34]> <058c01c1c0ab$2c86d8e0$020aff0c@tsg1>
Date: Fri, 1 Mar 2002 11:19:47 -0500
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Validation policy in DPV/DPD rqmts
Cc: "LISTS - 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>

At 2:56 PM -0800 2/28/02, todd glassey wrote:
>Steve
>
>----- Original Message -----
>From: "Stephen Kent" <[e-mail]>
>To: "todd glassey" <[e-mail]>
>Cc: <[e-mail]>
>Sent: Thursday, February 28, 2002 1:37 PM
>Subject: Re: Validation policy in DPV/DPD rqmts
>
>
>>  At 1:24 PM -0800 2/28/02, todd glassey wrote:
>>  >And Steve how many years have you been the WG Chair of this WG?
>>  >
>>  >Todd
>>  >
>>
>>  I've chaired PKIX since it's inception.
>
>My point exactly
>
>>  For comparison, the duration
>>  of my role as chair is less than the amount of time that John Linn
>>  has chaired CAT.
>
>Not a good comparison - CAT is not building technologies to be used in
>commercial transaction standards and you and your WG are, so the work PKIX
>is doing has more than just communications value, it has intrinsic value as
>part of the transaction infrastructrue itself and that is why PKIX is
>different than the other WG's.

you want PKIX to operate under different rules because you perceive 
that its standards apply to a fundamentally different constituency. 
But protocols such as SSH, SSL, S/MIME and IPsec make use of PKIX 
certs and these don't appear to fit your model of "commercial 
transaction standards."  So, the problem, in part, is that your have 
an unduly narrow view of the constituency that PKIX serves.

>  >  also chaired the PEM WG prior to PKIX, chaired
>>  the PSRG in the IRTF for about 10 years, and served on the IAB for
>>  about 10 years.
>
>with the amount of time that you have spent already in this, I have to ask -
>is this is a career for you?

I do lots of things, in addition to standards work, but I view 
standards activities as important and a worthy use of my time. Also, 
I have clients who agree and are willing to pay for me to spend the 
time on these activities. Within BBN I've provided technical 
leadership in developing several generations of network security 
devices, plus secure e-mail systems, high assurance crypto modules, 
CA technology, etc. I also am known as one of the senior Internet 
wine experts and engage in serious nature photography, in my spare 
time ...

>  >
>>  There are no term limits for WG chairs.
>
>WG Chairs are also not voted positions which is equally disturbing and why
>is that do you think? They are in virtually every other formal standards org
>on the planet. So I have to ask - Why not the IETF? is it beyond
>accountability here.

These other standards bodies have formal membership requirements and 
thus have a basis for voting.  the IETF does not, by its own choice, 
vote on these matters.  if you are unhappy with this arrangement, 
perhaps you should consider directing your energies to other 
standards bodies.

>  > If you want to suggest term
>>  limits, bring the topic up on POISED, where the topic is within scope.
>>
>
>I have done exactly that - but POISED has been shut down so I have no choice
>but to bring my petitions for reform of the IETF (and thus this WG) back
>inside this WG...  see the http://www.ietf.org/html.charters/OLD/index.html
>link for evidence of this.
>

See Paul's message.

Steve


Received: by above.proper.com (8.11.6/8.11.3) id g21FrA027747 for ietf-pkix-bks; Fri, 1 Mar 2002 07:53:10 -0800 (PST)
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 g21Fr8G27743 for <[e-mail]>; Fri, 1 Mar 2002 07:53:08 -0800 (PST)
Received: from smtp.digsigtrust.com by smtp1.digsigtrust.com  with ESMTP id g21Fr4a29834; Fri, 1 Mar 2002 08:53:04 -0700 (MST)
Received: from cc474623a (chr152dhcp1050.chrchv01.md.comcast.net [68.33.156.26]) by smtp.digsigtrust.com with SMTP id g21Fodk02495; Fri, 1 Mar 2002 08:50:39 -0700 (MST)
Reply-To: <[e-mail]>
From: "Yuriy Dzambasow" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>
Subject: RE: Comments on the DPV-DPD req doc
Date: Fri, 1 Mar 2002 10:51:57 -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.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I was going to make the same recommendation that Peter has made below, but
instead I will vote FOR the removal of those 2 items.

Yuriy

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Peter Sylvester
Sent: Friday, March 01, 2002 7:48 AM
To: [e-mail]
Subject: Re: Comments on the DPV-DPD req doc




Denis, chairmen, group,

Ambarish asked:
>
> 7. Section 7.1 7th para onwards
>
> I thought the group had recommended against the "cautionary
> period". Are you planning to get rid of these paragraphs?
>
Denis answered:
> [Answer 16]
>
> This section is related to your first comment. This is what makes the
> difference between the time T1, where the key was used and the time T2
where
> the revocation information is available. I would guess that the next IETF
> meeting will be the right place to discuss this issue, ... in corridors
> first.


I think the list is an appropriate place to discuss the issue.

I have the feeling that it has already been settled by the group,
as far as I remember the working group has already decided that
cautionary periods are not a subject of this document.

I will not hang around in the mentioned corridors, even if ...

Anyway, I propose that the chairmen ask for a straw poll concerning actions

1)  "to remove the text in paragraph 7.1 beginning on page 8, starting with
    'There is an inevitable delay ..' up to the end of 7.1"

2)  "to remove point 4 in paragraph 8.1"


I'd vote for removal of the parts.

Thanks in advance to the chairmen for their consideration.

Peter



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g21Fmkq27405 for ietf-pkix-bks; Fri, 1 Mar 2002 07:48:46 -0800 (PST)
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 g21FmiG27401 for <[e-mail]>; Fri, 1 Mar 2002 07:48:44 -0800 (PST)
Received: from smtp.digsigtrust.com by smtp1.digsigtrust.com  with ESMTP id g21Fmea29708; Fri, 1 Mar 2002 08:48:40 -0700 (MST)
Received: from cc474623a (chr152dhcp1050.chrchv01.md.comcast.net [68.33.156.26]) by smtp.digsigtrust.com with SMTP id g21FkDk02386; Fri, 1 Mar 2002 08:46:13 -0700 (MST)
Reply-To: <[e-mail]>
From: "Yuriy Dzambasow" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Ambarish Malpani" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Comments on the DPV-DPD req doc
Date: Fri, 1 Mar 2002 10:47:31 -0500
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)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

...snip...

[COMMENT 10]

1. Section 4 2nd paragraph

If a client is asking a server to validate a certificate at
a particular time, that means "was the certificate valid at that
time" (based on information available at that time or information
obtained later). I don't think we should allow it to mean multiple
things.

[Answer 10]

The question is what means the sentence: "Is the certificate valid
at a time T ? ".  Does it mean:

1) valid when compared to the revocation status information that is
   available at that time T (which may not be up to date) ? , or

2) valid for the time T, where the key was used ?

These two times are not always identical and thus the response is
dependant upon the meaning of that time which is left to the policy.
Yuriy> I agree w/ Ambarish.  Since the meaning of the response is dependent
upon policy, we should not try and define the types of responses here.


[COMMENT 11]

2. Section 4 3rd paragraph

The requirements document should not forbid specification
of the policy with a request. If the protocol writers find that
specifying the policy (or a subset of the policy) with the
request is too burdensome, let them make that decision. Allowing
a client to specify a frequently changing part of the policy
with every request wouldn't be a bad decision

[Answer 11]

Validation policies are usually not defined by end-users but by
administrators. So why a separate protocol should be used, the policy is not
locally defined. Clients should not define policies. As we know, policy
parameters are quite complex.
Yuriy> But clients can specify which trusted roots to use and certain
constraints.  I believe it would be beneficial in some cases (where policy
is easily defined) for a client to specify these things as part of a DPV
request, and not have to make a separate PDP request (which is more suitable
for complex policies).

...snip...

[COMMENT 16]

7. Section 7.1 7th para onwards

I thought the group had recommended against the "cautionary
period". Are you planning to get rid of these paragraphs?

[Answer 16]

This section is related to your first comment. This is what makes the
difference between the time T1, where the key was used and the time T2 where
the revocation information is available. I would guess that the next IETF
meeting will be the right place to discuss this issue, ... in corridors
first.
Yuriy> It seemed pretty clear to me from the poll on the list that
cautionary periods should be removed from this document.  I recommend
removing all text related to cautionary periods.
...snip...

[COMMENT 18]

9. Section 9

Any need to talk about DSV in this document? You aren't really
saying much about it - why mention it?

[Answer 18]

When the text was saying more, some people have been asking to say less.
Since now the text is saying less, you are suggesting more text ? :-)

yuriy> The document abstract says, "This document specifies the requirements
for Delegated Path Validation (DPV) and Delegated Path Discovery (DPD). It
also specifies the requirements for DPV and DPD policy management."  Based
on this, any text regarding DSV should be removed.

...snip...



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g21FTUR26951 for ietf-pkix-bks; Fri, 1 Mar 2002 07:29:30 -0800 (PST)
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 g21FTSi26945 for <[e-mail]>; Fri, 1 Mar 2002 07:29:28 -0800 (PST)
Received: from smtp.digsigtrust.com by smtp1.digsigtrust.com  with ESMTP id g21FTOa29059; Fri, 1 Mar 2002 08:29:24 -0700 (MST)
Received: from cc474623a (chr152dhcp1050.chrchv01.md.comcast.net [68.33.156.26]) by smtp.digsigtrust.com with SMTP id g21FQxk01838; Fri, 1 Mar 2002 08:26:59 -0700 (MST)
Reply-To: <[e-mail]>
From: "Yuriy Dzambasow" <[e-mail]>
To: "Michael Myers" <[e-mail]>, "Housley, Russ" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Validation policy in DPV/DPD rqmts
Date: Fri, 1 Mar 2002 10:28:16 -0500
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)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Mike,

Although section 7.1 has defined a bunch of MAYs, it does say this:

"In order to succeed, one valid certification path (i.e., none of the
certificates in the path are expired or revoked) MUST be found between an
end-entity certificate and a trust anchor and all constraints that apply to
the certification path MUST be verified."

I think if you say anything more than this you end up getting into
implementation specific details.

Yuriy

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Michael Myers
Sent: Thursday, February 28, 2002 5:14 PM
To: Housley, Russ
Cc: [e-mail]
Subject: RE: Validation policy in DPV/DPD rqmts


Russ,

Section 7.1 addresses the issues but not in my opinion to useful
degree of clarity.  Additional work in this area might improve
the document.

Mike



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

> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
> Sent: Thursday, February 28, 2002 12:39 PM
> To: Michael Myers
> Cc: [e-mail]
> Subject: RE: Validation policy in DPV/DPD rqmts
>
>
> Mike:
>
> >OK, I get it now.  It's basically a roots issue.
> >
> >Then perhaps the I-D could include some informative text that
> >expands on what a rational validation policy might likely
> >address.
>
> Is this really something that needs to be in the
> requirements document?
>
> Russ
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g21EFfa22718 for ietf-pkix-bks; Fri, 1 Mar 2002 06:15:41 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g21EFdi22714 for <[e-mail]>; Fri, 1 Mar 2002 06:15:39 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 1 Mar 2002 14:15:21 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA15222 for <[e-mail]>; Fri, 1 Mar 2002 09:15:19 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g21EFTH22233 for <[e-mail]>; Fri, 1 Mar 2002 09:15:29 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <F4N5N7CS>; Fri, 1 Mar 2002 09:13:19 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.66]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F4N5N7C3; Fri, 1 Mar 2002 09:13:14 -0500
From: "Housley, Russ" <[e-mail]>
To: Michael Myers <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 01 Mar 2002 08:26:10 -0500
Subject: RE: Validation policy in DPV/DPD rqmts
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>

Mike:

Please post your suggested text.  Based on your message, it should not need 
to be more than a paragraph.  Did I miss something?

Russ

At 10:22 AM 2/28/2002 -0800, Michael Myers wrote:
>Russ, Denis:
>
>After further thought, I see that what I was actually hunting
>for was that set of requirements leading to, among other things,
>assurance of the existence of path validation logic conformant
>to RFC 2459 among *any* technical specification claiming
>conformance to this requirements specification.
>
>I would count among those, for example, an XML-based approach
>towards satisfying these requirements.  While that technology
>platform is at present out of PKIX' scope, the existence of this
>document enables such claims from a PICS-like perspective.
>
>But if "valid" means whatever the policy OID says it means, we
>could see NULL policies, or something along the lines of "that
>individual is no longer in our customer directory, thus the
>certificate is invalid" without any path checking
>whatsoever--basically treating a certificate hash as nothing
>more than a database index. Or scenarios where a certificate may
>have a NULL subject DN, a non-conformant practice according to
>RFC 2459, but is nonetheless "valid".
>
>I don't think we want that, but I see no requirements that
>prohibit such practices.  I you'd like, I can draft up some
>text.
>
>Mike


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g21CmNZ18223 for ietf-pkix-bks; Fri, 1 Mar 2002 04:48:23 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g21CmLi18219 for <[e-mail]>; Fri, 1 Mar 2002 04:48:21 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA02682 for <[e-mail]>; Fri, 1 Mar 2002 13:48:21 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 1 Mar 2002 13:48:21 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id NAA10268 for <[e-mail]>; Fri, 1 Mar 2002 13:48:19 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id NAA20681 for [e-mail]; Fri, 1 Mar 2002 13:48:19 +0100 (MET)
Date: Fri, 1 Mar 2002 13:48:19 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Comments on the DPV-DPD req doc
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis, chairmen, group,

Ambarish asked:
> 
> 7. Section 7.1 7th para onwards
> 
> I thought the group had recommended against the "cautionary
> period". Are you planning to get rid of these paragraphs?
>  
Denis answered:
> [Answer 16]
> 
> This section is related to your first comment. This is what makes the
> difference between the time T1, where the key was used and the time T2 where
> the revocation information is available. I would guess that the next IETF
> meeting will be the right place to discuss this issue, ... in corridors
> first. 
 

I think the list is an appropriate place to discuss the issue.

I have the feeling that it has already been settled by the group, 
as far as I remember the working group has already decided that 
cautionary periods are not a subject of this document. 

I will not hang around in the mentioned corridors, even if ...
 
Anyway, I propose that the chairmen ask for a straw poll concerning actions

1)  "to remove the text in paragraph 7.1 beginning on page 8, starting with
    'There is an inevitable delay ..' up to the end of 7.1"

2)  "to remove point 4 in paragraph 8.1"


I'd vote for removal of the parts. 
 
Thanks in advance to the chairmen for their consideration.

Peter


Received: by above.proper.com (8.11.6/8.11.3) id g21C70n13589 for ietf-pkix-bks; Fri, 1 Mar 2002 04:07:00 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g21C70i13583 for <[e-mail]>; Fri, 1 Mar 2002 04:07:00 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14835; Fri, 1 Mar 2002 07:06:57 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-okid-01.txt
Date: Fri, 01 Mar 2002 07:06:56 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Out-of-Band Certificate and Key Identifier Protocol 
                          (OCKID)
	Author(s)	: P. Hoffman
	Filename	: draft-ietf-pkix-okid-01.txt
	Pages		: 
	Date		: 28-Feb-02
	
In general, certificates need not be communicated with communication or
storage media that are integrity-secure or authentic. This is because
certificates are digitally signed and users are expected to validate the
signatures using configured trust anchors. However, distribution of
trust anchor certificates, self-signed end-entity certificates, or bare
(unsigned) public keys requires a mechanism for establishing the
authenticity of the certificate or public key.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-okid-01.txt

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

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

--OtherAccess--

--NextPart--