Re: Question about the edition of RFC 3280

[Peter Sylvester <[e-mail]>]

hi Denis,

Do you have some result? 

regards
Peter


> Date: Thu, 10 Apr 2003 10:54:54 +0200
> From: Denis Pinkas <[e-mail]>
> 
> Stefan,
> 
> Thank you for the response.
> 
> I realize that very unfortunately both the sender of the message and the 
> receivers of the message lost the message. :-|
> 
> Now, looking forward, I would like to make the following proposal:
> 
> Next week there is the RSA 2003 Security Conference. I will attend the 
> Conference and I guess may other people from the PKIX WG will do so as well.
> 
> Since there is the speaker's dinner on the Tuesday and the Gala Dinner of 
> the Wednesday, I propose to have an informal meeting about key usage bits 0 
> and 1 on the Monday evening for anyone interrested.
> 
> I thus propose to meet in the North Lobby, in front of the registration 
> desks at 5:30 p.m. on the Monday evening.
> 
> I would like to discuss the meaning of a certificate that has:
> 
>   1° only the key usage bit 1 set,
>   2° only the key usage bit 0 set,
>   3° both the key usage bits 0 and 1 set.
> 
>    ... when looking at the writing of RFC 2459 and
>        when looking at the writing of RFC 3280.
> 
> Denis
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UGFKi2084019 for <[e-mail]>; Wed, 30 Apr 2003 09:15:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UGFKMx084018 for ietf-pkix-bks; Wed, 30 Apr 2003 09:15:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UGFIi2084008 for <[e-mail]>; Wed, 30 Apr 2003 09:15:19 -0700 (PDT) (envelope-from [e-mail])
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA08403 for <[e-mail]>; Wed, 30 Apr 2003 18:15:12 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.6); Wed, 30 Apr 2003 18:15:12 +0200 (MET DST)
Received: (from sylvest@localhost) by champagne.edelweb.fr (8.7.6/8.6.6) id SAA11650 for [e-mail]; Wed, 30 Apr 2003 18:15:06 +0200 (MET DST)
Date: Wed, 30 Apr 2003 18:15:06 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Question about the edition of RFC 3280
Sender: [e-mail]
Precedence: 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 Denis,

Do you have some result? 

regards
Peter


> Date: Thu, 10 Apr 2003 10:54:54 +0200
> From: Denis Pinkas <[e-mail]>
> 
> Stefan,
> 
> Thank you for the response.
> 
> I realize that very unfortunately both the sender of the message and the 
> receivers of the message lost the message. :-|
> 
> Now, looking forward, I would like to make the following proposal:
> 
> Next week there is the RSA 2003 Security Conference. I will attend the 
> Conference and I guess may other people from the PKIX WG will do so as well.
> 
> Since there is the speaker's dinner on the Tuesday and the Gala Dinner of 
> the Wednesday, I propose to have an informal meeting about key usage bits 0 
> and 1 on the Monday evening for anyone interrested.
> 
> I thus propose to meet in the North Lobby, in front of the registration 
> desks at 5:30 p.m. on the Monday evening.
> 
> I would like to discuss the meaning of a certificate that has:
> 
>   1° only the key usage bit 1 set,
>   2° only the key usage bit 0 set,
>   3° both the key usage bits 0 and 1 set.
> 
>    ... when looking at the writing of RFC 2459 and
>        when looking at the writing of RFC 3280.
> 
> Denis
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TDsVi2091065 for <[e-mail]>; Tue, 29 Apr 2003 06:54:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TDsVqd091064 for ietf-pkix-bks; Tue, 29 Apr 2003 06:54:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.8p1/8.12.8) with SMTP id h3TDsUi2091057 for <[e-mail]>; Tue, 29 Apr 2003 06:54:30 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 15591 invoked by uid 0); 29 Apr 2003 13:53:39 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (206.246.84.113) by woodstock.binhost.com with SMTP; 29 Apr 2003 13:53:39 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 29 Apr 2003 09:53:45 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: draft-ietf-pkix-rfc2511bis
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<html>
<body>
I am concerned about the change that is illustrated below (please excuse
the HTML).<br><br>
<pre>&nbsp;&nbsp; -- Registration Info in CRMF
&nbsp;&nbsp; id-regInfo&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OBJECT
IDENTIFIER ::= { id-pkip id-regInfo(2) }
&nbsp;&nbsp;
<font face="Courier New, Courier" color="#FF0000">id-regInfo-asciiPairs
</s></font>&nbsp;&nbsp;
<font face="Courier New, Courier" color="#008000">id-regInfo-utf8Pairs</b></font>&nbsp;&nbsp;&nbsp;
OBJECT IDENTIFIER ::= { id-regInfo 1 }
&nbsp;&nbsp; --with syntax
<font face="Courier New, Courier" color="#FF0000">OCTET STRING</s></font>
<font face="Courier New, Courier" color="#008000">UTF8STRING
</b></font>&nbsp;&nbsp; id-regInfo-certReq&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OBJECT IDENTIFIER ::= { id-regInfo 2 }
&nbsp;&nbsp; --with syntax CertRequest

</pre>First, I am concerned about the change in the semantics associated with an OID that was assigned a long time ago.&nbsp; This could lead to interoperability issues.&nbsp; Why would we change the semantics of an existing OID instead of assigning a new OID.<br><br>
Second, this change does not show up in the ASN.1 module.&nbsp; Why are the OIDs not part of the ASN.1 module?<br><br>
Russ</body>
</html>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3SBTmt2094371 for <[e-mail]>; Mon, 28 Apr 2003 04:29:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3SBTmKr094370 for ietf-pkix-bks; Mon, 28 Apr 2003 04:29:48 -0700 (PDT)
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.8p1/8.12.8) with ESMTP id h3SBTkt2094353 for <[e-mail]>; Mon, 28 Apr 2003 04:29:47 -0700 (PDT) (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 HAA27058; Mon, 28 Apr 2003 07:26:57 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ipki-new-rfc2527-02.txt
Date: Mon, 28 Apr 2003 07:26:57 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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 
                          Policy and Certification Practices Framework
	Author(s)	: S. Chokhani et al.
	Filename	: draft-ietf-pkix-ipki-new-rfc2527-02.txt
	Pages		: 81
	Date		: 2003-4-25
	
This document presents a framework to assist the writers of 
certificate policies or certification practice statements for 
participants within public key infrastructures, such as 
certification authorities, policy authorities, and communities of 
interest that wish to rely on certificates.  In particular, the 
framework provides a comprehensive list of topics that potentially 
(at the writer's discretion) need to be covered in a certificate 
policy or a certification practice statement.  This document is 
being submitted to the RFC Editor with a request for publication as 
an Informational RFC.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ipki-new-rfc2527-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-ipki-new-rfc2527-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-ipki-new-rfc2527-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-ipki-new-rfc2527-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ipki-new-rfc2527-02.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 [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3Q0evt2034465 for <[e-mail]>; Fri, 25 Apr 2003 17:40:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3Q0ev7c034464 for ietf-pkix-bks; Fri, 25 Apr 2003 17:40:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3Q0eut2034459 for <[e-mail]>; Fri, 25 Apr 2003 17:40:56 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.136]) by mailout.fastq.com (8.11.6/8.11.3.FastQ-MailOut) with SMTP id h3Q0evV11680; Fri, 25 Apr 2003 17:40:57 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Russ Housley" <[e-mail]>, <[e-mail]>
Subject: RE: draft-ietf-pkix-pi
Date: Fri, 25 Apr 2003 17:46:17 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
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>

>
>IdentifierType ::= CHOICE {
>    registeredOID         OBJECT IDENTIFIER,
>    uri                   IA5String }

Russ,

Please clarify.  Is the IESG saying the WG MUST eliminate the
CHOICE and so select a single type?

Mike







Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3PJ99t2023077 for <[e-mail]>; Fri, 25 Apr 2003 12:09:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3PJ99AV023076 for ietf-pkix-bks; Fri, 25 Apr 2003 12:09:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from maild.telia.com (maild.telia.com [194.22.190.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3PJ98t2023065 for <[e-mail]>; Fri, 25 Apr 2003 12:09:08 -0700 (PDT) (envelope-from [e-mail])
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by maild.telia.com (8.12.9/8.12.9) with SMTP id h3PJ907G010376; Fri, 25 Apr 2003 21:09:00 +0200 (CEST)
X-Original-Recipient: [e-mail]
Message-ID: <011601c30b64$d95c3600$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, "Russ Housley" <[e-mail]>
References: <[e-mail]>
Subject: Re: draft-ietf-pkix-pi
Date: Fri, 25 Apr 2003 21:57:06 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
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>

Russ,

I think the crux is really that the draft talks about a 
"type of permanent identifier" but does not explain what
that means.

My interpretation:

   IdentifierType denotes a globally distinct name space 
   where the corresponding IdentifierValue has a meaning.
   In addition, IdentifierType can in certain issuances be
   associated with a specific type of end-entity like
   "citizen",  "employee", "device", "account", etc.

Computer software looking for a type (=name space) would usually
only treat URIs and OIDs as strings or blobs without any interpretation,
which IMHO means that they are (in this respect) to be considered as
"functionally equivalent".  This is further proved by the fact that an
OID can be recasted into a URI: http://www.ietf.org/rfc/rfc3061.txt.

But if I were to select, I would go for URIs alone, as:
1. URIs are more or less human-readable
2. URIs based on HTTP or HTTPS are potentially browsable (bonus)
3. Most organizations already own one or more domain names, 
    while only a fraction have an OID arc
4. Namespaces as featured in XML only use URIs

OIDs seem well suited for "internal" types like identifying
certificate extensions.  Names however, are typically
rather "visible" and "external" properties.

Anders

----- Original Message ----- 
From: "Russ Housley" <[e-mail]>
To: <[e-mail]>
Sent: Friday, April 25, 2003 15:37
Subject: draft-ietf-pkix-pi



Dear PKIX WG:

The IESG has been discussing the draft-ietf-pkix-pi document, and I need 
some information to bring the discussion to closure.

The document allows the naming authority to be identified in several 
different ways.  The following chunk of ASN.1 from the document illustrates 
the point:

      PermanentIdentifier ::=     SEQUENCE {
         identifierValue              IdentifierValue,
         identifierType               IdentifierType OPTIONAL,
         matchingRule        [0]      IMPLICIT OBJECT IDENTIFIER OPTIONAL
      }

      IdentifierValue ::= CHOICE {
             iA5String            IA5String,
             uTF8String           UTF8String
      }

      IdentifierType ::= CHOICE {
             registeredOID                   OBJECT IDENTIFIER,
             uri                             IA5String
      }

The pros and cons of OIDs and URIs have been discussed in the IESG.  In 
practice, they are not used in the same manner.

Some people are uncomfortable with OIDs. For one thing, there is no 
straightforward way of getting to know anything more about them than the 
values of their numbers, which give no hint of the context in which they 
were assigned.

Some people are uncomfortable with URIs. Their content is subject to 
various interpretations, and people sometimes make unreasonable guesses 
based on the strings embedded in the URI.

Is there a community that wants each naming alternative?

Russ




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3PDbnt2003460 for <[e-mail]>; Fri, 25 Apr 2003 06:37:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3PDbnKl003459 for ietf-pkix-bks; Fri, 25 Apr 2003 06:37:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.8p1/8.12.8) with SMTP id h3PDbmt2003454 for <[e-mail]>; Fri, 25 Apr 2003 06:37:48 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 3913 invoked by uid 0); 25 Apr 2003 13:37:09 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.190.15) by woodstock.binhost.com with SMTP; 25 Apr 2003 13:37:09 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Fri, 25 Apr 2003 09:37:32 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: draft-ietf-pkix-pi
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 PKIX WG:

The IESG has been discussing the draft-ietf-pkix-pi document, and I need 
some information to bring the discussion to closure.

The document allows the naming authority to be identified in several 
different ways.  The following chunk of ASN.1 from the document illustrates 
the point:

      PermanentIdentifier ::=     SEQUENCE {
         identifierValue              IdentifierValue,
         identifierType               IdentifierType OPTIONAL,
         matchingRule        [0]      IMPLICIT OBJECT IDENTIFIER OPTIONAL
      }

      IdentifierValue ::= CHOICE {
             iA5String            IA5String,
             uTF8String           UTF8String
      }

      IdentifierType ::= CHOICE {
             registeredOID                   OBJECT IDENTIFIER,
             uri                             IA5String
      }

The pros and cons of OIDs and URIs have been discussed in the IESG.  In 
practice, they are not used in the same manner.

Some people are uncomfortable with OIDs. For one thing, there is no 
straightforward way of getting to know anything more about them than the 
values of their numbers, which give no hint of the context in which they 
were assigned.

Some people are uncomfortable with URIs. Their content is subject to 
various interpretations, and people sometimes make unreasonable guesses 
based on the strings embedded in the URI.

Is there a community that wants each naming alternative?

Russ



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OEGBt2006241 for <[e-mail]>; Thu, 24 Apr 2003 07:16:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OEGAKE006240 for ietf-pkix-bks; Thu, 24 Apr 2003 07:16:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OEG6t2006229; Thu, 24 Apr 2003 07:16:07 -0700 (PDT) (envelope-from [e-mail])
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id h3OEAF232759; Thu, 24 Apr 2003 15:10:15 +0100
Received: from  ([10.153.25.53]) by Baltimore-FW1; Thu, 24 Apr 2003 15:11:11 +0100 (BST)
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]>; Thu, 24 Apr 2003 15:15:28 +0100
Received: from  ([10.153.25.10]) by Baltimore-FW1; Thu, 24 Apr 2003 15:11:08 +0100 (BST)
Received: from baltimore.ie (wks218-25.ie.baltimore.com [10.153.25.218]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id PAA26986; Thu, 24 Apr 2003 15:16:00 +0100
Message-ID: <[e-mail]>
Date: Thu, 24 Apr 2003 15:15:37 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Shivaram Mysore <[e-mail]>, xme <[e-mail]>
Subject: XML Key Management Specification Last Call - need review/feedback
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>

Dear IETF security folks,

Firstly, apologies if (or when) you get more than one copy of this.

On behalf of the W3C XML Key Managment Service WG [XKMS-WG], we are
pleased to announce the publication of the "XML Key Management Specification"
Last Call Working Draft.  This is one of the deliverables of the WG.  The
document address is:

  http://www.w3.org/TR/2003/WD-xkms2-20030418/Overview.html
  http://www.w3.org/TR/2003/WD-xkms2-bindings-20030418/Overview.html

The Last Call review period will end on 23 May, 2003. Please send review
comments by that date to the editor - [e-mail] and cc:
[e-mail]

Thanks,
Stephen.

[XKMS-WG]  http://www.w3.org/2001/XKMS


-- 
____________________________________________________________
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 above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MLZnt2046930 for <[e-mail]>; Tue, 22 Apr 2003 14:35:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MLZnI4046928 for ietf-pkix-bks; Tue, 22 Apr 2003 14:35:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nic.lp.se (nic.lp.se [212.247.5.91]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MLZlt2046920 for <[e-mail]>; Tue, 22 Apr 2003 14:35:48 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (212.247.5.91) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Tue, 22 Apr 2003 23:34:16 +0200
Date: Tue, 22 Apr 2003 23:31:46 +0200 (CEST)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: Question about Version-1 X509 Certificates
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <001201c308bd$c6592d00$1100a8c0@ascertia3>
References: <001201c308bd$c6592d00$1100a8c0@ascertia3>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.2.2, Mew version 3.2
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 3.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
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>

In message <001201c308bd$c6592d00$1100a8c0@ascertia3> on Tue, 22 Apr 2003 15:56:02 +0500, "Yasir Khan" <[e-mail]> said:

Yasir.Khan> How can we check that a version 1 X509 certificate is a CA
Yasir.Khan> certificate or an End-User certificate. In version 1
Yasir.Khan> certificates, we dont have BasicConstraints and KeyUsage
Yasir.Khan> Extension. Any help on this issue would be appreciated.

There is no way.  It isn't recommended to produce v1 certificates, for
that reason among others.

-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MKvNt2045307 for <[e-mail]>; Tue, 22 Apr 2003 13:57:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MKvNed045306 for ietf-pkix-bks; Tue, 22 Apr 2003 13:57:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mpls-qmqp-04.inet.qwest.net (mpls-qmqp-04.inet.qwest.net [63.231.195.115]) by above.proper.com (8.12.8p1/8.12.8) with SMTP id h3MKvMt2045298 for <[e-mail]>; Tue, 22 Apr 2003 13:57:22 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 59054 invoked by uid 0); 22 Apr 2003 20:44:59 -0000
Received: from mpls-pop-04.inet.qwest.net (63.231.195.4) by mpls-qmqp-04.inet.qwest.net with QMQP; 22 Apr 2003 20:44:59 -0000
Received: from vdsl-130-13-127-251.phnx.uswest.net (HELO ?192.168.2.7?) (130.13.127.251) by mpls-pop-04.inet.qwest.net with SMTP; 22 Apr 2003 20:57:23 -0000
Date: Tue, 22 Apr 2003 13:57:13 -0700
Message-Id: <a05210601bacb55fa0fca@[192.168.2.7]>
From: "Hoyt L. Kesterson II" <[e-mail]>
To: [e-mail]
Mime-Version: 1.0
X-Sender: [e-mail]@mail.earthlink.net
In-Reply-To: <001201c308bd$c6592d00$1100a8c0@ascertia3>
References: <001201c308bd$c6592d00$1100a8c0@ascertia3>
Subject: Re: Question about Version-1 X509 Certificates
Content-Type: text/html; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<!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: Question about Version-1 X509
Certificates</title></head><body>
<div>version 1 certificates were specified in a more innocent world.
although we did categorized revocations into CA and user, there was no
way specified in the standard to state in a certificate the
restrictions on the use of that certificate. follow on work such as
PEM (privacy enhanced mail) demonstrated the need to flexibly specify
constraints.</div>
<div><br></div>
<div>that was the reason we developed the extension mechanism. as you
have noticed, that mechanism requires that the certificate be version
3. basic constraints was one of the first extensions defined.</div>
<div><br></div>
<div>one could use other mechanisms such as out-of-band agreements and
signal restrictions by the name but that is out of the scope of
x.509</div>
<div><br></div>
<div>&nbsp; hoyt</div>
<div><br></div>
<div>At 15:56 +0500 4/22/03, Yasir Khan wrote:</div>
<blockquote type="cite" cite><font face="Arial" size="-1"
color="#800080">Hi All,</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1"
color="#800080">How can we check that a version 1 X509 certificate is
a CA certificate or an End-User certificate. In version 1
certificates, we dont have BasicConstraints and KeyUsage Extension.
Any help on this issue would be appreciated.</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1"
color="#800080">Best Regards,</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1"
color="#800080">Yasir Khan</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<div><br></div>
</body>
</html>


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MAwft2013450 for <[e-mail]>; Tue, 22 Apr 2003 03:58:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MAwfOw013449 for ietf-pkix-bks; Tue, 22 Apr 2003 03:58:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.worldcall.net.pk ([203.81.192.10]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MAwQt2013431 for <[e-mail]>; Tue, 22 Apr 2003 03:58:35 -0700 (PDT) (envelope-from [e-mail])
Received: from ascertia3 ([203.81.195.235]) by ns3.worldcall.net.pk (8.12.8+Sun/8.12.2) with SMTP id h3MA1Vot015638 for <[e-mail]>; Tue, 22 Apr 2003 16:01:32 +0600 (PKST)
Message-ID: <001201c308bd$c6592d00$1100a8c0@ascertia3>
From: "Yasir Khan" <[e-mail]>
To: <[e-mail]>
Subject: Question about Version-1 X509 Certificates
Date: Tue, 22 Apr 2003 15:56:02 +0500
Organization: Ascertia Limited.
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C308E7.ACF0B6B0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
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>

This is a multi-part message in MIME format.

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

Hi All,

How can we check that a version 1 X509 certificate is a CA certificate =
or an End-User certificate. In version 1 certificates, we dont have =
BasicConstraints and KeyUsage Extension. Any help on this issue would be =
appreciated.

Best Regards,
Yasir Khan


=20

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3502.5390" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#800080 face=3DArial size=3D2>Hi All,</FONT></DIV>
<DIV><FONT color=3D#800080 face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#800080 face=3DArial size=3D2>How can we check that a =
version 1=20
X509 certificate is a CA certificate or an End-User certificate. In =
version 1=20
certificates, we dont have BasicConstraints and KeyUsage Extension. =
</FONT><FONT=20
color=3D#800080 face=3DArial size=3D2>Any help on this issue would be=20
appreciated.</FONT></DIV>
<DIV><FONT color=3D#800080 face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#800080 face=3DArial size=3D2>Best =
Regards,</FONT></DIV>
<DIV><FONT color=3D#800080 face=3DArial size=3D2>Yasir Khan</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_000F_01C308E7.ACF0B6B0--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3LFSWt2050408 for <[e-mail]>; Mon, 21 Apr 2003 08:28:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3LFSW5m050407 for ietf-pkix-bks; Mon, 21 Apr 2003 08:28:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3LFSUt2050396 for <[e-mail]>; Mon, 21 Apr 2003 08:28:31 -0700 (PDT) (envelope-from [e-mail])
Received: from VON-TP-T30 (terra.mcs.anl.gov [140.221.11.103]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id h3LFSP5183866; Mon, 21 Apr 2003 10:28:25 -0500
X-Mailer: 21.4 (patch 11) "Native Windows TTY Support (Windows)" XEmacs Lucid (via feedmail 10 I); VM 7.07 under 21.4 (patch 11) "Native Windows TTY Support (Windows)" XEmacs Lucid
From: "Von Welch" <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Mon, 21 Apr 2003 10:29:20 -0500
To: [e-mail]
Subject: Fwd: I-D ACTION:draft-ietf-pkix-proxy-05.txt
Sender: [e-mail]
Precedence: 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 wanted to bring the new Proxy Cert draft to the attention of the
group. We've made some improvemnets based on questions, corrections
and feedback from Jim Schaad and David Chadwick (a full changelog is
in the document) and at this point belive we've addressed all their
comments.

Von

------- start of forwarded message -------
Reply-to: [e-mail]
From: [e-mail]
To: IETF-Announce: ;
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-proxy-05.txt
Date: Fri, 18 Apr 2003 07:16:08 -0400


--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-05.txt
	Pages		: 45
	Date		: 2003-4-17
	
This document forms a certificate profile for Proxy 
Certificates, based on X.509 PKI certificates as defined 
in RFC 3280, 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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-proxy-05.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-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-proxy-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-proxy-05.txt

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

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

--OtherAccess--

--NextPart--


------- end of forwarded message -------



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3LB9rt2036619 for <[e-mail]>; Mon, 21 Apr 2003 04:09:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3LB9rUQ036618 for ietf-pkix-bks; Mon, 21 Apr 2003 04:09:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from vmmr8.verisignmail.com (vmmrnat.verisignmail.com [216.168.230.187]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3LB9qt2036609 for <[e-mail]>; Mon, 21 Apr 2003 04:09:52 -0700 (PDT) (envelope-from [e-mail])
Received: from ms1.verisignmail.com (ms1.verisignmail.com [216.168.230.167] (may be forged)) by vmmr8.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id AKA30188; Mon, 21 Apr 2003 07:09:51 -0400 (EDT)
Received: from laptop-cpq.retrospekt.com (1Cust193.tnt15.stk3.swe.da.uu.net [213.116.222.193]) by ms1.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id AEF95291; Mon, 21 Apr 2003 07:09:49 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]@mail.retrospekt.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 21 Apr 2003 13:09:37 +0200
To: "Roberto Opazo" <[e-mail]>, <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: New ideas for PIs
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>

Roberto,

RFC 3039 has basically the functionality you ask for.
RFC 3039 specifies a mechanism where you can define the semantics of the 
information carried in the serialNumber attribute (or any other attribute) 
in the DN.

Yes I agree that this (use of serialNumber) should be (as it already is and 
probably will be) the mainstream solution to this type of issue.

There is definitely an overlapping of functionality between RFC 3039 and PI 
draft here.

/Stefan

At 23:26 2003-04-20 -0400, Roberto Opazo wrote:

>Here we go:
>
>Last year we had a long discussion to get an agreement about PI. It was not
>a consensus, but an agreement. On those time, we had the opportunity to
>standardize the way we use to code permanent identifier in an X.509v3
>certificate, but we still haven't an standard.
>
>Some thinks must be recognized...
>
>The comments received in the WG, an the "minor and major" comment sent by
>the IESG to the draft's authors, makes think we have to start again, because
>an standard can't be a football goal.
>
>RFC 3280 states than Subject is a mandatory field, but with the actual
>draft, this field can't contain a PI, so when you have an End Entity
>identified only by one or more PI, you have to put some garbage in the
>Subject field and code the PI in the SubjectAltName extension, that is a
>crazy idea! Also, it is not very useful to identify the CA with a PI,
>because in practice every program need the Issuer field, not the
>IssuerAltName.
>
>Some countries are actually using the Subject field to code their main PIs.
>
>It is easy to see than there are good reasons to use DN to code PIs, but
>last year, we decided not to use DN to code PIs for many reasons, I hope
>this is a good summary:
>
>* DN are already overloaded.
>
>* One entity can have many PIs, but just one DN.
>
>* DN have no way to indicate the nature of the SerialNumber field, so two
>entities with the same SerialNumber and other DN's attributes could be
>different entities.
>
>Are this reasons invincible? Not in my opinion...
>
>In short, I propose the following:
>
>* Let's recognize than a new discussion is needed.
>
>* Let's use SerialNumber in DN to code a "main entity PI".
>
>* Let's use an extension to indicate when SerialNumber is been used to code
>a "main entity PI", and also the Assigner Authority and the type of that PI.
>Maybe we could use Certificate Policies for that.
>
>* Let's indicate, that when PI is been used in a DN, then other attributes
>in DN (like CN) are just informative.
>
>* Let's continue using the PI draft syntax to code alternative entity's PIs.
>
>Best regards,
>
>Roberto Opazo

_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com
[phone]



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3L3OTt2096079 for <[e-mail]>; Sun, 20 Apr 2003 20:24:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3L3OTUK096078 for ietf-pkix-bks; Sun, 20 Apr 2003 20:24:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mta3.entelchile.net (mta3.real.mail.entelchile.net [164.77.62.92]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3L3OQt2096073 for <[e-mail]>; Sun, 20 Apr 2003 20:24:27 -0700 (PDT) (envelope-from [e-mail])
Received: from vyrealb17wkabo ([200.72.145.36]) by mta3.entelchile.net with SMTP id <20030421032340.IEEO4806.mta3@vyrealb17wkabo> for <[e-mail]>; Sun, 20 Apr 2003 23:23:40 -0400
From: "Roberto Opazo" <[e-mail]>
To: <[e-mail]>
Subject: New ideas for PIs
Date: Sun, 20 Apr 2003 23:26:12 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-reply-to: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Here we go:

Last year we had a long discussion to get an agreement about PI. It was not
a consensus, but an agreement. On those time, we had the opportunity to
standardize the way we use to code permanent identifier in an X.509v3
certificate, but we still haven't an standard.

Some thinks must be recognized...

The comments received in the WG, an the "minor and major" comment sent by
the IESG to the draft's authors, makes think we have to start again, because
an standard can't be a football goal.

RFC 3280 states than Subject is a mandatory field, but with the actual
draft, this field can't contain a PI, so when you have an End Entity
identified only by one or more PI, you have to put some garbage in the
Subject field and code the PI in the SubjectAltName extension, that is a
crazy idea! Also, it is not very useful to identify the CA with a PI,
because in practice every program need the Issuer field, not the
IssuerAltName.

Some countries are actually using the Subject field to code their main PIs.

It is easy to see than there are good reasons to use DN to code PIs, but
last year, we decided not to use DN to code PIs for many reasons, I hope
this is a good summary:

* DN are already overloaded.

* One entity can have many PIs, but just one DN.

* DN have no way to indicate the nature of the SerialNumber field, so two
entities with the same SerialNumber and other DN's attributes could be
different entities.

Are this reasons invincible? Not in my opinion...

In short, I propose the following:

* Let's recognize than a new discussion is needed.

* Let's use SerialNumber in DN to code a "main entity PI".

* Let's use an extension to indicate when SerialNumber is been used to code
a "main entity PI", and also the Assigner Authority and the type of that PI.
Maybe we could use Certificate Policies for that.

* Let's indicate, that when PI is been used in a DN, then other attributes
in DN (like CN) are just informative.

* Let's continue using the PI draft syntax to code alternative entity's PIs.

Best regards,

Roberto Opazo



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3KNQMt2092230 for <[e-mail]>; Sun, 20 Apr 2003 16:26:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3KNQMGd092229 for ietf-pkix-bks; Sun, 20 Apr 2003 16:26:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from vmmr9.verisignmail.com (vmmrnat.verisignmail.com [216.168.230.187]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3KNQKt2092224 for <[e-mail]>; Sun, 20 Apr 2003 16:26:20 -0700 (PDT) (envelope-from [e-mail])
Received: from ms1.verisignmail.com (ms1.verisignmail.com [216.168.230.167] (may be forged)) by vmmr9.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id PDZ07146; Sun, 20 Apr 2003 19:25:50 -0400 (EDT)
Received: from laptop-cpq.retrospekt.com (1Cust221.tnt6.stk3.swe.da.uu.net [213.116.236.221]) by ms1.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id AEF50512; Sun, 20 Apr 2003 19:25:47 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]@mail.retrospekt.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 21 Apr 2003 01:25:33 +0200
To: "Anders Rundgren" <[e-mail]>, <[e-mail]>, "Russ Housley" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: PI's RFC number
Cc: "Roberto Opazo Gazmuri" <[e-mail]>
In-Reply-To: <003a01c30715$2a6a19d0$0500a8c0@arport>
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>

Anders,

I don't feel I can go into the details of this standard since I basically 
don't believe that IETF should produce this standard in the first place.

I don't think this standard should be produced unless the industry without 
any doubts have failed to reasonably address these issues through existing 
mechanisms of X.509 and related standards.

On the contrary I firmly believe that the industry will seek to solve these 
issues through existing mechanisms regardless of this RFC.

I respect though if it is to late to have that discussion.

/Stefan

At 10:16 2003-04-20 +0200, Anders Rundgren wrote:
>Thanx Stefan,
>
>Here is another paragraph which I have a problem with:
>
>    "The IdentifierType field, when present, identifies both the
>    Assigner Authority and the type of that field."
>
>That it has a "type" is true (OID or URI) but this is a self-reference
>and then you usually do not name things xxxType but rather something
>descriptive that implicitly has a type.  Like "PermanentIdentifierNamespace"
>(which is closer to its real function as far as I can tell).
>
>But maybe "type" is rather derived from the following paragraph?
>
>    "Characteristically, when an OID is used, the prefix of the OID
>    identifies the Assigner Authority, and a suffix is used to identify
>    the type of permanent identifier being identified. Essentially the
>    same thing is true of URI's."
>
>What does "type of permanent identifier" mean?  I think I know,
>but there is not a trace of an explanation to this in the draft.
>BTW, there is nothing in the draft assuring that the name space
>identified by "IdentifierType" can be used for anything but as a
>name space, because a type implies issuance constraints.
>
>
>The draft's mixing of "Assigner Authority" and "Name Space" is
>another thing I find a bit confusing.  "http://registry.org/members"
>is a name space, but the authority is rather "registry.org" as there
>could be an "http://registry.org/clients" as well.
>
>
>Anders
>
>
>----- Original Message -----
>From: "Stefan Santesson" <[e-mail]>
>To: "Anders Rundgren" <[e-mail]>; <[e-mail]>; 
>"Russ Housley" <[e-mail]>
>Cc: "Roberto Opazo Gazmuri" <[e-mail]>
>Sent: Saturday, April 19, 2003 14:45
>Subject: Re: PI's RFC number
>
>
>
>I don't know the status and appropriateness of these comments but I would
>agree with Anders observation.
>
>In the second sentence I would remove the beginning all together and start
>with "The permanent identifier may ..."
>
>Or why not remove the whole draft (since I fear it will do more harm than
>good), but I guess we are past that :)
>
>/Stefan
>
>
>At 10:57 2003-04-19 +0200, Anders Rundgren wrote:
>
> >Russ,
> >
> >In case you are doing updates I would drop the following paragraph:
> >
> >    "The permanent identifier identifies the entity, irrespective of any
> >    attribute extension. When a public key certificate contains
> >    attribute extensions, the permanent identifier, if present, should
> >    not be used for access control purposes but only for audit purposes.
> >    The reason is that since these attributes may change, access could
> >    be granted on attributes that were originally present in a
> >    certificate issued to that entity but are no more present in the
> >    current certificate."
> >
> >As a permanent identifier is just another subject name form, semantics of
> >PKCs augmented with PIs do not change unless other things regarding
> >policy is changed as well.   The exact relation between identity and
> >attribute extensions w.r.t. access control seems to me to be outside
> >of what should be written in a standard.  As an implementer however,
> >I have to _select_ between certificate-based attributes for 
> access-control or
> >identity-based access-control using lookups in access control databases.
> >The text above more or less implies, that implementers do not understand
> >how to build access control systems.
> >
> >Another paragraph worth a revision:
> >
> >          "For non-repudiation, the permanent identifier may be used to
> >          link different transactions to the same entity, even when
> >          the subject name of the entity changes."
> >
> >"non-repudiation" should be replaced by the more general "signed messages",
> >as the entity may be a device, server or whatever, to which the 
> human-related
> >term "non-repudiation" usually does not apply.
> >
> >Anders
> >
> >----- Original Message -----
> >From: "Russ Housley" <[e-mail]>
> >To: "Roberto Opazo Gazmuri" <[e-mail]>; <[e-mail]>
> >Sent: Friday, April 18, 2003 17:09
> >Subject: Re: PI's RFC number
> >
> >
> >
> >The IESG sent some concerns to the authors earlier this week.  Those need
> >to be resolved.
> >
> >Russ
> >
> >
> >At 11:39 AM 4/17/2003 -0400, Roberto Opazo Gazmuri wrote:
> >
> > >Hello everybody:
> > >
> > >Is there anybody who could estimate a date when we could reference the 
> IETF
> > >Permanent Identifier work with an RFC number?
> > >
> > >The last call was on Mon, 25 Nov 2002.
> > >
> > >Best regards,
> > >
> > >Roberto Opazo
>
>_____________________________
>Stefan Santesson,  Retrospekt AB
>http://www.retrospekt.com
>[phone]

_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com
[phone]



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3K7SRt2047824 for <[e-mail]>; Sun, 20 Apr 2003 00:28:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3K7SR9S047823 for ietf-pkix-bks; Sun, 20 Apr 2003 00:28:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3K7SQt2047811 for <[e-mail]>; Sun, 20 Apr 2003 00:28:26 -0700 (PDT) (envelope-from [e-mail])
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by mailc.telia.com (8.12.9/8.12.9) with SMTP id h3K7SPj0017336; Sun, 20 Apr 2003 09:28:25 +0200 (CEST)
X-Original-Recipient: [e-mail]
Message-ID: <003a01c30715$2a6a19d0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, "Russ Housley" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Cc: "Roberto Opazo Gazmuri" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: PI's RFC number
Date: Sun, 20 Apr 2003 10:16:37 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
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>

Thanx Stefan,

Here is another paragraph which I have a problem with:

   "The IdentifierType field, when present, identifies both the 
   Assigner Authority and the type of that field."

That it has a "type" is true (OID or URI) but this is a self-reference
and then you usually do not name things xxxType but rather something
descriptive that implicitly has a type.  Like "PermanentIdentifierNamespace"
(which is closer to its real function as far as I can tell).

But maybe "type" is rather derived from the following paragraph?

   "Characteristically, when an OID is used, the prefix of the OID 
   identifies the Assigner Authority, and a suffix is used to identify 
   the type of permanent identifier being identified. Essentially the 
   same thing is true of URI's."

What does "type of permanent identifier" mean?  I think I know,
but there is not a trace of an explanation to this in the draft.
BTW, there is nothing in the draft assuring that the name space
identified by "IdentifierType" can be used for anything but as a
name space, because a type implies issuance constraints.


The draft's mixing of "Assigner Authority" and "Name Space" is
another thing I find a bit confusing.  "http://registry.org/members" 
is a name space, but the authority is rather "registry.org" as there
could be an "http://registry.org/clients" as well.


Anders


----- Original Message ----- 
From: "Stefan Santesson" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>; <[e-mail]>; "Russ Housley" <[e-mail]>
Cc: "Roberto Opazo Gazmuri" <[e-mail]>
Sent: Saturday, April 19, 2003 14:45
Subject: Re: PI's RFC number



I don't know the status and appropriateness of these comments but I would 
agree with Anders observation.

In the second sentence I would remove the beginning all together and start 
with "The permanent identifier may ..."

Or why not remove the whole draft (since I fear it will do more harm than 
good), but I guess we are past that :)

/Stefan


At 10:57 2003-04-19 +0200, Anders Rundgren wrote:

>Russ,
>
>In case you are doing updates I would drop the following paragraph:
>
>    "The permanent identifier identifies the entity, irrespective of any
>    attribute extension. When a public key certificate contains
>    attribute extensions, the permanent identifier, if present, should
>    not be used for access control purposes but only for audit purposes.
>    The reason is that since these attributes may change, access could
>    be granted on attributes that were originally present in a
>    certificate issued to that entity but are no more present in the
>    current certificate."
>
>As a permanent identifier is just another subject name form, semantics of
>PKCs augmented with PIs do not change unless other things regarding
>policy is changed as well.   The exact relation between identity and
>attribute extensions w.r.t. access control seems to me to be outside
>of what should be written in a standard.  As an implementer however,
>I have to _select_ between certificate-based attributes for access-control or
>identity-based access-control using lookups in access control databases.
>The text above more or less implies, that implementers do not understand
>how to build access control systems.
>
>Another paragraph worth a revision:
>
>          "For non-repudiation, the permanent identifier may be used to
>          link different transactions to the same entity, even when
>          the subject name of the entity changes."
>
>"non-repudiation" should be replaced by the more general "signed messages",
>as the entity may be a device, server or whatever, to which the human-related
>term "non-repudiation" usually does not apply.
>
>Anders
>
>----- Original Message -----
>From: "Russ Housley" <[e-mail]>
>To: "Roberto Opazo Gazmuri" <[e-mail]>; <[e-mail]>
>Sent: Friday, April 18, 2003 17:09
>Subject: Re: PI's RFC number
>
>
>
>The IESG sent some concerns to the authors earlier this week.  Those need
>to be resolved.
>
>Russ
>
>
>At 11:39 AM 4/17/2003 -0400, Roberto Opazo Gazmuri wrote:
>
> >Hello everybody:
> >
> >Is there anybody who could estimate a date when we could reference the IETF
> >Permanent Identifier work with an RFC number?
> >
> >The last call was on Mon, 25 Nov 2002.
> >
> >Best regards,
> >
> >Roberto Opazo

_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com
[phone]






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3K2uUt2029401 for <[e-mail]>; Sat, 19 Apr 2003 19:56:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3K2uT83029400 for ietf-pkix-bks; Sat, 19 Apr 2003 19:56:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mta3.entelchile.net (mta3.real.mail.entelchile.net [164.77.62.92]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3K2uRt2029395 for <[e-mail]>; Sat, 19 Apr 2003 19:56:28 -0700 (PDT) (envelope-from [e-mail])
Received: from vyrealb17wkabo ([200.72.145.185]) by mta3.entelchile.net with SMTP id <20030420025540.YBLW4806.mta3@vyrealb17wkabo> for <[e-mail]>; Sat, 19 Apr 2003 22:55:40 -0400
From: "Roberto Opazo" <[e-mail]>
To: <[e-mail]>
Subject: RE: PI's RFC number
Date: Sat, 19 Apr 2003 22:58:14 -0400
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 V6.00.2600.0000
In-Reply-To: <00fd01c30651$aa169470$0500a8c0@arport>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

This time a disagree with you, but I think we should discuss this topic
after having the first version of the standard.

Best regards,

Roberto Opazo

> -----Mensaje original-----
> De: Anders Rundgren [mailto:[e-mail]]
> Enviado el: sábado, 19 de abril de 2003 4:57
> Para: [e-mail]; Russ Housley
> CC: Roberto Opazo Gazmuri
> Asunto: Re: PI's RFC number
>
>
> Russ,
>
> In case you are doing updates I would drop the following paragraph:
>
>    "The permanent identifier identifies the entity, irrespective of any
>    attribute extension. When a public key certificate contains
>    attribute extensions, the permanent identifier, if present, should
>    not be used for access control purposes but only for audit purposes.
>    The reason is that since these attributes may change, access could
>    be granted on attributes that were originally present in a
>    certificate issued to that entity but are no more present in the
>    current certificate."
>
> As a permanent identifier is just another subject name form, semantics of
> PKCs augmented with PIs do not change unless other things regarding
> policy is changed as well.   The exact relation between identity and
> attribute extensions w.r.t. access control seems to me to be outside
> of what should be written in a standard.  As an implementer however,
> I have to _select_ between certificate-based attributes for
> access-control or
> identity-based access-control using lookups in access control databases.
> The text above more or less implies, that implementers do not understand
> how to build access control systems.
>
> Another paragraph worth a revision:
>
>          "For non-repudiation, the permanent identifier may be used to
>          link different transactions to the same entity, even when
>          the subject name of the entity changes."
>
> "non-repudiation" should be replaced by the more general "signed
> messages",
> as the entity may be a device, server or whatever, to which the
> human-related
> term "non-repudiation" usually does not apply.
>
> Anders
>
> ----- Original Message -----
> From: "Russ Housley" <[e-mail]>
> To: "Roberto Opazo Gazmuri" <[e-mail]>; <[e-mail]>
> Sent: Friday, April 18, 2003 17:09
> Subject: Re: PI's RFC number
>
>
>
> The IESG sent some concerns to the authors earlier this week.  Those need
> to be resolved.
>
> Russ
>
>
> At 11:39 AM 4/17/2003 -0400, Roberto Opazo Gazmuri wrote:
>
> >Hello everybody:
> >
> >Is there anybody who could estimate a date when we could
> reference the IETF
> >Permanent Identifier work with an RFC number?
> >
> >The last call was on Mon, 25 Nov 2002.
> >
> >Best regards,
> >
> >Roberto Opazo
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3JCkYt2005106 for <[e-mail]>; Sat, 19 Apr 2003 05:46:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3JCkYbk005105 for ietf-pkix-bks; Sat, 19 Apr 2003 05:46:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from vmmr8.verisignmail.com (vmmrnat.verisignmail.com [216.168.230.187]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3JCkWt2005100 for <[e-mail]>; Sat, 19 Apr 2003 05:46:32 -0700 (PDT) (envelope-from [e-mail])
Received: from ms1.verisignmail.com (ms1.verisignmail.com [216.168.230.167] (may be forged)) by vmmr8.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id AJZ35574; Sat, 19 Apr 2003 08:46:09 -0400 (EDT)
Received: from laptop-cpq.retrospekt.com (1Cust69.tnt13.stk3.swe.da.uu.net [213.116.251.69]) by ms1.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id AEE49608; Sat, 19 Apr 2003 08:46:05 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]@mail.retrospekt.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Sat, 19 Apr 2003 14:45:45 +0200
To: "Anders Rundgren" <[e-mail]>, <[e-mail]>, "Russ Housley" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: PI's RFC number
Cc: "Roberto Opazo Gazmuri" <[e-mail]>
In-Reply-To: <00fd01c30651$aa169470$0500a8c0@arport>
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>

I don't know the status and appropriateness of these comments but I would 
agree with Anders observation.

In the second sentence I would remove the beginning all together and start 
with "The permanent identifier may ..."

Or why not remove the whole draft (since I fear it will do more harm than 
good), but I guess we are past that :)

/Stefan


At 10:57 2003-04-19 +0200, Anders Rundgren wrote:

>Russ,
>
>In case you are doing updates I would drop the following paragraph:
>
>    "The permanent identifier identifies the entity, irrespective of any
>    attribute extension. When a public key certificate contains
>    attribute extensions, the permanent identifier, if present, should
>    not be used for access control purposes but only for audit purposes.
>    The reason is that since these attributes may change, access could
>    be granted on attributes that were originally present in a
>    certificate issued to that entity but are no more present in the
>    current certificate."
>
>As a permanent identifier is just another subject name form, semantics of
>PKCs augmented with PIs do not change unless other things regarding
>policy is changed as well.   The exact relation between identity and
>attribute extensions w.r.t. access control seems to me to be outside
>of what should be written in a standard.  As an implementer however,
>I have to _select_ between certificate-based attributes for access-control or
>identity-based access-control using lookups in access control databases.
>The text above more or less implies, that implementers do not understand
>how to build access control systems.
>
>Another paragraph worth a revision:
>
>          "For non-repudiation, the permanent identifier may be used to
>          link different transactions to the same entity, even when
>          the subject name of the entity changes."
>
>"non-repudiation" should be replaced by the more general "signed messages",
>as the entity may be a device, server or whatever, to which the human-related
>term "non-repudiation" usually does not apply.
>
>Anders
>
>----- Original Message -----
>From: "Russ Housley" <[e-mail]>
>To: "Roberto Opazo Gazmuri" <[e-mail]>; <[e-mail]>
>Sent: Friday, April 18, 2003 17:09
>Subject: Re: PI's RFC number
>
>
>
>The IESG sent some concerns to the authors earlier this week.  Those need
>to be resolved.
>
>Russ
>
>
>At 11:39 AM 4/17/2003 -0400, Roberto Opazo Gazmuri wrote:
>
> >Hello everybody:
> >
> >Is there anybody who could estimate a date when we could reference the IETF
> >Permanent Identifier work with an RFC number?
> >
> >The last call was on Mon, 25 Nov 2002.
> >
> >Best regards,
> >
> >Roberto Opazo

_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com
[phone]



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3J894t2082483 for <[e-mail]>; Sat, 19 Apr 2003 01:09:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3J893DR082482 for ietf-pkix-bks; Sat, 19 Apr 2003 01:09:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3J892t2082452 for <[e-mail]>; Sat, 19 Apr 2003 01:09:03 -0700 (PDT) (envelope-from [e-mail])
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by mailc.telia.com (8.12.9/8.12.9) with SMTP id h3J88tj0021972; Sat, 19 Apr 2003 10:08:55 +0200 (CEST)
X-Original-Recipient: [e-mail]
Message-ID: <00fd01c30651$aa169470$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, "Russ Housley" <[e-mail]>
Cc: "Roberto Opazo Gazmuri" <[e-mail]>
References: <[e-mail]>
Subject: Re: PI's RFC number
Date: Sat, 19 Apr 2003 10:57:10 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
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>

Russ,

In case you are doing updates I would drop the following paragraph:

   "The permanent identifier identifies the entity, irrespective of any 
   attribute extension. When a public key certificate contains 
   attribute extensions, the permanent identifier, if present, should 
   not be used for access control purposes but only for audit purposes. 
   The reason is that since these attributes may change, access could 
   be granted on attributes that were originally present in a 
   certificate issued to that entity but are no more present in the 
   current certificate."

As a permanent identifier is just another subject name form, semantics of
PKCs augmented with PIs do not change unless other things regarding
policy is changed as well.   The exact relation between identity and
attribute extensions w.r.t. access control seems to me to be outside
of what should be written in a standard.  As an implementer however, 
I have to _select_ between certificate-based attributes for access-control or
identity-based access-control using lookups in access control databases. 
The text above more or less implies, that implementers do not understand
how to build access control systems.

Another paragraph worth a revision:

         "For non-repudiation, the permanent identifier may be used to 
         link different transactions to the same entity, even when 
         the subject name of the entity changes."

"non-repudiation" should be replaced by the more general "signed messages",
as the entity may be a device, server or whatever, to which the human-related
term "non-repudiation" usually does not apply.

Anders

----- Original Message ----- 
From: "Russ Housley" <[e-mail]>
To: "Roberto Opazo Gazmuri" <[e-mail]>; <[e-mail]>
Sent: Friday, April 18, 2003 17:09
Subject: Re: PI's RFC number



The IESG sent some concerns to the authors earlier this week.  Those need 
to be resolved.

Russ


At 11:39 AM 4/17/2003 -0400, Roberto Opazo Gazmuri wrote:

>Hello everybody:
>
>Is there anybody who could estimate a date when we could reference the IETF
>Permanent Identifier work with an RFC number?
>
>The last call was on Mon, 25 Nov 2002.
>
>Best regards,
>
>Roberto Opazo




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3ILWrt2038807 for <[e-mail]>; Fri, 18 Apr 2003 14:32:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3ILWrQb038806 for ietf-pkix-bks; Fri, 18 Apr 2003 14:32:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fnord.ir.bbn.com (FNORD.IR.BBN.com [192.1.100.210]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3ILWot2038800 for <[e-mail]>; Fri, 18 Apr 2003 14:32:51 -0700 (PDT) (envelope-from [e-mail])
Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id 7B4FB23F9; Fri, 18 Apr 2003 17:32:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: from wolfe.bbn.com (wolfe.bbn.com [128.89.80.22]) by fnord.ir.bbn.com (Postfix) with ESMTP id F2A131F75 for <[e-mail]>; Fri, 18 Apr 2003 12:27:32 -0400 (EDT)
Received: by wolfe.bbn.com (Postfix) id D51E116504; Fri, 18 Apr 2003 12:27:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by wolfe.bbn.com (Postfix) with ESMTP id C7BA416484 for <[e-mail]>; Fri, 18 Apr 2003 12:27:32 -0400 (EDT)
Received: from gollum.bbn.com (gollum.bbn.com [192.1.120.132]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h3IGRV5v022792; Fri, 18 Apr 2003 12:27:32 -0400 (EDT)
Received: from above.proper.com (mail.proper.com [208.184.76.45]) by gollum.bbn.com (8.12.9/8.12.2) with ESMTP id h3IGRPxK011397; Fri, 18 Apr 2003 12:27:25 -0400
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IG9lt2027689 for <[e-mail]>; Fri, 18 Apr 2003 09:09:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IG9lg5027688 for ietf-pkix-bks; Fri, 18 Apr 2003 09:09:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IG9jt2027682 for <[e-mail]>; Fri, 18 Apr 2003 09:09:45 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (unknown[12.81.120.164]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <2003041816093011200q2mcge>; Fri, 18 Apr 2003 16:09:31 +0000
Message-ID: <013b01c67a95$6c00def0$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "todd glassey" <[e-mail]>, "Jeff Williams" <[e-mail]>, <[e-mail]>, "Lynn St.Amour" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <[e-mail]> <005801c3036e$e5232f00$020aff0a@tsg1> <p05100305bac1f918d257@[128.89.88.34]> <01ce01c67926$a1131ba0$020aff0a@tsg1> <p05100316bac3737d4c50@[128.89.88.34]> <02a101c67934$0fe58c40$020aff0a@tsg1> <[e-mail]> <00c601c67a86$86797170$020aff0a@tsg1>
Subject: Re: Possible Solution: WAS Re: RFC3161(TSP): doubts about tcp protocol
Date: Thu, 18 May 2006 09:09:16 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
X-Scanned-By: MIMEDefang 2.19 (www . roaringpenguin . com / mimedefang)
X-Spam-Status: No, hits=-13.5 required=5.0 tests=AWL,ORIGINAL_MESSAGE,QUOTED_EMAIL_TEXT,REFERENCES, X_AUTH_WARNING autolearn=ham version=2.53
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

By the way - my apologies for what many will consider very negative
commentary below in the previous message - I thought I should really bring
out a little more of my motivations so that it was clear that I am not
really a madman or an anarchist at all. In fact I am pretty conservative
politically but anyway - my intent is not negative at all but rather that I
seek certain changes to correct things that I see as wrong with the Global
Internet Standards Process at this time.  Most of these are at an
organizational level, but they all generally circle around having the same
set of simple rules be applied to everyone equally and that the process and
expectations of each step of the process are defined as opposed as they are
now, which  much left up to the WG Chairs and AD's to come to consensus on.
Mark that phrase "simple rules" and not the convoluted ones we have today.

In any event, most all of you probably don't want to hear this, so I will
close this thread out from my standpoint unless someone asks me for a
reply - Again my apologies for "wasting" your time.

Todd

----- Original Message -----
From: "todd glassey" <[e-mail]>
To: "Jeff Williams" <[e-mail]>; <[e-mail]>; "Lynn
St.Amour" <[e-mail]>; <[e-mail]>
Sent: Thursday, May 18, 2006 7:21 AM
Subject: Possible Solution: WAS Re: RFC3161(TSP): doubts about tcp protocol


> Thanks Jeff - I appreciate your words but Steve and I have been trading
> commentary, nasty remarks, and insults for several years here including my
> demands for him to retire, so I would think that by now everyone is pretty
> much used to it. But thanks for the comment anyway.  As to the world
around
> this, Steve's supporter's just say "Damn what is Glassey doing now... that
> J$%^&k..." or something stronger, and my supporters and the curious just
> send me private email asking my why I put up with it. I probably get 3-5
of
> those a day these days, including yours Jeff! (and BTW - all of those that
> send those letters of encouragement - thanks!)
>
> The answer is simple - Why I do this is to create a semi-permanent record
of
> the IETF's refusal to play by its own rules or insure a level and even
> playing field.
>
> You see this type of interchange supposedly creates a permanent record and
> it is my feeling that this will eventually amount to enough evidence at
some
> point to have the US DoJ investigate the IETF and its management for
> Antitrust and restraint of trade, which I hope will culminate in a US
> Federal Court getting involved and in the Court's  telling the NTIA that
its
> contract with ICANN is illegal since it takes control of the "system" away
> from the people it was built to serve. And - yes - I believe that this
will
> come to pass and that it is coming sooner than later.
>
> As to my detractors, I just laugh at their refusal to see anything like
the
> real world. So its cool. We each have our own opinions on how things
should
> operate and I am the one proposing radical change, so you have to give
them
> space to vent. And remember that many of these people actually earn a
living
> by being the IETF liaison so any change to the process affects their Job
and
> these days that is really scary, but this is also why there is so much
> Industry Interference in the IETF's processes - that being their need to
> keep the processes loose and undefined so that those participants can slip
> their standards through to support their products without attracting too
> much attention. Hell look at IPSEC for instance.
>
> The Problem - Maintaining the current value of the IP disclosure section
of
> an IETF document
> --------------
> But, the real issue here is probably more like whether there should be any
> IP disclosure requirements inside an IETF draft or not, and especially
ones
> (those inside the Standards Process) that spend more than a calendar year
in
> the hopper such that the IP under them and around them is a moving target.
> In a legal sense this would be phrased as a stale declaration, one that
had
> aged so much and was tied to such a specific point in time that it
> there-after would have little or diminishing value moving forward in time.
>
> So far what I think after reviewing this and how the IP disclosure was
> implemented, I think that the any disclosure of any IP impingements on an
> IETF draft or RFC creates a fiduciary responsibility to keep that portion
of
> the Draft or RFC accurate and current, so a partial disclosure is worse
than
> no disclosure and by a lot.
>
> If this is true, then what than means is that each time the draft was
> republished or changes state, then this same responsibility would like
also
> require that the IP implications section be updated and that is
> realistically not something that most of our technical contributors have
any
> desire to participate in. Or that the Editor's of the drafts and RFC's
have
> time for now either.
>
> The Proposed Solution - eliminate the need to do IP disclosure and replace
> it with a Disclaimer
> ------------------------
> With that said, the only option I see is to re-adopt the original policy
of
> replacing the "Patent Liabilities" section of the Draft or RFC with a
> disclaimer stating "that it would be the adopter's responsibility to do a
> complete patent or other IP search before adopting anything therein", and
> that the IETF, because of its structure and process, cannot be held
> accountable for keeping up to date on current IP implications re: any
> specific submittal, other than what is required in the submitter's
> disclosure that they indeed have the right to publish this document.
>
> . Or they can choose to ignore these words and suffer the consequences if
> there is an IP conflict over their use of those IP's.
>
> I made this BTW, in an offline proposal to Steve yesterday.
>
> Optional BCP's detailing IP issues
> ----------------------------------
> I would also propose that anyone that wants to can also file a BCP style
> informational draft on the legal aspects of using any specific IETF
protocol
> as a formal notice to the IETF and its participants regarding IP issues
with
> a protocol. I would also argue that this is a consistent use of the IETF
as
> a publishing house for new and emerging technologies. For instance if you
> wanted to publish a statement regarding the patent aspects of using any
> protocol(s), you could as a BCP statement, and that then would become a
part
> of the IETF's permanent record, and there would be a record within the
IETF
> that there were specific IP issues with a technology which puts the total
> responsibility on the adopters for verifying that their implementation
does
> not run afoul of someone else's IP rights.
>
> And as long as we are at it, lets add a section to the IP Disclosure rules
> within 2026 (ss10) on "that the IETF is to be held blameless for
disclosing
> this information if the submitter turns out not to own the IP, or more
> importantly, if there is IP-based litigation over the disclosure of the IP
> itself, and that it is the responsibility of the Submitter to warrant that
> the documents IP issues are addressed and that the document is legally fit
> for publication". So then by this model it is the submitter that bears the
> brunt of any legal attacks rather than the IETF.
>
> ---
>
> Anyone have a problem with these comments? (other than it was me that made
> them or you don't like my writing style?)...
>
> Todd
>
>
>
> ----- Original Message -----
> From: "Jeff Williams" <[e-mail]>
> To: "todd glassey" <[e-mail]>
> Cc: "Stephen Kent" <[e-mail]>; "Ricardo Barroso"
> <[e-mail]>; "Gianluca Ramunno" <[e-mail]>;
> <[e-mail]>; <[e-mail]>; "Lynn St.Amour"
> <[e-mail]>; <[e-mail]>
> Sent: Friday, April 18, 2003 2:03 AM
> Subject: Re: RFC3161(TSP): doubts about tcp protocol
>
>
> > Todd, Stephen, and all,
> >
> >   Stephen, please discontinue your diatribe and obvious personal
> > attack of Todd.  It is unseemly and unproductive..
> >
> > todd glassey wrote:
> >
> > > ----- Original Message -----
> > > From: "Stephen Kent" <[e-mail]>
> > > To: "todd glassey" <[e-mail]>
> > > Cc: "Ricardo Barroso" <[e-mail]>; "Gianluca
> Ramunno"
> > > <[e-mail]>; <[e-mail]>; <[e-mail]>;
"Lynn
> > > St.Amour" <[e-mail]>; <[e-mail]>
> > > Sent: Wednesday, April 16, 2003 2:41 PM
> > > Subject: Re: RFC3161(TSP): doubts about tcp protocol
> > >
> > > > At 1:22 PM -0700 5/16/06, todd glassey wrote:
> > > > >Look Dr. Kent - the issue here is that you do not invalidate what I
> am
> > > > >saying you just attack me personally.  If I am wrong I humbly
> apologize
> > > but
> > > > >so far this is 100% dead-on by my take. So lets get to debunking
your
> > > > >commentary from the last response -
> > > > >
> > > >
> > > > It appears that Todd can't distinguish between statements of fact
> > > > about IP issues and personal criticism.
> > > >
> > > > Personal criticism would be more along the lines of suggesting that
> > > > he is engaging in fear mongering at this stage of the standards
> > > > process, perhaps because he tried and failed to block the
advancement
> > > > of TSP through the WG process, in IETF last call, and via direct
> > > > appeal to the IESG. But even that observation is based on facts that
> > > > are part of the public record; only the motivation aspect of the
> > > > comment might be considered personal criticism.
> > >
> > > Fear Mongering implies that there is something wrong with what I am
> saying
> > > or that there is inaccuracy in it and that is not true. So in this
> instance
> > > I again claim that you use your status as the WG Chair to invalidate
> what I
> > > am saying becuase I am saying it without ever invalidating  the
> statement
> > > itself.
> > >
> > > >
> > > > The simple fact is that there have been many claims in the area of
> > > > secure time stamping, going back at least as far as the PB patent
> > > > cited by Todd. Some of these claims are quite broad. The more modern
> > > > ones often make explicit reference to digital signature mechanisms,
> > > > whereas the original PB patent does not. The applicability of any
> > > > patent to the RFC 3161 protocol is a matter for lawyers and the
> > > > courts to determine.
> > > >
> > > > Mr. Glassey is not a lawyer, although he sometimes seems to forget
> > > > that. Thus his assertions about what patents may be violated by a
> > > > product that implements 3161 are not legal opinions and there is
good
> > > > reason to believe that they are motivated by other than simple,
> > > > objective, technical observations, based on previous messages on
this
> > > > list.
> > >
> > > This is true and I do want to see my patent's supported but I also
want
> all
> > > other TS technologies to get their fair shake in the commercial world
> rather
> > > then being mandated by a standards org process. There is enough room
for
> all
> > > of us here. What's wrong with that comment other than it leaves you
out
> of
> > > the bigger picture Steve?
> > >
> > > >
> > > > As I noted in my earlier message, in the one legal case that is
> > > > clearly relevant to this discussion, a patent holder who made very
> > > > broad claims about time stamping sued a vendor who implemented a
> > > > TSP-like capability in a product. The defendant prevailed, and the
> > > > plaintiff had four broad patent claims disallowed as a result.
> > >
> > > I can send you a copy of the transscript for the case if you want -
Its
> > > number 99-203 in the Western Dist of Va, Feb 1999. - Surety V Entrust.
> We
> > > got a copy of it after I got the letter from Surety at Coastek about
my
> > > first timestamping tools so that when I started CertifiedTime in
August
> of
> > > 1999 I would know what was what.
> > >
> > > >
> > > > know that I am not a lawyer and thus not qualified to advise
> > > > prospective implementors about the implications of this court
> > > > decision,
> > >
> > > Then why did you?
> > >
> > > > but as an individual technologist I did take away a
> > > > positive message relative to 3161.
> > >
> > > That doesnt answer the question I asked - you made a public
commentary -
> > > what did you make it as? Please answer this question.
> > >
> > > > or for that matter any other standards body with which I am
familiar,
> > > > addresses these issues.
> > >
> > > Then dont make broad sweeping claims about the legal status of any
> > > submission as you have.
> > >
> > > > RFC 2026 describes the IETF process re IP
> > > > issues.
> > >
> > > The problem is that 2026 is couched to prevent any liability from
being
> > > ascribed to the IETF and that is what you always hide behind. So until
> you
> > > invalidate what it is I said Steve this is obvously just another one
of
> > > those things we will disagree on.
> > >
> > > >
> > > > Steve
> >
> > Regards,
> >
> > --
> > Jeffrey A. Williams
> > Spokesman for INEGroup LLA. - (Over 129k members/stakeholders strong!)
> > ================================================================
> > CEO/DIR. Internet Network Eng. SR. Eng. Network data security
> > Information Network Eng. Group. INEG. INC.
> > E-Mail [e-mail]
> > Contact Number: 214-244-4827 or 214-244-3801
> >
> >
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IG9lt2027689 for <[e-mail]>; Fri, 18 Apr 2003 09:09:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IG9lg5027688 for ietf-pkix-bks; Fri, 18 Apr 2003 09:09:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IG9jt2027682 for <[e-mail]>; Fri, 18 Apr 2003 09:09:45 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (unknown[12.81.120.164]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <2003041816093011200q2mcge>; Fri, 18 Apr 2003 16:09:31 +0000
Message-ID: <013b01c67a95$6c00def0$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "todd glassey" <[e-mail]>, "Jeff Williams" <[e-mail]>, <[e-mail]>, "Lynn St.Amour" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <[e-mail]> <005801c3036e$e5232f00$020aff0a@tsg1> <p05100305bac1f918d257@[128.89.88.34]> <01ce01c67926$a1131ba0$020aff0a@tsg1> <p05100316bac3737d4c50@[128.89.88.34]> <02a101c67934$0fe58c40$020aff0a@tsg1> <[e-mail]> <00c601c67a86$86797170$020aff0a@tsg1>
Subject: Re: Possible Solution: WAS Re: RFC3161(TSP): doubts about tcp protocol
Date: Thu, 18 May 2006 09:09:16 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

By the way - my apologies for what many will consider very negative
commentary below in the previous message - I thought I should really bring
out a little more of my motivations so that it was clear that I am not
really a madman or an anarchist at all. In fact I am pretty conservative
politically but anyway - my intent is not negative at all but rather that I
seek certain changes to correct things that I see as wrong with the Global
Internet Standards Process at this time.  Most of these are at an
organizational level, but they all generally circle around having the same
set of simple rules be applied to everyone equally and that the process and
expectations of each step of the process are defined as opposed as they are
now, which  much left up to the WG Chairs and AD's to come to consensus on.
Mark that phrase "simple rules" and not the convoluted ones we have today.

In any event, most all of you probably don't want to hear this, so I will
close this thread out from my standpoint unless someone asks me for a
reply - Again my apologies for "wasting" your time.

Todd

----- Original Message -----
From: "todd glassey" <[e-mail]>
To: "Jeff Williams" <[e-mail]>; <[e-mail]>; "Lynn
St.Amour" <[e-mail]>; <[e-mail]>
Sent: Thursday, May 18, 2006 7:21 AM
Subject: Possible Solution: WAS Re: RFC3161(TSP): doubts about tcp protocol


> Thanks Jeff - I appreciate your words but Steve and I have been trading
> commentary, nasty remarks, and insults for several years here including my
> demands for him to retire, so I would think that by now everyone is pretty
> much used to it. But thanks for the comment anyway.  As to the world
around
> this, Steve's supporter's just say "Damn what is Glassey doing now... that
> J$%^&k..." or something stronger, and my supporters and the curious just
> send me private email asking my why I put up with it. I probably get 3-5
of
> those a day these days, including yours Jeff! (and BTW - all of those that
> send those letters of encouragement - thanks!)
>
> The answer is simple - Why I do this is to create a semi-permanent record
of
> the IETF's refusal to play by its own rules or insure a level and even
> playing field.
>
> You see this type of interchange supposedly creates a permanent record and
> it is my feeling that this will eventually amount to enough evidence at
some
> point to have the US DoJ investigate the IETF and its management for
> Antitrust and restraint of trade, which I hope will culminate in a US
> Federal Court getting involved and in the Court's  telling the NTIA that
its
> contract with ICANN is illegal since it takes control of the "system" away
> from the people it was built to serve. And - yes - I believe that this
will
> come to pass and that it is coming sooner than later.
>
> As to my detractors, I just laugh at their refusal to see anything like
the
> real world. So its cool. We each have our own opinions on how things
should
> operate and I am the one proposing radical change, so you have to give
them
> space to vent. And remember that many of these people actually earn a
living
> by being the IETF liaison so any change to the process affects their Job
and
> these days that is really scary, but this is also why there is so much
> Industry Interference in the IETF's processes - that being their need to
> keep the processes loose and undefined so that those participants can slip
> their standards through to support their products without attracting too
> much attention. Hell look at IPSEC for instance.
>
> The Problem - Maintaining the current value of the IP disclosure section
of
> an IETF document
> --------------
> But, the real issue here is probably more like whether there should be any
> IP disclosure requirements inside an IETF draft or not, and especially
ones
> (those inside the Standards Process) that spend more than a calendar year
in
> the hopper such that the IP under them and around them is a moving target.
> In a legal sense this would be phrased as a stale declaration, one that
had
> aged so much and was tied to such a specific point in time that it
> there-after would have little or diminishing value moving forward in time.
>
> So far what I think after reviewing this and how the IP disclosure was
> implemented, I think that the any disclosure of any IP impingements on an
> IETF draft or RFC creates a fiduciary responsibility to keep that portion
of
> the Draft or RFC accurate and current, so a partial disclosure is worse
than
> no disclosure and by a lot.
>
> If this is true, then what than means is that each time the draft was
> republished or changes state, then this same responsibility would like
also
> require that the IP implications section be updated and that is
> realistically not something that most of our technical contributors have
any
> desire to participate in. Or that the Editor's of the drafts and RFC's
have
> time for now either.
>
> The Proposed Solution - eliminate the need to do IP disclosure and replace
> it with a Disclaimer
> ------------------------
> With that said, the only option I see is to re-adopt the original policy
of
> replacing the "Patent Liabilities" section of the Draft or RFC with a
> disclaimer stating "that it would be the adopter's responsibility to do a
> complete patent or other IP search before adopting anything therein", and
> that the IETF, because of its structure and process, cannot be held
> accountable for keeping up to date on current IP implications re: any
> specific submittal, other than what is required in the submitter's
> disclosure that they indeed have the right to publish this document.
>
> . Or they can choose to ignore these words and suffer the consequences if
> there is an IP conflict over their use of those IP's.
>
> I made this BTW, in an offline proposal to Steve yesterday.
>
> Optional BCP's detailing IP issues
> ----------------------------------
> I would also propose that anyone that wants to can also file a BCP style
> informational draft on the legal aspects of using any specific IETF
protocol
> as a formal notice to the IETF and its participants regarding IP issues
with
> a protocol. I would also argue that this is a consistent use of the IETF
as
> a publishing house for new and emerging technologies. For instance if you
> wanted to publish a statement regarding the patent aspects of using any
> protocol(s), you could as a BCP statement, and that then would become a
part
> of the IETF's permanent record, and there would be a record within the
IETF
> that there were specific IP issues with a technology which puts the total
> responsibility on the adopters for verifying that their implementation
does
> not run afoul of someone else's IP rights.
>
> And as long as we are at it, lets add a section to the IP Disclosure rules
> within 2026 (ss10) on "that the IETF is to be held blameless for
disclosing
> this information if the submitter turns out not to own the IP, or more
> importantly, if there is IP-based litigation over the disclosure of the IP
> itself, and that it is the responsibility of the Submitter to warrant that
> the documents IP issues are addressed and that the document is legally fit
> for publication". So then by this model it is the submitter that bears the
> brunt of any legal attacks rather than the IETF.
>
> ---
>
> Anyone have a problem with these comments? (other than it was me that made
> them or you don't like my writing style?)...
>
> Todd
>
>
>
> ----- Original Message -----
> From: "Jeff Williams" <[e-mail]>
> To: "todd glassey" <[e-mail]>
> Cc: "Stephen Kent" <[e-mail]>; "Ricardo Barroso"
> <[e-mail]>; "Gianluca Ramunno" <[e-mail]>;
> <[e-mail]>; <[e-mail]>; "Lynn St.Amour"
> <[e-mail]>; <[e-mail]>
> Sent: Friday, April 18, 2003 2:03 AM
> Subject: Re: RFC3161(TSP): doubts about tcp protocol
>
>
> > Todd, Stephen, and all,
> >
> >   Stephen, please discontinue your diatribe and obvious personal
> > attack of Todd.  It is unseemly and unproductive..
> >
> > todd glassey wrote:
> >
> > > ----- Original Message -----
> > > From: "Stephen Kent" <[e-mail]>
> > > To: "todd glassey" <[e-mail]>
> > > Cc: "Ricardo Barroso" <[e-mail]>; "Gianluca
> Ramunno"
> > > <[e-mail]>; <[e-mail]>; <[e-mail]>;
"Lynn
> > > St.Amour" <[e-mail]>; <[e-mail]>
> > > Sent: Wednesday, April 16, 2003 2:41 PM
> > > Subject: Re: RFC3161(TSP): doubts about tcp protocol
> > >
> > > > At 1:22 PM -0700 5/16/06, todd glassey wrote:
> > > > >Look Dr. Kent - the issue here is that you do not invalidate what I
> am
> > > > >saying you just attack me personally.  If I am wrong I humbly
> apologize
> > > but
> > > > >so far this is 100% dead-on by my take. So lets get to debunking
your
> > > > >commentary from the last response -
> > > > >
> > > >
> > > > It appears that Todd can't distinguish between statements of fact
> > > > about IP issues and personal criticism.
> > > >
> > > > Personal criticism would be more along the lines of suggesting that
> > > > he is engaging in fear mongering at this stage of the standards
> > > > process, perhaps because he tried and failed to block the
advancement
> > > > of TSP through the WG process, in IETF last call, and via direct
> > > > appeal to the IESG. But even that observation is based on facts that
> > > > are part of the public record; only the motivation aspect of the
> > > > comment might be considered personal criticism.
> > >
> > > Fear Mongering implies that there is something wrong with what I am
> saying
> > > or that there is inaccuracy in it and that is not true. So in this
> instance
> > > I again claim that you use your status as the WG Chair to invalidate
> what I
> > > am saying becuase I am saying it without ever invalidating  the
> statement
> > > itself.
> > >
> > > >
> > > > The simple fact is that there have been many claims in the area of
> > > > secure time stamping, going back at least as far as the PB patent
> > > > cited by Todd. Some of these claims are quite broad. The more modern
> > > > ones often make explicit reference to digital signature mechanisms,
> > > > whereas the original PB patent does not. The applicability of any
> > > > patent to the RFC 3161 protocol is a matter for lawyers and the
> > > > courts to determine.
> > > >
> > > > Mr. Glassey is not a lawyer, although he sometimes seems to forget
> > > > that. Thus his assertions about what patents may be violated by a
> > > > product that implements 3161 are not legal opinions and there is
good
> > > > reason to believe that they are motivated by other than simple,
> > > > objective, technical observations, based on previous messages on
this
> > > > list.
> > >
> > > This is true and I do want to see my patent's supported but I also
want
> all
> > > other TS technologies to get their fair shake in the commercial world
> rather
> > > then being mandated by a standards org process. There is enough room
for
> all
> > > of us here. What's wrong with that comment other than it leaves you
out
> of
> > > the bigger picture Steve?
> > >
> > > >
> > > > As I noted in my earlier message, in the one legal case that is
> > > > clearly relevant to this discussion, a patent holder who made very
> > > > broad claims about time stamping sued a vendor who implemented a
> > > > TSP-like capability in a product. The defendant prevailed, and the
> > > > plaintiff had four broad patent claims disallowed as a result.
> > >
> > > I can send you a copy of the transscript for the case if you want -
Its
> > > number 99-203 in the Western Dist of Va, Feb 1999. - Surety V Entrust.
> We
> > > got a copy of it after I got the letter from Surety at Coastek about
my
> > > first timestamping tools so that when I started CertifiedTime in
August
> of
> > > 1999 I would know what was what.
> > >
> > > >
> > > > know that I am not a lawyer and thus not qualified to advise
> > > > prospective implementors about the implications of this court
> > > > decision,
> > >
> > > Then why did you?
> > >
> > > > but as an individual technologist I did take away a
> > > > positive message relative to 3161.
> > >
> > > That doesnt answer the question I asked - you made a public
commentary -
> > > what did you make it as? Please answer this question.
> > >
> > > > or for that matter any other standards body with which I am
familiar,
> > > > addresses these issues.
> > >
> > > Then dont make broad sweeping claims about the legal status of any
> > > submission as you have.
> > >
> > > > RFC 2026 describes the IETF process re IP
> > > > issues.
> > >
> > > The problem is that 2026 is couched to prevent any liability from
being
> > > ascribed to the IETF and that is what you always hide behind. So until
> you
> > > invalidate what it is I said Steve this is obvously just another one
of
> > > those things we will disagree on.
> > >
> > > >
> > > > Steve
> >
> > Regards,
> >
> > --
> > Jeffrey A. Williams
> > Spokesman for INEGroup LLA. - (Over 129k members/stakeholders strong!)
> > ================================================================
> > CEO/DIR. Internet Network Eng. SR. Eng. Network data security
> > Information Network Eng. Group. INEG. INC.
> > E-Mail [e-mail]
> > Contact Number: 214-244-4827 or 214-244-3801
> >
> >
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IFGSt2026709 for <[e-mail]>; Fri, 18 Apr 2003 08:16:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IFGSEX026708 for ietf-pkix-bks; Fri, 18 Apr 2003 08:16:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.8p1/8.12.8) with SMTP id h3IFGMt2026703 for <[e-mail]>; Fri, 18 Apr 2003 08:16:24 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 11529 invoked by uid 0); 18 Apr 2003 15:15:47 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.186.161) by woodstock.binhost.com with SMTP; 18 Apr 2003 15:15:47 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Fri, 18 Apr 2003 11:09:35 -0400
To: "Roberto Opazo Gazmuri" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: PI's RFC number
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>

The IESG sent some concerns to the authors earlier this week.  Those need 
to be resolved.

Russ


At 11:39 AM 4/17/2003 -0400, Roberto Opazo Gazmuri wrote:

>Hello everybody:
>
>Is there anybody who could estimate a date when we could reference the IETF
>Permanent Identifier work with an RFC number?
>
>The last call was on Mon, 25 Nov 2002.
>
>Best regards,
>
>Roberto Opazo



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IENKt2025022 for <[e-mail]>; Fri, 18 Apr 2003 07:23:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IENKTg025021 for ietf-pkix-bks; Fri, 18 Apr 2003 07:23:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IENGt2025015 for <[e-mail]>; Fri, 18 Apr 2003 07:23:16 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (unknown[12.81.120.164]) by mtiwmhc13.worldnet.att.net (mtiwmhc13) with SMTP id <20030418142252113000gonke>; Fri, 18 Apr 2003 14:22:53 +0000
Message-ID: <00c601c67a86$86797170$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Jeff Williams" <[e-mail]>, <[e-mail]>, "Lynn St.Amour" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <[e-mail]> <005801c3036e$e5232f00$020aff0a@tsg1> <p05100305bac1f918d257@[128.89.88.34]> <01ce01c67926$a1131ba0$020aff0a@tsg1> <p05100316bac3737d4c50@[128.89.88.34]> <02a101c67934$0fe58c40$020aff0a@tsg1> <[e-mail]>
Subject: Possible Solution: WAS Re: RFC3161(TSP): doubts about tcp protocol
Date: Thu, 18 May 2006 07:21:11 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks Jeff - I appreciate your words but Steve and I have been trading
commentary, nasty remarks, and insults for several years here including my
demands for him to retire, so I would think that by now everyone is pretty
much used to it. But thanks for the comment anyway.  As to the world around
this, Steve's supporter's just say "Damn what is Glassey doing now... that
J$%^&k..." or something stronger, and my supporters and the curious just
send me private email asking my why I put up with it. I probably get 3-5 of
those a day these days, including yours Jeff! (and BTW - all of those that
send those letters of encouragement - thanks!)

The answer is simple - Why I do this is to create a semi-permanent record of
the IETF's refusal to play by its own rules or insure a level and even
playing field.

You see this type of interchange supposedly creates a permanent record and
it is my feeling that this will eventually amount to enough evidence at some
point to have the US DoJ investigate the IETF and its management for
Antitrust and restraint of trade, which I hope will culminate in a US
Federal Court getting involved and in the Court's  telling the NTIA that its
contract with ICANN is illegal since it takes control of the "system" away
from the people it was built to serve. And - yes - I believe that this will
come to pass and that it is coming sooner than later.

As to my detractors, I just laugh at their refusal to see anything like the
real world. So its cool. We each have our own opinions on how things should
operate and I am the one proposing radical change, so you have to give them
space to vent. And remember that many of these people actually earn a living
by being the IETF liaison so any change to the process affects their Job and
these days that is really scary, but this is also why there is so much
Industry Interference in the IETF's processes - that being their need to
keep the processes loose and undefined so that those participants can slip
their standards through to support their products without attracting too
much attention. Hell look at IPSEC for instance.

The Problem - Maintaining the current value of the IP disclosure section of
an IETF document
--------------
But, the real issue here is probably more like whether there should be any
IP disclosure requirements inside an IETF draft or not, and especially ones
(those inside the Standards Process) that spend more than a calendar year in
the hopper such that the IP under them and around them is a moving target.
In a legal sense this would be phrased as a stale declaration, one that had
aged so much and was tied to such a specific point in time that it
there-after would have little or diminishing value moving forward in time.

So far what I think after reviewing this and how the IP disclosure was
implemented, I think that the any disclosure of any IP impingements on an
IETF draft or RFC creates a fiduciary responsibility to keep that portion of
the Draft or RFC accurate and current, so a partial disclosure is worse than
no disclosure and by a lot.

If this is true, then what than means is that each time the draft was
republished or changes state, then this same responsibility would like also
require that the IP implications section be updated and that is
realistically not something that most of our technical contributors have any
desire to participate in. Or that the Editor's of the drafts and RFC's have
time for now either.

The Proposed Solution - eliminate the need to do IP disclosure and replace
it with a Disclaimer
------------------------
With that said, the only option I see is to re-adopt the original policy of
replacing the "Patent Liabilities" section of the Draft or RFC with a
disclaimer stating "that it would be the adopter's responsibility to do a
complete patent or other IP search before adopting anything therein", and
that the IETF, because of its structure and process, cannot be held
accountable for keeping up to date on current IP implications re: any
specific submittal, other than what is required in the submitter's
disclosure that they indeed have the right to publish this document.

. Or they can choose to ignore these words and suffer the consequences if
there is an IP conflict over their use of those IP's.

I made this BTW, in an offline proposal to Steve yesterday.

Optional BCP's detailing IP issues
----------------------------------
I would also propose that anyone that wants to can also file a BCP style
informational draft on the legal aspects of using any specific IETF protocol
as a formal notice to the IETF and its participants regarding IP issues with
a protocol. I would also argue that this is a consistent use of the IETF as
a publishing house for new and emerging technologies. For instance if you
wanted to publish a statement regarding the patent aspects of using any
protocol(s), you could as a BCP statement, and that then would become a part
of the IETF's permanent record, and there would be a record within the IETF
that there were specific IP issues with a technology which puts the total
responsibility on the adopters for verifying that their implementation does
not run afoul of someone else's IP rights.

And as long as we are at it, lets add a section to the IP Disclosure rules
within 2026 (ss10) on "that the IETF is to be held blameless for disclosing
this information if the submitter turns out not to own the IP, or more
importantly, if there is IP-based litigation over the disclosure of the IP
itself, and that it is the responsibility of the Submitter to warrant that
the documents IP issues are addressed and that the document is legally fit
for publication". So then by this model it is the submitter that bears the
brunt of any legal attacks rather than the IETF.

---

Anyone have a problem with these comments? (other than it was me that made
them or you don't like my writing style?)...

Todd



----- Original Message -----
From: "Jeff Williams" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: "Stephen Kent" <[e-mail]>; "Ricardo Barroso"
<[e-mail]>; "Gianluca Ramunno" <[e-mail]>;
<[e-mail]>; <[e-mail]>; "Lynn St.Amour"
<[e-mail]>; <[e-mail]>
Sent: Friday, April 18, 2003 2:03 AM
Subject: Re: RFC3161(TSP): doubts about tcp protocol


> Todd, Stephen, and all,
>
>   Stephen, please discontinue your diatribe and obvious personal
> attack of Todd.  It is unseemly and unproductive..
>
> todd glassey wrote:
>
> > ----- Original Message -----
> > From: "Stephen Kent" <[e-mail]>
> > To: "todd glassey" <[e-mail]>
> > Cc: "Ricardo Barroso" <[e-mail]>; "Gianluca
Ramunno"
> > <[e-mail]>; <[e-mail]>; <[e-mail]>; "Lynn
> > St.Amour" <[e-mail]>; <[e-mail]>
> > Sent: Wednesday, April 16, 2003 2:41 PM
> > Subject: Re: RFC3161(TSP): doubts about tcp protocol
> >
> > > At 1:22 PM -0700 5/16/06, todd glassey wrote:
> > > >Look Dr. Kent - the issue here is that you do not invalidate what I
am
> > > >saying you just attack me personally.  If I am wrong I humbly
apologize
> > but
> > > >so far this is 100% dead-on by my take. So lets get to debunking your
> > > >commentary from the last response -
> > > >
> > >
> > > It appears that Todd can't distinguish between statements of fact
> > > about IP issues and personal criticism.
> > >
> > > Personal criticism would be more along the lines of suggesting that
> > > he is engaging in fear mongering at this stage of the standards
> > > process, perhaps because he tried and failed to block the advancement
> > > of TSP through the WG process, in IETF last call, and via direct
> > > appeal to the IESG. But even that observation is based on facts that
> > > are part of the public record; only the motivation aspect of the
> > > comment might be considered personal criticism.
> >
> > Fear Mongering implies that there is something wrong with what I am
saying
> > or that there is inaccuracy in it and that is not true. So in this
instance
> > I again claim that you use your status as the WG Chair to invalidate
what I
> > am saying becuase I am saying it without ever invalidating  the
statement
> > itself.
> >
> > >
> > > The simple fact is that there have been many claims in the area of
> > > secure time stamping, going back at least as far as the PB patent
> > > cited by Todd. Some of these claims are quite broad. The more modern
> > > ones often make explicit reference to digital signature mechanisms,
> > > whereas the original PB patent does not. The applicability of any
> > > patent to the RFC 3161 protocol is a matter for lawyers and the
> > > courts to determine.
> > >
> > > Mr. Glassey is not a lawyer, although he sometimes seems to forget
> > > that. Thus his assertions about what patents may be violated by a
> > > product that implements 3161 are not legal opinions and there is good
> > > reason to believe that they are motivated by other than simple,
> > > objective, technical observations, based on previous messages on this
> > > list.
> >
> > This is true and I do want to see my patent's supported but I also want
all
> > other TS technologies to get their fair shake in the commercial world
rather
> > then being mandated by a standards org process. There is enough room for
all
> > of us here. What's wrong with that comment other than it leaves you out
of
> > the bigger picture Steve?
> >
> > >
> > > As I noted in my earlier message, in the one legal case that is
> > > clearly relevant to this discussion, a patent holder who made very
> > > broad claims about time stamping sued a vendor who implemented a
> > > TSP-like capability in a product. The defendant prevailed, and the
> > > plaintiff had four broad patent claims disallowed as a result.
> >
> > I can send you a copy of the transscript for the case if you want - Its
> > number 99-203 in the Western Dist of Va, Feb 1999. - Surety V Entrust.
We
> > got a copy of it after I got the letter from Surety at Coastek about my
> > first timestamping tools so that when I started CertifiedTime in August
of
> > 1999 I would know what was what.
> >
> > >
> > > know that I am not a lawyer and thus not qualified to advise
> > > prospective implementors about the implications of this court
> > > decision,
> >
> > Then why did you?
> >
> > > but as an individual technologist I did take away a
> > > positive message relative to 3161.
> >
> > That doesnt answer the question I asked - you made a public commentary -
> > what did you make it as? Please answer this question.
> >
> > > or for that matter any other standards body with which I am familiar,
> > > addresses these issues.
> >
> > Then dont make broad sweeping claims about the legal status of any
> > submission as you have.
> >
> > > RFC 2026 describes the IETF process re IP
> > > issues.
> >
> > The problem is that 2026 is couched to prevent any liability from being
> > ascribed to the IETF and that is what you always hide behind. So until
you
> > invalidate what it is I said Steve this is obvously just another one of
> > those things we will disagree on.
> >
> > >
> > > Steve
>
> Regards,
>
> --
> Jeffrey A. Williams
> Spokesman for INEGroup LLA. - (Over 129k members/stakeholders strong!)
> ================================================================
> CEO/DIR. Internet Network Eng. SR. Eng. Network data security
> Information Network Eng. Group. INEG. INC.
> E-Mail [e-mail]
> Contact Number: 214-244-4827 or 214-244-3801
>
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IDltt2022802 for <[e-mail]>; Fri, 18 Apr 2003 06:47:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IDlsNG022801 for ietf-pkix-bks; Fri, 18 Apr 2003 06:47:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IDlrt2022760 for <[e-mail]>; Fri, 18 Apr 2003 06:47:54 -0700 (PDT) (envelope-from [e-mail])
Received: from p4 (12-224-63-6.client.attbi.com[12.224.63.6]) by sccrmhc03.attbi.com (sccrmhc03) with SMTP id <200304181347430030054f9ue>; Fri, 18 Apr 2003 13:47:44 +0000
Message-Id: <3.0.5.32.20030418064743.01ed0ad0@localhost>
X-Sender: cme@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Fri, 18 Apr 2003 06:47:43 -0700
To: [e-mail]
From: Carl Ellison <[e-mail]>
Subject: 2003 PKI Research Workshop
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h3IDlst2022796
Sender: [e-mail]
Precedence: 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 2nd Annual PKI Research Workshop is almost here: April 28-29, 2003
at NIST in Gaithersburg, MD.

The program features a broad variety of perspectives, new developments
and results on the use of public key technology for security decision
making.  There are talks and panel sessions on human interface issues,
trust, identity management, SAML and of course PKI. The refereed papers
touch a variety of topics including authorization issues, enrollment,
novel architectures, CA for ad-hoc networks and much more.  Get an
update on the field, compare notes with leading researchers, discuss the
past, present and future & bring your own Work-In-Progress for an
evening session.

Sign up by April 22nd at
     http://middleware.internet2.edu/pki03/

Neal McBurnett                 http://bcn.boulder.co.us/~neal/
Signed and/or sealed mail encouraged.  GPG/PGP Keyid: 2C9EBA60


   2nd Annual PKI Research Workshop Preliminary Program

   Monday April 28th, 2003

   The bus from the hotel will leave at 7:45AM on Monday and 8:15AM on
   Tuesday. The bus will leave NIST immediately (5-10 minutes) after the
   end of the last session.
   ______________________________________________________________________

   Mon 08:00 - 09:00:  Registration and Coffee
   ______________________________________________________________________

   Mon 09:00 - 09:30:  Opening Remarks
     * Ken Klingenstein, Director of Internet2 Middleware Initiative;
       General Chair
     * Carl Ellison - Intel; Program Chair
   ______________________________________________________________________

   Mon 09:30 - 10:30:  Invited Talk
     * Making PKI Usable: Some Issues, Techniques, and Results
          + Alma Whitten, University of California, Berkeley
   ______________________________________________________________________

   Mon 10:30 - 11:00:  Coffee break
   ______________________________________________________________________

   Mon 11:00 - 12:30:  Referreed Papers: Enrollment
     * An Overview of Public Key Certificate Support for Canada's
       Government On-Line (GOL) Initiative
          + Mike Just, Treasury Board of Canada, Secretariat
     * FreeICP.ORG: Free Trusted Certiicates by Combining the X.509 and
       PGP Hierarchy Through a Collaborative Trust Scoring System
          + Marco Antônio Carnut, Evandro Curvelo Hora, Cristiano Lincoln
            Mattos : Tempest Security Technologies; Fábio Silva,
            Universidade Federal de Pernambuco - CIn/UFPE, Brazil
     * Improving Message Security With a Self-Assembling PKI
          + Jon Callas, PGP Corporation
   ______________________________________________________________________

   Mon 12:30 - 14:00:  Lunch break
   ______________________________________________________________________

   Mon 14:00 - 15:30:  Referreed Papers: Security of the CA
     * Intrusion Tolerant Password-Enabled PKI
          + Xunhua Wang, James Madison University
     * Decentralization Methods of Certification Authority Using the
       Digital Signature Schemes
          + Satoshi Koga, Kouichi Sakurai, Kyushu University, Japan
     * MOCA: Mobile Certificate Authority for Wireless Ad Hoc Networks
          + Seung Yi, Robin Cravets, University of Illinois at
            Urbana-Champaign
   ______________________________________________________________________

   Mon 15:30 - 16:00:  Coffee break
   ______________________________________________________________________

   Mon 16:00 - 17:30:  ReThinking Trust
     * This session will present the current state of trust models and
       practices in networked communities. It will look at macro models
       (hierarchies and bridges, federations, virtual organizations, etc)
       and micro models (static and run time trust decision
       architectures). It will then drill down into federated trust and
       discuss current deployments. There will be discussions around some
       of the emergent issues in federations, including multiple
       federations, multi-use federations, and managing trust.

     * Ken Klingenstein, Internet2
   ______________________________________________________________________

   Mon 18:15: Social Gathering and Conference Dinner at the Holiday Inn.
     * A cash bar will be available at 6:15PM with dinner starting at
       6:45PM.
   ______________________________________________________________________

   Mon 20:00 - ??:  Work In Progess Session
     * Organized by Peter Honeyman, University of Michigan
   ______________________________________________________________________

   Tuesday April 29, 2003
   The bus from the hotel will leave at 8:15AM on  Tuesday. The bus will
   leave NIST immediately (5-10 minutes) after the end of the last
   session.
   ______________________________________________________________________

   Mon 08:30 - 09:00:  Coffee
   ______________________________________________________________________

   Tue 09:00 - 10:30:  Referreed Papers: Authorization
     * Mediating Between Strangers: A Trust Management Based Approach
          + Joachim Biskup, Yücel Karabulut, Universität Dortmund,
            Germany
     * Electronic Signature System with Small Number of Private Keys
          + Ahto Buldas, Tallinn Technical University, Estonia; Märt
            Saarepera, Independent
     * Privacy-enhanced credential services
          + Alex Iliev, Sean Smith, Dartmouth College
   ______________________________________________________________________

   Tue 10:30 - 11:00:  Coffee break
   ______________________________________________________________________

   Tue 11:00 - 12:30:  Panel: Attribute Certificates
     * Organized by Tim Polk, NIST
   ______________________________________________________________________

   Tue 12:30 - 13:30:  Lunch break
   ______________________________________________________________________

   Tue 13:30 - 15:00:  Panel: Transports for Trust - Technology View
    1. Transports  for  trust  (PKI,  SAML,etc.) - when to use which, how
       they can interact, etc.
    2. Implementation   experience   with   SAML  and  relevance  to  PKI
       (Shibboleth et al)
    3. Identity Management topics - SAML applications in Liberty et al.
    4. Update  on  SAML TC - what the TC is working on now and what is in
       the future
    5. Q & A from the audience.

     * Moderator: Krishna Sankar, Cisco Systems
     * Panelists: Scott Cantor - Ohio State/I2-Shibboleth, Carlisle Adams
       - Entrust, Irving Reid - Baltimore, Bronislav Kavsan - RSA/Liberty
       Alliance
   ______________________________________________________________________

   Tue 15:00:  Coffee break
   ______________________________________________________________________

   Tue: 15:30 - 16:30:  Referreed Papers: Attacks
     * On the usefulness of proof-of-possession
          + N.  Asokan,  Valtteri  Niemi,  Pekka Laitinen, Nokia Research
            Center, Finland
     * Keyjacking: Risks of the Current Client-side Infrastructure
          + John Marchesini, S. W. Smith, Meiyuan Zhao, Dartmouth College
   ______________________________________________________________________

   Tue 16:30 - 17:30:  Book Project / Wrap-up Discussion
     * Eugene C. McDowell, National Oceanic & Atmospheric Administration
   ______________________________________________________________________





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IBIpt2015870 for <[e-mail]>; Fri, 18 Apr 2003 04:18:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IBIo94015869 for ietf-pkix-bks; Fri, 18 Apr 2003 04:18:50 -0700 (PDT)
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.8p1/8.12.8) with ESMTP id h3IBInt2015864 for <[e-mail]>; Fri, 18 Apr 2003 04:18:50 -0700 (PDT) (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 HAA08518; Fri, 18 Apr 2003 07:16:09 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-proxy-05.txt
Date: Fri, 18 Apr 2003 07:16:08 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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-05.txt
	Pages		: 45
	Date		: 2003-4-17
	
This document forms a certificate profile for Proxy 
Certificates, based on X.509 PKI certificates as defined 
in RFC 3280, 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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-proxy-05.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-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-proxy-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-proxy-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-proxy-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 [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HH3et2053257 for <[e-mail]>; Thu, 17 Apr 2003 10:03:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HH3eXb053256 for ietf-pkix-bks; Thu, 17 Apr 2003 10:03:40 -0700 (PDT)
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.8p1/8.12.8) with ESMTP id h3HH3dt2053249 for <[e-mail]>; Thu, 17 Apr 2003 10:03:39 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h3HH3T5w016937; Thu, 17 Apr 2003 13:03:29 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100310bac48e7eca33@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 17 Apr 2003 13:03:09 -0400
To: "Roberto Opazo Gazmuri" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: PI's RFC number
Cc: <[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>

>Hello everybody:
>
>Is there anybody who could estimate a date when we could reference the IETF
>Permanent Identifier work with an RFC number?
>
>The last call was on Mon, 25 Nov 2002.
>
>Best regards,
>
>Roberto Opazo

Roberto,

The document was returned by the IESG with a variety of minor and 
major concerns, which are now being worked. The document cannot 
progress ot an RFC until the issues they raised are addressed.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HGrnt2052906 for <[e-mail]>; Thu, 17 Apr 2003 09:53:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HGrn3v052905 for ietf-pkix-bks; Thu, 17 Apr 2003 09:53:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from osf1.gmu.edu (osf1.gmu.edu [129.174.1.13]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HGrkt2052900 for <[e-mail]>; Thu, 17 Apr 2003 09:53:46 -0700 (PDT) (envelope-from [e-mail])
Received: from phessel (gemini@[129.174.244.115]) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id MAA381813; Thu, 17 Apr 2003 12:53:36 -0400 (EDT)
Reply-To: <[e-mail]>
From: "Peter Hesse" <[e-mail]>
To: "'todd glassey'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: RFC3161(TSP): doubts about tcp protocol
Date: Thu, 17 Apr 2003 12:53:34 -0400
Organization: Gemini Security Solutions, Inc.
Message-ID: <004601c30501$e880fee0$6401a8c0@phessel>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
In-Reply-To: <02a101c67934$0fe58c40$020aff0a@tsg1>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
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,

>This is true and I do want to see my patent's supported but I also 
>want all other TS technologies to get their fair shake in the 
>commercial world rather then being mandated by a standards org process.


I suggest you read http://angryflower.com/bobsqu.gif

Proper grammar combined with ridiculous personal attacks will probably
get you farther than ridiculous personal attacks alone.

--Peter


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of todd glassey
Sent: Tuesday, May 16, 2006 6:00 PM
To: Stephen Kent
Cc: Ricardo Barroso; Gianluca Ramunno; [e-mail];
[e-mail]; Lynn St.Amour; [e-mail]
Subject: Re: RFC3161(TSP): doubts about tcp protocol




----- Original Message -----
From: "Stephen Kent" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: "Ricardo Barroso" <[e-mail]>; "Gianluca
Ramunno" <[e-mail]>; <[e-mail]>;
<[e-mail]>; "Lynn St.Amour" <[e-mail]>;
<[e-mail]>
Sent: Wednesday, April 16, 2003 2:41 PM
Subject: Re: RFC3161(TSP): doubts about tcp protocol


> At 1:22 PM -0700 5/16/06, todd glassey wrote:
> >Look Dr. Kent - the issue here is that you do not invalidate what I 
> >am saying you just attack me personally.  If I am wrong I humbly 
> >apologize
but
> >so far this is 100% dead-on by my take. So lets get to debunking your

> >commentary from the last response -
> >
>
> It appears that Todd can't distinguish between statements of fact 
> about IP issues and personal criticism.
>
> Personal criticism would be more along the lines of suggesting that he

> is engaging in fear mongering at this stage of the standards process, 
> perhaps because he tried and failed to block the advancement of TSP 
> through the WG process, in IETF last call, and via direct appeal to 
> the IESG. But even that observation is based on facts that are part of

> the public record; only the motivation aspect of the comment might be 
> considered personal criticism.

Fear Mongering implies that there is something wrong with what I am
saying or that there is inaccuracy in it and that is not true. So in
this instance I again claim that you use your status as the WG Chair to
invalidate what I am saying becuase I am saying it without ever
invalidating  the statement itself.

>
> The simple fact is that there have been many claims in the area of 
> secure time stamping, going back at least as far as the PB patent 
> cited by Todd. Some of these claims are quite broad. The more modern 
> ones often make explicit reference to digital signature mechanisms, 
> whereas the original PB patent does not. The applicability of any 
> patent to the RFC 3161 protocol is a matter for lawyers and the courts

> to determine.
>
> Mr. Glassey is not a lawyer, although he sometimes seems to forget 
> that. Thus his assertions about what patents may be violated by a 
> product that implements 3161 are not legal opinions and there is good 
> reason to believe that they are motivated by other than simple, 
> objective, technical observations, based on previous messages on this 
> list.

This is true and I do want to see my patent's supported but I also want
all other TS technologies to get their fair shake in the commercial
world rather then being mandated by a standards org process. There is
enough room for all of us here. What's wrong with that comment other
than it leaves you out of the bigger picture Steve?

>
> As I noted in my earlier message, in the one legal case that is 
> clearly relevant to this discussion, a patent holder who made very 
> broad claims about time stamping sued a vendor who implemented a 
> TSP-like capability in a product. The defendant prevailed, and the 
> plaintiff had four broad patent claims disallowed as a result.

I can send you a copy of the transscript for the case if you want - Its
number 99-203 in the Western Dist of Va, Feb 1999. - Surety V Entrust.
We got a copy of it after I got the letter from Surety at Coastek about
my first timestamping tools so that when I started CertifiedTime in
August of 1999 I would know what was what.

>
> know that I am not a lawyer and thus not qualified to advise 
> prospective implementors about the implications of this court 
> decision,

Then why did you?

> but as an individual technologist I did take away a
> positive message relative to 3161.

That doesnt answer the question I asked - you made a public commentary -
what did you make it as? Please answer this question.

> or for that matter any other standards body with which I am familiar, 
> addresses these issues.

Then dont make broad sweeping claims about the legal status of any
submission as you have.

> RFC 2026 describes the IETF process re IP
> issues.

The problem is that 2026 is couched to prevent any liability from being
ascribed to the IETF and that is what you always hide behind. So until
you invalidate what it is I said Steve this is obvously just another one
of those things we will disagree on.

>
> Steve




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HFdUt2049703 for <[e-mail]>; Thu, 17 Apr 2003 08:39:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HFdUB0049702 for ietf-pkix-bks; Thu, 17 Apr 2003 08:39:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.custodium.com ([200.68.2.38]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HFdRt2049695 for <[e-mail]>; Thu, 17 Apr 2003 08:39:28 -0700 (PDT) (envelope-from [e-mail])
Received: from ropazo (ns.custodium.cl [216.241.20.226] (may be forged)) by mail.custodium.com (8.12.2/8.12.2) with SMTP id h3HFd5L0014047 for <[e-mail]>; Thu, 17 Apr 2003 11:39:16 -0400
From: "Roberto Opazo Gazmuri" <[e-mail]>
To: <[e-mail]>
Subject: =?iso-8859-1?Q?PI's_RFC_number?=
Date: Thu, 17 Apr 2003 11:39:28 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
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>

Hello everybody:

Is there anybody who could estimate a date when we could reference the IETF
Permanent Identifier work with an RFC number?

The last call was on Mon, 25 Nov 2002.

Best regards,

Roberto Opazo



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HEpEt2047331 for <[e-mail]>; Thu, 17 Apr 2003 07:51:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HEpEjL047330 for ietf-pkix-bks; Thu, 17 Apr 2003 07:51:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HEpCt2047325 for <[e-mail]>; Thu, 17 Apr 2003 07:51:12 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (88.sanfrancisco-12rh16rt-ca.dial-access.att.net[12.81.119.88]) by mtiwmhc13.worldnet.att.net (mtiwmhc13) with SMTP id <20030417145106113000fkk6e>; Thu, 17 Apr 2003 14:51:07 +0000
Message-ID: <004301c679c1$4f5cab00$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Antonio Lioy" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "Lynn St.Amour" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <[e-mail]> <005801c3036e$e5232f00$020aff0a@tsg1> <p05100305bac1f918d257@[128.89.88.34]> <01ce01c67926$a1131ba0$020aff0a@tsg1> <[e-mail]>
Subject: Re: RFC3161(TSP): doubts about tcp protocol
Date: Wed, 17 May 2006 07:38:25 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Antonio - I will respond to this personally to you off the main list. lets
not waste the list's traffic on this anymore

Todd

----- Original Message -----
From: "Antonio Lioy" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; "Lynn St.Amour"
<[e-mail]>; <[e-mail]>
Sent: Thursday, April 17, 2003 12:12 AM
Subject: Re: RFC3161(TSP): doubts about tcp protocol


>
> todd glassey wrote:
> > Look Dr. Kent - the issue here is that you do not invalidate what I am
> > saying you just attack me personally.  If I am wrong I humbly apologize
but
> > so far this is 100% dead-on by my take. So lets get to debunking your
> > commentary from the last response -
> >
> > What are all these  numbers the rest of you folks might ask - Steve
already
> > knows what they are - they are some of the many patents that any of you
may
> > violate by building something out of 3161's technology and these are
just
> > the ones listed on the references section of the eOriginals Patent filed
in
> > 2001. And - this is just a partial list - there are more, like mine
> > (EP808997A)
> > for instance, so rather than attacking me personally Steve - lets try
this
> > again - how about disproving anything I said??? I don't think you can...
> >
> > 4200770 4405829 4625076 4853961 4893338
> > 4981370 4995082 5005200 5136646 5136647
> > 5163091 5164988 5191613 5214703 5231668
> > 5276737 5315658 5323146 5339361 5363448
> > 5371794 5373561 5377270 5390247 5524073
> > 5534855 5555307 5615268 5699431 5748738
> > 5987429 6023509 6070239
> >
> > But lets keep this up anyway. As far as receipts based on the RFC3161
> > protocol, my take there is that the Pitney Bowes patent probably covers
that
> > too, but if you think I am wrong  then maybe PKIX should  get a lawyer,
or
> > better yet a Judge to say that in an opinion. Or maybe in this case the
> > authors of RFC3161 and their company's should be paying for having a
legal
> > opinion rendered since they and you claim that the use of their
technology
> > does not violate these larger-picture patents - Eh Carlisle - how
> > about it? Does Sharon have budget for this?
>
> All this discussion appears to be strongly biased towards the US
> approach to patents.
> However, Internet is an international entity and RFC-3161 has a much
> wider application than just to US companies.
> I note that in Europe at least EESSI, ETSI and the Italian government
> are suggesting or mandating the use of timestamps and RFC-3161 is the
> de-facto standard in this field.
> In general, the US patents are not valid in other countries unless they
> have been registered *prior* to pubblication (as well shown by the RSA
> patent in the last 30 years). So we strongly think that RFC-3161 is
> providing a good service for all these other countries and we leave to
> US citizens, companies and courts the discussion if the mentioned
> patents hold or not. For the vast majority of Internet the answer is
> simply NO!
> So please Todd, take this case to courts and leave Internet be free to
> set up a good technical standard to be used at least in that part of the
> world outside US.
>
> Cheers,
>
> Antonio Lioy
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HEQSt2046625 for <[e-mail]>; Thu, 17 Apr 2003 07:26:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HEQSHc046624 for ietf-pkix-bks; Thu, 17 Apr 2003 07:26:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HEQQt2046619 for <[e-mail]>; Thu, 17 Apr 2003 07:26:26 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (88.sanfrancisco-12rh16rt-ca.dial-access.att.net[12.81.119.88]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <20030417142620111002rreje>; Thu, 17 Apr 2003 14:26:21 +0000
Message-ID: <003101c679bd$d94b04f0$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]> <005801c3036e$e5232f00$020aff0a@tsg1> <p05100305bac1f918d257@[128.89.88.34]> <01ce01c67926$a1131ba0$020aff0a@tsg1> <p05100316bac3737d4c50@[128.89.88.34]> <02a101c67934$0fe58c40$020aff0a@tsg1> <p05100303bac45f58b680@[128.89.88.34]>
Subject: Re: RFC3161(TSP): doubts about tcp protocol
Date: Wed, 17 May 2006 07:03:56 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: 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 - the things I have to reply to this I will cc to Tim but there is
little point in continuing this conversation. Lets just leave it that I
forced the issue into the spotlight again so it will appear in the mailing
list archive unless its edited out,  and you folks (you and Tim as the WG
Chairs) can ride the wave whatever happens.

Todd
----- Original Message -----
From: "Stephen Kent" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, April 17, 2003 6:47 AM
Subject: Re: RFC3161(TSP): doubts about tcp protocol


> Todd,
>
> I don't need to play by your rules (e.g., meeting your criteria for
> invalidating what you assert) to convey my message in this forum.
>
> My comments are rational and clear, unlike most of yours.
>
> You seem to confuse cause and effect. It is not that people pay
> attention to what I say primarily because I am the PKIX WG chair.
> Rather, in part, I was selected to serve as chair because of my
> knowledge in the area. Thus people often pay attention to what I say
> because what I say generally makes sense, and is usually correct,
> irrespective of my role in this WG.
>
> Steve



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HDsHt2045663 for <[e-mail]>; Thu, 17 Apr 2003 06:54:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HDsG0g045662 for ietf-pkix-bks; Thu, 17 Apr 2003 06:54:16 -0700 (PDT)
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.8p1/8.12.8) with ESMTP id h3HDs2t2045643 for <[e-mail]>; Thu, 17 Apr 2003 06:54:15 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h3HDrr5w001907; Thu, 17 Apr 2003 09:53:53 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100303bac45f58b680@[128.89.88.34]>
In-Reply-To: <02a101c67934$0fe58c40$020aff0a@tsg1>
References: <[e-mail]> <[e-mail]> <005801c3036e$e5232f00$020aff0a@tsg1> <p05100305bac1f918d257@[128.89.88.34]> <01ce01c67926$a1131ba0$020aff0a@tsg1> <p05100316bac3737d4c50@[128.89.88.34]> <02a101c67934$0fe58c40$020aff0a@tsg1>
Date: Thu, 17 Apr 2003 09:47:21 -0400
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: RFC3161(TSP): doubts about tcp protocol
Cc: <[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>

Todd,

I don't need to play by your rules (e.g., meeting your criteria for 
invalidating what you assert) to convey my message in this forum.

My comments are rational and clear, unlike most of yours.

You seem to confuse cause and effect. It is not that people pay 
attention to what I say primarily because I am the PKIX WG chair. 
Rather, in part, I was selected to serve as chair because of my 
knowledge in the area. Thus people often pay attention to what I say 
because what I say generally makes sense, and is usually correct, 
irrespective of my role in this WG.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3H7Cet2009767 for <[e-mail]>; Thu, 17 Apr 2003 00:12:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3H7CdwU009766 for ietf-pkix-bks; Thu, 17 Apr 2003 00:12:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from polito.it (terra.polito.it [130.192.3.81]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3H7Cbt2009758 for <[e-mail]>; Thu, 17 Apr 2003 00:12:38 -0700 (PDT) (envelope-from [e-mail])
Received: from [130.192.1.64] (HELO polito.it) by polito.it (CommuniGate Pro SMTP 4.0.6) with ESMTP-TLS id 6084117; Thu, 17 Apr 2003 09:06:18 +0200
Message-ID: <[e-mail]>
Date: Thu, 17 Apr 2003 09:12:36 +0200
From: Antonio Lioy <[e-mail]>
Organization: Politecnico di Torino
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: todd glassey <[e-mail]>
CC: [e-mail], [e-mail], "Lynn St.Amour" <[e-mail]>, [e-mail]
Subject: Re: RFC3161(TSP): doubts about tcp protocol
References: <[e-mail]> <[e-mail]> <005801c3036e$e5232f00$020aff0a@tsg1> <p05100305bac1f918d257@[128.89.88.34]> <01ce01c67926$a1131ba0$020aff0a@tsg1>
In-Reply-To: <01ce01c67926$a1131ba0$020aff0a@tsg1>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

todd glassey wrote:
> Look Dr. Kent - the issue here is that you do not invalidate what I am
> saying you just attack me personally.  If I am wrong I humbly apologize but
> so far this is 100% dead-on by my take. So lets get to debunking your
> commentary from the last response -
> 
> What are all these  numbers the rest of you folks might ask - Steve already
> knows what they are - they are some of the many patents that any of you may
> violate by building something out of 3161's technology and these are just
> the ones listed on the references section of the eOriginals Patent filed in
> 2001. And - this is just a partial list - there are more, like mine
> (EP808997A)
> for instance, so rather than attacking me personally Steve - lets try this
> again - how about disproving anything I said??? I don't think you can...
> 
> 4200770 4405829 4625076 4853961 4893338
> 4981370 4995082 5005200 5136646 5136647
> 5163091 5164988 5191613 5214703 5231668
> 5276737 5315658 5323146 5339361 5363448
> 5371794 5373561 5377270 5390247 5524073
> 5534855 5555307 5615268 5699431 5748738
> 5987429 6023509 6070239
> 
> But lets keep this up anyway. As far as receipts based on the RFC3161
> protocol, my take there is that the Pitney Bowes patent probably covers that
> too, but if you think I am wrong  then maybe PKIX should  get a lawyer, or
> better yet a Judge to say that in an opinion. Or maybe in this case the
> authors of RFC3161 and their company's should be paying for having a legal
> opinion rendered since they and you claim that the use of their technology
> does not violate these larger-picture patents - Eh Carlisle - how
> about it? Does Sharon have budget for this?

All this discussion appears to be strongly biased towards the US 
approach to patents.
However, Internet is an international entity and RFC-3161 has a much 
wider application than just to US companies.
I note that in Europe at least EESSI, ETSI and the Italian government 
are suggesting or mandating the use of timestamps and RFC-3161 is the 
de-facto standard in this field.
In general, the US patents are not valid in other countries unless they 
have been registered *prior* to pubblication (as well shown by the RSA 
patent in the last 30 years). So we strongly think that RFC-3161 is 
providing a good service for all these other countries and we leave to 
US citizens, companies and courts the discussion if the mentioned 
patents hold or not. For the vast majority of Internet the answer is 
simply NO!
So please Todd, take this case to courts and leave Internet be free to 
set up a good technical standard to be used at least in that part of the 
world outside US.

Cheers,

Antonio Lioy



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GM3Gt2078433 for <[e-mail]>; Wed, 16 Apr 2003 15:03:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3GM3GmJ078432 for ietf-pkix-bks; Wed, 16 Apr 2003 15:03:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sottmxssm.entrust.com (sottmxssm.entrust.com [216.191.252.10]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GM3Ft2078423 for <[e-mail]>; Wed, 16 Apr 2003 15:03:15 -0700 (PDT) (envelope-from [e-mail])
Received: from sottguard01.entrust.com (sottguard01.entrust.com [10.4.61.249]) by sottmxssm.entrust.com (Switch-2.2.6/Switch-2.2.4) with SMTP id V3GM00HB31632 for <[e-mail]>; Wed, 16 Apr 2003 18:00:17 -0400
Received: (qmail 25648 invoked by uid 64014); 16 Apr 2003 22:02:03 -0000
Received: from [e-mail] by sottguard01.entrust.com with AmikaGuardian-Server-1.1.2 (Processed in 0.437554 secs); 16 Apr 2003 22:02:03 -0000
Received: from unknown (HELO SOTTMXS01.entrust.com) (10.4.61.7) by 10.4.61.249 with SMTP; 16 Apr 2003 22:02:03 -0000
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <2ZN4TM12>; Wed, 16 Apr 2003 18:03:10 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'todd glassey'" <[e-mail]>, Stephen Kent <[e-mail]>
Cc: Ricardo Barroso <[e-mail]>, Gianluca Ramunno <[e-mail]>, [e-mail], [e-mail], "Lynn St.Amour" <[e-mail]>, [e-mail]
Subject: RE: RFC3161(TSP): doubts about tcp protocol
Date: Wed, 16 Apr 2003 18:03:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
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,

I've deleted all the text that has too many errors -- or is just plain too
"off-the-wall" -- to be worth a response.

See my one response below, prefixed by [Carlisle].


-----Original Message-----
From: todd glassey [mailto:[e-mail]]
Sent: Tuesday, May 16, 2006 4:22 PM
To: Stephen Kent
Cc: Ricardo Barroso; Gianluca Ramunno; [e-mail];
[e-mail]; Lynn St.Amour; [e-mail]
Subject: Re: RFC3161(TSP): doubts about tcp protocol

> Or maybe in this case the
> authors of RFC3161 and their company's should be paying for having a 
> legal opinion rendered since they and you claim that the use of their 
> technology does not violate these larger-picture patents - Eh Carlisle - 
> how about it? Does Sharon have budget for this?

[Carlisle]  You need to check your facts before throwing accusations around.
The actual truth is that I have never made any such claim, period.  Most
people know better than to publicly volunteer patent opinions one way or
another with respect to their employer's technologies, and I count myself in
that group.  As for Sharon, she is a colleague of mine and has no control
whatsoever over Entrust budget.  I can't help it if you like to dream things
up and then believe them, but you need to be careful when you begin to spout
them in public fora.  I'll thank you to retract your statement.  Now.


> just my 2 cents

[Carlisle]  That's more than I would pay for it.

Carlisle.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GM09t2078198 for <[e-mail]>; Wed, 16 Apr 2003 15:00:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3GM09WB078197 for ietf-pkix-bks; Wed, 16 Apr 2003 15:00:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GM07t2078187 for <[e-mail]>; Wed, 16 Apr 2003 15:00:08 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (unknown[12.81.120.186]) by mtiwmhc13.worldnet.att.net (mtiwmhc13) with SMTP id <20030416220000113000gi75e>; Wed, 16 Apr 2003 22:00:01 +0000
Message-ID: <02a101c67934$0fe58c40$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: "Ricardo Barroso" <[e-mail]>, "Gianluca Ramunno" <[e-mail]>, <[e-mail]>, <[e-mail]>, "Lynn St.Amour" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <[e-mail]> <005801c3036e$e5232f00$020aff0a@tsg1> <p05100305bac1f918d257@[128.89.88.34]> <01ce01c67926$a1131ba0$020aff0a@tsg1> <p05100316bac3737d4c50@[128.89.88.34]>
Subject: Re: RFC3161(TSP): doubts about tcp protocol
Date: Tue, 16 May 2006 14:59:47 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: 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: "Stephen Kent" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: "Ricardo Barroso" <[e-mail]>; "Gianluca Ramunno"
<[e-mail]>; <[e-mail]>; <[e-mail]>; "Lynn
St.Amour" <[e-mail]>; <[e-mail]>
Sent: Wednesday, April 16, 2003 2:41 PM
Subject: Re: RFC3161(TSP): doubts about tcp protocol


> At 1:22 PM -0700 5/16/06, todd glassey wrote:
> >Look Dr. Kent - the issue here is that you do not invalidate what I am
> >saying you just attack me personally.  If I am wrong I humbly apologize
but
> >so far this is 100% dead-on by my take. So lets get to debunking your
> >commentary from the last response -
> >
>
> It appears that Todd can't distinguish between statements of fact
> about IP issues and personal criticism.
>
> Personal criticism would be more along the lines of suggesting that
> he is engaging in fear mongering at this stage of the standards
> process, perhaps because he tried and failed to block the advancement
> of TSP through the WG process, in IETF last call, and via direct
> appeal to the IESG. But even that observation is based on facts that
> are part of the public record; only the motivation aspect of the
> comment might be considered personal criticism.

Fear Mongering implies that there is something wrong with what I am saying
or that there is inaccuracy in it and that is not true. So in this instance
I again claim that you use your status as the WG Chair to invalidate what I
am saying becuase I am saying it without ever invalidating  the statement
itself.

>
> The simple fact is that there have been many claims in the area of
> secure time stamping, going back at least as far as the PB patent
> cited by Todd. Some of these claims are quite broad. The more modern
> ones often make explicit reference to digital signature mechanisms,
> whereas the original PB patent does not. The applicability of any
> patent to the RFC 3161 protocol is a matter for lawyers and the
> courts to determine.
>
> Mr. Glassey is not a lawyer, although he sometimes seems to forget
> that. Thus his assertions about what patents may be violated by a
> product that implements 3161 are not legal opinions and there is good
> reason to believe that they are motivated by other than simple,
> objective, technical observations, based on previous messages on this
> list.

This is true and I do want to see my patent's supported but I also want all
other TS technologies to get their fair shake in the commercial world rather
then being mandated by a standards org process. There is enough room for all
of us here. What's wrong with that comment other than it leaves you out of
the bigger picture Steve?

>
> As I noted in my earlier message, in the one legal case that is
> clearly relevant to this discussion, a patent holder who made very
> broad claims about time stamping sued a vendor who implemented a
> TSP-like capability in a product. The defendant prevailed, and the
> plaintiff had four broad patent claims disallowed as a result.

I can send you a copy of the transscript for the case if you want - Its
number 99-203 in the Western Dist of Va, Feb 1999. - Surety V Entrust. We
got a copy of it after I got the letter from Surety at Coastek about my
first timestamping tools so that when I started CertifiedTime in August of
1999 I would know what was what.

>
> know that I am not a lawyer and thus not qualified to advise
> prospective implementors about the implications of this court
> decision,

Then why did you?

> but as an individual technologist I did take away a
> positive message relative to 3161.

That doesnt answer the question I asked - you made a public commentary -
what did you make it as? Please answer this question.

> or for that matter any other standards body with which I am familiar,
> addresses these issues.

Then dont make broad sweeping claims about the legal status of any
submission as you have.

> RFC 2026 describes the IETF process re IP
> issues.

The problem is that 2026 is couched to prevent any liability from being
ascribed to the IETF and that is what you always hide behind. So until you
invalidate what it is I said Steve this is obvously just another one of
those things we will disagree on.

>
> Steve



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GLltt2077875 for <[e-mail]>; Wed, 16 Apr 2003 14:47:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3GLltJD077874 for ietf-pkix-bks; Wed, 16 Apr 2003 14:47:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GLlrt2077867 for <[e-mail]>; Wed, 16 Apr 2003 14:47:54 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (unknown[12.81.120.186]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <2003041621474811200pu9qme>; Wed, 16 Apr 2003 21:47:48 +0000
Message-ID: <029001c67932$5ba00fe0$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: <[e-mail]>, "J Adrian Pickering" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <005801c3036e$e5232f00$020aff0a@tsg1> <p05100305bac1f918d257@[128.89.88.34]> <[e-mail]> <[e-mail]>
Subject: Re: RFC3161(TSP): doubts about tcp protocol
Date: Tue, 16 May 2006 14:46:21 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: 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 Adrian is that now there are many more patents than the ones
that were included in the original statement afterall its been how many
years since then?

Todd

----- Original Message -----
From: "J Adrian Pickering" <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, April 16, 2003 12:37 PM
Subject: Re: RFC3161(TSP): doubts about tcp protocol


>
> At 15:43 16/04/2003, Stephen Kent wrote:
>
> >As noted in my response to Todd, his assertions re problems with
> >implementing RFC 3161 are subject to dispute. The RFC does alert folks to
> >possible IP issues,
>
> and I did so while it was in discussion

As did any number of people - but once the initial statement of a few
patents were added the furor over this disappeared and 3161 was back on
track to standardization. The problem is that this effort didnt take a year,
it took seven so far that I know of and in that time any number of new or
other derivitive patents have been issued.

>
> >  but at least one court case in the U.S. where a patent holder tried to
> > sue based on a simple time stamp protocol implementation that is very
> > analogous to what 3161 calls for, provides a basis for believing that
> > very broad patent claims in this area may not be upheld in court
>
> I am glad to hear it.

I dont think you really are - this is the US Court saying that Bell Labs
cannot patent all forms of Digitally Signed Time and really nothing else.
All the other claims held and are still good as far as I know.

> The one that really concerns me is the Haber et al
> one in which time stamp data is extended by restamping the (hash) records.

That is part of RE34954 and that also is the reissue patent from Bell Labs.
But that claim withstood the trial but was not one of the primary claims
that were sought to be invalidated.

> This is neat but nearly obvious.

yes again I think  its a repackging of existing math and process as
crypto-speak to accomplish the making of a claim of a new and novel process
and that's pretty much it. Kinda sad that it gets passed the USPTO but it
does now and then.

> I look forward to this being challenged in
> court as it needs to be - it nearly cripples the principle of archiving.

Agreed. And this was originally done in the mid 60's by IBM in their code
management tools.

> This is what worries me about whatever is behind TAP.

yes - but TAP can use a modular regenerating system. TAP's biggest worry is
that it needs 3161's TST as its time setting process and that is inherently
flawed - also the other issue is that TAP does not really take into account
that UTC is a proclamation that happens once a month from the BIPM and not
some magically uniform piece of data. Also that as new timebases are
developed they allow us to retroactively plot Delta-T between what we
stamped something as and what it really was. And that als has to be figured
into the bigger picture here. remember that what the TAP is really for is
digital evidence.

>
> Adrian Pickering/
> University of Southampton, UK
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GLgLt2077678 for <[e-mail]>; Wed, 16 Apr 2003 14:42:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3GLgLTL077677 for ietf-pkix-bks; Wed, 16 Apr 2003 14:42:21 -0700 (PDT)
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.8p1/8.12.8) with ESMTP id h3GLf5t2077590 for <[e-mail]>; Wed, 16 Apr 2003 14:41:05 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h3GLeq5w025092; Wed, 16 Apr 2003 17:40:52 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100316bac3737d4c50@[128.89.88.34]>
In-Reply-To: <01ce01c67926$a1131ba0$020aff0a@tsg1>
References: <[e-mail]> <[e-mail]> <005801c3036e$e5232f00$020aff0a@tsg1> <p05100305bac1f918d257@[128.89.88.34]> <01ce01c67926$a1131ba0$020aff0a@tsg1>
Date: Wed, 16 Apr 2003 17:41:04 -0400
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: RFC3161(TSP): doubts about tcp protocol
Cc: "Ricardo Barroso" <[e-mail]>, "Gianluca Ramunno" <[e-mail]>, <[e-mail]>, <[e-mail]>, "Lynn St.Amour" <[e-mail]>, <[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>

At 1:22 PM -0700 5/16/06, todd glassey wrote:
>Look Dr. Kent - the issue here is that you do not invalidate what I am
>saying you just attack me personally.  If I am wrong I humbly apologize but
>so far this is 100% dead-on by my take. So lets get to debunking your
>commentary from the last response -
>

It appears that Todd can't distinguish between statements of fact 
about IP issues and personal criticism.

Personal criticism would be more along the lines of suggesting that 
he is engaging in fear mongering at this stage of the standards 
process, perhaps because he tried and failed to block the advancement 
of TSP through the WG process, in IETF last call, and via direct 
appeal to the IESG. But even that observation is based on facts that 
are part of the public record; only the motivation aspect of the 
comment might be considered personal criticism.

The simple fact is that there have been many claims in the area of 
secure time stamping, going back at least as far as the PB patent 
cited by Todd. Some of these claims are quite broad. The more modern 
ones often make explicit reference to digital signature mechanisms, 
whereas the original PB patent does not. The applicability of any 
patent to the RFC 3161 protocol is a matter for lawyers and the 
courts to determine.

Mr. Glassey is not a lawyer, although he sometimes seems to forget 
that. Thus his assertions about what patents may be violated by a 
product that implements 3161 are not legal opinions and there is good 
reason to believe that they are motivated by other than simple, 
objective, technical observations, based on previous messages on this 
list.

As I noted in my earlier message, in the one legal case that is 
clearly relevant to this discussion, a patent holder who made very 
broad claims about time stamping sued a vendor who implemented a 
TSP-like capability in a product. The defendant prevailed, and the 
plaintiff had four broad patent claims disallowed as a result.  I 
know that I am not a lawyer and thus not qualified to advise 
prospective implementors about the implications of this court 
decision, but as an individual technologist I did take away a 
positive message relative to 3161.

Todd's message ends with various comments about the WG or its members 
hiring an attorney to resolve this issue. This is not how the IETF, 
or for that matter any other standards body with which I am familiar, 
addresses these issues.  RFC 2026 describes the IETF process re IP 
issues.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GKO0t2074735 for <[e-mail]>; Wed, 16 Apr 2003 13:24:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3GKNxQH074734 for ietf-pkix-bks; Wed, 16 Apr 2003 13:23:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GKNwt2074720 for <[e-mail]>; Wed, 16 Apr 2003 13:23:58 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (unknown[12.81.120.186]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <2003041620234911200ptslde>; Wed, 16 Apr 2003 20:23:51 +0000
Message-ID: <01ce01c67926$a1131ba0$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: "Ricardo Barroso" <[e-mail]>, "Gianluca Ramunno" <[e-mail]>, <[e-mail]>, <[e-mail]>, "Lynn St.Amour" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <[e-mail]> <005801c3036e$e5232f00$020aff0a@tsg1> <p05100305bac1f918d257@[128.89.88.34]>
Subject: Re: RFC3161(TSP): doubts about tcp protocol
Date: Tue, 16 May 2006 13:22:15 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Look Dr. Kent - the issue here is that you do not invalidate what I am
saying you just attack me personally.  If I am wrong I humbly apologize but
so far this is 100% dead-on by my take. So lets get to debunking your
commentary from the last response -

What are all these  numbers the rest of you folks might ask - Steve already
knows what they are - they are some of the many patents that any of you may
violate by building something out of 3161's technology and these are just
the ones listed on the references section of the eOriginals Patent filed in
2001. And - this is just a partial list - there are more, like mine
(EP808997A)
for instance, so rather than attacking me personally Steve - lets try this
again - how about disproving anything I said??? I don't think you can...

4200770 4405829 4625076 4853961 4893338
4981370 4995082 5005200 5136646 5136647
5163091 5164988 5191613 5214703 5231668
5276737 5315658 5323146 5339361 5363448
5371794 5373561 5377270 5390247 5524073
5534855 5555307 5615268 5699431 5748738
5987429 6023509 6070239

But lets keep this up anyway. As far as receipts based on the RFC3161
protocol, my take there is that the Pitney Bowes patent probably covers that
too, but if you think I am wrong  then maybe PKIX should  get a lawyer, or
better yet a Judge to say that in an opinion. Or maybe in this case the
authors of RFC3161 and their company's should be paying for having a legal
opinion rendered since they and you claim that the use of their technology
does not violate these larger-picture patents - Eh Carlisle - how
about it? Does Sharon have budget for this?

---

Steve - back to the IETF issues - You also made a comment that  implied that
there was no legal issues now that RE34954 was invalidated in court, and I
need to ask you a formal question - is this an accurate perception or then
exactly
what do these following words mean - for instance are you formally saying
this as the WG Chair or as a private citizen?  It makes a difference as to
whether you are personally liable for what you say or the IETF's
Organization is - notice the cc:ing to the ISOC Powers. So again, is this
you personally speaking or are you formally speaking for PKIX  and the IETF
here or as BBN's Standards person or just for yourself?

Your comment is included below for reference:

> - When Entrust was sued by another patent holder in the area
> of time stamping, 4 claims of the patent holder were struck down by
> the court, who found for the defendant (Entrust)
>
> Thus it is far from clear that, as Todd claims, any use of TSP will
> violate existing patents.
>
> Steve

How you possibly got that is beyond me - but it may warrant an ethics
investigation into the operations of PKIX. You seem to imply here that
because of the invalidation of the primary claim of the RE34954 patent that
all TS patents are null and void and that is more than bad advice - it may
have actionable consequences for you as both an IETF Chair and as an
employee of BBN if they foot the bill for your participation in the IETF. I
cant believe you would publicly make such a proclamation - The smart thing
to say would be "Todd I am not a lawyer so the WG just goes on what it is
told" - but your words have shown that you are actively part of this efforts
standards process and as such are probably too close to it to see it as some
of the rest of us do, a private effort to standardize something less useful
than a simple NTP Timestamp, so that two company's can corral the
Timestamping Marketplace.

If that's not a commercial effort I don't know what is -

But back to debunking your commentary - and that in particular is
the specific commentary that there is no such  information available
(i.e. a method of generating a list of applicable patents), which also is
untrue.

The only question here as I see it is whether the IETF has liability for IP
information codified into a Draft some number of years previously as being
"currently valid". That's the problem with the process - i.e. how does the
IETF verify that its IP data on any technology is up to date as of the last
publishing of the document - which is yet another failing of the current
RFC2026. or that the WG didn't withhold current data which is what
happened in this case. And since there was discussion of this at the time
that section was added this is clearly intentional in nature from my
vantage point.

Ahh - spoon feeding you your own garbage can be fun, but tiring Steve and
certainly not in PKIX's best interests - so Dr. Kent - lets ignore the
issues with 2026 and you explain to me with the many patents around
timestamping, receipt generation, and document authentication already in
existence - how is it possible that my commentary is wrong?

just my 2 cents

Todd Glassey




----- Original Message -----
From: "Stephen Kent" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: "Ricardo Barroso" <[e-mail]>; "Gianluca Ramunno"
<[e-mail]>; <[e-mail]>; <[e-mail]>; "Lynn
St.Amour" <[e-mail]>
Sent: Tuesday, April 15, 2003 11:07 AM
Subject: Re: RFC3161(TSP): doubts about tcp protocol


>
> At 9:48 AM -0700 4/15/03, todd glassey wrote:
> >So Richard - what are you going to do when you get sued for building a
> >product that has NO possible use but to violate filed and reliable
> >Intellectual Property Rights - This is not just my claim - the original
RFC
> >now has a section that talks to its issues with commercially supplied
> >patents regarding receipt generation and the use of time data therein.
Only
> >it doesn't bother to include the XML ones or those filed and granted
since
> >the Haber ones it does reference became moot.
> >
> >This is the real issue with RFC3161 and its becoming a standard. It
> >essentially creates the first COMMERCIAL standard inside the IETF  since
> >there can be no use model that is not in violation of any number of
patents.
> >It also will IMHO constrain PKIX for what it is  - an old boys club
> >masquerading as a standards group.
> >
> >I see the ascension of 3161 as one of the saddest things that can happen
> >since it will permanently impugn PKIX and in fact may be the key item
> >necessary to force the deconstruction of the IETF as we know it today.
> >
> >Todd Glassey
>
> While it is thoughtful of Todd to express his opinion about the
> possible intellectual property issues that may be associated with the
> TSP RFC, it is also worth noting that:
>
> - the RFC makes note of possible IP problems in a fashion
> consistent with IETF guidelines
>
> - Todd himself is a patent holder in this area, and thus not
> exaclty an unbiased party
>
> - When Entrust was sued by another patent holder in the area
> of time stamping, 4 claims of the patent holder were struck down by
> the court, who found for the defendant (Entrust)
>
> Thus it is far from clear that, as Todd claims, any use of TSP will
> violate existing patents.
>
> Steve



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GJbqt2073007 for <[e-mail]>; Wed, 16 Apr 2003 12:37:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3GJbqxV073006 for ietf-pkix-bks; Wed, 16 Apr 2003 12:37:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from colossus.systems.pipex.net (colossus.systems.pipex.net [62.241.160.73]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GJbpt2073001 for <[e-mail]>; Wed, 16 Apr 2003 12:37:51 -0700 (PDT) (envelope-from [e-mail])
Received: from home.ecs.soton.ac.uk (81-86-178-22.dsl.pipex.com [81.86.178.22]) by colossus.systems.pipex.net (Postfix) with ESMTP id 884E816000127 for <[e-mail]>; Wed, 16 Apr 2003 20:37:49 +0100 (BST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 16 Apr 2003 20:37:42 +0100
To: [e-mail]
From: J Adrian Pickering <[e-mail]>
Subject: Re: RFC3161(TSP): doubts about tcp protocol
In-Reply-To: <p05100307bac31aad6e93@[128.89.88.34]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <005801c3036e$e5232f00$020aff0a@tsg1> <p05100305bac1f918d257@[128.89.88.34]> <[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 15:43 16/04/2003, Stephen Kent wrote:

>As noted in my response to Todd, his assertions re problems with 
>implementing RFC 3161 are subject to dispute. The RFC does alert folks to 
>possible IP issues,

and I did so while it was in discussion

>  but at least one court case in the U.S. where a patent holder tried to 
> sue based on a simple time stamp protocol implementation that is very 
> analogous to what 3161 calls for, provides a basis for believing that 
> very broad patent claims in this area may not be upheld in court

I am glad to hear it. The one that really concerns me is the Haber et al 
one in which time stamp data is extended by restamping the (hash) records. 
This is neat but nearly obvious. I look forward to this being challenged in 
court as it needs to be - it nearly cripples the principle of archiving. 
This is what worries me about whatever is behind TAP.

Adrian Pickering/
University of Southampton, UK



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GJ1Xt2072071 for <[e-mail]>; Wed, 16 Apr 2003 12:01:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3GJ1Xix072070 for ietf-pkix-bks; Wed, 16 Apr 2003 12:01:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GJ1Vt2072060 for <[e-mail]>; Wed, 16 Apr 2003 12:01:31 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (120.sanfrancisco-12rh15rt-ca.dial-access.att.net[12.81.118.120]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <20030416190126111002r49be>; Wed, 16 Apr 2003 19:01:27 +0000
Message-ID: <00d801c6791b$1e52ab50$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: <[e-mail]>
Subject: Todd's response to Carlisle re the issues with 3161
Date: Tue, 16 May 2006 12:01:15 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D5_01C678E0.6F210440"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: 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_00D5_01C678E0.6F210440
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Carlisle aren't you one of the authors of the original TSA and Notary =
protocol Drafts? and didn't you at that time work for Entrust and =
doesn't Entrust make a TS Tool Kit?

yes that what I thought -=20


Todd



------=_NextPart_000_00D5_01C678E0.6F210440
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1141" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Carlisle aren't you one of the authors =
of the=20
original TSA and Notary protocol Drafts? and didn't you at that time =
work for=20
Entrust and doesn't Entrust make a TS Tool Kit?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>yes that what I thought - </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></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></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_00D5_01C678E0.6F210440--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GEhOt2062166 for <[e-mail]>; Wed, 16 Apr 2003 07:43:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3GEhOoC062165 for ietf-pkix-bks; Wed, 16 Apr 2003 07:43:24 -0700 (PDT)
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.8p1/8.12.8) with ESMTP id h3GEhNt2062158 for <[e-mail]>; Wed, 16 Apr 2003 07:43:23 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h3GEhA5w024677; Wed, 16 Apr 2003 10:43:10 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100307bac31aad6e93@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <005801c3036e$e5232f00$020aff0a@tsg1> <p05100305bac1f918d257@[128.89.88.34]> <[e-mail]>
Date: Wed, 16 Apr 2003 10:43:48 -0400
To: Ricardo Barroso <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: RFC3161(TSP): doubts about tcp protocol
Cc: todd glassey <[e-mail]>, Gianluca Ramunno <[e-mail]>, [e-mail], [e-mail], "Lynn St.Amour" <[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>

At 3:20 PM +0100 4/16/03, Ricardo Barroso wrote:
>What will happen to all the companies from all over the world that 
>are implementing RFC 3161 or that
>already have implemented and posssibly are currently commercializing 
>their Time-Stamping Services?
>
>Is it supposed to exist RFCs (and continue being improved) that 
>supposely violate existing patents?
>Shoulnd't be IETF responsible for investigate that issues before the 
>development and publication of
>internet drafts and RFCs?
>
>Ricardo

The IETF tries to avoid issuing standards that involve patented 
technology, when possible, but it is not always possible to determine 
whether there are patents that may involve IETF standards, e.g., 
because of the lag time between patent filings and issuance, etc.

There are guidelines for how WGs deal with this issue and I refer you 
to those guidelines (RFC 2026).

As noted in my response to Todd, his assertions re problems with 
implementing RFC 3161 are subject to dispute. The RFC does alert 
folks to possible IP issues, but at least one court case in the U.S. 
where a patent holder tried to sue based on a simple time stamp 
protocol implementation that is very analogous to what 3161 calls 
for, provides a basis for believing that very broad patent claims in 
this area may not be upheld in court.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GESft2061734 for <[e-mail]>; Wed, 16 Apr 2003 07:28:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3GESftA061733 for ietf-pkix-bks; Wed, 16 Apr 2003 07:28:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.multicert.com ([62.48.185.5]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GESct2061725 for <[e-mail]>; Wed, 16 Apr 2003 07:28:39 -0700 (PDT) (envelope-from [e-mail])
Received: from multicert.com (unknown [192.168.0.125]) by mail.multicert.com (Postfix) with ESMTP id D41665B886; Wed, 16 Apr 2003 11:21:25 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 16 Apr 2003 15:20:17 +0100
From: Ricardo Barroso <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826
X-Accept-Language: pt, en-us, en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
Cc: todd glassey <[e-mail]>, Gianluca Ramunno <[e-mail]>, [e-mail], [e-mail], "Lynn St.Amour" <[e-mail]>
Subject: Re: RFC3161(TSP): doubts about tcp protocol
References: <[e-mail]> <[e-mail]> <005801c3036e$e5232f00$020aff0a@tsg1> <p05100305bac1f918d257@[128.89.88.34]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

What will happen to all the companies from all over the world that are 
implementing RFC 3161 or that
already have implemented and posssibly are currently commercializing 
their Time-Stamping Services?

Is it supposed to exist RFCs (and continue being improved) that 
supposely violate existing patents?
Shoulnd't be IETF responsible for investigate that issues before the 
development and publication of
internet drafts and RFCs?

Ricardo


Stephen Kent wrote:

> At 9:48 AM -0700 4/15/03, todd glassey wrote:
>
>> So Richard - what are you going to do when you get sued for building a
>> product that has NO possible use but to violate filed and reliable
>> Intellectual Property Rights - This is not just my claim - the 
>> original RFC
>> now has a section that talks to its issues with commercially supplied
>> patents regarding receipt generation and the use of time data 
>> therein. Only
>> it doesn't bother to include the XML ones or those filed and granted 
>> since
>> the Haber ones it does reference became moot.
>>
>> This is the real issue with RFC3161 and its becoming a standard. It
>> essentially creates the first COMMERCIAL standard inside the IETF  since
>> there can be no use model that is not in violation of any number of 
>> patents.
>> It also will IMHO constrain PKIX for what it is  - an old boys club
>> masquerading as a standards group.
>>
>> I see the ascension of 3161 as one of the saddest things that can happen
>> since it will permanently impugn PKIX and in fact may be the key item
>> necessary to force the deconstruction of the IETF as we know it today.
>>
>> Todd Glassey
>
>
> While it is thoughtful of Todd to express his opinion about the 
> possible intellectual property issues that may be associated with the 
> TSP RFC, it is also worth noting that:
>
>     - the RFC makes note of possible IP problems in a fashion 
> consistent with IETF guidelines
>
>     - Todd himself is a patent holder in this area, and thus not 
> exaclty an unbiased party
>
>     - When Entrust was sued by another patent holder in the area of 
> time stamping, 4 claims of the patent holder were struck down by the 
> court, who found for the defendant (Entrust)
>
> Thus it is far from clear that, as Todd claims, any use of TSP will 
> violate existing patents.
>
> Steve
>




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GCOmt2052580 for <[e-mail]>; Wed, 16 Apr 2003 05:24:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3GCOmfG052579 for ietf-pkix-bks; Wed, 16 Apr 2003 05:24:48 -0700 (PDT)
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.8p1/8.12.8) with ESMTP id h3GCOlt2052574 for <[e-mail]>; Wed, 16 Apr 2003 05:24:47 -0700 (PDT) (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 IAA27036; Wed, 16 Apr 2003 08:22:07 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-rfc2511bis-06.txt
Date: Wed, 16 Apr 2003 08:22:06 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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)	: M. Myers, C. Adams, D. Solo, D. Kemp
	Filename	: draft-ietf-pkix-rfc2511bis-06.txt
	Pages		: 26
	Date		: 2003-4-15
	
This document describes the Certificate Request Message Format
(CRMF).  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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2511bis-06.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-rfc2511bis-06.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-06.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-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-rfc2511bis-06.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 [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GCOgt2052569 for <[e-mail]>; Wed, 16 Apr 2003 05:24:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3GCOg4Z052568 for ietf-pkix-bks; Wed, 16 Apr 2003 05:24:42 -0700 (PDT)
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.8p1/8.12.8) with ESMTP id h3GCOet2052563 for <[e-mail]>; Wed, 16 Apr 2003 05:24:41 -0700 (PDT) (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 IAA27019; Wed, 16 Apr 2003 08:22:00 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-rfc2510bis-08.txt
Date: Wed, 16 Apr 2003 08:22:00 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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 
                          Management Protocols
	Author(s)	: C. Adams, S. Farrell
	Filename	: draft-ietf-pkix-rfc2510bis-08.txt
	Pages		: 92
	Date		: 2003-4-15
	
This document describes the Internet X.509 Public Key Infrastructure
(PKI) Certificate Management Protocol (CMP). Protocol messages are 
defined for X.509v3 certificate creation and management.  CMP provides
online interactions between PKI components, including an exchange 
between a Certification Authority (CA) and a client system.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2510bis-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-rfc2510bis-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-rfc2510bis-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-rfc2510bis-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-rfc2510bis-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 [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FIAlt2084420 for <[e-mail]>; Tue, 15 Apr 2003 11:10:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3FIAl20084419 for ietf-pkix-bks; Tue, 15 Apr 2003 11:10:47 -0700 (PDT)
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.8p1/8.12.8) with ESMTP id h3FIAkt2084410 for <[e-mail]>; Tue, 15 Apr 2003 11:10:46 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h3FIAa5w028142; Tue, 15 Apr 2003 14:10:36 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100305bac1f918d257@[128.89.88.34]>
In-Reply-To: <005801c3036e$e5232f00$020aff0a@tsg1>
References: <[e-mail]> <[e-mail]> <005801c3036e$e5232f00$020aff0a@tsg1>
Date: Tue, 15 Apr 2003 14:07:55 -0400
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: RFC3161(TSP): doubts about tcp protocol
Cc: "Ricardo Barroso" <[e-mail]>, "Gianluca Ramunno" <[e-mail]>, <[e-mail]>, <[e-mail]>, "Lynn St.Amour" <[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>

At 9:48 AM -0700 4/15/03, todd glassey wrote:
>So Richard - what are you going to do when you get sued for building a
>product that has NO possible use but to violate filed and reliable
>Intellectual Property Rights - This is not just my claim - the original RFC
>now has a section that talks to its issues with commercially supplied
>patents regarding receipt generation and the use of time data therein. Only
>it doesn't bother to include the XML ones or those filed and granted since
>the Haber ones it does reference became moot.
>
>This is the real issue with RFC3161 and its becoming a standard. It
>essentially creates the first COMMERCIAL standard inside the IETF  since
>there can be no use model that is not in violation of any number of patents.
>It also will IMHO constrain PKIX for what it is  - an old boys club
>masquerading as a standards group.
>
>I see the ascension of 3161 as one of the saddest things that can happen
>since it will permanently impugn PKIX and in fact may be the key item
>necessary to force the deconstruction of the IETF as we know it today.
>
>Todd Glassey

While it is thoughtful of Todd to express his opinion about the 
possible intellectual property issues that may be associated with the 
TSP RFC, it is also worth noting that:

	- the RFC makes note of possible IP problems in a fashion 
consistent with IETF guidelines

	- Todd himself is a patent holder in this area, and thus not 
exaclty an unbiased party

	- When Entrust was sued by another patent holder in the area 
of time stamping, 4 claims of the patent holder were struck down by 
the court, who found for the defendant (Entrust)

Thus it is far from clear that, as Todd claims, any use of TSP will 
violate existing patents.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FHprt2082963 for <[e-mail]>; Tue, 15 Apr 2003 10:51:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3FHpra3082962 for ietf-pkix-bks; Tue, 15 Apr 2003 10:51:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sottmxssm.entrust.com (sottmxssm.entrust.com [216.191.252.10]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FHppt2082955 for <[e-mail]>; Tue, 15 Apr 2003 10:51:52 -0700 (PDT) (envelope-from [e-mail])
Received: from sottguard01.entrust.com (sottguard01.entrust.com [10.4.61.249]) by sottmxssm.entrust.com (Switch-2.2.6/Switch-2.2.4) with SMTP id V3FH3CHB28094 for <[e-mail]>; Tue, 15 Apr 2003 13:48:53 -0400
Received: (qmail 19775 invoked by uid 64014); 15 Apr 2003 17:50:40 -0000
Received: from [e-mail] by sottguard01.entrust.com with AmikaGuardian-Server-1.1.2 (Processed in 2.444008 secs); 15 Apr 2003 17:50:40 -0000
Received: from unknown (HELO SOTTMXS01.entrust.com) (10.4.61.7) by sottguard01.entrust.com with SMTP; 15 Apr 2003 17:50:37 -0000
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <2ZN4SHZ2>; Tue, 15 Apr 2003 13:51:38 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'todd glassey'" <[e-mail]>, Ricardo Barroso <[e-mail]>, Gianluca Ramunno <[e-mail]>
Cc: Stephen Kent <[e-mail]>, [e-mail], [e-mail], "Lynn St.Amour" <[e-mail]>
Subject: RE: RFC3161(TSP): doubts about tcp protocol
Date: Tue, 15 Apr 2003 13:51:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
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>

Wow!  I'm sure that the authors of 3161 must feel a tremendous
responsibility for having unknowingly precipitated this impending
catastrophe...


-----Original Message-----
From: todd glassey [mailto:[e-mail]]
Sent: Tuesday, April 15, 2003 12:49 PM
To: Ricardo Barroso; Gianluca Ramunno
Cc: Stephen Kent; [e-mail]; [e-mail]; Lynn St.Amour
Subject: Re: RFC3161(TSP): doubts about tcp protocol

I see the ascension of 3161 as one of the saddest things that can happen
since it will permanently impugn PKIX and in fact may be the key item
necessary to force the deconstruction of the IETF as we know it today.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FGn4t2075272 for <[e-mail]>; Tue, 15 Apr 2003 09:49:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3FGn4e8075271 for ietf-pkix-bks; Tue, 15 Apr 2003 09:49:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FGmxt2075246 for <[e-mail]>; Tue, 15 Apr 2003 09:49:00 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (unknown[12.81.121.68]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <2003041516485311100r0jdve>; Tue, 15 Apr 2003 16:48:54 +0000
Message-ID: <005801c3036e$e5232f00$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Ricardo Barroso" <[e-mail]>, "Gianluca Ramunno" <[e-mail]>
Cc: "Stephen Kent" <[e-mail]>, <[e-mail]>, <[e-mail]>, "Lynn St.Amour" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: RFC3161(TSP): doubts about tcp protocol
Date: Tue, 15 Apr 2003 09:48:43 -0700
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.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: 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 Richard - what are you going to do when you get sued for building a
product that has NO possible use but to violate filed and reliable
Intellectual Property Rights - This is not just my claim - the original RFC
now has a section that talks to its issues with commercially supplied
patents regarding receipt generation and the use of time data therein. Only
it doesn't bother to include the XML ones or those filed and granted since
the Haber ones it does reference became moot.

This is the real issue with RFC3161 and its becoming a standard. It
essentially creates the first COMMERCIAL standard inside the IETF  since
there can be no use model that is not in violation of any number of patents.
It also will IMHO constrain PKIX for what it is  - an old boys club
masquerading as a standards group.

I see the ascension of 3161 as one of the saddest things that can happen
since it will permanently impugn PKIX and in fact may be the key item
necessary to force the deconstruction of the IETF as we know it today.


Todd Glassey
----- Original Message -----
From: "Ricardo Barroso" <[e-mail]>
To: "Gianluca Ramunno" <[e-mail]>
Cc: "Stephen Kent" <[e-mail]>; <[e-mail]>;
<[e-mail]>
Sent: Tuesday, April 15, 2003 3:48 AM
Subject: Re: RFC3161(TSP): doubts about tcp protocol


>
> Hi!
>
> I agree with Stephen when he says:
>
>     «I think we need to define one transport protocol as a default, and
> make it a MUST implement,
>     so that all clients and all servers are capable of communicating, at
> least in principle.»
>
> and with Gianluca when is said that protocol should be HTTP:
>
>     «Without a well-defined and mandatory transport protocol, it's quite
>     difficult to formally define the set of the interoperability tests
> that are
>     needed to push forward the TSP on the standard track according to
> RFC2026.
>
>     Regarding the question "which protocol should be mandatory?", in my
> personal
>     opinion a good choice may be HTTP.».
>
> Cheers,
> Ricardo Barroso
> (MULTICERT)
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FAvjt2046415 for <[e-mail]>; Tue, 15 Apr 2003 03:57:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3FAvjRH046414 for ietf-pkix-bks; Tue, 15 Apr 2003 03:57:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.multicert.com ([62.48.185.5]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FAuRt2046305 for <[e-mail]>; Tue, 15 Apr 2003 03:56:28 -0700 (PDT) (envelope-from [e-mail])
Received: from multicert.com (unknown [192.168.0.125]) by mail.multicert.com (Postfix) with ESMTP id 635525B7A3; Tue, 15 Apr 2003 07:49:15 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 15 Apr 2003 11:48:46 +0100
From: Ricardo Barroso <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826
X-Accept-Language: pt, en-us, en
MIME-Version: 1.0
To: Gianluca Ramunno <[e-mail]>
Cc: Stephen Kent <[e-mail]>, [e-mail], [e-mail]
Subject: Re: RFC3161(TSP): doubts about tcp protocol
References: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>

Hi!

I agree with Stephen when he says:

    «I think we need to define one transport protocol as a default, and 
make it a MUST implement,
    so that all clients and all servers are capable of communicating, at 
least in principle.»

and with Gianluca when is said that protocol should be HTTP:

    «Without a well-defined and mandatory transport protocol, it's quite
    difficult to formally define the set of the interoperability tests 
that are
    needed to push forward the TSP on the standard track according to 
RFC2026.

    Regarding the question "which protocol should be mandatory?", in my 
personal
    opinion a good choice may be HTTP.».

Cheers,
Ricardo Barroso
(MULTICERT)



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3DEssJM008222 for <[e-mail]>; Sun, 13 Apr 2003 07:54:54 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3DEssrx008221 for ietf-pkix-bks; Sun, 13 Apr 2003 07:54:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3DEsqJM008199 for <[e-mail]>; Sun, 13 Apr 2003 07:54:53 -0700 (PDT)
Received: from VON-TP-T30 (terra.mcs.anl.gov [140.221.11.103]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id h3DEsl4158830; Sun, 13 Apr 2003 09:54:47 -0500
X-Mailer: 21.4 (patch 11) "Native Windows TTY Support (Windows)" XEmacs Lucid (via feedmail 10 I); VM 7.07 under 21.4 (patch 11) "Native Windows TTY Support (Windows)" XEmacs Lucid
From: "Von Welch" <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Sun, 13 Apr 2003 09:55:37 -0500
To: <[e-mail]>
Cc: "'IETF-PKIX'" <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-proxy-04
In-Reply-To: <003301c2ff2c$4ce86de0$[e-mail]>
References: <[e-mail]> <003301c2ff2c$4ce86de0$[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>

Jim,

Comments/responses below.

Von

Jim Schaad writes (23:42 April 9, 2003):
 > Von,
 > 
 > I've removed those items for which I have no replies.
 > 
 > Jim
 > 
 >  > 9.  Section 3.2 - Please justify this section.  I know of know reason
 > > why an IssuerAltName should not be allowed in a PC.
 > 
 > There is a good reason why we disallow SubjectAltNames in PC's (see my
 > response to your issue number #13) and suspect this was a carry over.
 > 
 > Let me push back, is there a valid reason to allow an IssuerAltName in a
 > PC since the Issuer field must be non-empty (i.e. a Proxy Issuer must
 > have a non-empty Subject)? If not, I'd prefer to keep it out to keep
 > path validation simpler.
 > 
 > [JLS] One reason for allowing it is that an EE certificate can have a
 > SubjectAltName, which could be copied into the PC.

You are suggesting copying the SubjectAltName from PI to PC? I'm not
sure we've considered this, but I can't figure out any way it would be
useful since to verify a PC's SubjectAltName a relying party would
need to walk the cert chain back up to the EEC anyways so could just
get the SubjectAltName from the EEC.

As it stands currently the proxies and proxy issuers MUST have a
non-empty subject name so all of our path validation uses subject
names. We intentionally tried to avoid having to deal with the
SubjectAltNames, since we couldn't think of a benefit for them, to
keep path validation simpler.

 >  > 12.  Section 3.5 - Ditto of item 7.  I can see needing to potentially
 > > define how to do some conversions, are you just trying to avoid that
 > > problem?
 > 
 > (Reference should be item 9 instead of item 7)
 > 
 > The reason for this is that some of the subjectAltName forms are not
 > hierarchical, so we cannot use our current path validation techniques to
 > verify the validity of a proxy's SubjectAltName.  This means that
 > applications will have to locate the EEC to determine things like e-mail
 > address.
 > 
 > [JLS] The only issue that I have here is that I can see proxy's
 > potentially being named with some things that might not go well here.  I
 > don't know if these are real, but could see potentially  wanting to put
 > IP addresses in as alt names for the proxy.  I hate to see this
 > restricted out without really thinking hard about some cases where this
 > might be nice.

As stated, we couldn't think of a way to allow non-hierarchical naming
allowed in the SubjectAltName while allowing those names to be
validated.

 >  > 13. Section 3.6 - Signing only certificate cannot issue encrypting  >
 > certificate.
 > 
 > I believe the third bullet prohibits this.
 > 
 >  > 14.  Section 3.6 - RSA certificate cannot issue DH certificate.
 > 
 > I don't see why this is relevant to 3.6
 > 
 > Question from one of my coauthors:
 > 
 > What this comment seems to be pushing on is whether the signature
 > algorithm 
 > can change between the issuer and the subject.  I don't see why not.  In
 > 
 > fact, I can see some value to this, as you might want to secure an EEC
 > with 
 > a stronger algorithm and key, but use a lighter weight approach for a 
 > short-lived PC.  We already change the key length.  What's the problem
 > with 
 > change the algorithm?
 > 
 > [JLS]  This is in response to both 13 and 14.  The reason that an RSA
 > certificate cannot issue a DH certificate, is that an RSA certificate
 > will assert the keyEncipherment bit, however a DH certificate needs to
 > assert the keyAgreement bit.  This is not allowed since this is a change
 > in the set of keyUsage bits in a non-subset manner.  In the same way, a
 > signing only certificate would have either the digitialSignature or the
 > nonRepudiation bit set in KeyUsage.  Since the keyEncipherment or
 > keyAgreement bits are not set, an encryption certificate could not be
 > issued.  A certificate with only keyEncipherment would be unable to
 > issue a certificate since the signature operation is not allowed under
 > its abilities for verification.  This means that in order to issue a
 > certificate that allows for encryption, you need to start with an RSA
 > certificate that allows both keyEncipherment and
 > digitalSignature/nonReudiation.

This sparked a discussion about the KeyUsage and ExtendedKeyUsage
extensions in PCs and our conclusion was these bits are authorization
policy and should be treated in same manner as the proxy policy. What
this means is that if a relying party is basing a decision on one or
more of these bits in a PC, the relying party needs to verify local
policy as to whether the bits are legally set based on their values in
preceding certificates in the chain. For any policy that we thought up
that could be encoded in path validation to control inheritence, we
also thought of reasonable exceptions (especially for PCs with
independent proxy policies).

The result of this is that we will remove any constraints on the
contents of the KeyUsage and ExtendedKeyUsage in a PC, but make it
clear that relying parties that uses these bits as the basis for
decisions MUST verify that the inheritences of the bits meets local
policy. In general we most policies will probably subset, but we
there may be exceptions in that some sites MAY wish to allow
independent PCs to have any legal KeyUsage or ExtendedKeyUsage fields
and some sites may wish to allow the RSA/DH example as you point out.

 >  > 23.  Section 4 - policies evalution is messed up big time.  At a
 > minimum  > you need to put in specialized processing rules for
 > id-ppl-impersonation  > and possibly for independent as well.  Consider
 > the following:  I ask  > for a specific policy, I find a PC with with
 > impersonation - according  > to the rules I must reject the PC chain,
 > but I am sure that is not the  > desired behavior.
 > 
 > I think you are referring to what happens if the impersonation policy
 > doesn't appear in the acceptable-pc-policy-set and the you encounter a
 > proxy with that policy?
 > 
 > In that case, yes it should be a failure, since the relying party
 > doesn't understand the policy involved. We don't specify currently that
 > any policy MUST be understood.
 > 
 > In practice I suspect most of the time proxy policies will be ignored
 > during proxy path validation (i.e. acceptable-pc-policy-set will be
 > equal to any-policy) and not used until authorization. The
 > acceptable-pc-policy-set is included in path validation so that a
 > relying party that handles only inherited rights can fail earlier rather
 > than later.
 > 
 > [JLS]  If this is the case, then I don't see the benefit of having any
 > policy work done during validation.  If I pass in an acceptable policy,
 > I want to say it has policy FOO-BAR.  If there is not the ablity to
 > create a FOO-BAR chain of policy then it needs to be rejected.  The real
 > problem however is trying to distinguish between a permission and a
 > policy.  These are not the same things, but I keep wanting to treat them
 > as such.  I want to pass in the question "Is there a chain which gives
 > the permission BLAH to this entity?"  This is basically what happens for
 > the policy evaluation of identity certificates, and thus I expect the
 > same type of behavior for this chain validation logic given that you are
 > using the same term "POLICY".  The correct statement to say for the
 > initialization statement on policies is "This field is initialized to
 > the set of proxy policies that are understood by the permission
 > evaluation code."

Right, this is talking about known policies languages and not
permissions. I've made the following change in 4.1.1 to clarify:

(c) acceptable-pc-policy-set: A set of proxy certificate policy
languages understood by the policy evaluation code. The
acceptable-pc-policy-set MAY contain the special value any-policy if
the path validation code should not check the proxy certificate policy
languages (typically because the set of known policy languages is not
known yet and will be checked later in the authorization process).


 >  > 	id-ppl-impersonation and id-ppl-independent do not match the
 >  > definitions given in the body of the text with regard to naming of  >
 > either the OID or the last intenger in the oid string.  The version in
 > > the ASN.1 file is the correct method of naming.
 > 
 > [JLS]
 > iso(1) identified-organization(3) dod(6) internet(1) security(5)
 > mechanisms(5) pkix(7) ppl(21) id-ppl-impersonation(1)
 > Vs
 > id-ppl-impersonation   OBJECT IDENTIFIER ::= { id-ppl 1 }
 > 
 > In one case the last number is named, in the other the name represents
 > the entire OID.  These mean slightly different things in ASN.1.  In one
 > case it is the entire OID, in the other case is really only represents
 > the value '1'  Use the full x ::= y in the text and I will be happy.

Ah, gotcha. These names now refer to the whole OID.

-end-



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3C0CZJM028609 for <[e-mail]>; Fri, 11 Apr 2003 17:12:35 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3C0CZxw028608 for ietf-pkix-bks; Fri, 11 Apr 2003 17:12:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3C0CYJM028602 for <[e-mail]>; Fri, 11 Apr 2003 17:12:34 -0700 (PDT)
Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54] (may be forged)) by peacock.verisign.com (8.12.9/) with ESMTP id h3C0CaP4001216; Fri, 11 Apr 2003 17:12:36 -0700 (PDT)
Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id <HXCSK16P>; Fri, 11 Apr 2003 17:12:37 -0700
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'Michael Myers'" <[e-mail]>, [e-mail]
Subject: RE: TAP  - Yes in a new group
Date: Fri, 11 Apr 2003 17:12:36 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I vote to direct TAP to a new group as well

> -----Original Message-----
> From: Michael Myers [mailto:[e-mail]]
> Sent: Wednesday, April 02, 2003 2:43 PM
> To: [e-mail]
> Subject: TAP - Yes in a new group
> 
> 
> 
> I vote to redirect TAP away from PKIX.
> 
> Mike
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AH4bJM026131 for <[e-mail]>; Thu, 10 Apr 2003 10:04:37 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3AH4bBJ026130 for ietf-pkix-bks; Thu, 10 Apr 2003 10:04:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.11.6) with SMTP id h3AH4aJM026126 for <[e-mail]>; Thu, 10 Apr 2003 10:04:36 -0700 (PDT)
Received: (qmail 8277 invoked by uid 0); 10 Apr 2003 17:04:05 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.163.154) by woodstock.binhost.com with SMTP; 10 Apr 2003 17:04:05 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Thu, 10 Apr 2003 13:02:58 -0400
To: Denis Pinkas <[e-mail]>, Stefan Santesson <[e-mail]>, Tim Polk <[e-mail]>, Stephen Kent <[e-mail]>, pkix <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Question about the edition of RFC 3280
Cc: Jeff Schiller <[e-mail]>, Steve Bellovin <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
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 h3AH4bJM026127
Sender: [e-mail]
Precedence: 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 like to participate, but I already have a commitment for Monday 
evening.

Sorry,
   Russ

At 10:54 AM 4/10/2003 +0200, Denis Pinkas wrote:
>Stefan,
>
>Thank you for the response.
>
>I realize that very unfortunately both the sender of the message and the 
>receivers of the message lost the message. :-|
>
>Now, looking forward, I would like to make the following proposal:
>
>Next week there is the RSA 2003 Security Conference. I will attend the 
>Conference and I guess may other people from the PKIX WG will do so as well.
>
>Since there is the speaker's dinner on the Tuesday and the Gala Dinner of 
>the Wednesday, I propose to have an informal meeting about key usage bits 
>0 and 1 on the Monday evening for anyone interrested.
>
>I thus propose to meet in the North Lobby, in front of the registration 
>desks at 5:30 p.m. on the Monday evening.
>
>I would like to discuss the meaning of a certificate that has:
>
>  1° only the key usage bit 1 set,
>  2° only the key usage bit 0 set,
>  3° both the key usage bits 0 and 1 set.
>
>   ... when looking at the writing of RFC 2459 and
>       when looking at the writing of RFC 3280.
>
>Denis
>
>Note: I blindly copy the OSI Security list, including Hoyt Kesterson who 
>will be present at the Conference (and if he may join).
>
>
>>Denis,
>>At 12:10 2003-04-08 +0200, Denis Pinkas wrote:
>>
>>>>I do not know why you are asking about a change that happened a year 
>>>>ago, but here is the history.  This took quite a bit of time to pull 
>>>>together, and it involved searching the archives kept by several 
>>>>different individuals.
>>>>During IETF Last Call, the authors received a comment regarding the key 
>>>>usage bits.  We have been unsuccessful in locating this email message, 
>>>>so you will have to live with the personal recollection of the content 
>>>>of this message.
>>>
>>>
>>>It is quite strange that such a message has been lost by all the editors 
>>>together. :-|
>>>
>>>Unless someone from the WG mailing list remember that he posted this 
>>>message and makes itself known, the reality of the existence of this 
>>>message will be questionable.
>>>
>>>Can anyone from the WG identifies himself as being the sender of the 
>>>message that lead to that change ?
>>
>>I identify myself as the originator of this mail and confirm that the 
>>aspect referred to by Russ was contained in my comment.
>>I was asked to find this mail as part of the reconstruction you have 
>>requested but was unable to do so due to a disk crash I suffered from 
>>last year where I lost lots of old e-mail.
>>/Stefan
>>
>
>




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3ADMlJM012157 for <[e-mail]>; Thu, 10 Apr 2003 06:22:47 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3ADMlwA012156 for ietf-pkix-bks; Thu, 10 Apr 2003 06:22:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3ADMjJM012151 for <[e-mail]>; Thu, 10 Apr 2003 06:22:46 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA09014; Thu, 10 Apr 2003 15:22:44 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.6); Thu, 10 Apr 2003 15:22:44 +0200 (MET DST)
Received: (from sylvest@localhost) by champagne.edelweb.fr (8.7.6/8.6.6) id PAA26735; Thu, 10 Apr 2003 15:22:43 +0200 (MET DST)
Date: Thu, 10 Apr 2003 15:22:43 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Question about the edition of RFC 3280
Sender: [e-mail]
Precedence: 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,

you are claiming an important incompatiblity. So far, the
only thing you had provided is to point to the paragraph 
that differs between 3280 and 2459. 

Yes, there is a difference. 

But is is IMO a normal process to change standards
when enhancements seem useful. Or, by definition,
compatibility to X509 and withing X509 is not an
absolute goal. 

I think it could be a good idea that you provide a 
description of a problematic case, i.e. a situation 
where in a real existing implementation the change will
create harm. 

Regards 
Peter





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3A9NHJM022709 for <[e-mail]>; Thu, 10 Apr 2003 02:23:17 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3A9NHO9022708 for ietf-pkix-bks; Thu, 10 Apr 2003 02:23:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mpls-qmqp-03.inet.qwest.net (mpls-qmqp-03.inet.qwest.net [63.231.195.114]) by above.proper.com (8.12.9/8.11.6) with SMTP id h3A9NFJM022703 for <[e-mail]>; Thu, 10 Apr 2003 02:23:16 -0700 (PDT)
Received: (qmail 99617 invoked by uid 0); 10 Apr 2003 09:21:23 -0000
Received: from mpls-pop-11.inet.qwest.net (63.231.195.11) by mpls-qmqp-03.inet.qwest.net with QMQP; 10 Apr 2003 09:21:23 -0000
Received: from vdsl-130-13-127-251.phnx.uswest.net (HELO ?192.168.2.12?) (130.13.127.251) by mpls-pop-11.inet.qwest.net with SMTP; 10 Apr 2003 09:23:15 -0000
Date: Thu, 10 Apr 2003 02:08:03 -0700
Message-Id: <a0521060ababae495faff@[192.168.2.12]>
From: "Hoyt L. Kesterson II" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Stefan Santesson" <[e-mail]>, "Russ Housley" <[e-mail]>, "Tim Polk" <[e-mail]>, "Stephen Kent" <[e-mail]>, "pkix" <[e-mail]>
Cc: "Jeff Schiller" <[e-mail]>, "Steve Bellovin" <[e-mail]>
Mime-Version: 1.0
X-Sender: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: Question about the edition of RFC 3280
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 h3A9NGJM022704
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

more than willing to discuss this topic, especially 1 and 2.

i point out that the amendment had very clear text about the setting 
of multiple key usage bits and that there were no ballot comments on 
that point

    hoyt


At 10:54 AM +0200 4/10/03, Denis Pinkas wrote:
>Stefan,
>
>Thank you for the response.
>
>I realize that very unfortunately both the sender of the message and 
>the receivers of the message lost the message. :-|
>
>Now, looking forward, I would like to make the following proposal:
>
>Next week there is the RSA 2003 Security Conference. I will attend 
>the Conference and I guess may other people from the PKIX WG will do 
>so as well.
>
>Since there is the speaker's dinner on the Tuesday and the Gala 
>Dinner of the Wednesday, I propose to have an informal meeting about 
>key usage bits 0 and 1 on the Monday evening for anyone interrested.
>
>I thus propose to meet in the North Lobby, in front of the 
>registration desks at 5:30 p.m. on the Monday evening.
>
>I would like to discuss the meaning of a certificate that has:
>
>  1° only the key usage bit 1 set,
>  2° only the key usage bit 0 set,
>  3° both the key usage bits 0 and 1 set.
>
>   ... when looking at the writing of RFC 2459 and
>       when looking at the writing of RFC 3280.
>
>Denis
>
>Note: I blindly copy the OSI Security list, including Hoyt Kesterson 
>who will be present at the Conference (and if he may join).
>
>>Denis,
>>
>>At 12:10 2003-04-08 +0200, Denis Pinkas wrote:
>>
>>>>I do not know why you are asking about a change that happened a 
>>>>year ago, but here is the history.  This took quite a bit of time 
>>>>to pull together, and it involved searching the archives kept by 
>>>>several different individuals.
>>>>During IETF Last Call, the authors received a comment regarding 
>>>>the key usage bits.  We have been unsuccessful in locating this 
>>>>email message, so you will have to live with the personal 
>>>>recollection of the content of this message.
>>>
>>>
>>>It is quite strange that such a message has been lost by all the 
>>>editors together. :-|
>>>
>>>Unless someone from the WG mailing list remember that he posted 
>>>this message and makes itself known, the reality of the existence 
>>>of this message will be questionable.
>>>
>>>Can anyone from the WG identifies himself as being the sender of 
>>>the message that lead to that change ?
>>
>>
>>I identify myself as the originator of this mail and confirm that 
>>the aspect referred to by Russ was contained in my comment.
>>
>>I was asked to find this mail as part of the reconstruction you 
>>have requested but was unable to do so due to a disk crash I 
>>suffered from last year where I lost lots of old e-mail.
>>
>>/Stefan




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3A8tDJM020216 for <[e-mail]>; Thu, 10 Apr 2003 01:55:13 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3A8tCGO020215 for ietf-pkix-bks; Thu, 10 Apr 2003 01:55:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h3A8tAJM020208 for <[e-mail]>; Thu, 10 Apr 2003 01:55:11 -0700 (PDT)
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA06350; Thu, 10 Apr 2003 10:58:03 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id JAA08719; Thu, 10 Apr 2003 09:51:39 +0200
Message-ID: <[e-mail]>
Date: Thu, 10 Apr 2003 10:54:54 +0200
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: Stefan Santesson <[e-mail]>, Russ Housley <[e-mail]>, Tim Polk <[e-mail]>, Stephen Kent <[e-mail]>, pkix <[e-mail]>
CC: Jeff Schiller <[e-mail]>, Steve Bellovin <[e-mail]>
Subject: Re: Question about the edition of RFC 3280
References: <[e-mail]> <[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 h3A8tCJM020210
Sender: [e-mail]
Precedence: 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,

Thank you for the response.

I realize that very unfortunately both the sender of the message and the 
receivers of the message lost the message. :-|

Now, looking forward, I would like to make the following proposal:

Next week there is the RSA 2003 Security Conference. I will attend the 
Conference and I guess may other people from the PKIX WG will do so as well.

Since there is the speaker's dinner on the Tuesday and the Gala Dinner of 
the Wednesday, I propose to have an informal meeting about key usage bits 0 
and 1 on the Monday evening for anyone interrested.

I thus propose to meet in the North Lobby, in front of the registration 
desks at 5:30 p.m. on the Monday evening.

I would like to discuss the meaning of a certificate that has:

  1° only the key usage bit 1 set,
  2° only the key usage bit 0 set,
  3° both the key usage bits 0 and 1 set.

   ... when looking at the writing of RFC 2459 and
       when looking at the writing of RFC 3280.

Denis

Note: I blindly copy the OSI Security list, including Hoyt Kesterson who 
will be present at the Conference (and if he may join).


> Denis,
> 
> At 12:10 2003-04-08 +0200, Denis Pinkas wrote:
> 
>>> I do not know why you are asking about a change that happened a year 
>>> ago, but here is the history.  This took quite a bit of time to pull 
>>> together, and it involved searching the archives kept by several 
>>> different individuals.
>>> During IETF Last Call, the authors received a comment regarding the 
>>> key usage bits.  We have been unsuccessful in locating this email 
>>> message, so you will have to live with the personal recollection of 
>>> the content of this message.
>>
>>
>> It is quite strange that such a message has been lost by all the 
>> editors together. :-|
>>
>> Unless someone from the WG mailing list remember that he posted this 
>> message and makes itself known, the reality of the existence of this 
>> message will be questionable.
>>
>> Can anyone from the WG identifies himself as being the sender of the 
>> message that lead to that change ?
> 
> 
> I identify myself as the originator of this mail and confirm that the 
> aspect referred to by Russ was contained in my comment.
> 
> I was asked to find this mail as part of the reconstruction you have 
> requested but was unable to do so due to a disk crash I suffered from 
> last year where I lost lots of old e-mail.
> 
> /Stefan
> 
> 
> 
> 





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3A8rTJM020119 for <[e-mail]>; Thu, 10 Apr 2003 01:53:29 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3A8rTUs020118 for ietf-pkix-bks; Thu, 10 Apr 2003 01:53:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from polito.it (terra.polito.it [130.192.3.81]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3A8rRJM020113 for <[e-mail]>; Thu, 10 Apr 2003 01:53:28 -0700 (PDT)
Received: from [130.192.1.223] (HELO rossoluna) by polito.it (CommuniGate Pro SMTP 4.0.6) with ESMTP-TLS id 5726773; Thu, 10 Apr 2003 10:47:13 +0200
From: "Gianluca Ramunno" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: RFC3161(TSP): doubts about tcp protocol
Date: Thu, 10 Apr 2003 10:52:29 +0200
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.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <p05100321baba2bd3b762@[128.89.88.34]>
Sender: [e-mail]
Precedence: 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 agree with you.
Without a well-defined and mandatory transport protocol, it's quite
difficult to formally define the set of the interoperability tests that are
needed to push forward the TSP on the standard track according to RFC2026.

Regarding the question "which protocol should be mandatory?", in my personal
opinion a good choice may be HTTP.
It might be better profiled than now, e.g. by specifying the use of the POST
method.

The description of the other optional transport protocols should be moved
from the draft body to an informative Annex.

Another question is: is the polling mechanism useful or not? From time to
time there is a debate about it.
The polling mechanism makes the TSP protocol stateful at the transport layer
while it is stateless at the application layer and this is not so good.

In my opinion, if the polling is supposed to be useful, it should be moved
to the application layer. This way this mechanism might be used with any
transport protocol. Such a hypothesis, of course, should take care of the
compatibility with the past.

If the polling is supposed useless, we can leave (and forget) it as is in
the socked-based protocol; but this works only if the socket-based protocol
won't be defined as mandatory.

I think that the polling mechanism can be partially substituted by adding to
'PKIStatus' the following possible value:

<snip from=RFC2510>
waiting                (3),
         -- the request body part has not yet been processed,
         -- expect to hear more later
</snip>

This method doesn't transport back the value of the time to wait for.
On the other side, how may a TSU calculate such time interval?

Gianluca

----------------------------------------------------------------------

Gianluca Ramunno,
Computer and Network Security Group (TORSEC)
Dipartimento di Automatica ed Informatica
Politecnico di Torino - Italy
c/o ICT - Laboratorio di Sicurezza
via Cardinal Massaia 83
10147 Torino

GR e-mail:        [e-mail]
TORSEC e-mail:    [e-mail]
TORSEC home page: http://security.polito.it


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Stephen Kent
> Sent: giovedi 10 aprile 2003 0.31
> To: [e-mail]
> Cc: [e-mail]
> Subject: RE: RFC3161(TSP): doubts about tcp protocol
>
>
>
> Folks,
>
> I'd like to suggest a slightly different tact for this discussion.
>
> I think we need to define one transport protocol as a default, and
> make it a MUST implement, so that all clients and all servers are
> capable of communicating, at least in principle.
>
> I'm sorry that I didn't raise this issue earlier, but, better
> late than never?
>
> I'm agnostic as to what protocol we choose (subject to good arguments
> as to why we chose the protocol in question).
>
> I'd also like to solicit Russ's view on this.
>
> Steve



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3A7AUJM003031 for <[e-mail]>; Thu, 10 Apr 2003 00:10:30 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3A7AUCj003030 for ietf-pkix-bks; Thu, 10 Apr 2003 00:10:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3A7ASJM003007 for <[e-mail]>; Thu, 10 Apr 2003 00:10:28 -0700 (PDT)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h3A7A2oU024466; Thu, 10 Apr 2003 19:10:02 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h3A7A3N21839; Thu, 10 Apr 2003 19:10:03 +1200
Date: Thu, 10 Apr 2003 19:10:03 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: RFC3161(TSP): doubts about tcp protocol
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>

Stephen Kent <[e-mail]> writes:

>I think we need to define one transport protocol as a default, and make it a
>MUST implement, so that all clients and all servers are capable of
>communicating, at least in principle.

Already done: HTTP, same as for CMP.  

Next!

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3A6g8JM028034 for <[e-mail]>; Wed, 9 Apr 2003 23:42:08 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3A6g8Pw028033 for ietf-pkix-bks; Wed, 9 Apr 2003 23:42:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3A6g7JM028024 for <[e-mail]>; Wed, 9 Apr 2003 23:42:07 -0700 (PDT)
Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp4.pacifier.net (Postfix) with ESMTP id A98E56A42D; Wed,  9 Apr 2003 23:23:29 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Von Welch'" <[e-mail]>
Cc: "'IETF-PKIX'" <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-proxy-04
Date: Wed, 9 Apr 2003 23:42:04 -0700
Message-ID: <003301c2ff2c$4ce86de0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
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>

Von,

I've removed those items for which I have no replies.

Jim

 > 9.  Section 3.2 - Please justify this section.  I know of know reason
> why an IssuerAltName should not be allowed in a PC.

There is a good reason why we disallow SubjectAltNames in PC's (see my
response to your issue number #13) and suspect this was a carry over.

Let me push back, is there a valid reason to allow an IssuerAltName in a
PC since the Issuer field must be non-empty (i.e. a Proxy Issuer must
have a non-empty Subject)? If not, I'd prefer to keep it out to keep
path validation simpler.

[JLS] One reason for allowing it is that an EE certificate can have a
SubjectAltName, which could be copied into the PC.


 > 10.  Section 3.4 - I have a problem with the requirement that a
subject  > be unique.  This means that I cannot issue both a signing PC
and an  > encryption PC to a single proxy agent.  Depending on the
algorithm set a  > single certificiate cannot be used for both
operations.

We left this open as an option since the unique name is a SHOULD and not
a MUST. I've rewritten this section to clarify:

3.4	Subject

The subject field of a Proxy Certificate MUST be the issuer field (that
is the subject of the Proxy Issuer) appended with a single Common Name
component.

The value of the Common Name SHOULD be unique to each Proxy Certificate
bearer amongst all Proxy Certificates with the same issuer.

If a Proxy Issuer issues two proxy certificates to the same bearer, the
Proxy Issuer MAY choose to use the same Common Name for both. Examples
of this include Proxy Certificates for different uses (e.g. signing vs
encryption) or the re-issuance of an expired Proxy Certificate.

The Proxy Issuer MAY use an approach to assigning Common Name values
that merely ensures a high probability of uniqueness. This value MAY be
the same value used for the serial number.

The result of this approach is that all subject names of Proxy
Certificates are derived from the name of the issuing EEC (it will be
the first part of the subject name appended with one or more CN
components) and be unique to each bearer.

-end new 3.4-

[JLS] I am not really happy about this, but it is acceptable wording.
The problem I have is that a Proxy Certificate bearer is not really a
defined item.

 > 12.  Section 3.5 - Ditto of item 7.  I can see needing to potentially
> define how to do some conversions, are you just trying to avoid that
> problem?

(Reference should be item 9 instead of item 7)

The reason for this is that some of the subjectAltName forms are not
hierarchical, so we cannot use our current path validation techniques to
verify the validity of a proxy's SubjectAltName.  This means that
applications will have to locate the EEC to determine things like e-mail
address.

[JLS] The only issue that I have here is that I can see proxy's
potentially being named with some things that might not go well here.  I
don't know if these are real, but could see potentially  wanting to put
IP addresses in as alt names for the proxy.  I hate to see this
restricted out without really thinking hard about some cases where this
might be nice.

 > 13. Section 3.6 - Signing only certificate cannot issue encrypting  >
certificate.

I believe the third bullet prohibits this.

 > 14.  Section 3.6 - RSA certificate cannot issue DH certificate.

I don't see why this is relevant to 3.6

Question from one of my coauthors:

What this comment seems to be pushing on is whether the signature
algorithm 
can change between the issuer and the subject.  I don't see why not.  In

fact, I can see some value to this, as you might want to secure an EEC
with 
a stronger algorithm and key, but use a lighter weight approach for a 
short-lived PC.  We already change the key length.  What's the problem
with 
change the algorithm?

[JLS]  This is in response to both 13 and 14.  The reason that an RSA
certificate cannot issue a DH certificate, is that an RSA certificate
will assert the keyEncipherment bit, however a DH certificate needs to
assert the keyAgreement bit.  This is not allowed since this is a change
in the set of keyUsage bits in a non-subset manner.  In the same way, a
signing only certificate would have either the digitialSignature or the
nonRepudiation bit set in KeyUsage.  Since the keyEncipherment or
keyAgreement bits are not set, an encryption certificate could not be
issued.  A certificate with only keyEncipherment would be unable to
issue a certificate since the signature operation is not allowed under
its abilities for verification.  This means that in order to issue a
certificate that allows for encryption, you need to start with an RSA
certificate that allows both keyEncipherment and
digitalSignature/nonReudiation.



 > 19.  Section 3.9.3, bullet item #2 - This does not seem to be a
correct  > statement, what if the policy is Independent, it would be
indepent of  > the EEC's authorizations.  In such a case the proxy could
have MORE  > abilities that the EEC would imply.

Agreed. Changed to:

2) If the Proxy Issuer is an EEC and the right to perform the requested
action is being inherited from the EEC by the proxy policy, then the
relying party's local policies authorize the request for the entity
named in the EEC.

 > 20.  Section 3.9.3 - Paragraph starting "Note that since..." When I
> finally got the last sentence parsed, I think I agreed with it.  I
would  > like to see it written in a clearer manner so I don't have read
it  > multiple times to understand it.  
 > 
 > Suggested text - Te rights granted to the bearer of a PC are the
union  > of the rights granted to the PC identity and the inherited
rights.  The  > inherited rights consist of the intersection of the
rights granted to  > the PI identity intersected with the proxy policy
in the PC.

I like your text, but I'd like to keep most of the first sentence that
is there. I have changed this paragraph to:

Note that since a proxy certificate has a unique identity it MAY also
have rights granted to it by means other than inheritance from it's
issuer via its proxy policy. The rights granted to the bearer of a PC
are the union of the rights granted to the PC identity and the inherited
rights.  The inherited rights consist of the intersection of the rights
granted to the PI identity intersected with the proxy policy in the PC.

[JLS] This reads just fine.

 > 21.  Section 4 - What about all of the Policy information that was
built  > in the EEC path validation algorithm.  Is this suppose to be
passed in  > or are the extensions not to appear in a PC.

The extensions do not appear in PCs.


 > 23.  Section 4 - policies evalution is messed up big time.  At a
minimum  > you need to put in specialized processing rules for
id-ppl-impersonation  > and possibly for independent as well.  Consider
the following:  I ask  > for a specific policy, I find a PC with with
impersonation - according  > to the rules I must reject the PC chain,
but I am sure that is not the  > desired behavior.

I think you are referring to what happens if the impersonation policy
doesn't appear in the acceptable-pc-policy-set and the you encounter a
proxy with that policy?

In that case, yes it should be a failure, since the relying party
doesn't understand the policy involved. We don't specify currently that
any policy MUST be understood.

In practice I suspect most of the time proxy policies will be ignored
during proxy path validation (i.e. acceptable-pc-policy-set will be
equal to any-policy) and not used until authorization. The
acceptable-pc-policy-set is included in path validation so that a
relying party that handles only inherited rights can fail earlier rather
than later.

[JLS]  If this is the case, then I don't see the benefit of having any
policy work done during validation.  If I pass in an acceptable policy,
I want to say it has policy FOO-BAR.  If there is not the ablity to
create a FOO-BAR chain of policy then it needs to be rejected.  The real
problem however is trying to distinguish between a permission and a
policy.  These are not the same things, but I keep wanting to treat them
as such.  I want to pass in the question "Is there a chain which gives
the permission BLAH to this entity?"  This is basically what happens for
the policy evaluation of identity certificates, and thus I expect the
same type of behavior for this chain validation logic given that you are
using the same term "POLICY".  The correct statement to say for the
initialization statement on policies is "This field is initialized to
the set of proxy policies that are understood by the permission
evaluation code."

 > 24.  Section 4 - How does it help to have the proxy_policy_list as an
> output of the process?  I would think that I need a list of <subject
> name,  policy> pairs so that I can go find the extra permissions  >
associated with the subject name.

I agree with this, somehow I was under the impression that the ordered
subject list was also available. I'll add it.

 > 25.  Section 4 - If ACs are to be permitted for anybody other than
the  > leaf PC, this needs to be folded into the validation algorithm.

Can you elaborate on what you mean here?

 > 	id-ppl-impersonation and id-ppl-independent do not match the
 > definitions given in the body of the text with regard to naming of  >
either the OID or the last intenger in the oid string.  The version in
> the ASN.1 file is the correct method of naming.

[JLS]
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) ppl(21) id-ppl-impersonation(1)
Vs
id-ppl-impersonation   OBJECT IDENTIFIER ::= { id-ppl 1 }

In one case the last number is named, in the other the name represents
the entire OID.  These mean slightly different things in ASN.1.  In one
case it is the entire OID, in the other case is really only represents
the value '1'  Use the full x ::= y in the text and I will be happy.





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39MUeJM026549 for <[e-mail]>; Wed, 9 Apr 2003 15:30:40 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h39MUetH026548 for ietf-pkix-bks; Wed, 9 Apr 2003 15:30:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h39MUdJM026509 for <[e-mail]>; Wed, 9 Apr 2003 15:30:39 -0700 (PDT)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h39MUU5w001636; Wed, 9 Apr 2003 18:30:30 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100321baba2bd3b762@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 9 Apr 2003 18:30:39 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: RE: RFC3161(TSP): doubts about tcp protocol
Cc: [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,

I'd like to suggest a slightly different tact for this discussion.

I think we need to define one transport protocol as a default, and 
make it a MUST implement, so that all clients and all servers are 
capable of communicating, at least in principle.

I'm sorry that I didn't raise this issue earlier, but, better late than never?

I'm agnostic as to what protocol we choose (subject to good arguments 
as to why we chose the protocol in question).

I'd also like to solicit Russ's view on this.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38HbnJM003276 for <[e-mail]>; Tue, 8 Apr 2003 10:37:49 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38HbnVd003275 for ietf-pkix-bks; Tue, 8 Apr 2003 10:37:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from vmmr8.verisignmail.com (vmmrnat.verisignmail.com [216.168.230.187]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38HbmJM003271 for <[e-mail]>; Tue, 8 Apr 2003 10:37:48 -0700 (PDT)
Received: from ms1.verisignmail.com (ms1.verisignmail.com [216.168.230.167] (may be forged)) by vmmr8.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id AJN40759; Tue, 8 Apr 2003 13:37:39 -0400 (EDT)
Received: from laptop-cpq.retrospekt.com (t3o902p453.telia.com [81.225.157.213]) by ms1.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id ADL64860; Tue, 8 Apr 2003 13:37:34 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]@mail.retrospekt.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 08 Apr 2003 19:37:32 +0200
To: Denis Pinkas <[e-mail]>, Russ Housley <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: Question about the edition of RFC 3280
Cc: pkix <[e-mail]>, Jeff Schiller <[e-mail]>, Steve Bellovin <[e-mail]>, Tim Polk <[e-mail]>, Stephen Kent <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: 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,

At 12:10 2003-04-08 +0200, Denis Pinkas wrote:
>>I do not know why you are asking about a change that happened a year ago, 
>>but here is the history.  This took quite a bit of time to pull together, 
>>and it involved searching the archives kept by several different individuals.
>>During IETF Last Call, the authors received a comment regarding the key 
>>usage bits.  We have been unsuccessful in locating this email message, so 
>>you will have to live with the personal recollection of the content of 
>>this message.
>
>It is quite strange that such a message has been lost by all the editors 
>together. :-|
>
>Unless someone from the WG mailing list remember that he posted this 
>message and makes itself known, the reality of the existence of this 
>message will be questionable.
>
>Can anyone from the WG identifies himself as being the sender of the 
>message that lead to that change ?

I identify myself as the originator of this mail and confirm that the 
aspect referred to by Russ was contained in my comment.

I was asked to find this mail as part of the reconstruction you have 
requested but was unable to do so due to a disk crash I suffered from last 
year where I lost lots of old e-mail.

/Stefan





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38GFeJM029501 for <[e-mail]>; Tue, 8 Apr 2003 09:15:40 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38GFet7029500 for ietf-pkix-bks; Tue, 8 Apr 2003 09:15:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38GFcJM029485 for <[e-mail]>; Tue, 8 Apr 2003 09:15:38 -0700 (PDT)
Received: from tsg1 (unknown[12.81.121.122]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <2003040816153011100r4tlne>; Tue, 8 Apr 2003 16:15:33 +0000
Message-ID: <005301c2fde9$f22b81a0$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Question about the edition of RFC 3280
Date: Tue, 8 Apr 2003 09:12:06 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: 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

>
> Denis Pinkas <[e-mail]> writes:
>
> >Peter Sylvester raised the following questions:
> >

SNIP

>
> >- how the consensus was achieved.
>
> The consensus is achieved by noting that the RFC reflects the position
that no
> consensus has been (or is likely to ever be) achieved.
>
> (Maybe Dan Streetmentioner needs to come up with a grammatical system for
>  expressing the above).

How about something like:

This design constraint met a consensus for which there were a number of
different uses and operating models and as such, this effort did not define
a "single specific state" that  could be set as the "baseline" in this
technology's standard effort.

Todd



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38E7rJM020111 for <[e-mail]>; Tue, 8 Apr 2003 07:07:53 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38E7r1L020110 for ietf-pkix-bks; Tue, 8 Apr 2003 07:07:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38E7qJM020104 for <[e-mail]>; Tue, 8 Apr 2003 07:07:52 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10956; Tue, 8 Apr 2003 10:05:20 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-pr-tsa-04.txt
Date: Tue, 08 Apr 2003 10:05:19 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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, N. Pope, J. Ross
	Filename	: draft-ietf-pkix-pr-tsa-04.txt
	Pages		: 40
	Date		: 2003-4-7
	
This document defines requirements for a baseline time-stamp policy 
for Time-Stamping Authorities (TSAs) issuing time-stamp tokens, 
supported by public key certificates, with an accuracy of one 
second or better. A TSA may define its own policy which enhances 
the policy defined in the current document. Such a policy shall 
incorporate or further constrain the requirements identified in the 
current document. 
The contents of this Informational RFC is technically equivalent 
to ETSI TS 102 023 V 1.2.1 (2002-06) [TS 102023]. The ETSI TS is 
under the ETSI Copyright (C). Individual copies of this ETSI 
deliverable can be downloaded from http://www.etsi.org

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-pr-tsa-04.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-04.txt".

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


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

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

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

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

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

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-pr-tsa-04.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 [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38E7lJM020096 for <[e-mail]>; Tue, 8 Apr 2003 07:07:47 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38E7lNs020094 for ietf-pkix-bks; Tue, 8 Apr 2003 07:07:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38E7kJM020088 for <[e-mail]>; Tue, 8 Apr 2003 07:07:46 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10932; Tue, 8 Apr 2003 10:05:13 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-acpolicies-extn-03.txt
Date: Tue, 08 Apr 2003 10:05:13 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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 Policies extension
	Author(s)	: C. Francis, D. Pinkas
	Filename	: draft-ietf-pkix-acpolicies-extn-03.txt
	Pages		: 6
	Date		: 2003-4-7
	
This document describes one certificate extension to explicitly 
state the Attribute Certificate (AC) policies that apply to a given 
Attribute Certificate.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-acpolicies-extn-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-acpolicies-extn-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-acpolicies-extn-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-acpolicies-extn-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-acpolicies-extn-03.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 [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38ArlJM004897 for <[e-mail]>; Tue, 8 Apr 2003 03:53:47 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38ArlcM004895 for ietf-pkix-bks; Tue, 8 Apr 2003 03:53:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38ArjJM004890 for <[e-mail]>; Tue, 8 Apr 2003 03:53:46 -0700 (PDT)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h38AqloU002997; Tue, 8 Apr 2003 22:52:47 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h38AqkL05379; Tue, 8 Apr 2003 22:52:46 +1200
Date: Tue, 8 Apr 2003 22:52:46 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Question about the edition of RFC 3280
Cc: [e-mail], [e-mail], [e-mail], [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>

Denis Pinkas <[e-mail]> writes:

>Peter Sylvester raised the following questions:
>
>- Whether this reflects a discussion in the working group for which consensus
>  had been achieved.

No, it reflects the fact that there is no consensus in the WG over how to
handle it, therefore the RFC doesn't try to make a statement one way or the
other.

>- how the consensus was achieved.

The consensus is achieved by noting that the RFC reflects the position that no
consensus has been (or is likely to ever be) achieved.

(Maybe Dan Streetmentioner needs to come up with a grammatical system for
 expressing the above).

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38AB1JM001237 for <[e-mail]>; Tue, 8 Apr 2003 03:11:01 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38AB1Xj001236 for ietf-pkix-bks; Tue, 8 Apr 2003 03:11:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h38AAwJM001217 for <[e-mail]>; Tue, 8 Apr 2003 03:10:59 -0700 (PDT)
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA12558; Tue, 8 Apr 2003 12:13:36 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id LAA20494; Tue, 8 Apr 2003 11:07:13 +0200
Message-ID: <[e-mail]>
Date: Tue, 08 Apr 2003 12:10:31 +0200
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: Russ Housley <[e-mail]>
CC: pkix <[e-mail]>, Jeff Schiller <[e-mail]>, Steve Bellovin <[e-mail]>, Tim Polk <[e-mail]>, Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: Question about the edition of RFC 3280
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

Thank you for this long-awaited answer.

Shortly speaking, the change that has been made cannot be considered as 
"editorial" and introduces an incompatibility with both RFC 2459 and X.509.

Peter Sylvester raised the following questions:

- Whether this reflects a discussion in the working group for which
   consensus had been achieved.

- how the consensus was achieved.

We can see that this change does not reflect a WG consensus and that the WG 
has been kept ignorant when the change was being made (and that the change 
was being made).

Furthermore, the comment that lead to that change has *not* been posted to 
the WG list. We cannot thus speak of a fair and open process.

See additional comments below.

> Denis:
> 
>> ===================================================================
>>
>> A new Request for Comments is now available in online RFC libraries.
>>
>>         RFC 3280
>>
>>         Title:      Internet X.509 Public Key Infrastructure
>>                     Certificate and Certificate Revocation List (CRL)
>>                     Profile
>>         Author(s):  R. Housley, W. Polk, W. Ford, D. Solo
>>         Status:     Standards Track
>>         Date:       April 2002
>>         Mailbox:    [e-mail], [e-mail],
>>                     [e-mail], [e-mail]
>>         Pages:      129
>>         Characters: 295556
>>         Updates/Obsoletes/SeeAlso:    None
>>
>>         I-D Tag:    draft-ietf-pkix-new-part1-12.txt
>>
>> ====================================================================
>>
>> The text that was draft-ietf-pkix-new-part1-12.txt is the following:
>>
>>       "The digitalSignature bit is asserted when the subject public key
>>       is used with a digital signature mechanism to support security
>>       services other than non-repudiation (bit 1), certificate signing
>>       (bit 5), or CRL signing (bit 6).  Digital signature mechanisms are
>>       often used for entity authentication and data origin
>>       authentication with integrity."
>>
>> while the text that is in RFC 3280 is the following:
>>
>>       "The digitalSignature bit is asserted when the subject public key
>>       is used with a digital signature mechanism to support security
>>       services other than certificate signing (bit 5), or CRL signing
>>       (bit 6).  Digital signature mechanisms are often used for entity
>>       authentication and data origin authentication with integrity."
>>
>> I would like to know, how/when such a change happened.
> 
> 
> I do not know why you are asking about a change that happened a year 
> ago, but here is the history.  This took quite a bit of time to pull 
> together, and it involved searching the archives kept by several 
> different individuals.
> 
> During IETF Last Call, the authors received a comment regarding the key 
> usage bits.  We have been unsuccessful in locating this email message, 
> so you will have to live with the personal recollection of the content 
> of this message.  

It is quite strange that such a message has been lost by all the editors 
together. :-|

Unless someone from the WG mailing list remember that he posted this message 
and makes itself known, the reality of the existence of this message will be 
questionable.

Can anyone from the WG identifies himself as being the sender of the message 
that lead to that change ?

> The comment stated that section 4.2.1.3 contained an 
> inconsistency.  The comment pointed to the following text from 
> draft-ietf-pkix-new-part1-12.txt:
> 
>       The digitalSignature bit is asserted when the subject public key
>       is used with a digital signature mechanism to support security
>       services other than non-repudiation (bit 1), certificate signing
>       (bit 5), or CRL signing (bit 6).  Digital signature mechanisms are
>       often used for entity authentication and data origin
>       authentication with integrity.
> 
>       The nonRepudiation bit is asserted when the subject public key is
>       used to verify digital signatures used to provide a non-
>       repudiation service which protects against the signing entity
>       falsely denying some action, excluding certificate or CRL signing.
>       In the case of later conflict, a reliable third party may
>       determine the authenticity of the signed data.
> 
>       Further distinctions between the digitalSignature and
>       nonRepudiation bits may be provided in specific certificate
>       policies.
> 
> The crux of the comment was: When the digitalSignature bit is asserted, 
> then the digital signature mechanism supports security services other 
> than non-repudiation.  This means that there is no overlap between these 
> two bit settings.  This is in conflict with the statement that policy 
> can provide further distinction between digitalSignature and 
> nonRepudiation.

When the addition was discussed noone said that additional text neeeded to 
be changed.

If the person that sent the message saw a contradiction, then this issue 
should have at least advertised to the WG.

A simple way to solve this "contradiction" would have been to delete the 
addition.

As far as I am concerned, I interpreted the sentence by the fact that some 
certificate policies may refuse to issue certificates with the two bits set, 
while some others may accept. The exclusivity of bits 1 and 0 is not 
mandated, but is certainly a potentially very dangerous combination.


> In resolving this comment, the authors also considered the vast volumes 
> of messages on the PKIX WG mail list regarding the disputed meaning of 
> these bits.  Recall that the third paragraph was added as a result of 
> that very long discussion.

Since you mention that it was a disputed debate, any change to that section 
should have been brought back to the group.

> The actual changes were made to the document by the RFC Editor, and the 
> request of the authors and concurrence of the Security Area Director.  
> These changes were considered to be clarifications that resolved an 
> internal inconsistency.

I am sorry, but the change is well behind a "clarification" since it 
introduces a major change with the agreed document placed on the web server, 
i.e. version 12. Once a document is placed on the server, only real 
editorial changes can be done. This one cannot fall in this category.

> The following is the note from the authors to the RFC Editor:
> 
>> Date: Wed, 17 Apr 2002 14:57:50 -0400
>> To: [e-mail]
>> From: Russ Housley <[e-mail]>
>> Subject: Re: draft-ietf-pkix-new-part1-12.txt
>> Cc: [e-mail], [e-mail], [e-mail]
>>
>> Dear RFC Editor:
>>
>> Here are the changes that are needed for draft-ietf-pkix-new-part1-12.txt
>>
>> [snip]
>>
>> Section 4.2.1.3, 4th Paragraph: Drop "non-repudiation (bit 1)" from the
>> 1st sentence.  Otherwise it conflicts with the first and last paragraphs
>> of the same section.
>>
>> OLD:
>>
>>    Bits in the KeyUsage type are used as follows:
>>
>>        The digitalSignature bit is asserted when the subject public key
>>        is used with a digital signature mechanism to support security
>>        services other than non-repudiation (bit 1), certificate signing
>>        (bit 5), or CRL signing (bit 6).  Digital signature mechanisms are
>>        often used for entity authentication and data origin
>>        authentication with integrity.
>>
>> NEW:
>>
>>     Bits in the KeyUsage type are used as follows:
>>
>>        The digitalSignature bit is asserted when the subject public key
>>        is used with a digital signature mechanism to support security
>>        services other than certificate signing (bit 5), or CRL signing
>>        (bit 6).  Digital signature mechanisms are often used for entity
>>        authentication and data origin authentication with integrity.
>>
>> [snip]
> 
> 
> In response to this request, the RFC Editor contacted the Security Area 
> Directors to confirm that the changes were appropriate.  Jeff Schiller 
> responded with the following message:
> 
>> Date: Wed, 17 Apr 2002 19:37:36 -0400
>> From: "Jeffrey I. Schiller" <[e-mail]>
>> To: [e-mail]
>> Cc: [e-mail], [e-mail], [e-mail]
>> Subject: Re: AD response request: Re: draft-ietf-pkix-new-part1-12.txt
>>
>> I have reviewed the changes and they look fine to me.
>>
>>                         -Jeff
>>
>> On Wed, Apr 17, 2002 at 10:18:22PM +0000, [e-mail] 
>> wrote:
>> > Jeff and Steve,
>> >
>> > Could you please verify that the following changes are okay?  For the
>> > most part, they seem editorial in nature, but we wanted to get an okay
>> > from you guys as there are such a great number of changes.
>> >
>> > Thank you.
>> >
>> > RFC Editor

> Denis, this is the history.  

We cannot change history, but we can now consider how to correct the situation.

> I think you can see that an appropriate comment resolution process was followed. 

I have to disagree with your statement.

 > I am sure you have faced similar comments on documents that you have
 > authored.

Up to now, I have not faced such a situation, and given that experience it 
is very unlikely that I will ever face it.

I am awaiting for proposals from yourself, the co-chairs and/or the Security 
Area Directors on the way to re-establish a backward compatibility with RFC 
2459.

Denis

> Russ





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h387tcJM012105 for <[e-mail]>; Tue, 8 Apr 2003 00:55:38 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h387tcdF012104 for ietf-pkix-bks; Tue, 8 Apr 2003 00:55:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h387taJM012071 for <[e-mail]>; Tue, 8 Apr 2003 00:55:37 -0700 (PDT)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h387ssoU032530; Tue, 8 Apr 2003 19:54:54 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h387sqH04715; Tue, 8 Apr 2003 19:54:52 +1200
Date: Tue, 8 Apr 2003 19:54:52 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: RFC3161(TSP): doubts about tcp protocol
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>

"Pere Fiol" <[e-mail]> writes:

>I think that will be a good idea change test of RFC to include this situation
>in Socket chapter, my proposal is:

I agree with this.  As has been pointed out repeatedly in the past, since the
TSP sockets protocol serves no useful purpose, implementations are just
memcpy()'ing in magic values on transmission and treating it as noise to be
stripped on receipt.  Because of this, you can specify anything you like in
the RFC safe in the knowledge that implementors will completely ignore what
you're saying.  As far as I'm concerned, feel free to say whatever makes you
happy in there, although since it's going to be ignored anyway it'd be fun to
require that anyone sending a TSP message be required to jump up and down
saying "I'm a teapot! I'm a teapot!" or something.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h386cCJM029495 for <[e-mail]>; Mon, 7 Apr 2003 23:38:12 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h386cCH5029493 for ietf-pkix-bks; Mon, 7 Apr 2003 23:38:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from amatabogados.com ([213.229.156.25]) by above.proper.com (8.12.9/8.11.6) with SMTP id h386c8JM029428 for <[e-mail]>; Mon, 7 Apr 2003 23:38:09 -0700 (PDT)
Received: from gandalf [213.96.78.77] by amatabogados.com (SMTPD32-4.07) id AED516E01CA; Tue, 08 Apr 2003 08:40:21 +0200
From: "Pere Fiol" <[e-mail]>
To: "'todd glassey'" <[e-mail]>, "'Denis Pinkas'" <[e-mail]>
Cc: "'ietf'" <[e-mail]>
Subject: RE: RFC3161(TSP): doubts about tcp protocol
Date: Tue, 8 Apr 2003 08:37:07 +0200
Message-ID: <001201c2fd99$47b800e0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
In-Reply-To: <00f201c2fd14$9a67c3a0$020aff0a@tsg1>
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>

Hi,

I think the same than Todd!! The messages must be well formed in order
to be more secure and robust ...

I think that will be a good idea change test of RFC to include this
situation in Socket chapter, my proposal is:

------------------------------------------------------------------------
----
3.3. Socket Based Protocol

...

The socket protocol is a FULL duplex protocol. So, if the request is
sended with a
 wrong format and the server can decode it, the server SHOULD response
with a error message 
 and close connection nicely. But, if it isn't possible decode the
response for any reason (as long time waitting without receive any
byte), the server SHOULD break connection without 
send any kind of error message to client.

------------------------------------------------------------------------
----

Best Regards,
Pere



-----Mensaje original-----
De: [e-mail] [mailto:[e-mail]]
En nombre de todd glassey
Enviado el: lunes, 07 de abril de 2003 16:26
Para: Denis Pinkas; Pere Fiol
CC: ietf
Asunto: Re: RFC3161(TSP): doubts about tcp protocol


Denis - the question is whether Error Conditions of this sort apply to
the
trust processes in some fashion, or are deemed to be transport failings.
If
there is a rule that say's that the TSA can only accept "properly formed
messages" as part of its operations process, then this situation is not
so
much an issue.

The problem comes in when you try to build a dynamic protocols that can
"negotiate" because then each state and decision matrix has to be
defined.
And for what the TSP is, that is too much "noise" in its possible uses.
They
need to be better defined as I have always said. Otherwise - you have
the
potential of having  many implementations of the TSA with unpredictable
interactions...

My feeling is that any Trust Protocol that receives an invalid or
malformed
request should reject that request "whole cloth" for security and
process-integrity reasons.

Todd Glassey

----- Original Message -----
From: "Denis Pinkas" <[e-mail]>
To: "Pere Fiol" <[e-mail]>
Cc: "ietf" <[e-mail]>
Sent: Monday, April 07, 2003 1:08 AM
Subject: Re: RFC3161(TSP): doubts about tcp protocol


>
> > Hi,
>
> > I've developed a TSA but I have a doubt in TCP protocol: if a client
> > sends a request to TSA with invalid TCP message (for example with a
flag
> > different of '00'H, with wrong number of bytes in length,...) What
must
> > do a TSA in this situations?? RFC3161 mustn't talk something about
it??
>
> Does anyone has a text proposal to clarify this situation ?
>
> Denis
>
> > Thanks and Best Regards,
> > Pere Fiol
>
>




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3820OJM012661 for <[e-mail]>; Mon, 7 Apr 2003 19:00:24 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3820Oeg012660 for ietf-pkix-bks; Mon, 7 Apr 2003 19:00:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from smtp.newpki.org (ATuileries-102-1-2-21.abo.wanadoo.fr [193.253.207.21]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3820MJM012655 for <[e-mail]>; Mon, 7 Apr 2003 19:00:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.newpki.org (Postfix) with ESMTP id 526E4B5B7 for <[e-mail]>; Tue,  8 Apr 2003 03:02:15 +0200 (CEST)
Received: from smtp.newpki.org (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.1.10) id 12459-68DF774F; Tue, 08 Apr 2003 03:01:25 +0200
Received: from newpki.org (unknown [192.168.0.1]) by smtp.newpki.org (Postfix) with SMTP id 83375B5B5 for <[e-mail]>; Tue,  8 Apr 2003 03:01:25 +0200 (CEST)
Received: from 212.194.19.193 (SquirrelMail authenticated user groups) by webmail.newpki.org with HTTP; Tue, 8 Apr 2003 04:00:16 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Tue, 8 Apr 2003 04:00:16 +0200 (CEST)
Subject: CMP RFC2510bis-07 implementation
From: "=?iso-8859-1?Q?Fr=E9d=E9ric_Giudicelli?=" <[e-mail]>
To: <[e-mail]>
X-Priority: 3
Importance: Normal
X-Mailer: SquirrelMail (version 1.2.10)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.10; AVE: 6.18.0.1; VDF: 6.18.0.4; host: server-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,
I'm currently working on an implementation of CMP for my PKI project,
however I cam
accross a problem.
In my architecture, I try to put the Repository in the center of the PKI,
meaning
that all datas go thru the repository which will dispatch the messages to
the porper
entities.
This architecture allows me to have some redundancy, I can create many
repositories
that can synchronize between each other, plus when a CA is offline I can
connect to
the repository and export all the certificate-requests for the CA, whereas
if I
follow the PKIX architectural model (1.4), for each RA that can request
certificates
from an offline CA I will have to export the requests to a file and then
import them
to the offline CA, import the responses back to each RA, which becomes very
complicated...
In my emplementation the repository stands as a unique interface between
all entities.

My application is TCPIP client/server model, on one server I can have many
entities,
the server will then be in charge of dispatching the CMP message to the
proper
entity, identified by PKIHeader:recipient (3.1.1).
That's where my problem starts; in the case of a certificate request,
PKIHeader:recipient should contains the name of the destination entity,
which in the
PKIX implementation should be the CA name; problems in my implementation
it should
be the name of the respository (for the TCPIP server to be able to feed the
repository with the request), now if PKIHeader:recipient contains the name
of the
repository how will the repository know the destination CA ?

Maybe there should a new field in PKIHeader, such as:
- netRecipient GeneralName OPTIONAL (which identifies the intermediate
recipient,
the repository in my case)
- recipient GeneralName (which identifies the final recipient, the CA in
my case)

I hope someone will be able to solve this problem.
Thanks,
Frédéric Giudicelli
http://www.newpki.org






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37GijJM015679 for <[e-mail]>; Mon, 7 Apr 2003 09:44:45 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37GijMw015678 for ietf-pkix-bks; Mon, 7 Apr 2003 09:44:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37GihJM015673 for <[e-mail]>; Mon, 7 Apr 2003 09:44:44 -0700 (PDT)
Received: from tsg1 (unknown[12.81.121.134]) by mtiwmhc13.worldnet.att.net (mtiwmhc13) with SMTP id <2003040716442411300a23lce>; Mon, 7 Apr 2003 16:44:24 +0000
Message-ID: <028401c2fd24$d4c5d4a0$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: <[e-mail]>
Subject: Fw: NIST FISSEA Security Presentations available
Date: Mon, 7 Apr 2003 09:43:28 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: 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 don't know how many of you saw this -

----- Original Message -----

>
> Hi.  I'm the webmaster for CSRC and also for the FISSEA website.  I just
> wanted to let you know that I have uploaded the presentations for the
> FISSEA Conference to the website this morning.
> http://csrc.nist.gov/organizations/fissea/conference/2003/index.html
>
> The
> link will take you to the 2003 Conference homepage.  Click the Agenda &
> Presentation link (top right corner) and it will take you to the Agenda
> page.  Within this page, you will find links to the presentations that we
> have received thus far from the presenters.  Not all presenters left or
> gave us their presentation.  Hopefully in the near future, we will get
most
> if not all of the presentations.  The links are found under the title of
> the talk column.  All presentations are in Adobe .pdf format.
>
> Hope this helps and thank you for writing.  Sorry it took a little longer
> to post these presentations, but I have been rather swamped with things to
> do.
>
>
> Sincerely,
> Pat O'Reilly
> CSRC & FISSEA webmaster
> NIST
>
> To unsubscribe send the following in the body of a message to
> [e-mail]  - unsubscribe st-isc



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37FJXJM009191 for <[e-mail]>; Mon, 7 Apr 2003 08:19:33 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37FJWbc009190 for ietf-pkix-bks; Mon, 7 Apr 2003 08:19:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37FJVJM009171 for <[e-mail]>; Mon, 7 Apr 2003 08:19:31 -0700 (PDT)
Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6659); Mon, 7 Apr 2003 08:19:28 -0700
Received: from 157.54.5.25 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 07 Apr 2003 08:19:27 -0700
Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Mon, 7 Apr 2003 08:19:27 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 7 Apr 2003 08:19:27 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Mon, 7 Apr 2003 08:19:27 -0700
MIME-Version: 1.0
Subject: RE: OCSP - Adoption of response models
From: "Ryan M. Hurst" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>, <[e-mail]> <000e01c2fb96$98a3a510$8800a8c0@OFFICE>, <[e-mail]>
To: Jean-Marc Desperrier <[e-mail]>, <[e-mail]>
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Date: Mon, 7 Apr 2003 08:19:06 -0700
Thread-Topic: RE: OCSP - Adoption of response models
Thread-Index: AcL9GQdrrSrM2Wr/RNC7LUnuLhWACg==
Message-ID: <001201c2fd19$0780b050$8800a8c0@OFFICE>
X-Mailer: Microsoft Outlook Web Access 6.5.6851.6
X-MimeCtl: Produced By Microsoft Exchange V6.5.6851.6
X-OriginalArrivalTime: 07 Apr 2003 15:19:27.0244 (UTC) FILETIME=[1410A4C0:01C2FD19]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="_597D9D4C-4596-41AE-B59D-17D0180093F6_"

--_597D9D4C-4596-41AE-B59D-17D0180093F6_
Content-Type: text/plain;
	charset="iso-8859-1";
	format=flowed
Content-Transfer-Encoding: quoted-printable




From: Jean-Marc Desperrier
Sent: Sat 4/5/2003 4:36 PM
To: [e-mail]
Subject: Re: OCSP - Adoption of response models


Ryan M. Hurst wrote:

>Responder Load
>Just like with CRLs responder load usually happens at a fixed time (nextUp=
date) so issuers need to scope deployment so accommodate peeks vs. having l=
oad distributed. Servers should "shift" the nextUpdate to control this, and=
 clients should intelligently pre-fetch information to help distribute the =
load.
>
Are they really many clients that cache OSCP response until nextUpdate ?
OCSP just simply generates lot of load.
IMO large scale use can only be handled with a network of responders,=20
not a single one.

[rmh] Well, I know of several but either way my statements were not necessa=
rily based on what clients do today; instead they were intended to communic=
ate what I beleive is necessary to scale the protocol to support ssl server=
 revocation in "internet" volumes. It is cost pro-hibitive for a certificat=
e issuer to operate enough OCSP responders to handle peek loads associated =
with every get to a the amazons and ebays of the worlds especialy consideri=
ng that in many cases one issuer may be responsible for 60+% of the certifi=
cate issuence.
>Responder Freshness
>OCSP does not provide a mechanism for the client to request a real-time re=
sponse, this makes deploying a system that serves cached responses most of =
the time and dynamic ones on demand not really viable.
> =20
>
This can be done by setting up clients so that will not use a nonce=20
usually, getting a pre-produced response, and when they need a real time=20
response, they'll use the nonce in the request.

[rmh] I recognize that the protocol has a nonce, and the nonce could be int=
erpreted as you say; additionally I have seen several implementations that =
do but with that being said the RFC does not describe behavior in this area=
 as a result I have also seen many implementations thatbehave poorly when n=
o monce is suppplied.

--_597D9D4C-4596-41AE-B59D-17D0180093F6_
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD>
<BODY>
<DIV id=3DidOWAReplyText20508 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2></FONT>&nbsp;</D=
IV></DIV>
<DIV dir=3Dltr>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Jean-Marc Desperrier<BR><B>Sent:<=
/B> Sat 4/5/2003 4:36 PM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B>=
 Re: OCSP - Adoption of response models<BR></FONT><BR></DIV>
<DIV><PRE style=3D"WORD-WRAP: break-word">Ryan M. Hurst wrote:

&gt;Responder Load
&gt;Just like with CRLs responder load usually happens at a fixed time (nex=
tUpdate) so issuers need to scope deployment so accommodate peeks vs. havin=
g load distributed. Servers should "shift" the nextUpdate to control this, =
and clients should intelligently pre-fetch information to help distribute t=
he load.
&gt;
Are they really many clients that cache OSCP response until nextUpdate ?
OCSP just simply generates lot of load.
IMO large scale use can only be handled with a network of responders,=20
not a single one.
</PRE><PRE style=3D"WORD-WRAP: break-word">[rmh] Well, I know of several bu=
t either way my statements were not necessarily based on what clients do to=
day; instead they were intended to communicate what I beleive is necessary =
to scale the protocol to support ssl server revocation in "internet" volume=
s. It is cost pro-hibitive for a certificate issuer to operate enough OCSP =
responders to handle peek loads associated with every get to a the amazons =
and ebays of the worlds especialy considering that in many cases one issuer=
 may be responsible for 60+% of the certificate issuence.</PRE><PRE style=
=3D"WORD-WRAP: break-word">&gt;Responder Freshness
&gt;OCSP does not provide a mechanism for the client to request a real-time=
 response, this makes deploying a system that serves cached responses most =
of the time and dynamic ones on demand not really viable.
&gt; =20
&gt;
This can be done by setting up clients so that will not use a nonce=20
usually, getting a pre-produced response, and when they need a real time=20
response, they'll use the nonce in the request.
</PRE><PRE style=3D"WORD-WRAP: break-word">[rmh] I recognize that the proto=
col has a nonce, and the nonce could be interpreted as you say; additionall=
y I have seen several implementations that do but with that being said the =
RFC does not describe behavior in this area as a result I have also seen ma=
ny implementations thatbehave poorly when no monce is suppplied.



</PRE></DIV></BODY></HTML>

--_597D9D4C-4596-41AE-B59D-17D0180093F6_--

--------------InterScan_NT_MIME_Boundary--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37FHRJM008880 for <[e-mail]>; Mon, 7 Apr 2003 08:17:27 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37FHRL3008879 for ietf-pkix-bks; Mon, 7 Apr 2003 08:17:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.11.6) with SMTP id h37FHQJM008870 for <[e-mail]>; Mon, 7 Apr 2003 08:17:26 -0700 (PDT)
Received: (qmail 2738 invoked by uid 0); 7 Apr 2003 15:16:55 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.168.151) by woodstock.binhost.com with SMTP; 7 Apr 2003 15:16:55 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 07 Apr 2003 11:17:11 -0400
To: Denis Pinkas <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Question about the edition of RFC 3280
Cc: pkix <[e-mail]>, Jeff Schiller <[e-mail]>, Steve Bellovin <[e-mail]>, Tim Polk <[e-mail]>, Stephen Kent <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis:

>===================================================================
>
>A new Request for Comments is now available in online RFC libraries.
>
>         RFC 3280
>
>         Title:      Internet X.509 Public Key Infrastructure
>                     Certificate and Certificate Revocation List (CRL)
>                     Profile
>         Author(s):  R. Housley, W. Polk, W. Ford, D. Solo
>         Status:     Standards Track
>         Date:       April 2002
>         Mailbox:    [e-mail], [e-mail],
>                     [e-mail], [e-mail]
>         Pages:      129
>         Characters: 295556
>         Updates/Obsoletes/SeeAlso:    None
>
>         I-D Tag:    draft-ietf-pkix-new-part1-12.txt
>
>====================================================================
>
>The text that was draft-ietf-pkix-new-part1-12.txt is the following:
>
>       "The digitalSignature bit is asserted when the subject public key
>       is used with a digital signature mechanism to support security
>       services other than non-repudiation (bit 1), certificate signing
>       (bit 5), or CRL signing (bit 6).  Digital signature mechanisms are
>       often used for entity authentication and data origin
>       authentication with integrity."
>
>while the text that is in RFC 3280 is the following:
>
>       "The digitalSignature bit is asserted when the subject public key
>       is used with a digital signature mechanism to support security
>       services other than certificate signing (bit 5), or CRL signing
>       (bit 6).  Digital signature mechanisms are often used for entity
>       authentication and data origin authentication with integrity."
>
>I would like to know, how/when such a change happened.

I do not know why you are asking about a change that happened a year ago, 
but here is the history.  This took quite a bit of time to pull together, 
and it involved searching the archives kept by several different individuals.

During IETF Last Call, the authors received a comment regarding the key 
usage bits.  We have been unsuccessful in locating this email message, so 
you will have to live with the personal recollection of the content of this 
message.  The comment stated that section 4.2.1.3 contained an 
inconsistency.  The comment pointed to the following text from 
draft-ietf-pkix-new-part1-12.txt:

       The digitalSignature bit is asserted when the subject public key
       is used with a digital signature mechanism to support security
       services other than non-repudiation (bit 1), certificate signing
       (bit 5), or CRL signing (bit 6).  Digital signature mechanisms are
       often used for entity authentication and data origin
       authentication with integrity.

       The nonRepudiation bit is asserted when the subject public key is
       used to verify digital signatures used to provide a non-
       repudiation service which protects against the signing entity
       falsely denying some action, excluding certificate or CRL signing.
       In the case of later conflict, a reliable third party may
       determine the authenticity of the signed data.

       Further distinctions between the digitalSignature and
       nonRepudiation bits may be provided in specific certificate
       policies.

The crux of the comment was: When the digitalSignature bit is asserted, 
then the digital signature mechanism supports security services other than 
non-repudiation.  This means that there is no overlap between these two bit 
settings.  This is in conflict with the statement that policy can provide 
further distinction between digitalSignature and nonRepudiation.

In resolving this comment, the authors also considered the vast volumes of 
messages on the PKIX WG mail list regarding the disputed meaning of these 
bits.  Recall that the third paragraph was added as a result of that very 
long discussion.

The actual changes were made to the document by the RFC Editor, and the 
request of the authors and concurrence of the Security Area 
Director.  These changes were considered to be clarifications that resolved 
an internal inconsistency.

The following is the note from the authors to the RFC Editor:

>Date: Wed, 17 Apr 2002 14:57:50 -0400
>To: [e-mail]
>From: Russ Housley <[e-mail]>
>Subject: Re: draft-ietf-pkix-new-part1-12.txt
>Cc: [e-mail], [e-mail], [e-mail]
>
>Dear RFC Editor:
>
>Here are the changes that are needed for draft-ietf-pkix-new-part1-12.txt
>
>[snip]
>
>Section 4.2.1.3, 4th Paragraph: Drop "non-repudiation (bit 1)" from the
>1st sentence.  Otherwise it conflicts with the first and last paragraphs
>of the same section.
>
>OLD:
>
>    Bits in the KeyUsage type are used as follows:
>
>        The digitalSignature bit is asserted when the subject public key
>        is used with a digital signature mechanism to support security
>        services other than non-repudiation (bit 1), certificate signing
>        (bit 5), or CRL signing (bit 6).  Digital signature mechanisms are
>        often used for entity authentication and data origin
>        authentication with integrity.
>
>NEW:
>
>     Bits in the KeyUsage type are used as follows:
>
>        The digitalSignature bit is asserted when the subject public key
>        is used with a digital signature mechanism to support security
>        services other than certificate signing (bit 5), or CRL signing
>        (bit 6).  Digital signature mechanisms are often used for entity
>        authentication and data origin authentication with integrity.
>
>[snip]

In response to this request, the RFC Editor contacted the Security Area 
Directors to confirm that the changes were appropriate.  Jeff Schiller 
responded with the following message:

>Date: Wed, 17 Apr 2002 19:37:36 -0400
>From: "Jeffrey I. Schiller" <[e-mail]>
>To: [e-mail]
>Cc: [e-mail], [e-mail], [e-mail]
>Subject: Re: AD response request: Re: draft-ietf-pkix-new-part1-12.txt
>
>I have reviewed the changes and they look fine to me.
>
>                         -Jeff
>
>On Wed, Apr 17, 2002 at 10:18:22PM +0000, [e-mail] wrote:
> > Jeff and Steve,
> >
> > Could you please verify that the following changes are okay?  For the
> > most part, they seem editorial in nature, but we wanted to get an okay
> > from you guys as there are such a great number of changes.
> >
> > Thank you.
> >
> > RFC Editor

Denis, this is the history.  I think you can see that an appropriate 
comment resolution process was followed.  I am sure you have faced similar 
comments on documents that you have authored.

Russ



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37EmKJM005881 for <[e-mail]>; Mon, 7 Apr 2003 07:48:20 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37EmKww005880 for ietf-pkix-bks; Mon, 7 Apr 2003 07:48:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37EmIJM005867 for <[e-mail]>; Mon, 7 Apr 2003 07:48:18 -0700 (PDT)
Received: from tsg1 (unknown[12.81.121.134]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <2003040714481211200p024ee>; Mon, 7 Apr 2003 14:48:13 +0000
Message-ID: <00f201c2fd14$9a67c3a0$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Pere Fiol" <[e-mail]>
Cc: "ietf" <[e-mail]>
References: <002701c2d37f$a8accf00$0200a8c0@host> <[e-mail]>
Subject: Re: RFC3161(TSP): doubts about tcp protocol
Date: Mon, 7 Apr 2003 07:25:42 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: 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 - the question is whether Error Conditions of this sort apply to the
trust processes in some fashion, or are deemed to be transport failings. If
there is a rule that say's that the TSA can only accept "properly formed
messages" as part of its operations process, then this situation is not so
much an issue.

The problem comes in when you try to build a dynamic protocols that can
"negotiate" because then each state and decision matrix has to be defined.
And for what the TSP is, that is too much "noise" in its possible uses. They
need to be better defined as I have always said. Otherwise - you have the
potential of having  many implementations of the TSA with unpredictable
interactions...

My feeling is that any Trust Protocol that receives an invalid or malformed
request should reject that request "whole cloth" for security and
process-integrity reasons.

Todd Glassey

----- Original Message -----
From: "Denis Pinkas" <[e-mail]>
To: "Pere Fiol" <[e-mail]>
Cc: "ietf" <[e-mail]>
Sent: Monday, April 07, 2003 1:08 AM
Subject: Re: RFC3161(TSP): doubts about tcp protocol


>
> > Hi,
>
> > I've developed a TSA but I have a doubt in TCP protocol: if a client
> > sends a request to TSA with invalid TCP message (for example with a flag
> > different of '00'H, with wrong number of bytes in length,...) What must
> > do a TSA in this situations?? RFC3161 mustn't talk something about it??
>
> Does anyone has a text proposal to clarify this situation ?
>
> Denis
>
> > Thanks and Best Regards,
> > Pere Fiol
>
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37CmDJM029764 for <[e-mail]>; Mon, 7 Apr 2003 05:48:13 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37CmD8t029763 for ietf-pkix-bks; Mon, 7 Apr 2003 05:48:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37CmBJM029744 for <[e-mail]>; Mon, 7 Apr 2003 05:48:12 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id OAA22896; Mon, 7 Apr 2003 14:48:07 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.6); Mon, 7 Apr 2003 14:48:07 +0200 (MET DST)
Received: (from sylvest@localhost) by champagne.edelweb.fr (8.7.6/8.6.6) id OAA13182; Mon, 7 Apr 2003 14:48:05 +0200 (MET DST)
Date: Mon, 7 Apr 2003 14:48:05 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Question about the edition of RFC 3280
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,

It happened when the editor put it into the text. He typed
this using his favorite editing program. :-)

(A little bit more) seriously, I don't think that you want to know this. 

You (and also others) might want to know (one or more of)

- why the change was made.

- Whether this reflects a discussion in the working group for which
  consensus had been achieved.

- how the consensus was achieved.

It may be helpful to indicate what problem do you have with the change.
  
regards
Peter

> 
> The text that was draft-ietf-pkix-new-part1-12.txt is the following:
> 
>        "The digitalSignature bit is asserted when the subject public key
>        is used with a digital signature mechanism to support security
>        services other than non-repudiation (bit 1), certificate signing
>        (bit 5), or CRL signing (bit 6).  Digital signature mechanisms are
>        often used for entity authentication and data origin
>        authentication with integrity."
> 
> while the text that is in RFC 3280 is the following:
> 
>        "The digitalSignature bit is asserted when the subject public key
>        is used with a digital signature mechanism to support security
>        services other than certificate signing (bit 5), or CRL signing
>        (bit 6).  Digital signature mechanisms are often used for entity
>        authentication and data origin authentication with integrity."
> 
> I would like to know, how/when such a change happened.
> 
> Thanks,
> 
> Denis
> 
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h379ZZJM012798 for <[e-mail]>; Mon, 7 Apr 2003 02:35:35 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h379ZZVP012797 for ietf-pkix-bks; Mon, 7 Apr 2003 02:35:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from huva.hittite.isp.9tel.net (huva.hittite.isp.9tel.net [62.62.156.28]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h379ZXJM012782 for <[e-mail]>; Mon, 7 Apr 2003 02:35:34 -0700 (PDT)
Received: from free.fr (8.102-30-212.9massy1-1-ro-as-i1-2.9tel.net [212.30.102.8]) by huva.hittite.isp.9tel.net (Postfix) with ESMTP id 0D2CA9C215 for <[e-mail]>; Sun,  6 Apr 2003 02:35:07 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Sun, 06 Apr 2003 02:36:36 +0200
From: Jean-Marc Desperrier <[e-mail]>
Organization: totalement desorganise
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030129
X-Accept-Language: en-us, en, fr, fr-fr, ja
MIME-Version: 1.0
To: [e-mail]
Subject: Re: OCSP - Adoption of response models
References: <[e-mail]>, <[e-mail]> <000e01c2fb96$98a3a510$8800a8c0@OFFICE>
In-Reply-To: <000e01c2fb96$98a3a510$8800a8c0@OFFICE>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ryan M. Hurst wrote:

>Responder Load
>Just like with CRLs responder load usually happens at a fixed time (nextUpdate) so issuers need to scope deployment so accommodate peeks vs. having load distributed. Servers should "shift" the nextUpdate to control this, and clients should intelligently pre-fetch information to help distribute the load.
>
Are they really many clients that cache OSCP response until nextUpdate ?
OCSP just simply generates lot of load.
IMO large scale use can only be handled with a network of responders, 
not a single one.

>Responder Freshness
>OCSP does not provide a mechanism for the client to request a real-time response, this makes deploying a system that serves cached responses most of the time and dynamic ones on demand not really viable.
>  
>
This can be done by setting up clients so that will not use a nonce 
usually, getting a pre-produced response, and when they need a real time 
response, they'll use the nonce in the request.






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h378HeJM001408 for <[e-mail]>; Mon, 7 Apr 2003 01:17:40 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h378HeiS001407 for ietf-pkix-bks; Mon, 7 Apr 2003 01:17:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h378HbJM001394 for <[e-mail]>; Mon, 7 Apr 2003 01:17:39 -0700 (PDT)
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAB21174; Mon, 7 Apr 2003 10:15:14 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id JAA08751; Mon, 7 Apr 2003 09:08:52 +0200
Message-ID: <[e-mail]>
Date: Mon, 07 Apr 2003 10:12:10 +0200
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: IETF Internet-Drafts posting <[e-mail]>
CC: pkix <[e-mail]>, Jeff Schiller <[e-mail]>, Steve Bellovin <[e-mail]>, Tim Polk <[e-mail]>, Stephen Kent <[e-mail]>, Russ Housley <[e-mail]>
Subject: Question about the edition of RFC 3280
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear web editor,

An e-mail from the RFC editor dated from May 10, 2002 states:

===================================================================

A new Request for Comments is now available in online RFC libraries.

         RFC 3280

         Title:      Internet X.509 Public Key Infrastructure
                     Certificate and Certificate Revocation List (CRL)
                     Profile
         Author(s):  R. Housley, W. Polk, W. Ford, D. Solo
         Status:     Standards Track
         Date:       April 2002
         Mailbox:    [e-mail], [e-mail],
                     [e-mail], [e-mail]
         Pages:      129
         Characters: 295556
         Updates/Obsoletes/SeeAlso:    None

         I-D Tag:    draft-ietf-pkix-new-part1-12.txt

====================================================================

The text that was draft-ietf-pkix-new-part1-12.txt is the following:

       "The digitalSignature bit is asserted when the subject public key
       is used with a digital signature mechanism to support security
       services other than non-repudiation (bit 1), certificate signing
       (bit 5), or CRL signing (bit 6).  Digital signature mechanisms are
       often used for entity authentication and data origin
       authentication with integrity."

while the text that is in RFC 3280 is the following:

       "The digitalSignature bit is asserted when the subject public key
       is used with a digital signature mechanism to support security
       services other than certificate signing (bit 5), or CRL signing
       (bit 6).  Digital signature mechanisms are often used for entity
       authentication and data origin authentication with integrity."

I would like to know, how/when such a change happened.

Thanks,

Denis



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h378HMJM001352 for <[e-mail]>; Mon, 7 Apr 2003 01:17:22 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h378HMu5001350 for ietf-pkix-bks; Mon, 7 Apr 2003 01:17:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mail3.consignia.com (mail.royalmail.com [144.87.143.83]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h378HLJM001342 for <[e-mail]>; Mon, 7 Apr 2003 01:17:22 -0700 (PDT)
Received: from postoffice.co.uk (unknown [144.87.146.16]) by mail3.consignia.com (Postfix) with SMTP id 9F2F718FA51 for <[e-mail]>; Mon,  7 Apr 2003 09:17:20 +0100 (BST)
Received: by postoffice.co.uk(Lotus SMTP MTA v4.6.6  (890.1 7-16-1999))  id 00256D01.003309D6 ; Mon, 7 Apr 2003 09:17:28 +0000
X-Lotus-FromDomain: POSTOFFICE
From: [e-mail]
To: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 7 Apr 2003 09:17:06 +0000
Subject: RE: OCSP - Adoption of response models - Thanks
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks for all your responses. It's clear that there are many
points of view and differences of opinion. The technology
remains under limited deployment, IMO, with local trust models
preferred. In the context of Interoperability, which is the basis of
my study,  I feel very strongly that the model based on explicit
delegation offers the most potential as it componentises the
actual mechanics and its success depends entirely on the
interoperability of the components. Of course, this model could
also adequately serve the needs of a single company.

Chris




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3788HJM029319 for <[e-mail]>; Mon, 7 Apr 2003 01:08:17 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3788HXP029318 for ietf-pkix-bks; Mon, 7 Apr 2003 01:08:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h3788DJM029300 for <[e-mail]>; Mon, 7 Apr 2003 01:08:15 -0700 (PDT)
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA31542; Mon, 7 Apr 2003 10:11:07 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id JAA08729; Mon, 7 Apr 2003 09:04:46 +0200
Message-ID: <[e-mail]>
Date: Mon, 07 Apr 2003 10:08:04 +0200
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: Pere Fiol <[e-mail]>
CC: ietf <[e-mail]>
Subject: Re: RFC3161(TSP): doubts about tcp protocol
References: <002701c2d37f$a8accf00$0200a8c0@host>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Hi,

> I've developed a TSA but I have a doubt in TCP protocol: if a client 
> sends a request to TSA with invalid TCP message (for example with a flag 
> different of '00'H, with wrong number of bytes in length,...) What must 
> do a TSA in this situations?? RFC3161 mustn't talk something about it??

Does anyone has a text proposal to clarify this situation ?

Denis

> Thanks and Best Regards,
> Pere Fiol




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h36IgpJM018809 for <[e-mail]>; Sun, 6 Apr 2003 11:42:51 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h36IgphW018808 for ietf-pkix-bks; Sun, 6 Apr 2003 11:42:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from rhenium.btinternet.com (rhenium.btinternet.com [194.73.73.93]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h36IgnJM018802 for <[e-mail]>; Sun, 6 Apr 2003 11:42:50 -0700 (PDT)
Received: from host213-122-111-4.in-addr.btopenworld.com ([213.122.111.4] helo=ascertiacompaq) by rhenium.btinternet.com with smtp (Exim 3.22 #23) id 192F6N-0005K1-00 for [e-mail]; Sun, 06 Apr 2003 19:42:48 +0100
From: "Liaquat Khan" <[e-mail]>
To: <[e-mail]>
Subject: RE: OCSP - Adoption of response models
Date: Sun, 6 Apr 2003 19:41:29 +0100
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)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Chris

In our OCSP responder, we implement:
- model ii (most common in my opinion)
- model iii (i.e. where the VA is certified by a Root CA or some other CA)
- model iv (where the VA's keys are directly trusted by end-users, but is
not the CA)

I have seen model (i) implemented by some CA vendors, typically for
infrastructure certificates (rather than end-user certificates).  Although I
have not really seen "live" examples.

Our OCSP clients (e.g. ARP) support all four models, following an approach
similar to that described in Miguel's earlier email.

Regards,
LK

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of
[e-mail]
Sent: 04 April 2003 10:47
To: [e-mail]
Subject: OCSP - Adoption of response models





RFC2560 offers three valid response models for OCSP (Two too many
in my opinion)

i.   Signed by the CA
ii.  Signed by a VA with explicit delegation by the CA
iii. A local model

Does anyone have a feel for which model boasts the most widespread
adoption ? I feel it should be ii) but suspect its iii) Deployment of the
technology appears to be too scarce at present to make a sensible
judgement.

Opinions appreciated

Chris


This  email  and  any  attachments  are confidential and intended for the
addressee
only.   If  you are not the named recipient, you must not use, disclose,
reproduce,
copy  or  distribute the contents of this communication.  If you have
received this
in error, please contact the sender and then delete this email from your
system.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h35HDIJM025341 for <[e-mail]>; Sat, 5 Apr 2003 09:13:18 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h35HDHcl025340 for ietf-pkix-bks; Sat, 5 Apr 2003 09:13:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h35HDFJM025317 for <[e-mail]>; Sat, 5 Apr 2003 09:13:15 -0800 (PST)
Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6659); Sat, 5 Apr 2003 09:13:02 -0800
Received: from 157.54.8.109 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 05 Apr 2003 09:13:10 -0800
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Sat, 5 Apr 2003 09:13:07 -0800
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sat, 5 Apr 2003 09:13:08 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Sat, 5 Apr 2003 09:13:09 -0800
Subject: RE: OCSP - Adoption of response models
MIME-Version: 1.0
From: "Ryan M. Hurst" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>, <[e-mail]>
To: Ambarish Malpani <[e-mail]>, Florian Oelmaier <[e-mail]>, <[e-mail]>, <[e-mail]>
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Date: Sat, 5 Apr 2003 09:12:54 -0800
Thread-Topic: RE: OCSP - Adoption of response models
Thread-Index: AcL7lphqz/IN4lBcSteHTJaktB52rA==
Message-ID: <000e01c2fb96$98a3a510$8800a8c0@OFFICE>
X-Mailer: Microsoft Outlook Web Access 6.5.6851.6
X-MimeCtl: Produced By Microsoft Exchange V6.5.6851.6
X-OriginalArrivalTime: 05 Apr 2003 17:13:09.0648 (UTC) FILETIME=[A1B56100:01C2FB96]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="_4FF2D657-7A26-411C-9CBF-9456A2F25E7A_"

--_4FF2D657-7A26-411C-9CBF-9456A2F25E7A_
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I agree that what is being referred to as local trust  is valid within the =
RFC I think the crux of the matter is it implicit or explicit trust; e.g. t=
he issuer is implicitly capable of issuing responses for the certificates i=
t has issued, a VA is explicitly trusted to issue for a set of CAs (I suppo=
se its reasonable for the set to be defined by a certificate chain).

I have seen implementations that have implicitly given the root of trust fo=
r the chain the authority to issue responses for the entire chain, I have a=
lways viewed this as a derivation since it extends the domain of control of=
 the root to the certificates that its subordinates have issued (and their =
subordinates).=20

Just consider cross-certification: company x's certificate was issued by tt=
p a, company x cross-certifies company b as such ttp a can revoke company b=
's certificates using OCSP.

The same problem set is introduced when the va delegated model is extended =
beyond one level.

I do think this is a legitimate problem for widespread OCSP deployment, but=
 not the only one; most of the issues that come to mind are not standard re=
lated but implementation based:
Responder Trust
Responses should be as small as possible, certificates are big and need to =
be communicated numerous times, There should be a mechanism to tell the res=
ponder not to send certificates if it knows them, or a way for a responder =
to tell the client where to get them (ala AIA) instead of sending them each=
 time.
In large PKIs vendors often use a single responder (cluster) to issue respo=
nses, why should they have to maintain separate certificates for all of the=
m; it should be possible to define some implicit trust for the trust anchor=
 to refer to where to get information about all of its certificates, and it=
s issuers certificates. This is especially helpful since many issuers have =
revocation information available via OCSP but not all of the certificates h=
ave a AIA /w OCSP specified.
Most implementations only support a limited subset of the usefull trust mod=
els and there is no clear way to determin other than testing them.
Responder Identification
The RFC defines both a HTTP GET and POST method, but the AIA does not commu=
nicate which way the responder expects to be communicated with; This is par=
ticularly important since in practice it is possible to cache GETs and not =
POSTS.
Response Caching
Without caching it is not possible to deploy OCSP in a volume necessary to =
support ssl server certificate revocation checking for the internet.
For OCSP to scale there needs to be support for caching, most http proxies =
do not support post caching, most OCSP implementations do not support GET r=
etrievals.
Most OCSP implementations do not set the http cache expiration headers so i=
f OCSP responses were to be cached they would likely be cached indefinably =
causing failed validations.
Responder Load
Just like with CRLs responder load usually happens at a fixed time (nextUpd=
ate) so issuers need to scope deployment so accommodate peeks vs. having lo=
ad distributed. Servers should "shift" the nextUpdate to control this, and =
clients should intelligently pre-fetch information to help distribute the l=
oad.
OCSP allows for a single request to consist of many unrelated certIds, this=
 is great for chain validation however most responders do not support this =
(or at least do it correctly).
OCSP allows for response pre-production this is important for a internet sc=
ale solution however most responders do not support this.
Responder Freshness
OCSP does not provide a mechanism for the client to request a real-time res=
ponse, this makes deploying a system that serves cached responses most of t=
he time and dynamic ones on demand not really viable.
Its important to know that when something was signed the certificate associ=
ated with that signature was not revoked, it is not normally to check the v=
alidity at the time of verification; that is if the data is time stamped an=
d the signer included its own OCSP response. PKCS7/CMS allows for CRLs to b=
e included for this reason however there is no way to include OCSP response=
s, Denis has done a informational RFC for historical signatures that has th=
is concept in it but if all you want is a standard place to put OCSP in a P=
KCS7/CMS you are out of luck.
These are all solveable problems, they are just things that I think most im=
plementations do not take these things into concern today.
Ryan M. Hurst
Program Manager
Windows Security
Microsoft Corporation





From: Ambarish Malpani
Sent: Fri 4/4/2003 10:35 PM
To: Florian Oelmaier; [e-mail]; [e-mail]
Subject: RE: OCSP - Adoption of response models


Hi Florian,
    The model you have seen is compliant with the RFC. It is
basically an example of model (iii), where you explicitly
trust the root CA to validate all the certificates and allow
it to delegate that responsibity to the VA that is actually
responding.

Chris, to respond to your original question, (ii) and (iii)
are the two models that I have seen used to most. (ii) is
what people do who have simple PKIs - normally a single
CA or at most a 3 level hierarchy.

(iii) is used in more complicated situations, or in places
where you want a single entity to respond for all the CAs in
your system.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani                                         650.759.9045
Malpani Consulting Services                      [e-mail]
http://www.malpani.biz



> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Florian Oelmaier
> Sent: Friday, April 04, 2003 3:20 AM
> To: [e-mail]; [e-mail]
> Subject: Re: OCSP - Adoption of response models
>=20
>=20
>=20
> > RFC2560 offers three valid response models for OCSP (Two too many
> > in my opinion)
> >=20
> > i.   Signed by the CA
> > ii.  Signed by a VA with explicit delegation by the CA
> > iii. A local model
>=20
> I have seen 2 installations using a fourth model:
>=20
> ii-a. Signed by a VA with explicit delegation by any CA in the chain.
>=20
> Thus it is possible to use one OCSP-Responder signed by the Root-CA to=20
> answer for all Sub-CAs. Interesting idea. But afaik not RfC-conform.
>=20
> > Does anyone have a feel for which model boasts the most widespread
> > adoption ? I feel it should be ii) but suspect its iii)=20
> Deployment of the
> > technology appears to be too scarce at present to make a sensible
> > judgement.
>=20
> A big use-case of the trust model iii) is www.openvalidation.org. The=20
> OCSP-Responder there answers for 120 CAs with a certificate you have to=20
> trust locally.
>=20
> A lot of large companies seem to like this idea, too. This way they can=20
> manage the trust a little bit (actually partly doing with OCSP what SCVP=
=20
> tries to establish now).
>=20
> --
> Florian Oelmaier
> SyTrust S.A.
>=20

--_4FF2D657-7A26-411C-9CBF-9456A2F25E7A_
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD>
<BODY>
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>I agree that wha=
t is being referred to as local trust&nbsp; is valid within the RFC I think=
 the crux of the matter is it implicit or explicit trust; e.g. the issuer i=
s implicitly capable of issuing responses for the certificates it has issue=
d, a VA is explicitly trusted to issue for a set of CAs (I suppose its reas=
onable for the set to be defined by a certificate chain).</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>I have seen implementations that=
 have implicitly given the root of trust for the chain the authority to iss=
ue responses for the entire chain, I have always viewed this as a derivatio=
n since it extends the domain of control of the root to the certificates th=
at its subordinates have issued (and their subordinates). </FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Just consider cross-certificatio=
n: company x's certificate was issued by ttp a, company x cross-certifies c=
ompany b as such ttp a can revoke company b's certificates using OCSP.</FON=
T></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>The same problem set is introduc=
ed when the va delegated model is extended beyond one level.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>I do think this is a legitimate =
problem for widespread OCSP deployment, but not the only one; most of the i=
ssues that come to mind are not standard related but implementation based:<=
/FONT></DIV>
<OL dir=3Dltr>
<LI>
<DIV><FONT face=3DArial size=3D2><STRONG>Responder Trust</STRONG></FONT></D=
IV>
<UL>
<LI>
<DIV><FONT face=3DArial size=3D2>Responses should be as small as possible, =
certificates are big and need to be communicated numerous times, There shou=
ld be a mechanism to tell the responder not to send certificates if it know=
s them, or a way for a responder to tell the client where to get them (ala =
AIA) instead of sending them each time.</FONT></DIV>
<LI>
<DIV><FONT face=3DArial size=3D2>In large PKIs vendors often use a single r=
esponder (cluster) to issue responses, why should they have to maintain sep=
arate certificates for all of them; it should be possible to define some im=
plicit trust for the trust anchor to refer to where to get information abou=
t all of its certificates, and its issuers certificates. This is especially=
 helpful since many issuers have revocation information available via OCSP =
but not all of the certificates have a AIA /w OCSP specified.</FONT></DIV>
<LI>
<DIV><FONT face=3DArial size=3D2>Most implementations only support a limite=
d subset of the usefull trust models and there is no clear way to determin =
other than testing them.</FONT></DIV></LI></UL>
<LI>
<DIV><FONT face=3DArial size=3D2><STRONG>Responder Identification</STRONG><=
/FONT></DIV>
<UL>
<LI>
<DIV><FONT face=3DArial size=3D2>The RFC defines both a HTTP GET and POST m=
ethod, but the AIA does not communicate which way the responder expects to =
be communicated with; This is particularly important since in practice it i=
s possible to cache GETs&nbsp;and not POSTS.</FONT></DIV></LI></UL>
<LI>
<DIV><FONT face=3DArial size=3D2><STRONG>Response Caching</STRONG></FONT></=
DIV>
<UL>
<LI>
<DIV><FONT face=3DArial size=3D2>Without caching it is not possible to depl=
oy OCSP in a volume necessary to support ssl server certificate revocation =
checking for the internet.</FONT></DIV>
<LI>
<DIV><FONT face=3DArial size=3D2>For OCSP to scale there needs to be suppor=
t for caching, most http proxies do not support post caching, most OCSP imp=
lementations do not support GET retrievals.</FONT></DIV>
<LI>
<DIV><FONT face=3DArial size=3D2>Most OCSP implementations do not set the h=
ttp cache expiration headers so if OCSP responses were to be cached they wo=
uld likely be cached indefinably causing failed validations.</FONT></DIV></=
LI></UL>
<LI>
<DIV><FONT face=3DArial size=3D2><STRONG>Responder Load</STRONG></FONT></DI=
V>
<UL>
<LI>
<DIV><FONT face=3DArial size=3D2>Just like with CRLs responder load usually=
 happens at a fixed time (nextUpdate) so issuers need to scope deployment s=
o accommodate peeks vs. having load distributed. Servers should "shift" the=
 nextUpdate to control this, and clients should intelligently pre-fetch inf=
ormation to help distribute the load.</FONT></DIV>
<LI>
<DIV><FONT face=3DArial size=3D2>OCSP allows for a single request to consis=
t of many unrelated certIds, this is great for chain validation however mos=
t responders do not support this (or at least do it correctly).</FONT></DIV=
>
<LI>
<DIV><FONT face=3DArial size=3D2>OCSP allows for response pre-production th=
is is important for a internet scale solution however most responders do no=
t support this.</FONT></DIV></LI></UL>
<LI>
<DIV><STRONG><FONT face=3DArial size=3D2>Responder Freshness</FONT></STRONG=
></DIV>
<UL>
<LI>
<DIV><FONT face=3DArial size=3D2>OCSP does not provide a mechanism for the =
client to request a&nbsp;real-time response, this makes deploying a system =
that serves cached responses most of the time and dynamic ones on demand no=
t really viable.</FONT></DIV>
<LI>
<DIV><FONT face=3DArial size=3D2>Its important to know that when something =
was signed the certificate associated with that signature was not revoked, =
it is not normally to check the validity at the time of verification; that =
is if the data is time stamped and the signer included its own OCSP respons=
e. PKCS7/CMS allows for CRLs to be included for this reason however there i=
s no way to include OCSP responses, Denis has done a informational RFC for =
historical signatures that has this concept in it but if all you want is a =
standard place to put OCSP in a PKCS7/CMS you are out of luck.</FONT></DIV>=
</LI></UL></LI></OL>
<P><FONT face=3DArial size=3D2>These are all solveable problems, they are j=
ust things that I think most implementations do not take these things into =
concern today.</FONT></P>
<P><FONT face=3DArial size=3D2>Ryan M. Hurst<BR>Program Manager<BR>Windows =
Security<BR>Microsoft Corporation</FONT></P>
<P><FONT face=3DArial size=3D2></FONT>&nbsp;</P>
<P><FONT face=3DArial size=3D2></FONT>&nbsp;</P>
<DIV dir=3Dltr>
<HR tabIndex=3D-1>
</DIV>
<DIV dir=3Dltr><FONT face=3DTahoma size=3D2><B>From:</B> Ambarish Malpani<B=
R><B>Sent:</B> Fri 4/4/2003 10:35 PM<BR><B>To:</B> Florian Oelmaier; chris.=
[e-mail]; [e-mail]<BR><B>Subject:</B> RE: OCSP - Adop=
tion of response models<BR></FONT><BR></DIV>
<DIV><PRE style=3D"WORD-WRAP: break-word">Hi Florian,
    The model you have seen is compliant with the RFC. It is
basically an example of model (iii), where you explicitly
trust the root CA to validate all the certificates and allow
it to delegate that responsibity to the VA that is actually
responding.

Chris, to respond to your original question, (ii) and (iii)
are the two models that I have seen used to most. (ii) is
what people do who have simple PKIs - normally a single
CA or at most a 3 level hierarchy.

(iii) is used in more complicated situations, or in places
where you want a single entity to respond for all the CAs in
your system.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani                                         650.759.9045
Malpani Consulting Services                      [e-mail]
http://www.malpani.biz



&gt; -----Original Message-----
&gt; From: [e-mail]
&gt; [mailto:[e-mail]]On Behalf Of Florian Oelmaier
&gt; Sent: Friday, April 04, 2003 3:20 AM
&gt; To: [e-mail]; [e-mail]
&gt; Subject: Re: OCSP - Adoption of response models
&gt;=20
&gt;=20
&gt;=20
&gt; &gt; RFC2560 offers three valid response models for OCSP (Two too many
&gt; &gt; in my opinion)
&gt; &gt;=20
&gt; &gt; i.   Signed by the CA
&gt; &gt; ii.  Signed by a VA with explicit delegation by the CA
&gt; &gt; iii. A local model
&gt;=20
&gt; I have seen 2 installations using a fourth model:
&gt;=20
&gt; ii-a. Signed by a VA with explicit delegation by any CA in the chain.
&gt;=20
&gt; Thus it is possible to use one OCSP-Responder signed by the Root-CA to=
=20
&gt; answer for all Sub-CAs. Interesting idea. But afaik not RfC-conform.
&gt;=20
&gt; &gt; Does anyone have a feel for which model boasts the most widesprea=
d
&gt; &gt; adoption ? I feel it should be ii) but suspect its iii)=20
&gt; Deployment of the
&gt; &gt; technology appears to be too scarce at present to make a sensible
&gt; &gt; judgement.
&gt;=20
&gt; A big use-case of the trust model iii) is www.openvalidation.org. The=
=20
&gt; OCSP-Responder there answers for 120 CAs with a certificate you have t=
o=20
&gt; trust locally.
&gt;=20
&gt; A lot of large companies seem to like this idea, too. This way they ca=
n=20
&gt; manage the trust a little bit (actually partly doing with OCSP what SC=
VP=20
&gt; tries to establish now).
&gt;=20
&gt; --
&gt; Florian Oelmaier
&gt; SyTrust S.A.
&gt;=20
</PRE></DIV></BODY></HTML>

--_4FF2D657-7A26-411C-9CBF-9456A2F25E7A_--

--------------InterScan_NT_MIME_Boundary--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h356WfJM027569 for <[e-mail]>; Fri, 4 Apr 2003 22:32:41 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h356Wf0i027568 for ietf-pkix-bks; Fri, 4 Apr 2003 22:32:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h356WeJM027563 for <[e-mail]>; Fri, 4 Apr 2003 22:32:40 -0800 (PST)
Received: from nt1 (nt1.malpani.biz [192.168.25.13]) by ns.malpani.biz (8.12.5/8.12.5) with SMTP id h356WdQP009643; Fri, 4 Apr 2003 22:32:39 -0800
From: "Ambarish Malpani" <[e-mail]>
To: "Florian Oelmaier" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: OCSP - Adoption of response models
Date: Fri, 4 Apr 2003 22:35:47 -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 V6.00.2800.1106
Sender: [e-mail]
Precedence: 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 Florian,
    The model you have seen is compliant with the RFC. It is
basically an example of model (iii), where you explicitly
trust the root CA to validate all the certificates and allow
it to delegate that responsibity to the VA that is actually
responding.

Chris, to respond to your original question, (ii) and (iii)
are the two models that I have seen used to most. (ii) is
what people do who have simple PKIs - normally a single
CA or at most a 3 level hierarchy.

(iii) is used in more complicated situations, or in places
where you want a single entity to respond for all the CAs in
your system.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani                                         650.759.9045
Malpani Consulting Services                      [e-mail]
http://www.malpani.biz



> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Florian Oelmaier
> Sent: Friday, April 04, 2003 3:20 AM
> To: [e-mail]; [e-mail]
> Subject: Re: OCSP - Adoption of response models
> 
> 
> 
> > RFC2560 offers three valid response models for OCSP (Two too many
> > in my opinion)
> > 
> > i.   Signed by the CA
> > ii.  Signed by a VA with explicit delegation by the CA
> > iii. A local model
> 
> I have seen 2 installations using a fourth model:
> 
> ii-a. Signed by a VA with explicit delegation by any CA in the chain.
> 
> Thus it is possible to use one OCSP-Responder signed by the Root-CA to 
> answer for all Sub-CAs. Interesting idea. But afaik not RfC-conform.
> 
> > Does anyone have a feel for which model boasts the most widespread
> > adoption ? I feel it should be ii) but suspect its iii) 
> Deployment of the
> > technology appears to be too scarce at present to make a sensible
> > judgement.
> 
> A big use-case of the trust model iii) is www.openvalidation.org. The 
> OCSP-Responder there answers for 120 CAs with a certificate you have to 
> trust locally.
> 
> A lot of large companies seem to like this idea, too. This way they can 
> manage the trust a little bit (actually partly doing with OCSP what SCVP 
> tries to establish now).
> 
> --
> Florian Oelmaier
> SyTrust S.A.
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34GnAJM020310 for <[e-mail]>; Fri, 4 Apr 2003 08:49:10 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h34Gn9jM020309 for ietf-pkix-bks; Fri, 4 Apr 2003 08:49:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34Gn5JM020297 for <[e-mail]>; Fri, 4 Apr 2003 08:49:05 -0800 (PST)
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Fri, 4 Apr 2003 08:49:02 -0800
Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 04 Apr 2003 08:49:01 -0800
Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3789.0); Fri, 4 Apr 2003 08:48:52 -0800
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 4 Apr 2003 08:49:01 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Fri, 4 Apr 2003 08:49:02 -0800
Subject: RE: OCSP - Adoption of response models
Mime-Version: 1.0
From: "Ryan M. Hurst" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
To: <[e-mail]>, Florian Oelmaier <[e-mail]>
Cc: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Date: Fri, 4 Apr 2003 08:48:47 -0800
Thread-Topic: RE: OCSP - Adoption of response models
Thread-Index: AcL6yg+zgpwRNuy9S7Kg7fq3ayD3rA==
Message-ID: <000d01c2faca$0fcbc7d0$8800a8c0@OFFICE>
X-Mailer: Microsoft Outlook Web Access 6.5.6851.6
X-MimeCtl: Produced By Microsoft Exchange V6.5.6851.6
X-OriginalArrivalTime: 04 Apr 2003 16:49:02.0006 (UTC) FILETIME=[186EFD60:01C2FACA]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="_DA2726D3-89EC-44AE-A495-F10D9E727E72_"

--_DA2726D3-89EC-44AE-A495-F10D9E727E72_
Content-type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

This model does solve a real problem especially in complex PKIs, on the sam=
e note it does concern me though; today  a issuer has no direct control (ot=
her than policy) over the certificates his subordinate issues this model ch=
anges that and I am not sure how I feel about that.

In general I have always described the OCSP trust models as follows:
direct - I directly trust a ocsp responder to respond for a particular ca (=
or set)
va delegated - I directly trust a ocsp responder/ca to issue certificates t=
o other responders I will trust through delegation. This delegation is rest=
ricted to one level (e.g. only the root is a ca)
ca delegated - ca assigns the ability to sign responses for his certificate=
s by issuing a OCSP Signing certificate to a responder. In this case if the=
 responder was to respond for more than one CA he has a certificate from ea=
ch ca, but each certificate uses the same key. The response uses the key ba=
sed responder id vs a name based one; not all client implementations suppor=
t this form of responder identification.=20
ca signed - ca who issued the certificate issued the response, no eku neede=
d but it should be present.




From: [e-mail]
Sent: Fri 4/4/2003 6:26 AM
To: Florian Oelmaier
Cc: [e-mail]
Subject: Re: OCSP - Adoption of response models





> Thus it is possible to use one OCSP-Responder signed by the Root-CA to
> answer for all Sub-CAs. Interesting idea. But afaik not RfC-conform.

I have referred to this one in the past as the 'Family model'
wherein if its OK with the head of the family (the Root CA)
then its OK with the rest of the family. To me it seems a
logical extension of the Root of trust principle on which
much of PKI is based.

Of course, within the RFC it *is* compliant within what Peter has
described 'Everything else' bucket.

Chris

--_DA2726D3-89EC-44AE-A495-F10D9E727E72_
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD>
<BODY>
<DIV id=3DidOWAReplyText21708 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>This model does =
solve a real problem especially in complex PKIs,&nbsp;on the same note&nbsp=
;it&nbsp;does concern me though; today&nbsp; a issuer has no direct control=
 (other than policy) over the certificates his subordinate issues this mode=
l changes that and I am not sure how I feel about that.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>In general I&nbsp;have always de=
scribed the&nbsp;OCSP trust models as follows:</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2><STRONG>direct</STRONG> - I dire=
ctly trust a ocsp responder to respond for a particular ca (or set)</FONT><=
/DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2><STRONG>va delegated -</STRONG> =
I directly trust a ocsp responder/ca to issue certificates to other respond=
ers I will trust through delegation. This delegation is restricted to one l=
evel (e.g. only the root is a ca)</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2><STRONG>ca delegated</STRONG> - =
ca assigns the ability to sign responses for his certificates by issuing a =
OCSP Signing certificate to a responder. In this case if the responder was =
to respond for more than one CA he has a certificate from each ca, but each=
 certificate uses the same key. The response uses the key based responder i=
d vs a name based one; not all client implementations support this form of =
responder identification. </FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2><STRONG>ca signed</STRONG> - ca =
who issued the certificate issued the response, no eku needed but it should=
 be present.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2><STRONG></STRONG></FONT>&nbsp;</=
DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></DIV>
<DIV dir=3Dltr>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [e-mail]<BR><B=
>Sent:</B> Fri 4/4/2003 6:26 AM<BR><B>To:</B> Florian Oelmaier<BR><B>Cc:</B=
> [e-mail]<BR><B>Subject:</B> Re: OCSP - Adoption of response mode=
ls<BR></FONT><BR></DIV>
<DIV><PRE style=3D"WORD-WRAP: break-word">


&gt; Thus it is possible to use one OCSP-Responder signed by the Root-CA to
&gt; answer for all Sub-CAs. Interesting idea. But afaik not RfC-conform.

I have referred to this one in the past as the 'Family model'
wherein if its OK with the head of the family (the Root CA)
then its OK with the rest of the family. To me it seems a
logical extension of the Root of trust principle on which
much of PKI is based.

Of course, within the RFC it *is* compliant within what Peter has
described 'Everything else' bucket.

Chris



</PRE></DIV></BODY></HTML>

--_DA2726D3-89EC-44AE-A495-F10D9E727E72_--

--------------InterScan_NT_MIME_Boundary--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34GODJM018818 for <[e-mail]>; Fri, 4 Apr 2003 08:24:13 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h34GOD6t018817 for ietf-pkix-bks; Fri, 4 Apr 2003 08:24:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from seguridata1.seguridata.com ([200.57.34.107]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34GOBJM018811 for <[e-mail]>; Fri, 4 Apr 2003 08:24:12 -0800 (PST)
Received: from MarsXP ([148.233.248.105]) by seguridata1.seguridata.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 4 Apr 2003 10:25:43 -0600
From: "Miguel Rodriguez" <[e-mail]>
To: <[e-mail]>
Subject: RE: OCSP - Adoption of response models
Date: Fri, 4 Apr 2003 10:23:45 -0600
Message-ID: <000201c2fac6$93d7d7a0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <[e-mail]>
X-OriginalArrivalTime: 04 Apr 2003 16:25:43.0562 (UTC) FILETIME=[D6E55EA0:01C2FAC6]
Sender: [e-mail]
Precedence: 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 few products (OCSP Clients) support all three models as follows:

i. Check the responder certificate is a CA certificate and to be the
issuer of the target certificate

ii. Check that the response responder certificate was issued by the CA
who issued the target certificate and that it has the ocsp signing key
usage

iii. Check that the responder certificate is specified as trusted
(locally). The client may have  a list of trusted responder certificates

Model (iii) also can arise when checking revocation for the OCSP
responder certificate. For this you have also 3 models:

1. the responder certificate is trusted for its lifetime (ocsp no-check
extension)
2. a CRL must be checked
3. the responder certificate is trusted according to some local policy
(which may include having a list of trusted responder certificates).

Finally, I agree with you that ii) should be the most common. 

Regards,

Miguel A Rodriguez
SeguriDATA
Mexico

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of [e-mail]
> Sent: Viernes, 04 de Abril de 2003 03:47 a.m.
> To: [e-mail]
> Subject: OCSP - Adoption of response models
> 
> 
> 
> 
> RFC2560 offers three valid response models for OCSP (Two too many
> in my opinion)
> 
> i.   Signed by the CA
> ii.  Signed by a VA with explicit delegation by the CA
> iii. A local model
> 
> Does anyone have a feel for which model boasts the most widespread
> adoption ? I feel it should be ii) but suspect its iii) Deployment of
the
> technology appears to be too scarce at present to make a sensible
> judgement.
> 
> Opinions appreciated
> 
> Chris
> 





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34FCHJM011563 for <[e-mail]>; Fri, 4 Apr 2003 07:12:17 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h34FCHm5011562 for ietf-pkix-bks; Fri, 4 Apr 2003 07:12:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34FCFJM011555 for <[e-mail]>; Fri, 4 Apr 2003 07:12:16 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA11083; Fri, 4 Apr 2003 17:12:15 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.6); Fri, 4 Apr 2003 17:12:15 +0200 (MET DST)
Received: (from sylvest@localhost) by champagne.edelweb.fr (8.7.6/8.6.6) id RAA04341; Fri, 4 Apr 2003 17:12:13 +0200 (MET DST)
Date: Fri, 4 Apr 2003 17:12:13 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: RFC3161(TSP): doubts about tcp protocol
Sender: [e-mail]
Precedence: 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 small reminder. 

----- Begin Included Message -----

Date: Mon, 3 Mar 2003 18:14:46 +0100 (MET)
From: Peter Sylvester <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: RFC3161(TSP): doubts about tcp protocol



Hi,

after more than 2 weeks of no response, it would be nice from the editor
of 3161bis to indicate a procedure to get whatever kind of answer to this
question as a possible clarification into the 3161bis document.

Peter

> From: "Pere Fiol" <[e-mail]>
> To: "ietf" <[e-mail]>
> Subject: RFC3161(TSP): doubts about tcp protocol 
> Date: Thu, 13 Feb 2003 17:47:55 +0100
> 
> Hi,
> 
> I've developed a TSA but I have a doubt in TCP protocol: if a client
> sends a request to TSA with invalid TCP message (for example with a flag
> different of '00'H, with wrong number of bytes in length,...) What must
> do a TSA in this situations?? RFC3161 mustn't talk something about it??
> 
> Thanks and Best Regards,
> Pere Fiol


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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34DQjJM002660 for <[e-mail]>; Fri, 4 Apr 2003 05:26:45 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h34DQj0U002659 for ietf-pkix-bks; Fri, 4 Apr 2003 05:26:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mail4.consignia.com (mail.royalmail.com [144.87.143.84]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34DQiJM002654 for <[e-mail]>; Fri, 4 Apr 2003 05:26:44 -0800 (PST)
Received: from postoffice.co.uk (mta2.int.consignia.com [144.87.146.16]) by mail4.consignia.com (Postfix) with SMTP id 1199F122622; Fri,  4 Apr 2003 14:26:45 +0100 (BST)
Received: by postoffice.co.uk(Lotus SMTP MTA v4.6.6  (890.1 7-16-1999))  id 00256CFE.004F5C9E ; Fri, 4 Apr 2003 14:26:50 +0000
X-Lotus-FromDomain: POSTOFFICE
From: [e-mail]
To: Florian Oelmaier <[e-mail]>
Cc: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 4 Apr 2003 14:26:27 +0000
Subject: Re: OCSP - Adoption of response models
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Thus it is possible to use one OCSP-Responder signed by the Root-CA to
> answer for all Sub-CAs. Interesting idea. But afaik not RfC-conform.

I have referred to this one in the past as the 'Family model'
wherein if its OK with the head of the family (the Root CA)
then its OK with the rest of the family. To me it seems a
logical extension of the Root of trust principle on which
much of PKI is based.

Of course, within the RFC it *is* compliant within what Peter has
described 'Everything else' bucket.

Chris





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34BMqJM021167 for <[e-mail]>; Fri, 4 Apr 2003 03:22:52 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h34BMqLQ021166 for ietf-pkix-bks; Fri, 4 Apr 2003 03:22:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mail3.consignia.com (mail.royalmail.com [144.87.143.83]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34BMpJM021160 for <[e-mail]>; Fri, 4 Apr 2003 03:22:51 -0800 (PST)
Received: from postoffice.co.uk (unknown [144.87.146.16]) by mail3.consignia.com (Postfix) with SMTP id CAEA118F85B; Fri,  4 Apr 2003 12:22:50 +0100 (BST)
Received: by postoffice.co.uk(Lotus SMTP MTA v4.6.6  (890.1 7-16-1999))  id 00256CFE.00440802 ; Fri, 4 Apr 2003 12:23:04 +0000
X-Lotus-FromDomain: POSTOFFICE
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 4 Apr 2003 12:22:42 +0000
Subject: Re: OCSP - Adoption of response models
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello David

> I should also think that it is the response model II). But who
> thrust/signs the certificate of the VA.

The response from the VA should be signed using keys issued by
the CA in the Issuer field of the certificate being queried
(and thus the issuer of the CRL that might contain that
certificate's serial number). The certificate sent with the
response must have OCSP-signing in the Extended Key Usage field.

Chris




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34BLCJM021002 for <[e-mail]>; Fri, 4 Apr 2003 03:21:12 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h34BLCB1021001 for ietf-pkix-bks; Fri, 4 Apr 2003 03:21:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from druss.secaron.de (druss.secaron.de [195.145.99.123]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34BLAJM020986 for <[e-mail]>; Fri, 4 Apr 2003 03:21:11 -0800 (PST)
Received: by druss.secaron.de (Postfix, from userid 104) id 44C1E51F0C; Fri,  4 Apr 2003 13:21:02 +0200 (MET DST)
Received: from druss.secaron.de (localhost [127.0.0.1]) by druss-vscan.secaron.de (Postfix) with ESMTP id DC9B151F0E; Fri,  4 Apr 2003 13:20:55 +0200 (MET DST)
Received: from marvin.munich.secaron.de (marvin.munich.secaron.de [192.168.1.20]) by druss.secaron.de (Postfix) with ESMTP id 80B1851F0C; Fri,  4 Apr 2003 13:20:55 +0200 (MET DST)
Received: from sytrust.com ([192.168.2.3]) by marvin.munich.secaron.de (Lotus Domino Release 6.0.1) with ESMTP id 2003040413205448-604 ; Fri, 4 Apr 2003 13:20:54 +0200 
Message-ID: <[e-mail]>
Date: Fri, 04 Apr 2003 13:19:46 +0200
From: Florian Oelmaier <[e-mail]>
Organization: SyTrust GmbH
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.3b) Gecko/20030210
X-Accept-Language: de-de, en-us, en
MIME-Version: 1.0
To: [e-mail], [e-mail]
Subject: Re: OCSP - Adoption of response models
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on Marvin/Secaron(Release 6.0.1|February 07, 2003) at 04/04/2003 13:20:54, Serialize by Router on Marvin/Secaron(Release 6.0.1|February 07, 2003) at 04/04/2003 13:20:54, Serialize complete at 04/04/2003 13:20:54
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
X-Spam-Status: No, hits=-101.4 required=7.5 tests=AWL,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, USER_IN_WHITELIST,X_ACCEPT_LANG version=2.43
X-Spam-Level: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> RFC2560 offers three valid response models for OCSP (Two too many
> in my opinion)
> 
> i.   Signed by the CA
> ii.  Signed by a VA with explicit delegation by the CA
> iii. A local model

I have seen 2 installations using a fourth model:

ii-a. Signed by a VA with explicit delegation by any CA in the chain.

Thus it is possible to use one OCSP-Responder signed by the Root-CA to 
answer for all Sub-CAs. Interesting idea. But afaik not RfC-conform.

> Does anyone have a feel for which model boasts the most widespread
> adoption ? I feel it should be ii) but suspect its iii) Deployment of the
> technology appears to be too scarce at present to make a sensible
> judgement.

A big use-case of the trust model iii) is www.openvalidation.org. The 
OCSP-Responder there answers for 120 CAs with a certificate you have to 
trust locally.

A lot of large companies seem to like this idea, too. This way they can 
manage the trust a little bit (actually partly doing with OCSP what SCVP 
tries to establish now).

--
Florian Oelmaier
SyTrust S.A.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34AwMJM016608 for <[e-mail]>; Fri, 4 Apr 2003 02:58:22 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h34AwLau016607 for ietf-pkix-bks; Fri, 4 Apr 2003 02:58:21 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from utimaco.be (mail.utimaco.be [193.121.107.230]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34AwJJM016599 for <[e-mail]>; Fri, 4 Apr 2003 02:58:20 -0800 (PST)
Received: (from smtp@localhost) by utimaco.be (8.11.1/8.11.1) id h34AxYd07297; Fri, 4 Apr 2003 10:59:34 GMT (envelope-from [e-mail])
X-Authentication-Warning: Internet-Router.utimaco.be: smtp set sender to <[e-mail]> using -f
Received: from belgien1(10.7.0.25), claiming to be "belgien1.utimaco.be" via SMTP by Internet-Router, id smtpdXv7294; Fri Apr  4 10:59:27 2003
Subject: Re: OCSP - Adoption of response models
To: [e-mail]
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 4 Apr 2003 12:51:01 +0200
X-MIMETrack: Serialize by Router on Belgien1/Utimaco/BE(Release 5.0.7 |March 21, 2001) at 04/04/2003 12:51:03 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>

Hi Chris,

     I should also think that it is the response model II). But who
thrust/signs the certificate of the VA.

Friendly greetings,
Utimaco Safeware - Digital Transaction Security

David Tillemans
Project Leader

Tel.     [phone]
Fax.     [phone]
mailto:[e-mail]
Internet   http://www.utimaco.be
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

This email is confidential and intended solely for the use of the
individual to whom it is addressed. If you are not the intended recipient,
be advised that you have received this email in error and that any use,
dissemination, forwarding, printing or copying of this email is strictly
prohibited. If you have received this email in error please notify the
sender by telephone on [phone]
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------




                                                                                                                       
                    chris.gilbert@roya                                                                                 
                    lmail.com                To:     [e-mail]                                                 
                    Sent by:                 cc:                                                                       
                    owner-ietf-pkix@ma       Subject:     OCSP - Adoption of response models                           
                    il.imc.org                                                                                         
                                                                                                                       
                                                                                                                       
                    04/04/2003 11:46                                                                                   
                                                                                                                       
                                                                                                                       







RFC2560 offers three valid response models for OCSP (Two too many
in my opinion)

i.   Signed by the CA
ii.  Signed by a VA with explicit delegation by the CA
iii. A local model

Does anyone have a feel for which model boasts the most widespread
adoption ? I feel it should be ii) but suspect its iii) Deployment of the
technology appears to be too scarce at present to make a sensible
judgement.

Opinions appreciated

Chris


This  email  and  any  attachments  are confidential and intended for the
addressee
only.   If  you are not the named recipient, you must not use, disclose,
reproduce,
copy  or  distribute the contents of this communication.  If you have
received this
in error, please contact the sender and then delete this email from your
system.







Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h349UcJM007983 for <[e-mail]>; Fri, 4 Apr 2003 01:30:38 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h349UcEm007982 for ietf-pkix-bks; Fri, 4 Apr 2003 01:30:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h349UaJM007955 for <[e-mail]>; Fri, 4 Apr 2003 01:30:36 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h349UUoU002964; Fri, 4 Apr 2003 21:30:30 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h349UUE13450; Fri, 4 Apr 2003 21:30:30 +1200
Date: Fri, 4 Apr 2003 21:30:30 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: OCSP - Adoption of response models
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] writes:

>RFC2560 offers three valid response models for OCSP (Two too many in my
>opinion)
>
>i.   Signed by the CA
>ii.  Signed by a VA with explicit delegation by the CA
>iii. A local model

Actually it offers an infinite number of models: (i), (ii), and (everything
else).  (And even within the above, there are a pile of sub-variations that
you can enable with OIDs and adding extra bits and pieces to messages).  Which
variant is best depends on which of the RFC authors you ask, and to some
extent who they're employed with at the time they offer their opinion.

>Does anyone have a feel for which model boasts the most widespread adoption ?
>I feel it should be ii) but suspect its iii) Deployment of the technology
>appears to be too scarce at present to make a sensible judgement.

Definitely (iii).  Note that a significant subset of (iii) is:

(iii-a) We don't check the signature on the response, we're only doing this to
        comply with some regulatory requirement.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h348lAJM003291 for <[e-mail]>; Fri, 4 Apr 2003 00:47:10 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h348lAsD003290 for ietf-pkix-bks; Fri, 4 Apr 2003 00:47:10 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mail4.consignia.com (mail4.consignia.com [144.87.143.84]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h348l8JM003279 for <[e-mail]>; Fri, 4 Apr 2003 00:47:09 -0800 (PST)
Received: from postoffice.co.uk (mta2.int.consignia.com [144.87.146.16]) by mail4.consignia.com (Postfix) with SMTP id EFE561226B3 for <[e-mail]>; Fri,  4 Apr 2003 09:47:07 +0100 (BST)
Received: by postoffice.co.uk(Lotus SMTP MTA v4.6.6  (890.1 7-16-1999))  id 00256CFE.0035C599 ; Fri, 4 Apr 2003 09:47:19 +0000
X-Lotus-FromDomain: POSTOFFICE
From: [e-mail]
To: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 4 Apr 2003 09:46:57 +0000
Subject: OCSP - Adoption of response models
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

RFC2560 offers three valid response models for OCSP (Two too many
in my opinion)

i.   Signed by the CA
ii.  Signed by a VA with explicit delegation by the CA
iii. A local model

Does anyone have a feel for which model boasts the most widespread
adoption ? I feel it should be ii) but suspect its iii) Deployment of the
technology appears to be too scarce at present to make a sensible
judgement.

Opinions appreciated

Chris


This  email  and  any  attachments  are confidential and intended for the addressee
only.   If  you are not the named recipient, you must not use, disclose, reproduce,
copy  or  distribute the contents of this communication.  If you have received this
in error, please contact the sender and then delete this email from your system.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33K8lJM007969 for <[e-mail]>; Thu, 3 Apr 2003 12:08:47 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h33K8lKF007968 for ietf-pkix-bks; Thu, 3 Apr 2003 12:08:47 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33K8kJM007964 for <[e-mail]>; Thu, 3 Apr 2003 12:08:46 -0800 (PST)
Received: from chokhani (159.washington-14rh16rt.dc.dial-access.att.net[12.91.131.159]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <2003040320083611100hdu5be>; Thu, 3 Apr 2003 20:08:36 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Peter Sylvester'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: TAP out of PKIX
Date: Thu, 3 Apr 2003 15:08:57 -0500
Message-ID: <004f01c2fa1c$dc781240$ad00a8c0@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h33K8kJM007965
Sender: [e-mail]
Precedence: 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:

Thanks.

All:

I whole-heartedly agree with Peter.

I am baffled by some of the Denny's sweeping statements.

Not being a lawyer, I do not intend to debate what non-repudiation means.
Little I know of cryptography, what we have done can form the basis for
providing evidence well in to future to support the existence of a signed
document well in the past. 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Peter Sylvester
Sent: Thursday, April 03, 2003 1:03 PM
To: [e-mail]; [e-mail]
Subject: Re: TAP out of PKIX




Denis, 

> 
> The technical quality of this draft document is very questionable.

Do you understand the meaning of the word 'draft'? 
Could it be that you suffer from psychological projection? 

For some it maybe surprising that you start with a comment about the content
of the document. Knowing a little bit of the 'French way of talking', one
can still interprete this as "Well, let's talk". Good. 

> 
> Like another draft document (i.e. SCVP) there is an abuse of OIDs in 
> particular for archiveControls and even for the inclusion of a nonce 
> using id-tap-nonce !!!
Peanuts.  

> 
> I wonder when the next draft posted to this WG will simply contain:
> 
>         queryControlType   OBJECT IDENTIFIER
>         queryControlValue  ANY DEFINED BY queryControlType OPTIONAL
> 
> with the corresponding response:
> 
>         responseControlType   OBJECT IDENTIFIER
>         responseControlValue  ANY DEFINED BY responseControlType 
> OPTIONAL
> 
> Note the OPTIONAL at the end of the line !

You 'wonder when the next draft will'.  Do you mean
'whether' or something else?  Or, did you just read the 
next half page of 'ASN1 pour les nuls'? 

> The aspect of periodic refresh are mentioned in section 1.4 but the 
> rational for it is missing many aspects. Section 7.2 only mentions:
> 
>      In order to protect against algorithm (i.e., hashing and digital
>      signature) compromise and/or computing technology advances,
>      timestamps are periodically refreshed.
> 
> This is only a small part of the whole story.

Thanks for pointing this out, you are invited to make constructive comments
to other parts of the whole story. 

> 
> Santosh said that TAP provide long-term non-repudiation of 
> information. I disagree with this. TAP has nothing to do with 
> non-repudiation.

I assume that in the last sentence there is a missing 'IMO' at the
beginning. 

Would you mind to provide your vision of non-repudiation?

Do you know the meaning of conversion and redundancy of security measures?  

> 
> TAP is an archive protocol and should be addressed in a group 
> specialized in archiving. PKIX is not such a WG.

Please reread the roadmap of PKIX concerning the section of data
certification and time stamping. 
 
> Note that it is also wrong to say that the TAA MAY be a TSA.

A missing 'IMO' or 'IMHO'? Can you explain why you think that 
a TAA cannot be a TSA?

> My position:
> 
> TAP should not been addressed in the PKIX WG, but some PKIX members 
> could
> certainly provide guidance to the security section dedicated to
time-stamping.

Time stamping falls into the same roadmap item. If I' follow your advise
then time stamping has nothing to do in PKIX. 
 
> As an alternative, we could produce a *draft* dedicated to the use of 
> time-stamp tokens associated with archives and the way to apply and 
> verify them. That draft would *not* reach the RFC status and would be 
> integrated in an RFC produced elsewhere.

Divide in order to conquer and then try to recombine is not exactly 
a good recipe IMHO to get a result. It seems that you already 
agree that there is something to be said from this group, and you already
discuss aspects the content. 

Peter




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33I2oJM000995 for <[e-mail]>; Thu, 3 Apr 2003 10:02:50 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h33I2oDW000994 for ietf-pkix-bks; Thu, 3 Apr 2003 10:02:50 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33I2lJM000989 for <[e-mail]>; Thu, 3 Apr 2003 10:02:48 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA06818; Thu, 3 Apr 2003 20:02:43 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.6); Thu, 3 Apr 2003 20:02:43 +0200 (MET DST)
Received: (from sylvest@localhost) by champagne.edelweb.fr (8.7.6/8.6.6) id UAA01151; Thu, 3 Apr 2003 20:02:42 +0200 (MET DST)
Date: Thu, 3 Apr 2003 20:02:42 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: TAP out of PKIX
Sender: [e-mail]
Precedence: 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, 

> 
> The technical quality of this draft document is very questionable.

Do you understand the meaning of the word 'draft'? 
Could it be that you suffer from psychological projection? 

For some it maybe surprising that you start with a comment about
the content of the document. Knowing a little bit of the
'French way of talking', one can still interprete this as "Well,
let's talk". Good. 

> 
> Like another draft document (i.e. SCVP) there is an abuse of OIDs
> in particular for archiveControls and even for the inclusion of
> a nonce using id-tap-nonce !!!
Peanuts.  

> 
> I wonder when the next draft posted to this WG will simply contain:
> 
>         queryControlType   OBJECT IDENTIFIER
>         queryControlValue  ANY DEFINED BY queryControlType OPTIONAL
> 
> with the corresponding response:
> 
>         responseControlType   OBJECT IDENTIFIER
>         responseControlValue  ANY DEFINED BY responseControlType OPTIONAL
> 
> Note the OPTIONAL at the end of the line !

You 'wonder when the next draft will'.  Do you mean
'whether' or something else?  Or, did you just read the 
next half page of 'ASN1 pour les nuls'? 

> The aspect of periodic refresh are mentioned in section 1.4 but the
> rational for it is missing many aspects. Section 7.2 only mentions:
> 
>      In order to protect against algorithm (i.e., hashing and digital
>      signature) compromise and/or computing technology advances,
>      timestamps are periodically refreshed.
> 
> This is only a small part of the whole story.

Thanks for pointing this out, you are invited to make constructive
comments to other parts of the whole story. 

> 
> Santosh said that TAP provide long-term non-repudiation of information.
> I disagree with this. TAP has nothing to do with non-repudiation.

I assume that in the last sentence there is a missing 'IMO' at the beginning. 

Would you mind to provide your vision of non-repudiation?

Do you know the meaning of conversion and redundancy of security measures?  

> 
> TAP is an archive protocol and should be addressed in a group specialized
> in archiving. PKIX is not such a WG.

Please reread the roadmap of PKIX concerning the section of data
certification and time stamping. 
 
> Note that it is also wrong to say that the TAA MAY be a TSA.

A missing 'IMO' or 'IMHO'? Can you explain why you think that 
a TAA cannot be a TSA?

> My position:
> 
> TAP should not been addressed in the PKIX WG, but some PKIX members could 
> certainly provide guidance to the security section dedicated to time-stamping.

Time stamping falls into the same roadmap item. If I' follow your advise
then time stamping has nothing to do in PKIX. 
 
> As an alternative, we could produce a *draft* dedicated to the use of
> time-stamp tokens associated with archives and the way to apply and
> verify them. That draft would *not* reach the RFC status and would
> be integrated in an RFC produced elsewhere.

Divide in order to conquer and then try to recombine is not exactly 
a good recipe IMHO to get a result. It seems that you already 
agree that there is something to be said from this group, and you
already discuss aspects the content. 

Peter



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33G6rJM024668 for <[e-mail]>; Thu, 3 Apr 2003 08:06:53 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h33G6rAf024666 for ietf-pkix-bks; Thu, 3 Apr 2003 08:06:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h33G6pJM024626 for <[e-mail]>; Thu, 3 Apr 2003 08:06:51 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h33G5v5w020760; Thu, 3 Apr 2003 11:05:57 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100307bab209808e47@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <p05100311baa52e765ff7@[128.89.88.34]> <[e-mail]>
Date: Thu, 3 Apr 2003 10:58:52 -0500
To: Denis Pinkas <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: draft minutes
Cc: IETF-PKIX <[e-mail]>
Content-Type: multipart/mixed; boundary="============_-1162736461==_============"
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>

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

At 4:21 PM +0200 4/3/03, Denis Pinkas wrote:
>Steve,
>
>As you probably noticed I was not present at the meeting, so I 
>cannot say whether the minutes are accurate or not.
>
>I can however say that they contain an obvious error since:
>Delegated Path Validation and Delegated Path Discovery Protocol Requirements
>is not RFC 3371 but RFC 3379.
>

Denis,

Thanks for the correction re the RFC #.

I have now received corrections from several folks and we are well 
past the 3/26 close of the comment period established in the message 
distributing the draft minutes.

So, attached is a PDF with the final, revised version of the minutes, 
which is being submitted to the IETF Secretariat.

Steve
--============_-1162736461==_============
Content-Id: <p05100307bab209808e47@[128.89.88.34].0.0>
Content-Type: application/pdf; name="PKIX_minutes_3=20=03.pdf"
 ; x-mac-type="50444620"
 ; x-mac-creator="4341524F"
Content-Disposition: attachment; filename="PKIX_minutes_3=20=03.pdf"
Content-Transfer-Encoding: base64

JVBERi0xLjIgDSXi48/TIA03IDAgb2JqDTw8DS9MZW5ndGggOCAwIFINL0ZpbHRlciAv
RmxhdGVEZWNvZGUgDT4+DXN0cmVhbQ0KSIl9V9tu2zgQ/YL8wzymgKvYkq+LomjWdrrZ
NrtGYyQFNvtAS7TNRiK1JGXHf79nKClJoaAPcWSbnMuZM2fG/Sge0ZHOYvqTzn5fn11c
DWgQ03p7lvSjZDKiyaBP6wXhJeWXI52vvlx/p/vPdCOlV3pHyUXcv+gn79Y/zpZrttHc
HE+TaMR3z5eZ8jKjzYluvTxI+iK17x4fTcLh+V4o637jo+Ve6nCYPjzi9dNmo6PUFB97
tFYFrUz+SB+8KqIST5+0cj7amcPHrmX8rwNZ7yW14RfSk9GppKyynIbHd6Ox39P1cn0V
0SV540VOZkuiLK15UoXwMj/RZNx1MJgwjOxB6UwdVFaJ3FEprFepKgUnr3TwUNSgRR0b
o8mkCfJyJ3UmyMqDkkcSOqPMpFXBMDgvfOXo/Uv+D+d/Xd+uH9692BuPa3vjYRsTsraS
BP9tTOVpMOP8W6OOQzsIqwwsw8FOujZYpJ1K53rkTCG7EY8GwTwQOu5VuqetzHPcs6ba
7cP91Ir00QFgCTBba7TLlU/30gHj3JkeXS9cCE6brotkEk3qJHKjd9KSqLxBIVQqctQC
xZfZe86JYSoq52kjST6VOXD3OGBlYQ419ZByytTqOomHDfIi9croXpOOSFNTMT5bYwMC
zAVOa4OscrOL6O8tuVKmCjRR2gNk+FeOz3SdDAYvFMFRU0orNgpQIAvcYwYCdVeVpbGe
PQGuHSw6RMRvv13NKYmn/Yi44HDTcTGcTYP9o7GPbM5wETkc4R4jml+++EENDD8cuWAb
oIeIT6QlgJJPoihzGZLuepgO23Is/ujRcj7v0eL2koku0E4oj9LgmvICfdWrqStzL2j+
7SvKvcqlcJJ2aDwmmKkAstp2vUwGTT1OpoJJjoeJKrg4LUIBZScjuoWgWBRAeI+2kYG8
GejBPef3os6t62M0bctxNFXOLYYSR7RuIGL8BbTgIHKV1Y5/jsPRUQE89AuqpeVTV8+G
w9p+YbTfR/SPgyXp/u2e64/aUBarxcVidcdWoQA2IydzGTjZNs9DEvd/1fyNzWQWB4N0
BSkNEISOB1Q5iJfVZEomAxJoPTTJf5WyshaDjXAKtVrXV0LHdKmWTKYtEV6MCoI2o/O4
+IQeteopUEAK1Bnxe5OanI5waUN1rMwB5SFoAxO162U8aohQW2NRdt6KI0Hwa0up0VmV
sjX2dDu/W8FsKtUhxFOIH8Zyhz2ca+PpB+uD6LoZxW0ByrwCl3Dj4V3b7Afjg1Rp5pUs
mWMQ4kacmzOdvLs+kllwgHi3yhYtN0PAnAc4fKI0Ny6g8WKv1xSHOVkojRmUd23Ho7YY
KBdU0l1IvefboaK/oF48m7WZh0gWyqVVrTg10ZAmtO/KSjYFFG9Uao0zW//GwImn42Dp
vpEf5MHDDlPhyDIsED0nwcz2xp5+Zh1LLAg5q0XDdydBPInbJG0gFJB0UjvMLNbHkpsE
KrCVGJA2FCzL2N/N5RxxQ24E3odOQlxO7XQ490brxKNZQ7pWizk2DpbVHeMHOwmPH7YV
0T2LQCa3SkuGLG47F88JsxRjCIokutyOh+MWelwXVe7Rc8KyNoJiTKwbcQquy2qTN/74
Y9YayqzY4sI1JomuRw7AxqDrukmS4APfo5tzgRR4cmJKwrSkOyW1Fs9LyS+Y0h83qKyw
Cp1oLrHabIPMOrpDZPcyR1Eezi/tzmiA8VVs3BskGcySZ7FrlxqEj23JIKYwk0AftAcL
rqbPudmgqp+tyujK2KqI6Hs06s9oueyEOJj26x54HVroMl4ulHNVvQcYVNDCANYaFoX5
Jcgyh0aDoFhYVFgtusYRf0M/4A/ecTUKUTNd+VpHywDNK/8RXYm0mfEGHCrBzLdW38Go
3ZQxLuXuudbbCqUCBXJVhAXaqt0ezfJwnoqyXR4KgzuQqyCiso6hx3m+tYUMhv0W/uUy
AsWgj1SLBm2tKWqGNHRoeAU+ABasVW0HhU95OnbNx/UK/2pq4ijvUQXCBCBdiFAFFcmo
R3sRaL+tj3RND5JnkXu53WYdapKx5jcxgjSvgkiBEY80JKTCzMCI828Wot/+UjgqX++w
R3GqV42fog6cSitrYQVrZjOda4IhVRzDMwvlEQc7bqavfi4EJ695jvA88mnivV5wyJC8
rFaD113c6df/AWu2UNINZW5kc3RyZWFtDWVuZG9iag04IDAgb2JqDTE2MjINZW5kb2Jq
DTQgMCBvYmoNPDwNL1R5cGUgL1BhZ2UNL1BhcmVudCA1IDAgUg0vUmVzb3VyY2VzIDw8
DS9Gb250IDw8DS9GMSA2IDAgUiANPj4NL1Byb2NTZXQgMiAwIFINPj4NL0NvbnRlbnRz
IDcgMCBSDT4+DWVuZG9iag0xMCAwIG9iag08PA0vTGVuZ3RoIDExIDAgUg0vRmlsdGVy
IC9GbGF0ZURlY29kZSANPj4Nc3RyZWFtDQpIiX1X25LaRhD9Av9DP6VwFatF3Mkb2bXj
jS9LVqScqpCHQRpgjKRRNKPF/H1Oz0gCl0he9oLEnO7Tp0/3DILhhE705pf1m/v3IYVD
Wu/ejAbBaDah6WIa4Nf6kQa0jvnHiXqR2ufCVqWkZbrXpbKHzNBP9FGe6Q8j9pI2o+GA
flMZRfFBiIQ2vUiLUuV7+iBOR3rQualSi/83b9+uv715t2bs6dQjzkeBA+w976zMqai2
qYrpiMMTYQXO2umSKiPpBGAyTSxm85ZiXaUJKXwJYLEqUtmnrbxANEnNBpwyY+CcxB+U
aeRjDyInnUsSTWJ9ksE+6NNLtKRVFN0/L9+tCAE8frh/jJYBrXUiznS6ATKZOYStypNL
lPQqUoU8lM45JUNWk6BCqJL07oJq+vSqBJ4YkJRKen56DLoI41Fdm94zQv6nksadqwwd
9IlPlt8LEGM4LevSYhY9SVtJV7lzNcBWFwK/PcJ1aJ4RQZn6zlEfhDlchc7syFdULlG7
nSxlbq9q2EUIZ00triGYlletEiplUuWJwCGxLK3aqVhYiRRNJfKYy1tZQtppijetUHkX
YDD2p29Vquz5mpa4Kl14uXa8IRV8bEsVW/Xq6AlomYtU73VlHKQ0BBmbLk+TxaApBdR3
VWOceVFon1QgwVxR6hj43A8XYeyUTBOcD7VkwsYHPO3CzGZNOfbI1VjfErtSZ6ix/IEi
V10kWwcjnZhqsIC+yloHie6iTMdNScAMB9Lnmp5k219xWiU4MEkUJylSHwbAdiJmlhnO
9dNe5rLE8+oWZ5PQYYAijp2luVW2ldcWSi2lYJcAKagZzMAADS13gKroJAwUBrsppcy4
ivpVll2Q0awpzOkggVMyWMkKYkIkJMCiiDXEVOa+UfhRkrBCwCDC4OhQskLj/y7AcFyX
BFaX70HtXwaES/N359XxYu5eXJeVsTh6WaLKENqq1FbHOoW1rZerzVvnng+iTOmrSFMR
w097D2eULtbZDcMcz8dNil/kiSP1pyVyp3LHHvIsXxXOYee0Nbqo0UE/V6/PtmmqotCl
7UY+C+sk8faXl4AilcEucJbIjYid0ltcB6IymZ7RTjvQeGAM/sRYkRWm3z1+Mm8Ed6Vg
KOHh5RPrwcYBvUjnb6aJEb+3GXqybjLfB0Cu07oBMq47Bw0mKFWZYhaM5C/cwztKJdEq
FIuidoqA3jWaczaN2sDlUjirJ/SG2sajsCkFvgBRwU3Qp05B9lzAPppQRRzLAgE4p8NR
and2AFYfAdkHABQN7YkuRjhvBJcqvNXw8/6BRuE0vBBdnwVGJEmUS59lEtBzUbdsrQnT
BRhMmmo0ne40gy6MD2C45aqPP1PhvNJPsVLhcaEVQuekEUhAD5+jDsJoMXTHo16wOu9U
XLt1tCIEzyuEgfUSswdBa5h7bRKZlN4QLCqTSMkWkLB/dzFm86YUhqche58TVm5bCTml
HpSr7laiu9gkc/TQ11/ppMsjQSKZ8xt80kWYTi6dr0qDUcpTSGA+uFjbeay9AFJlUCwn
P3Okk3Oa3EoeOXA3xdouuy45mgzbanDPsdX50VJngcbd+SxO7GvXqSANn8F/WtJoOGlY
+r3CoMAQSujhqgfZnHYKrX5HkZU7GHEEBlEjBLDpvUAKOirk0d7wpVE4rPlhAkVlWTyK
kxSJG8NV4eYSc5PouHImzvSw/5ojl/nKsjuhDxeLdonzB6HOPJ5q73bnmlgXshFPA9KM
4fp9xx3WoVclTzcMfjifet/ggbHBRMzv5He0hYHusXIWNT/1UooME0C4mXJN449baxdk
NmzqkKg9Bmh6GdYAuZ6l6Rm7IdpD5zBYPvSftnDXiLy63EhmsqhrAtEY3YfMPQUQI0jD
Gsid6yeZawtHYrWFoWBAdol0o7qLMp42peHXcS/w1wKLIY6lcX+wzLdHSbxiKeWSXa1f
3P+Zyp1ksHjhZxdmNGoxsHhYn8ZKI9h0WYsApY3BWW0wPPn9yujscjgfIBckestAhuGi
KUkGVTqB1b7haAAUXKhUOM3vU7lskzE8NhpjbNnEV7oog2ldEKxXmTjKOkYsh+D73Tp6
YpNVPDmw2HtfPUjcFrgiiSgT8z/dHSI/PvqTginh+y+Sw/+ZPj0uV/d/BpPBAAMNMnOd
57aO6KgKilK+Kmx6n3R8PCCpu88CuspvtHg4bW6Hvaf1H84z+94GnedWBcc74a/xxXLG
98pw4ZbLRh3NM3/p5Ml25x+R9Mslk+1CDeiz+MaGrQsVu0HauGc370lzheSirz4+/fkz
SpKpO6wnOBE3MlGe2y27z3OG3ebygcwPrPfLJt7VeDhu75CJznjIw3QLEMf3CZHx9vLl
hRfagC0UuyNa2k8aXDnw3DWSfwNux+wPsS9gqt1IZ+hvkgDA0sLFwtsjPgorXlVPGyS2
p7LK3caXyK3b+Le6su6pQxQ3DCEM2zskGIK1g9vgPwU1b+9qUbX9JtFyT87tnOdwsT7D
r3WCYbESGJ+/Iaa7r1ofvbg2vY9P0bKV0b/+7S7IDWVuZHN0cmVhbQ1lbmRvYmoNMTEg
MCBvYmoNMTg5MQ1lbmRvYmoNOSAwIG9iag08PA0vVHlwZSAvUGFnZQ0vUGFyZW50IDUg
MCBSDS9SZXNvdXJjZXMgPDwNL0ZvbnQgPDwNL0YxIDYgMCBSIA0+Pg0vUHJvY1NldCAy
IDAgUg0+Pg0vQ29udGVudHMgMTAgMCBSDT4+DWVuZG9iag0xMyAwIG9iag08PA0vTGVu
Z3RoIDE0IDAgUg0vRmlsdGVyIC9GbGF0ZURlY29kZSANPj4Nc3RyZWFtDQpIiX1XXXPb
NhD8BfkP95jMuKq+ZffNtd2M204mEzlJZ+o+QORJQkMCLABKUX999wCCckq1L5JGJO9u
b/cWx/FouqAjvfrx6dX3P01oMqWn7avlcjRbLWg1GdPTPeGjkI8jvX5rVUXaU7DUOHvQ
JZOiozrJH44bx55NwF8NO28N7n28p4OqWqbn1zzaja7ePP356uFJss3GMcfyZjnCF9K8
Niro/JBp6w275zekDcIV7ILe6kKFPlC64NvNn1wgYxWMqjnfj4qGia5no5Qn7FWg0rIn
Y/FD+6KynkkHn2q9oq11wKcPqjgBlgIUP6KnPQvoxnqUqCpvhylWY+mm5NCmqNoSKZQ8
E2xhqxg1OGX8lp3TZkdhj1aWKihpX0D4u9uYxjEddVXRhsnbmod5FqsEhF2tja3s7kTF
Xpkd+yvaKM8lWUOf39KWudyo4kuOinT2wK5SDXVZwp5s64YZ5rPMCqislRFawbYRGtjR
0bovV6R8rHrIG8UW1zaghYF9BDrMge+UQqJJbYrePyKqKVNncqkGKKLk0I8NB6AmdLZw
egOg4FtqeLwf0S04uSCwySqTUltg5q+qbqpzhzsdfxNJqFZt2IMwx3+17CGN+HBu6DDL
eB5TbJ2tY5jPb0f0u68Q2f8xuHuxWnXQf9VKQ170gRvrwg/08LBeP9LzbDqmD7oolCst
vWWz22ujIf11aEtt6Z0NymmAyJee35xzdMO7WM4z7vdpLiNNooyHFjJmhR8VhsdZowta
6x14bIFxHcAAEuu/4wPD4heTGPXR6KBxy4FH9JjlvnGat2jaQfORrPyq+KAgnoePmLSd
DpCJz6mGoWerLDvfVeGTIGRKW+8jgC3G1GnbegT9Lsm9sHWtoQwZONwtgpIB2znbNkPl
LabzUR7TJDWFKR/Rut1hhGKXooATGRLw/S+Pv8lAKeQwpaSp9W4faMcBwsQnxmmYZjLJ
DKitqPaTZmMU1cwB1f2PPubX89yHfwvk53frW7rbq6oC9SyF0XQ8ngprAR1Jt9F39OHU
ghVVKqhGnrmgkPlq0rXhlnx63KXHbRoFbVA1lOLURlc6wOWlO+irKkA72Ecf0MGfVaPM
aAhicZ3hyzxBg22FOQJ9fRiorfW8bZM3tqaQkZcrvuEiGb6QgRHdVFz76FfDPPNO5cJR
L5tIG3Lh2bItxNph4QAFo+/vwaCjEmJz0BiCGiMyDD6bZCZ6S7+7TdE/4bsAdtQmmXZs
0KkILHp6tHuJX0CikLFYOe4bpphcZx/c62Ifu26So1YnnFPxlCqsQbxaXPBbnNGsTmcX
w5kI27oAZLzIbJRc20jDnnVXYuBinw6S/1HlbHXdq/L+9n3U3qP3sMdkWPcKJYg2y6Mu
vkB3Hw3MwXlRDtKtVQUI5QUhzpaLUXaqyHRcMWQCj4zuGWmAZ+XQHGnqi20gEXH34dco
RKlqWPVimoH3R6MyJ4y9KDAEHCMt1gorIyxJZX9Yd2vF/bsr2gGDoaJ1Ts7AyylmN8mz
Uo2VhhdF5YKdH9uI4mjbqsSVLywUVjauMkmOUSyytiQAQOoOF9xkNl3k7vc4UtE9iG5J
gRk2Np7YtQpFxOlt1cZROuLM9iy2jwib4ZY0m0z7LYljPfw1ROdLZz1WPNle8HAfMu4u
IKybUmwggOwtbZXDTkV7NTTg6c1N5kS4dVwwulwm/Gh3CZZ924gXCSQx6AbhFZor57GG
l+SFJ+4F9oItTK+XMUFRwXVDEkpqLdp0a7rW5bCSotcCIDuxOGuuXkz1MMNq2q+uOO3O
NESVlqiyCNad4C+4IGfjqY8clz/oPK4LL/U8TLK46QjJSu86grmQ9YW320wmWn2Iopaw
RnytpPOui3zD4PNl5gF9KBgHLJ6P269t2qozs38DSaKOnHvACYz1U870iMGEaqiq6WyW
LVTWaZYHrVM4v3yjCo4ZWWiQDKdU9N5WcPGXvfle0Of98AKYyU2m44y/buFuaFPbYMzQ
peMefB7ipCM5Tm8Y0wvi0pIZx4bLYYbxMnOxU9qItScR/rdIo/jOy3lXO6my1GkbG54H
k5tZJqXHESvr1JsGzNiXE9Bdkvcu/B5R9IE1w7XEfG/vh0mu46vda0wncd3gS//NqTZZ
tyUm1ARbNDiDYCb9uGN2CODg78L9EUKpqmH05fJ8apadU0dWI/h+idqqg/j5wK8SxFhM
ep+41KZFfp87xzvYqFgxObQDqqxxhl4hEFYbWJH8X2KxKBPAoMSN4ztYv10O08z7d7ru
Ja3SPgxOyX8Aiejaow1lbmRzdHJlYW0NZW5kb2JqDTE0IDAgb2JqDTE3MDMNZW5kb2Jq
DTEyIDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQgNSAwIFINL1Jlc291cmNlcyA8
PA0vRm9udCA8PA0vRjEgNiAwIFIgDT4+DS9Qcm9jU2V0IDIgMCBSDT4+DS9Db250ZW50
cyAxMyAwIFINPj4NZW5kb2JqDTYgMCBvYmoNPDwNL1R5cGUgL0ZvbnQNL1N1YnR5cGUg
L1RydWVUeXBlDS9OYW1lIC9GMQ0vQmFzZUZvbnQgL0NvdXJpZXINL0VuY29kaW5nIC9N
YWNSb21hbkVuY29kaW5nDT4+DWVuZG9iag0yIDAgb2JqDVsgL1BERiAvVGV4dCAgXQ1l
bmRvYmoNNSAwIG9iag08PA0vS2lkcyBbNCAwIFIgOSAwIFIgMTIgMCBSIF0NL0NvdW50
IDMNL1R5cGUgL1BhZ2VzDS9NZWRpYUJveCBbIDAgMCAgNjEyIDc5MiAgXQ0+Pg1lbmRv
YmoNMSAwIG9iag08PA0vQ3JlYXRvciAoTWljcm9zb2Z0IFdvcmQpDS9DcmVhdGlvbkRh
dGUgKEQ6MjAwMzA0MDMxMDUzMDUpDS9TdWJqZWN0ICgpDS9UaXRsZSAoKQ0vQXV0aG9y
IChLZW50KQ0vUHJvZHVjZXIgKEFjcm9iYXQgUERGV3JpdGVyIDQuMDUgIGZvciBQb3dl
ciBNYWNpbnRvc2gpDS9LZXl3b3JkcyAoKQ0+Pg1lbmRvYmoNMyAwIG9iag08PA0vUGFn
ZXMgNSAwIFINL1R5cGUgL0NhdGFsb2cNL0RlZmF1bHRHcmF5IDE1IDAgUg0vRGVmYXVs
dFJHQiAgMTYgMCBSDT4+DWVuZG9iag0xNSAwIG9iag1bL0NhbEdyYXkNPDwNL1doaXRl
UG9pbnQgWzAuOTQ5NiAxIDEuNDA1OSBdDS9HYW1tYSAxLjc5NjkgDT4+DV0NZW5kb2Jq
DTE2IDAgb2JqDVsvQ2FsUkdCDTw8DS9XaGl0ZVBvaW50IFswLjk0OTYgMSAxLjQwNTkg
XQ0vR2FtbWEgWzEuNzk2OSAxLjc5NjkgMS43OTY5IF0NL01hdHJpeCBbMC40MiAwLjIy
NjEgMC4wMTk3IDAuMzY0IDAuNjg2NiAwLjE2MjEgMC4xNjU2IDAuMDg3MyAxLjIyNDEg
XQ0+Pg1dDWVuZG9iag14cmVmDTAgMTcNMDAwMDAwMDAwMCA2NTUzNSBmIA0wMDAwMDA2
MTIzIDAwMDAwIG4gDTAwMDAwMDU5OTMgMDAwMDAgbiANMDAwMDAwNjMwOSAwMDAwMCBu
IA0wMDAwMDAxNzM1IDAwMDAwIG4gDTAwMDAwMDYwMjQgMDAwMDAgbiANMDAwMDAwNTg4
NCAwMDAwMCBuIA0wMDAwMDAwMDE3IDAwMDAwIG4gDTAwMDAwMDE3MTUgMDAwMDAgbiAN
MDAwMDAwMzg0MyAwMDAwMCBuIA0wMDAwMDAxODUzIDAwMDAwIG4gDTAwMDAwMDM4MjIg
MDAwMDAgbiANMDAwMDAwNTc2NCAwMDAwMCBuIA0wMDAwMDAzOTYyIDAwMDAwIG4gDTAw
MDAwMDU3NDMgMDAwMDAgbiANMDAwMDAwNjM5OCAwMDAwMCBuIA0wMDAwMDA2NDc4IDAw
MDAwIG4gDXRyYWlsZXINPDwNL1NpemUgMTcNL1Jvb3QgMyAwIFINL0luZm8gMSAwIFIN
L0lEIFs8MjljYjczZTcyYTQ4ZjRmMWE2M2ZlZjU1NzgxMWY3ZDM+PDI5Y2I3M2U3MmE0
OGY0ZjFhNjNmZWY1NTc4MTFmN2QzPl0NPj4Nc3RhcnR4cmVmDTY2NDQNJSVFT0YN
--============_-1162736461==_============--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33F9wJM018668 for <[e-mail]>; Thu, 3 Apr 2003 07:09:58 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h33F9wYM018667 for ietf-pkix-bks; Thu, 3 Apr 2003 07:09:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h33F9uJM018663 for <[e-mail]>; Thu, 3 Apr 2003 07:09:56 -0800 (PST)
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA21270 for <[e-mail]>; Thu, 3 Apr 2003 17:12:55 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id QAA07720 for <[e-mail]>; Thu, 3 Apr 2003 16:06:33 +0200
Message-ID: <[e-mail]>
Date: Thu, 03 Apr 2003 17:05:47 +0200
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: [e-mail]
Subject: Re: TAP out of PKIX
References: <[e-mail]> <p0510030abab0a74d5643@[128.89.88.34]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The technical quality of this draft document is very questionable.

Like another draft document (i.e. SCVP) there is an abuse of OIDs
in particular for archiveControls and even for the inclusion of
a nonce using id-tap-nonce !!!

I wonder when the next draft posted to this WG will simply contain:

        queryControlType   OBJECT IDENTIFIER
        queryControlValue  ANY DEFINED BY queryControlType OPTIONAL

with the corresponding response:

        responseControlType   OBJECT IDENTIFIER
        responseControlValue  ANY DEFINED BY responseControlType OPTIONAL

Note the OPTIONAL at the end of the line !

The aspect of periodic refresh are mentioned in section 1.4 but the
rational for it is missing many aspects. Section 7.2 only mentions:

     In order to protect against algorithm (i.e., hashing and digital
     signature) compromise and/or computing technology advances,
     timestamps are periodically refreshed.

This is only a small part of the whole story.

Santosh said that TAP provide long-term non-repudiation of information.
I disagree with this. TAP has nothing to do with non-repudiation.

TAP is an archive protocol and should be addressed in a group specialized
in archiving. PKIX is not such a WG.

Note that it is also wrong to say that the TAA MAY be a TSA.

My position:

TAP should not been addressed in the PKIX WG, but some PKIX members could 
certainly provide guidance to the security section dedicated to time-stamping.

As an alternative, we could produce a *draft* dedicated to the use of
time-stamp tokens associated with archives and the way to apply and
verify them. That draft would *not* reach the RFC status and would
be integrated in an RFC produced elsewhere.

Denis



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33EQMJM017426 for <[e-mail]>; Thu, 3 Apr 2003 06:26:22 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h33EQMQV017425 for ietf-pkix-bks; Thu, 3 Apr 2003 06:26:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h33EQKJM017421 for <[e-mail]>; Thu, 3 Apr 2003 06:26:21 -0800 (PST)
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA26450; Thu, 3 Apr 2003 16:28:57 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id PAA07322; Thu, 3 Apr 2003 15:22:34 +0200
Message-ID: <[e-mail]>
Date: Thu, 03 Apr 2003 16:21:49 +0200
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: Stephen Kent <[e-mail]>
CC: IETF-PKIX <[e-mail]>, Tim Polk <[e-mail]>, Russ Housley <[e-mail]>
Subject: Re: draft minutes
References: <p05100311baa52e765ff7@[128.89.88.34]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,

As you probably noticed I was not present at the meeting, so I cannot say 
whether the minutes are accurate or not.

I can however say that they contain an obvious error since:
Delegated Path Validation and Delegated Path Discovery Protocol Requirements
is not RFC 3371 but RFC 3379.

I read the minutes but could not find a point I mentioned before the 
meeting, nor a separate response to the e-mail that I sent on March 17 to 
Tim Polk, yourself, Russ as co-editor of RFC 3280, and the two ADs before 
the meeting.

That e-mail was mentioning several other unresponsed e-mails.
The topic was: "key usage bits 0 and 1".

I would greatly appreciate to finally obtain a response.

Regards,

Denis


> Folks,
> 
> Attached are the draft minutes from last week's PKIX meeting.  Please 
> review them and send comment to me by Wednesday, 3/26.  Also, each 
> presenter should send a copy of his slides to me.  I already have slides 
> from Riccardo, Jim, Jong-Wook, Trevor, and Stefan.
> 
> As noted in the minutes, we will conduct a straw poll, starting now, to 
> determine the sense of the WG re initiating a new work item, for the 
> trusted archive spec.  The co-chairs approved publication of this 
> document as a WG I-D, as it seems like another aspect of PKI 
> infrastructure, e.g., it makes use of our time stamp authority standard 
> and is an obvious component for NR support. However, given the limited 
> support shown at the meeting for pursuing this work, we want to revisit 
> this decision before proceeding. Please look at the document 
> (draft-ietf-pkix-tap-00.txt) and indicate whether you believe this is an 
> appropriate WG activity, or not.
> 
> Thanks,
> 
> Steve




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h331rwJM017690 for <[e-mail]>; Wed, 2 Apr 2003 17:53:58 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h331rwBg017689 for ietf-pkix-bks; Wed, 2 Apr 2003 17:53:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h331ruJM017678 for <[e-mail]>; Wed, 2 Apr 2003 17:53:57 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h331rfoU028838; Thu, 3 Apr 2003 13:53:41 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h331rfu04855; Thu, 3 Apr 2003 13:53:41 +1200
Date: Thu, 3 Apr 2003 13:53:41 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: RFC2510bis
Sender: [e-mail]
Precedence: 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 Sylvester <[e-mail]> writes:

>If not, will some open questions concerning the socket protocol address be
>addressed by something like the old transport prtocols for 2510 draft or in
>simpler way, in particular:

Isn't this more or less de facto solved by everyone using the alternative HTTP
transport, which fixes all of these problems for you?

Peter.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32IxjJM021848 for <[e-mail]>; Wed, 2 Apr 2003 10:59:45 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32IxjXv021847 for ietf-pkix-bks; Wed, 2 Apr 2003 10:59:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32IxhJM021841; Wed, 2 Apr 2003 10:59:43 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA01750; Wed, 2 Apr 2003 20:59:44 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.6); Wed, 2 Apr 2003 20:59:44 +0200 (MET DST)
Received: (from sylvest@localhost) by champagne.edelweb.fr (8.7.6/8.6.6) id UAA27355; Wed, 2 Apr 2003 20:59:43 +0200 (MET DST)
Date: Wed, 2 Apr 2003 20:59:43 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: Re: RFC2510bis
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> See the list archives for the message from 1/30/03 to the ADs, and 
> from the IESG on 2/10/03.

The message says:

   The PKIX WG has completed Last Call and achieved rough consensus on the 
   specification "Internet X.509 Public Key Infrastructure Certificate 
   Management Protocols".

When did this happen?

-----

Extract from the minutes of 
PKIX WG Meeting 12/11/01

Edited by Steve Kent

Three RFCs are ready for progression to Draft 
Standard status: CRMF, CMP, and OCSP(v1).


----
From: Carlisle Adams <[e-mail]>
Date: Mon, 3 Dec 2001 15:59:20 -0500 

Hi Francois,

Thanks again for keeping us all up-to-date and for doing your part to keep
various specifications in sync!

I will update 2511bis when I update 2510bis (i.e., immediately after Salt
Lake City) and re-submit both.

Carlisle.

----

Draft 6 appeared at 17-Dec-01


-----

Date: Mon, 29 Jul 2002 9:8:5 +0800 :
From: carol <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: draft-ietf-pkix-rfc2510bis-06.txt and draft-ietf-pkix-rfc2511bis-04.txt

Hi,

  According to the draft themselves, they have expired in June , 2002.

But I couldn't find any new version draft or RFC about rfc2510 and rfc2511.

What's the current status of draft-ietf-pkix-rfc2510bis-06.txt and draft-ietf-pkix-rfc2511bis-04.txt?

----


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32IljJM021474 for <[e-mail]>; Wed, 2 Apr 2003 10:47:45 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32IljI7021473 for ietf-pkix-bks; Wed, 2 Apr 2003 10:47:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32IliJM021468 for <[e-mail]>; Wed, 2 Apr 2003 10:47:44 -0800 (PST)
Received: from MMyersLapTop ([65.39.77.110]) by mailout.fastq.com (8.11.6/8.11.3.FastQ-MailOut) with SMTP id h32IlkV26968 for <[e-mail]>; Wed, 2 Apr 2003 11:47:46 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: TAP  - Yes in a new group
Date: Wed, 2 Apr 2003 11:42:37 -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: <006201c2f87b$768070b0$[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>

I vote to redirect TAP away from PKIX.

Mike



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32Hw1JM020025 for <[e-mail]>; Wed, 2 Apr 2003 09:58:01 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32Hw16f020024 for ietf-pkix-bks; Wed, 2 Apr 2003 09:58:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32HvuJN020020; Wed, 2 Apr 2003 09:57:57 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0521060fbab0d4f24a89@[63.202.92.152]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Wed, 2 Apr 2003 09:57:55 -0800
To: Peter Sylvester <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: RFC2510bis
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 7:08 PM +0200 4/2/03, Peter Sylvester wrote:
>To come back to some PKI relevant things:
>
>
>The IMC server mentions that the document is in
>IETF last call? How did we got at that state?

See the list archives for the message from 1/30/03 to the ADs, and 
from the IESG on 2/10/03.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32H88JM018283 for <[e-mail]>; Wed, 2 Apr 2003 09:08:08 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32H887n018282 for ietf-pkix-bks; Wed, 2 Apr 2003 09:08:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32H86JM018278 for <[e-mail]>; Wed, 2 Apr 2003 09:08:07 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA01275 for <[e-mail]>; Wed, 2 Apr 2003 19:08:07 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.6); Wed, 2 Apr 2003 19:08:07 +0200 (MET DST)
Received: (from sylvest@localhost) by champagne.edelweb.fr (8.7.6/8.6.6) id TAA27043 for [e-mail]; Wed, 2 Apr 2003 19:08:06 +0200 (MET DST)
Date: Wed, 2 Apr 2003 19:08:06 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RFC2510bis
Sender: [e-mail]
Precedence: 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 come back to some PKI relevant things:


The IMC server mentions that the document is in
IETF last call? How did we got at that state? 

So, just in case I missed some announcement, I apologise 
for not raising the following earlier: 

Is rfc2510bis supposed to make RFC 2510 obsolete or not?
If yes, where is the replacement of chapter 5 of RFC 2510.

If not, will some open questions concerning the
socket protocol address be addressed by something
like the old transport prtocols for 2510 draft
or in simpler way, in particular:

- Who is supposed to initiate a connection?
  (both parties can do?)

- Who closes and when?
  (client, server after some timeout?, nobody?)

- is the protocol half duplex/full duplex?

- can one send a errorMsgRep at any time?



regards
Peter



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32EoRJM006277 for <[e-mail]>; Wed, 2 Apr 2003 06:50:27 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32EoRXe006276 for ietf-pkix-bks; Wed, 2 Apr 2003 06:50:27 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h32EoPJM006264 for <[e-mail]>; Wed, 2 Apr 2003 06:50:25 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h32EoE5w003595; Wed, 2 Apr 2003 09:50:14 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100308bab0a711484b@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 2 Apr 2003 09:41:47 -0500
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: TAP
Cc: "Stefan Santesson" <[e-mail]>, <[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>

At 3:07 PM -0800 3/31/03, todd glassey wrote:
>THERE IS NO REASON THAT TAP CANNOT BE REPRESENTED IN XML -
>IT IS MERELY AN ENCODING MODEL.
>
>Todd.

Todd,

Your CAPS LOCK key is stuck again.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32EoRJM006278 for <[e-mail]>; Wed, 2 Apr 2003 06:50:27 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32EoRoe006275 for ietf-pkix-bks; Wed, 2 Apr 2003 06:50:27 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h32EoPJM006265 for <[e-mail]>; Wed, 2 Apr 2003 06:50:25 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h32EoE60003595; Wed, 2 Apr 2003 09:50:16 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0510030abab0a74d5643@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 2 Apr 2003 09:45:11 -0500
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: TAP
Cc: <[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>

At 8:58 AM -0800 4/1/03, todd glassey wrote:
>Stephen - TAP is one of the most important things that PKI
>and PKIX can undertake and it should be adopted within PKIX
>or allowed to flow through PKIX as a sub group. Maybe it has
>its own list and is a short termed project???
>
>I cant see any reason for you as the WG Chair to say no to
>TAP other than it actually has real deliverables and could
>potentially be one of the most important things to come out
>of PKIX and the PKI world in many years. And for many of us,
>this potentially may be the log that breaks the log-jam in
>the PKI marketplace as well.

You missed the point, again, Todd.

I agreed to add TAP as a WG item, in response to a request by its authors.

This decision was questioned at the PKIX meeting (read the minutes).

I then initiated a discussion on whether TAP should be a WG item.

Do try to keep up,

Steve



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32DVqJM002621 for <[e-mail]>; Wed, 2 Apr 2003 05:31:52 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32DVq6M002620 for ietf-pkix-bks; Wed, 2 Apr 2003 05:31:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32DVmJM002610 for <[e-mail]>; Wed, 2 Apr 2003 05:31:48 -0800 (PST)
Received: from tsg1 (unknown[12.81.121.24]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <20030402133141112008stgqe>; Wed, 2 Apr 2003 13:31:42 +0000
Message-ID: <012701c2f91c$141b7720$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "tho" <[e-mail]>, <[e-mail]>, "ietf-pkix" <[e-mail]>
References: <[e-mail]> <006201c2f87b$768070b0$[e-mail]> <[e-mail]>
Subject: Re: TAP  - Yes in a new group
Date: Wed, 2 Apr 2003 05:20:01 -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.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: 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 is a larger inherent question regarding PKIX and that is "Must all of
PKIX be involved with each project" and then the issue is how the project
team deals with the WG Chair - do they answer questions re their efforts, do
they file updates in a timely manner, etc.

The problem is that the way PKIX is setup, the WG Chairs are personally
involved in the evolution of each protocol that goes through the group and
that is a serious issue I think.

Also DVCS and many of the non-core x509 tools are also outside the scope of
the Purest-Form-of-PKI so how do they fit and TAP not?  RFC2026 talks to the
need to implement fair and equal environments. And when PKIX didn't have
anything on its plate it took what it could get - core PKI or otherwise. For
instance how is the TSP part of any core protocol? Its not clearly.

So what has happened is that with this management model, management is
saying that it is loaded too much - this is not a issue with what is
processed with PKIX but rather for the mandate from two individuals that
they must have a hands on in everything they do. If they were to set up a
defined vetting process for their drafts and rfc's this would also not be
such a problem but rather than be pro-active they insist that this happen
elsewhere in the IETF and that wont occur until someone sues the
organization, at least as far as I can tell.

Its why this deck can be stacked from the gate. Is it time to do anything
about it?

Todd Glassey
----- Original Message -----
From: "tho" <[e-mail]>
To: <[e-mail]>; "ietf-pkix" <[e-mail]>
Sent: Wednesday, April 02, 2003 12:24 AM
Subject: Re: TAP - Yes in a new group


>
> On Tue, Apr 01, 2003 at 10:21:06AM -0800, Jim Schaad wrote:
> >
> > I think that TAP is a useful addtion, but I would like to see the PKIX
> > group restrict itself to direct issues of what certificates are and how
> > to get them and move out of the how to use them field.
>
> Personally I have nothing against a new WG for dealing with TAP and other
> applications based on PKIX if this just aims at a simpler/more efficient
> work-load distribution.  But really, there is no "philosophical" reason
> for which TAP can be considered different from the TSP or DVCS efforts
which,
> in fact, have grown within the PKIX-WG scope.
>
> Thomas



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h328OqJM029935 for <[e-mail]>; Wed, 2 Apr 2003 00:24:52 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h328OqYX029934 for ietf-pkix-bks; Wed, 2 Apr 2003 00:24:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from smtp3.cp.tin.it (vsmtp3.tin.it [212.216.176.223]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h328OoJM029927 for <[e-mail]>; Wed, 2 Apr 2003 00:24:51 -0800 (PST)
Received: from congo.homeunix.net (80.117.16.108) by smtp3.cp.tin.it (6.5.033) id 3E48CE9F01314CD6; Wed, 2 Apr 2003 10:24:36 +0200
Received: from host108-16.pool80117.interbusiness.it (localhost [127.0.0.1]) by congo.homeunix.net (8.12.3/8.12.3) with ESMTP id h328OXuh000430; Wed, 2 Apr 2003 10:24:34 +0200 (CEST) (envelope-from [e-mail])
Received: (from tho@localhost) by host108-16.pool80117.interbusiness.it (8.12.3/8.12.3/Submit) id h328OVGl000429; Wed, 2 Apr 2003 10:24:31 +0200 (CEST)
Date: Wed, 2 Apr 2003 10:24:30 +0200
From: tho <[e-mail]>
To: [e-mail], ietf-pkix <[e-mail]>
Subject: Re: TAP  - Yes in a new group
Message-ID: <[e-mail]>
References: <[e-mail]> <006201c2f87b$768070b0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <006201c2f87b$768070b0$[e-mail]>; from [e-mail] on Tue, Apr 01, 2003 at 10:21:06AM -0800
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 Tue, Apr 01, 2003 at 10:21:06AM -0800, Jim Schaad wrote:
> 
> I think that TAP is a useful addtion, but I would like to see the PKIX
> group restrict itself to direct issues of what certificates are and how
> to get them and move out of the how to use them field.

Personally I have nothing against a new WG for dealing with TAP and other 
applications based on PKIX if this just aims at a simpler/more efficient
work-load distribution.  But really, there is no "philosophical" reason 
for which TAP can be considered different from the TSP or DVCS efforts which,
in fact, have grown within the PKIX-WG scope.

Thomas


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h320PZJM002200 for <[e-mail]>; Tue, 1 Apr 2003 16:25:35 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h320PZm7002199 for ietf-pkix-bks; Tue, 1 Apr 2003 16:25:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h320PSJM002167 for <[e-mail]>; Tue, 1 Apr 2003 16:25:32 -0800 (PST)
Received: from VON-TP-T30 (terra.mcs.anl.gov [140.221.11.103]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id h320PN4104344; Tue, 1 Apr 2003 18:25:23 -0600
X-Mailer: 21.4 (patch 11) "Native Windows TTY Support (Windows)" XEmacs Lucid (via feedmail 10 I); VM 7.07 under 21.4 (patch 11) "Native Windows TTY Support (Windows)" XEmacs Lucid
From: "Von Welch" <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 1 Apr 2003 18:26:02 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: "Jim Schaad" <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-proxy-04
CC: "IETF-PKIX" <[e-mail]>
In-Reply-To: <000201c2f045$d026f960$[e-mail]>
References: <000201c2f045$d026f960$[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>

Jim,

 Thanks for the comments. I've gone through and responded to each
wither with answers, questions, a different opinion or description of
change to the draft.

Von

Jim Schaad writes (23:36 March 21, 2003):
 > 
 > I have the following comments, questions and issues with the draft:
 > 
 > 1.  Formatting:  You should be starting the first column of the text in
 > column #1 not column #10.  As it currently is laid out, I have problems
 > reading it.

Looking around there doesn't seem to be any convention or rule for
this, though ours is more indented than most. Looking at IDs and RFCs
that start on column 1, I find them really hard to read. Column 4
seems to be fairly common and easier to read, so I've reformatted to
that.

 > 2.  Feel free to ignore this comment.  I have a strong preference for
 > statements to be written if A then B not do B if A.  You have several of
 > this variety.  I find this order of writing difficult to read.
 > 
 > 3.  Feel free to ignore this comment.  I have a strong preference for
 > writing protocol statements in a positive manner.  i.e you MUST do this
 > rather than you MUST NOT do that.  From a testing standpoint I claim
 > that I don't know how to test negivate statements, just positive
 > statements.  
 > 
 > 4.  Section 2.3 - I disagree that if stee wants to go offline, he would
 > leave an agent running on his laptop.  Does this agent restart when the
 > laptop goes back on line?

I don't think this point is really central to the issue and worth
discussing unless you think it is really clouding things. The point in
Steve being offline is that he is not available to perform
authentication. Having the agent run when not on the network doesn't
make sense, but that seems to be going into greater than needed
detail.

 > 5.   Section 2.5 - for item 2 on creating identities, would you
 > considere a self-signed certificate to fall into this category?  If so
 > this might be a better example.

I agree it's worth mentioning and added it.

 > 6. Section 2.6 is defined as non-normative, but has a MAY protocol
 > statement in it.  This should be removed.

The following sentence is the offender:

"In order to make the appropriate PC(s) and EEC available for path
validation, the authentication protocol using the PC (e.g. TLS) MAY
pass the entire PC and EEC chain as part of the authentication
protocol."

I don't think this sentence adds anything. I've deleted it.

 > 7.  Section 3.1 - Certificates are not used to sign anything, keys are.
 > Please remove the statement as it does not have anything to do with the
 > Issuer field.

The sentence in question is:

"A Proxy Certificate MUST NOT be used to sign an End Entity
Certificate or a CA Certificate."

Agreed. This is already covered in 2.6 item 2, sentence deleted.

 > 8.  Section 3 - Add the following statement:  "Certificates issued by a
 > Proxy Issuer MUST include the ProxyCertInfo extension and the extension
 > MUST be critical."

I'm concerned here that the sentence above implies that a Proxy Issuer
is something special (akin to a CA). What I have added is:

"All Proxy Certificates MUST include the Proxy Certificate Information
(ProxyCertInfo) extension defined in this section and the extension
MUST be critical."

 > 9.  Section 3.2 - Please justify this section.  I know of know reason
 > why an IssuerAltName should not be allowed in a PC.

There is a good reason why we disallow SubjectAltNames in PC's (see my
response to your issue number #13) and suspect this was a carry over.

Let me push back, is there a valid reason to allow an IssuerAltName in
a PC since the Issuer field must be non-empty (i.e. a Proxy Issuer
must have a non-empty Subject)? If not, I'd prefer to keep it out to
keep path validation simpler.

 > 10.  Section 3.4 - I have a problem with the requirement that a subject
 > be unique.  This means that I cannot issue both a signing PC and an
 > encryption PC to a single proxy agent.  Depending on the algorithm set a
 > single certificiate cannot be used for both operations.

We left this open as an option since the unique name is a SHOULD and
not a MUST. I've rewritten this section to clarify:

3.4	Subject

The subject field of a Proxy Certificate MUST be the issuer field
(that is the subject of the Proxy Issuer) appended with a single
Common Name component.

The value of the Common Name SHOULD be unique to each Proxy
Certificate bearer amongst all Proxy Certificates with the same
issuer.

If a Proxy Issuer issues two proxy certificates to the same bearer,
the Proxy Issuer MAY choose to use the same Common Name for
both. Examples of this include Proxy Certificates for different uses
(e.g. signing vs encryption) or the re-issuance of an expired Proxy
Certificate.

The Proxy Issuer MAY use an approach to assigning Common Name values
that merely ensures a high probability of uniqueness. This value MAY
be the same value used for the serial number.

The result of this approach is that all subject names of Proxy
Certificates are derived from the name of the issuing EEC (it will be
the first part of the subject name appended with one or more CN
components) and be unique to each bearer.

-end new 3.4-

 > 11. Section 3.4 - Is there a desire to be able to determine what subject
 > of the EE that issued the first proxy certificate without having to do
 > the entire chain processing?  This would seem to be difficult by just
 > appending some cn= components to the subject name.

The only way to securely determine the subject of the EE that issued
the first proxy certificate is to process the entire chain since that
is the only way to verify a proxy issuer didn't lie. We considered
adding a short cut but felt that would lead to folks insecurely using
it.

 > 12.  Section 3.5 - Ditto of item 7.  I can see needing to potentially
 > define how to do some conversions, are you just trying to avoid that
 > problem?

(Reference should be item 9 instead of item 7)

The reason for this is that some of the subjectAltName forms are not
hierarchical, so we cannot use our current path validation techniques
to verify the validity of a proxy's SubjectAltName.  This means that
applications will have to locate the EEC to determine things like
e-mail address.

 > 13. Section 3.6 - Signing only certificate cannot issue encrypting
 > certificate.

I believe the third bullet prohibits this.

 > 14.  Section 3.6 - RSA certificate cannot issue DH certificate.

I don't see why this is relevant to 3.6

Question from one of my coauthors:

What this comment seems to be pushing on is whether the signature algorithm 
can change between the issuer and the subject.  I don't see why not.  In 
fact, I can see some value to this, as you might want to secure an EEC with 
a stronger algorithm and key, but use a lighter weight approach for a 
short-lived PC.  We already change the key length.  What's the problem with 
change the algorithm?

 > 15.  Section 3.7 - Cannot omit ALL usages in the extKeyUsage extension.
 > The extension requires one be present.

Changed third item to clarify:

The Proxy Certificate's extKeyUsage extension MAY omit any OID that is
present in the issuer certificate's extKeyUsage. Note that the Proxy
Certificate's extKeyUsage extension MUST contain at least one OID.

 > 16.  Section 3.9 - Please remove the version field from the extension.
 > Changes in structure and behavior should be addressed by issuing a new
 > OID for a new extension.

After soliciting some opinions, I agree with you that this is the
right thing to do.

 > 17.  Section 3.9 - Does a CA have a way to do the equivalent of a
 > pCPathLenConstraint in an EEC?

No. We thought about allowing this at one point by having a boolean
bit in the ProxyCertInfo extension to indicate if it was a proxy. This
would have allowed a CA to put a ProxyCertInfo extension into an EEC
and do this, but it complicated things more than we thought it was
worth.

 > 18.  Section 3.9.3, bullet item #1 - Why does this statement start "If
 > the PC includes a proxy policy..." This is a required field is it not.
 > It would seem that this should be "The relying policy understands the
 > policy specified and correctly interpets the policy data."

Old text that slipped through. Changed to:

1) The relying party MUST know how to interpret the proxy policy and the request is allowed under that policy.

 > 19.  Section 3.9.3, bullet item #2 - This does not seem to be a correct
 > statement, what if the policy is Independent, it would be indepent of
 > the EEC's authorizations.  In such a case the proxy could have MORE
 > abilities that the EEC would imply.

Agreed. Changed to:

2) If the Proxy Issuer is an EEC and the right to perform the
requested action is being inherited from the EEC by the proxy policy,
then the relying party's local policies authorize the request for the
entity named in the EEC.

 > 20.  Section 3.9.3 - Paragraph starting "Note that since..." When I
 > finally got the last sentence parsed, I think I agreed with it.  I would
 > like to see it written in a clearer manner so I don't have read it
 > multiple times to understand it.  
 > 
 > Suggested text - Te rights granted to the bearer of a PC are the union
 > of the rights granted to the PC identity and the inherited rights.  The
 > inherited rights consist of the intersection of the rights granted to
 > the PI identity intersected with the proxy policy in the PC.

I like your text, but I'd like to keep most of the first sentence that
is there. I have changed this paragraph to:

Note that since a proxy certificate has a unique identity it MAY also
have rights granted to it by means other than inheritance from it's
issuer via its proxy policy. The rights granted to the bearer of a PC
are the union of the rights granted to the PC identity and the
inherited rights.  The inherited rights consist of the intersection of
the rights granted to the PI identity intersected with the proxy
policy in the PC.

 > 21.  Section 4 - What about all of the Policy information that was built
 > in the EEC path validation algorithm.  Is this suppose to be passed in
 > or are the extensions not to appear in a PC.

The extensions do not appear in PCs.

 > 22.  Section 4 - This is a standard, it is independent of you "plans"
 > either CRLs are covered by the standard or they are not.  If the are not
 > then that needs to be explicit.  If they are ditto.

Changed last paragrpah of section 4 to:

At this point there is no mechanism defined for revoking proxy
certificates.

 > 23.  Section 4 - policies evalution is messed up big time.  At a minimum
 > you need to put in specialized processing rules for id-ppl-impersonation
 > and possibly for independent as well.  Consider the following:  I ask
 > for a specific policy, I find a PC with with impersonation - according
 > to the rules I must reject the PC chain, but I am sure that is not the
 > desired behavior.

I think you are referring to what happens if the impersonation policy
doesn't appear in the acceptable-pc-policy-set and the you encounter a
proxy with that policy?

In that case, yes it should be a failure, since the relying party
doesn't understand the policy involved. We don't specify currently
that any policy MUST be understood.

In practice I suspect most of the time proxy policies will be ignored
during proxy path validation (i.e. acceptable-pc-policy-set will be
equal to any-policy) and not used until authorization. The
acceptable-pc-policy-set is included in path validation so that a
relying party that handles only inherited rights can fail earlier
rather than later.

 > 24.  Section 4 - How does it help to have the proxy_policy_list as an
 > output of the process?  I would think that I need a list of <subject
 > name,  policy> pairs so that I can go find the extra permissions
 > associated with the subject name.

I agree with this, somehow I was under the impression that the ordered
subject list was also available. I'll add it.

 > 25.  Section 4 - If ACs are to be permitted for anybody other than the
 > leaf PC, this needs to be folded into the validation algorithm.

Can you elaborate on what you mean here?

 > 26. Section 5.4.1 - There is a reference to DelegationTrace extension.

Removed.

 > 27.  ASN Module Problems:
 > 	id-pe is defined twice.

Duplicate removed.

 > 	id-ppl-impersonation and id-ppl-independent do not match the
 > definitions given in the body of the text with regard to naming of
 > either the OID or the last intenger in the oid string.  The version in
 > the ASN.1 file is the correct method of naming.

I'm don't understand, I'm looking at the definitions in 3.9.3 and they
match both in name and value.

 > 	the END statement is missing.

Added.

 > 	id-mod definition can be removed as it is unused.

Removed.

-end-





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31MgVJM026149 for <[e-mail]>; Tue, 1 Apr 2003 14:42:31 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31MgVvZ026148 for ietf-pkix-bks; Tue, 1 Apr 2003 14:42:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31MgUJM026112 for <[e-mail]>; Tue, 1 Apr 2003 14:42:30 -0800 (PST)
Received: from home.ecs.soton.ac.uk (81-86-178-22.dsl.pipex.com [81.86.178.22]) by shockwave.systems.pipex.net (Postfix) with ESMTP id EA762160008A4 for <[e-mail]>; Tue,  1 Apr 2003 23:42:24 +0100 (BST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 01 Apr 2003 23:42:16 +0100
To: <[e-mail]>
From: J Adrian Pickering <[e-mail]>
Subject: RE: TAP (in favor)
In-Reply-To: <001601c2f865$b2bfe120$6401a8c0@phessel>
References: <001601c2f859$d49fb790$477c60cf@CarlsPC>
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 16:45 01/04/2003, you wrote:

>I'll throw my hat into the ring and recommend that PKIX take up the TAP
>spec as a work item.

I'll add my support to this. However, I'm sympathetic to it being spun off 
into an APPS area if this judged appropriate. What must not happen is that 
such applications/interfaces fail to find a home. I think most agree that, 
in principle, TAP is important.

Adrian Pickering/
ECS, University of Southampton, UK




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31LopJM023458 for <[e-mail]>; Tue, 1 Apr 2003 13:50:51 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31LopP0023457 for ietf-pkix-bks; Tue, 1 Apr 2003 13:50:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from vmmr7.verisignmail.com (vmmrnat.verisignmail.com [216.168.230.187]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31LooJM023452 for <[e-mail]>; Tue, 1 Apr 2003 13:50:50 -0800 (PST)
Received: from ms1.verisignmail.com (ms1.verisignmail.com [216.168.230.167] (may be forged)) by vmmr7.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id OTP40701; Tue, 1 Apr 2003 16:38:56 -0500 (EST)
Received: from laptop-cpq.retrospekt.com (1Cust44.tnt1.stk3.swe.da.uu.net [213.116.224.44]) by ms1.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id ACZ30072; Tue, 1 Apr 2003 16:38:54 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]@mail.retrospekt.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 01 Apr 2003 23:38:47 +0200
To: <[e-mail]>, <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RE: TAP  - Yes in a new group
In-Reply-To: <006201c2f87b$768070b0$[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>

The more I think of this, the more I agree with Jim.

Some thoughts...

This either is or is not something that is highly needed and wanted by the 
market, IN THIS FORM. I personally don't know right now.
But if it is, then it seams to me that it applies more to a signature 
infrastructure, than just the Public Key Infrastructure.

And as being useful for non-repudiation, a work group may consider 
solutions that is outside the scope of just X.509 and ASN.1.
E.g. How could XML signatures benefit from this?

/Stefan

At 10:21 2003-04-01 -0800, Jim Schaad wrote:

>I think that TAP is a useful addtion, but I would like to see the PKIX
>group restrict itself to direct issues of what certificates are and how
>to get them and move out of the how to use them field.
>
>jim

_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com
[phone] 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31IL8JM011064 for <[e-mail]>; Tue, 1 Apr 2003 10:21:08 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31IL8uE011063 for ietf-pkix-bks; Tue, 1 Apr 2003 10:21:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31IL6JM011059 for <[e-mail]>; Tue, 1 Apr 2003 10:21:07 -0800 (PST)
Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp1.pacifier.net (Postfix) with ESMTP id 10CE1703F8 for <[e-mail]>; Tue,  1 Apr 2003 10:21:07 -0800 (PST)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>
Subject: RE: TAP  - Yes in a new group
Date: Tue, 1 Apr 2003 10:21:06 -0800
Message-ID: <006201c2f87b$768070b0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think that TAP is a useful addtion, but I would like to see the PKIX
group restrict itself to direct issues of what certificates are and how
to get them and move out of the how to use them field.

jim



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31GxVJM008713 for <[e-mail]>; Tue, 1 Apr 2003 08:59:31 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31GxVfh008712 for ietf-pkix-bks; Tue, 1 Apr 2003 08:59:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31GxTJM008707 for <[e-mail]>; Tue, 1 Apr 2003 08:59:29 -0800 (PST)
Received: from tsg1 (unknown[12.81.121.179]) by mtiwmhc13.worldnet.att.net (mtiwmhc13) with SMTP id <2003040116592311300k7rcpe>; Tue, 1 Apr 2003 16:59:24 +0000
From: "todd glassey" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, "'Stephen Kent'" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: TAP
Date: Tue, 1 Apr 2003 08:58:38 -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.2910.0)
In-Reply-To: <004001c2f7e4$82e19060$ad00a8c0@Chokhani>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
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>

Stephen - TAP is one of the most important things that PKI
and PKIX can undertake and it should be adopted within PKIX
or allowed to flow through PKIX as a sub group. Maybe it has
its own list and is a short termed project???

I cant see any reason for you as the WG Chair to say no to
TAP other than it actually has real deliverables and could
potentially be one of the most important things to come out
of PKIX and the PKI world in many years. And for many of us,
this potentially may be the log that breaks the log-jam in
the PKI marketplace as well.

I believe it is in PKIX's best Interest to allow TAP into
its fold either as an "in-house" project or as a sub
project. Further I think you or the TAP team should define a
set of vetting requirements for it and thus allow us to get
on with this.

If PKIX as a group as enough people that want to work on TAP
then they should be allowed to do that, unless that is this
is a monarchy and not a democracy within the WG.


Todd Glassey

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Santosh
Chokhani
Sent: Monday, March 31, 2003 4:21 PM
To: 'Stephen Kent'; 'Stefan Santesson'
Cc: [e-mail]
Subject: RE: TAP



Steve and Stephan:

The TAP protocol is not about rights to access data.  It is
based on using
PKI to provide long-term non-repudiation of information.

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On
Behalf Of Stephen Kent
Sent: Monday, March 31, 2003 6:01 PM
To: Stefan Santesson
Cc: [e-mail]
Subject: Re: TAP



At 12:27 AM +0200 4/1/03, Stefan Santesson wrote:
>I'm not sure, but is strikes me that the efforts of the
OASIS Rights
>Language TC
http://www.oasis-open.org/committees/rights/charter.php
>might be used as a protocol framework to exercise rights
over
>information and policies/conditions for its archival and
retrieval.
>All supported by PKI based authentications of rights
holders and
>licensees.
>
>It would be interesting if anyone else has more deep
knowledge about
>this.
>
>/Stefan

Well, I would not like to become embroiled in any schemes
that focus
on DRM, or to depend on them for archive.  I think the two
are very
separate functions, and even through there may be functions
in DRM
that make use of archive, I would not want to make use of
trusted
archive depend on adoption of DRM technologies, given the
generally
very negative perception associated with DRM.

Steve




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31FjOJM004850 for <[e-mail]>; Tue, 1 Apr 2003 07:45:24 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31FjOqO004849 for ietf-pkix-bks; Tue, 1 Apr 2003 07:45:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from osf1.gmu.edu (osf1.gmu.edu [129.174.1.13]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31FjMJM004841 for <[e-mail]>; Tue, 1 Apr 2003 07:45:22 -0800 (PST)
Received: from phessel (gemini@[129.174.244.115]) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id KAA329594 for <[e-mail]>; Tue, 1 Apr 2003 10:45:18 -0500 (EST)
Reply-To: <[e-mail]>
From: "Peter Hesse" <[e-mail]>
To: <[e-mail]>
Subject: RE: TAP (in favor)
Date: Tue, 1 Apr 2003 10:45:14 -0500
Organization: Gemini Security Solutions, Inc.
Message-ID: <001601c2f865$b2bfe120$6401a8c0@phessel>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
In-Reply-To: <001601c2f859$d49fb790$477c60cf@CarlsPC>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: 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'll throw my hat into the ring and recommend that PKIX take up the TAP
spec as a work item.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31EKKJM027272 for <[e-mail]>; Tue, 1 Apr 2003 06:20:20 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31EKKDo027271 for ietf-pkix-bks; Tue, 1 Apr 2003 06:20:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31EKJJM027266 for <[e-mail]>; Tue, 1 Apr 2003 06:20:19 -0800 (PST)
Received: from jazzhive.erols.com ([207.96.124.71] helo=CarlsPC) by smtp02.mrf.mail.rcn.net with smtp (Exim 3.35 #4) id 190Mcd-0007Zr-00; Tue, 01 Apr 2003 09:20:20 -0500
Message-ID: <001601c2f859$d49fb790$477c60cf@CarlsPC>
From: "Carl Wallace" <[e-mail]>
To: <[e-mail]>, "Stefan Santesson" <[e-mail]>
References: <[e-mail]>
Subject: Re: TAP (in favor)
Date: Tue, 1 Apr 2003 09:20:17 -0500
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.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: 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 current draft mentions, but does not define, alternative (i.e.
XML-based) submission request formats.  It requires support for ASN.1-based
objects for retrieval/deletion purposes.  Given the relative infrequency of
retrieval operations and the fact that an XML-based retrieval structure
would carry some ASN.1 payloads, this sort of accommodation seems
reasonable.

If the straw poll is still going on, I am in favor of pursuing a trusted
archive spec as a PKIX work item.

Carl

----- Original Message -----
From: "Stefan Santesson" <[e-mail]>
To: <[e-mail]>
Sent: Monday, March 31, 2003 2:34 PM
Subject: Re: TAP


>
> Steve,
>
> Some thoughts and questions, if you could elaborate.
>
> Doesn't this come very close to the aspects of reality that would be
> suitable for OASIS, if it wasn't for the fact that TAP as proposed is
based
> on ASN.1 and not XML.?
>
> Has then PKIX become the body for ASN.1 based application standards for
> anything related to PKI?
> Had this been suitable for PKIX if the proposed protocol was XML based?
>
> /Stefan