WG last call

[Stephen Kent <[e-mail]>]

A new version of RFC 3770 needs to be issued to address an OID 
assignment collision, for the data item: id-aca-wlanSSID.



The new I-D is: 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3770bis-00.txt


This should not require any discussion, since the only change is 
fixing the duplicate OID assignment, but we want to conduct the Wg 
last call for procedural consistency.

The last call starts today and end on 2/7, a week from now.

Thanks,

Steve




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0SN8Vvn098842; Fri, 28 Jan 2005 15:08:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0SN8Vvt098841; Fri, 28 Jan 2005 15:08:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0SN8UDV098826 for <[e-mail]>; Fri, 28 Jan 2005 15:08:31 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j0SN8Ijf017460 for <[e-mail]>; Fri, 28 Jan 2005 18:08:19 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p06200705be20756bb0ac@[128.89.89.75]>
Date: Fri, 28 Jan 2005 18:08:16 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: WG last call
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / 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>

A new version of RFC 3770 needs to be issued to address an OID 
assignment collision, for the data item: id-aca-wlanSSID.



The new I-D is: 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3770bis-00.txt


This should not require any discussion, since the only change is 
fixing the duplicate OID assignment, but we want to conduct the Wg 
last call for procedural consistency.

The last call starts today and end on 2/7, a week from now.

Thanks,

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0QKWW7J046429; Wed, 26 Jan 2005 12:32:32 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0QKWWIC046428; Wed, 26 Jan 2005 12:32:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0QKWVkx046422 for <[e-mail]>; Wed, 26 Jan 2005 12:32:32 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12289; Wed, 26 Jan 2005 15:32:27 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
Date: Wed, 26 Jan 2005 15:32: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		: Internet X.509 Public Key Infrastructure Authority 
			  Information Access CRL Extension
	Author(s)	: S. Santesson, R. Housley
	Filename	: draft-ietf-pkix-crlaia-00.txt
	Pages		: 7
	Date		: 2005-1-26
	
This document updates RFC 3280 by defining the Authority Information
   Access Certificate Revocation Lists (CRL) extension.  RFC 3280
   defines the Authority Information Access certificate extension using
   the same syntax.  The CRL extension provides a means of discovering
   and retrieving CRL issuer certificates.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-crlaia-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-crlaia-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-crlaia-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-crlaia-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 above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0PL96NC017823; Tue, 25 Jan 2005 13:09:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0PL96DV017822; Tue, 25 Jan 2005 13:09:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0PL95wH017816 for <[e-mail]>; Tue, 25 Jan 2005 13:09:06 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08070; Tue, 25 Jan 2005 16:09:02 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-rfc2511bis-08.txt
Date: Tue, 25 Jan 2005 16:09:02 -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 Certificate 
			  Request Message Format (CRMF)
	Author(s)	: J. Schaad
	Filename	: draft-ietf-pkix-rfc2511bis-08.txt
	Pages		: 33
	Date		: 2005-1-25
	
This document describes the Certificate Request Message Format (CRMF) 
   syntax and semantics.  This syntax is used to convey a request for a 
   certificate to a Certification Authority (CA), possibly via a 
   Registration Authority (RA), for the purposes of X.509 certificate 
   production.  The request will typically include a public key and 
   associated registration information.  This document does not define a 
   certificate request protocol

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-rfc2511bis-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-rfc2511bis-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-rfc2511bis-08.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0PL8U37017783; Tue, 25 Jan 2005 13:08:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0PL8UsL017782; Tue, 25 Jan 2005 13:08:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0PL8TXu017775 for <[e-mail]>; Tue, 25 Jan 2005 13:08:29 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07940; Tue, 25 Jan 2005 16:08:23 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-rfc3770bis-00.txt
Date: Tue, 25 Jan 2005 16:08:23 -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 Extensions and Attributes Supporting 
			  Authentication in Point-to-Point Protocol (PPP) and 
			  Wireless Local Area Networks (WLAN)
	Author(s)	: R. Housley, T. Moore
	Filename	: draft-ietf-pkix-rfc3770bis-00.txt
	Pages		: 10
	Date		: 2005-1-25
	
This document defines two EAP extended key usage values and a public
   key certificate extension to carry Wireless LAN (WLAN) System Service
   identifiers (SSIDs).  This document obsoletes RFC 3770.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-rfc3770bis-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-rfc3770bis-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-rfc3770bis-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-rfc3770bis-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 above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0OMLPaS092182; Mon, 24 Jan 2005 14:21:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0OMLPsw092181; Mon, 24 Jan 2005 14:21:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0OMLKd6092168 for <[e-mail]>; Mon, 24 Jan 2005 14:21:24 -0800 (PST) (envelope-from [e-mail])
Received: from romans (unknown [207.202.179.27]) by smtp2.pacifier.net (Postfix) with ESMTP id D60088282E for <[e-mail]>; Mon, 24 Jan 2005 14:21:17 -0800 (PST)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "IETF-PKIX" <[e-mail]>
Subject: Draft-ietf-pkix-rfc2511bis-08
Date: Mon, 24 Jan 2005 14:31:27 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcThWwept5M0OIEuR8enDSXlEmbtFAhB/doA
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

A new draft of this document has been submitted  All of the issues listed
below have been addressed or removed from the document.  Thoses people who
have CMP implementations need to look carefully at the updated document as I
am sure, not being a CMP guru, that I have changed how things work in some
cases.  This may not affect any current implemenations but I don't know
that.

Except for one issue, this document is ready for last call.  The remaining
issue is to address and pickup any further changes that CMP made to CRMF
without actually specifying it as such.  If anyone knows the rational and
syntax associated with id-regCtrl-altCertTemplate which is partially
specified in the RFC 2510 bis document but not documented please let me
know.  If no one speaks up I will put the syntax into CRMF document and
deprecate it.

jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Jim Schaad
> Sent: Monday, December 13, 2004 1:31 PM
> To: IETF-PKIX
> Subject: Draft-ietf-pkix-rfc2511bis-07
> 
> 
> As advertized this draft is now under new editorship.  As the 
> new editor there are a number of issues that I fill still 
> need to be resolved before this draft can go to last call.  
> If there is no help forth coming then I will be making 
> arbitrary decions on these issue.
> 
> Additionally, if anyone has kept any of the final reports 
> from the interop trials for CMP, I would like to see the 
> sections that relate to CRMF.
> 
> You can easily find the open issues and questions by 
> searching for [[[ in the document.
> 
> 1.  Section 4.1 - I have a partial answer for this question 
> dealing with non DN style names that are authenticated, but 
> are not actually either subject names (DNs) or subject alt 
> names (General Names).  The only real question at this point 
> is should this rational be documented.
> 
> 2.  Section 4.2 - I am worried about the possiblity of 
> somebody copying an encrypted private key being sent to the 
> CA/RA and then copying it into their own certificate request. 
>  They could then later request a key recovery from the CA/RA 
> and get back somebody elses private key.  This is the reason 
> that I am worried about how a POP proof is done here.  One 
> potential answer is to include the authenticated identity 
> along with the private key in the encrypted block.
> 
> 3.  Section 4.2 - We MUST solve the question of what the 
> contents of the encrypted blob look like.  One potential 
> answer is to obsolete thisMessage and reaplace it with an 
> EnvelopedData then all that needs to be covered is the format 
> of the encrypted key plus any POP info required.
> 
> 4.  Section 4.3 - Does the DH section need to be expanded so 
> that any key agreement key pair can be used?  This can be 
> done by adding a MAC alg and value pair to the end of the 
> POPOPrivKey choice (and potentially obsoleting the dhMAC element).
> 
> 5.  Section 4.4 - Two questions regarding guidence for the 
> number of iterations and the amount of salt to be used.  We 
> need a cryptographer to give us some guidelines for these 
> details, or atleast need to set some minimums.
> 
> 6.  Section 6.1 & 6.2 - The content of these controls is not 
> well defined and a couple of questions regarding this are 
> asked.  This may have been addressed in the interop by adding 
> some undocumented restrictions.
> 
> 7.  Section 6.4 - There are a couple of archive questions 
> here.  At this point my inclination is to kill the entire 
> section unless somebody wants to make it acutally work.
> 
> 8.  Section 6.8 - Ditto here.
> 
> 9.  Section 7.1 - Consider the string "Tokens?%30%FA%F3?9%"   
> The parsing is
> difficult (but not impossible) due to the overload of the % token.
> 
> Jim
> 
> 
> 
> 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0O58qDo066087; Sun, 23 Jan 2005 21:08:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0O58oC7066012; Sun, 23 Jan 2005 21:08:50 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j0O58jcf065925 for <[e-mail]>; Sun, 23 Jan 2005 21:08:46 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 7164 invoked by uid 0); 23 Jan 2005 22:31:36 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.35.173) by woodstock.binhost.com with SMTP; 23 Jan 2005 22:31:36 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Sat, 22 Jan 2005 13:11:51 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: RFC 3770 Errata
Cc: [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>

Dear RFC Editor:

Section 4 of RFC 3770 contains a significant error.  There is a 
typographical error in the object identifier.  Please publish this errata 
as soon as possible.

OLD:

    The WLAN SSID attribute certificate attribute is identified by
    id-aca-wlanSSID.

      id-aca  OBJECT IDENTIFIER  ::=  { iso(1) identified-organization(3)
        dod(6) internet(1) security(5) mechanisms(5) pkix(7) 10 }

      id-aca-wlanSSID  OBJECT IDENTIFIER ::= { id-aca 6 }

NEW:

    The WLAN SSID attribute certificate attribute is identified by
    id-aca-wlanSSID.

      id-aca  OBJECT IDENTIFIER  ::=  { iso(1) identified-organization(3)
        dod(6) internet(1) security(5) mechanisms(5) pkix(7) 10 }

      id-aca-wlanSSID  OBJECT IDENTIFIER ::= { id-aca 7 }

This same error is repeated in the ASN.1 Module (Section 8).

OLD:

    id-aca-wlanSSID  OBJECT IDENTIFIER ::= { id-aca 6 }

NEW:

    id-aca-wlanSSID  OBJECT IDENTIFIER ::= { id-aca 7 }

Thanks,
   Russ



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0BF7fmQ041291; Tue, 11 Jan 2005 07:07:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0BF7fvd041290; Tue, 11 Jan 2005 07:07:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from people.com.cn ([202.99.23.227]) by above.proper.com (8.12.11/8.12.9) with SMTP id j0BF7cLo041053 for <[e-mail]>; Tue, 11 Jan 2005 07:07:39 -0800 (PST) (envelope-from [e-mail])
Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm441e4634c; Tue, 11 Jan 2005 23:10:19 +0800
Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmd41df3ffe; Sat, 08 Jan 2005 05:10:01 +0800
Received: from megatron.ietf.org([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm341df6741; Sat, 08 Jan 2005 05:09:59 +0800
Received: from megatron.ietf.org([132.151.6.71]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Sat, 08 Jan 2005 05:09:59 +0800
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn0vU-0004eP-V5; Fri, 07 Jan 2005 15:41:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn0ts-0003my-2S for [e-mail]; Fri, 07 Jan 2005 15:40:00 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21483; Fri, 7 Jan 2005 15:39:54 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
From: [e-mail]
Date: Fri, 07 Jan 2005 15:39:14 -0500
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-certpathbuild-05.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Reply-To: [e-mail]
List-Id: i-d-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>, <mailto:[e-mail]?subject=unsubscribe>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>, <mailto:[e-mail]?subject=subscribe>
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: [e-mail]
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: [e-mail]
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: [e-mail]
X-Auto-Forward: [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>

--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:       
			  Certification Path Building
	Author(s)	: M. Cooper, et al.
	Filename	: draft-ietf-pkix-certpathbuild-05.txt
	Pages		: 77
	Date		: 2005-1-7
	
This document was written to provide guidance and recommendations to 
developers building X.509 public-key certification paths within their 
applications.  By following the guidance and recommendations defined 
in this document, an application developer is more likely to develop 
a robust X.509 certificate enabled application that can build valid 
certification paths across a wide range of PKI environments.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-certpathbuild-05.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-certpathbuild-05.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-certpathbuild-05.txt

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

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


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0AGEfi0039145; Mon, 10 Jan 2005 08:14:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0AGEfZX039144; Mon, 10 Jan 2005 08:14:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0AGEeu4039101 for <[e-mail]>; Mon, 10 Jan 2005 08:14:40 -0800 (PST) (envelope-from [e-mail])
Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1Co25S-0001da-9t; Mon, 10 Jan 2005 11:08:10 -0500
X-test-idtracker: no
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>, pkix mailing list <[e-mail]>, pkix chair <[e-mail]>, pkix chair <[e-mail]>
Subject: Document Action: 'Internet X.509 Public Key Infrastructure:  Certification Path Building' to Informational RFC 
Message-Id: <[e-mail]>
Date: Mon, 10 Jan 2005 11:08:10 -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>

The IESG has approved the following document:

- 'Internet X.509 Public Key Infrastructure: Certification Path Building '
   <draft-ietf-pkix-certpathbuild-05.txt> as an Informational RFC

This document is the product of the Public-Key Infrastructure (X.509) Working 
Group. 

The IESG contact persons are Russ Housley and Sam Hartman.

Technical Summary

  This document provides guidance and recommendations to developers who
  need to build X.509 public-key certification paths within their
  applications.  By following the guidance and recommendations defined
  in this document, an application developer is more likely to develop a
  robust X.509 certificate-enabled application that can build valid
  certification paths in a wide range of PKI environments.

Working Group Summary

  The PKIX Working Group reached consensus on this document.

Protocol Quality

  This document was reviewed by Russ Housley for the IESG.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j07L47Pw095906; Fri, 7 Jan 2005 13:04:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j07L47FR095905; Fri, 7 Jan 2005 13:04:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j07L42pQ095521 for <[e-mail]>; Fri, 7 Jan 2005 13:04:02 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j07L3tjf010093; Fri, 7 Jan 2005 16:03:55 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p06200700be04a628aacd@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 7 Jan 2005 16:03:37 -0500
To: <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Draft-ietf-pkix-rfc2511bis-07
Cc: "IETF-PKIX" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / 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>

Folks,

Jim sent this message in mid-December and I have seen no response on 
the list, so far.  if nobody responds to Jim, Tim and I will 
interpret this as implicit authorization for Jim to proceed as he see 
fit on this topics.

Steve


>As advertized this draft is now under new editorship.  As the new editor
>there are a number of issues that I fill still need to be resolved before
>this draft can go to last call.  If there is no help forth coming then I
>will be making arbitrary decions on these issue.
>
>Additionally, if anyone has kept any of the final reports from the interop
>trials for CMP, I would like to see the sections that relate to CRMF.
>
>You can easily find the open issues and questions by searching for [[[ in
>the document.
>
>1.  Section 4.1 - I have a partial answer for this question dealing with non
>DN style names that are authenticated, but are not actually either subject
>names (DNs) or subject alt names (General Names).  The only real question at
>this point is should this rational be documented.
>
>2.  Section 4.2 - I am worried about the possiblity of somebody copying an
>encrypted private key being sent to the CA/RA and then copying it into their
>own certificate request.  They could then later request a key recovery from
>the CA/RA and get back somebody elses private key.  This is the reason that
>I am worried about how a POP proof is done here.  One potential answer is to
>include the authenticated identity along with the private key in the
>encrypted block.
>
>3.  Section 4.2 - We MUST solve the question of what the contents of the
>encrypted blob look like.  One potential answer is to obsolete thisMessage
>and reaplace it with an EnvelopedData then all that needs to be covered is
>the format of the encrypted key plus any POP info required.
>
>4.  Section 4.3 - Does the DH section need to be expanded so that any key
>agreement key pair can be used?  This can be done by adding a MAC alg and
>value pair to the end of the POPOPrivKey choice (and potentially obsoleting
>the dhMAC element).
>
>5.  Section 4.4 - Two questions regarding guidence for the number of
>iterations and the amount of salt to be used.  We need a cryptographer to
>give us some guidelines for these details, or atleast need to set some
>minimums.
>
>6.  Section 6.1 & 6.2 - The content of these controls is not well defined
>and a couple of questions regarding this are asked.  This may have been
>addressed in the interop by adding some undocumented restrictions.
>
>7.  Section 6.4 - There are a couple of archive questions here.  At this
>point my inclination is to kill the entire section unless somebody wants to
>make it acutally work.
>
>8.  Section 6.8 - Ditto here.
>
>9.  Section 7.1 - Consider the string "Tokens?%30%FA%F3?9%"   The parsing is
>difficult (but not impossible) due to the overload of the % token.
>
>Jim



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j07KdvR5062372; Fri, 7 Jan 2005 12:39:57 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j07Kdvmv062369; Fri, 7 Jan 2005 12:39:57 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j07KduQ5062305 for <[e-mail]>; Fri, 7 Jan 2005 12:39:56 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21483; Fri, 7 Jan 2005 15:39:54 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-certpathbuild-05.txt
Date: Fri, 07 Jan 2005 15:39:14 -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:       
			  Certification Path Building
	Author(s)	: M. Cooper, et al.
	Filename	: draft-ietf-pkix-certpathbuild-05.txt
	Pages		: 77
	Date		: 2005-1-7
	
This document was written to provide guidance and recommendations to 
developers building X.509 public-key certification paths within their 
applications.  By following the guidance and recommendations defined 
in this document, an application developer is more likely to develop 
a robust X.509 certificate enabled application that can build valid 
certification paths across a wide range of PKI environments.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-certpathbuild-05.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-certpathbuild-05.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-certpathbuild-05.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j05CkUcA020799; Wed, 5 Jan 2005 04:46:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j05CkUxA020798; Wed, 5 Jan 2005 04:46:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j05CkRoZ020628 for <[e-mail]>; Wed, 5 Jan 2005 04:46:28 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id NAA51114; Wed, 5 Jan 2005 13:58:51 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005010513455259:171 ; Wed, 5 Jan 2005 13:45:52 +0100 
Message-ID: <[e-mail]>
Date: Wed, 05 Jan 2005 13:46:18 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Trevor Freeman <[e-mail]>
CC: [e-mail]
Subject: Re: SCVP 16 comments deadline
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 01/05/2005 01:45:52 PM, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 01/05/2005 01:45:54 PM, Serialize complete at 01/05/2005 01:45:54 PM
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j05CkUoZ020791
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor,

Here are my responses on 17-45. There are still many major points on which
we do not agree. The MAJOR one has still to do with the deletion of the 
validation ALGORITHM so that all validation POLICY dependant parameters can 
be placed under the validation policy reference.


17. On top of page 7, the relationship between the validation policy and
the basic certification path algorithm is not explained. Then in section
1.4 The concept of validation algorithm is introduced but its relationship
with the validation policy is not explained. This is confusing.

Later on when observing the ASN.1 syntax it may be discovered that two
OIDs are being used:

    - one for the validation policy (ValidationPolRef) and
    - one for the validation algorithm (ValidationAlg).

This is overcomplicated and unnecessary.

[TF] Is there a specific issue with the current draft such as a scenario
which is not addressed ?

[DP] I do not believe that raising this question is a good way to solve my
concern. The “S” from SCVP was supposed to mean “Simple”. The current
description is the description of CCVP ”Complex Certificate Validation
Protocol”. Now, since you asked, CCVP is unable to support the validation
algorithm described in section 6.2 of RFC 3280 (with many trust points, each 
one with its set of parameters). Adding more complexity to
solve it would not be the right answer.

A major simplification is obtained if there is an OID to define the
validation policy while there may be or not be additional parameters.

We sould then have:

   valPolByOID::= SEQUENCE {
         valPolId              OBJECT IDENTIFIER,
         parameters            ANY DEFINED BY ValPolId OPTIONAL }

Specifying a path processing compliant with section 6.1 of RFC 3280 would 
not be possible in the general case, since the current text from RFC 3280
is too vague/ambiguous to support the case where a CRL is *not* signed
by the CA.

It would be desirable to be able to communicate easily and in a standard
way the parameters that may be set in section 6.1 from RFC 3280. In
addition, key usage should be added to that list.

The document should then define a bundle of all these previous useful
parameters and allow for the addition of other parameters.

It is thus proposed to define an OID for a validation policy compliant
with section 6.1 of RFC 3280 (some differences with section 6 from
3280bis, i.e. adding precision, may be expected). It is thus proposed to
modify the text starting from :

" The inputs to the basic certification path processing algorithm used by
SCVP are defined by [PKIX-1] in section 6.1.1 and comprise" up to the end
of section 1.3 with the following:

"For clients able to specify the parameters of a validation policy, it may
be useful to define a standard data structure (using a bundle) able to
support the parameters of the basic certification path processing
algorithm defined by in section 6.1.1 from [PKIX-1] :

    - a set of Trust Anchors (by value or by reference),
    - the initial Certificate Policy set,
    - initial Certificate Policy mapping setting,
    - initial any-Policy setting,
    - initial explicit Certificate Policy setting.
as well as :
    - the usage of the key contained in the certificate (e.g., key
encipherment, key agreement, signature)

This will be done using a bundle which encapsulates all these parameters.
Other application-specific purposes parameters may be added".

18. Section 1.4 is about a "Validation Algorithm". Given what was said
before, the header of this section should be changed. If we make a
subsection 1.3.1 called "1.3.1. General" for encapsulating the previous
text, then we can introduce a new section 1.3.2 called:
"1.3.2. Validation policy according to section 6.1 of RFC 3280"

[TF] See comment to 17
[DP] See my response above.

Some of the text present in the current section 1.4 has been used to build
the new text that is proposed below:

"1.3.2. Validation policy according to section 6.1 of RFC 3280 SCVP
defines a specific validation policy which implements the certification
path validation algorithm as defined in section 6.1 of [PKIX-1]. This
specific validation policy, called "rfc-3280 basic validation policy" uses
the parameters defined in the bundle mentioned above.

Note that this algorithm does not support in its full generality the
algorithm described in section 6.2 of [PKIX-1] since, when more than one
trust anchor is being defined, all the conditions that are specified apply
to all trust anchors, whereas section 6.2 allows to have different
conditions for every trust anchor.

The rfc-3280 basic validation policy may be the default validation policy
supported by the server, but does not need to".

19. Section 2 "Protocol Overview"
In order to allow for interoperability and testing a common protocol needs
to be supported. It should be defined.

[TF] There is plenty of precedence for this to be in a separate document.
CMS itself just defines the syntax.

[DP] Would you be more explicit ?


20. Section 3 "Validation Request"
The unsigned request form is not explained and there is a confusion for
the signed request which indeed authenticates the client and is thus not
anonymous. The current text is :

"A signed request is used to authenticate the client to the server or to
provide an anonymous client integrity over the request-response pair."
It should be rephrased as:

"An unsigned request provides an anonymous client integrity over the
request since the hash of the request or the full request is incorporated
in the response. A signed request is used to authenticate the client to
the server".

[TF] Since by definition the anonymous client has to sign the request as
well this does not make sense. A server can also return a cached response
in which case there is no hash of the request in the response. How about :
An anonymous client signs the request to provide integrity over the
request. A identifiable signs the request to authenticate itself to the
server.

[DP] This does not make sense. If the response is a live response (not
cached) then including the hash of the request in the response is fine and
the request does not need to be signed. If the response is a cached
response, then the cached response must include “sufficient” information
to make sure for the client that it is not a replay from a too old
response. The only way is to copy all the parameters of the original
request. In either case, signing the request does not help.


21. Page 13. Section 3.1.2 "checks"
The following sentence adds nothing and should be removed:
"A server may still choose to perform revocation status checks when
performing path construction, although this information cannot be returned
to the client."

[TF] I think it reinforces that with some checks, don't require revocation
status checking but a server may still elect to do so.

[DP] I disagree. A server SHALL do what the client asks, no more no less.
Please, delete the sentence.


22. Page 15. Section 3.1.3 "wantBack"
The text states:
- Proof of revocation status for each certificate in the AC issuer
certification path;

It would be important to refer the section of the RFC which explains how
to check the "revocation status for each certificate in the AC issuer
certification path".

[TF] OK, I will add a reference to 3281 section 5.

[DP] RFC 3281 is “An Internet Attribute Certificate Profile for
Authorization ». I do not believe that it is the correct reference. The
basic problem is that there exists no RFC that explains how to check the
"revocation status for each certificate in the AC issuer certification
path". So leaving details to the validation policy is the only solution.


23. Page 15. Section 3.1.3 "wantBack"
The text states:
The client can also request a non-cached response to the
request by including wantback id-swb-non-cached-resp in the request.
The default behavior should be the reverse: fresh information is provided,
unless the client accept cached information. The item should be changed
into: id-swb-cached-resp

[TF] This has been moved to response flags and the default is non-cached.
[DP] Fine, finally one point on which we agree.

24. Page 15. Section 3.1.3 "wantBack"
The text states:
id-swb-pkc-all-valid-cert-paths OBJECT IDENTIFIER ::= { id-swb 13}
It should be mentioned that this item is only possible for DPD.

[TF] Why is this only possible with DPD?
[DP] Because DPV returns only the fist valid path (i.e. a single path)


25. Page 16. Section 3.1.4 validationPolicy
The following sentence is talking of an agreement whereas such agreement
does not exist. Delete the sentence:
"The client and server can optionally agree on a set of parameters which
may fully or partially define a validation policy".
[TF] OK


26. Page 16. Section 3.1.4 validationPolicy
The text states:
"If a partial set of parameters has been agreed upon, then the client
supplies a reference to the policy plus whatever parameters are necessary
to complete the request in this item.

This should be replaced with:
"If the validation policy does not define all parameters necessary for
processing an SCVP request, then the client need to supply these
parameters".

[TF] Thats is not true. The client can omit whatever parameters match the
server default value.

[DP] This would mean that the default validation policy always have a full
set of parameters. In that case the quoted sentence is still incorrect
since it states “ a partial set of parameters”. That sentence still needs
to be corrected. What about:” The client supplies a reference to the
policy plus whatever parameters which are allowed to change the default
parameters".

27. Page 16. Section 3.1.4 validationPolicy
    The syntax of the validationPolicy item is defined as:

    ValidationPolicy ::= SEQUENCE {
       validationPolRef          ValidationPolRef,
       validationAlg         [0] ValidationAlg OPTIONAL,
       userPolicySet         [1] SEQUENCE SIZE (1..MAX) OF OBJECT
                                   IDENTIFIER OPTIONAL,
       inhibitPolicyMapping  [2] BOOLEAN OPTIONAL,
       requireExplicitPolicy [3] BOOLEAN OPTIONAL,
       inhibitAnyPolicy      [4] BOOLEAN OPTIONAL,
       isCA                  [5] BOOLEAN OPTIONAL,
       trustAnchors          [6] TrustAnchors OPTIONAL,
       keyUsages             [7] SEQUENCE SIZE (1..MAX) OF KeyUsage
                                    OPTIONAL,
       extendedKeyUsages     [8] ExtKeyUsageSyntax OPTIONAL}

This structure is quite odd, because it only allows to pass additional
parameters as parameters of the validationAlg. Suppressing the
validationAlg item add adding validationParamExtensions would be a simpler
and cleaner way.

[TF] The only way to include other parameters is because the algorithm
needs them. You cannot introduce new parameters without at the same time
defining there use. Therefore mandating additional parameters be passed
which the corresponding identifier for their is the right thing to do.

[DP] I disagree. I could say: the only way to include other parameters is
to place them as parameters of the validation policy because the
validation policy needs them. Your response is placed too early and does
not consider the proposal made just after. See the proposal hereafter and
please reconsider your position. This is one of the major issues.

Each validation policies uses its own parameters. We should have something
like :

ValPolByOID  ::= SEQUENCE {
         valPolgId             OBJECT IDENTIFIER,
         parameters            ANY DEFINED BY valPolId OPTIONAL }

More details follow.

28. It is highly debatable if URIs should be supported or not to reference
a validation policy. URIs are not stable over time and thus unless there
are dereferenced and a hash value is computed over them, it is insecure to
use them. There is a discussion in the security consideration section, but
no warning and no pointer here. If we keep them, we should warn the user.

[TF] The argument over the stability of URIs is discussed in the security
section - which is the appropriate place. The reality is in many
organizations are stable enough and much more manageable. The issue over
dereferencing and hashing is bogus. Both OID and URI are both opaque
stings for this purpose and rely on you trusting the management doing the
right thing.

[DP] Anyway a reference to the security consideration section is missing.
If you believe that a URI is opaque, it should be said, because
dereferencing is very often announced by some people as being an
advantage. You can place that information in the security considerations
section if you wish and then let the IESG decide.

If the WG should decides that they should be supported (and if the IESG
agrees) on page 17, the ASN.1 description should then be:

ValidationPolicy ::= CHOICE {
       valPolByOID         [0] ValPolByOID,
       valPolByURI         [1] ValPolByURI }

ValPolByOID  ::= SEQUENCE {
         valPolgId             OBJECT IDENTIFIER,
         parameters            ANY DEFINED BY valPolId OPTIONAL }

ValPolByURI ::= SEQUENCE {
       uri            IA5String,
       hashAlgo       OBJECT IDENTIFIER,
       hashValue      OCTET STRING}

29. It is proposed to define the following bundle:
ValidationParamBundle ::= SEQUENCE {
       certificatePolicySet      [0] SEQUENCE SIZE (1..MAX) OF
                                     OBJECT IDENTIFIER OPTIONAL,
       inhibitPolicyMapping      [1] BOOLEAN OPTIONAL,
       requireExplicitPolicy     [2] BOOLEAN OPTIONAL,
       inhibitAnyPolicy          [3] BOOLEAN OPTIONAL,
       isCA                      [4] BOOLEAN OPTIONAL,
       trustAnchors              [5] TrustAnchors OPTIONAL,
       keyUsages                 [6] SEQUENCE SIZE (1..MAX) OF
                                     KeyUsage OPTIONAL,
       extendedKeyUsages         [7] ExtKeyUsageSyntax OPTIONAL,
       extensions                [8] EXPLICIT Extensions OPTIONAL }

Note that userPolicySet" is unclear and has been changed into
"certificatePolicySet".

[TF] The use of userPolicySet aligns with 3280. I don't think the name to
the existing structure is ambiguous or misleading.

[DP] Your response arguments about the note but omits to respond to the
main argument of this comment. So I consider that a response to this
comment is still awaited. BTW, userPolicySet is not a term used in RFC
3280, so you cant’t say it aligns with RFC 3280.

The text would need to be aligned with the new structure and, of course
the parameters of the rfc-3280 basic validation policy will simply include
the bundle above as its parameters. It should also be mentioned somewhere
in the document that the support of the rfc-3280 basic validation policy
is not mandatory for conformance but, if supported then the bundle needs
to be supported.

30. Page 17. Section 3.1.5 validationAlg should be deleted.
[TF] Already done

[DP] Let us see what the next text will look like to know whether this
comment is solved or not. I fear it is not.


31. Page 17. Section 3.1.5.1 Default Validation Algorithm should be
deleted and replaced by a section later on the "rfc-3280 basic validation
policy", which should have its OID defined under the scvp tree for OIDs.

[TF] the basic validation algorithm references the 3280 section 6.

[DP] What you call the basic validation algorithm is one of the many
elements of the rfc-3280 basic validation policy. It is buried within the
validation policy and does not need to be identified independently of the
validation policy. The default Validation Algorithm still needs to be
deleted. This relates to comment 17.


32. Page 17. Section 3.1.5.1. Some text of this section might be re-used
to build a new section on the rfc-3280 basic validation policy. Note that
the last sentence at the bottom of page 17, should be removed. This
sentence is: "The default validation policy MUST use the basic validation
algorithm". Any default validation policy can be used.

[TF] See answer to 31
[DP] See my response above.


33. Page 17. Section 3.1.5.2 validationAlg (same title as 3.1.5 !) should
be as well deleted.
[TF] The duplicate has been deleted


34. Page 20. Section 3.1.5.2.3 Name Validation Algorithm
This goal of this section seems to introduce an additional test to the
basic "rfc-3280 basic validation policy". It would come naturally as an
extension of ValidationParamBundle, rather than as a parameter of the
validationAlgo which has been proposed to be removed. The text should be
modified accordingly.

[TF] See answer 27.
[DP] See my response: your response does not consider the proposal made in
comment 27.


35. Page 21. Section 3.1.5.2.3 Name Validation Algorithm
      NameValidationAlgParms ::= SEQUENCE {
         keyPurposeId      KeyPurposeId,
         validationNames   GeneralNames }

This construct is artificial since KeyPurposeId is about the Extended Key
Usage and has nothing to do with name validation.

[TF] Its simple reuses and existing practice.
[DP] I do not understand the argument about “existing practice”.

It could indeed be interesting to test the Extended Key Usage extension of
a certificate, but this should be supported as an extension of
ValidationParamBundle. The text should be modified accordingly.


36. Page 22. Section 3.1.5.3 userPolicySet
userPolicySet should be changed everywhere into certificatePolicySet.

[TF] userPolicySet aligns with 3280 section 6.
[DP] userPolicySet is not a term used in RFC 3280, so you cant’t say it
aligns with RFC 3280 section 6. You are probably reading a different
document.


37. Page 22. Section 3.1.5.3 userPolicySet
The text has many sentences like:
SCVP clients SHOULD support userPolicySet item in requests, and SCVP
servers MUST support userPolicySet item in requests.

These requirements only apply for the rfc-3280 basic validation policy,
and this should be clearly mentioned.

[TF] Since all validation polices contain userPolicySet, it can be in any
policy.

[DP] I disagree. There may be some validation policies where no parameter
at all can be changed by the client. I would expect that most clients will
use OIDs for validation policies with no parameter at all. A client is not
necessarily allowed to change any parameter of a validation policy. In
some cases clients will be allowed to specify only some parameters (but
not all).


38. Page 22. Section 3.1.5.4 inhibitPolicyMapping
The text states:
     By default the server allows policy mapping as
     part of certification path validation.

For simplicity, this should be the reverse. Replace with:

    "By default the server does not perform policy mapping as
     part of certification path validation. If the client wants
     the server to support policy mapping, allowPolicyMapping must
     be set to TRUE in the request".

[TF] This conflicts with 3280 section 6.
[DP] It does not. Section 6 does not mandate policy mapping.
The default is simplicity: no policy mapping.


39. Page 24. Section 3.1.5.8 trustAnchors
The text states:
   "A certificate reference can be used to identify the
     trust anchor by certificate hash and optionally a
     distinguished  name with serial number".

This is not consistent with the ASN.1 definition of PKCReference
which is:
    PKCReference ::= CHOICE {
       cert                   [0] Certificate,
       pkcRef                 [1] ESSCertID }

Please correct.

[DP] A response is missing.


40. Page 25. Section 3.1.6 responseRefHash

The text states:
    "By default, the server includes a hash
    of the request in the response. If the client wants the server
    to include the full request in the response, responseRefHash
    is set to FALSE."

The server shall always include a hash of the request in the response.

[TF] A server cannot include a hash of the request in a cached response.

[DP] See my new response to comment 20. If the response is a live response
(not cached) then including the hash of the request in the response is
fine. If the response is a cached response, then the cached response must
include “sufficient” information to make sure for the client that it is
not a replay from a too old response. The only way is to copy all the
parameters of the original request.

This is an easy way to allow to test the integrity of the request. Since
the full description of the validation policy may be much longer a flag
should be used to say that the full validation policy is not returned
unless requested.

[TF] There is one, it is responseValidationPolByRef. The response flags
now has a FullRequestInResponse in place of the requestRefHash.

[DP] Let us see what the full new proposal is. If you agree with my
response to comment 20, maybe we are converging.


It is thus proposed to have instead the following:

"3.1.6.1 fullRequestInResponse
The fullRequestInResponse controls if the client wants the server to
include the full request in the response. By default,
fullRequestInResponse is set to FALSE. If the client wants back the full
request then it must set this parameter to TRUE. The main reason a client
would request the server to include the full request in the response is to
archive the request-response exchange in a single object.  That is, the
client wants to archive a single object which includes both request and
response".


41. Page 26. Section 3.1.6.2 responseValidationPolByRef
This item should be renamed: fullValPolInResponse
The text should be changed into:

"The fullValPolInResponse controls whether the response includes the
identifier of the validation policy with all the parameters that have been
used by the server, i.e. all the variable parameters independent from the
fact that there were specified by the client or defaulted if not
specified. By default, fullValPolInResponse is set to FALSE. If the client
wants the full validation policy to be included, then fullValPolInResponse
is set to TRUE. The main reason a client would request the server to
include validation policy to be included by value is to archive the
request-response exchange in a single object. That is, the client wants to
archive the CVResponse and have it include every aspect of the validation
policy."

[TF] I have not changed the name, but the section now reads

The responseValidationPolByRef controls whether the response includes just
a reference to the policy or the reference to the policy plus all the
parameters by value of the policy used to process the request. the
response MUST contain references to the validation policy. If the client
wants the validation policy parameters to be also included by value, then
the responseValidationPolByRef is set to FALSE. The main reason a client
would request the server to include validation policy to be included by
value is to archive the request-response exchange in a single object. That
is, the client wants to archive the CVResponse and have it include every
aspect of the validation policy.

[DP] This new proposed text is still incorrect: “just a reference to the
validation policy” does not help, (unless the validation policy has no
variable parameter). We need to have a mechanism for replay protection
and/or for making sure that the response relates to the right request:
“just a reference to the validation policy” does not provide this
property. However, my proposal provides that property. Please reconsider
my text.

The ResponseFlags should be changed as follows:
    ResponseFlags ::= SEQUENCE {
       fullRequestInResponse      BOOLEAN DEFAULT FALSE,
       fullValPolInResponse       BOOLEAN DEFAULT FALSE,
       signResponse               BOOLEAN DEFAULT TRUE }

42. Page 28. Section 3.1.9 intermediateCerts. Minor.
Change:
    The optional intermediateCerts item helps the SCVP server
    create valid certification paths.
into:
    The optional intermediateCerts item may help the SCVP server
    to create valid certification paths.

[TF] Fixed

43. Page 29. Section 3.1.11. producedAt
Last sentence. Change:
    SCVP server SHOULD support the producedAt values in the
    request.
into:
    SCVP server MAY support the producedAt values in the request.

Reason: cached responses should not need to be implemented in
order to be compliant with the specification.

[TF] Fixed


44. Page 32. Section 3.5 dhPublicKey
The text states:
"For the server to compute the shared secret, it must lean the public
values the client generates, therefore the client MUST include this in the
request if it uses this mechanism to integrity protect the request-
response pair."

Replace:

"to integrity protect the request-response pair"

with :

"to authenticate and integrity protect the first response and authenticate
and integrity protect subsequent request-response pairs".

[TF] draft now read " integrity protect the request and the subsequent
response." The use of DH does not necessarily authenticate the request.


45. Page 32. Section 3.6 SCVP Request Authentication
The text states:

"It is a matter of local policy what validation policy is used by the
server when validating requests".

This sentence could be misinterpreted because the word "validating" is
being used. Change into:

It is a matter of local policy what validation policy is used by the
server when authentication requests".

[TF] Fixed

END OF COMMENTS

Denis




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j03NIJiv003917; Mon, 3 Jan 2005 15:18:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j03NIJsx003916; Mon, 3 Jan 2005 15:18:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j03NIEqq003788 for <[e-mail]>; Mon, 3 Jan 2005 15:18:14 -0800 (PST) (envelope-from [e-mail])
Received: from emss03g01.ems.lmco.com (relay3.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.12.10/8.12.10) with ESMTP id j03Kn4UO023339; Mon, 3 Jan 2005 15:49:05 -0500 (EST)
Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1X6 #30875) id <[e-mail]>; Mon, 03 Jan 2005 18:18:16 -0500 (EST)
Received: from EMSS03I00.us.lmco.com ([166.27.250.234]) by lmco.com (PMDF V6.1-1X6 #30875) with ESMTP id <[e-mail]>; Mon, 03 Jan 2005 18:18:15 -0500 (EST)
Received: from EMSS03M09.us.lmco.com ([166.27.250.218]) by EMSS03I00.us.lmco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 03 Jan 2005 18:18:15 -0500
Date: Mon, 03 Jan 2005 18:18:15 -0500
From: "Slone, Skip" <[e-mail]>
Subject: RE: RFC 3280 and multiple Organization (O) fields in DN
To: Russ Housley <[e-mail]>, Jostein Tveit <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Thread-Topic: RFC 3280 and multiple Organization (O) fields in DN
Thread-index: AcTxrM2gobQYvgHRR9yL5c9904aQxQAO4emw
Content-Class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-OriginalArrivalTime: 03 Jan 2005 23:18:15.0473 (UTC) FILETIME=[808F4210:01C4F1EA]
Sender: [e-mail]
Precedence: 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, the annex in question is NOT being dropped -- instead, it is being
updated in the upcoming fifth edition to include domainComponent and to
add the following statement, applicable to the whole annex: "This
example is for illustrative purposes only, and is not intended to limit
the types of names that can be validly constructed in the Directory." 

As mentioned below, it was (and remains) an informative annex, but
common mythology has for years treated it as normative and limiting.
According to the myth, names that include domainComponent RDNs are not
valid X.500 names. Obviously, we on the X.500/X.509 committee disagree
with the myth and would like to see it go away.

Hope this helps,

 -- Skip

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Russ Housley
Sent: Monday, January 03, 2005 9:15 AM
To: Jostein Tveit; [e-mail]
Subject: Re: RFC 3280 and multiple Organization (O) fields in DN


It used to be in Annex B of X.521 (the 1988 version).  Obviously I have
not 
tracked this carefully.  I was told that it was dropped due to the 
confusion that is caused.

Russ


At 03:59 AM 1/3/2005, Jostein Tveit wrote:
>Russ Housley <[e-mail]> writes:
>
> > Early versions of the CCITT (wkich is now called ITU-T) included
> > an informative state machine about name construction.  So many
> > people took the state machine as normative that it was dropped
> > from the later versions of the document to avoid confusion.
>
>Do you mean the state machine in Annex B in X.521?
>If so, it is still in the standard.
>
>--
>Jostein Tveit <[e-mail]>




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j03EJovG017271; Mon, 3 Jan 2005 06:19:50 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j03EJoFL017270; Mon, 3 Jan 2005 06:19:50 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id j03EJj7t017218 for <[e-mail]>; Mon, 3 Jan 2005 06:19:50 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 10713 invoked by uid 0); 3 Jan 2005 14:19:07 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.33.186) by woodstock.binhost.com with SMTP; 3 Jan 2005 14:19:07 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Mon, 03 Jan 2005 09:15:00 -0500
To: Jostein Tveit <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: RFC 3280 and multiple Organization (O) fields in DN
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[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>

It used to be in Annex B of X.521 (the 1988 version).  Obviously I have not 
tracked this carefully.  I was told that it was dropped due to the 
confusion that is caused.

Russ


At 03:59 AM 1/3/2005, Jostein Tveit wrote:
>Russ Housley <[e-mail]> writes:
>
> > Early versions of the CCITT (wkich is now called ITU-T) included
> > an informative state machine about name construction.  So many
> > people took the state machine as normative that it was dropped
> > from the later versions of the document to avoid confusion.
>
>Do you mean the state machine in Annex B in X.521?
>If so, it is still in the standard.
>
>--
>Jostein Tveit <[e-mail]>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j038xcSZ088526; Mon, 3 Jan 2005 00:59:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j038xcou088525; Mon, 3 Jan 2005 00:59:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from bacchus.pvv.ntnu.no (bacchus.pvv.ntnu.no [129.241.210.178]) by above.proper.com (8.12.11/8.12.9) with SMTP id j038xWCY088384 for <[e-mail]>; Mon, 3 Jan 2005 00:59:33 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 47400 invoked by uid 32454); 3 Jan 2005 08:59:31 -0000
To: [e-mail]
Cc: Russ Housley <[e-mail]>
Subject: Re: RFC 3280 and multiple Organization (O) fields in DN
References: <[e-mail]> <[e-mail]>
From: Jostein Tveit <[e-mail]>
Organization: Norwegian University of Science and Technology
Date: Mon, 03 Jan 2005 09:59:31 +0100
In-Reply-To: <[e-mail]> (Russ Housley's message of "Wed, 22 Dec 2004 09:13:04 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix)
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>

Russ Housley <[e-mail]> writes:

> Early versions of the CCITT (wkich is now called ITU-T) included
> an informative state machine about name construction.  So many
> people took the state machine as normative that it was dropped
> from the later versions of the document to avoid confusion.

Do you mean the state machine in Annex B in X.521?
If so, it is still in the standard. 

-- 
Jostein Tveit <[e-mail]>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j035BCv4029020; Sun, 2 Jan 2005 21:11:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j035BAVV029004; Sun, 2 Jan 2005 21:11:10 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j035B5pY028813; Sun, 2 Jan 2005 21:11:05 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.115] (dhcp89-089-115.bbn.com [128.89.89.115]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j0359wjf003765; Mon, 3 Jan 2005 00:09:58 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p061005d3bdf24f5d9a23@[128.89.89.115]>
Date: Mon, 3 Jan 2005 00:13:09 -0500
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], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
From: Karen Seo <[e-mail]>
Subject: 2005 Network and Distributed System Security Symposium (NDSS '05)
Cc: [e-mail]
Content-Type: multipart/alternative; boundary="============_-1107393303==_ma============"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / 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>

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

   ** My apologies if you receive multiple copies of this message. **

                ANNOUNCING THE INTERNET SOCIETY'S
2005 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'05)

February 2, 2005 - Pre Conference Workshop
February 3-4, 2005 - Symposium
Catamaran Resort Hotel, San Diego, California
General Chair:  Eric Harder, National Security Agency
Program co-Chairs: Dan Simon, Microsoft Research
		   Dan Boneh, Stanford University

ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss05/

     The 12th annual NDSS Symposium brings together innovative and
     forward thinking members of the Internet community including
     leading edge security researchers and implementers, globally
     recognized security technology experts, and users from both
     the private and public sectors who design, develop, exploit,
     and deploy the technologies that define network and distributed
     system security.

     NDSS'05 provides a balanced mix of technical papers (with a
     strong emphasis on implementation) that cover new and practical
     approaches to security problems that are endemic to network and
     distributed systems. 

THIS YEAR'S TOPICS INCLUDE:
	* Cryptography in Network Security
	* Denial of Service Attacks,
	* Peer to Peer Approaches
	* Internet Defense
	* Intrusion Detection
	* Platform Security.

FEATURED GUEST SPEAKER:
	* Amit Yoran, who was responsible for coordinating cyber-security
           activities for Homeland Security, will speak on "Security
           Challenges and Opportunities of the Future Enterprise"

PRE CONFERENCE WORKSHOP TOPICS INCLUDE:
	* Security in handling mobility on the internet
	* Security in wireless LANs
	* Security for telephony or voice over IP
	* Trust relations in ad hoc networks
	* Key management strategies to support mobility
	* Security in RFID.
      More information is available at:
         http://www.isoc.org/isoc/conferences/ndss/05/workshop.shtml
      Parties interested in submitting papers should see the above
         web page for directions

REGISTER EARLY FOR BEST PRICING
      Registration for NDSS'05 is now open. Student rates are available
      for both the workshop and symposium. See the web site for more
      information -- http://www.isoc.org/ndss05/  Registration fees:
	*  November 31, 2004-January 10, 2005   $625.
	*  After January 10, 2005               $695.

SPONSORSHIP OPPORTUNITIES AVAILABLE!
      If your organization would like to help support NDSS and gain
      visibility through sponsoring, please contact:
      [e-mail].  Information is also available at   
      http://www.isoc.org/ndss05/


Karen Seo
NDSS'05 Publicity Chair
--============_-1107393303==_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>2005 Network and Distributed System Security
Symposium (ND</title></head><body>
<div>&nbsp; ** My apologies if you receive multiple copies of this
message. **</div>
<div><font color="#000000"><br></font></div>
<div><font
color="#000000"
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; ANNOUNCING THE INTERNET
SOCIETY'S</font></div>
<div><font color="#000000">2005 NETWORK AND DISTRIBUTED SYSTEM
SECURITY SYMPOSIUM (NDSS'05)</font></div>
<div><font color="#000000"><br>
February 2, 2005 - Pre Conference Workshop<br>
February 3-4, 2005 - Symposium<br>
Catamaran Resort Hotel, San Diego, California</font></div>
<div><font color="#000000">General Chair:&nbsp; Eric Harder, National
Security Agency</font></div>
<div><font color="#000000">Program co-Chairs: Dan Simon, Microsoft
Research</font></div>
<div><font
color="#000000"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>&nbsp;&nbsp; Dan Boneh, Stanford University</font></div>
<div><font color="#000000"><br>
ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss05/<br>
<br>
&nbsp;&nbsp;&nbsp; The 12th annual NDSS Symposium brings together
innovative and</font></div>
<div><font color="#000000">&nbsp;&nbsp;&nbsp; forward thinking members
of the Internet community including</font></div>
<div><font color="#000000">&nbsp;&nbsp;&nbsp; leading edge security
researchers and implementers, globally</font></div>
<div><font color="#000000">&nbsp;&nbsp;&nbsp; recognized security
technology experts, and users from both</font></div>
<div><font color="#000000">&nbsp;&nbsp;&nbsp; the private and public
sectors who design, develop, exploit,</font></div>
<div><font color="#000000">&nbsp;&nbsp;&nbsp; and deploy the
technologies that define network and distributed</font></div>
<div><font color="#000000">&nbsp;&nbsp;&nbsp; system
security.</font></div>
<div><font color="#000000"><br>
&nbsp;&nbsp;&nbsp; NDSS'05 provides a balanced mix of technical papers
(with a</font></div>
<div><font color="#000000">&nbsp;&nbsp;&nbsp; strong emphasis on
implementation) that cover new and practical</font></div>
<div><font color="#000000">&nbsp;&nbsp;&nbsp; approaches to security
problems that are endemic to network and</font></div>
<div><font color="#000000">&nbsp;&nbsp;&nbsp; distributed
systems.&nbsp;</font></div>
<div><font color="#000000"><br>
THIS YEAR'S TOPICS INCLUDE:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>* Cryptography in Network
Security<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>* Denial of Service
Attacks,<br>
<x-tab>&nbsp;&nbsp;&nbsp; </x-tab>* Peer to Peer Approaches<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>* Internet
Defense<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>* Intrusion
Detection<br>
<x-tab>&nbsp;&nbsp; </x-tab>* Platform Security.</font><br>
</div>
<div>FEATURED GUEST SPEAKER:</div>
<div><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>* Amit
Yoran, who was responsible for coordinating cyber-security</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; activities
for Homeland Security, will speak on &quot;Security</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Challenges
and Opportunities of the Future Enterprise&quot;</div>
<div><br>
PRE CONFERENCE WORKSHOP TOPICS INCLUDE:<br>
<x-tab> </x-tab>* Security in handling mobility on the internet</div>
<div><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>*
Security in wireless LANs<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>* Security for telephony or
voice over IP<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>* Trust relations
in ad hoc networks<br>
<x-tab>&nbsp;&nbsp;&nbsp; </x-tab>* Key management strategies to
support mobility</div>
<div><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>*
Security in RFID.</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp; More information is available at:</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
http://www.isoc.org/isoc/conferences/ndss/05/workshop.shtml</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp; Parties interested in submitting papers
should see the above</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; web page for
directions</div>
<div><font color="#000000"><br></font></div>
<div><font color="#000000">REGISTER EARLY FOR BEST
PRICING</font></div>
<div><font color="#000000">&nbsp;&nbsp;&nbsp;&nbsp; Registration for
NDSS'05 is now open. Student rates are available</font></div>
<div><font color="#000000">&nbsp;&nbsp;&nbsp;&nbsp; for both the
workshop and symposium. See the web site for more</font></div>
<div><font color="#000000">&nbsp;&nbsp;&nbsp;&nbsp; information
--&nbsp;</font><font
color="#0000FF"><u>http://www.isoc.org/ndss05/</u></font><font
color="#000000">&nbsp; Registration fees:</font></div>
<div><font
color="#000000"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>*&nbsp; November 31, 2004-January 10, 2005&nbsp;&nbsp;
$625.</font></div>
<div><font
color="#000000"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>*&nbsp; After January 10,
2005&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp; $695.</font></div>
<div><font color="#000000"><br>
SPONSORSHIP OPPORTUNITIES AVAILABLE!</font></div>
<div><font color="#000000">&nbsp;&nbsp;&nbsp;&nbsp; If your
organization would like to help support NDSS and gain</font></div>
<div><font color="#000000">&nbsp;&nbsp;&nbsp;&nbsp; visibility through
sponsoring, please contact:</font></div>
<div><font color="#000000">&nbsp;&nbsp;&nbsp;&nbsp;
[e-mail].&nbsp; Information is also available
at&nbsp;&nbsp;&nbsp;</font></div>
<div><font color="#000000">&nbsp;&nbsp;&nbsp;&nbsp;
http://www.isoc.org/ndss05/</font></div>
<div><br></div>
<div><br></div>
<div>Karen Seo</div>
<div>NDSS'05 Publicity Chair</div>
</body>
</html>
--============_-1107393303==_ma============--