Re: I-D ACTION:draft-ietf-pkix-pkixrep-04.txt

[Russ Housley <[e-mail]>]

This was just published last week as an Experimental RFC.  I would 
like to know if people find it useful.

Russ


At 11:55 AM 11/24/2005, Ulf Möller wrote:

>Hello,
>
>We have implemented a client that uses PKIXREP to locate an LDAP service for
>an e-mail address. However I have not found anyone who announces their
>directory in DNS according to this specification.
>
>If there is anyone who does, I'd appreciate a message. It would be nice if
>we could perform some interoperability tests.
>
>The draft doesn't specify the LDAP search base. According to the expired
>draft-ietf-ldapext-locate-08, you would use a DC style distinguished name.
>Am I right in assuming that the same holds for PKIXREP?
>
>Ulf Möller
>
>=======================================
>Secardeo GmbH
>Betastrasse 9a
>85774 Unterfoehring
>GERMANY
>
>Office      [phone]
>Fax         [phone]
>E-mail      [e-mail]
>WWW         http://www.secardeo.com
>=======================================
>





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jARKYrRG048400; Sun, 27 Nov 2005 12:34:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jARKYrlo048399; Sun, 27 Nov 2005 12:34:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id jARKYq02048381 for <[e-mail]>; Sun, 27 Nov 2005 12:34:52 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 30149 invoked by uid 0); 27 Nov 2005 20:34:45 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.159.19) by woodstock.binhost.com with SMTP; 27 Nov 2005 20:34:45 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta)
Date: Fri, 25 Nov 2005 12:58:45 -0500
To: Ulf Möller <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-pkixrep-04.txt
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
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>

This was just published last week as an Experimental RFC.  I would 
like to know if people find it useful.

Russ


At 11:55 AM 11/24/2005, Ulf Möller wrote:

>Hello,
>
>We have implemented a client that uses PKIXREP to locate an LDAP service for
>an e-mail address. However I have not found anyone who announces their
>directory in DNS according to this specification.
>
>If there is anyone who does, I'd appreciate a message. It would be nice if
>we could perform some interoperability tests.
>
>The draft doesn't specify the LDAP search base. According to the expired
>draft-ietf-ldapext-locate-08, you would use a DC style distinguished name.
>Am I right in assuming that the same holds for PKIXREP?
>
>Ulf Möller
>
>===================>Secardeo GmbH
>Betastrasse 9a
>85774 Unterfoehring
>GERMANY
>
>Office      [phone]
>Fax         [phone]
>E-mail      [e-mail]
>WWW         http://www.secardeo.com
>===================>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAOGtsst082884; Thu, 24 Nov 2005 08:55:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAOGtstY082883; Thu, 24 Nov 2005 08:55:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAOGtqbd082877 for <[e-mail]>; Thu, 24 Nov 2005 08:55:52 -0800 (PST) (envelope-from [e-mail])
Received: from [85.233.34.84] (helo=secmoe) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1EfKNp2HP2-0000vm; Thu, 24 Nov 2005 17:55:51 +0100
From: =?iso-8859-1?Q?Ulf_Möller?= <[e-mail]>
To: <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-pkixrep-04.txt
Date: Thu, 24 Nov 2005 17:55:41 +0100
Organization: Secardeo GmbH
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-index: AcXxF+bewJe6tKb9SMmRxP25DqHJeg=
Message-ID: <[e-mail]>
X-Provags-ID: kundenserver.de [e-mail] login:0f127e19937015e7b75cb484ac44fc0e
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id jAOGtrbd082878
Sender: [e-mail]
Precedence: 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,

We have implemented a client that uses PKIXREP to locate an LDAP service for
an e-mail address. However I have not found anyone who announces their
directory in DNS according to this specification.

If there is anyone who does, I'd appreciate a message. It would be nice if
we could perform some interoperability tests.

The draft doesn't specify the LDAP search base. According to the expired
draft-ietf-ldapext-locate-08, you would use a DC style distinguished name.
Am I right in assuming that the same holds for PKIXREP?

Ulf Möller

===================Secardeo GmbH
Betastrasse 9a
85774 Unterfoehring
GERMANY

Office      [phone]
Fax         [phone]
E-mail      [e-mail]
WWW         http://www.secardeo.com
=================== 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAMIKovb002106; Tue, 22 Nov 2005 10:20:50 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAMIKoFO002105; Tue, 22 Nov 2005 10:20:50 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAMIKl8W002094 for <[e-mail]>; Tue, 22 Nov 2005 10:20:47 -0800 (PST) (envelope-from [e-mail])
Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1Eecl2-0002vn-09; Tue, 22 Nov 2005 13:20:44 -0500
X-test-idtracker: no
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>, pkix mailing list <[e-mail]>, pkix chair <[e-mail]>, pkix chair <[e-mail]>
Subject: Document Action: 'Internet X.509 Public Key Infrastructure  Repository Locator Service' to Experimental RFC 
Message-Id: <[e-mail]>
Date: Tue, 22 Nov 2005 13:20:44 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has approved the following document:

- 'Internet X.509 Public Key Infrastructure Repository Locator Service '
   <draft-ietf-pkix-pkixrep-04.txt> as an Experimental RFC

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

The IESG contact persons are Russ Housley and Sam Hartman.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-pkixrep-04.txt

Technical Summary

  This document defines a PKI repository locator service.  The service
  makes use of DNS SRV records defined in accordance with RFC 2782.  The
  service enables certificate using systems to locate PKI repositories
  based on a domain name, identify the protocols that can be used to
  access the repository, and obtain addresses for the servers that host
  the repository service.

Working Group Summary

  The PKIX Working Group came to consensus on this document.

Protocol Quality

  This document was reviewed by Russell Housley for the IESG.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAIKwaMX046037; Fri, 18 Nov 2005 12:58:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAIKwalS046036; Fri, 18 Nov 2005 12:58:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAIKwZ8H046024 for <[e-mail]>; Fri, 18 Nov 2005 12:58:35 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id jAIKwFIC025074; Fri, 18 Nov 2005 15:58:16 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p06230910bfa3f0575619@[128.89.89.106]>
In-Reply-To: <[e-mail]>
References: <002d01c5ebc4$1f97da10$0301a8c0@Wylie> <[e-mail]> <01c101c5ec3d$f322c6f0$[e-mail]> <p06230909bfa3d6fe650c@[128.89.89.106]> <[e-mail]>
Date: Fri, 18 Nov 2005 15:56:53 -0500
To: Blake Ramsdell <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: WG LAST CALL: draft-ietf-smime-gost-05.txt
Cc: "Gregory S. Chudov" <[e-mail]>, <[e-mail]>, <[e-mail]>, "Sean Turner" <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: 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 11:14 AM -0800 11/18/05, Blake Ramsdell wrote:
>On Nov 18, 2005, at 11:09 AM, Stephen Kent wrote:
>>Sorry. What I meant to say in my previous message was that I 
>>requested that a fresh (vs. expired) copy of the I-D in question be 
>>posted, so that we could initiate last call in PKIX.  Please you 
>>provide a URL for that copy.
>
>Just to make sure we're talking about the same document -- I'm 
>talking about draft-ietf-pkix-gost-cppk-03

Yes, that I-D is OK.  I will initiate WG last call on it.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAIKwOcY046015; Fri, 18 Nov 2005 12:58:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAIKwOvl046014; Fri, 18 Nov 2005 12:58:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAIKwNkF045995 for <[e-mail]>; Fri, 18 Nov 2005 12:58:23 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id jAIKwFIE025074 for <[e-mail]>; Fri, 18 Nov 2005 15:58:17 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p06230911bfa3f0a16767@[128.89.89.106]>
Date: Fri, 18 Nov 2005 15:58:41 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Last Call
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I am initiating last call on:  draft-ietf-pkix-gost-cppk-03.txt, an 
I-D targeted as INFORMATIONAL.

Please provides comments to the list between now and the end of the month.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAIJFTqb036771; Fri, 18 Nov 2005 11:15:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAIJFT3q036770; Fri, 18 Nov 2005 11:15:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-out.sendmail.com (smtp-out.sendmail.com [209.246.26.45]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAIJFSwQ036764 for <[e-mail]>; Fri, 18 Nov 2005 11:15:29 -0800 (PST) (envelope-from [e-mail])
Received: from [192.168.0.3] (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) (authenticated bits=0) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jAIJEsMV007213 (version=TLSv1/SSLv3 cipher=RC4-SHA bits8 verify=NO); Fri, 18 Nov 2005 11:14:55 -0800
X-DKIM: Sendmail DKIM Filter v0.1.1 foon.sendmail.com jAIJEsMV007213
DKIM-Signature: a=rsa-sha1; c=nowsp; d=sendmail.com; s=tls.dkim; t32341296; h=X-DomainKeys:DomainKey-Signature:In-Reply-To: References:Mime-Version:Content-Type:Message-Id:Cc: Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer: X-ok-sendmail.com; b=g3GZf2Dj9RK6sVY8E1XvQmIGKEdAsozz8EdaGCDwozqE6e 3XW3evnuuRtV9hbDBRx+/l2ZBk9kiLp25HV0eriG2/zpiAV5HN1zPOyCoq6epwjD2X3 InUGOJ1JrksbCpW1Dx2SUH+8SHPh0N2ChAJ2sUq9Y/zYeAf7t/cVJ2L9+kX-DomainKeys: Sendmail DomainKeys Filter v0.3.0 foon.sendmail.com jAIJEsMV007213
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=in-reply-to:references:mime-version:content-type:message-id:cc: content-transfer-encoding:from:subject:date:to:x-mailer:x-ok-sendmail.com; b=CibQhxUFeWnt/zQbhp20kPpLwsLVGpnNqQoRMkUmLmt4TY1zaDThfAnE8xHLdCb8n niXYCS0GtxPEsPDfaOMT6JRtb4P3vLI7ukgoUN9j/XEJ9m+hcrogpN0r/x4x1M2jaQA T5rctA41gmLsxtyamfkTmRCKNvLksg4YXqUxnzkIn-Reply-To: <p06230909bfa3d6fe650c@[128.89.89.106]>
References: <002d01c5ebc4$1f97da10$0301a8c0@Wylie> <[e-mail]> <01c101c5ec3d$f322c6f0$[e-mail]> <p06230909bfa3d6fe650c@[128.89.89.106]>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: "Gregory S. Chudov" <[e-mail]>, <[e-mail]>, <[e-mail]>, "Sean Turner" <[e-mail]>, <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Blake Ramsdell <[e-mail]>
Subject: Re: WG LAST CALL: draft-ietf-smime-gost-05.txt
Date: Fri, 18 Nov 2005 11:14:54 -0800
To: Stephen Kent <[e-mail]>
X-Mailer: Apple Mail (2.746.2)
X-ok-sendmail.com: Yes
Sender: [e-mail]
Precedence: 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 Nov 18, 2005, at 11:09 AM, Stephen Kent wrote:
> Sorry. What I meant to say in my previous message was that I  
> requested that a fresh (vs. expired) copy of the I-D in question be  
> posted, so that we could initiate last call in PKIX.  Please you  
> provide a URL for that copy.

Just to make sure we're talking about the same document -- I'm  
talking about draft-ietf-pkix-gost-cppk-03

https://datatracker.ietf.org/public/idindex.cgi? 
command=id_detail&id620

http://www.ietf.org/internet-drafts/draft-ietf-pkix-gost-cppk-03.txt

Which points to a draft submitted on 9/9 and expires March, 2006. The  
draft announcement to the PKIX list is here:

http://www.imc.org/ietf-pkix/mail-archive/msg02783.html

Blake
--
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAIJA6p7036309; Fri, 18 Nov 2005 11:10:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAIJA6QE036308; Fri, 18 Nov 2005 11:10:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAIJA56A036284 for <[e-mail]>; Fri, 18 Nov 2005 11:10:06 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id jAIJ9OIG018491; Fri, 18 Nov 2005 14:09:32 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p06230909bfa3d6fe650c@[128.89.89.106]>
In-Reply-To: <01c101c5ec3d$f322c6f0$[e-mail]>
References: <002d01c5ebc4$1f97da10$0301a8c0@Wylie> <[e-mail]> <01c101c5ec3d$f322c6f0$[e-mail]>
Date: Fri, 18 Nov 2005 14:09:50 -0500
To: "Gregory S. Chudov" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: WG LAST CALL: draft-ietf-smime-gost-05.txt
Cc: <[e-mail]>, "Blake Ramsdell" <[e-mail]>, <[e-mail]>, "Sean Turner" <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>Greetings.
>
>We are ready for last call on gost-cppk too.
>
Sorry. What I meant to say in my previous message was that I 
requested that a fresh (vs. expired) copy of the I-D in question be 
posted, so that we could initiate last call in PKIX.  Please you 
provide a URL for that copy.

Thanks,

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAIGnOf5023523; Fri, 18 Nov 2005 08:49:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAIGnOoS023522; Fri, 18 Nov 2005 08:49:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAIGnId3023511 for <[e-mail]>; Fri, 18 Nov 2005 08:49:23 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id jAIGlxIC009709; Fri, 18 Nov 2005 11:47:59 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p06230905bfa3b1f3b695@[128.89.89.106]>
In-Reply-To: <01c101c5ec3d$f322c6f0$[e-mail]>
References: <002d01c5ebc4$1f97da10$0301a8c0@Wylie> <[e-mail]> <01c101c5ec3d$f322c6f0$[e-mail]>
Date: Fri, 18 Nov 2005 11:48:25 -0500
To: "Gregory S. Chudov" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: WG LAST CALL: draft-ietf-smime-gost-05.txt
Cc: <[e-mail]>, <[e-mail]>, "Blake Ramsdell" <[e-mail]>, <[e-mail]>, "Sean Turner" <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: 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:45 PM +0300 11/18/05, Gregory S. Chudov wrote:
>Greetings.
>
>We are ready for last call on gost-cppk too.
>

I sent a message



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAIGOfqf021793; Fri, 18 Nov 2005 08:24:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAIGOfPX021792; Fri, 18 Nov 2005 08:24:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAIGOeMg021784 for <[e-mail]>; Fri, 18 Nov 2005 08:24:40 -0800 (PST) (envelope-from [e-mail])
Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 17:24:38 +0100
Received: from [10.193.203.220] ([10.193.203.220]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 17:24:38 +0100
Message-ID: <[e-mail]>
Date: Fri, 18 Nov 2005 17:24:37 +0100
From: David Lefranc <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Certificates and Blind Signatures
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 Nov 2005 16:24:38.0330 (UTC) FILETIME=[922A01A0:01C5EC5C]
Sender: [e-mail]
Precedence: 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 would like to use a blind RSA signature algorithm, and I am currently 
analyzing the best way to use X509 certificates : I need to precise that 
the public key will be used with such an algorithm.

The easiest solution would be to create a new algorithmIdentifier 
identifying the Blind RSA signature algorithm so that I could use it in 
the field subjectPublicKeyInfo.
However, since blind RSA signature and classical signature algorithms 
are quite similar, I think a better solution would be the following :

1. Keep the algorithmIdentifier for the classical RSA signature 
algorithm in the field subjectPublicKeyInfo.
2. Do not use the Key Usage extension.
3. Use the Extended Key Usage extension, set it as "non critical", and 
create a new KeyPurposeId for "blind signature", (and also eventually 
precise DigitalSignature and NonRepudiation).

With this second solution, the system for blind RSA signatures that I 
develop SHOULD require such certificates, and the certificates could 
also be used in a classical way outside my system to perform classical  
RSA signatures.

Does it seem reasonable?

David



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAIChCST096280; Fri, 18 Nov 2005 04:43:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAIChCCB096279; Fri, 18 Nov 2005 04:43:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mx2.cryptopro.ru (mx2.cryptopro.ru [213.59.158.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAIChAxa096268 for <[e-mail]>; Fri, 18 Nov 2005 04:43:11 -0800 (PST) (envelope-from [e-mail])
Received: from fandra2k ([192.168.68.6]) by mx2.cryptopro.ru with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Nov 2005 15:45:26 +0300
Message-ID: <01c101c5ec3d$f322c6f0$[e-mail]>
From: "Gregory S. Chudov" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: "Blake Ramsdell" <[e-mail]>, <[e-mail]>, "Sean Turner" <[e-mail]>, <[e-mail]>
References: <002d01c5ebc4$1f97da10$0301a8c0@Wylie> <[e-mail]>
Subject: Re: WG LAST CALL: draft-ietf-smime-gost-05.txt
Date: Fri, 18 Nov 2005 15:45:26 +0300
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.1830
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830
X-OriginalArrivalTime: 18 Nov 2005 12:45:26.0640 (UTC) FILETIME=[F3255F00:01C5EC3D]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Greetings.

We are ready for last call on gost-cppk too.

----- Original Message ----- 
From: "Blake Ramsdell" <[e-mail]>
To: <[e-mail]>; "Sean Turner" <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
Sent: Friday, November 18, 2005 2:04 AM
Subject: Re: WG LAST CALL: draft-ietf-smime-gost-05.txt


> 
> On Nov 17, 2005, at 2:13 PM, Turner, Sean P. wrote:
>> PS there is a companion GOST documents in PKIX
>> (http://ietf.org/internet-drafts/draft-ietf-pkix-gost-cppk-03.txt)  
>> and in
>> RFC editor's queue
>> (ftp://ftp.isi.edu/internet-drafts/draft-popov-cryptopro- 
>> cpalgs-04.txt).
> 
> Are we going to run into another CMC / symkeydist situation here?  
> That is, is gost-cppk going to get stuck for any reason in PKIX? I  
> note that the last draft revision is 9/9/05 and I did not see  
> anything to indicate that there is active discussion about this draft  
> on the PKIX list.
> 
> Just firing a warning shot that cppk is a normative reference that  
> will need to progress through PKIX before gost-05 can complete.  
> Authors -- can you give a quick status update about this?
> 
> cpalgs looks pretty frictionless -- no missing normative references,  
> and in the editor's queue.
> 
> Blake
> --
> Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com
> 
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF05OF7061905; Mon, 14 Nov 2005 16:05:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAF05Ojc061904; Mon, 14 Nov 2005 16:05:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhub1.dartmouth.edu (mailhub1.dartmouth.edu [129.170.16.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF05NGI061894 for <[e-mail]>; Mon, 14 Nov 2005 16:05:24 -0800 (PST) (envelope-from [e-mail])
Received: from [129.170.212.213] (dhcp-212-213.cs.dartmouth.edu [129.170.212.213]) by mailhub1.dartmouth.edu (8.13.5/DND2.0/8.13.5) with ESMTP id jAF05HAT018383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=OK) for <[e-mail]>; Mon, 14 Nov 2005 19:05:19 -0500
Message-ID: <[e-mail]>
Date: Mon, 14 Nov 2005 19:05:52 -0500
From: Massimiliano Pala <[e-mail]>
Organization: Dartmouth College
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Re: RFC-3280 [Subject Information Access]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090706050508090406040208"
X-MailScanner: Found to be clean by mailhub.Dartmouth.EDU
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms090706050508090406040208
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

David A. Cooper wrote:
> Massimiliano,
> 
> At the moment, there is no way to accomplish what you are trying to do 
> in general.

:-(

> I should begin by pointing out that the text that you quoted from RFC 
> 3280 has been changed in 3280bis so that it no longer mentions CRLs:
> 
>   The id-ad-caRepository OID is used when the subject is a CA, and
>   publishes certificates it issues in a repository.  The accessLocation
>   field is defined as a GeneralName, which can take several forms.

So in 3280bis this will not provide a generalized pointer to certs AND
CRLs but only to certs repositories, right ?

> If a CA issues full CRLs then what you are trying to accomplish may be 
> possible.  If the CA makes its certificates and CRLs available in a 
[...]
> certificates could not be updated to add these new segments.

Is there any chance we can define a `SubjectRevocationAccess' extension
that will point to revocation informations provided by the Subject of the
certificate it appears in ? Is a bad idea ? Could it be added to the
3280bis ?

Thanks to all for any comment/support!

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]            [e-mail]
                                                   [e-mail]

Dartmouth Computer Science Dept               Home Phone: [phone]
PKI/Trust - Office 062                        Work Phone: [phone]
--o------------------------------------------------------------------------

--------------ms090706050508090406040208
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJIjCC
BI0wggN1oAMCAQICAhpTMA0GCSqGSIb3DQEBBQUAMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUx
GTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0
bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMTAeFw0wNTExMDgy
MDMzMDZaFw0wOTExMDkyMDMzMDZaMIHBMRMwEQYKCZImiZPyLGQBGRYDZWR1MRkwFwYKCZIm
iZPyLGQBGRYJZGFydG1vdXRoMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1vdXRoIENv
bGxlZ2UxGjAYBgoJkiaJk/IsZAEBEwoxMjI1NjAyOTQ3MRowGAYDVQQDExFNYXNzaW1pbGlh
bm8gUGFsYTEuMCwGCSqGSIb3DQEJARYfTWFzc2ltaWxpYW5vLlBhbGFARGFydG1vdXRoLmVk
dTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAsv8obBpbhPixgdyIJj7UN0GYRNhsgWHB
muCE5j8v8IvCSJWRF9spKoR0NBYgOfJu8DwQuKTIgrvbp0EC3ikrneotL4KTGD1IqWz/bSXL
UR/bZAsc0r9PrvCUsZOi7wbijy784gOuqQUCJ2fJwKwk5SJ3RBaPnUROQXTp+LPSK8MCAwEA
AaOCAVowggFWMA4GA1UdDwEB/wQEAwIF4DARBglghkgBhvhCAQEEBAMCBaAwgaIGA1UdIASB
mjCBlzCBlAYKKwYBBAFBAgEBATCBhTA9BggrBgEFBQcCAjAxMBgWEURhcnRtb3V0aCBDb2xs
ZWdlMAMCAQEaFURhcnRtb3V0aCBDb2xsZWdlIENQUzBEBggrBgEFBQcCARY4aHR0cDovL3d3
dy5kYXJ0bW91dGguZWR1L35wa2lsYWIvRGFydG1vdXRoQ1BTXzRTZXAwMy5wZGYwKgYDVR0R
BCMwIYEfTWFzc2ltaWxpYW5vLlBhbGFARGFydG1vdXRoLmVkdTAfBgNVHSMEGDAWgBQ/wNbH
p08Afu8GmWdsvJYeTaN3EjA/BggrBgEFBQcBAQQzMDEwLwYIKwYBBQUHMAGGI2h0dHA6Ly9j
b2xsZWdlY2EuZGFydG1vdXRoLmVkdS9vY3NwMA0GCSqGSIb3DQEBBQUAA4IBAQDEYIWmG3Ht
wcgFiBbrYKp7YpI62hgAw9I3Dj9Ai+etQcMDZL8cWg3Kd7DwYHDkLxO7jl518HIJCk8Elk+Z
3Y2c0rR+c9WLuxE+EHEUmQg2AbgxzRGZAeMXj7jrv5w75IWiXBrW3SdDkjVH6MQFZVP1CBk7
PF3/+dzmiO6E5g4cVtphPSdK2qtnX7Sh0zdePzeE+e0BTnsWdN0yHgKabKx3dCiEnQXt96sA
Jf5ckg7fFLcplohwWlWJCpk8WwnJM0QGw3xbrZvLk+kIQgyh0sn2va4FgA1ae29cJ1d2NurA
Z+LMdei9/ZbzBeMoD9XPSYyj7zLuVXGLF/JQQoPywk5oMIIEjTCCA3WgAwIBAgICGlMwDQYJ
KoZIhvcNAQEFBQAwdzETMBEGCgmSJomT8ixkARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRh
cnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYD
VQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTA1MTEwODIwMzMwNloXDTA5MTEwOTIwMzMw
NlowgcExEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgx
CzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEaMBgGCgmSJomT8ixk
AQETCjEyMjU2MDI5NDcxGjAYBgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMS4wLAYJKoZIhvcN
AQkBFh9NYXNzaW1pbGlhbm8uUGFsYUBEYXJ0bW91dGguZWR1MIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQCy/yhsGluE+LGB3IgmPtQ3QZhE2GyBYcGa4ITmPy/wi8JIlZEX2ykqhHQ0
FiA58m7wPBC4pMiCu9unQQLeKSud6i0vgpMYPUipbP9tJctRH9tkCxzSv0+u8JSxk6LvBuKP
LvziA66pBQInZ8nArCTlIndEFo+dRE5BdOn4s9IrwwIDAQABo4IBWjCCAVYwDgYDVR0PAQH/
BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIFoDCBogYDVR0gBIGaMIGXMIGUBgorBgEEAUECAQEB
MIGFMD0GCCsGAQUFBwICMDEwGBYRRGFydG1vdXRoIENvbGxlZ2UwAwIBARoVRGFydG1vdXRo
IENvbGxlZ2UgQ1BTMEQGCCsGAQUFBwIBFjhodHRwOi8vd3d3LmRhcnRtb3V0aC5lZHUvfnBr
aWxhYi9EYXJ0bW91dGhDUFNfNFNlcDAzLnBkZjAqBgNVHREEIzAhgR9NYXNzaW1pbGlhbm8u
UGFsYUBEYXJ0bW91dGguZWR1MB8GA1UdIwQYMBaAFD/A1senTwB+7waZZ2y8lh5No3cSMD8G
CCsGAQUFBwEBBDMwMTAvBggrBgEFBQcwAYYjaHR0cDovL2NvbGxlZ2VjYS5kYXJ0bW91dGgu
ZWR1L29jc3AwDQYJKoZIhvcNAQEFBQADggEBAMRghaYbce3ByAWIFutgqntikjraGADD0jcO
P0CL561BwwNkvxxaDcp3sPBgcOQvE7uOXnXwcgkKTwSWT5ndjZzStH5z1Yu7ET4QcRSZCDYB
uDHNEZkB4xePuOu/nDvkhaJcGtbdJ0OSNUfoxAVlU/UIGTs8Xf/53OaI7oTmDhxW2mE9J0ra
q2dftKHTN14/N4T57QFOexZ03TIeAppsrHd0KISdBe33qwAl/lySDt8UtymWiHBaVYkKmTxb
CckzRAbDfFutm8uT6QhCDKHSyfa9rgWADVp7b1wnV3Y26sBn4sx16L39lvMF4ygP1c9JjKPv
Mu5VcYsX8lBCg/LCTmgxggL4MIIC9AIBATB9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAX
BgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91
dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwCQYFKw4DAhoF
AKCCAdEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMTE1
MDAwNTUyWjAjBgkqhkiG9w0BCQQxFgQUqz2IMZzTIcBxAeaOiGGy0mdzZIYwUgYJKoZIhvcN
AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF
Kw4DAgcwDQYIKoZIhvcNAwICASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixk
ARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNV
BAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgIa
UzCBjgYLKoZIhvcNAQkQAgsxf6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJ
k/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29s
bGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwDQYJKoZIhvcNAQEBBQAE
gYCbgc5gINjXwvThvuUyllLPvZ44cthg+crGW2TIXp1ze5QyXcsMpMcdFIzhEC1K+FQYJi40
zkmUytjpmrJi6JuK7m+MlALiYTZa+y8S1auWRc1ichd6W8YRiPfFJ/bRH7+yJyxJdVwH5YcG
ETXO4AFKSfSaG+olH+OdLCSnsmTymAAAAAAAAA=
--------------ms090706050508090406040208--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAENvWjN060888; Mon, 14 Nov 2005 15:57:32 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAENvWwa060887; Mon, 14 Nov 2005 15:57:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhub1.dartmouth.edu (mailhub1.dartmouth.edu [129.170.16.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAENvUc8060880 for <[e-mail]>; Mon, 14 Nov 2005 15:57:31 -0800 (PST) (envelope-from [e-mail])
Received: from [129.170.212.213] (dhcp-212-213.cs.dartmouth.edu [129.170.212.213]) by mailhub1.dartmouth.edu (8.13.5/DND2.0/8.13.5) with ESMTP id jAENvPl5017403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=OK) for <[e-mail]>; Mon, 14 Nov 2005 18:57:27 -0500
Message-ID: <[e-mail]>
Date: Mon, 14 Nov 2005 18:57:55 -0500
From: Massimiliano Pala <[e-mail]>
Organization: Dartmouth College
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Re: RFC-3280 [Subject Information Access]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000800070606020107080508"
X-MailScanner: Found to be clean by mailhub.Dartmouth.EDU
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms000800070606020107080508
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Russ Housley wrote:
> SIA could be used to provide the pointer that you seek, but I do not 
> think that anyone uses it that way.  In fact, I suspect that a document 

That was my original point, but I do agree no one is actually using it
in this way...

> would need to be written to tell people how to do it in an interoperable 
> way.  If you want to pursue that, you would need to write an 
> internet-draft and convince the PKIX WG that it wants to adopt it as a 
> work item.

Now the next step is to understand if this could be useful in real environments
or not... well, obviously I think so, but I would like to have other opinions
about this.

Thanks for the answer!

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]            [e-mail]
                                                  [e-mail]

Dartmouth Computer Science Dept               Home Phone: [phone]
PKI/Trust - Office 062                        Work Phone: [phone]
--o------------------------------------------------------------------------

--------------ms000800070606020107080508
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJIjCC
BI0wggN1oAMCAQICAhpTMA0GCSqGSIb3DQEBBQUAMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUx
GTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0
bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMTAeFw0wNTExMDgy
MDMzMDZaFw0wOTExMDkyMDMzMDZaMIHBMRMwEQYKCZImiZPyLGQBGRYDZWR1MRkwFwYKCZIm
iZPyLGQBGRYJZGFydG1vdXRoMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1vdXRoIENv
bGxlZ2UxGjAYBgoJkiaJk/IsZAEBEwoxMjI1NjAyOTQ3MRowGAYDVQQDExFNYXNzaW1pbGlh
bm8gUGFsYTEuMCwGCSqGSIb3DQEJARYfTWFzc2ltaWxpYW5vLlBhbGFARGFydG1vdXRoLmVk
dTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAsv8obBpbhPixgdyIJj7UN0GYRNhsgWHB
muCE5j8v8IvCSJWRF9spKoR0NBYgOfJu8DwQuKTIgrvbp0EC3ikrneotL4KTGD1IqWz/bSXL
UR/bZAsc0r9PrvCUsZOi7wbijy784gOuqQUCJ2fJwKwk5SJ3RBaPnUROQXTp+LPSK8MCAwEA
AaOCAVowggFWMA4GA1UdDwEB/wQEAwIF4DARBglghkgBhvhCAQEEBAMCBaAwgaIGA1UdIASB
mjCBlzCBlAYKKwYBBAFBAgEBATCBhTA9BggrBgEFBQcCAjAxMBgWEURhcnRtb3V0aCBDb2xs
ZWdlMAMCAQEaFURhcnRtb3V0aCBDb2xsZWdlIENQUzBEBggrBgEFBQcCARY4aHR0cDovL3d3
dy5kYXJ0bW91dGguZWR1L35wa2lsYWIvRGFydG1vdXRoQ1BTXzRTZXAwMy5wZGYwKgYDVR0R
BCMwIYEfTWFzc2ltaWxpYW5vLlBhbGFARGFydG1vdXRoLmVkdTAfBgNVHSMEGDAWgBQ/wNbH
p08Afu8GmWdsvJYeTaN3EjA/BggrBgEFBQcBAQQzMDEwLwYIKwYBBQUHMAGGI2h0dHA6Ly9j
b2xsZWdlY2EuZGFydG1vdXRoLmVkdS9vY3NwMA0GCSqGSIb3DQEBBQUAA4IBAQDEYIWmG3Ht
wcgFiBbrYKp7YpI62hgAw9I3Dj9Ai+etQcMDZL8cWg3Kd7DwYHDkLxO7jl518HIJCk8Elk+Z
3Y2c0rR+c9WLuxE+EHEUmQg2AbgxzRGZAeMXj7jrv5w75IWiXBrW3SdDkjVH6MQFZVP1CBk7
PF3/+dzmiO6E5g4cVtphPSdK2qtnX7Sh0zdePzeE+e0BTnsWdN0yHgKabKx3dCiEnQXt96sA
Jf5ckg7fFLcplohwWlWJCpk8WwnJM0QGw3xbrZvLk+kIQgyh0sn2va4FgA1ae29cJ1d2NurA
Z+LMdei9/ZbzBeMoD9XPSYyj7zLuVXGLF/JQQoPywk5oMIIEjTCCA3WgAwIBAgICGlMwDQYJ
KoZIhvcNAQEFBQAwdzETMBEGCgmSJomT8ixkARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRh
cnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYD
VQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTA1MTEwODIwMzMwNloXDTA5MTEwOTIwMzMw
NlowgcExEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgx
CzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEaMBgGCgmSJomT8ixk
AQETCjEyMjU2MDI5NDcxGjAYBgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMS4wLAYJKoZIhvcN
AQkBFh9NYXNzaW1pbGlhbm8uUGFsYUBEYXJ0bW91dGguZWR1MIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQCy/yhsGluE+LGB3IgmPtQ3QZhE2GyBYcGa4ITmPy/wi8JIlZEX2ykqhHQ0
FiA58m7wPBC4pMiCu9unQQLeKSud6i0vgpMYPUipbP9tJctRH9tkCxzSv0+u8JSxk6LvBuKP
LvziA66pBQInZ8nArCTlIndEFo+dRE5BdOn4s9IrwwIDAQABo4IBWjCCAVYwDgYDVR0PAQH/
BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIFoDCBogYDVR0gBIGaMIGXMIGUBgorBgEEAUECAQEB
MIGFMD0GCCsGAQUFBwICMDEwGBYRRGFydG1vdXRoIENvbGxlZ2UwAwIBARoVRGFydG1vdXRo
IENvbGxlZ2UgQ1BTMEQGCCsGAQUFBwIBFjhodHRwOi8vd3d3LmRhcnRtb3V0aC5lZHUvfnBr
aWxhYi9EYXJ0bW91dGhDUFNfNFNlcDAzLnBkZjAqBgNVHREEIzAhgR9NYXNzaW1pbGlhbm8u
UGFsYUBEYXJ0bW91dGguZWR1MB8GA1UdIwQYMBaAFD/A1senTwB+7waZZ2y8lh5No3cSMD8G
CCsGAQUFBwEBBDMwMTAvBggrBgEFBQcwAYYjaHR0cDovL2NvbGxlZ2VjYS5kYXJ0bW91dGgu
ZWR1L29jc3AwDQYJKoZIhvcNAQEFBQADggEBAMRghaYbce3ByAWIFutgqntikjraGADD0jcO
P0CL561BwwNkvxxaDcp3sPBgcOQvE7uOXnXwcgkKTwSWT5ndjZzStH5z1Yu7ET4QcRSZCDYB
uDHNEZkB4xePuOu/nDvkhaJcGtbdJ0OSNUfoxAVlU/UIGTs8Xf/53OaI7oTmDhxW2mE9J0ra
q2dftKHTN14/N4T57QFOexZ03TIeAppsrHd0KISdBe33qwAl/lySDt8UtymWiHBaVYkKmTxb
CckzRAbDfFutm8uT6QhCDKHSyfa9rgWADVp7b1wnV3Y26sBn4sx16L39lvMF4ygP1c9JjKPv
Mu5VcYsX8lBCg/LCTmgxggL4MIIC9AIBATB9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAX
BgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91
dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwCQYFKw4DAhoF
AKCCAdEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMTE0
MjM1NzU1WjAjBgkqhkiG9w0BCQQxFgQUlO3CIcC7V6k0gys/B81+fUJOoiQwUgYJKoZIhvcN
AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF
Kw4DAgcwDQYIKoZIhvcNAwICASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixk
ARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNV
BAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgIa
UzCBjgYLKoZIhvcNAQkQAgsxf6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJ
k/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29s
bGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwDQYJKoZIhvcNAQEBBQAE
gYAQS61tO0loQw2xnaeTsUZm8GS4+3m67bZSiVw23jlTTKkhFs3YgIJbAWzdO34wDw4Wxnqc
5s9nBVsOnakHiPWIMpKJiLz+R+8JTVO+Y1RRPVh7bJncsJnqS7a5ZSjN8Q773jAlPCffimJn
+c0gv5ZKPOHlThZDfhpD34pXELjsRwAAAAAAAA=
--------------ms000800070606020107080508--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAEML8PV047679; Mon, 14 Nov 2005 14:21:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAEML8rD047678; Mon, 14 Nov 2005 14:21:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAEML7qn047672 for <[e-mail]>; Mon, 14 Nov 2005 14:21:08 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (static-70-21-114-242.res.east.verizon.net [70.21.114.242]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id jAEML5wp015456 for <[e-mail]>; Mon, 14 Nov 2005 17:21:07 -0500
From: "Santosh Chokhani" <[e-mail]>
To: "'pkix'" <[e-mail]>
Subject: RE: RFC-3280 [Subject Information Access]
Date: Mon, 14 Nov 2005 17:20:59 -0500
Message-ID: <018701c5e969$b459d070$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <[e-mail]>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id jAEML8qn047673
Sender: [e-mail]
Precedence: 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 are several issues like this for CA -- OCSP Responder communication
that are not covered by 2560 and could stand some guidance or
standardization in a new I-D or revision of 2560.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Russ Housley
Sent: Monday, November 14, 2005 2:16 PM
To: Massimiliano Pala
Cc: pkix
Subject: Re: RFC-3280 [Subject Information Access]



SIA could be used to provide the pointer that you seek, but I do not 
think that anyone uses it that way.  In fact, I suspect that a 
document would need to be written to tell people how to do it in an 
interoperable way.  If you want to pursue that, you would need to 
write an internet-draft and convince the PKIX WG that it wants to 
adopt it as a work item.

Russ

At 01:51 PM 11/14/2005, Massimiliano Pala wrote:
>Hi Russ,
>
>thank for the answer, but probably due to my bad english I was not 
>really clear... my situation is this:
>
>- I have an OCSP server and I want it to be able to "auto" configure the
>   downloading of CRLs, provided some pointer is given in the CA cert for
>   its own certs, this is:
>
>         * I have only CA2 cert
>
>         * I want to access CRLs issued by CA2
>
>         * No other info is given to the server besides the CA2 cert
>
>The question is if there are extensions/methods to do that without 
>having to access at least one certificate issued by CA2 (where the CDP 
>will provide the pointer I need).
>
>My guess is that SubjectInformationAccess could be used, but its 
>definition is quite broad and I was looking for something more 
>specific... easy for the developers...
>
>Russ Housley wrote:
>>Massimiliano:
>>
>>>Now I am confused... sorry I did not get your question. Let me 
>>>explain by using an example:
>>>
>>>         rootCA -> CA1 -> CA2 -> UserCert
>[...]
>>If each of these certificates contains a CRL DP, then you do not
>>need any further information.
>>CA2 -> UserCert:  The CRL DP in this certificate will provide a 
>>pointer to the CRL issued by CA2 that will include an entry for 
>>UserCert if it is revoked.
>>CA1 -> CA2:  The CRL DP in this certificate will provide a pointer 
>>to the CRL issued by CA1 that will include an entry for CA2 if it is
revoked.
>>rootCA -> CA1:  The CRL DP in this certificate will provide a 
>>pointer to the CRL issued by rootCA that will include an entry for 
>>CA1 if it is revoked.
>
>--
>
>Best Regards,
>
>         Massimiliano Pala
>
>--o------------------------------------------------------------------------
>Massimiliano Pala [OpenCA Project Manager]            [e-mail]
>                                                  
>[e-mail]
>
>Dartmouth Computer Science Dept                     Tel.: [phone]
>PKI/Trust
>--o--------------------------------------------------------------------
>----




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAEKYHsm020394; Mon, 14 Nov 2005 12:34:17 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAEKYHPd020393; Mon, 14 Nov 2005 12:34:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAEKYGfq020382 for <[e-mail]>; Mon, 14 Nov 2005 12:34:17 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id jAEKY5ai019101; Mon, 14 Nov 2005 15:34:06 -0500
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id jAEKXcG3019811; Mon, 14 Nov 2005 15:33:38 -0500 (EST)
Message-ID: <[e-mail]>
Date: Mon, 14 Nov 2005 15:34:08 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050416
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Massimiliano Pala <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: RFC-3280 [Subject Information Access]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: [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>

Massimiliano,

At the moment, there is no way to accomplish what you are trying to do 
in general.

I should begin by pointing out that the text that you quoted from RFC 
3280 has been changed in 3280bis so that it no longer mentions CRLs:

   The id-ad-caRepository OID is used when the subject is a CA, and
   publishes certificates it issues in a repository.  The accessLocation
   field is defined as a GeneralName, which can take several forms.

If a CA issues full CRLs then what you are trying to accomplish may be 
possible.  If the CA makes its certificates and CRLs available in a 
directory and you know the directory and the name of the CA, then you 
should be able to obtain the CA's CRL if it issues a full CRL (see RFC 
2587).  If a CA issues full CRLs, but you cannot use this method to find 
the CRL, then you will need to look at the cRLDistributionPoints 
extension in one of the certificates issued by the CA to determine where 
to obtain the CRL.

The biggest problem will be if the CA only issues segmented CRLs.  In 
this case looking at a single certificate issued by the CA will not be 
sufficient, since different certificates will point to different CRL 
segments.  For such a CA it would also not be possible to use some new 
accessMethod in the subjectInfoAccess extension since the CA may create 
new CRL segments as it issues certificates and the SIA extensions of 
certificates could not be updated to add these new segments.

Dave

Massimiliano Pala wrote:

> Hi Russ,
>
> thank for the answer, but probably due to my bad english I was not really
> clear... my situation is this:
>
> - I have an OCSP server and I want it to be able to "auto" configure the
>   downloading of CRLs, provided some pointer is given in the CA cert for
>   its own certs, this is:
>
>     * I have only CA2 cert
>
>     * I want to access CRLs issued by CA2
>
>     * No other info is given to the server besides the CA2 cert
>
> The question is if there are extensions/methods to do that without having
> to access at least one certificate issued by CA2 (where the CDP will 
> provide
> the pointer I need).
>
> My guess is that SubjectInformationAccess could be used, but its 
> definition
> is quite broad and I was looking for something more specific... easy 
> for the
> developers...


Massimiliano Pala wrote:

> Hi all,
>
> Is there a way for a CA to specify its own (not its issuer's) CRL
> distribution point in its certificate ?
>
> I am asking this because the only way I found so far is by using
> the Subject Information Access with id-ad-caRepository as accessMethod.
> The problem is that its definition is too broad, therefore the URI I
> can put in there could address a CRL or Certs repository or other
> services.
>
> From the RFC-3280 (pp 47):
>
> << The id-ad-caRepository OID is used when the subject is a CA, and
>    publishes its certificates and CRLs (if issued) in a repository.  The
>    accessLocation field is defined as a GeneralName, which can take
>    several forms. >>
>
> While the accessLocation is quite simple to deal with, we should have
> different accessMethod ids at least for CRLs and Certificates 
> repositories.
>
> In other words, is there a method to access the CRLs of a CA from the 
> CA's
> certificate only ?
>
> Am I missing something here ?
>




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAEJuBPB012650; Mon, 14 Nov 2005 11:56:11 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAEJuBw0012649; Mon, 14 Nov 2005 11:56:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id jAEJuBRV012641 for <[e-mail]>; Mon, 14 Nov 2005 11:56:11 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 24418 invoked by uid 0); 14 Nov 2005 19:55:56 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (209.82.80.118) by woodstock.binhost.com with SMTP; 14 Nov 2005 19:55:56 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta)
Date: Mon, 14 Nov 2005 14:16:24 -0500
To: Massimiliano Pala <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: RFC-3280 [Subject Information Access]
Cc: pkix <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

SIA could be used to provide the pointer that you seek, but I do not 
think that anyone uses it that way.  In fact, I suspect that a 
document would need to be written to tell people how to do it in an 
interoperable way.  If you want to pursue that, you would need to 
write an internet-draft and convince the PKIX WG that it wants to 
adopt it as a work item.

Russ

At 01:51 PM 11/14/2005, Massimiliano Pala wrote:
>Hi Russ,
>
>thank for the answer, but probably due to my bad english I was not really
>clear... my situation is this:
>
>- I have an OCSP server and I want it to be able to "auto" configure the
>   downloading of CRLs, provided some pointer is given in the CA cert for
>   its own certs, this is:
>
>         * I have only CA2 cert
>
>         * I want to access CRLs issued by CA2
>
>         * No other info is given to the server besides the CA2 cert
>
>The question is if there are extensions/methods to do that without having
>to access at least one certificate issued by CA2 (where the CDP will provide
>the pointer I need).
>
>My guess is that SubjectInformationAccess could be used, but its definition
>is quite broad and I was looking for something more specific... easy for the
>developers...
>
>Russ Housley wrote:
>>Massimiliano:
>>
>>>Now I am confused... sorry I did not get your question. Let me explain by
>>>using an example:
>>>
>>>         rootCA -> CA1 -> CA2 -> UserCert
>[...]
>>If each of these certificates contains a CRL DP, then you do not 
>>need any further information.
>>CA2 -> UserCert:  The CRL DP in this certificate will provide a 
>>pointer to the CRL issued by CA2 that will include an entry for 
>>UserCert if it is revoked.
>>CA1 -> CA2:  The CRL DP in this certificate will provide a pointer 
>>to the CRL issued by CA1 that will include an entry for CA2 if it is revoked.
>>rootCA -> CA1:  The CRL DP in this certificate will provide a 
>>pointer to the CRL issued by rootCA that will include an entry for 
>>CA1 if it is revoked.
>
>--
>
>Best Regards,
>
>         Massimiliano Pala
>
>--o------------------------------------------------------------------------
>Massimiliano Pala [OpenCA Project Manager]            [e-mail]
>                                                  [e-mail]
>
>Dartmouth Computer Science Dept                     Tel.: [phone]
>PKI/Trust
>--o------------------------------------------------------------------------



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAEIpFO3098448; Mon, 14 Nov 2005 10:51:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAEIpF9E098447; Mon, 14 Nov 2005 10:51:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhub1.dartmouth.edu (mailhub1.dartmouth.edu [129.170.16.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAEIpEew098441 for <[e-mail]>; Mon, 14 Nov 2005 10:51:15 -0800 (PST) (envelope-from [e-mail])
Received: from [129.170.212.213] (dhcp-212-213.cs.dartmouth.edu [129.170.212.213]) by mailhub1.dartmouth.edu (8.13.5/DND2.0/8.13.5) with ESMTP id jAEIp9n8029997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=OK); Mon, 14 Nov 2005 13:51:10 -0500
Message-ID: <[e-mail]>
Date: Mon, 14 Nov 2005 13:51:42 -0500
From: Massimiliano Pala <[e-mail]>
Organization: Dartmouth College
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: RFC-3280 [Subject Information Access]
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000607020907050505030602"
X-MailScanner: Found to be clean by mailhub.Dartmouth.EDU
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms000607020907050505030602
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Russ,

thank for the answer, but probably due to my bad english I was not really
clear... my situation is this:

- I have an OCSP server and I want it to be able to "auto" configure the
   downloading of CRLs, provided some pointer is given in the CA cert for
   its own certs, this is:

	* I have only CA2 cert

	* I want to access CRLs issued by CA2

	* No other info is given to the server besides the CA2 cert

The question is if there are extensions/methods to do that without having
to access at least one certificate issued by CA2 (where the CDP will provide
the pointer I need).

My guess is that SubjectInformationAccess could be used, but its definition
is quite broad and I was looking for something more specific... easy for the
developers...

Russ Housley wrote:
> 
> Massimiliano:
> 
>> Now I am confused... sorry I did not get your question. Let me explain by
>> using an example:
>>
>>         rootCA -> CA1 -> CA2 -> UserCert
[...]
> If each of these certificates contains a CRL DP, then you do not need 
> any further information.
> 
> CA2 -> UserCert:  The CRL DP in this certificate will provide a pointer 
> to the CRL issued by CA2 that will include an entry for UserCert if it 
> is revoked.
> 
> CA1 -> CA2:  The CRL DP in this certificate will provide a pointer to 
> the CRL issued by CA1 that will include an entry for CA2 if it is revoked.
> 
> rootCA -> CA1:  The CRL DP in this certificate will provide a pointer to 
> the CRL issued by rootCA that will include an entry for CA1 if it is 
> revoked.

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]            [e-mail]
                                                  [e-mail]

Dartmouth Computer Science Dept                     Tel.: [phone]
PKI/Trust
--o------------------------------------------------------------------------

--------------ms000607020907050505030602
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJIjCC
BI0wggN1oAMCAQICAhpTMA0GCSqGSIb3DQEBBQUAMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUx
GTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0
bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMTAeFw0wNTExMDgy
MDMzMDZaFw0wOTExMDkyMDMzMDZaMIHBMRMwEQYKCZImiZPyLGQBGRYDZWR1MRkwFwYKCZIm
iZPyLGQBGRYJZGFydG1vdXRoMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1vdXRoIENv
bGxlZ2UxGjAYBgoJkiaJk/IsZAEBEwoxMjI1NjAyOTQ3MRowGAYDVQQDExFNYXNzaW1pbGlh
bm8gUGFsYTEuMCwGCSqGSIb3DQEJARYfTWFzc2ltaWxpYW5vLlBhbGFARGFydG1vdXRoLmVk
dTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAsv8obBpbhPixgdyIJj7UN0GYRNhsgWHB
muCE5j8v8IvCSJWRF9spKoR0NBYgOfJu8DwQuKTIgrvbp0EC3ikrneotL4KTGD1IqWz/bSXL
UR/bZAsc0r9PrvCUsZOi7wbijy784gOuqQUCJ2fJwKwk5SJ3RBaPnUROQXTp+LPSK8MCAwEA
AaOCAVowggFWMA4GA1UdDwEB/wQEAwIF4DARBglghkgBhvhCAQEEBAMCBaAwgaIGA1UdIASB
mjCBlzCBlAYKKwYBBAFBAgEBATCBhTA9BggrBgEFBQcCAjAxMBgWEURhcnRtb3V0aCBDb2xs
ZWdlMAMCAQEaFURhcnRtb3V0aCBDb2xsZWdlIENQUzBEBggrBgEFBQcCARY4aHR0cDovL3d3
dy5kYXJ0bW91dGguZWR1L35wa2lsYWIvRGFydG1vdXRoQ1BTXzRTZXAwMy5wZGYwKgYDVR0R
BCMwIYEfTWFzc2ltaWxpYW5vLlBhbGFARGFydG1vdXRoLmVkdTAfBgNVHSMEGDAWgBQ/wNbH
p08Afu8GmWdsvJYeTaN3EjA/BggrBgEFBQcBAQQzMDEwLwYIKwYBBQUHMAGGI2h0dHA6Ly9j
b2xsZWdlY2EuZGFydG1vdXRoLmVkdS9vY3NwMA0GCSqGSIb3DQEBBQUAA4IBAQDEYIWmG3Ht
wcgFiBbrYKp7YpI62hgAw9I3Dj9Ai+etQcMDZL8cWg3Kd7DwYHDkLxO7jl518HIJCk8Elk+Z
3Y2c0rR+c9WLuxE+EHEUmQg2AbgxzRGZAeMXj7jrv5w75IWiXBrW3SdDkjVH6MQFZVP1CBk7
PF3/+dzmiO6E5g4cVtphPSdK2qtnX7Sh0zdePzeE+e0BTnsWdN0yHgKabKx3dCiEnQXt96sA
Jf5ckg7fFLcplohwWlWJCpk8WwnJM0QGw3xbrZvLk+kIQgyh0sn2va4FgA1ae29cJ1d2NurA
Z+LMdei9/ZbzBeMoD9XPSYyj7zLuVXGLF/JQQoPywk5oMIIEjTCCA3WgAwIBAgICGlMwDQYJ
KoZIhvcNAQEFBQAwdzETMBEGCgmSJomT8ixkARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRh
cnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYD
VQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTA1MTEwODIwMzMwNloXDTA5MTEwOTIwMzMw
NlowgcExEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgx
CzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEaMBgGCgmSJomT8ixk
AQETCjEyMjU2MDI5NDcxGjAYBgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMS4wLAYJKoZIhvcN
AQkBFh9NYXNzaW1pbGlhbm8uUGFsYUBEYXJ0bW91dGguZWR1MIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQCy/yhsGluE+LGB3IgmPtQ3QZhE2GyBYcGa4ITmPy/wi8JIlZEX2ykqhHQ0
FiA58m7wPBC4pMiCu9unQQLeKSud6i0vgpMYPUipbP9tJctRH9tkCxzSv0+u8JSxk6LvBuKP
LvziA66pBQInZ8nArCTlIndEFo+dRE5BdOn4s9IrwwIDAQABo4IBWjCCAVYwDgYDVR0PAQH/
BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIFoDCBogYDVR0gBIGaMIGXMIGUBgorBgEEAUECAQEB
MIGFMD0GCCsGAQUFBwICMDEwGBYRRGFydG1vdXRoIENvbGxlZ2UwAwIBARoVRGFydG1vdXRo
IENvbGxlZ2UgQ1BTMEQGCCsGAQUFBwIBFjhodHRwOi8vd3d3LmRhcnRtb3V0aC5lZHUvfnBr
aWxhYi9EYXJ0bW91dGhDUFNfNFNlcDAzLnBkZjAqBgNVHREEIzAhgR9NYXNzaW1pbGlhbm8u
UGFsYUBEYXJ0bW91dGguZWR1MB8GA1UdIwQYMBaAFD/A1senTwB+7waZZ2y8lh5No3cSMD8G
CCsGAQUFBwEBBDMwMTAvBggrBgEFBQcwAYYjaHR0cDovL2NvbGxlZ2VjYS5kYXJ0bW91dGgu
ZWR1L29jc3AwDQYJKoZIhvcNAQEFBQADggEBAMRghaYbce3ByAWIFutgqntikjraGADD0jcO
P0CL561BwwNkvxxaDcp3sPBgcOQvE7uOXnXwcgkKTwSWT5ndjZzStH5z1Yu7ET4QcRSZCDYB
uDHNEZkB4xePuOu/nDvkhaJcGtbdJ0OSNUfoxAVlU/UIGTs8Xf/53OaI7oTmDhxW2mE9J0ra
q2dftKHTN14/N4T57QFOexZ03TIeAppsrHd0KISdBe33qwAl/lySDt8UtymWiHBaVYkKmTxb
CckzRAbDfFutm8uT6QhCDKHSyfa9rgWADVp7b1wnV3Y26sBn4sx16L39lvMF4ygP1c9JjKPv
Mu5VcYsX8lBCg/LCTmgxggL4MIIC9AIBATB9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAX
BgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91
dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwCQYFKw4DAhoF
AKCCAdEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMTE0
MTg1MTQyWjAjBgkqhkiG9w0BCQQxFgQUwixaRWizQi0oVQnb11xxMBBAeIcwUgYJKoZIhvcN
AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF
Kw4DAgcwDQYIKoZIhvcNAwICASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixk
ARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNV
BAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgIa
UzCBjgYLKoZIhvcNAQkQAgsxf6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJ
k/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29s
bGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwDQYJKoZIhvcNAQEBBQAE
gYA8Wr1+++oRR+CyIU3ZxM1i9Pa0XDydOzhC+0B3uyt6I1+sWxpglTGaCvlkwhJrQBBiiZP2
UCSLBR+8MkVwIo424zgPRyzuLXeGbNryQFuqdHgtHpOJT4emwyy/XBjp2qyok2VaMOU9+o2w
Nm9X6BFTY/SmJNGysSgw9y2rh47glwAAAAAAAA=
--------------ms000607020907050505030602--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAE05Xt9023541; Sun, 13 Nov 2005 16:05:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAE05XCm023540; Sun, 13 Nov 2005 16:05:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id jAE05WlU023522 for <[e-mail]>; Sun, 13 Nov 2005 16:05:32 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 1184 invoked by uid 0); 14 Nov 2005 00:05:19 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (216.123.155.194) by woodstock.binhost.com with SMTP; 14 Nov 2005 00:05:19 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta)
Date: Sun, 13 Nov 2005 19:05:25 -0500
To: Massimiliano Pala <[e-mail]>, pkix <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: RFC-3280 [Subject Information Access]
In-Reply-To: <[e-mail]>
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>

Massimiliano:

>Now I am confused... sorry I did not get your question. Let me explain by
>using an example:
>
>         rootCA -> CA1 -> CA2 -> UserCert

Since you do not say anything about indirect CRLs, I'll assume that 
it has nothing to do with your question.  My response ignores indirect CRLs.

If each of these certificates contains a CRL DP, then you do not need 
any further information.

CA2 -> UserCert:  The CRL DP in this certificate will provide a 
pointer to the CRL issued by CA2 that will include an entry for 
UserCert if it is revoked.

CA1 -> CA2:  The CRL DP in this certificate will provide a pointer to 
the CRL issued by CA1 that will include an entry for CA2 if it is revoked.

rootCA -> CA1:  The CRL DP in this certificate will provide a pointer 
to the CRL issued by rootCA that will include an entry for CA1 if it 
is revoked.

Russ



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAD1ed8h068664; Sat, 12 Nov 2005 17:40:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAD1edgC068663; Sat, 12 Nov 2005 17:40:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAD1ecCQ068656 for <[e-mail]>; Sat, 12 Nov 2005 17:40:39 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (pcp09271453pcs.arlngt01.va.comcast.net [69.143.129.49]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id jAD1ebwp030677 for <[e-mail]>; Sat, 12 Nov 2005 20:40:38 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: RFC-3280 [Subject Information Access]
Date: Sat, 12 Nov 2005 20:40:29 -0500
Message-ID: <008d01c5e7f3$3dd42670$[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.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom,

See responses in-line under [Santosh:]

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Tom Gindin
Sent: Saturday, November 12, 2005 4:05 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: RFC-3280 [Subject Information Access]



        Santosh, Massimiliano:

        I'm confused by the way in which one would enable "a CA to specify 
its own (not its issuer's) CRL distribution point in its certificate". 

[Santosh: A CRL DP in a certificate will point to location(s) from which
revocation information for that certificate can be obtained.]

Does this mean the distribution point covering the CA (which should 
already be in the certificate issued to this CA) or a distribution point 
containing a CRL created by the CA (which gets put into the CRL DP of a 
certificate it creates)?

[Santosh: Again, a CRL DP in certificate points to CRL that covers the
status of the certificate.]

  And does it go into a certificate issued to the 
CA by another CA (in which case it can't be specified in this way), a 
certificate issued by the CA to somebody else (the purpose for which CRL 
DP's were designed, unless it's a CRL covering the CA), or a rollover 
self-issued certificate?

[Santosh: I am not sure what you are saying above.  But, a CRL DP in a
certificate will point to location(s) from which revocation information for
that certificate can be obtained.]

A relying party certainly needs to have revocation information for 
an intermediate CA, and that's normally found in the intermediate CA's 
certificate.

[Santosh; Amen]

I suppose that if an intermediate CA has a certificate from 
which it's hard to find the CRL (e.g. a certificate with no distribution 
point address or with only a DN as specification) a pointer from each 
certificate it issues could be useful.  However, this would naturally go 
into the AIA extension (since it references information about the issuer 
of the certificate) rather than into SIA, and it would have to be of lower 
precedence than an AIA or DP in the issuer certificate itself since the CA 
MUST not be able to override a revocation of its certificate.  Is 
permitting a CA to do this really a good idea, and if so is it worthwhile?

[Santosh: You can always define new extensions or add fields and options to
existing extensions.  But, that is not there.  You should talk with the
3280bis editors if you want to have a capability in SIA or AIA to point to
CRL.]

Tom Gindin






"Santosh Chokhani" <[e-mail]>
Sent by: [e-mail]
11/11/2005 07:29 AM
 
        To:     <[e-mail]>
        cc: 
        Subject:        RE: RFC-3280 [Subject Information Access]



And why would you want to do that?

Generally, you need revocation information for a certificate and hence CRL
DP in the certificate can and should be used to get the revocation data.

Why would you want a pointer in Issuing CA certificate?

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
On
Behalf Of Massimiliano Pala
Sent: Friday, November 11, 2005 12:16 AM
To: [e-mail]
Subject: RFC-3280 [Subject Information Access]


Hi all,

Is there a way for a CA to specify its own (not its issuer's) CRL
distribution point in its certificate ?

I am asking this because the only way I found so far is by using the 
Subject
Information Access with id-ad-caRepository as accessMethod. The problem is
that its definition is too broad, therefore the URI I can put in there 
could
address a CRL or Certs repository or other services.

 From the RFC-3280 (pp 47):

<< The id-ad-caRepository OID is used when the subject is a CA, and
    publishes its certificates and CRLs (if issued) in a repository.  The
    accessLocation field is defined as a GeneralName, which can take
    several forms. >>

While the accessLocation is quite simple to deal with, we should have
different accessMethod ids at least for CRLs and Certificates 
repositories.

In other words, is there a method to access the CRLs of a CA from the CA's
certificate only ?

Am I missing something here ?

-- 

Best Regards,

                 Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager] [e-mail]
                                                 Tel.:   [phone] 
7081
http://security.polito.it                       Fax:    +39   178  270 
2077
                                                 Mobile: [phone] 
365

Politecnico di Torino (EuroPKI)
Certification Authority Informations:

Authority Access Point                                  
http://ca.polito.it
Authority's Certificate:          
http://ca.polito.it/ca_cert/en_index.html
Certificate Revocation List:              
http://ca.polito.it/crl02/crl.crl
--o------------------------------------------------------------------------






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jACMrcWv032229; Sat, 12 Nov 2005 14:53:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jACMrcGm032227; Sat, 12 Nov 2005 14:53:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhub1.dartmouth.edu (mailhub1.dartmouth.edu [129.170.16.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jACMrbRR032215 for <[e-mail]>; Sat, 12 Nov 2005 14:53:37 -0800 (PST) (envelope-from [e-mail])
Received: from [129.170.212.213] (dhcp-212-213.cs.dartmouth.edu [129.170.212.213]) by mailhub1.dartmouth.edu (8.13.5/DND2.0/8.13.5) with ESMTP id jACMrV9P000605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=OK); Sat, 12 Nov 2005 17:53:32 -0500
Message-ID: <[e-mail]>
Date: Sat, 12 Nov 2005 17:54:04 -0500
From: Massimiliano Pala <[e-mail]>
Organization: Dartmouth College
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: pkix <[e-mail]>
CC: Tom Gindin <[e-mail]>
Subject: Re: RFC-3280 [Subject Information Access]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080608000000000609030908"
X-MailScanner: Found to be clean by mailhub.Dartmouth.EDU
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms080608000000000609030908
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Tom Gindin wrote:
>         Santosh, Massimiliano:
> 
>         I'm confused by the way in which one would enable "a CA to specify 
> its own (not its issuer's) CRL distribution point in its certificate". 
> Does this mean the distribution point covering the CA (which should 
> already be in the certificate issued to this CA) or a distribution point 
> containing a CRL created by the CA (which gets put into the CRL DP of a 
> certificate it creates)?  And does it go into a certificate issued to the 
> CA by another CA (in which case it can't be specified in this way), a 
> certificate issued by the CA to somebody else (the purpose for which CRL 
> DP's were designed, unless it's a CRL covering the CA), or a rollover 
> self-issued certificate?

Now I am confused... sorry I did not get your question. Let me explain by
using an example:

	rootCA -> CA1 -> CA2 -> UserCert

In this case the CRL Distribution Point extension will carry pointers to:
* If in the user cert -> to the CRL issued by CA2
* If in the CA2 cert -> to the CRL issued by CA1
* If in the rootCA cert -> to the CRL issued by the issuer of rootCA, which
   is equivalent to the subject, therefor (this is my guess) you can put there
   the pointer to the CRL issued by rootCA

My problem is: how do I find the CRL issued by CA2 without having to retrieve
a UserCert (or a cert issued by CA2) ? I guess there is no way to do such a
thing at the moment... am I wrong ?

>         A relying party certainly needs to have revocation information for 
> an intermediate CA, and that's normally found in the intermediate CA's 
> certificate.  I suppose that if an intermediate CA has a certificate from 
> which it's hard to find the CRL (e.g. a certificate with no distribution 
> point address or with only a DN as specification) a pointer from each 
> certificate it issues could be useful.  However, this would naturally go 
> into the AIA extension (since it references information about the issuer 
> of the certificate) rather than into SIA, and it would have to be of lower

Indeed, my point was : how to search for a CRL issued by CA1 provided you
only have CA1 cert ? This should go into SIA, not AIA...

> precedence than an AIA or DP in the issuer certificate itself since the CA 
> MUST not be able to override a revocation of its certificate.  Is 
> permitting a CA to do this really a good idea, and if so is it worthwhile?

No, probably there is a misunderstanding here. What I was proposing was not
to change AIA or CDP contents, instead to provide a specific extension to
point to CRLs issued by the "current" CA cert (not by its issuer). This
has a different purpose than searching for revocation information for the
"current" certificate; I want a pointer to revocation information provided
by the "current" certificate...

I hope I clarified a bit what I was really asking... :-D

Let me know,

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]            [e-mail]
                                                  [e-mail]

Dartmouth Computer Science Dept               Home Phone: [phone]
PKI/Trust - Office 062 (Sudikoff)	    Office Phone: [phone]
--o------------------------------------------------------------------------

--------------ms080608000000000609030908
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJIjCC
BI0wggN1oAMCAQICAhpTMA0GCSqGSIb3DQEBBQUAMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUx
GTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0
bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMTAeFw0wNTExMDgy
MDMzMDZaFw0wOTExMDkyMDMzMDZaMIHBMRMwEQYKCZImiZPyLGQBGRYDZWR1MRkwFwYKCZIm
iZPyLGQBGRYJZGFydG1vdXRoMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1vdXRoIENv
bGxlZ2UxGjAYBgoJkiaJk/IsZAEBEwoxMjI1NjAyOTQ3MRowGAYDVQQDExFNYXNzaW1pbGlh
bm8gUGFsYTEuMCwGCSqGSIb3DQEJARYfTWFzc2ltaWxpYW5vLlBhbGFARGFydG1vdXRoLmVk
dTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAsv8obBpbhPixgdyIJj7UN0GYRNhsgWHB
muCE5j8v8IvCSJWRF9spKoR0NBYgOfJu8DwQuKTIgrvbp0EC3ikrneotL4KTGD1IqWz/bSXL
UR/bZAsc0r9PrvCUsZOi7wbijy784gOuqQUCJ2fJwKwk5SJ3RBaPnUROQXTp+LPSK8MCAwEA
AaOCAVowggFWMA4GA1UdDwEB/wQEAwIF4DARBglghkgBhvhCAQEEBAMCBaAwgaIGA1UdIASB
mjCBlzCBlAYKKwYBBAFBAgEBATCBhTA9BggrBgEFBQcCAjAxMBgWEURhcnRtb3V0aCBDb2xs
ZWdlMAMCAQEaFURhcnRtb3V0aCBDb2xsZWdlIENQUzBEBggrBgEFBQcCARY4aHR0cDovL3d3
dy5kYXJ0bW91dGguZWR1L35wa2lsYWIvRGFydG1vdXRoQ1BTXzRTZXAwMy5wZGYwKgYDVR0R
BCMwIYEfTWFzc2ltaWxpYW5vLlBhbGFARGFydG1vdXRoLmVkdTAfBgNVHSMEGDAWgBQ/wNbH
p08Afu8GmWdsvJYeTaN3EjA/BggrBgEFBQcBAQQzMDEwLwYIKwYBBQUHMAGGI2h0dHA6Ly9j
b2xsZWdlY2EuZGFydG1vdXRoLmVkdS9vY3NwMA0GCSqGSIb3DQEBBQUAA4IBAQDEYIWmG3Ht
wcgFiBbrYKp7YpI62hgAw9I3Dj9Ai+etQcMDZL8cWg3Kd7DwYHDkLxO7jl518HIJCk8Elk+Z
3Y2c0rR+c9WLuxE+EHEUmQg2AbgxzRGZAeMXj7jrv5w75IWiXBrW3SdDkjVH6MQFZVP1CBk7
PF3/+dzmiO6E5g4cVtphPSdK2qtnX7Sh0zdePzeE+e0BTnsWdN0yHgKabKx3dCiEnQXt96sA
Jf5ckg7fFLcplohwWlWJCpk8WwnJM0QGw3xbrZvLk+kIQgyh0sn2va4FgA1ae29cJ1d2NurA
Z+LMdei9/ZbzBeMoD9XPSYyj7zLuVXGLF/JQQoPywk5oMIIEjTCCA3WgAwIBAgICGlMwDQYJ
KoZIhvcNAQEFBQAwdzETMBEGCgmSJomT8ixkARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRh
cnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYD
VQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTA1MTEwODIwMzMwNloXDTA5MTEwOTIwMzMw
NlowgcExEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgx
CzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEaMBgGCgmSJomT8ixk
AQETCjEyMjU2MDI5NDcxGjAYBgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMS4wLAYJKoZIhvcN
AQkBFh9NYXNzaW1pbGlhbm8uUGFsYUBEYXJ0bW91dGguZWR1MIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQCy/yhsGluE+LGB3IgmPtQ3QZhE2GyBYcGa4ITmPy/wi8JIlZEX2ykqhHQ0
FiA58m7wPBC4pMiCu9unQQLeKSud6i0vgpMYPUipbP9tJctRH9tkCxzSv0+u8JSxk6LvBuKP
LvziA66pBQInZ8nArCTlIndEFo+dRE5BdOn4s9IrwwIDAQABo4IBWjCCAVYwDgYDVR0PAQH/
BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIFoDCBogYDVR0gBIGaMIGXMIGUBgorBgEEAUECAQEB
MIGFMD0GCCsGAQUFBwICMDEwGBYRRGFydG1vdXRoIENvbGxlZ2UwAwIBARoVRGFydG1vdXRo
IENvbGxlZ2UgQ1BTMEQGCCsGAQUFBwIBFjhodHRwOi8vd3d3LmRhcnRtb3V0aC5lZHUvfnBr
aWxhYi9EYXJ0bW91dGhDUFNfNFNlcDAzLnBkZjAqBgNVHREEIzAhgR9NYXNzaW1pbGlhbm8u
UGFsYUBEYXJ0bW91dGguZWR1MB8GA1UdIwQYMBaAFD/A1senTwB+7waZZ2y8lh5No3cSMD8G
CCsGAQUFBwEBBDMwMTAvBggrBgEFBQcwAYYjaHR0cDovL2NvbGxlZ2VjYS5kYXJ0bW91dGgu
ZWR1L29jc3AwDQYJKoZIhvcNAQEFBQADggEBAMRghaYbce3ByAWIFutgqntikjraGADD0jcO
P0CL561BwwNkvxxaDcp3sPBgcOQvE7uOXnXwcgkKTwSWT5ndjZzStH5z1Yu7ET4QcRSZCDYB
uDHNEZkB4xePuOu/nDvkhaJcGtbdJ0OSNUfoxAVlU/UIGTs8Xf/53OaI7oTmDhxW2mE9J0ra
q2dftKHTN14/N4T57QFOexZ03TIeAppsrHd0KISdBe33qwAl/lySDt8UtymWiHBaVYkKmTxb
CckzRAbDfFutm8uT6QhCDKHSyfa9rgWADVp7b1wnV3Y26sBn4sx16L39lvMF4ygP1c9JjKPv
Mu5VcYsX8lBCg/LCTmgxggL4MIIC9AIBATB9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAX
BgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91
dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwCQYFKw4DAhoF
AKCCAdEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMTEy
MjI1NDA0WjAjBgkqhkiG9w0BCQQxFgQUvwqfakDeVCxtlXv+caiCDpsCLnEwUgYJKoZIhvcN
AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF
Kw4DAgcwDQYIKoZIhvcNAwICASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixk
ARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNV
BAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgIa
UzCBjgYLKoZIhvcNAQkQAgsxf6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJ
k/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29s
bGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwDQYJKoZIhvcNAQEBBQAE
gYBGVBwYPn+cld+FmqotUgqP0fw4jwzg7TlxT/pgBLqTA0VhJr24uofu5WI5UqB9wdbfAdh/
zNogXB4RNDLloSEd3xtGtYlcokS9tMpTdzdTgnbYFt57Snh0Kgs+dMANu0za7qMZrYbbj002
P/g5YS2/IyBQyLPd8OQ9jR70cxixxwAAAAAAAA=
--------------ms080608000000000609030908--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jACL4sHx016855; Sat, 12 Nov 2005 13:04:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jACL4sAa016851; Sat, 12 Nov 2005 13:04:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jACL4reJ016729 for <[e-mail]>; Sat, 12 Nov 2005 13:04:53 -0800 (PST) (envelope-from [e-mail])
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jACL4imd023293 for <[e-mail]>; Sat, 12 Nov 2005 16:04:44 -0500
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id jACL4ixb123930 for <[e-mail]>; Sat, 12 Nov 2005 16:04:45 -0500
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jACL4iLL015475 for <[e-mail]>; Sat, 12 Nov 2005 16:04:44 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jACL4iOI015472; Sat, 12 Nov 2005 16:04:44 -0500
In-Reply-To: <003b01c5e6bb$a55374b0$[e-mail]>
To: "Santosh Chokhani" <[e-mail]>
Cc: [e-mail]
MIME-Version: 1.0
Subject: RE: RFC-3280 [Subject Information Access]
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Sat, 12 Nov 2005 16:04:43 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.5.4FP2 HF2|November 9, 2005) at 11/12/2005 16:04:43, Serialize complete at 11/12/2005 16:04:43
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>

        Santosh, Massimiliano:

        I'm confused by the way in which one would enable "a CA to specify 
its own (not its issuer's) CRL distribution point in its certificate". 
Does this mean the distribution point covering the CA (which should 
already be in the certificate issued to this CA) or a distribution point 
containing a CRL created by the CA (which gets put into the CRL DP of a 
certificate it creates)?  And does it go into a certificate issued to the 
CA by another CA (in which case it can't be specified in this way), a 
certificate issued by the CA to somebody else (the purpose for which CRL 
DP's were designed, unless it's a CRL covering the CA), or a rollover 
self-issued certificate?
        A relying party certainly needs to have revocation information for 
an intermediate CA, and that's normally found in the intermediate CA's 
certificate.  I suppose that if an intermediate CA has a certificate from 
which it's hard to find the CRL (e.g. a certificate with no distribution 
point address or with only a DN as specification) a pointer from each 
certificate it issues could be useful.  However, this would naturally go 
into the AIA extension (since it references information about the issuer 
of the certificate) rather than into SIA, and it would have to be of lower 
precedence than an AIA or DP in the issuer certificate itself since the CA 
MUST not be able to override a revocation of its certificate.  Is 
permitting a CA to do this really a good idea, and if so is it worthwhile?

Tom Gindin






"Santosh Chokhani" <[e-mail]>
Sent by: [e-mail]
11/11/2005 07:29 AM
 
        To:     <[e-mail]>
        cc: 
        Subject:        RE: RFC-3280 [Subject Information Access]



And why would you want to do that?

Generally, you need revocation information for a certificate and hence CRL
DP in the certificate can and should be used to get the revocation data.

Why would you want a pointer in Issuing CA certificate?

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
On
Behalf Of Massimiliano Pala
Sent: Friday, November 11, 2005 12:16 AM
To: [e-mail]
Subject: RFC-3280 [Subject Information Access]


Hi all,

Is there a way for a CA to specify its own (not its issuer's) CRL
distribution point in its certificate ?

I am asking this because the only way I found so far is by using the 
Subject
Information Access with id-ad-caRepository as accessMethod. The problem is
that its definition is too broad, therefore the URI I can put in there 
could
address a CRL or Certs repository or other services.

 From the RFC-3280 (pp 47):

<< The id-ad-caRepository OID is used when the subject is a CA, and
    publishes its certificates and CRLs (if issued) in a repository.  The
    accessLocation field is defined as a GeneralName, which can take
    several forms. >>

While the accessLocation is quite simple to deal with, we should have
different accessMethod ids at least for CRLs and Certificates 
repositories.

In other words, is there a method to access the CRLs of a CA from the CA's
certificate only ?

Am I missing something here ?

-- 

Best Regards,

                 Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager] [e-mail]
                                                 Tel.:   [phone] 
7081
http://security.polito.it                       Fax:    +39   178  270 
2077
                                                 Mobile: [phone] 
365

Politecnico di Torino (EuroPKI)
Certification Authority Informations:

Authority Access Point                                  
http://ca.polito.it
Authority's Certificate:          
http://ca.polito.it/ca_cert/en_index.html
Certificate Revocation List:              
http://ca.polito.it/crl02/crl.crl
--o------------------------------------------------------------------------






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jABCU8oG089214; Fri, 11 Nov 2005 04:30:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jABCU8AF089213; Fri, 11 Nov 2005 04:30:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jABCU8t1089207 for <[e-mail]>; Fri, 11 Nov 2005 04:30:08 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (pcp09271453pcs.arlngt01.va.comcast.net [69.143.129.49]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id jABCU5U0032392 for <[e-mail]>; Fri, 11 Nov 2005 07:30:07 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: RFC-3280 [Subject Information Access]
Date: Fri, 11 Nov 2005 07:29:59 -0500
Message-ID: <003b01c5e6bb$a55374b0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id jABCU8t1089208
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

And why would you want to do that?

Generally, you need revocation information for a certificate and hence CRL
DP in the certificate can and should be used to get the revocation data.

Why would you want a pointer in Issuing CA certificate?

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Massimiliano Pala
Sent: Friday, November 11, 2005 12:16 AM
To: [e-mail]
Subject: RFC-3280 [Subject Information Access]


Hi all,

Is there a way for a CA to specify its own (not its issuer's) CRL
distribution point in its certificate ?

I am asking this because the only way I found so far is by using the Subject
Information Access with id-ad-caRepository as accessMethod. The problem is
that its definition is too broad, therefore the URI I can put in there could
address a CRL or Certs repository or other services.

 From the RFC-3280 (pp 47):

<< The id-ad-caRepository OID is used when the subject is a CA, and
    publishes its certificates and CRLs (if issued) in a repository.  The
    accessLocation field is defined as a GeneralName, which can take
    several forms. >>

While the accessLocation is quite simple to deal with, we should have
different accessMethod ids at least for CRLs and Certificates repositories.

In other words, is there a method to access the CRLs of a CA from the CA's
certificate only ?

Am I missing something here ?

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]      [e-mail]
                                                 Tel.:   [phone]
http://security.polito.it                       Fax:    +39   178  270 2077
                                                 Mobile: [phone]

Politecnico di Torino (EuroPKI)
Certification Authority Informations:

Authority Access Point                                  http://ca.polito.it
Authority's Certificate:          http://ca.polito.it/ca_cert/en_index.html
Certificate Revocation List:              http://ca.polito.it/crl02/crl.crl
--o------------------------------------------------------------------------




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAB5FSYm012307; Thu, 10 Nov 2005 21:15:28 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAB5FSb8012306; Thu, 10 Nov 2005 21:15:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from polito.it (anacreon.polito.it [130.192.3.82]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAB5FPQD012285 for <[e-mail]>; Thu, 10 Nov 2005 21:15:27 -0800 (PST) (envelope-from [e-mail])
X-AttachExt: p7s
X-ExtScanner: Niversoft's FindAttachments (free)
Received: from [129.170.210.181] ([129.170.210.181] verified) by polito.it (CommuniGate Pro SMTP 5.0.1) with ESMTPS id 137608 for [e-mail]; Fri, 11 Nov 2005 06:15:23 +0100
Message-ID: <[e-mail]>
Date: Fri, 11 Nov 2005 00:15:53 -0500
From: Massimiliano Pala <[e-mail]>
Organization: Politecnico di Torino
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: RFC-3280 [Subject Information Access]
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030303090006000509010605"
Sender: [e-mail]
Precedence: 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 cryptographically signed message in MIME format.

--------------ms030303090006000509010605
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi all,

Is there a way for a CA to specify its own (not its issuer's) CRL
distribution point in its certificate ?

I am asking this because the only way I found so far is by using
the Subject Information Access with id-ad-caRepository as accessMethod.
The problem is that its definition is too broad, therefore the URI I
can put in there could address a CRL or Certs repository or other
services.

 From the RFC-3280 (pp 47):

<< The id-ad-caRepository OID is used when the subject is a CA, and
    publishes its certificates and CRLs (if issued) in a repository.  The
    accessLocation field is defined as a GeneralName, which can take
    several forms. >>

While the accessLocation is quite simple to deal with, we should have
different accessMethod ids at least for CRLs and Certificates repositories.

In other words, is there a method to access the CRLs of a CA from the CA's
certificate only ?

Am I missing something here ?

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]      [e-mail]
                                                 Tel.:   [phone]
http://security.polito.it                       Fax:    +39   178  270 2077
                                                 Mobile: [phone]

Politecnico di Torino (EuroPKI)
Certification Authority Informations:

Authority Access Point                                  http://ca.polito.it
Authority's Certificate:          http://ca.polito.it/ca_cert/en_index.html
Certificate Revocation List:              http://ca.polito.it/crl02/crl.crl
--o------------------------------------------------------------------------

--------------ms030303090006000509010605
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIU7zCC
BIMwggNroAMCAQICAQswDQYJKoZIhvcNAQEFBQAwQTEQMA4GA1UEChMHRXVyb1BLSTEtMCsG
A1UEAxMkRXVyb1BLSSBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAxMTIxMjEw
MDAwMFoXDTA2MTIzMTEwMDAwMFowUTELMAkGA1UEBhMCSVQxEDAOBgNVBAoTB0V1cm9QS0kx
MDAuBgNVBAMTJ0V1cm9QS0kgSXRhbGlhbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAP7ay1Eyxgv7fW1lpkRT4bljS3Cf7Z5m/KaX
pQEsMQfihBXvocVGVqYCTbXl1u+9rbyVV8MtoaZFE2Eb+8tKTA6D2UJpVln2GinHi1Cs+wIV
6Sz55wKaN3tKzGMw3L/H3ADNiYottP//ge3S1P6j0bcGhQ/p/xOGzmALt8CB7KCtn9+VHV8D
vcmOqmmQVcymUz9MCN68ZzfLvefAnUzWoIN72fxJDRG8szLj1IYxHOPsoLVID20yGDdyppHt
Vr1xUY4rGo5jPCuI79/QxNhQeDyWQo2x2jqM3nVmVXDFRJIms1j7BWpuiEhs0ZJWkaQXd29g
mBeZopvMKyAXO3XDDv8CAwEAAaOCAXQwggFwMEwGCWCGSAGG+EIBDQQ/Fj1Jc3N1ZWQgdW5k
ZXIgcG9saWN5OgogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9yb290L2Nwcy8xLjEvMDgG
CCsGAQUFBwEBBCwwKjAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AuZXVyb3BraS5vcmc6ODAy
NjA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3Js
L2NybC5kZXIwTgYDVR0gBEcwRTBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6
Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzAfBgNVHSMEGDAWgBSM3IuxpUqQ
506Icxg8ndVefuSyzTAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIB9jAdBgNVHQ4EFgQUqjwT
yUkLXM240yDgxZWXMzNdJBMwDQYJKoZIhvcNAQEFBQADggEBAGuphjJQE0RQ28euKSOZ7Q4b
vGgPeO8WgGiUHrpZ6vI2+/knSqqK0AQ7j5+4viGMJgm2x8JnYq9ZYy1i0wFrYIxE/G2fw8cW
1P/8sCNzqTj+SO0/2KpJ0BkvuTSG2r1NTeg6a5r61a4jUqp4upKxuzgu6unsw/+RkU2KzlNm
053JOcsM82dIN3NBr+hZs/0IFiMW1GJB2P7225WWDF01OtQcmLYspoiffUPy2g+g4FD5IxHF
HKvCG1b9zHmfJoaDn5y+kQQpHs/ZIZeUyNe9ULifu3GgGQKp9sj6bpbGfjW3LAhhG6Ldhf8+
Azi6vNmzQwCbegU26NFazErhLS5qDXQwggU+MIIEJqADAgECAgIBaDANBgkqhkiG9w0BAQUF
ADBRMQswCQYDVQQGEwJJVDEQMA4GA1UEChMHRXVyb1BLSTEwMC4GA1UEAxMnRXVyb1BLSSBJ
dGFsaWFuIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAxMTIxNDEwMDAwMFoXDTA2MTIz
MTA5MDAwMFowZTELMAkGA1UEBhMCSVQxHjAcBgNVBAoTFVBvbGl0ZWNuaWNvIGRpIFRvcmlu
bzE2MDQGA1UEAxMtUG9saXRlY25pY28gZGkgVG9yaW5vIENlcnRpZmljYXRpb24gQXV0aG9y
aXR5MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9sfcfWMG/mS8O69abPfnUWci
6TfUncSlfs8SzpwAsoW1/OJpGVtxq1yKQrP8WqiixEcZWSvnlOcyRj/C0tz3JLQKSAyrHKGS
Dkn5Md4HCue+L1JHQ3Ba14eQOj7rAugFgE+6LenTAvguOQl74/t9C93Ldm1NY+t1Fs36oPhP
JQ5inrZ6D8P9ol4s/ecyPhhQaU1tioqQy1d01gXTrmI2eH6Ui0AkyexVcxFpXR7qnvPV7huE
+ZTDU77t9jx24smmJuSxlA8HQS8I+qCytDhOYsKm676n1a4wpE9VunoVAm/+7tajm31ZYaxT
njX891kfFGoFi/J3tIRc67vh8Joy+wIDAQABo4ICCjCCAgYwdQYJYIZIAYb4QgENBGgWZklz
c3VlZCB1bmRlciBwb2xpY2llczoKIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9j
cHMvMS4xLwogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4xLzBcBggrBgEF
BQcBAQRQME4wKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwLmV1cm9wa2kub3JnOjgwMjYwIgYI
KwYBBQUHMAKGFmh0dHA6Ly93d3cuZXVyb3BraS5vcmcwOwYDVR0fBDQwMjAwoC6gLIYqaHR0
cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcmwwMi9jcmwuZGVyMIGTBgNVHSAEgYswgYgw
QwYKKwYBBAGpBwEBATA1MDMGCCsGAQUFBwIBFidodHRwOi8vd3d3LmV1cm9wa2kub3JnL2Nh
L3Jvb3QvY3BzLzEuMS8wQQYKKwYBBAGpBwIBATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vd3d3
LmV1cm9wa2kub3JnL2NhL2l0L2Nwcy8xLjEvMB8GA1UdIwQYMBaAFKo8E8lJC1zNuNMg4MWV
lzMzXSQTMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgH2MB0GA1UdDgQWBBT0DG1tnl9M
YlY5geDe+Y8vN6CExTANBgkqhkiG9w0BAQUFAAOCAQEAXx26gpm/oiG7ti2+e1Lwmnqn6jk0
ihxIxccazoTAjWzq60x+MhIJsIgRfGtv5U2XzEWc15UZru6srk8TqctT6EbqRMTCtx6mxPd6
RpKp3jepigGOkwnJsnjjUPC/tHmfJHNcll3Rk6a4OIvazlwOoCuQ8D0N9sAGtx35+T+tAyph
NU9yHtC3dpvQotLmJFo2Pr6sTy2ijCqQnHxJ2sZUEAlNEunKFP8y3uPfwvE0FEC7lONkUx+U
79yAlwPvBvASUopIQPy7BQ9IMupkj/1DmUvml/05f+DYv2x7UbiUlp1ksQXzs+WLxB2NADfn
CaPNvqphRz5KhJGOTJpc8CZ+UDCCBY8wggR3oAMCAQICAgFnMA0GCSqGSIb3DQEBBQUAMGUx
CzAJBgNVBAYTAklUMR4wHAYDVQQKExVQb2xpdGVjbmljbyBkaSBUb3Jpbm8xNjA0BgNVBAMT
LVBvbGl0ZWNuaWNvIGRpIFRvcmlubyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDAy
MDMxNTAwMDBaFw0wNTEyMzExMjAwMDBaMH0xCzAJBgNVBAYTAklUMR4wHAYDVQQKExVQb2xp
dGVjbmljbyBkaSBUb3Jpbm8xMTAvBgNVBAsTKERpcGFydGltZW50byBkaSBBdXRvbWF0aWNh
IGUgSW5mb3JtYXRpY2ExGzAZBgNVBAMTEk1hc3NpbWlsaWFubyAgUGFsYTCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAq9EaJRA7cRia5n0014UeruZBPwDwNyEpWxIvWqVG6taEt1P1
wApd7oKi7yhUL8yUpX2eEQdLj/yjCQOr1NqmkL5MwiZhVtwcli3/3G0OayKu/i6yRIW24SM5
sbNLO4hhZYSiHAMlZ/U5Y6r6zFvxRbIK9/mB/wrJ6HIzOzC+xncCAwEAAaOCArMwggKvMIGV
BglghkgBhvhCAQ0EgYcWgYRJc3N1ZWQgdW5kZXIgcG9saWNpZXM6CiBodHRwOi8vd3d3LmV1
cm9wa2kub3JnL2NhL3Jvb3QvY3BzLzEuMS8KIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Ev
aXQvY3BzLzEuMS8KIGh0dHA6Ly9jYS5wb2xpdG8uaXQvY3BzLzIuMS8wEQYJYIZIAYb4QgEB
BAQDAgCwMGMGCCsGAQUFBwEBBFcwVTAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AuZXVyb3Br
aS5vcmc6ODAyNjApBggrBgEFBQcwAoYdaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC8w
MgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NhLnBvbGl0by5pdC9jcmwwMi9jcmwuZGVyMAwG
A1UdEwEB/wQCMAAwPgYDVR0RBDcwNYEbbWFzc2ltaWxpYW5vLnBhbGFAcG9saXRvLml0oBYG
CisGAQQBlWICAQGgCBYGMTIxNTc1MIHNBgNVHSAEgcUwgcIwQwYKKwYBBAGpBwEBATA1MDMG
CCsGAQUFBwIBFidodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3BzLzEuMS8wQQYK
KwYBBAGpBwIBATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL2l0
L2Nwcy8xLjEvMDgGCisGAQQBlWIBAgEwKjAoBggrBgEFBQcCARYcaHR0cDovL2NhLnBvbGl0
by5pdC9jcHMvMi4xLzALBgNVHQ8EBAMCBPAwHQYDVR0OBBYEFKBsBAutUrWisrKMhGDw86gH
WDoSMB8GA1UdIwQYMBaAFPQMbW2eX0xiVjmB4N75jy83oITFMA0GCSqGSIb3DQEBBQUAA4IB
AQDrwXGLgvcDvhk2w6AFLp3DIhWl4zX9G6W4v9gis9vBHkIHQUg2iBmbVEeCn9XrSIXtuleH
uyYI+uu+KUdoCqt9XEFlL6eYnvrZNc7wWkH+msZwc11C+8UibhzaUezlEqTm9l+08xucAJER
4q489+2ZY7Kf8tFB1n4edgtg8rxrlNX++ZqqrJCnYWQvv0e4Hmav+CKnuMT+Y1qVv3BW6HDD
OBljhSEx6+cmooIPoWy8/5W/aGl5WEr1aCUZ/o8DODPxUIwEcUHV+m4EuQz7j0XLLcyC62Lc
FCx7+itzdJ61epbCmOgTNSWJFryVPClhlM3YFzFxL9Ae7mFmTdUbkdyKMIIFjzCCBHegAwIB
AgICAWcwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCSVQxHjAcBgNVBAoTFVBvbGl0ZWNu
aWNvIGRpIFRvcmlubzE2MDQGA1UEAxMtUG9saXRlY25pY28gZGkgVG9yaW5vIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MB4XDTA0MDIwMzE1MDAwMFoXDTA1MTIzMTEyMDAwMFowfTELMAkG
A1UEBhMCSVQxHjAcBgNVBAoTFVBvbGl0ZWNuaWNvIGRpIFRvcmlubzExMC8GA1UECxMoRGlw
YXJ0aW1lbnRvIGRpIEF1dG9tYXRpY2EgZSBJbmZvcm1hdGljYTEbMBkGA1UEAxMSTWFzc2lt
aWxpYW5vICBQYWxhMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCr0RolEDtxGJrmfTTX
hR6u5kE/APA3ISlbEi9apUbq1oS3U/XACl3ugqLvKFQvzJSlfZ4RB0uP/KMJA6vU2qaQvkzC
JmFW3ByWLf/cbQ5rIq7+LrJEhbbhIzmxs0s7iGFlhKIcAyVn9TljqvrMW/FFsgr3+YH/Csno
cjM7ML7GdwIDAQABo4ICszCCAq8wgZUGCWCGSAGG+EIBDQSBhxaBhElzc3VlZCB1bmRlciBw
b2xpY2llczoKIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLwogaHR0
cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4xLwogaHR0cDovL2NhLnBvbGl0by5p
dC9jcHMvMi4xLzARBglghkgBhvhCAQEEBAMCALAwYwYIKwYBBQUHAQEEVzBVMCgGCCsGAQUF
BzABhhxodHRwOi8vb2NzcC5ldXJvcGtpLm9yZzo4MDI2MCkGCCsGAQUFBzAChh1odHRwOi8v
d3d3LmV1cm9wa2kub3JnL2NhL2l0LzAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY2EucG9s
aXRvLml0L2NybDAyL2NybC5kZXIwDAYDVR0TAQH/BAIwADA+BgNVHREENzA1gRttYXNzaW1p
bGlhbm8ucGFsYUBwb2xpdG8uaXSgFgYKKwYBBAGVYgIBAaAIFgYxMjE1NzUwgc0GA1UdIASB
xTCBwjBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93d3cuZXVyb3BraS5v
cmcvY2Evcm9vdC9jcHMvMS4xLzBBBgorBgEEAakHAgEBMDMwMQYIKwYBBQUHAgEWJWh0dHA6
Ly93d3cuZXVyb3BraS5vcmcvY2EvaXQvY3BzLzEuMS8wOAYKKwYBBAGVYgECATAqMCgGCCsG
AQUFBwIBFhxodHRwOi8vY2EucG9saXRvLml0L2Nwcy8yLjEvMAsGA1UdDwQEAwIE8DAdBgNV
HQ4EFgQUoGwEC61StaKysoyEYPDzqAdYOhIwHwYDVR0jBBgwFoAU9AxtbZ5fTGJWOYHg3vmP
LzeghMUwDQYJKoZIhvcNAQEFBQADggEBAOvBcYuC9wO+GTbDoAUuncMiFaXjNf0bpbi/2CKz
28EeQgdBSDaIGZtUR4Kf1etIhe26V4e7Jgj6674pR2gKq31cQWUvp5ie+tk1zvBaQf6axnBz
XUL7xSJuHNpR7OUSpOb2X7TzG5wAkRHirjz37Zljsp/y0UHWfh52C2DyvGuU1f75mqqskKdh
ZC+/R7geZq/4Iqe4xP5jWpW/cFbocMM4GWOFITHr5yaigg+hbLz/lb9oaXlYSvVoJRn+jwM4
M/FQjARxQdX6bgS5DPuPRcstzILrYtwULHv6K3N0nrV6lsKY6BM1JYkWvJU8KWGUzdgXMXEv
0B7uYWZN1RuR3IoxggLAMIICvAIBATBrMGUxCzAJBgNVBAYTAklUMR4wHAYDVQQKExVQb2xp
dGVjbmljbyBkaSBUb3Jpbm8xNjA0BgNVBAMTLVBvbGl0ZWNuaWNvIGRpIFRvcmlubyBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eQICAWcwCQYFKw4DAhoFAKCCAaswGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMTExMDUxNTUzWjAjBgkqhkiG9w0BCQQx
FgQUax4iG7iINjVrt7YhP1NlvAA74pcwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw
egYJKwYBBAGCNxAEMW0wazBlMQswCQYDVQQGEwJJVDEeMBwGA1UEChMVUG9saXRlY25pY28g
ZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xpdGVjbmljbyBkaSBUb3Jpbm8gQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkCAgFnMHwGCyqGSIb3DQEJEAILMW2gazBlMQswCQYDVQQGEwJJVDEeMBwG
A1UEChMVUG9saXRlY25pY28gZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xpdGVjbmljbyBkaSBU
b3Jpbm8gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAgFnMA0GCSqGSIb3DQEBAQUABIGAptCn
lXH7TUVItxOHVeyy7SsjZ2fWCGLCt2qYtIIyhtA4MZsZjnc3XCrYlMTJvG74z9uZw0FST10R
2bnQSUhbmBBnJzwlcypIxhbhlCITXlA7PU+dNgfCZ3y7pDaoMwIs29safdLVl4xopvmKYXH9
Mg2LU2waYg5t/59gLr86QbsAAAAAAAA--------------ms030303090006000509010605--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAADk2P9061368; Thu, 10 Nov 2005 05:46:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAADk2T9061367; Thu, 10 Nov 2005 05:46:02 -0800 (PST)
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.11/8.12.9) with ESMTP id jAADk0Gm061348 for <[e-mail]>; Thu, 10 Nov 2005 05:46:01 -0800 (PST) (envelope-from [e-mail])
Received: from champagne.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id jAADjpi08188; Thu, 10 Nov 2005 14:45:51 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/2.4); Thu, 10 Nov 2005 14:45:51 +0100 (MET)
Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id OAA16308; Thu, 10 Nov 2005 14:45:50 +0100 (MET)
Message-ID: <[e-mail]>
Date: Thu, 10 Nov 2005 14:45:50 +0100
From: Peter Sylvester <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: draft minutes (SCVP part)
References: <p06230900bf95711e723c@[128.89.89.106]> <[e-mail]> <p06230904bf96b8df23f8@[209.52.105.172]> <[e-mail]> <p06230908bf97e5a7fa62@[209.52.105.172]>
In-Reply-To: <p06230908bf97e5a7fa62@[209.52.105.172]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070605070908040502050701"
Sender: [e-mail]
Precedence: 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 cryptographically signed message in MIME format.

--------------ms070605070908040502050701
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


SCVP-21 was made as a result of a discussion of one hour between Tim, 
Denis and me, where
Tim took notes.

During three months there was no exchange to clarify anything. one week 
before
the deadline of the submission we were informed about an editors draft 
and had three
days to comment, the obvious thing was that several points were 
misunderstood
or that the authors were afraid to change something, or they referred to 
existing
implementations, etc. Nothing, really nothing to explain what is wrong, 
in particular
when some requests have been partially treated and retreated in the past.
I don't think that it is unfair to ask why the authors (who are as I 
understand not implementors)
continue to find arguments other than technical to refuse request which they
technically already admit as useful, ending with a remark

Given the tone and content of your message, I have finally recognized that you 
will never be happy with SCVP (or any document I am involved with.)  You are 
clearly determined to disagree with whatever is in the specification, so I have 
given up on addressing your comments.  There are far too many demands on my time 
for such wasted effort.  I have got to concentrate my efforts where they have 
*some* chance of success.


SCVP 21 finally after years of pointing to the requirement
a server can return another SCVP response. Good.

There is the n-th iterator of changed handling identities in the request 
and
response, resulting this time in a respondername in a request,
the encodings and semantics of the fields were changed
from octet strings to generalname, good, but, I did only see recently
that two drafts ago an already existing responder identity in the request
was removed.

It is not very pleasing to see, first, total rejection, then partial 
support,
then a bit more, then partial removal, etc. It may be that my request
is totally uninterpretable or what?


Peter


-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. 


--------------ms070605070908040502050701
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC
BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G
A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs
UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx
CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ
S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu
ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo
VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq
q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID
AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5
MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT
VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F
ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV
HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA
A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U
TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8
1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5
V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9
F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely
LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+
udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr
LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy
MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp
Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA
ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN
LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy
x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm
T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl
Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl
ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F
ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx
cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI
hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2
mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT
g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ
bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4
88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8
oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI
MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m
JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0
MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV
HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3
UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy
4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz
QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u
US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj
PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq
Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf
Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y
rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6
PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL
d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18
k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg
d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD
VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ
S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMTEwMTM0NTUwWjAjBgkqhkiG9w0B
CQQxFgQUXyEukMzISAjjbhjZr1Ce12FiMmQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY
MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy
c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE
ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ
IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAJHXKNMY8ugRCcRWw
Gk/pFJC0VCqzZSLAf53uzuzho2u/X8mPrX5gnc+X9nOxqWMdIyWyyQBxtkMPKCfoWsSxsK3o
IzX14Z23B6Z6BXWhp/o080aw4I7mYe9T1aN3AO+VYop97y7CSmJFwU/xui70iK52erFMGgC+
URUK9fHhkx8AAAAAAAA--------------ms070605070908040502050701--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA9LT8DU094657; Wed, 9 Nov 2005 13:29:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA9LT8sQ094656; Wed, 9 Nov 2005 13:29:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA9LT6jN094646 for <[e-mail]>; Wed, 9 Nov 2005 13:29:07 -0800 (PST) (envelope-from [e-mail])
Received: from [209.52.105.172] (dommiel.bbn.com [192.1.122.15]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id jA9LStIC023063; Wed, 9 Nov 2005 16:28:56 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p06230908bf97e5a7fa62@[209.52.105.172]>
In-Reply-To: <[e-mail]>
References: <p06230900bf95711e723c@[128.89.89.106]> <[e-mail]> <p06230904bf96b8df23f8@[209.52.105.172]> <[e-mail]>
Date: Wed, 9 Nov 2005 16:28:18 -0500
To: Peter Sylvester <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: draft minutes (SCVP part)
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: 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,

I reread your message and realize that when you used the phrase "... 
the notes taken by Tim Polk ..." you were not referring to the 
meeting minutes. My error. I had assumed you were, because the 
message was sent with a subject line of "draft minutes (SCVP part)."

>...
>Do you want me to resend?
>
I would like the material I requested in the private message re SCVP, 
sent a a private response. The 6 points in your message don't follow 
the format of what I requested, i.e., reference to section of 
SCVP-21, explanation of why is is not compliant with 3379 OR with a 
request that you or Denis made in subsequent messages. None of the 
points references a section number in SCVP-21, nor provides cross 
references to 3379, for example.

steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA9B0N2I099109; Wed, 9 Nov 2005 03:00:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA9B0Nuf099108; Wed, 9 Nov 2005 03:00:23 -0800 (PST)
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.11/8.12.9) with ESMTP id jA9B0MB0099101 for <[e-mail]>; Wed, 9 Nov 2005 03:00:23 -0800 (PST) (envelope-from [e-mail])
Received: from champagne.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id jA9B0Di10947; Wed, 9 Nov 2005 12:00:13 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/2.4); Wed, 9 Nov 2005 12:00:13 +0100 (MET)
Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id MAA15297; Wed, 9 Nov 2005 12:00:12 +0100 (MET)
Message-ID: <[e-mail]>
Date: Wed, 09 Nov 2005 12:00:12 +0100
From: Peter Sylvester <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: draft minutes (SCVP part)
References: <p06230900bf95711e723c@[128.89.89.106]> <[e-mail]> <p06230904bf96b8df23f8@[209.52.105.172]>
In-Reply-To: <p06230904bf96b8df23f8@[209.52.105.172]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080704030206020704070507"
Sender: [e-mail]
Precedence: 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 cryptographically signed message in MIME format.

--------------ms080704030206020704070507
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Stephen Kent wrote:

> Peter,
>
> First, I am the editor of the minutes, not Tim.

Did I say that?

>
> I'm afraid that your comments are not germane to the meeting minutes, 
> the primary goal of which is to accurately represent what was said by 
> the presenters and WG attendees in the course of the meeting. 
> Objective, factual errors related to what was said are valid a basis 
> for comments on meeting minutes. However, a detailed debate about a 
> contentious issue like this is not appropriate for meeting minute 
> comments & corrections.

Indeed, this is not a comment for minutes.

Throw into a black hole, wait until they evaporate as a part of
the detailed discussion. You have asked in a private message
to send a comment, you may thus just consider that I have forgotten
to change the comment into something more appropriate and that
I used the minutes as a starting point.

Do you want me to resend?


-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. 


--------------ms080704030206020704070507
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC
BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G
A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs
UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx
CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ
S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu
ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo
VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq
q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID
AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5
MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT
VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F
ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV
HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA
A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U
TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8
1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5
V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9
F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely
LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+
udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr
LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy
MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp
Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA
ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN
LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy
x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm
T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl
Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl
ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F
ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx
cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI
hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2
mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT
g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ
bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4
88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8
oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI
MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m
JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0
MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV
HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3
UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy
4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz
QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u
US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj
PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq
Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf
Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y
rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6
PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL
d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18
k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg
d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD
VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ
S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMTA5MTEwMDEyWjAjBgkqhkiG9w0B
CQQxFgQUI8cZmH5H6uttxGAqipkHQAdHGsUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY
MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy
c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE
ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ
IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAMEpccY5SlodwoJ1Y
zrNUcgi+Tb8sWANQx83/d6CPXzItoe2ToYB3VE/AA5/rN32f0vDJgZkH5H7VWd2AJNZempMg
qUpwC2MzIm0BwFz+6pLzDxHXsXq3+OWXDE7DnKrY+w8069tyiKgZ3ZxS9Lz7+vA+UIZdk8MX
VaAuWEzeNgwAAAAAAAA--------------ms080704030206020704070507--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA92Ouxs012259; Tue, 8 Nov 2005 18:24:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA92OuJe012258; Tue, 8 Nov 2005 18:24:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA92Otk9012168 for <[e-mail]>; Tue, 8 Nov 2005 18:24:55 -0800 (PST) (envelope-from [e-mail])
Received: from [209.52.105.172] (dommiel.bbn.com [192.1.122.15]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id jA92OcIC006854 for <[e-mail]>; Tue, 8 Nov 2005 21:24:45 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p06230905bf970e520849@[209.52.105.172]>
Date: Tue, 8 Nov 2005 21:24:51 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: WG meeting presentations now posted
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

https://onsite.ietf.org/public/meeting_materials.cgi?meeting_numd



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA8KX0bj058875; Tue, 8 Nov 2005 12:33:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA8KX0rm058874; Tue, 8 Nov 2005 12:33:00 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA8KWxfn058804 for <[e-mail]>; Tue, 8 Nov 2005 12:33:00 -0800 (PST) (envelope-from [e-mail])
Received: from [209.52.105.172] (dommiel.bbn.com [192.1.122.15]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id jA8KWpIC022617; Tue, 8 Nov 2005 15:32:51 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p06230904bf96b8df23f8@[209.52.105.172]>
In-Reply-To: <[e-mail]>
References: <p06230900bf95711e723c@[128.89.89.106]> <[e-mail]>
Date: Tue, 8 Nov 2005 15:32:28 -0500
To: Peter Sylvester <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: draft minutes (SCVP part)
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: 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,

First, I am the editor of the minutes, not Tim.

I'm afraid that your comments are not germane to the meeting minutes, 
the primary goal of which is to accurately represent what was said by 
the presenters and WG attendees in the course of the meeting. 
Objective, factual errors related to what was said are valid a basis 
for comments on meeting minutes. However, a detailed debate about a 
contentious issue like this is not appropriate for meeting minute 
comments & corrections.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA8Jd29k052659; Tue, 8 Nov 2005 11:39:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA8Jd2mk052658; Tue, 8 Nov 2005 11:39:02 -0800 (PST)
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.11/8.12.9) with ESMTP id jA8Jd1ei052651 for <[e-mail]>; Tue, 8 Nov 2005 11:39:02 -0800 (PST) (envelope-from [e-mail])
Received: from champagne.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id jA8Jcji27280; Tue, 8 Nov 2005 20:38:45 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/2.4); Tue, 8 Nov 2005 20:38:45 +0100 (MET)
Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id UAA14710; Tue, 8 Nov 2005 20:38:44 +0100 (MET)
Message-ID: <[e-mail]>
Date: Tue, 08 Nov 2005 20:38:44 +0100
From: Peter Sylvester <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: draft minutes (SCVP part)
References: <p06230900bf95711e723c@[128.89.89.106]>
In-Reply-To: <p06230900bf95711e723c@[128.89.89.106]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090104030100020405010305"
Sender: [e-mail]
Precedence: 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 cryptographically signed message in MIME format.

--------------ms090104030100020405010305
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Stephen Kent wrote:

> Please send me a message with any requested corrections before 11/28:
>
> Steve
> -----
>
>
> PKIX WG Meeting 11/7/05
>
> Edited by Steve Kent
>
>
>
> SCVP rev 21- David Cooper (NIST)
>        Text was added to clarify conformance requirements. WantBack 
> items were made optional. New, optional items were added to allow an 
> SCVP server to relay responses from other SCVP servers, and to label 
> responses with an identity specified by a requestor, if the server has 
> multiple identities. The reference to validation policies was 
> tightened, so that only OIDs, not URIs, are accepted. Policy 
> parameters, in addition to validation algorithm parameters, are now 
> supported, but the optional validation policy attributes were removed, 
> since no examples have been provided and the need for this facility 
> was not well established.

The authors have spend three months to get out an editors after the 
Paris meeting and
after Denis and me spend an hour to explain Tim Polk our issues. During 
the following
months that was no interaction, and  just a week before the submission 
deadline, there
was a editors draft shown to us to comment it within three days. This 
draft showed that
the notes taken by Tim Polk do not reflect the issues, and, not 
surprisong, they were either
ignored or only partially interpreted.

The mentioned 'server has multiple identities' has never been stated as 
such, and the requested
implementation (something which I have been asking for since years) is 
continuously misunderstood,
either refused, then partially implement, and then withdrawn.

Point 1:

What I have been requesting is that the CVrequest, and the CVResponse 
carry two sequences
of identifiers for the requestors and the responders.

For the CVRequest, the requestorName sequence indicates who is acting as 
client or for whom
the client is acting. A server may use the list to determine whether one 
of the authentication
methods matches with one of the entities.

For the CVRequest, the responderName sequence indicates who the client 
believs should participate
in the response. (this seems to be close to the current text). But the 
indication should be
a list, in order to allow for proxies chaining or other. it is up to the 
server to determine
what to do with the field, and how to respond with an appropriate 
authentication method.

For the CVResponse, the the requestorName sequence is essentially a copy 
of the last CVrequest
(e.g. if chaining was used). The server may add an identification, if 
the initial client has not
provide one, and if it can be derived from a networking identification 
or an authentication method,
all this controlled by a policy where a client can be allowed to stay 
anonymous through a proxy.

For the CVResponse, the the responderName sequence (a responder field 
had been introduced in the
past and then removed again), indicates the identities of parties that 
have participated in the
creation of the response. This allows a client to show them immediately 
without the need of
interpreting the details of the result which is difficult if not 
impossible in case of muiltiple
identities of servers.

The various drafts cover all this partially, but each time only a part, 
a different one.

Or,  in

    CVRequest ::= SEQUENCE {
      cvRequestVersion        INTEGER DEFAULT 1,
      query                   Query,
      requestorRef        [0] GeneralNames OPTIONAL,
      requestNonce        [1] OCTET STRING OPTIONAL,
      requestorName       [2] GeneralName OPTIONAL,
      responderName       [3] GeneralName OPTIONAL,
      requestExtensions   [4] Extensions OPTIONAL }


   CVResponse ::= SEQUENCE {
      cvResponseVersion         INTEGER,
      serverConfigurationID     INTEGER,
      producedAt                GeneralizedTime,
      responseStatus            ResponseStatus,
      respValidationPolicy  [0] RespValidationPolicy OPTIONAL,
      requestRef            [1] RequestReference OPTIONAL,
      requestorRef          [2] GeneralNames OPTIONAL,
      requestorName         [3] GeneralNames OPTIONAL,
      replyObjects          [4] ReplyObjects OPTIONAL,
      respNonce             [5] OCTET STRING OPTIONAL,
      serverContextInfo     [6] OCTET STRING OPTIONAL,
      cvResponseExtensions  [7] Extensions OPTIONAL }


there should be

      requestorName         [x] GeneralNames OPTIONAL,
      responderName         [y] GeneralNames OPTIONAL,

(There was once a responder in the response structure.)

Point 2:

I have asked to explain the need for the  MUST concerning

 If the default values for all of the flags are used, then the
  response flags item MUST NOT be included in the request.

    responseFlags           ResponseFlags OPTIONAL,

you can have the same effect using

    responseFlags           ResponseFlags DEFAULT {} ,

(modulo syntax errors introduced by my limited knowledge).

i.e. a MUST important for interop test is replaced by a standard feature 
of ASN.1

My suggestion of  'elegance', i.e. the one that I made a strawman in Paris
was to change the definition of

    ResponseFlags ::= SEQUENCE {
      fullRequestInResponse      [0] BOOLEAN DEFAULT FALSE,
      responseValidationPolByRef [1] BOOLEAN DEFAULT TRUE,
      protectResponse            [2] BOOLEAN DEFAULT TRUE,
      cachedResponse             [3] BOOLEAN DEFAULT TRUE }

to a bitstring with named values, and thus avoiding nested DEFAULT specs.
I can live with that, just write the DEFAULT as indicated above, and you 
have one
test les for interop. On the other hand, there are compilers that may have
problems with nested defaults. so

    ResponseFlags ::= BIT STRING {
      fullRequestInResponse(0),         responseValidationPolByRef(1)
      protectResponse(2)
      cachedResponse (3) }

and an appropriate DEFAULT 
(responseValidationPolByRef,protectResponse,cachedResponse)
or DEFAULT '0111'B

I repeat, the original point is the MUST about the empty sequence 
implying an
unncessary addition explicit test for conformance which you can handle by a
spec of DEFAULT { }.

point 3;

After 2 years or so, none of the authors ever answered why there is:

ReplyWantBacks ::= SEQUENCE OF ReplyWantBack

    ReplyWantBack::= SEQUENCE {
      wb                         OBJECT IDENTIFIER,
      value                      OCTET STRING }


where some of the octet strings contain certificat lists and crls for 
example.
What is the security risk or advantage to force client to invoke a parser
individually each time.

I simply propose:

    ReplyWantBack::= SEQUENCE {
      wbType                       OBJECT IDENTIFIER,
      wbValue                      ANY DEFINED BY wbType }

(or in fact the correct corresponding current ASN.1 which may be a
bit difficult to understand for some people.)

There are minimal changes in the text that follows this definition, i.e.
instead of saying the octet string contains you says the type used is ...


Compare this with a similar construct in the request.

    RevocationInfo ::= CHOICE {
      crl                    [0] CertificateList,
      delta-crl              [1] CertificateList,
      ocsp                   [2] OCSPResponse,
      other                  [3] OtherRevInfo }

    OtherRevInfo ::= SEQUENCE {
      riType                     OBJECT IDENTIFIER,
      riValue                    ANY DEFINED BY riType }


Point 4:

Use current ASN1. Free tools to validate the syntax exist.

Point 5:
Policy issues: I leave this mainly to Denis, but IMO the policy definitions
are intended to be usable for a client to determine *ALL* the required 
or possible
parameters. By no way it is acceptable that a client try be required to 
make
a trial to detrmline whether a something is necessary or required. Otherwise
the whole point of having a protocol for policy discovery is useless.

Point 6:

Since this is ther from the very beginning, some error codes are represented
as integer, although one would rather use an enumeration. Integers are
for values that be be used for counting. But well, I won't die because 
of that.

>
> The one remaining problem here is how to make this protocol agile with 
> regard to the hash algorithm employed for certificate references. 
> Today SHA-1 is hardwired. Updating the spec to specify another hash 
> function does not satisfy the new algorithm agility requirement. Steve 
> Kent suggested that the hash function can be an aspect of the server's 
> validation policy, to satisfy the agility requirement. Russ Housley 
> suggested that the OID of the hash employed be explicitly returned, in 
> case the server's policy changes over time (but the policy OID does 
> not). A straw poll was conducted to get a sense of the room for the 
> two alternatives described in the last slide in this presentation. The 
> first alternative received 12 votes, vs. 0 for the second. (Slides)

Why are these alternatives?

A client should be able to detect CURRENT hash algorithm in a policy 
lookup.

A server response and request are self containing entities. No 
additional information
should be required to interprete the content, in particular, it an octet 
string containing
a hash always needs to be accompanied by an algorithm identifier (unless 
the the protocol
or version specific default is used.

Peter


-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. 


--------------ms090104030100020405010305
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC
BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G
A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs
UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx
CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ
S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu
ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo
VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq
q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID
AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5
MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT
VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F
ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV
HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA
A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U
TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8
1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5
V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9
F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely
LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+
udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr
LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy
MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp
Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA
ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN
LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy
x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm
T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl
Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl
ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F
ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx
cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI
hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2
mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT
g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ
bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4
88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8
oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI
MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m
JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0
MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV
HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3
UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy
4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz
QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u
US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj
PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq
Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf
Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y
rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6
PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL
d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18
k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg
d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD
VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ
S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMTA4MTkzODQ0WjAjBgkqhkiG9w0B
CQQxFgQU7WgM/2+iIGWUS7f6MGIyFYos2LcwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY
MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy
c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE
ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ
IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAoH/r4Ckyp06PXQIY
s3K+niDo+kHlbzF8mm7iwogYKOqPzcQwt/8g5E5dMszuU1WITomrhcFpkbe1A0V1JQeXDaR0
qxiDDIwwsbp2iKJFLJMxsxgI7+uqlMRquKNVnsMSMTu5O2OZ+8RRZmpyg+uPG5eeeUZkIXye
SvOvawCwBXwAAAAAAAA--------------ms090104030100020405010305--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA8JaM8G052468; Tue, 8 Nov 2005 11:36:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA8JaMKe052467; Tue, 8 Nov 2005 11:36:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-30.mail.demon.net (anchor-post-30.mail.demon.net [194.217.242.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA8JaLan052460 for <[e-mail]>; Tue, 8 Nov 2005 11:36:21 -0800 (PST) (envelope-from [e-mail])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.2]) by anchor-post-30.mail.demon.net with esmtp (Exim 4.42) id 1EZZGV-000IHu-31 for [e-mail]; Tue, 08 Nov 2005 19:36:20 +0000
Message-ID: <[e-mail]>
Date: Tue, 08 Nov 2005 19:36:41 +0000
From: Dr Stephen Henson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: OCSP revision
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.92.0.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>

Carl Wallace wrote:

> At the meeting yesterday, OCSP revisions to address algorithm agility were
> discussed.  Since the doc is being revised, I suggest an extension or field
> be added to enable clients to ask the responder to include the responder's
> certificate in the response (similar to the certReq field in RFC3161).  
> 

Could other OCSP revisions be incorporated at the same time or just
"algorithm agility"?

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [e-mail], PGP key: via homepage.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA8IqMNQ047852; Tue, 8 Nov 2005 10:52:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA8IqMGR047851; Tue, 8 Nov 2005 10:52:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA8IqLIk047845 for <[e-mail]>; Tue, 8 Nov 2005 10:52:22 -0800 (PST) (envelope-from [e-mail])
Received: from wcwallace (pp110-146.bctel.ca [209.52.110.146]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id jA8IqJh8006705 for <[e-mail]>; Tue, 8 Nov 2005 13:52:20 -0500
Message-Id: <[e-mail]>
From: "Carl Wallace" <[e-mail]>
To: <[e-mail]>
Subject: OCSP revision
Date: Tue, 8 Nov 2005 13:52:20 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcXklYwiQ8sOu2HPT52Ro6Z8EtHhsA=
Sender: [e-mail]
Precedence: 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 the meeting yesterday, OCSP revisions to address algorithm agility were
discussed.  Since the doc is being revised, I suggest an extension or field
be added to enable clients to ask the responder to include the responder's
certificate in the response (similar to the certReq field in RFC3161).  



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA7MF4Y2030009; Mon, 7 Nov 2005 14:15:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA7MF4fQ030007; Mon, 7 Nov 2005 14:15:04 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA7MF4Td029864 for <[e-mail]>; Mon, 7 Nov 2005 14:15:04 -0800 (PST) (envelope-from [e-mail])
Received: from [209.52.105.172] (dommiel.bbn.com [192.1.122.15]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id jA7MCxIC000314 for <[e-mail]>; Mon, 7 Nov 2005 17:13:45 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p06230900bf95711e723c@[128.89.89.106]>
Date: Mon, 7 Nov 2005 16:03:57 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: draft minutes
Content-Type: multipart/alternative; boundary="======_-1080720781=_ma======"
X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Please send me a message with any requested corrections before 11/28:

Steve
-----


PKIX WG Meeting 11/7/05

Edited by Steve Kent

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

The PKIX WG met once during the 64th IETF. A total of approximately 
45 individuals participated in the meeting.


Document status - Tim Polk (NIST)
Three RFCs just issued: 4158, 4210, and 4211.
Three documents in the RFC editor's queue: CertStore HTTP, 3770bis, 
and CRL AIA.
Two documents with the ADs: AC Policies & PKIX Repository Locator.
Other documents:
-	SIM is undergoing revisions to address WG co-chair comments 
before being forwarded to the IESG.
-	The authors are being asked to create a matrix
-	A new version of 3280bis will be submitted after this meeting.
-	The WG chairs have requested a new version of the GOST 
algorithms to be posted, before initiating a last call
(Slides)


PKIX WG Document Presentations


RFC 2797bis, CMC transport, and CMC Compliance - Jim Schaad (Soaring Hawk)
Last call will be initiated for all three after this meeting. Updates 
include features to support SIM certificate requests. (Slides)


SCVP rev 21- David Cooper (NIST)
	Text was added to clarify conformance requirements. WantBack 
items were made optional. New, optional items were added to allow an 
SCVP server to relay responses from other SCVP servers, and to label 
responses with an identity specified by a requestor, if the server 
has multiple identities. The reference to validation policies was 
tightened, so that only OIDs, not URIs, are accepted. Policy 
parameters, in addition to validation algorithm parameters, are now 
supported, but the optional validation policy attributes were 
removed, since no examples have been provided and the need for this 
facility was not well established.

The one remaining problem here is how to make this protocol agile 
with regard to the hash algorithm employed for certificate 
references. Today SHA-1 is hardwired. Updating the spec to specify 
another hash function does not satisfy the new algorithm agility 
requirement. Steve Kent suggested that the hash function can be an 
aspect of the server's validation policy, to satisfy the agility 
requirement. Russ Housley suggested that the OID of the hash employed 
be explicitly returned, in case the server's policy changes over time 
(but the policy OID does not). A straw poll was conducted to get a 
sense of the room for the two alternatives described in the last 
slide in this presentation. The first alternative received 12 votes, 
vs. 0 for the second. (Slides)
    

SHA-1 Collisions & OCSP - Russ Housley (Vigil Security)
	 Based on the recent NIST hash workshop, Russ suggests that 
we begin making plans to move away from  SHA-1, with a 2010 target 
for transition. NIST will begin work on a successor to SHA-256, but a 
new algorithm may be 5 years away. The only good alternative now is 
SHA-256.

	From an algorithm agility perspective, OCSP request/response 
exchange needs to provide a way for the requestor to know which 
algorithms the responder (server) supports. This could be supported 
by adding a new protocol to negotiate the hash algorithm prior to 
entering into the OCSP exchange. Alternatively, the responder's 
certificate could have an extension that specified supported hash 
algorithms. This also might be addressed via configuration at the 
requestor, although this is problematic given the intent of changing 
the algorithm twice over the next 10 years. Russ suggests a request 
extension that allows the requestor to specify which hash functions 
(and signature algorithms) it supports. There is still a need to 
select one of the three approaches cited above, to allow a requestor 
to determine which algorithms are supported by the responder.

	Russ suggests that the WG find volunteers to update OCSP, and 
to examine other PKIX protocols to determine whether they exhibit 
similar problems and, if so, how to fix them. Stephen Farrell asks 
whether there may be a way to solve this problem more generically, 
rather than engineering a solution for each protocol in PKIX, and in 
other WGs.  (Slides)


SHA-2 Support in PKIX - Tim Polk (NIST)
        We currently specify how to use SHA-2 (SHA-256 & SHA-512) for 
RSA (RFC 4055), but not for DSA or EC-DSA. Tim suggests that two new 
drafts be generated, one for DSA and one for ECDSA, because the two 
algorithms are at different stages of NIST publication. NIST has 
volunteered to write these two drafts, but additional co-editors are 
welcome. (Slides)
   

Service Names as Subject Alt Names - Stefan Santesson (Microsoft)
       The draft has been revised since its initial version. It no 
longer is bound as tightly to the DNS SRV record example. The 
assumption here is that the user (host) knows the service name and 
domain name and determines whether the server to which it connects is 
appropriate, based on the server's certificate. Steve Kent suggests 
that we need to revisit the security implications of use of this 
facility, given the revised definition of the use model. Stefan 
suggests that use of name constraints for this extension may be 
appropriate. Since the string comparison is against the locally 
configured service name, not the DNS SRV string, UTF8 seems to be the 
right encoding choice. (Slides)


Related Specifications & Liaison Presentations

Carl Wallace (Orion Security) - LTANS WG status
	LTANS is meeting the same day (in the same room) at this 
IETF. Carl requests review by PKIX WG members of the evidence record 
I-D and an archive protocol I-D from LTANS. Note potential 
relationships between SCVP and LTNANS work.  (no slides)
--======_-1080720781=_ma======
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>draft minutes</title></head><body>
<div>Please send me a message with any requested corrections before
11/28:</div>
<div><br></div>
<div>Steve</div>
<div>-----</div>
<div><br></div>
<div><font face="Times New Roman" size="+1" color="#000000"><br>
</font><font color="#000000">PKIX WG Meeting 11/7/05<br>
<br>
Edited by Steve Kent<br>
<br>
Chairs: Stephen Kent &lt;[e-mail]&gt; &amp; Tim Polk
&lt;[e-mail]&gt;<br>
<br>
The PKIX WG met once during the 64th IETF. A total of approximately 45
individuals participated in the meeting.<br>
<br>
<br>
Document status - Tim Polk (NIST)<br>
Three RFCs just issued: 4158, 4210, and 4211.<br>
Three documents in the RFC editor's queue: CertStore HTTP, 3770bis,
and CRL AIA.<br>
Two documents with the ADs: AC Policies &amp; PKIX Repository
Locator.<br>
Other documents:<br>
-<font face="Arial"><x-tab>&nbsp;&nbsp; </x-tab></font>SIM is
undergoing revisions to address WG co-chair comments before being
forwarded to the IESG.<br>
-<font face="Arial"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab></font>The authors are being asked to create a matrix<br>
-<font face="Arial"><x-tab> </x-tab></font>A new version of 3280bis
will be submitted after this meeting.<br>
-<font face="Arial"><x-tab> </x-tab></font>The WG chairs have
requested a new version of the GOST algorithms to be posted, before
initiating a last call<br>
(Slides)<br>
<br>
<br>
PKIX WG Document Presentations<br>
<br>
<br>
RFC 2797bis, CMC transport, and CMC Compliance - Jim Schaad (Soaring
Hawk)<br>
Last call will be initiated for all three after this meeting. Updates
include features to support SIM certificate requests. (Slides)<br>
<br>
<br>
SCVP rev 21- David Cooper (NIST)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Text was added to
clarify conformance requirements. WantBack items were made optional.
New, optional items were added to allow an SCVP server to relay
responses from other SCVP servers, and to label responses with an
identity specified by a requestor, if the server has multiple
identities. The reference to validation policies was tightened, so
that only OIDs, not URIs, are accepted. Policy parameters, in addition
to validation algorithm parameters, are now supported, but the
optional validation policy attributes were removed, since no examples
have been provided and the need for this facility was not well
established.<br>
<br>
The one remaining problem here is how to make this protocol agile with
regard to the hash algorithm employed for certificate references.
Today SHA-1 is hardwired. Updating the spec to specify another hash
function does not satisfy the new algorithm agility requirement. Steve
Kent suggested that the hash function can be an aspect of the server's
validation policy, to satisfy the agility requirement. Russ Housley
suggested that the OID of the hash employed be explicitly returned, in
case the server's policy changes over time (but the policy OID does
not). A straw poll was conducted to get a sense of the room for the
two alternatives described in the last slide in this presentation. The
first alternative received 12 votes, vs. 0 for the second.
(Slides)<br>
&nbsp;&nbsp;&nbsp;<br>
<br>
SHA-1 Collisions &amp; OCSP - Russ Housley (Vigil Security)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp; </x-tab> Based on the recent NIST hash
workshop, Russ suggests that we begin making plans to move away from&nbsp;
SHA-1, with a 2010 target for transition. NIST will begin work on a
successor to SHA-256, but a new algorithm may be 5 years away. The
only good alternative now is SHA-256.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>From an algorithm
agility perspective, OCSP request/response exchange needs to provide a
way for the requestor to know which algorithms the responder (server)
supports. This could be supported by adding a new protocol to
negotiate the hash algorithm prior to entering into the OCSP exchange.
Alternatively, the responder's certificate could have an extension
that specified supported hash algorithms. This also might be addressed
via configuration at the requestor, although this is problematic given
the intent of changing the algorithm twice over the next 10 years.
Russ suggests a request extension that allows the requestor to specify
which hash functions (and signature algorithms) it supports. There is
still a need to select one of the three approaches cited above, to
allow a requestor to determine which algorithms are supported by the
responder.<br>
<br>
<x-tab> </x-tab>Russ suggests that the WG find volunteers to update
OCSP, and to examine other PKIX protocols to determine whether they
exhibit similar problems and, if so, how to fix them. Stephen Farrell
asks whether there may be a way to solve this problem more
generically, rather than engineering a solution for each protocol in
PKIX, and in other WGs.&nbsp; (Slides)</font></div>
<div><font color="#000000"><br>
<br>
SHA-2 Support in PKIX - Tim Polk (NIST)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; We currently specify how to use
SHA-2 (SHA-256 &amp; SHA-512) for RSA (RFC 4055), but not for DSA or
EC-DSA. Tim suggests that two new drafts be generated, one for DSA and
one for ECDSA, because the two algorithms are at different stages of
NIST publication. NIST has volunteered to write these two drafts, but
additional co-editors are welcome. (Slides)<br>
&nbsp;&nbsp;<br>
<br>
Service Names as Subject Alt Names - Stefan Santesson (Microsoft)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The draft has been revised since its
initial version. It no longer is bound as tightly to the DNS SRV
record example. The assumption here is that the user (host) knows the
service name and domain name and determines whether the server to
which it connects is appropriate, based on the server's certificate.
Steve Kent suggests that we need to revisit the security implications
of use of this facility, given the revised definition of the use
model. Stefan suggests that use of name constraints for this extension
may be appropriate. Since the string comparison is against the locally
configured service name, not the DNS SRV string, UTF8 seems to be the
right encoding choice. (Slides)<br>
<br>
<br>
Related Specifications &amp; Liaison Presentations<br>
<br>
Carl Wallace (Orion Security) - LTANS WG status<br>
<x-tab> </x-tab>LTANS is meeting the same day (in the same room) at
this IETF. Carl requests review by PKIX WG members of the evidence
record I-D and an archive protocol I-D from LTANS. Note potential
relationships between SCVP and LTNANS work.&nbsp; (no
slides)</font></div>
</body>
</html>
--======_-1080720781=_ma======--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA7LRErX020755; Mon, 7 Nov 2005 13:27:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA7LRE4j020754; Mon, 7 Nov 2005 13:27:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA7LRDwf020731 for <[e-mail]>; Mon, 7 Nov 2005 13:27:13 -0800 (PST) (envelope-from [e-mail])
Received: from [209.52.105.172] (dommiel.bbn.com [192.1.122.15]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id jA7LPVIC027759 for <[e-mail]>; Mon, 7 Nov 2005 16:26:03 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p06230900bf95711e723c@[128.89.89.106]>
Date: Mon, 7 Nov 2005 16:03:57 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: draft minutes
Content-Type: multipart/alternative; boundary="======_-1080723712=_ma======"
X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Please send me a message with any requested corrections before 11/28:

Steve
-----


PKIX WG Meeting 11/7/05

Edited by Steve Kent

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

The PKIX WG met once during the 64th IETF. A total of approximately 
45 individuals participated in the meeting.


Document status - Tim Polk (NIST)
Three RFCs just issued: 4158, 4210, and 4211.
Three documents in the RFC editor's queue: CertStore HTTP, 3770bis, 
and CRL AIA.
Two documents with the ADs: AC Policies & PKIX Repository Locator.
Other documents:
-	SIM is undergoing revisions to address WG co-chair comments 
before being forwarded to the IESG.
-	The authors are being asked to create a matrix
-	A new version of 3280bis will be submitted after this meeting.
-	The WG chairs have requested a new version of the GOST 
algorithms to be posted, before initiating a last call
(Slides)


PKIX WG Document Presentations


RFC 2797bis, CMC transport, and CMC Compliance - Jim Schaad (Soaring Hawk)
Last call will be initiated for all three after this meeting. Updates 
include features to support SIM certificate requests. (Slides)


SCVP rev 21- David Cooper (NIST)
	Text was added to clarify conformance requirements. WantBack 
items were made optional. New, optional items were added to allow an 
SCVP server to relay responses from other SCVP servers, and to label 
responses with an identity specified by a requestor, if the server 
has multiple identities. The reference to validation policies was 
tightened, so that only OIDs, not URIs, are accepted. Policy 
parameters, in addition to validation algorithm parameters, are now 
supported, but the optional validation policy attributes were 
removed, since no examples have been provided and the need for this 
facility was not well established.

The one remaining problem here is how to make this protocol agile 
with regard to the hash algorithm employed for certificate 
references. Today SHA-1 is hardwired. Updating the spec to specify 
another hash function does not satisfy the new algorithm agility 
requirement. Steve Kent suggested that the hash function can be an 
aspect of the server's validation policy, to satisfy the agility 
requirement. Russ Housley suggested that the OID of the hash employed 
be explicitly returned, in case the server's policy changes over time 
(but the policy OID does not). A straw poll was conducted to get a 
sense of the room for the two alternatives described in the last 
slide in this presentation. The first alternative received 12 votes, 
vs. 0 for the second. (Slides)
    

SHA-1 Collisions & OCSP - Russ Housley (Vigil Security)
	 Based on the recent NIST hash workshop, Russ suggests that 
we begin making plans to move away from  SHA-1, with a 2010 target 
for transition. NIST will begin work on a successor to SHA-256, but a 
new algorithm may be 5 years away. The only good alternative now is 
SHA-256.

	From an algorithm agility perspective, OCSP request/response 
exchange needs to provide a way for the requestor to know which 
algorithms the responder (server) supports. This could be supported 
by adding a new protocol to negotiate the hash algorithm prior to 
entering into the OCSP exchange. Alternatively, the responder's 
certificate could have an extension that specified supported hash 
algorithms. This also might be addressed via configuration at the 
requestor, although this is problematic given the intent of changing 
the algorithm twice over the next 10 years. Russ suggests a request 
extension that allows the requestor to specify which hash functions 
(and signature algorithms) it supports. There is still a need to 
select one of the three approaches cited above, to allow a requestor 
to determine which algorithms are supported by the responder.

	Russ suggests that the WG find volunteers to update OCSP, and 
to examine other PKIX protocols to determine whether they exhibit 
similar problems and, if so, how to fix them. Stephen Farrell asks 
whether there may be a way to solve this problem more generically, 
rather than engineering a solution for each protocol in PKIX, and in 
other WGs.  (Slides)


SHA-2 Support in PKIX - Tim Polk (NIST)
        We currently specify how to use SHA-2 (SHA-256 & SHA-512) for 
RSA (RFC 4055), but not for DSA or EC-DSA. Tim suggests that two new 
drafts be generated, one for DSA and one for ECDSA, because the two 
algorithms are at different stages of NIST publication. NIST has 
volunteered to write these two drafts, but additional co-editors are 
welcome. (Slides)
   

Service Names as Subject Alt Names - Stefan Santesson (Microsoft)
       The draft has been revised since its initial version. It no 
longer is bound as tightly to the DNS SRV record example. The 
assumption here is that the user (host) knows the service name and 
domain name and determines whether the server to which it connects is 
appropriate, based on the server's certificate. Steve Kent suggests 
that we need to revisit the security implications of use of this 
facility, given the revised definition of the use model. Stefan 
suggests that use of name constraints for this extension may be 
appropriate. Since the string comparison is against the locally 
configured service name, not the DNS SRV string, UTF8 seems to be the 
right encoding choice. (Slides)


Related Specifications & Liaison Presentations

Carl Wallace (Orion Security) - LTANS WG status
	LTANS is meeting the same day (in the same room) at this 
IETF. Carl requests review by PKIX WG members of the evidence record 
I-D and an archive protocol I-D from LTANS. Note potential 
relationships between SCVP and LTNANS work.  (no slides)
--======_-1080723712=_ma======
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>draft minutes</title></head><body>
<div>Please send me a message with any requested corrections before
11/28:</div>
<div><br></div>
<div>Steve</div>
<div>-----</div>
<div><br></div>
<div><font face="Times New Roman" size="+1" color="#000000"><br>
</font><font color="#000000">PKIX WG Meeting 11/7/05<br>
<br>
Edited by Steve Kent<br>
<br>
Chairs: Stephen Kent &lt;[e-mail]&gt; &amp; Tim Polk
&lt;[e-mail]&gt;<br>
<br>
The PKIX WG met once during the 64th IETF. A total of approximately 45
individuals participated in the meeting.<br>
<br>
<br>
Document status - Tim Polk (NIST)<br>
Three RFCs just issued: 4158, 4210, and 4211.<br>
Three documents in the RFC editor's queue: CertStore HTTP, 3770bis,
and CRL AIA.<br>
Two documents with the ADs: AC Policies &amp; PKIX Repository
Locator.<br>
Other documents:<br>
-<font face="Arial"><x-tab>&nbsp;&nbsp; </x-tab></font>SIM is
undergoing revisions to address WG co-chair comments before being
forwarded to the IESG.<br>
-<font face="Arial"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab></font>The authors are being asked to create a matrix<br>
-<font face="Arial"><x-tab> </x-tab></font>A new version of 3280bis
will be submitted after this meeting.<br>
-<font face="Arial"><x-tab> </x-tab></font>The WG chairs have
requested a new version of the GOST algorithms to be posted, before
initiating a last call<br>
(Slides)<br>
<br>
<br>
PKIX WG Document Presentations<br>
<br>
<br>
RFC 2797bis, CMC transport, and CMC Compliance - Jim Schaad (Soaring
Hawk)<br>
Last call will be initiated for all three after this meeting. Updates
include features to support SIM certificate requests. (Slides)<br>
<br>
<br>
SCVP rev 21- David Cooper (NIST)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Text was added to
clarify conformance requirements. WantBack items were made optional.
New, optional items were added to allow an SCVP server to relay
responses from other SCVP servers, and to label responses with an
identity specified by a requestor, if the server has multiple
identities. The reference to validation policies was tightened, so
that only OIDs, not URIs, are accepted. Policy parameters, in addition
to validation algorithm parameters, are now supported, but the
optional validation policy attributes were removed, since no examples
have been provided and the need for this facility was not well
established.<br>
<br>
The one remaining problem here is how to make this protocol agile with
regard to the hash algorithm employed for certificate references.
Today SHA-1 is hardwired. Updating the spec to specify another hash
function does not satisfy the new algorithm agility requirement. Steve
Kent suggested that the hash function can be an aspect of the server's
validation policy, to satisfy the agility requirement. Russ Housley
suggested that the OID of the hash employed be explicitly returned, in
case the server's policy changes over time (but the policy OID does
not). A straw poll was conducted to get a sense of the room for the
two alternatives described in the last slide in this presentation. The
first alternative received 12 votes, vs. 0 for the second.
(Slides)<br>
&nbsp;&nbsp;&nbsp;<br>
<br>
SHA-1 Collisions &amp; OCSP - Russ Housley (Vigil Security)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp; </x-tab> Based on the recent NIST hash
workshop, Russ suggests that we begin making plans to move away from&nbsp;
SHA-1, with a 2010 target for transition. NIST will begin work on a
successor to SHA-256, but a new algorithm may be 5 years away. The
only good alternative now is SHA-256.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>From an algorithm
agility perspective, OCSP request/response exchange needs to provide a
way for the requestor to know which algorithms the responder (server)
supports. This could be supported by adding a new protocol to
negotiate the hash algorithm prior to entering into the OCSP exchange.
Alternatively, the responder's certificate could have an extension
that specified supported hash algorithms. This also might be addressed
via configuration at the requestor, although this is problematic given
the intent of changing the algorithm twice over the next 10 years.
Russ suggests a request extension that allows the requestor to specify
which hash functions (and signature algorithms) it supports. There is
still a need to select one of the three approaches cited above, to
allow a requestor to determine which algorithms are supported by the
responder.<br>
<br>
<x-tab> </x-tab>Russ suggests that the WG find volunteers to update
OCSP, and to examine other PKIX protocols to determine whether they
exhibit similar problems and, if so, how to fix them. Stephen Farrell
asks whether there may be a way to solve this problem more
generically, rather than engineering a solution for each protocol in
PKIX, and in other WGs.&nbsp; (Slides)</font></div>
<div><font color="#000000"><br>
<br>
SHA-2 Support in PKIX - Tim Polk (NIST)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; We currently specify how to use
SHA-2 (SHA-256 &amp; SHA-512) for RSA (RFC 4055), but not for DSA or
EC-DSA. Tim suggests that two new drafts be generated, one for DSA and
one for ECDSA, because the two algorithms are at different stages of
NIST publication. NIST has volunteered to write these two drafts, but
additional co-editors are welcome. (Slides)<br>
&nbsp;&nbsp;<br>
<br>
Service Names as Subject Alt Names - Stefan Santesson (Microsoft)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The draft has been revised since its
initial version. It no longer is bound as tightly to the DNS SRV
record example. The assumption here is that the user (host) knows the
service name and domain name and determines whether the server to
which it connects is appropriate, based on the server's certificate.
Steve Kent suggests that we need to revisit the security implications
of use of this facility, given the revised definition of the use
model. Stefan suggests that use of name constraints for this extension
may be appropriate. Since the string comparison is against the locally
configured service name, not the DNS SRV string, UTF8 seems to be the
right encoding choice. (Slides)<br>
<br>
<br>
Related Specifications &amp; Liaison Presentations<br>
<br>
Carl Wallace (Orion Security) - LTANS WG status<br>
<x-tab> </x-tab>LTANS is meeting the same day (in the same room) at
this IETF. Carl requests review by PKIX WG members of the evidence
record I-D and an archive protocol I-D from LTANS. Note potential
relationships between SCVP and LTNANS work.&nbsp; (no
slides)</font></div>
</body>
</html>
--======_-1080723712=_ma======--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA6NUiPk098220; Sun, 6 Nov 2005 15:30:44 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA6NUia6098219; Sun, 6 Nov 2005 15:30:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id jA6NUhc2098212 for <[e-mail]>; Sun, 6 Nov 2005 15:30:43 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 24131 invoked by uid 0); 6 Nov 2005 23:30:35 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (209.52.108.226) by woodstock.binhost.com with SMTP; 6 Nov 2005 23:30:35 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta)
Date: Sun, 06 Nov 2005 18:30:32 -0500
To: Terry Hayes <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: RE: Public key validation and Proof of possession
In-Reply-To: <[e-mail] m>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<html>
<body>
RFC 3280 says:<br><br>
&nbsp;&nbsp; To promote interoperability, this profile RECOMMENDS that
policy<br>
&nbsp;&nbsp; information terms consist of only an OID.&nbsp; Where an OID
alone is<br>
&nbsp;&nbsp; insufficient, this profile strongly recommends that use of
qualifiers<br>
&nbsp;&nbsp; be limited to those identified in this section.&nbsp; When
qualifiers are<br>
&nbsp;&nbsp; used with the special policy anyPolicy, they MUST be limited
to the<br>
&nbsp;&nbsp; qualifiers identified in this section.<br><br>
Russ<br><br>
At 04:18 PM 10/27/2005, Terry Hayes wrote:<br>
<blockquote type=cite class=cite cite="">What's wrong with defining a new
policy qualifier?<br>
&nbsp;<br>
id-qt-ietf-pkix-key-validation-performed<br>
id-qt-ietf-pkix-proof-of-posession-performed
(owner-posession-of-key-assured?)<br>
&nbsp;<br>
These would generally be asserted only in the end-entity
certificates.<br>
&nbsp;<br>
Terry Hayes<br><br>
&nbsp;<br>
On 10/27/05, <b>Stefan Santesson</b>
&lt;<a href="mailto:[e-mail]">[e-mail] </a>&gt;
wrote: <br>

<dl><br>

<dd>It is not a proposal.<br>

<dd>I just wanted to add it to the picture.<br><br>

<dd>I'm just generally worried about adding new extensions for every
<br>

<dd>specific certificate policy aspect that can be argued to be useful
to<br>

<dd>have explicitly encoded.<br><br>

<dd>If we go that path, we may need to consider a common framework for
it.<br>

<dd>qcStatement is one, suitable or not.<br><br>
<br>

<dd>Stefan Santesson<br>

<dd>Program Manager, Standards Liaison<br>

<dd>Windows Security<br><br>

</dl></blockquote></body>
</html>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA6NLHD5097332; Sun, 6 Nov 2005 15:21:17 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA6NLGln097331; Sun, 6 Nov 2005 15:21:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eagle.unknowndns.net (IDENT:U2FsdGVkX19kxnavTMOEWCPLDqz/[e-mail] [221.133.206.175]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA6NLEur097318 for <[e-mail]>; Sun, 6 Nov 2005 15:21:15 -0800 (PST) (envelope-from [e-mail])
Received: from cust3103.vic01.dataco.com.au ([202.63.62.31] helo=[192.168.1.156]) by eagle.unknowndns.net with esmtpa (Exim 4.52) id 1EYtod-0002J8-NO; Mon, 07 Nov 2005 09:20:48 +1000
Message-ID: <[e-mail]>
Date: Mon, 07 Nov 2005 10:20:46 +1100
From: Steven Legg <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tom Yu <[e-mail]>
CC: Peter Sylvester <[e-mail]>, =?ISO-8859-1?Q?Love_H?= =?ISO-8859-1?Q?örnquist_Åstrand?= <[e-mail]>, Tom Gindin <[e-mail]>, Sam Hartman <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - eagle.unknowndns.net
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - eb2bcom.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom,

Tom Yu wrote:
>>>>>>"Peter" = Peter Sylvester <[e-mail]> writes:
> 
> 
> Peter> Steven Legg wrote:
> 
> 
>>>Love, et al,
>>>
>>>Love Hörnquist Åstrand wrote:
>>>
>>>
>>>>Lets take another example:
>>>>
>>>>PA-PK-AS-REQ ::= SEQUENCE {
>>>>signedAuthPack          [0] IMPLICIT OCTET STRING,
>>>>-- Contains a CMS type ContentInfo encoded
>>>>-- according to [RFC3852].
>>>>-- The contentType field of the type ContentInfo
>>>>-- is id-signedData (1.2.840.113549.1.7.2),
>>>>-- and the content field is a SignedData.
>>>>
>>>>With you syntax this should be
>>>>
>>>>signedAuthPack IMPLICIT OCTET STRING OPTIONAL CONTAINING ContentInfo
>>>>
>>>>Now, ContentInfo in a CMS type, and is allowed to be encoded in BER.
>>>>Kerberos datatypes uses DER.
>>>>
>>>>How is that expressed in a formal way ?
>>>
>>>
>>>signedAuthPack IMPLICIT OCTET STRING
> 
> 
> "IMPLICIT" only goes after a tag, so the above should contain something
> like "[0] IMPLICIT"

Quite right. I was focussed on the constraint and didn't notice the tag
had been dropped.

or drop the IMPLICIT completely.  Dropping the
> context-specific tag would cause a change in wire encoding from
> pkinit-29.
> 
> 
>>>(CONTAINING ContentInfo
>>>ENCODED BY {joint-iso-itu-t asn(1) ber-derived(2)
>>>distinguished-encoding(1)})
>>>OPTIONAL
>>>
>>>The OID after the "ENCODED BY" is the OID that identifies DER.
> 
> 
> Except here, we are using a CMS message, which is permitted to be
> encoded in BER, and pkinit requires DER, so you really want something
> like
> 
> PA-PK-AS-REQ ::= SEQUENCE {
>     signedAuthPack [0] IMPLICIT OCTET STRING
>         (CONTAINING ContentInfo ENCODED BY {
>             joint-iso-itu-t asn1 (1) basic-encoding (1)
>         })
> }

I'm not an expert on this but it would seem that as far as pkinit is
concerned, the encoding of a ContentInfo value contained in the
signedAuthPack component of a PA-PK-AS-REQ value is always a DER
encoding. It doesn't matter what encoding rules CMS uses to encode
values of ContentInfo, and the constraint has no effect whatsoever
on encodings of ContentInfo values outside the signedAuthPack component.

> 
> You'll need to normatively reference X.682, because the "CONTAINING"
> constraint isn't in X.680.

Yes.

> 
> 
>>>>Just saying IMPORT and CONTANING and expect the right thing to
>>>>happen when
>>>>given to a compiler seems very naive.
>>>
>>>
>>>There's a better chance that the compiler can do something useful than if
>>>the requirements are expressed informally as a comment.
>>>
>>>Regards,
>>>Steven
>>>
>>>
>>>>Love
>>>>
> 
> 
> What one can expect from the compiler depends on what sort of compiler
> one is using.  The open-source ASN.1 toolkits with acceptable license
> conditions often omit much of the functionality of the full ASN.1
> standard.

And they always will if ASN.1 specifications always pander to the lowest
common denominator. Contents constraints are a nudge in the right direction.

Regards,
Steven

> 
> ---Tom
> 
> 
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA6K92Pt068073; Sun, 6 Nov 2005 12:09:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA6K92lA068072; Sun, 6 Nov 2005 12:09:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA6K8v0X068048 for <[e-mail]>; Sun, 6 Nov 2005 12:09:00 -0800 (PST) (envelope-from [e-mail])
Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Sun, 6 Nov 2005 21:08:50 +0100
Received: from [10.193.106.41] ([10.193.106.41]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Sun, 6 Nov 2005 21:08:50 +0100
Message-ID: <[e-mail]>
Date: Sun, 06 Nov 2005 21:08:49 +0100
From: Olivier Dubuisson <[e-mail]>
Organization: France Telecom - Research & Development
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography  for InitialAuthentication in Kerberos
References: <[e-mail]	m.com> <[e-mail]> 	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 06 Nov 2005 20:08:50.0510 (UTC) FILETIME=[E754C6E0:01C5E30D]
Sender: [e-mail]
Precedence: 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 wrote:
> 
> The message was not necessarily to promote AUTOMATIC, but a question
> why there is a different tagging regime involved which is not totally 
> respected
> because OCTET STRINGS are IMPLICIT tagged when the contain other
> syntaxes.

What do you mean here? Which clause of the ASN.1 standard states that 
"OCTET STRINGS are IMPLICIT tagged when the contain other syntaxes".
Also, what does "contain other syntaxes" mean? Do you mean "contain the 
encoding of an ASN.1 value"?
-- 
Olivier DUBUISSON
France Telecom
Recherche & Developpement
R&D/MAPS/AMS - 22307 Lannion Cedex - France
t: [phone] - f: [phone] - http://asn1.elibel.tm.fr/




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA6FJSbn017544; Sun, 6 Nov 2005 07:19:28 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA6FJShU017543; Sun, 6 Nov 2005 07:19:28 -0800 (PST)
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.11/8.12.9) with ESMTP id jA6FJRPC017536 for <[e-mail]>; Sun, 6 Nov 2005 07:19:28 -0800 (PST) (envelope-from [e-mail])
Received: from champagne.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id jA6FEIi09203; Sun, 6 Nov 2005 16:14:18 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/2.4); Sun, 6 Nov 2005 16:14:18 +0100 (MET)
Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id QAA12824; Sun, 6 Nov 2005 16:14:17 +0100 (MET)
Message-ID: <[e-mail]>
Date: Sun, 06 Nov 2005 16:14:17 +0100
From: Peter Sylvester <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Steven Legg <[e-mail]>
CC: [e-mail], Olivier Dubuisson <[e-mail]>, Tom Gindin <[e-mail]>, Sam Hartman <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for  InitialAuthentication in Kerberos
References: <[e-mail]	m.com> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010906020804060804020307"
Sender: [e-mail]
Precedence: 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 cryptographically signed message in MIME format.

--------------ms010906020804060804020307
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

BTW:

Since SNACC is mentioned. There is one application thta uses SNACC, and in
order to decode soem data encapsulated in an OCTET STRING the author
has changed the syntax to something like

[UNIVERSAL 4] IMPLICIT SEQUENCE {data TheType}

and then changed in the generated code the generation/parsing of the 
constructed
bit by hand. If the syntax would not have the addition OCTET STRING 
encapsulation
such a hack wouldn't be necessary.

Steven Legg wrote:

>
> Olivier Dubuisson wrote:
>
>> The right syntax is:
>> subjectName [0] IMPLICIT OCTET STRING(CONTAINING Name) OPTIONAL
>>
>> It would be even better to add an "ENCODED BY oid" after "CONTAINING 
>> Name" with 'oid' being the OID of the binary encoding rules used to 
>> encode 'Name'.
>>
>> But I can already hear some people saying: This is not supported by 
>> Snacc :(
>
>
> Since the constraint does not change the bits on the wire for BER the
> simple retort is: "If your ASN.1 compiler does not support
> CONTAINING constraints then comment them out". The hardship caused to
> users of dumber ASN.1 toolkits is negligible in a case like this.
>
> Regards,
> Steven
>
>


-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. 


--------------ms010906020804060804020307
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC
BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G
A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs
UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx
CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ
S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu
ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo
VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq
q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID
AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5
MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT
VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F
ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV
HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA
A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U
TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8
1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5
V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9
F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely
LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+
udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr
LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy
MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp
Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA
ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN
LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy
x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm
T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl
Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl
ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F
ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx
cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI
hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2
mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT
g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ
bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4
88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8
oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI
MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m
JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0
MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV
HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3
UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy
4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz
QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u
US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj
PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq
Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf
Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y
rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6
PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL
d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18
k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg
d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD
VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ
S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMTA2MTUxNDE3WjAjBgkqhkiG9w0B
CQQxFgQUXkmFoCfMQU9t0jvLQzhMmmi+Sj4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY
MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy
c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE
ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ
IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGA3oRSLPeYDnOUklXW
WEaa1X89m/rtXqILHB+TOKNIwDKIUrS85jAO2f9ceoxAK6ZbfEOu22Ct5F4IosL0djpWcOdd
WTJ3rh5cc5GRrqPsr5FQD2dknfEQe8yn5JewxT3W+GBil+ssMeOnmxX0HZ9WapWMTpeG7enB
eDMC8+IoYv8AAAAAAAA--------------ms010906020804060804020307--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA6FEN8d016747; Sun, 6 Nov 2005 07:14:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA6FENq0016746; Sun, 6 Nov 2005 07:14:23 -0800 (PST)
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.11/8.12.9) with ESMTP id jA6FEKGL016726 for <[e-mail]>; Sun, 6 Nov 2005 07:14:21 -0800 (PST) (envelope-from [e-mail])
Received: from champagne.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id jA6FEAi09188; Sun, 6 Nov 2005 16:14:10 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/2.4); Sun, 6 Nov 2005 16:14:10 +0100 (MET)
Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id QAA12820; Sun, 6 Nov 2005 16:14:09 +0100 (MET)
Message-ID: <[e-mail]>
Date: Sun, 06 Nov 2005 16:14:09 +0100
From: Peter Sylvester <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: Olivier Dubuisson <[e-mail]>, Tom Gindin <[e-mail]>, Sam Hartman <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography  for InitialAuthentication in Kerberos
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040409080102030803000206"
Sender: [e-mail]
Precedence: 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 cryptographically signed message in MIME format.

--------------ms040409080102030803000206
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

I think we may have a different opinion of what could be maintenance.
Feel free to explain.

Anyway, You can do exactly what AUTOMATIC does with concrete tags.

The message was not necessarily to promote AUTOMATIC, but a question
why there is a different tagging regime involved which is not totally 
respected
because OCTET STRINGS are IMPLICIT tagged when the contain other
syntaxes.


Russ Housley wrote:

>
> I find AUTOMATIC TAGS to be more difficult later down the line when 
> one is doing maintenance. In my opinion, it hides too much.
>
> Russ
>
> At 09:10 AM 11/3/2005, Olivier Dubuisson wrote:
>
>> Tom Gindin wrote:
>>
>>> If it isn't too late to fix this without breaking lots of 
>>> implementations, the ASN.1 in this specification is over-tagged. In 
>>> section 3.2.1, all three of the tags in PA-PK-AS-REQ are 
>>> unnecessary, and the one on signedAuthPack is actually slightly 
>>> harmful. None of the tags in PKAuthenticator do any good either. The 
>>> OCTET STRING wrappings for subjectName and issuerAndSerialNumber are 
>>> not really appropriate, and subjectName doesn't need a tag. Even in 
>>> AuthPack, pkAuthenticator and clientDHNonce don't need tags.
>>> Similarly, in 3.2.3, there is no reason for any of the tags in 
>>> PA-PK-AS-REP, DHRepInfo, or KDCDHKeyInfo. The tags in ReplyKeyPack 
>>> in 3.2.3.2 also seem unnecessary.
>>
>>
>> The easiest thing would be to put "AUTOMATIC TAGS" in the module 
>> header (instead of "EXPLICIT TAGS") and not bother with tags, for 
>> "AUTOMATIC TAGS" would tag where necessary. But I understand from 
>> another response that the Kerberos team doesn't want to deviate from 
>> their historical choice...
>> -- 
>> Olivier DUBUISSON
>> France Telecom
>> Recherche & Developpement
>> R&D/MAPS/AMS - 22307 Lannion Cedex - France
>> t: [phone] - f: [phone] - http://asn1.elibel.tm.fr/
>>
>>
>
>
>


-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. 


--------------ms040409080102030803000206
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC
BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G
A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs
UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx
CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ
S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu
ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo
VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq
q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID
AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5
MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT
VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F
ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV
HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA
A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U
TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8
1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5
V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9
F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely
LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+
udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr
LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy
MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp
Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA
ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN
LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy
x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm
T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl
Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl
ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F
ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx
cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI
hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2
mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT
g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ
bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4
88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8
oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI
MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m
JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0
MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV
HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3
UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy
4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz
QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u
US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj
PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq
Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf
Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y
rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6
PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL
d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18
k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg
d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD
VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ
S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMTA2MTUxNDA5WjAjBgkqhkiG9w0B
CQQxFgQUdiJuuUe23fyMeGgIc0uNbTWwtcgwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY
MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy
c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE
ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ
IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGA0XZGWr0Q+K7Xf6uQ
CNH0dTU3yDwCt3RQUf59e6GtjyfNo/Pz0h58ji2NOn82gsbQq8mGDkKWRZN6ISpuzhCHdZ0S
D+9FQXByJq1F7fZSqx15+UGSK9+OkdPDLYMsLgZc45gqOQtWIga1gL5YquaRU8H9U3aEIuO0
OoIT16EyrUYAAAAAAAA--------------ms040409080102030803000206--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA661vlF019064; Sat, 5 Nov 2005 22:01:57 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA661vBc019063; Sat, 5 Nov 2005 22:01:57 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA661rvh019040 for <[e-mail]>; Sat, 5 Nov 2005 22:01:54 -0800 (PST) (envelope-from [e-mail])
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id jA661G1p017779; Sun, 6 Nov 2005 01:01:19 -0500 (EST)
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bitsV) (User authenticated as [e-mail]) by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id jA66167c027217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NOT); Sun, 6 Nov 2005 01:01:07 -0500 (EST)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9) id jA6616S2020236; Sun, 6 Nov 2005 01:01:06 -0500 (EST)
To: Peter Sylvester <[e-mail]>
Cc: Steven Legg <[e-mail]>, =?iso-8859-1?q?Love_Hörnquist_Åstrand?= <[e-mail]>, Tom Gindin <[e-mail]>, Sam Hartman <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Tom Yu <[e-mail]>
Date: Sun, 06 Nov 2005 01:01:06 -0500
In-Reply-To: <[e-mail]> (Peter Sylvester's message of "Thu, 03 Nov 2005 10:37:49 +0100")
Message-ID: <[e-mail]>
Lines: 77
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
X-Spam-Score: 1.217
X-Spam-Level: * (1.217)
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id jA661svh019042
Sender: [e-mail]
Precedence: 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" = Peter Sylvester <[e-mail]> writes:

Peter> Steven Legg wrote:

>> Love, et al,
>> 
>> Love Hörnquist Åstrand wrote:
>> 
>>> Lets take another example:
>>> 
>>> PA-PK-AS-REQ ::= SEQUENCE {
>>> signedAuthPack          [0] IMPLICIT OCTET STRING,
>>> -- Contains a CMS type ContentInfo encoded
>>> -- according to [RFC3852].
>>> -- The contentType field of the type ContentInfo
>>> -- is id-signedData (1.2.840.113549.1.7.2),
>>> -- and the content field is a SignedData.
>>> 
>>> With you syntax this should be
>>> 
>>> signedAuthPack IMPLICIT OCTET STRING OPTIONAL CONTAINING ContentInfo
>>> 
>>> Now, ContentInfo in a CMS type, and is allowed to be encoded in BER.
>>> Kerberos datatypes uses DER.
>>> 
>>> How is that expressed in a formal way ?
>> 
>> 
>> signedAuthPack IMPLICIT OCTET STRING

"IMPLICIT" only goes after a tag, so the above should contain something
like "[0] IMPLICIT" or drop the IMPLICIT completely.  Dropping the
context-specific tag would cause a change in wire encoding from
pkinit-29.

>> (CONTAINING ContentInfo
>> ENCODED BY {joint-iso-itu-t asn(1) ber-derived(2)
>> distinguished-encoding(1)})
>> OPTIONAL
>> 
>> The OID after the "ENCODED BY" is the OID that identifies DER.

Except here, we are using a CMS message, which is permitted to be
encoded in BER, and pkinit requires DER, so you really want something
like

PA-PK-AS-REQ ::= SEQUENCE {
    signedAuthPack [0] IMPLICIT OCTET STRING
        (CONTAINING ContentInfo ENCODED BY {
            joint-iso-itu-t asn1 (1) basic-encoding (1)
        })
}

You'll need to normatively reference X.682, because the "CONTAINING"
constraint isn't in X.680.

>>> Just saying IMPORT and CONTANING and expect the right thing to
>>> happen when
>>> given to a compiler seems very naive.
>> 
>> 
>> There's a better chance that the compiler can do something useful than if
>> the requirements are expressed informally as a comment.
>> 
>> Regards,
>> Steven
>> 
>>> 
>>> Love
>>> 

What one can expect from the compiler depends on what sort of compiler
one is using.  The open-source ASN.1 toolkits with acceptable license
conditions often omit much of the functionality of the full ASN.1
standard.

---Tom



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA3Mu1bj047455; Thu, 3 Nov 2005 14:56:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA3Mu1YW047454; Thu, 3 Nov 2005 14:56:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eagle.unknowndns.net (IDENT:[e-mail] [221.133.206.175]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA3MtwZ3047438 for <[e-mail]>; Thu, 3 Nov 2005 14:55:59 -0800 (PST) (envelope-from [e-mail])
Received: from cust3103.vic01.dataco.com.au ([202.63.62.31] helo=[192.168.1.156]) by eagle.unknowndns.net with esmtpa (Exim 4.52) id 1EXnzq-0000iz-86; Fri, 04 Nov 2005 08:55:50 +1000
Message-ID: <[e-mail]>
Date: Fri, 04 Nov 2005 09:55:48 +1100
From: Steven Legg <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: Olivier Dubuisson <[e-mail]>, Peter Sylvester <[e-mail]>, Tom Gindin <[e-mail]>, Sam Hartman <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for  InitialAuthentication in Kerberos
References: <[e-mail]	m.com> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - eagle.unknowndns.net
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - eb2bcom.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Olivier Dubuisson wrote:
> The right syntax is:
> subjectName   [0] IMPLICIT OCTET STRING(CONTAINING Name) OPTIONAL
> 
> It would be even better to add an "ENCODED BY oid" after "CONTAINING 
> Name" with 'oid' being the OID of the binary encoding rules used to 
> encode 'Name'.
> 
> But I can already hear some people saying: This is not supported by 
> Snacc :(

Since the constraint does not change the bits on the wire for BER the
simple retort is: "If your ASN.1 compiler does not support
CONTAINING constraints then comment them out". The hardship caused to
users of dumber ASN.1 toolkits is negligible in a case like this.

Regards,
Steven



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA3GHGbg094906; Thu, 3 Nov 2005 08:17:17 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA3GHGjU094905; Thu, 3 Nov 2005 08:17:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id jA3GHF0H094899 for <[e-mail]>; Thu, 3 Nov 2005 08:17:15 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 8930 invoked by uid 0); 3 Nov 2005 16:17:08 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.190.163) by woodstock.binhost.com with SMTP; 3 Nov 2005 16:17:08 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta)
Date: Thu, 03 Nov 2005 10:51:51 -0500
To: Olivier Dubuisson <[e-mail]>, Tom Gindin <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for  InitialAuthentication in Kerberos
Cc: Sam Hartman <[e-mail]>, [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: 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 find AUTOMATIC TAGS to be more difficult later down the line when 
one is doing maintenance.  In my opinion, it hides too much.

Russ

At 09:10 AM 11/3/2005, Olivier Dubuisson wrote:

>Tom Gindin wrote:
>>         If it isn't too late to fix this without breaking lots of 
>> implementations, the ASN.1 in this specification is 
>> over-tagged.  In section 3.2.1, all three of the tags in 
>> PA-PK-AS-REQ are unnecessary, and the one on signedAuthPack is 
>> actually slightly harmful.  None of the tags in PKAuthenticator do 
>> any good either.  The OCTET STRING wrappings for subjectName and 
>> issuerAndSerialNumber are not really appropriate, and subjectName 
>> doesn't need a tag.  Even in AuthPack, pkAuthenticator and 
>> clientDHNonce don't need tags.
>>         Similarly, in 3.2.3, there is no reason for any of the 
>> tags in PA-PK-AS-REP, DHRepInfo, or KDCDHKeyInfo.  The tags in 
>> ReplyKeyPack in 3.2.3.2 also seem unnecessary.
>
>The easiest thing would be to put "AUTOMATIC TAGS" in the module 
>header (instead of "EXPLICIT TAGS") and not bother with tags, for 
>"AUTOMATIC TAGS" would tag where necessary. But I understand from 
>another response that the Kerberos team doesn't want to deviate from 
>their historical choice...
>--
>Olivier DUBUISSON
>France Telecom
>Recherche & Developpement
>R&D/MAPS/AMS - 22307 Lannion Cedex - France
>t: [phone] - f: [phone] - http://asn1.elibel.tm.fr/
>
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA3EpEjx085710; Thu, 3 Nov 2005 06:51:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA3EpEdu085709; Thu, 3 Nov 2005 06:51:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA3EpCoU085703 for <[e-mail]>; Thu, 3 Nov 2005 06:51:13 -0800 (PST) (envelope-from [e-mail])
Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Nov 2005 15:51:10 +0100
Received: from [10.193.13.149] ([10.193.13.149]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Nov 2005 15:51:09 +0100
Message-ID: <[e-mail]>
Date: Thu, 03 Nov 2005 15:51:09 +0100
From: Olivier Dubuisson <[e-mail]>
Organization: France Telecom - Research & Development
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: Tom Gindin <[e-mail]>, Sam Hartman <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for  InitialAuthentication in Kerberos
References: <[e-mail]	m.com> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 03 Nov 2005 14:51:09.0989 (UTC) FILETIME=[0722D550:01C5E086]
Sender: [e-mail]
Precedence: 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 wrote:
 > I think I second Tom Gindin.
 >
 > Itseems strange to me to have pieces of the specification
 > as comments of the asn.1.
 >
 > example:
 >
 >          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
 >                   -- Contains a PKIX type Name encoded according to
 >                   -- [RFC3280].
 >                   -- Identifies the certificate subject by the
 >                   -- distinguished subject name.
 >                   -- REQUIRED when there is a distinguished subject
 >                   -- name present in the certificate.
 >
 >
 > The first two lines are syntactic specification, it was common
 > to have such syntactical restrictions until some years ago.
 > The others don't belong to the syntax at all.
 >
 > The first one can be replaced by
 >
 >        subjectName            [0] IMPLICIT OCTET STRING OPTIONAL
 > CONTAINING Name

The right syntax is:
subjectName   [0] IMPLICIT OCTET STRING(CONTAINING Name) OPTIONAL

It would be even better to add an "ENCODED BY oid" after "CONTAINING 
Name" with 'oid' being the OID of the binary encoding rules used to 
encode 'Name'.

But I can already hear some people saying: This is not supported by Snacc :(

 > and an IMPORT that imports Name from an appropiate module.

IMPORT*S*

 > There are lots of exemples of useless tagging iKDCDHKeyInfo or
 > PKAuthenticator All base tags are different, and there is only one
 > optional field.
 > Well, that'a a matter of style as well as the global EXPLICIT default.

Not only, an EXPLICIT tagging takes more bytes because you can encode 
more than one tag per value.
-- 
Olivier DUBUISSON
France Telecom
Recherche & Developpement
R&D/MAPS/AMS - 22307 Lannion Cedex - France
t: [phone] - f: [phone] - http://asn1.elibel.tm.fr/





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA3EB12E081528; Thu, 3 Nov 2005 06:11:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA3EB1ci081526; Thu, 3 Nov 2005 06:11:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA3EAvGu081503 for <[e-mail]>; Thu, 3 Nov 2005 06:11:00 -0800 (PST) (envelope-from [e-mail])
Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Nov 2005 15:10:52 +0100
Received: from [10.193.13.149] ([10.193.13.149]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Nov 2005 15:10:52 +0100
Message-ID: <[e-mail]>
Date: Thu, 03 Nov 2005 15:10:50 +0100
From: Olivier Dubuisson <[e-mail]>
Organization: France Telecom - Research & Development
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tom Gindin <[e-mail]>
CC: Sam Hartman <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for  InitialAuthentication in Kerberos
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 03 Nov 2005 14:10:52.0239 (UTC) FILETIME=[660B75F0:01C5E080]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom Gindin wrote:
>         If it isn't too late to fix this without breaking lots of 
> implementations, the ASN.1 in this specification is over-tagged.  In 
> section 3.2.1, all three of the tags in PA-PK-AS-REQ are unnecessary, and 
> the one on signedAuthPack is actually slightly harmful.  None of the tags 
> in PKAuthenticator do any good either.  The OCTET STRING wrappings for 
> subjectName and issuerAndSerialNumber are not really appropriate, and 
> subjectName doesn't need a tag.  Even in AuthPack, pkAuthenticator and 
> clientDHNonce don't need tags.
>         Similarly, in 3.2.3, there is no reason for any of the tags in 
> PA-PK-AS-REP, DHRepInfo, or KDCDHKeyInfo.  The tags in ReplyKeyPack in 
> 3.2.3.2 also seem unnecessary.

The easiest thing would be to put "AUTOMATIC TAGS" in the module header 
(instead of "EXPLICIT TAGS") and not bother with tags, for "AUTOMATIC 
TAGS" would tag where necessary. But I understand from another response 
that the Kerberos team doesn't want to deviate from their historical 
choice...
-- 
Olivier DUBUISSON
France Telecom
Recherche & Developpement
R&D/MAPS/AMS - 22307 Lannion Cedex - France
t: [phone] - f: [phone] - http://asn1.elibel.tm.fr/




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA3DBtt0074587; Thu, 3 Nov 2005 05:11:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA3DBtxa074585; Thu, 3 Nov 2005 05:11:55 -0800 (PST)
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.11/8.12.9) with ESMTP id jA3DBsx6074576 for <[e-mail]>; Thu, 3 Nov 2005 05:11:54 -0800 (PST) (envelope-from [e-mail])
Received: from champagne.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id jA3DBri03282 for <[e-mail]>; Thu, 3 Nov 2005 14:11:53 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/2.4); Thu, 3 Nov 2005 14:11:53 +0100 (MET)
Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id OAA10112 for <[e-mail]>; Thu, 3 Nov 2005 14:11:52 +0100 (MET)
Message-ID: <[e-mail]>
Date: Thu, 03 Nov 2005 14:11:52 +0100
From: Peter Sylvester <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-21.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010506020400030704010003"
Sender: [e-mail]
Precedence: 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 cryptographically signed message in MIME format.

--------------ms010506020400030704010003
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

The current text has some improvements and simplifications, addressing
some points that I have been repeating since years.
but does not address adequately all the issues that had been discussed
after the Paris meeting with Tim Polk, in particular some are
misunderstood.





--------------ms010506020400030704010003
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC
BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G
A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs
UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx
CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ
S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu
ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo
VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq
q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID
AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5
MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT
VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F
ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV
HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA
A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U
TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8
1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5
V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9
F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely
LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+
udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr
LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy
MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp
Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA
ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN
LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy
x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm
T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl
Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl
ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F
ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx
cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI
hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2
mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT
g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ
bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4
88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8
oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI
MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m
JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0
MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV
HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3
UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy
4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz
QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u
US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj
PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq
Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf
Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y
rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6
PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL
d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18
k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg
d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD
VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ
S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMTAzMTMxMTUyWjAjBgkqhkiG9w0B
CQQxFgQUZQTO2huHpq7yFay1ufAaIB6v+FAwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY
MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy
c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE
ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ
IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGA4pRgW5TxmUbxXKfv
dNlV0dVvUsp8xoxd8rLs7LLxop0wRvplnbp5Xc8yvdP6GAMYlaFq0gRExkuLChUp/qte09Pw
W/f3tmU8RiqcRU47XIdCQpWY5h+Oyda94snCAsVuv6DhuyXMnigtJK73UwbKlgBW+ZF2F+xg
Grp1HBOuBywAAAAAAAA--------------ms010506020400030704010003--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA3BhiEr063183; Thu, 3 Nov 2005 03:43:44 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA3BhiCK063182; Thu, 3 Nov 2005 03:43:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA3BhhuN063161 for <[e-mail]>; Thu, 3 Nov 2005 03:43:43 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id NAA13068 for <[e-mail]>; Thu, 3 Nov 2005 13:01:08 +0100
Importance: Normal
X-Priority: 3 (Normal)
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-21.txt
MIME-Version: 1.0
From: [e-mail]
To: [e-mail]
Date: Thu, 3 Nov 2005 12:44:22 +0100
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 03/11/2005 12:44:24
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

PEZPTlQgZmFjZT0iRGVmYXVsdCBTYW5zIFNlcmlmLCBWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNh
LCBzYW5zLXNlcmlmIiBzaXplPTI+PGRpdj5UbyB0aGUgbGlzdCw8L2Rpdj48RElWPiZuYnNwOzwv
RElWPjxESVY+T25lIG9mIHRoZSBtYWpvciBkaXNwdXRlcyBpcyByZWxhdGVkIHRvIHRoZSBkZWZp
bml0aW9uIG9mIFZhbGlkYXRpb25Qb2xpY3kuPC9ESVY+PERJVj4mbmJzcDs8L0RJVj48RElWPk1v
c3QgdmFsaWRhdGlvbiBwb2xpY2llcyB3aWxsIG9ubHkgYmUgcmVmZXJlbmNlZCBieSBhIGNsaWVu
dCB1c2luZyBhbiBPSUQuIDwvRElWPjxESVY+SW4gYSBmZXcgY2FzZXMsJm5ic3A7b25lIG9yIHR3
byBwYXJhbWV0ZXJzIHdoaWNoIGFyZSBzcGVjaWZpYyB0byB0aGUgdmFsaWRhdGlvbiBwb2xpY2ll
cyB3aWxsIGJlIG5lZWRlZCAoYWxsIG90aGVyIHBhcmFtZXRlcnMgYmVpbmcgZml4ZWQpLjwvRElW
PjxESVY+Jm5ic3A7PC9ESVY+PERJVj5QYXJhbWV0ZXJzIGRlZmluZWQgYnkgdGhlIG1hZ2ljIHNl
bnRlbmNlIEFOWSBERUZJTkVEIEJZIGFyZSBub3QgdGhhdCBlYXN5IHRvIGhhbmRsZSwgdW5sZXNz
IGZvciBwcmVkZWZpbmVkIHZhbGlkYXRpb24gcG9saWNpZXMuPC9ESVY+PERJVj4mbmJzcDs8L0RJ
Vj48RElWPlRoaXMgbWF5IGJlIHRoZSBjYXNlIGZvciB0aGUgImJhc2ljIHZhbGlkYXRpb24gcG9s
aWN5Ii48L0RJVj48RElWPiZuYnNwOzwvRElWPjxESVY+SGVyZWFmdGVyIGlzIGEgcHJvcG9zYWwg
OjwvRElWPjxESVY+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1GQU1JTFk6IENvdXJpZXI7
IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUyI+PFNQQU4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVz
Ij48Rk9OVCBzaXplPTM+Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9ESVY+PERJVj48UCBjbGFzcz1Nc29O
b3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9
IkZPTlQtRkFNSUxZOiBDb3VyaWVyOyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVMiPjxTUEFOIHN0
eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7IDwvU1BBTj5WYWxpZGF0aW9uUG9s
aWN5IDo6PSBDSE9JQ0UgezxCUj48U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+dmFsaWRhdGlvblBvbGljeURl
ZjxTUEFOIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvU1BB
Tj5bMF08U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyA8L1NQQU4+
VmFsaWRhdGlvblBvbGljeURlZiw8QlI+PFNQQU4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4m
bmJzcDsmbmJzcDsmbmJzcDsgPC9TUEFOPjxTUEFOIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9TUEFOPjwvU1BBTj48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6
IENvdXJpZXIiPnByZURlZmluZWRWPC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQt
RkFNSUxZOiBDb3VyaWVyOyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVMiPmFsUG9sPFNQQU4gc3R5
bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgPC9TUEFOPlsxXTxTUEFOIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7
IDwvU1BBTj5QPC9TUEFOPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogQ291cmllciI+cmVEZWZp
bmVkVjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULUZBTUlMWTogQ291cmllcjsg
bXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTIj5hbFBvbCB9PD94bWw6bmFtZXNwYWNlIHByZWZpeCA9
IG8gbnMgPSAidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiAvPjxvOnA+
PC9vOnA+PC9TUEFOPjwvUD48UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBj
bSAwcHQiPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtRkFNSUxZOiBDb3VyaWVyOyBtc28t
YW5zaS1sYW5ndWFnZTogRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD48UCBjbGFz
cz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVMg
c3R5bGU9IkZPTlQtRkFNSUxZOiBDb3VyaWVyOyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVMiPjxv
OnA+PC9vOnA+PC9TUEFOPjwvUD48UFJFPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0la
RTogMTJwdDsgRk9OVC1GQU1JTFk6IENvdXJpZXI7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUyI+
PFNQQU4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsgPC9TUEFOPlZhbGlk
YXRpb25Qb2xpY3lEZWYgOjo9IFNFUVVFTkNFIHs8QlI+PFNQQU4gc3R5bGU9Im1zby1zcGFjZXJ1
bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9TUEFOPnZhbFBvbElkPFNQQU4gc3R5
bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9TUEFOPk9CSkVD
VCBJREVOVElGSUVSLDxCUj48U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+dmFsUG9sUGFyYW1zPFNQQU4gc3R5bGU9Im1zby1zcGFj
ZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9T
UEFOPjxTUEFOIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7PC9TUEFOPlNF
UVVFTkNFIE9GIFZhbFBvbFBhcmFtPFNQQU4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJz
cDsgPC9TUEFOPk9QVElPTkFMIH08bzpwPjwvbzpwPjwvU1BBTj48L1BSRT48UCBjbGFzcz1Nc29O
b3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9
IkZPTlQtRkFNSUxZOiBDb3VyaWVyOyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVMiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9TUEFOPjwvUD48UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNt
IDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtRkFNSUxZOiBDb3VyaWVyOyBt
c28tYW5zaS1sYW5ndWFnZTogRU4tVVMiPi0tIFZhbGlkYXRpb25Qb2xpY3lEZWYgYXZvaWRzIHRo
ZSB1c2Ugb2YgIjwvU1BBTj48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6IENvdXJpZXIiPkFOWSBE
RUZJTkVEIEJZIi48bzpwPjwvbzpwPjwvU1BBTj48L1A+PFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl
PSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULUZBTUlM
WTogQ291cmllcjsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv
U1BBTj48L1A+PFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48
U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULUZBTUlMWTogQ291cmllcjsgbXNvLWFuc2ktbGFu
Z3VhZ2U6IEVOLVVTIj48bzpwPjwvbzpwPjwvU1BBTj48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAx
MnB0OyBGT05ULUZBTUlMWTogQ291cmllciI+Jm5ic3A7Jm5ic3A7IFByZURlZmluZWRWPC9TUEFO
PjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IENv
dXJpZXI7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUyI+YWxQb2w8L1NQQU4+PFNQQU4gc3R5bGU9
IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IENvdXJpZXIiPiA6Oj0gU0VRVUVOQ0UgezxC
Uj48U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyAmbmJzcDsgPC9TUEFOPnZhbEFsZ0lkPFNQQU4gc3R5bGU9Im1zby1zcGFjZXJ1bjog
eWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9TUEFOPk9CSkVDVCBJREVOVElGSUVSLDxCUj48
U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+cGFyYW1ldGVyczxTUEFOIHN0eWxlPSJtc28tc3BhY2Vy
dW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvU1BBTj5BTlkgREVGSU5FRCBCWSB2YWxBbGdJZCBPUFRJT05B
TCB9PC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1G
QU1JTFk6IENvdXJpZXI7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUyI+PG86cD48L286cD48L1NQ
QU4+PC9QPjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQ
QU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1GQU1JTFk6IENvdXJpZXI7IG1zby1hbnNpLWxhbmd1
YWdlOiBFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPjxQIGNsYXNzPU1zb05vcm1h
bCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9O
VC1GQU1JTFk6IENvdXJpZXI7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUyI+PFNQQU4gc3R5bGU9
Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDs8L1NQQU4+LS0gQmFzaWNWYWxQb2wgaXMgdGhlIHBv
bGljeSBkZXNjcmliZWQgaW4gc2VjdGlvbiAzLjIuNC4yLjE8bzpwPjwvbzpwPjwvU1BBTj48L1A+
PFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5n
PUVOLVVTIHN0eWxlPSJGT05ULUZBTUlMWTogQ291cmllcjsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVO
LVVTIj48U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOzwvU1BBTj4tLSBpdCBj
b21lcyB3aXRoIGl0cyBvd24gT0lEIGFuZCBpdHMgb3duIHBhcmFtZXRlcnMgYW5kIDxvOnA+PC9v
OnA+PC9TUEFOPjwvUD48UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAw
cHQiPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtRkFNSUxZOiBDb3VyaWVyOyBtc28tYW5z
aS1sYW5ndWFnZTogRU4tVVMiPjxTUEFOIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7
PC9TUEFOPi0tIG1heSBiZSBzdXBwb3J0ZWQgdXNpbmcgPC9TUEFOPjxTUEFOIHN0eWxlPSJGT05U
LUZBTUlMWTogQ291cmllciI+UHJlRGVmaW5lZFY8L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHls
ZT0iRk9OVC1GQU1JTFk6IENvdXJpZXI7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUyI+YWxQb2wu
PG86cD48L286cD48L1NQQU4+PC9QPjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAw
Y20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1GQU1JTFk6IENvdXJpZXI7
IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPjxQ
IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1F
Ti1VUyBzdHlsZT0iRk9OVC1GQU1JTFk6IENvdXJpZXI7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1V
UyI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0i
TUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1GQU1JTFk6
IENvdXJpZXI7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUyI+Jm5ic3A7Jm5ic3A7IFZhbFBvbFBh
cmFtIDo9IFNFUVVFTkNFIHsgPG86cD48L286cD48L1NQQU4+PC9QPjxQIGNsYXNzPU1zb05vcm1h
bCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9O
VC1GQU1JTFk6IENvdXJpZXI7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUyI+PFNQQU4gc3R5bGU9
Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7
IDwvU1BBTj5pZDxTUEFOIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvU1BBTj5PQkpFQ1Qg
SURFTlRJRklFUiw8QlI+PFNQQU4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7PC9TUEFOPnZhbHVlPFNQQU4gc3R5bGU9
Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgPC9TUEFOPkJhc2VPYmplY3QgfTxvOnA+PC9vOnA+PC9TUEFOPjwvUD48UCBjbGFzcz1Nc29O
b3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9
IkZPTlQtRkFNSUxZOiBDb3VyaWVyOyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVMiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9TUEFOPjwvUD48UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNt
IDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtRkFNSUxZOiBDb3VyaWVyOyBt
c28tYW5zaS1sYW5ndWFnZTogRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD48UCBj
bGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIHN0eWxlPSJG
T05ULUZBTUlMWTogQ291cmllciI+Jm5ic3A7Jm5ic3A7IEJhc2VPYmplY3QgOjo9IENIT0lDRSB7
PEJSPjxTUEFOIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyA8L1NQQU4+b2JqZWN0bGlzdDxTUEFOIHN0eWxlPSJtc28t
c3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvU1BB
Tj48U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOzwvU1BBTj5TRVFVRU5DRSBP
RiBTaW1wbGVPYmplY3QsPEJSPjxTUEFOIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvU1BBTj5vYmplY3Qg
PFNQQU4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L1NQQU4+U2ltcGxlT2Jq
ZWN0IH08L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1GQU1JTFk6IENvdXJpZXI7
IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUyI+PG86cD48L286cD48L1NQQU4+PC9QPjxQIGNsYXNz
PU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUyBz
dHlsZT0iRk9OVC1GQU1JTFk6IENvdXJpZXI7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUyI+PG86
cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lO
OiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1GQU1JTFk6IENvdXJp
ZXI7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9Q
PjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gc3R5
bGU9IkZPTlQtRkFNSUxZOiBDb3VyaWVyIj4mbmJzcDsmbmJzcDsgU2ltcGxlT2JqZWN0IDo6PSBD
SE9JQ0UgezxCUj48U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyAmbmJzcDs8L1NQQU4+PFNQQU4gc3R5bGU9Im1zby1zcGFjZXJ1bjog
eWVzIj4mbmJzcDs8L1NQQU4+aW50IDxTUEFOIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9TUEFOPklOVEVHRVIsPEJSPjxTUEFOIHN0eWxlPSJtc28t
c3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyA8L1NQQU4+PFNQ
QU4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDs8L1NQQU4+c3RyaW5nIDxTUEFOIHN0
eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9TUEFOPlVURjhTdHJpbmcsPEJSPjxTUEFO
IHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7PC9TUEFOPjxTUEFOIHN0eWxlPSJtc28t
c3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOzwvU1BB
Tj5vaWQgPFNQQU4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L1NQQU4+PFNQQU4gc3R5bGU9Im1z
by1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L1NQQU4+T0JKRUNU
IElERU5USUZJRVIsPEJSPjxTUEFOIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyA8L1NQQU4+ZmxhZyA8U1BBTiBzdHlsZT0ibXNv
LXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvU1BBTj5CT09MRUFOLDxCUj48U1BB
TiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyAmbmJzcDs8L1NQQU4+Yml0c3RyaW5nIDxTUEFOIHN0eWxlPSJtc28tc3BhY2VydW46
IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9TUEFO
PkJJVCBTVFJJTkcsPEJSPjxTUEFOIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOzwvU1BBTj5vY3RldHMgPFNQQU4gc3R5
bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L1NQQU4+T0NURVQgU1RSSU5HLDxCUj48U1BB
TiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyAmbmJzcDs8L1NQQU4+ZGF0ZXRpbWUgPFNQQU4gc3R5bGU9Im1zby1zcGFjZXJ1bjog
eWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8
L1NQQU4+R0VORVJBTElaRURUSU1FLDxCUj48U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMi
PiZuYnNwOzwvU1BBTj48U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+cEtDUmVmZXJlbmNlIDxTUEFOIHN0eWxl
PSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9TUEFOPlswXSA8U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5
ZXMiPiZuYnNwOzwvU1BBTj5QS0NSZWZlcmVuY2UsPEJSPjxTUEFOIHN0eWxlPSJtc28tc3BhY2Vy
dW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvU1BB
Tj5hdHRyaWJ1dGVDZXJ0aWZpY2F0ZSA8U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZu
YnNwOzwvU1BBTj5bMV0gPFNQQU4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDs8L1NQ
QU4+QXR0cmlidXRlQ2VydGlmaWNhdGUgfTwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJG
T05ULUZBTUlMWTogQ291cmllcjsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTIj48bzpwPjwvbzpw
PjwvU1BBTj48L1A+PFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0
Ij48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULUZBTUlMWTogQ291cmllcjsgbXNvLWFuc2kt
bGFuZ3VhZ2U6IEVOLVVTIj48bzpwPjwvbzpwPjwvU1BBTj48L1A+PFAgY2xhc3M9TXNvTm9ybWFs
IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48L0ZPTlQ+PC9TUEFOPjwvU1BBTj48U1BBTiBs
YW5nPUVOLVVTIHN0eWxlPSJGT05ULUZBTUlMWTogQ291cmllcjsgbXNvLWFuc2ktbGFuZ3VhZ2U6
IEVOLVVTIj48bzpwPjxGT05UIHNpemU9Mz4mbmJzcDs8L0ZPTlQ+PC9vOnA+PC9TUEFOPjwvUD48
L0RJVj48RElWPkRlbmlzPC9ESVY+PERJVj4mbmJzcDs8L0RJVj48L0ZPTlQ+



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA39c4cW046595; Thu, 3 Nov 2005 01:38:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA39c43E046594; Thu, 3 Nov 2005 01:38:04 -0800 (PST)
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.11/8.12.9) with ESMTP id jA39c1TJ046584 for <[e-mail]>; Thu, 3 Nov 2005 01:38:02 -0800 (PST) (envelope-from [e-mail])
Received: from champagne.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id jA39bqi00137; Thu, 3 Nov 2005 10:37:52 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/2.4); Thu, 3 Nov 2005 10:37:52 +0100 (MET)
Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id KAA09977; Thu, 3 Nov 2005 10:37:50 +0100 (MET)
Message-ID: <[e-mail]>
Date: Thu, 03 Nov 2005 10:37:49 +0100
From: Peter Sylvester <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Steven Legg <[e-mail]>
CC: =?ISO-8859-1?Q?Love_Hörnquist_Åstrand?= <[e-mail]>, Tom Gindin <[e-mail]>, Sam Hartman <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos
References: <[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050504060708090503010803"
Sender: [e-mail]
Precedence: 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 cryptographically signed message in MIME format.

--------------ms050504060708090503010803
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hi,

I stand corrected (for the syntax). For the rest, I am not sure whether
I could have given an explanation as precisely as Steve. :-)

Peter


Steven Legg wrote:

>
>
> Love, et al,
>
> Love Hörnquist Åstrand wrote:
>
>> Peter Sylvester <[e-mail]> writes:
>>
>>
>>> The first one can be replaced by
>>>
>>>        subjectName            [0] IMPLICIT OCTET STRING OPTIONAL 
>>> CONTAINING Name
>>
>
> The correct syntax here is:
>
>          subjectName   [0] IMPLICIT OCTET STRING (CONTAINING Name) 
> OPTIONAL
>
>>
>>
>> Lets take another example:
>>
>>        PA-PK-AS-REQ ::= SEQUENCE {
>>           signedAuthPack          [0] IMPLICIT OCTET STRING,
>>                    -- Contains a CMS type ContentInfo encoded
>>                    -- according to [RFC3852].
>>                    -- The contentType field of the type ContentInfo
>>                    -- is id-signedData (1.2.840.113549.1.7.2),
>>                    -- and the content field is a SignedData.
>>
>> With you syntax this should be
>>
>>     signedAuthPack IMPLICIT OCTET STRING OPTIONAL CONTAINING ContentInfo
>>
>> Now, ContentInfo in a CMS type, and is allowed to be encoded in BER.
>> Kerberos datatypes uses DER.
>>
>> How is that expressed in a formal way ?
>
>
> signedAuthPack IMPLICIT OCTET STRING
>                   (CONTAINING ContentInfo
>                    ENCODED BY {joint-iso-itu-t asn(1) ber-derived(2) 
> distinguished-encoding(1)})
>                   OPTIONAL
>
> The OID after the "ENCODED BY" is the OID that identifies DER.
>
>>
>> Just saying IMPORT and CONTANING and expect the right thing to happen 
>> when
>> given to a compiler seems very naive.
>
>
> There's a better chance that the compiler can do something useful than if
> the requirements are expressed informally as a comment.
>
> Regards,
> Steven
>
>>
>> Love
>>
>
>
>


-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. 


--------------ms050504060708090503010803
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC
BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G
A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs
UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx
CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ
S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu
ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo
VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq
q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID
AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5
MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT
VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F
ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV
HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA
A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U
TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8
1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5
V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9
F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely
LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+
udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr
LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy
MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp
Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA
ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN
LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy
x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm
T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl
Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl
ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F
ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx
cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI
hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2
mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT
g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ
bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4
88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8
oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI
MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m
JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0
MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV
HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3
UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy
4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz
QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u
US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj
PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq
Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf
Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y
rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6
PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL
d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18
k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg
d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD
VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ
S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMTAzMDkzNzQ5WjAjBgkqhkiG9w0B
CQQxFgQUSS+ERu3NSioTntmkwwbHXPlLENUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY
MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy
c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE
ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ
IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAYfF9eDoa2MHxnrMv
DLtFZdiPVGxMBL4xdA+h2HANF2eLoOK7/aIz37W82TkThTW2ywKEoDn0ciK/y4yLcyWISbRM
6uaniDrA67hgbehP0U55Itq5igYYZ/hDegJnjH92wSHIjPoK9Xc67G8cnrnniltFk+kzB8TM
MKSH3j0/gesAAAAAAAA--------------ms050504060708090503010803--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA2NcNK1086676; Wed, 2 Nov 2005 15:38:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA2NcNGj086675; Wed, 2 Nov 2005 15:38:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eagle.unknowndns.net (IDENT:[e-mail] [221.133.206.175]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA2NcKni086664 for <[e-mail]>; Wed, 2 Nov 2005 15:38:21 -0800 (PST) (envelope-from [e-mail])
Received: from cust3103.vic01.dataco.com.au ([202.63.62.31] helo=[192.168.1.156]) by eagle.unknowndns.net with esmtpa (Exim 4.52) id 1EXSAr-0005eM-3Q; Thu, 03 Nov 2005 09:37:45 +1000
Message-ID: <[e-mail]>
Date: Thu, 03 Nov 2005 10:37:43 +1100
From: Steven Legg <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Love_Hörnquist_Åstrand?= <[e-mail]>
CC: Peter Sylvester <[e-mail]>, Tom Gindin <[e-mail]>, Sam Hartman <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - eagle.unknowndns.net
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - eb2bcom.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Love, et al,

Love Hörnquist Åstrand wrote:
> Peter Sylvester <[e-mail]> writes:
> 
> 
>>The first one can be replaced by
>>
>>        subjectName            [0] IMPLICIT OCTET STRING OPTIONAL CONTAINING Name

The correct syntax here is:

          subjectName   [0] IMPLICIT OCTET STRING (CONTAINING Name) OPTIONAL

> 
> 
> Lets take another example:
> 
>        PA-PK-AS-REQ ::= SEQUENCE {
>           signedAuthPack          [0] IMPLICIT OCTET STRING,
>                    -- Contains a CMS type ContentInfo encoded
>                    -- according to [RFC3852].
>                    -- The contentType field of the type ContentInfo
>                    -- is id-signedData (1.2.840.113549.1.7.2),
>                    -- and the content field is a SignedData.
> 
> With you syntax this should be
> 
> 	signedAuthPack IMPLICIT OCTET STRING OPTIONAL CONTAINING ContentInfo
> 
> Now, ContentInfo in a CMS type, and is allowed to be encoded in BER.
> Kerberos datatypes uses DER.
> 
> How is that expressed in a formal way ?

signedAuthPack IMPLICIT OCTET STRING
                   (CONTAINING ContentInfo
                    ENCODED BY {joint-iso-itu-t asn(1) ber-derived(2) distinguished-encoding(1)})
                   OPTIONAL

The OID after the "ENCODED BY" is the OID that identifies DER.

> 
> Just saying IMPORT and CONTANING and expect the right thing to happen when
> given to a compiler seems very naive.

There's a better chance that the compiler can do something useful than if
the requirements are expressed informally as a comment.

Regards,
Steven

> 
> Love
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA2K184I055883; Wed, 2 Nov 2005 12:01:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA2K18eA055882; Wed, 2 Nov 2005 12:01:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from amsfep18-int.chello.nl (amsfep18-int.chello.nl [213.46.243.13]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA2K15Dn055863 for <[e-mail]>; Wed, 2 Nov 2005 12:01:06 -0800 (PST) (envelope-from [e-mail])
Received: from c80-217-232-48.cm-upc.chello.se ([80.217.232.48]) by amsfep18-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <[e-mail]>; Wed, 2 Nov 2005 21:00:59 +0100
Received: by c80-217-232-48.cm-upc.chello.se (Postfix, from userid 501) id 6E08335F222; Wed,  2 Nov 2005 21:00:58 +0100 (CET)
To: Peter Sylvester <[e-mail]>
Cc: Sam Hartman <[e-mail]>, Tom Gindin <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: =?iso-8859-1?q?Love_Hörnquist_Åstrand?= <[e-mail]>
Date: Wed, 02 Nov 2005 21:00:56 +0100
In-Reply-To: <[e-mail]> (Peter Sylvester's message of "Wed, 02 Nov 2005 16:58:33 +0100")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/22.0.50 (darwin)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Sender: [e-mail]
Precedence: 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,

> Tagging is a matter of ket's say "taste", in fact, it is a matter of
> implementation
> experience. ASN.1 after many years has come with AUTOMATIC tags
> allowing automatically unambiguous and non-excessive explicit tagging.

The excessive amount of tagging seems like minor nit, its bloaty, sure, its
like rest of the Kerberos protocol.

> Wrapping: Strong boundaries would make sense if you don't have to
> cross them
>
> Interoperability note: Some implementations may not be able to decode
>    wrapped CMS objects encoded with BER but not DER; specifically, they
>    may not be able to decode infinite length encodings. 
>
>
>
> something that seems to be necessary according to the previous citation.
>
> As soon as you have the data structure that you wrap,
> you can also encode them in DER. I doubt that you just have the
> octet string contents only available as blobs.

The CMS implemtetion might use another asn1-package then then Kerberos
implemetation, I think today that this is the common case. You call CMS
package, get back blob, and you have no clue about the encoding it used
used.

Love


--=-=-Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iQEVAwUAQ2ka+to1gLFKFEjAAQIgQwf8CfqEn+VTKEos0XqFQhSqDpmnsJkY2r4R
Xp1jgCj9dr7eqKbIXdABKHVhT/z5Ox7bhy3N6ssJlvrhOFV8qqG9sQNIkxYlO9wp
iCPm26JVacz3v4P/ryMKO4rJoWVzrO6S5HWnC4Mo76zRIkOmfutJOLKxXdNpajPG
J89wM3canq3V9ExaVqd42ffGGXaiGGxi4EBHwyRsgNot2fd9nWR7kc7BM5E0zXvt
PRHgE07c9qqeJuMWgnNvp3jEV/HTpiXNPiyXESBPQe3bEM03SJshSaAyTrwsqbfG
sodIuN7KDYrFtsyP6Ct6NoSd56Qzf9H62JkN24A7JxaxegFJavTACg=
=iQPg
-----END PGP SIGNATURE-----
--=-=-=--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA2JsvuH055396; Wed, 2 Nov 2005 11:54:57 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA2JsvlZ055395; Wed, 2 Nov 2005 11:54:57 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from amsfep19-int.chello.nl (amsfep11-int.chello.nl [213.46.243.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA2JstwL055361 for <[e-mail]>; Wed, 2 Nov 2005 11:54:56 -0800 (PST) (envelope-from [e-mail])
Received: from c80-217-232-48.cm-upc.chello.se ([80.217.232.48]) by amsfep19-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <[e-mail]>; Wed, 2 Nov 2005 20:53:53 +0100
Received: by c80-217-232-48.cm-upc.chello.se (Postfix, from userid 501) id 221DD35F20B; Wed,  2 Nov 2005 20:53:50 +0100 (CET)
To: Peter Sylvester <[e-mail]>
Cc: Tom Gindin <[e-mail]>, Sam Hartman <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos
References: <[e-mail]> <[e-mail]>
From: =?iso-8859-1?q?Love_Hörnquist_Åstrand?= <[e-mail]>
Date: Wed, 02 Nov 2005 20:53:44 +0100
In-Reply-To: <[e-mail]> (Peter Sylvester's message of "Tue, 01 Nov 2005 19:15:24 +0100")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/22.0.50 (darwin)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Sender: [e-mail]
Precedence: 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:

> The first one can be replaced by
>
>         subjectName            [0] IMPLICIT OCTET STRING OPTIONAL CONTAINING Name

Lets take another example:

       PA-PK-AS-REQ ::= SEQUENCE {
          signedAuthPack          [0] IMPLICIT OCTET STRING,
                   -- Contains a CMS type ContentInfo encoded
                   -- according to [RFC3852].
                   -- The contentType field of the type ContentInfo
                   -- is id-signedData (1.2.840.113549.1.7.2),
                   -- and the content field is a SignedData.

With you syntax this should be

	signedAuthPack IMPLICIT OCTET STRING OPTIONAL CONTAINING ContentInfo

Now, ContentInfo in a CMS type, and is allowed to be encoded in BER.
Kerberos datatypes uses DER.

How is that expressed in a formal way ?

Just saying IMPORT and CONTANING and expect the right thing to happen when
given to a compiler seems very naive.

Love


--=-=-Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iQEVAwUAQ2kZTto1gLFKFEjAAQID/Af+OWQT87mcOtSKqYXb0aTmnNWuO2BIBhdd
rnTZhrPeeej8nTlKIY6XoV3LcK3sy8Qbsqjl/4l66WlXCLwjwjSh06kRUpui04Xx
9Ssf3MiMkOCij0N0gn2DH9a2W/GPeZpClhg7Stb+VHatcgvF4FFTsRBEIDWybqD2
XZyUw803BCezh6PACpll/wi1EBJVF1+XjR8pG7tUSxnUwnceeshRQeO8AMjwacu6
aWgkwgNjipugE/5nOu6+tnS9s6+FtPmQS0c+J2MyIN76hJcYIslkcO2Ym5w/5kSF
xiKlN9SoNgEenpwlW90beQd9iKlPtgCF89+pbNBwqZAFTZhVDM6iXA=
=mlWA
-----END PGP SIGNATURE-----
--=-=-=--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA2IKYAD039591; Wed, 2 Nov 2005 10:20:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA2IKYjp039590; Wed, 2 Nov 2005 10:20:34 -0800 (PST)
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.11/8.12.9) with ESMTP id jA2IKXxf039574 for <[e-mail]>; Wed, 2 Nov 2005 10:20:33 -0800 (PST) (envelope-from [e-mail])
Received: from 204.127.135.41 ([204.127.135.41]) by worldnet.att.net (mtiwmhc11) with SMTP id <2005110218202211100n91kce>; Wed, 2 Nov 2005 18:20:27 +0000
Received: from [64.127.102.91] by 204.127.135.41; Wed, 02 Nov 2005 18:20:19 +0000
From: [e-mail]
To: [e-mail], Sam Hartman <[e-mail]>
Cc: Tom Gindin <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos
Date: Wed, 02 Nov 2005 18:20:19 +0000
Message-Id: <110220051820[e-mail]>
X-Mailer: AT&T Message Center Version 1 (Oct 30 2005)
X-Authenticated-Sender: dG9kZC5nbGFzc2V5QGF0dC5uZXQMIME-Version: 1.0
Content-Type: multipart/mixed; boundary="NextPart_Webmail_9m3u9jl4l_1090_1130955619_0"
Sender: [e-mail]
Precedence: 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_Webmail_9m3u9jl4l_1090_1130955619_0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit


Denis - doesnt the idea that the IETF as a whole needs to sign off on ASN.1 Notation in order for their to be any responsibility of any A-D's anywhere to push it seem reasonable to you? Or does PKIX rule the IETF still? 

Todd Glassey


--NextPart_Webmail_9m3u9jl4l_1090_1130955619_0
Content-Type: message/rfc822

From:    [e-mail]
To:    Sam Hartman <[e-mail]>
Cc:    Tom Gindin <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Subject:    Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos
Date:    Wed, 2 Nov 2005 17:03:36 +0000
Content-Type: Multipart/mixed;
 boundary="NextPart_Webmail_9m3u9jl4l_1090_1130955619_1"

--NextPart_Webmail_9m3u9jl4l_1090_1130955619_1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64


PEZPTlQgZmFjZT0iRGVmYXVsdCBTYW5zIFNlcmlmLCBWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNh
LCBzYW5zLXNlcmlmIiBzaXplPTI+PERJVj5JIHNlY29uZCBUb20gYW5kIFBldGVyIHBvc2l0aW9u
cy48L0RJVj48RElWPiZuYnNwOzwvRElWPjxESVY+U2luY2UgeW91IGFza2VkLCB5b3UgZ290IHRo
cmVlIGNvbnNpc3RhbnQgYW5zd2Vycy48QlI+SXQgaXMgbm90Jm5ic3A7YXBwcm9wcmlhdGUgdG8g
b3ZlciB0YWcgYW5kIG92ZXIgY29tbWVudCBpbiB0aGUgQVNOLjEgc3ludGF4LjwvRElWPjxESVY+
Jm5ic3A7PC9ESVY+PERJVj5JIGJlbGlldmUgdGhhdCB0aGUgQS1EcyBzaG91bGQgbWFrZSBzdXJl
IHRoZSBBU04uMSBkZXNjcmlwdGlvbnMgY29taW5nIGZyb20gZGlmZmVyZW50IFdHcyBoYXZlIHRo
ZSBzYW1lIGxvb2sgYW5kIGZlZWwuPC9ESVY+PERJVj4mbmJzcDs8L0RJVj48RElWPkluIGFkZGl0
aW9uOjwvRElWPjxESVY+Jm5ic3A7PC9ESVY+PERJVj5Gcm9tIHRoZSBpbnRyb2R1Y3Rpb24sIGl0
IGlzIGhhcmQmbmJzcDt0byBrbm93IHdoaWNoIGtpbmQgb2YgcHJpdmF0ZSBrZXkgaXMgbmVlZGVk
OiA8L0RJVj48RElWPmlzIGl0IGEgcHJpdmF0ZSBrZXkgZm9yIGRlY3J5cHRpb24gb3IvYW5kIGZv
ciBkaWdpdGFsbHkgc2lnbmluZyA/IDwvRElWPjxESVY+Jm5ic3A7PC9ESVY+PERJVj5JdCBpcyBh
bHNvIGhhcmQgdG8ga25vdyB3aGV0aGVyIGEgcHVyZSBzaWduYXR1cmUgYWxnb3JpdGhtIGxpa2Ug
RFNBIG1heSZuYnNwO2JlIHVzZWQuIDwvRElWPjxESVY+TGF0ZXIgb24gZnJvbSB0aGUgbmV4dCwg
aXQgc2VlbXMgdGhhdCB0aGUgYW5zd2VyIGlzICJvbmx5IHRoZSBSU0EgYWxnb3JpdGhtIGNhbiBi
ZSB1c2VkIi48L0RJVj48RElWPiZuYnNwOzwvRElWPjxESVY+U3RlcCAyIGFzIGRlc2NyaWJlZCBp
biBzZWN0aW9uIDMsIG1hbmRhdGVzIHRoZSB1c2Ugb2YgYSBwdWJsaWMga2V5IGNlcnRpZmljYXRl
LCA8L0RJVj48RElWPmJ1dCBzdGVwIDEgb25seSBtZW50aW9ucyB0aGF0IGEgcHVibGljIGtleSBp
cyBwYXNzZWQsIGluc3RlYWQgb2YgYSBwdWJsaWMga2V5IGNlcnRpZmljYXRlLiA8L0RJVj48RElW
PlN0ZXBzIDEgYW5kIDIgbmVlZCB0byBiZSBtYWRlIGNvbnNpc3RhbnQuJm5ic3A7Jm5ic3A7PC9E
SVY+PERJVj4mbmJzcDs8L0RJVj48RElWPlBsZWFzZSBjbGFyaWZ5IHRoZSBpbnRyb2R1Y3Rpb24g
dG8gdGhlc2UgcmVzcGVjdHMuIDwvRElWPjxESVY+Jm5ic3A7PC9ESVY+PERJVj5UaGUgc3ludGF4
IG9mIEV4dGVybmFsUHJpbmNpcGFsSWRlbnRpZmllciAodXNlZCBieSB0cnVzdGVkQ2VydGlmaWVy
cykgaXMgcXVpdGUgb2RkLiA8L0RJVj48RElWPldoeSBpcyBzaW1wbHkgYSBzZWxmLXNpZ25lZCBj
ZXJ0aWZpY2F0ZSBub3QgYWxsb3dlZCA/PC9ESVY+PERJVj4mbmJzcDs8L0RJVj48RElWPlNob3Vs
ZCBtZDUgcmVhbGx5IGJlIHN0aWxsIGFsbG93ZWQgPzwvRElWPjxESVY+Jm5ic3A7PC9ESVY+PERJ
Vj5UaGVyZSBzaG91bGQgYmUgYW4gZWFybHkgZGlzY3Vzc2lvbiB0byBzYXkgd2hlbiAzYSBhbmQg
M2IgKGZyb20gc2VjdGlvbiAzKSZuYnNwO2FyZSBuZWVkZWQgb3IgImJlc3QiLjwvRElWPjxESVY+
PERJVj5UaGUgZHJhZnQgc2VlbXMgdG8gaGF2ZSB0b28gbWFueSBtYW5kYXRvcnkgb3B0aW9ucyB0
byBpbXBsZW1lbnQuPC9ESVY+PC9ESVY+PERJVj4mbmJzcDs8L0RJVj48RElWPklmIEkgaGF2ZSBt
b3JlIHRpbWUsIEkgd2lsbCByZWFkIHRoZSBkcmFmdCBpbiBtb3JlIGRldGFpbHMuPC9ESVY+PERJ
Vj4mbmJzcDs8L0RJVj48RElWPkluIHRoZSBtZWFuIHRpbWUsIHJlc3BvbnNlcyB0byB0aGUgYWJv
dmUmbmJzcDtxdWVzdGlvbnMgd2lsbCBiZSBpbnRlcnJlc3RpbmcuPC9ESVY+PERJVj4mbmJzcDs8
L0RJVj48RElWPkRlbmlzPC9ESVY+PERJVj4mbmJzcDs8L0RJVj48RElWPjxESVY+UFMuIEkgYW0g
cHV6emxlZCB0aGF0IHlvdSBhbnN3ZXJlZCAoYXMgQUQmbmJzcDs/KSBpbnN0ZWFkIG9mIHRoZSBl
ZGl0b3IocykuPEJSPjwvRElWPjwvRElWPjxGT05UIGNvbG9yPSM5OTAwOTk+LS0tLS1vd25lci1p
ZXRmLXBraXhAbWFpbC5pbWMub3JnIHdyb3RlOiAtLS0tLTxCUj48QlI+PC9GT05UPlRvOiBUb20g
R2luZGluICZsdDt0Z2luZGluQHVzLmlibS5jb20mZ3Q7PEJSPkZyb206IFNhbSBIYXJ0bWFuICZs
dDtoYXJ0bWFucy1pZXRmQG1pdC5lZHUmZ3Q7PEJSPlNlbnQgYnk6IG93bmVyLWlldGYtcGtpeEBt
YWlsLmltYy5vcmc8QlI+RGF0ZTogMDEvMTEvMjAwNSAwMzoyN1BNPEJSPmNjOiBpZXRmLXBraXhA
aW1jLm9yZywgamh1dHpAY211LmVkdSwgaWV0Zi1rcmItd2dAYW5sLmdvdjxCUj5TdWJqZWN0OiBS
ZTogW0plZmZyZXkgSHV0emVsbWFuXSBMQVNUIENBTEwgLSBQdWJsaWMgS2V5IENyeXB0b2dyYXBo
eSBmb3IgSW5pdGlhbCBBdXRoZW50aWNhdGlvbiBpbiBLZXJiZXJvczxCUj48QlI+PEJSPiZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7ICJUb20iID09IFRvbSBHaW5kaW4gJmx0O3RnaW5kaW5AdXMuaWJtLmNv
bSZndDsgd3JpdGVzOjxCUj48QlI+ICAgIFRvbSZndDsgICAgICAgICBJZiBpdCBpc24ndCB0b28g
bGF0ZSB0byBmaXggdGhpcyB3aXRob3V0IGJyZWFraW5nPEJSPiAgICBUb20mZ3Q7IGxvdHMgb2Yg
aW1wbGVtZW50YXRpb25zLCB0aGUgQVNOLjEgaW4gdGhpcyBzcGVjaWZpY2F0aW9uIGlzPEJSPiAg
ICBUb20mZ3Q7IG92ZXItdGFnZ2VkLiAgSW4gc2VjdGlvbiAzLjIuMSwgYWxsIHRocmVlIG9mIHRo
ZSB0YWdzIGluPEJSPiAgICBUb20mZ3Q7IFBBLVBLLUFTLVJFUSBhcmUgdW5uZWNlc3NhcnksIGFu
ZCB0aGUgb25lIG9uIHNpZ25lZEF1dGhQYWNrPEJSPiAgICBUb20mZ3Q7IGlzIGFjdHVhbGx5IHNs
aWdodGx5IGhhcm1mdWwuICBOb25lIG9mIHRoZSB0YWdzIGluPEJSPiAgICBUb20mZ3Q7IFBLQXV0
aGVudGljYXRvciBkbyBhbnkgZ29vZCBlaXRoZXIuICBUaGUgT0NURVQgU1RSSU5HPEJSPiAgICBU
b20mZ3Q7IHdyYXBwaW5ncyBmb3Igc3ViamVjdE5hbWUgYW5kIGlzc3VlckFuZFNlcmlhbE51bWJl
ciBhcmUgbm90PEJSPiAgICBUb20mZ3Q7IHJlYWxseSBhcHByb3ByaWF0ZSwgYW5kIHN1YmplY3RO
YW1lIGRvZXNuJ3QgbmVlZCBhIHRhZy4gIEV2ZW48QlI+ICAgIFRvbSZndDsgaW4gQXV0aFBhY2ss
IHBrQXV0aGVudGljYXRvciBhbmQgY2xpZW50REhOb25jZSBkb24ndCBuZWVkPEJSPiAgICBUb20m
Z3Q7IHRhZ3MuICBTaW1pbGFybHksIGluIDMuMi4zLCB0aGVyZSBpcyBubyByZWFzb24gZm9yIGFu
eSBvZiB0aGU8QlI+ICAgIFRvbSZndDsgdGFncyBpbiBQQS1QSy1BUy1SRVAsIERIUmVwSW5mbywg
b3IgS0RDREhLZXlJbmZvLiAgVGhlIHRhZ3M8QlI+ICAgIFRvbSZndDsgaW4gUmVwbHlLZXlQYWNr
IGluIDMuMi4zLjIgYWxzbyBzZWVtIHVubmVjZXNzYXJ5LjxCUj48QlI+VGhlIGtlcmJlcm9zIHdv
cmtpbmcgZ3JvdXAgaGFzIGEgcmF0aGVyIGRpZmZlcmVudCBwaGlsb3NvcGh5IG9uIEFTTi4xPEJS
PnRoYW4gdGhlIFBLSVggY29tbXVuaXR5LiAgV2UndmUgYXR0ZW1wdGVkIHRvIGRyYXcgc3Ryb25n
IGJvdW5kYXJpZXM8QlI+YXJvdW5kIHN0cnVjdHVyZXMgdG8gdGhlIGV4dGVudCB0aGF0IHdlIGNh
bjoga2VyYmVyb3Mgc3RydWN0dXJlcyB1c2U8QlI+b3VyIGNvbnZlbnRpb25zOyBQS0lYIHN0cnVj
dHVyZXMgdXNlIHlvdXJzLjxCUj48QlI+VGhlIHNob3J0IGFuc3dlciBpcyB0aGF0IHRhZ2dpbmcg
aXNzdWVzIGhhdmUgYmVlbiBkaXNjdXNzZWQ8QlI+ZXh0ZW5zaXZlbHkgYWNyb3NzIGFsbCBvdXIg
QVNOLjEgdXNhZ2UuPEJSPjxCUj48L0ZPTlQ+


--NextPart_Webmail_9m3u9jl4l_1090_1130955619_1--

--NextPart_Webmail_9m3u9jl4l_1090_1130955619_0--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA2Fwftw018108; Wed, 2 Nov 2005 07:58:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA2Fwfp6018107; Wed, 2 Nov 2005 07:58:41 -0800 (PST)
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.11/8.12.9) with ESMTP id jA2FweR6018092 for <[e-mail]>; Wed, 2 Nov 2005 07:58:40 -0800 (PST) (envelope-from [e-mail])
Received: from champagne.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id jA2FwYi17500; Wed, 2 Nov 2005 16:58:35 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/2.4); Wed, 2 Nov 2005 16:58:35 +0100 (MET)
Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id QAA09296; Wed, 2 Nov 2005 16:58:33 +0100 (MET)
Message-ID: <[e-mail]>
Date: Wed, 02 Nov 2005 16:58:33 +0100
From: Peter Sylvester <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sam Hartman <[e-mail]>
CC: Tom Gindin <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080808090809000606010300"
Sender: [e-mail]
Precedence: 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 cryptographically signed message in MIME format.

--------------ms080808090809000606010300
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Sam,

Just because I find your response strange I'd like to add some reamrks.
Why do you mention PKIX here. Tom didn't mention it at all.
You could as well have mentioned SMIME.
Anyway, not too important.

Saying that kerberos has other rules than PKIX has nothing to
do with the problem. besides that PKIX has no rules and continue
s to use obsolete ASN.1, thus it may be good to use something else,
i.e. to ignore whatever some PKIX authors are proposing. :-)

There are two issues in Tom's message: The tagging with
context tags almost always explicit, and the wrapping.

Tagging is a matter of ket's say "taste", in fact, it is a matter of 
implementation
experience. ASN.1 after many years has come with AUTOMATIC tags
allowing automatically unambiguous and non-excessive explicit tagging.

The actual tagging appeared in the 03 draft in 1997 as far as I see.
The krb-wg first meeting was in Jul 2000 but the text was obviously
discussed before in cat. well, let's see the mail archives of this group.
oops. It is difficult to determine now what has "always" been discussed.

Wrapping: Strong boundaries would make sense if you don't have to
cross them

Interoperability note: Some implementations may not be able to decode
   wrapped CMS objects encoded with BER but not DER; specifically, they
   may not be able to decode infinite length encodings. 



something that seems to be necessary according to the previous citation.

As soon as you have the data structure that you wrap,
you can also encode them in DER. I doubt that you just have the
octet string contents only available as blobs.

I refer to the minutes of San Diego concerning the use of DER/BER
and wrapping. Must have been real fun, this meeting
The argument of the difficulties of parsing BER (in particular
when it is totally unrestricted) seem right to me, or better, that
it is too complex to mandate a BER parser.


There may be good arguments after years to keep the syntax or the bits
on the wire but it has been change just a year ago after 8 years or so.

Have fun
Peter


>
>    Tom>         If it isn't too late to fix this without breaking
>    Tom> lots of implementations, the ASN.1 in this specification is
>    Tom> over-tagged.  In section 3.2.1, all three of the tags in
>    Tom> PA-PK-AS-REQ are unnecessary, and the one on signedAuthPack
>    Tom> is actually slightly harmful.  None of the tags in
>    Tom> PKAuthenticator do any good either.  The OCTET STRING
>    Tom> wrappings for subjectName and issuerAndSerialNumber are not
>    Tom> really appropriate, and subjectName doesn't need a tag.  Even
>    Tom> in AuthPack, pkAuthenticator and clientDHNonce don't need
>    Tom> tags.  Similarly, in 3.2.3, there is no reason for any of the
>    Tom> tags in PA-PK-AS-REP, DHRepInfo, or KDCDHKeyInfo.  The tags
>    Tom> in ReplyKeyPack in 3.2.3.2 also seem unnecessary.
>
>The kerberos working group has a rather different philosophy on ASN.1
>than the PKIX community.  We've attempted to draw strong boundaries
>around structures to the extent that we can: kerberos structures use
>our conventions; PKIX structures use yours.
>
>The short answer is that tagging issues have been discussed
>extensively across all our ASN.1 usage.
>
>
>
>  
>


-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. 


--------------ms080808090809000606010300
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC
BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G
A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs
UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx
CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ
S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu
ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo
VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq
q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID
AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5
MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT
VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F
ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV
HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA
A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U
TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8
1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5
V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9
F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely
LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+
udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr
LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy
MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp
Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA
ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN
LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy
x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm
T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl
Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl
ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F
ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx
cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI
hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2
mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT
g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ
bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4
88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8
oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI
MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m
JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0
MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV
HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3
UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy
4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz
QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u
US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj
PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq
Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf
Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y
rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6
PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL
d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18
k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg
d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD
VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ
S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMTAyMTU1ODMzWjAjBgkqhkiG9w0B
CQQxFgQUk61YQiOk/VPj5SmKQd4QWaGKz7UwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY
MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy
c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE
ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ
IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGARtzOTwk7jaGqUdP3
T2xmgHxYQ+kdqz/C4cGzjtbrDt5szfEajZytPojh/yAUHDeKxh4thohs9sMUvo8LuLkw3AIi
blYZtNSBq42YbqtqptIvViAbp6Md+0jNZXOF5XUpkNeEPH3vI+iTFX02S13GTVjPxCmRa/OC
wrC6e6LdozYAAAAAAAA--------------ms080808090809000606010300--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA2ETYtp009027; Wed, 2 Nov 2005 06:29:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA2ETYVc009026; Wed, 2 Nov 2005 06:29:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA2ETVgV009013 for <[e-mail]>; Wed, 2 Nov 2005 06:29:32 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA25970; Wed, 2 Nov 2005 15:46:44 +0100
Importance: Normal
X-Priority: 3 (Normal)
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos
MIME-Version: 1.0
From: [e-mail]
To: Sam Hartman <[e-mail]>
Cc: Tom Gindin <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Date: Wed, 2 Nov 2005 15:29:59 +0100
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 02/11/2005 15:30:02
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

PEZPTlQgZmFjZT0iRGVmYXVsdCBTYW5zIFNlcmlmLCBWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNh
LCBzYW5zLXNlcmlmIiBzaXplPTI+PERJVj5JIHNlY29uZCBUb20gYW5kIFBldGVyIHBvc2l0aW9u
cy48L0RJVj48RElWPiZuYnNwOzwvRElWPjxESVY+U2luY2UgeW91IGFza2VkLCB5b3UgZ290IHRo
cmVlIGNvbnNpc3RhbnQgYW5zd2Vycy48QlI+SXQgaXMgbm90Jm5ic3A7YXBwcm9wcmlhdGUgdG8g
b3ZlciB0YWcgYW5kIG92ZXIgY29tbWVudCBpbiB0aGUgQVNOLjEgc3ludGF4LjwvRElWPjxESVY+
Jm5ic3A7PC9ESVY+PERJVj5JIGJlbGlldmUgdGhhdCB0aGUgQS1EcyBzaG91bGQgbWFrZSBzdXJl
IHRoZSBBU04uMSBkZXNjcmlwdGlvbnMgY29taW5nIGZyb20gZGlmZmVyZW50IFdHcyBoYXZlIHRo
ZSBzYW1lIGxvb2sgYW5kIGZlZWwuPC9ESVY+PERJVj4mbmJzcDs8L0RJVj48RElWPkluIGFkZGl0
aW9uOjwvRElWPjxESVY+Jm5ic3A7PC9ESVY+PERJVj5Gcm9tIHRoZSBpbnRyb2R1Y3Rpb24sIGl0
IGlzIGhhcmQmbmJzcDt0byBrbm93IHdoaWNoIGtpbmQgb2YgcHJpdmF0ZSBrZXkgaXMgbmVlZGVk
OiA8L0RJVj48RElWPmlzIGl0IGEgcHJpdmF0ZSBrZXkgZm9yIGRlY3J5cHRpb24gb3IvYW5kIGZv
ciBkaWdpdGFsbHkgc2lnbmluZyA/IDwvRElWPjxESVY+Jm5ic3A7PC9ESVY+PERJVj5JdCBpcyBh
bHNvIGhhcmQgdG8ga25vdyB3aGV0aGVyIGEgcHVyZSBzaWduYXR1cmUgYWxnb3JpdGhtIGxpa2Ug
RFNBIG1heSZuYnNwO2JlIHVzZWQuIDwvRElWPjxESVY+TGF0ZXIgb24gZnJvbSB0aGUgbmV4dCwg
aXQgc2VlbXMgdGhhdCB0aGUgYW5zd2VyIGlzICJvbmx5IHRoZSBSU0EgYWxnb3JpdGhtIGNhbiBi
ZSB1c2VkIi48L0RJVj48RElWPiZuYnNwOzwvRElWPjxESVY+U3RlcCAyIGFzIGRlc2NyaWJlZCBp
biBzZWN0aW9uIDMsIG1hbmRhdGVzIHRoZSB1c2Ugb2YgYSBwdWJsaWMga2V5IGNlcnRpZmljYXRl
LCA8L0RJVj48RElWPmJ1dCBzdGVwIDEgb25seSBtZW50aW9ucyB0aGF0IGEgcHVibGljIGtleSBp
cyBwYXNzZWQsIGluc3RlYWQgb2YgYSBwdWJsaWMga2V5IGNlcnRpZmljYXRlLiA8L0RJVj48RElW
PlN0ZXBzIDEgYW5kIDIgbmVlZCB0byBiZSBtYWRlIGNvbnNpc3RhbnQuJm5ic3A7Jm5ic3A7PC9E
SVY+PERJVj4mbmJzcDs8L0RJVj48RElWPlBsZWFzZSBjbGFyaWZ5IHRoZSBpbnRyb2R1Y3Rpb24g
dG8gdGhlc2UgcmVzcGVjdHMuIDwvRElWPjxESVY+Jm5ic3A7PC9ESVY+PERJVj5UaGUgc3ludGF4
IG9mIEV4dGVybmFsUHJpbmNpcGFsSWRlbnRpZmllciAodXNlZCBieSB0cnVzdGVkQ2VydGlmaWVy
cykgaXMgcXVpdGUgb2RkLiA8L0RJVj48RElWPldoeSBpcyBzaW1wbHkgYSBzZWxmLXNpZ25lZCBj
ZXJ0aWZpY2F0ZSBub3QgYWxsb3dlZCA/PC9ESVY+PERJVj4mbmJzcDs8L0RJVj48RElWPlNob3Vs
ZCBtZDUgcmVhbGx5IGJlIHN0aWxsIGFsbG93ZWQgPzwvRElWPjxESVY+Jm5ic3A7PC9ESVY+PERJ
Vj5UaGVyZSBzaG91bGQgYmUgYW4gZWFybHkgZGlzY3Vzc2lvbiB0byBzYXkgd2hlbiAzYSBhbmQg
M2IgKGZyb20gc2VjdGlvbiAzKSZuYnNwO2FyZSBuZWVkZWQgb3IgImJlc3QiLjwvRElWPjxESVY+
PERJVj5UaGUgZHJhZnQgc2VlbXMgdG8gaGF2ZSB0b28gbWFueSBtYW5kYXRvcnkgb3B0aW9ucyB0
byBpbXBsZW1lbnQuPC9ESVY+PC9ESVY+PERJVj4mbmJzcDs8L0RJVj48RElWPklmIEkgaGF2ZSBt
b3JlIHRpbWUsIEkgd2lsbCByZWFkIHRoZSBkcmFmdCBpbiBtb3JlIGRldGFpbHMuPC9ESVY+PERJ
Vj4mbmJzcDs8L0RJVj48RElWPkluIHRoZSBtZWFuIHRpbWUsIHJlc3BvbnNlcyB0byB0aGUgYWJv
dmUmbmJzcDtxdWVzdGlvbnMgd2lsbCBiZSBpbnRlcnJlc3RpbmcuPC9ESVY+PERJVj4mbmJzcDs8
L0RJVj48RElWPkRlbmlzPC9ESVY+PERJVj4mbmJzcDs8L0RJVj48RElWPjxESVY+UFMuIEkgYW0g
cHV6emxlZCB0aGF0IHlvdSBhbnN3ZXJlZCAoYXMgQUQmbmJzcDs/KSBpbnN0ZWFkIG9mIHRoZSBl
ZGl0b3IocykuPEJSPjwvRElWPjwvRElWPjxGT05UIGNvbG9yPSM5OTAwOTk+LS0tLS1vd25lci1p
ZXRmLXBraXhAbWFpbC5pbWMub3JnIHdyb3RlOiAtLS0tLTxCUj48QlI+PC9GT05UPlRvOiBUb20g
R2luZGluICZsdDt0Z2luZGluQHVzLmlibS5jb20mZ3Q7PEJSPkZyb206IFNhbSBIYXJ0bWFuICZs
dDtoYXJ0bWFucy1pZXRmQG1pdC5lZHUmZ3Q7PEJSPlNlbnQgYnk6IG93bmVyLWlldGYtcGtpeEBt
YWlsLmltYy5vcmc8QlI+RGF0ZTogMDEvMTEvMjAwNSAwMzoyN1BNPEJSPmNjOiBpZXRmLXBraXhA
aW1jLm9yZywgamh1dHpAY211LmVkdSwgaWV0Zi1rcmItd2dAYW5sLmdvdjxCUj5TdWJqZWN0OiBS
ZTogW0plZmZyZXkgSHV0emVsbWFuXSBMQVNUIENBTEwgLSBQdWJsaWMgS2V5IENyeXB0b2dyYXBo
eSBmb3IgSW5pdGlhbCBBdXRoZW50aWNhdGlvbiBpbiBLZXJiZXJvczxCUj48QlI+PEJSPiZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7ICJUb20iID09IFRvbSBHaW5kaW4gJmx0O3RnaW5kaW5AdXMuaWJtLmNv
bSZndDsgd3JpdGVzOjxCUj48QlI+ICAgIFRvbSZndDsgICAgICAgICBJZiBpdCBpc24ndCB0b28g
bGF0ZSB0byBmaXggdGhpcyB3aXRob3V0IGJyZWFraW5nPEJSPiAgICBUb20mZ3Q7IGxvdHMgb2Yg
aW1wbGVtZW50YXRpb25zLCB0aGUgQVNOLjEgaW4gdGhpcyBzcGVjaWZpY2F0aW9uIGlzPEJSPiAg
ICBUb20mZ3Q7IG92ZXItdGFnZ2VkLiAgSW4gc2VjdGlvbiAzLjIuMSwgYWxsIHRocmVlIG9mIHRo
ZSB0YWdzIGluPEJSPiAgICBUb20mZ3Q7IFBBLVBLLUFTLVJFUSBhcmUgdW5uZWNlc3NhcnksIGFu
ZCB0aGUgb25lIG9uIHNpZ25lZEF1dGhQYWNrPEJSPiAgICBUb20mZ3Q7IGlzIGFjdHVhbGx5IHNs
aWdodGx5IGhhcm1mdWwuICBOb25lIG9mIHRoZSB0YWdzIGluPEJSPiAgICBUb20mZ3Q7IFBLQXV0
aGVudGljYXRvciBkbyBhbnkgZ29vZCBlaXRoZXIuICBUaGUgT0NURVQgU1RSSU5HPEJSPiAgICBU
b20mZ3Q7IHdyYXBwaW5ncyBmb3Igc3ViamVjdE5hbWUgYW5kIGlzc3VlckFuZFNlcmlhbE51bWJl
ciBhcmUgbm90PEJSPiAgICBUb20mZ3Q7IHJlYWxseSBhcHByb3ByaWF0ZSwgYW5kIHN1YmplY3RO
YW1lIGRvZXNuJ3QgbmVlZCBhIHRhZy4gIEV2ZW48QlI+ICAgIFRvbSZndDsgaW4gQXV0aFBhY2ss
IHBrQXV0aGVudGljYXRvciBhbmQgY2xpZW50REhOb25jZSBkb24ndCBuZWVkPEJSPiAgICBUb20m
Z3Q7IHRhZ3MuICBTaW1pbGFybHksIGluIDMuMi4zLCB0aGVyZSBpcyBubyByZWFzb24gZm9yIGFu
eSBvZiB0aGU8QlI+ICAgIFRvbSZndDsgdGFncyBpbiBQQS1QSy1BUy1SRVAsIERIUmVwSW5mbywg
b3IgS0RDREhLZXlJbmZvLiAgVGhlIHRhZ3M8QlI+ICAgIFRvbSZndDsgaW4gUmVwbHlLZXlQYWNr
IGluIDMuMi4zLjIgYWxzbyBzZWVtIHVubmVjZXNzYXJ5LjxCUj48QlI+VGhlIGtlcmJlcm9zIHdv
cmtpbmcgZ3JvdXAgaGFzIGEgcmF0aGVyIGRpZmZlcmVudCBwaGlsb3NvcGh5IG9uIEFTTi4xPEJS
PnRoYW4gdGhlIFBLSVggY29tbXVuaXR5LiAgV2UndmUgYXR0ZW1wdGVkIHRvIGRyYXcgc3Ryb25n
IGJvdW5kYXJpZXM8QlI+YXJvdW5kIHN0cnVjdHVyZXMgdG8gdGhlIGV4dGVudCB0aGF0IHdlIGNh
bjoga2VyYmVyb3Mgc3RydWN0dXJlcyB1c2U8QlI+b3VyIGNvbnZlbnRpb25zOyBQS0lYIHN0cnVj
dHVyZXMgdXNlIHlvdXJzLjxCUj48QlI+VGhlIHNob3J0IGFuc3dlciBpcyB0aGF0IHRhZ2dpbmcg
aXNzdWVzIGhhdmUgYmVlbiBkaXNjdXNzZWQ8QlI+ZXh0ZW5zaXZlbHkgYWNyb3NzIGFsbCBvdXIg
QVNOLjEgdXNhZ2UuPEJSPjxCUj48L0ZPTlQ+



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA1JKoEE074249; Tue, 1 Nov 2005 11:20:50 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA1JKoj2074248; Tue, 1 Nov 2005 11:20:50 -0800 (PST)
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.11/8.12.9) with ESMTP id jA1JKnWr074232 for <[e-mail]>; Tue, 1 Nov 2005 11:20:49 -0800 (PST) (envelope-from [e-mail])
Received: from 204.127.135.57 ([204.127.135.57]) by worldnet.att.net (mtiwmhc12) with SMTP id <2005110119203311200egrf4e>; Tue, 1 Nov 2005 19:20:44 +0000
Received: from [64.127.102.91] by 204.127.135.57; Tue, 01 Nov 2005 19:20:32 +0000
From: [e-mail]
To: Sam Hartman <[e-mail]>, Tom Gindin <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos
Date: Tue, 01 Nov 2005 19:20:32 +0000
Message-Id: <110120051920.[e-mail]>
X-Mailer: AT&T Message Center Version 1 (Oct 30 2005)
X-Authenticated-Sender: dG9kZC5nbGFzc2V5QGF0dC5uZXQSender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sam what you are looking at is the obvious incompetence in the IETF and ISOC's management to allow for a myriad of incompatible notation schemas... Just another reason why the IETF is a joke.

Todd Glassey
 -------------- Original message ----------------------
From: Sam Hartman <[e-mail]>
> 
> >>>>> "Tom" = Tom Gindin <[e-mail]> writes:
> 
>     Tom>         If it isn't too late to fix this without breaking
>     Tom> lots of implementations, the ASN.1 in this specification is
>     Tom> over-tagged.  In section 3.2.1, all three of the tags in
>     Tom> PA-PK-AS-REQ are unnecessary, and the one on signedAuthPack
>     Tom> is actually slightly harmful.  None of the tags in
>     Tom> PKAuthenticator do any good either.  The OCTET STRING
>     Tom> wrappings for subjectName and issuerAndSerialNumber are not
>     Tom> really appropriate, and subjectName doesn't need a tag.  Even
>     Tom> in AuthPack, pkAuthenticator and clientDHNonce don't need
>     Tom> tags.  Similarly, in 3.2.3, there is no reason for any of the
>     Tom> tags in PA-PK-AS-REP, DHRepInfo, or KDCDHKeyInfo.  The tags
>     Tom> in ReplyKeyPack in 3.2.3.2 also seem unnecessary.
> 
> The kerberos working group has a rather different philosophy on ASN.1
> than the PKIX community.  We've attempted to draw strong boundaries
> around structures to the extent that we can: kerberos structures use
> our conventions; PKIX structures use yours.
> 
> The short answer is that tagging issues have been discussed
> extensively across all our ASN.1 usage.
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA1IFa6k065587; Tue, 1 Nov 2005 10:15:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA1IFanS065586; Tue, 1 Nov 2005 10:15:36 -0800 (PST)
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.11/8.12.9) with ESMTP id jA1IFYk4065578 for <[e-mail]>; Tue, 1 Nov 2005 10:15:35 -0800 (PST) (envelope-from [e-mail])
Received: from champagne.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id jA1IFPi00571; Tue, 1 Nov 2005 19:15:25 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/2.4); Tue, 1 Nov 2005 19:15:25 +0100 (MET)
Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id TAA08421; Tue, 1 Nov 2005 19:15:24 +0100 (MET)
Message-ID: <[e-mail]>
Date: Tue, 01 Nov 2005 19:15:24 +0100
From: Peter Sylvester <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tom Gindin <[e-mail]>
CC: Sam Hartman <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060708060608030909050701"
Sender: [e-mail]
Precedence: 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 cryptographically signed message in MIME format.

--------------ms060708060608030909050701
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

I think I second Tom Gindin.

Itseems strange to me to have pieces of the specification
as comments of the asn.1.

example:

          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
                   -- Contains a PKIX type Name encoded according to
                   -- [RFC3280].
                   -- Identifies the certificate subject by the
                   -- distinguished subject name.
                   -- REQUIRED when there is a distinguished subject
                   -- name present in the certificate.


The first two lines are syntactic specification, it was common
to have such syntactical restrictions until some years ago.
The others don't belong to the syntax at all.

The first one can be replaced by

        subjectName            [0] IMPLICIT OCTET STRING OPTIONAL CONTAINING Name

and an IMPORT that imports Name from an appropiate module. 


I have the feeling that the following sentence doesn't make sense.

   All data structures carried in OCTET
   STRINGs must be encoded according to the rules specified in
   corresponding specifications.

because as far as I remeber the texts, none of the specifications have 
any particular
requirement on the encoding, You can encode everything in XER, can't you?

There are lots of exemples of useless tagging iKDCDHKeyInfo or
PKAuthenticator All base tags are different, and there is only one 
optional field.
Well, that'a a matter of style as well as the global EXPLICIT default.

          nonce                   [1] INTEGER (0..4294967295),
                   -- Contains the nonce in the PKAuthenticator of the
                   -- request if DH keys are NOT reused,
                   -- 0 otherwise.

To me the comment seems to suggest that

	nonce                   INTEGER (1..4294967295) OPTIONAL 


could be more appropriate. But, the nonce in PKAuthenticator says:

          nonce                   [2] INTEGER (0..4294967295),
                   -- Chosen randomly;  This nonce does not need to
                   -- match with the nonce in the KDC-REQ-BODY.

so it can be 0.



This comment doesn't change anything fundamental of the spec.


Tom Gindin wrote:

>        If it isn't too late to fix this without breaking lots of 
>implementations, the ASN.1 in this specification is over-tagged.  In 
>section 3.2.1, all three of the tags in PA-PK-AS-REQ are unnecessary, and 
>the one on signedAuthPack is actually slightly harmful.  None of the tags 
>in PKAuthenticator do any good either.  The OCTET STRING wrappings for 
>subjectName and issuerAndSerialNumber are not really appropriate, and 
>subjectName doesn't need a tag.  Even in AuthPack, pkAuthenticator and 
>clientDHNonce don't need tags.
>        Similarly, in 3.2.3, there is no reason for any of the tags in 
>PA-PK-AS-REP, DHRepInfo, or KDCDHKeyInfo.  The tags in ReplyKeyPack in 
>3.2.3.2 also seem unnecessary.
>
>Tom Gindin
>P.S. - The opinions above are mine, and not necessarily those of my 
>employer.
>
>
>  
>


-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. 


--------------ms060708060608030909050701
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC
BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G
A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs
UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx
CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ
S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu
ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo
VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq
q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID
AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5
MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT
VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F
ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV
HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA
A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U
TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8
1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5
V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9
F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely
LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+
udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr
LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy
MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp
Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA
ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN
LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy
x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm
T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl
Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl
ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F
ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx
cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI
hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2
mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT
g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ
bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4
88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8
oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI
MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m
JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0
MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV
HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3
UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy
4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz
QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u
US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj
PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq
Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf
Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y
rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6
PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL
d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18
k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg
d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD
VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ
S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMTAxMTgxNTI0WjAjBgkqhkiG9w0B
CQQxFgQUe0Vr+/CFxbYNyLxDIydYAffsp9UwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY
MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy
c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE
ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ
IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAUk09SnLZJ2ZMhXIr
6ozmuomkDh4Xez1ZKoyTwSNEf5ry+MocutaUI4NCsoRxibZn8SPISFZbGNGoMgdNz5Qhxn/h
2/d4k2fcnHwszXuoSQ2DXXMymJ7mh2RvUG6axZw2fWq18G1n1h20RixxlksXmOjrEf7s8ybx
1NaE5l46qYAAAAAAAAA--------------ms060708060608030909050701--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA1GGuf2048552; Tue, 1 Nov 2005 08:16:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA1GGuRO048551; Tue, 1 Nov 2005 08:16:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.mit.edu (h193007.nist.gov [129.6.193.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA1GGuEd048544 for <[e-mail]>; Tue, 1 Nov 2005 08:16:56 -0800 (PST) (envelope-from [e-mail])
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 6F99EE0049; Tue,  1 Nov 2005 09:27:12 -0500 (EST)
To: Tom Gindin <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos
References: <[e-mail]>
From: Sam Hartman <[e-mail]>
Date: Tue, 01 Nov 2005 09:27:12 -0500
In-Reply-To: <[e-mail]> (Tom Gindin's message of "Tue, 1 Nov 2005 08:36:31 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
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>

>>>>> "Tom" = Tom Gindin <[e-mail]> writes:

    Tom>         If it isn't too late to fix this without breaking
    Tom> lots of implementations, the ASN.1 in this specification is
    Tom> over-tagged.  In section 3.2.1, all three of the tags in
    Tom> PA-PK-AS-REQ are unnecessary, and the one on signedAuthPack
    Tom> is actually slightly harmful.  None of the tags in
    Tom> PKAuthenticator do any good either.  The OCTET STRING
    Tom> wrappings for subjectName and issuerAndSerialNumber are not
    Tom> really appropriate, and subjectName doesn't need a tag.  Even
    Tom> in AuthPack, pkAuthenticator and clientDHNonce don't need
    Tom> tags.  Similarly, in 3.2.3, there is no reason for any of the
    Tom> tags in PA-PK-AS-REP, DHRepInfo, or KDCDHKeyInfo.  The tags
    Tom> in ReplyKeyPack in 3.2.3.2 also seem unnecessary.

The kerberos working group has a rather different philosophy on ASN.1
than the PKIX community.  We've attempted to draw strong boundaries
around structures to the extent that we can: kerberos structures use
our conventions; PKIX structures use yours.

The short answer is that tagging issues have been discussed
extensively across all our ASN.1 usage.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA1DaiPp030249; Tue, 1 Nov 2005 05:36:44 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA1DaiRH030248; Tue, 1 Nov 2005 05:36:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA1DagWl030223 for <[e-mail]>; Tue, 1 Nov 2005 05:36:42 -0800 (PST) (envelope-from [e-mail])
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jA1DaYXM026781 for <[e-mail]>; Tue, 1 Nov 2005 08:36:34 -0500
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id jA1DaY5c104730 for <[e-mail]>; Tue, 1 Nov 2005 08:36:34 -0500
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jA1DaXnB023377 for <[e-mail]>; Tue, 1 Nov 2005 08:36:34 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jA1DaXsx023369; Tue, 1 Nov 2005 08:36:33 -0500
In-Reply-To: <[e-mail]>
To: Sam Hartman <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
MIME-Version: 1.0
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 1 Nov 2005 08:36:31 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.5.4FP1 HF2|August 30, 2005) at 11/01/2005 08:36:32, Serialize complete at 11/01/2005 08:36:32
Content-Type: text/plain; charset="US-ASCII"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        If it isn't too late to fix this without breaking lots of 
implementations, the ASN.1 in this specification is over-tagged.  In 
section 3.2.1, all three of the tags in PA-PK-AS-REQ are unnecessary, and 
the one on signedAuthPack is actually slightly harmful.  None of the tags 
in PKAuthenticator do any good either.  The OCTET STRING wrappings for 
subjectName and issuerAndSerialNumber are not really appropriate, and 
subjectName doesn't need a tag.  Even in AuthPack, pkAuthenticator and 
clientDHNonce don't need tags.
        Similarly, in 3.2.3, there is no reason for any of the tags in 
PA-PK-AS-REP, DHRepInfo, or KDCDHKeyInfo.  The tags in ReplyKeyPack in 
3.2.3.2 also seem unnecessary.

Tom Gindin
P.S. - The opinions above are mine, and not necessarily those of my 
employer.






Sam Hartman <[e-mail]>
Sent by: [e-mail]
10/28/2005 09:12 AM
 
        To:     [e-mail]
        cc:     [e-mail]
        Subject:        [Jeffrey Hutzelman] LAST CALL - Public Key 
Cryptography for Initial Authentication in Kerberos




Hi.  The Kerberos working group has started a last call on the pkinit
draft.  Pkinit is a mechanism for acquiring kerberos tickets based on
knowledge of a private key.  It also supports and is typically used
with a PKI.

I'd appreciate any review that members of the pkix working group can
provide on this document.




----- Message from Unknown on Unknown -----


solipsist-nation ([unix socket]) by solipsist-nation (Cyrus
v2.1.16-IPv6-Debian-2.1.16-10) with LMTP; Sun, 23 Oct 2005 22:07:31
-0400 X-Sieve: CMU Sieve 2.2 Return-Path:
<[e-mail]> Received: from
south-station-annex.mit.edu (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client
certificate requested) by suchdamage.org (Postfix) with ESMTP id
9BDFA1383E for <[e-mail]>; Sun, 23 Oct 2005 22:07:24
-0400 (EDT) Received: from pacific-carrier-annex.mit.edu
(PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by
south-station-annex.mit.edu (8.12.4/8.9.2) with ESMTP id
j9O27MkZ012927 for <[e-mail]>; Sun, 23 Oct 2005
22:07:22 -0400 (EDT) Received: from mailhost.anl.gov (mailhost.anl.gov
[130.202.113.50]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with
ESMTP id j9O26Emq005270; Sun, 23 Oct 2005 22:06:14 -0400 (EDT)
Received: by mailhost.anl.gov (Postfix) id 18622286; Sun, 23 Oct 2005
21:06:13 -0500 (CDT) Delivered-To: [e-mail]
Received: from mailhost.anl.gov (localhost [127.0.0.1]) by
localhost.ctd.anl.gov (Postfix) with ESMTP id E87EA26D for
<[e-mail]>; Sun, 23 Oct 2005 21:06:12 -0500 (CDT)
Received: by mailhost.anl.gov (Postfix, from userid 10733) id
D6987286; Sun, 23 Oct 2005 21:06:12 -0500 (CDT) X-Original-To:
[e-mail] Delivered-To: [e-mail] Received: from
mailhost.anl.gov (localhost [127.0.0.1]) by localhost.ctd.anl.gov
(Postfix) with ESMTP id 5D96227F for <[e-mail]>; Sun, 23
Oct 2005 21:06:12 -0500 (CDT) Received: from mailrelay.anl.gov
(mailrelay.anl.gov [130.202.101.22]) by mailhost.anl.gov (Postfix)
with ESMTP id 4C9D526D for <[e-mail]>; Sun, 23 Oct 2005
21:06:12 -0500 (CDT) Received: from mailrelay.anl.gov (localhost
[127.0.0.1]) by localhost.ctd.anl.gov (Postfix) with ESMTP id
D63D05F0D5B; Sun, 23 Oct 2005 21:06:11 -0500 (CDT) Received: from
currant.srv.cs.cmu.edu (CURRANT.SRV.CS.CMU.EDU [128.2.194.193]) by
mailrelay.anl.gov (Postfix) with SMTP id 7F1595F0D5A for
<[e-mail]>; Sun, 23 Oct 2005 21:06:11 -0500 (CDT) Received:
from CRUNCHBERRY.SRV.CS.CMU.EDU ([128.2.203.75]) by
currant.srv.cs.cmu.edu id aa18518; 23 Oct 2005 22:06 EDT Received:
from jhutz-dyn0.pc.cs.cmu.edu
(IDENT:U2FsdGVkX1+t+NgCyV0xi/[e-mail]
[128.2.200.136]) (authenticated bits=0) by crunchberry.srv.cs.cmu.edu
(8.13.4/8.13.4) with ESMTP id j9O264gX002260 (version=TLSv1/SSLv3
cipheríH-RSA-DES-CBC3-SHA bits8 verify=NO); Sun, 23 Oct 2005
22:06:05 -0400 (EDT) Date: Sun, 23 Oct 2005 22:06:00 -0400 From:
Jeffrey Hutzelman <[e-mail]> To: [e-mail] Cc: Jeffrey
Hutzelman <[e-mail]> Subject: LAST CALL - Public Key Cryptography
for Initial Authentication in Kerberos Message-ID:
<[e-mail]> Originator-Info:
login-token=Mulberry:01ouPFOwxLOq/uLj281WH1qjlV/GYpFz4PWPOg2GM=;
token_authority=[e-mail] X-Mailer: Mulberry/3.1.6
(Linux/x86) Sender: [e-mail] Precedence:
bulk X-Scanned-By: MIMEDefang 2.42 X-Spam-Checker-Version:
SpamAssassin 3.0.2 (2004-11-16) on solipsist-nation.suchdamage.org
X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0
tests=AWL,BAYES_00 autolearn=ham version=3.0.2
MIME-Version: 1.0

At long last...

As of October 23, 2005, I am beginning a two-week Last Call period
on the following document:

                 Title                           : Public Key Cryptography 
for
                          Initial Authentication in Kerberos
                 Author(s)               : B. Tung, L. Zhu
                 Filename                : 
draft-ietf-cat-kerberos-pk-init-29.txt
                 Pages                           : 36
                 Date                            : 2005-10-21

Comments on this document should be sent to the Kerberos Working Group
mailing list, [e-mail], and will be accepted at least until
11:59pm EST on November 6, 2005.  All issues raised will be entered
into the Request Tracker system at https://rt.psg.com/.


Once the Last Call period has ended, I will make a determination as to
whether there remain any unresolved issue, and whether there is a rough
consensus withing the working group to send this document to the IESG for
publication as a Proposed Standard.

-- Jeffrey T. Hutzelman (N3NHS) <[e-mail]>
   Chair, IETF Kerberos Working Group
   Carnegie Mellon University - Pittsburgh, PA