From owner-ietf-pkix@mail.imc.org Sat Oct 01 02:55:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELbHA-0004yK-Jp for pkix-archive@megatron.ietf.org; Sat, 01 Oct 2005 02:55:18 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27960 for ; Sat, 1 Oct 2005 02:55:14 -0400 (EDT) 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 j9167X78050378; Fri, 30 Sep 2005 23:07:34 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9167XSJ050377; Fri, 30 Sep 2005 23:07:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpauth06.mail.atl.earthlink.net (smtpauth06.mail.atl.earthlink.net [209.86.89.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9167XWo050371 for ; Fri, 30 Sep 2005 23:07:33 -0700 (PDT) (envelope-from hoytkesterson@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=MIhRhf8bFbM8JQeMrx1Akh4h/aNz2xNwisvIDtLSpOL2fGI52+pfQuZA641Bmh/m; h=Received:Mime-Version:Message-Id:Date:To:From:Subject:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [130.13.80.76] (helo=[192.168.0.3]) by smtpauth06.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1ELaWj-00031Z-Fo; Sat, 01 Oct 2005 02:07:17 -0400 Mime-Version: 1.0 Message-Id: Date: Fri, 30 Sep 2005 23:07:06 -0700 To: "X.509":; From: Hoyt L Kesterson II Subject: DR 314 - New Defect report and DTC on Name Constraints Content-Type: text/html; charset="us-ascii" X-ELNK-Trace: 59f3edefb26af0321a6f9084d36cbc6474bf435c0eb9d47808daa5b3e7ca120f7254c95654298909e5231b431cb7c002350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.13.80.76 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: DR 314 - New Defect report and DTC on Name Constraints
I meant DR 314. The referenced files were correct; the error occurred only in the body of the email.

A new defect report, DR 214, has been posted to the server at

  ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/AllDefectReports/DR_314.pdf

Two DTCs have been sent to the Secretariat for balloting. The one for the 4th edition is at

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigenda/Closing%20January%202006/X.509DTC-10(4th).pdf

The one for the 5th edition (scheduled for publishing at the end of 2005) is at

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigenda/Closing%20January%202006/X.509DTC-1(5th).pdf

I will let you know what the ballot close date is when it is set by the SC6 Secretariat

   hoyt
From owner-ietf-pkix@mail.imc.org Sun Oct 02 11:32:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EM5pI-0005FK-VO for pkix-archive@megatron.ietf.org; Sun, 02 Oct 2005 11:32:33 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20631 for ; Sun, 2 Oct 2005 11:32:30 -0400 (EDT) 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 j92EZQL3055292; Sun, 2 Oct 2005 07:35:26 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j92EZPFU055291; Sun, 2 Oct 2005 07:35:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from uekae.uekae.gov.tr (uekaegateway.mam.gov.tr [193.140.74.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j92EZOCn055285 for ; Sun, 2 Oct 2005 07:35:25 -0700 (PDT) (envelope-from egulacti@uekae.tubitak.gov.tr) Received: from www.uekae.tubitak.gov.tr (hitit.uekae.tubitak.gov.tr [192.168.5.6]) by uekae.uekae.gov.tr (UEKAE_MAIL_SERVER_V4) with ESMTP id 0DEBEBD65CA for ; Sun, 2 Oct 2005 17:32:39 +0300 (EEST) Received: from 85.96.157.50 (SquirrelMail authenticated user egulacti) by www.uekae.tubitak.gov.tr with HTTP; Sun, 2 Oct 2005 17:33:33 +0300 (EEST) Date: Sun, 2 Oct 2005 17:33:33 +0300 (EEST) Subject: RFC for Certificate Store From: "Ersin Gulacti" To: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-9 X-Priority: 3 (Normal) Importance: Normal Message-Id: <20051002143239.C70C9BD65CA@uekae.uekae.gov.tr> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j92EZPCn055286 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hello, On the PKIX page it is declared that on Jun 2005 Certificate Store is approved as Informational RFC. Unfortunately I couldn't find any documents related to this RFC. Is it going to be released soon? Or better can someone post a copy of it? We plan to implement a certificate store and I would prefer to read a related RFC before starting our design. Thanks. Ersin Gulacti From owner-ietf-pkix@mail.imc.org Sun Oct 02 14:53:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EM8xN-0004WR-1m for pkix-archive@megatron.ietf.org; Sun, 02 Oct 2005 14:53:05 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27159 for ; Sun, 2 Oct 2005 14:53:03 -0400 (EDT) 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 j92ID1JI087094; Sun, 2 Oct 2005 11:13:01 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j92ID1nP087093; Sun, 2 Oct 2005 11:13:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j92ID08r087087 for ; Sun, 2 Oct 2005 11:13:00 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 21344 invoked by uid 0); 2 Oct 2005 18:12:54 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (212.147.51.217) by woodstock.binhost.com with SMTP; 2 Oct 2005 18:12:54 -0000 Message-Id: <6.2.1.2.2.20051002140915.05d69c20@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 02 Oct 2005 14:10:47 -0400 To: "Ersin Gulacti" , ietf-pkix@imc.org From: Russ Housley Subject: Re: RFC for Certificate Store In-Reply-To: <20051002143239.C70C9BD65CA@uekae.uekae.gov.tr> References: <20051002143239.C70C9BD65CA@uekae.uekae.gov.tr> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It is in the RFC Editor queue:

2005-08-23      

draft-ietf-pkix-certstore-http-09.txt
EDIT
P. Gutmann
Internet X.509 Public Key Infrastructure Operational Protocols:
Certificate Store Access via HTTP
Bytes: 52680
Working Group: Public-Key Infrastructure (X.509)
At 10:33 AM 10/2/2005, Ersin Gulacti wrote:


Hello,

On the PKIX page it is declared that on Jun 2005 Certificate Store is
approved as Informational RFC. Unfortunately I couldn't find any documents
related to this RFC. Is it going to be released soon? Or better can
someone post a copy of it? We plan to implement a certificate store and I
would prefer to read a related RFC before starting our design.

Thanks.

Ersin Gulacti
From owner-ietf-pkix@mail.imc.org Mon Oct 10 15:26:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP3Hm-00006M-F6 for pkix-archive@megatron.ietf.org; Mon, 10 Oct 2005 15:26:10 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15673 for ; Mon, 10 Oct 2005 15:26:08 -0400 (EDT) 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 j9AIQS4M053355; Mon, 10 Oct 2005 11:26:28 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9AIQSr8053354; Mon, 10 Oct 2005 11:26:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9AIQQZx053345 for ; Mon, 10 Oct 2005 11:26:27 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 6508 invoked by uid 0); 10 Oct 2005 18:25:13 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.183.78) by woodstock.binhost.com with SMTP; 10 Oct 2005 18:25:13 -0000 Message-Id: <6.2.1.2.2.20051010142255.06892020@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 10 Oct 2005 14:25:12 -0400 To: ietf-pkix@imc.org From: Russ Housley Subject: Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please take a look at draft-ietf-dnsext-rfc2538bis-08. It is on the agenda for the IESG telechat this Thursday. If anyone has any concerns, please notify me by Wednesday. Russ From owner-ietf-pkix@mail.imc.org Wed Oct 12 17:05:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPnnR-0006yL-BJ for pkix-archive@megatron.ietf.org; Wed, 12 Oct 2005 17:05:57 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05730 for ; Wed, 12 Oct 2005 17:05:53 -0400 (EDT) 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 j9CK84cR066030; Wed, 12 Oct 2005 13:08:04 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9CK84L0066027; Wed, 12 Oct 2005 13:08:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9CK80L3066017 for ; Wed, 12 Oct 2005 13:08:01 -0700 (PDT) (envelope-from shu-jen.chang@nist.gov) 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 j9CJsijb011784; Wed, 12 Oct 2005 15:55:57 -0400 Received: from othello.nist.gov (othello.ncsl.nist.gov [129.6.54.41]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j9CJqTG4026166; Wed, 12 Oct 2005 15:52:29 -0400 (EDT) Message-Id: <5.1.1.5.2.20051012154229.0304b5d0@email.nist.gov> X-Sender: sjchang@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 12 Oct 2005 15:51:43 -0400 To: shu-jen.chang@nist.gov From: Shu-jen Chang Subject: Oops Re: Hash Workshop Program Ready and Posted Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_20986500==.ALT" X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: shu-jen.chang@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=====================_20986500==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Oops. I meant to hide the recipient list and just Blind CC them, but I forgot to do that before I hit the send key. Also, I was going to remove the attachment, but I got distracted and forgot to do that too. I am very sorry, especially to Professor Yao. Apologetically, Shu-jen Chang --=====================_20986500==.ALT Content-Type: text/html; charset="us-ascii" Oops. I meant to hide the recipient list and just Blind CC them, but I forgot to do that before I hit the send key. Also, I was going to remove the attachment, but I got distracted and forgot to do that too. I am very sorry, especially to Professor Yao.

Apologetically,
Shu-jen Chang
--=====================_20986500==.ALT-- From owner-ietf-pkix@mail.imc.org Wed Oct 12 19:18:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPprd-0003Rr-In for pkix-archive@megatron.ietf.org; Wed, 12 Oct 2005 19:18:27 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11331 for ; Wed, 12 Oct 2005 19:18:21 -0400 (EDT) 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 j9CMdCB8079346; Wed, 12 Oct 2005 15:39:12 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9CMdCoJ079345; Wed, 12 Oct 2005 15:39:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9CMd7Vc079333 for ; Wed, 12 Oct 2005 15:39:07 -0700 (PDT) (envelope-from tgindin@us.ibm.com) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j9CMd1Q4023760 for ; Wed, 12 Oct 2005 18:39:01 -0400 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 j9CMd16E103212 for ; Wed, 12 Oct 2005 18:39:01 -0400 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 j9CMd0ue028109 for ; Wed, 12 Oct 2005 18:39:00 -0400 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 j9CMd0p3028096; Wed, 12 Oct 2005 18:39:00 -0400 In-Reply-To: <6.2.1.2.2.20051010142255.06892020@mail.binhost.com> To: Russ Housley Cc: ietf-pkix@imc.org, simon@josefsson.org MIME-Version: 1.0 Subject: Re: Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08) X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Tom Gindin Message-ID: Date: Wed, 12 Oct 2005 18:38:58 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 10/12/2005 18:38:59, Serialize complete at 10/12/2005 18:38:59 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ: Are there any guidelines for CRL owner names, since they're covered in the draft although DNS distribution points aren't detailed in RFC 3280? If there aren't any, IMHO a reasonable rule would be that if any sequence member of the distribution point name is a domain name (not a URI), that should be used. Also (and lower in precedence), if any sequence member of the distribution point name is an RFC 822 address, its standard translation should be used. I doubt if URI's will work without conflicts. I don't know if these count as "concerns". Tom Gindin P.S. The opinions above are mine, and not necessarily those of my employer. From owner-ietf-pkix@mail.imc.org Wed Oct 12 23:12:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPtVe-0007lT-SC for pkix-archive@megatron.ietf.org; Wed, 12 Oct 2005 23:12:03 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19671 for ; Wed, 12 Oct 2005 23:11:54 -0400 (EDT) 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 j9D2NR99097135; Wed, 12 Oct 2005 19:23:27 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9D2NRpG097134; Wed, 12 Oct 2005 19:23:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9D2NQL2097127 for ; Wed, 12 Oct 2005 19:23:26 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by colibri.verisign.com (8.13.1/8.13.4) with ESMTP id j9D2NLNX007342; Wed, 12 Oct 2005 19:23:21 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Oct 2005 19:23:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08) Date: Wed, 12 Oct 2005 19:23:20 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD376D51AB@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08) Thread-Index: AcXPhxBGZ1gNKPvpTcWuwqYTEn+ixAACab6g From: "Hallam-Baker, Phillip" To: "Tom Gindin" , "Russ Housley" Cc: , X-OriginalArrivalTime: 13 Oct 2005 02:23:21.0293 (UTC) FILETIME=[14A267D0:01C5CF9D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j9D2NQL2097129 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit While storing certificates in the DNS makes sense in some applications I would be concerned if this proposal was intended to make DNS the recommended storage mechanism. The problem is that the original DNS protocol has a hard wired limit of 512 bytes for a UDP packet after which it falls back to TCPIP. This limitation has been eased in part by the DNSEXT work but the maximum UDP packet size is still effectively limited by the Ethernet MTA in most real world applications. If the application falls back to TCP it is much simpler, cleaner and more effective to simply use HTTP which is designed as a TCPIP protocol. In theory DNSEXT is deployed and TCPIP fallback for DNS works fine. The practice is very different. The DNSEXT group has a habbit of faith based deployment, i.e. if they declare the protocol deployed it is deployed. There are certainly cases where storing a cert in the DNS is useful but it is important that the limitations of this approach be understood and that it does not become another architectural fiat from the DNSEXT group. > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Tom Gindin > Sent: Wednesday, October 12, 2005 6:39 PM > To: Russ Housley > Cc: ietf-pkix@imc.org; simon@josefsson.org > Subject: Re: Storing Certificates in the DNS > (draft-ietf-dnsext-rfc2538bis-08) > > > Russ: > > Are there any guidelines for CRL owner names, since > they're covered in the draft although DNS distribution points > aren't detailed in RFC 3280? If there aren't any, IMHO a > reasonable rule would be that if any sequence member of the > distribution point name is a domain name (not a URI), that > should be used. Also (and lower in precedence), if any > sequence member of the distribution point name is an RFC 822 > address, its standard translation should be used. I doubt if > URI's will work without conflicts. > I don't know if these count as "concerns". > > Tom Gindin > P.S. The opinions above are mine, and not necessarily those of my > employer. > > > From owner-ietf-pkix@mail.imc.org Thu Oct 13 11:31:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ53N-000050-EX for pkix-archive@megatron.ietf.org; Thu, 13 Oct 2005 11:31:33 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24082 for ; Thu, 13 Oct 2005 11:31:29 -0400 (EDT) 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 j9DEhnXq005390; Thu, 13 Oct 2005 07:43:49 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9DEhnvu005389; Thu, 13 Oct 2005 07:43:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9DEhmEZ005343 for ; Thu, 13 Oct 2005 07:43:48 -0700 (PDT) (envelope-from todd.glassey@att.net) Received: from 204.127.135.58 ([204.127.135.58]) by worldnet.att.net (mtiwmhc12) with SMTP id <2005101314433811200eemhme>; Thu, 13 Oct 2005 14:43:42 +0000 Received: from [64.127.102.91] by 204.127.135.58; Thu, 13 Oct 2005 14:43:37 +0000 From: todd.glassey@att.net To: "Hallam-Baker, Phillip" , "Tom Gindin" , "Russ Housley" Cc: , Subject: RE: Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08) Date: Thu, 13 Oct 2005 14:43:37 +0000 Message-Id: <101320051443.13707.434E72990005C3C50000358B2160281060970A9C9C0E0409D20B0B019B@att.net> X-Mailer: AT&T Message Center Version 1 (Feb 14 2005) X-Authenticated-Sender: dG9kZC5nbGFzc2V5QGF0dC5uZXQ= Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: phb - NO ONE in their right mind would use DNS as the only repository for storing certificates and this initiative and the conversations in re of this idea are demonstrative of how little PKIX has a grip on reality IMHO. Clearly storing certs for DNS in DNS and possibly in some limited scope might work, but the reality is why bother - the issue is in the trust and use models - something which this group refuses to do... T. -------------- Original message ---------------------- From: "Hallam-Baker, Phillip" > > While storing certificates in the DNS makes sense in some applications I > would be concerned if this proposal was intended to make DNS the > recommended storage mechanism. > > The problem is that the original DNS protocol has a hard wired limit of > 512 bytes for a UDP packet after which it falls back to TCPIP. This > limitation has been eased in part by the DNSEXT work but the maximum UDP > packet size is still effectively limited by the Ethernet MTA in most > real world applications. If the application falls back to TCP it is much > simpler, cleaner and more effective to simply use HTTP which is designed > as a TCPIP protocol. > > In theory DNSEXT is deployed and TCPIP fallback for DNS works fine. The > practice is very different. The DNSEXT group has a habbit of faith based > deployment, i.e. if they declare the protocol deployed it is deployed. > > There are certainly cases where storing a cert in the DNS is useful but > it is important that the limitations of this approach be understood and > that it does not become another architectural fiat from the DNSEXT > group. > > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Tom Gindin > > Sent: Wednesday, October 12, 2005 6:39 PM > > To: Russ Housley > > Cc: ietf-pkix@imc.org; simon@josefsson.org > > Subject: Re: Storing Certificates in the DNS > > (draft-ietf-dnsext-rfc2538bis-08) > > > > > > Russ: > > > > Are there any guidelines for CRL owner names, since > > they're covered in the draft although DNS distribution points > > aren't detailed in RFC 3280? If there aren't any, IMHO a > > reasonable rule would be that if any sequence member of the > > distribution point name is a domain name (not a URI), that > > should be used. Also (and lower in precedence), if any > > sequence member of the distribution point name is an RFC 822 > > address, its standard translation should be used. I doubt if > > URI's will work without conflicts. > > I don't know if these count as "concerns". > > > > Tom Gindin > > P.S. The opinions above are mine, and not necessarily those of my > > employer. > > > > > > > From owner-ietf-pkix@mail.imc.org Thu Oct 13 12:15:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ5jm-0004TG-5E for pkix-archive@megatron.ietf.org; Thu, 13 Oct 2005 12:15:22 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26488 for ; Thu, 13 Oct 2005 12:15:17 -0400 (EDT) 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 j9DFV9ra017880; Thu, 13 Oct 2005 08:31:09 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9DFV9t4017877; Thu, 13 Oct 2005 08:31:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9DFV8VQ017848 for ; Thu, 13 Oct 2005 08:31:08 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 7422 invoked by uid 0); 13 Oct 2005 15:30:04 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.99.91) by woodstock.binhost.com with SMTP; 13 Oct 2005 15:30:04 -0000 Message-Id: <6.2.1.2.2.20051013112936.05c48280@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 13 Oct 2005 11:30:04 -0400 To: Tom Gindin From: Russ Housley Subject: Re: Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08) Cc: ietf-pkix@imc.org, simon@josefsson.org In-Reply-To: References: <6.2.1.2.2.20051010142255.06892020@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tom: Thanks for the review. I do not think that this kind of guidance belongs in draft-ietf-dnsext-rfc2538bis, but it does belong in 3280bis. Russ At 06:38 PM 10/12/2005, Tom Gindin wrote: > Russ: > > Are there any guidelines for CRL owner names, since they're >covered in the draft although DNS distribution points aren't detailed in >RFC 3280? If there aren't any, IMHO a reasonable rule would be that if >any sequence member of the distribution point name is a domain name (not a >URI), that should be used. Also (and lower in precedence), if any >sequence member of the distribution point name is an RFC 822 address, its >standard translation should be used. I doubt if URI's will work without >conflicts. > I don't know if these count as "concerns". > > Tom Gindin >P.S. The opinions above are mine, and not necessarily those of my >employer. From owner-ietf-pkix@mail.imc.org Thu Oct 13 12:13:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ5hg-0004GX-Q5 for pkix-archive@megatron.ietf.org; Thu, 13 Oct 2005 12:13:12 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26416 for ; Thu, 13 Oct 2005 12:13:04 -0400 (EDT) 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 j9DFbEEY019678; Thu, 13 Oct 2005 08:37:14 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9DFbEae019677; Thu, 13 Oct 2005 08:37:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9DFbDQF019671 for ; Thu, 13 Oct 2005 08:37:13 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 18605 invoked by uid 0); 13 Oct 2005 15:36:38 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.99.91) by woodstock.binhost.com with SMTP; 13 Oct 2005 15:36:38 -0000 Message-Id: <6.2.1.2.2.20051013113537.06447e10@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 13 Oct 2005 11:36:38 -0400 To: todd.glassey@att.net From: Russ Housley Subject: RE: Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08) Cc: ietf-pkix@imc.org, simon@josefsson.org In-Reply-To: <101320051443.13707.434E72990005C3C50000358B2160281060970A9 C9C0E0409D20B0B019B@att.net> References: <101320051443.13707.434E72990005C3C50000358B2160281060970A9C9C0E0409D20B0B019B@att.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Todd: This is not a PKIX work product, so you comments are directed at the wrong audience. Russ At 10:43 AM 10/13/2005, todd.glassey@att.net wrote: >phb - NO ONE in their right mind would use DNS as the only repository for >storing certificates and this initiative and the conversations in re of >this idea are demonstrative of how little PKIX has a grip on reality IMHO. >Clearly storing certs for DNS in DNS and possibly in some limited scope >might work, but the reality is why bother - the issue is in the trust and >use models - something which this group refuses to do... > >T. > -------------- Original message ---------------------- >From: "Hallam-Baker, Phillip" > > > > While storing certificates in the DNS makes sense in some applications I > > would be concerned if this proposal was intended to make DNS the > > recommended storage mechanism. > > > > The problem is that the original DNS protocol has a hard wired limit of > > 512 bytes for a UDP packet after which it falls back to TCPIP. This > > limitation has been eased in part by the DNSEXT work but the maximum UDP > > packet size is still effectively limited by the Ethernet MTA in most > > real world applications. If the application falls back to TCP it is much > > simpler, cleaner and more effective to simply use HTTP which is designed > > as a TCPIP protocol. > > > > In theory DNSEXT is deployed and TCPIP fallback for DNS works fine. The > > practice is very different. The DNSEXT group has a habbit of faith based > > deployment, i.e. if they declare the protocol deployed it is deployed. > > > > There are certainly cases where storing a cert in the DNS is useful but > > it is important that the limitations of this approach be understood and > > that it does not become another architectural fiat from the DNSEXT > > group. > > > > > > > -----Original Message----- > > > From: owner-ietf-pkix@mail.imc.org > > > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Tom Gindin > > > Sent: Wednesday, October 12, 2005 6:39 PM > > > To: Russ Housley > > > Cc: ietf-pkix@imc.org; simon@josefsson.org > > > Subject: Re: Storing Certificates in the DNS > > > (draft-ietf-dnsext-rfc2538bis-08) > > > > > > > > > Russ: > > > > > > Are there any guidelines for CRL owner names, since > > > they're covered in the draft although DNS distribution points > > > aren't detailed in RFC 3280? If there aren't any, IMHO a > > > reasonable rule would be that if any sequence member of the > > > distribution point name is a domain name (not a URI), that > > > should be used. Also (and lower in precedence), if any > > > sequence member of the distribution point name is an RFC 822 > > > address, its standard translation should be used. I doubt if > > > URI's will work without conflicts. > > > I don't know if these count as "concerns". > > > > > > Tom Gindin > > > P.S. The opinions above are mine, and not necessarily those of my > > > employer. > > > > > > > > > > > From owner-ietf-pkix@mail.imc.org Thu Oct 13 13:00:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ6Qz-0001Fw-Ke for pkix-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:00:01 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28757 for ; Thu, 13 Oct 2005 12:59:56 -0400 (EDT) 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 j9DGG0UG032409; Thu, 13 Oct 2005 09:16:00 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9DGG08t032405; Thu, 13 Oct 2005 09:16:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9DGFx1G032379 for ; Thu, 13 Oct 2005 09:15:59 -0700 (PDT) (envelope-from todd.glassey@att.net) Received: from 204.127.135.58 ([204.127.135.58]) by worldnet.att.net (mtiwmhc11) with SMTP id <2005101316155311100n8tbae>; Thu, 13 Oct 2005 16:15:53 +0000 Received: from [64.127.102.91] by 204.127.135.58; Thu, 13 Oct 2005 16:15:51 +0000 From: todd.glassey@att.net To: Russ Housley Cc: ietf-pkix@imc.org, simon@josefsson.org Subject: RE: Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08) Date: Thu, 13 Oct 2005 16:15:51 +0000 Message-Id: <101320051615.20035.434E88370005122800004E432160281060970A9C9C0E0409D20B0B019B@att.net> X-Mailer: AT&T Message Center Version 1 (Feb 14 2005) X-Authenticated-Sender: dG9kZC5nbGFzc2V5QGF0dC5uZXQ= Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Yes Russ it is - there is so little difference between these WG's and their products, that its almost silly. Any use through the IETF of one groups' standards needs to be codified under the 'no repeating work or work related to another standard effort' rule that the IETF's bylaws clearly define. So - what can I say - this is yet another instance where someone wants to enable an enduser use model without bothering to actually document how that end-use model will work and under what constraints it will work - as to the separation issues between the WG's - when there were no standards, and there were no processes already in place - the IETF's shotgun approach was possibly warranted - but not anymore. And since this will likely really tee you off as a response, its my final one on the subject except to say that for some uses there are really good justifications for looking up certs through DNS services - just like there is with the e.64 phone numbers in DNS. Its just that DNS as a whole is not what it could be and well - what can I say. todd -------------- Original message ---------------------- From: Russ Housley > Todd: > > This is not a PKIX work product, so you comments are directed at the wrong > audience. > > Russ > > At 10:43 AM 10/13/2005, todd.glassey@att.net wrote: > >phb - NO ONE in their right mind would use DNS as the only repository for > >storing certificates and this initiative and the conversations in re of > >this idea are demonstrative of how little PKIX has a grip on reality IMHO. > >Clearly storing certs for DNS in DNS and possibly in some limited scope > >might work, but the reality is why bother - the issue is in the trust and > >use models - something which this group refuses to do... > > > >T. > > -------------- Original message ---------------------- > >From: "Hallam-Baker, Phillip" > > > > > > While storing certificates in the DNS makes sense in some applications I > > > would be concerned if this proposal was intended to make DNS the > > > recommended storage mechanism. > > > > > > The problem is that the original DNS protocol has a hard wired limit of > > > 512 bytes for a UDP packet after which it falls back to TCPIP. This > > > limitation has been eased in part by the DNSEXT work but the maximum UDP > > > packet size is still effectively limited by the Ethernet MTA in most > > > real world applications. If the application falls back to TCP it is much > > > simpler, cleaner and more effective to simply use HTTP which is designed > > > as a TCPIP protocol. > > > > > > In theory DNSEXT is deployed and TCPIP fallback for DNS works fine. The > > > practice is very different. The DNSEXT group has a habbit of faith based > > > deployment, i.e. if they declare the protocol deployed it is deployed. > > > > > > There are certainly cases where storing a cert in the DNS is useful but > > > it is important that the limitations of this approach be understood and > > > that it does not become another architectural fiat from the DNSEXT > > > group. > > > > > > > > > > -----Original Message----- > > > > From: owner-ietf-pkix@mail.imc.org > > > > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Tom Gindin > > > > Sent: Wednesday, October 12, 2005 6:39 PM > > > > To: Russ Housley > > > > Cc: ietf-pkix@imc.org; simon@josefsson.org > > > > Subject: Re: Storing Certificates in the DNS > > > > (draft-ietf-dnsext-rfc2538bis-08) > > > > > > > > > > > > Russ: > > > > > > > > Are there any guidelines for CRL owner names, since > > > > they're covered in the draft although DNS distribution points > > > > aren't detailed in RFC 3280? If there aren't any, IMHO a > > > > reasonable rule would be that if any sequence member of the > > > > distribution point name is a domain name (not a URI), that > > > > should be used. Also (and lower in precedence), if any > > > > sequence member of the distribution point name is an RFC 822 > > > > address, its standard translation should be used. I doubt if > > > > URI's will work without conflicts. > > > > I don't know if these count as "concerns". > > > > > > > > Tom Gindin > > > > P.S. The opinions above are mine, and not necessarily those of my > > > > employer. > > > > > > > > > > > > > > > > From owner-ietf-pkix@mail.imc.org Thu Oct 13 13:27:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ6rt-0002DO-33 for pkix-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:27:49 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00078 for ; Thu, 13 Oct 2005 13:27:44 -0400 (EDT) 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 j9DGmerv042636; Thu, 13 Oct 2005 09:48:40 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9DGmeui042618; Thu, 13 Oct 2005 09:48:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9DGmbhI042608; Thu, 13 Oct 2005 09:48:38 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <101320051443.13707.434E72990005C3C50000358B2160281060970A9C9C0E0409D20B0B 019B@att.net> References: <101320051443.13707.434E72990005C3C50000358B2160281060970A9C9C0E0409D20B0B 019B@att.net> Date: Thu, 13 Oct 2005 09:48:35 -0700 To: todd.glassey@att.net From: Paul Hoffman Subject: RE: Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08) Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 2:43 PM +0000 10/13/05, todd.glassey@att.net wrote: >phb - NO ONE in their right mind would use DNS as the only >repository for storing certificates and this initiative and the >conversations in re of this idea are demonstrative of how little >PKIX has a grip on reality IMHO. Clearly storing certs for DNS in >DNS and possibly in some limited scope might work, but the reality >is why bother - the issue is in the trust and use models - something >which this group refuses to do... Reading the subject line of this thread shows that this effort comes from the DNSEXT WG, not this one. --Paul Hoffman, Director --VPN Consortium From owner-ietf-pkix@mail.imc.org Fri Oct 14 08:49:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQOzy-0003UZ-O4 for pkix-archive@megatron.ietf.org; Fri, 14 Oct 2005 08:49:25 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07652 for ; Fri, 14 Oct 2005 08:49:16 -0400 (EDT) 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 j9EBp7bt055662; Fri, 14 Oct 2005 04:51:07 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9EBp7h9055661; Fri, 14 Oct 2005 04:51:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9EBp4L0055612 for ; Fri, 14 Oct 2005 04:51:04 -0700 (PDT) (envelope-from tgindin@us.ibm.com) 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 j9EBoswV025411 for ; Fri, 14 Oct 2005 07:50:54 -0400 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 j9EBosDn109788 for ; Fri, 14 Oct 2005 07:50:54 -0400 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 j9EBosDh019145 for ; Fri, 14 Oct 2005 07:50:54 -0400 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 j9EBosXQ019141; Fri, 14 Oct 2005 07:50:54 -0400 In-Reply-To: <6.2.1.2.2.20051013112936.05c48280@mail.binhost.com> To: Russ Housley Cc: ietf-pkix@imc.org, simon@josefsson.org MIME-Version: 1.0 Subject: Re: Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08) X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Tom Gindin Message-ID: Date: Fri, 14 Oct 2005 07:50:52 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 10/14/2005 07:50:52, Serialize complete at 10/14/2005 07:50:52 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ: In the current 2538-bis draft, section 2 contains OID's for both certificates and CRL's (although not AC's), while section 3 profiles owner names for certificates and not for CRL's. Does this really make sense, especially given that there doesn't seem to be any place where owner names for CRL's are profiled? Also, I think we all realize that most current certificates don't fit in 512 bytes, and if the size of standard RSA keys increases the certificates will grow more since every certificate contains both a subject public key and a signature whose size is no smaller than the CA's key. CRL's actually fit better (a sample one I have with a 1024-bit key has a size of about 350 bytes + 37 bytes for each entry, changing to 39 for revocation times after 2000), but they have to be distribution point CRL's and they have to be quite small. If Phill's point about MTU size is relevant, a CRL with more than about 30 entries revoked won't fit into that window - and that doesn't guarantee that 30 will. Tom Gindin Russ Housley 10/13/2005 11:30 AM To: Tom Gindin/Watson/IBM@IBMUS cc: ietf-pkix@imc.org, simon@josefsson.org Subject: Re: Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08) Tom: Thanks for the review. I do not think that this kind of guidance belongs in draft-ietf-dnsext-rfc2538bis, but it does belong in 3280bis. Russ At 06:38 PM 10/12/2005, Tom Gindin wrote: > Russ: > > Are there any guidelines for CRL owner names, since they're >covered in the draft although DNS distribution points aren't detailed in >RFC 3280? If there aren't any, IMHO a reasonable rule would be that if >any sequence member of the distribution point name is a domain name (not a >URI), that should be used. Also (and lower in precedence), if any >sequence member of the distribution point name is an RFC 822 address, its >standard translation should be used. I doubt if URI's will work without >conflicts. > I don't know if these count as "concerns". > > Tom Gindin >P.S. The opinions above are mine, and not necessarily those of my >employer. From owner-ietf-pkix@mail.imc.org Fri Oct 14 09:29:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQPcY-0008Fr-FY for pkix-archive@megatron.ietf.org; Fri, 14 Oct 2005 09:29:17 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09587 for ; Fri, 14 Oct 2005 09:29:08 -0400 (EDT) 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 j9ECYWhf067151; Fri, 14 Oct 2005 05:34:32 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9ECYW3Z067150; Fri, 14 Oct 2005 05:34:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from yxa.extundo.com (root@178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9ECYSRR067116 for ; Fri, 14 Oct 2005 05:34:31 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j9ECYO7L002878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Oct 2005 14:34:25 +0200 From: Simon Josefsson To: Tom Gindin Cc: Russ Housley , ietf-pkix@imc.org Subject: Re: Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08) References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051014:tgindin@us.ibm.com::L+MFvcadOUkL4Y6c:16zJ X-Hashcash: 1:21:051014:housley@vigilsec.com::elVOWjJv2j7GeGwH:1HnE X-Hashcash: 1:21:051014:ietf-pkix@imc.org::Sz8rYUEwAto4tW1G:J3NK Date: Fri, 14 Oct 2005 14:34:23 +0200 In-Reply-To: (Tom Gindin's message of "Fri, 14 Oct 2005 07:50:52 -0400") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=1.2 required=5.0 tests=FORGED_RCVD_HELO, SUBJ_HAS_UNIQ_ID autolearn=no version=3.0.3 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yxa-iv X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tom Gindin writes: > Russ: > > In the current 2538-bis draft, section 2 contains OID's for both > certificates and CRL's (although not AC's), while section 3 profiles owner > names for certificates and not for CRL's. Does this really make sense, > especially given that there doesn't seem to be any place where owner names > for CRL's are profiled? If CERT RR are to be used by PKIX, I believe you would need an PKIX Operational Protocols for DNS, such as: http://josefsson.org/rfc2538bis/draft-josefsson-pkix-dns-00.txt That document should mandate exact owner name rules used for particular applications, and could describe how CRLs stored in DNS would be used. I don't think that kind of detail should go into RFC 2538bis. Your concerns would be applicable to that document. > Also, I think we all realize that most current certificates don't > fit in 512 bytes, and if the size of standard RSA keys increases the > certificates will grow more since every certificate contains both a > subject public key and a signature whose size is no smaller than the CA's > key. CRL's actually fit better (a sample one I have with a 1024-bit key > has a size of about 350 bytes + 37 bytes for each entry, changing to 39 > for revocation times after 2000), but they have to be distribution point > CRL's and they have to be quite small. If Phill's point about MTU size is > relevant, a CRL with more than about 30 entries revoked won't fit into > that window - and that doesn't guarantee that 30 will. The document address this problem through the IPKIX type. Thanks, Simon > Tom Gindin > > > > > > > Russ Housley > 10/13/2005 11:30 AM > > To: Tom Gindin/Watson/IBM@IBMUS > cc: ietf-pkix@imc.org, simon@josefsson.org > Subject: Re: Storing Certificates in the DNS > (draft-ietf-dnsext-rfc2538bis-08) > > > Tom: > > Thanks for the review. I do not think that this kind of guidance belongs > in draft-ietf-dnsext-rfc2538bis, but it does belong in 3280bis. > > Russ > > > At 06:38 PM 10/12/2005, Tom Gindin wrote: > >> Russ: >> >> Are there any guidelines for CRL owner names, since they're >>covered in the draft although DNS distribution points aren't detailed in >>RFC 3280? If there aren't any, IMHO a reasonable rule would be that if >>any sequence member of the distribution point name is a domain name (not > a >>URI), that should be used. Also (and lower in precedence), if any >>sequence member of the distribution point name is an RFC 822 address, its >>standard translation should be used. I doubt if URI's will work without >>conflicts. >> I don't know if these count as "concerns". >> >> Tom Gindin >>P.S. The opinions above are mine, and not necessarily those of my >>employer. From owner-ietf-pkix@mail.imc.org Fri Oct 14 18:10:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQXkX-0003Eg-Vm for pkix-archive@megatron.ietf.org; Fri, 14 Oct 2005 18:10:02 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29708 for ; Fri, 14 Oct 2005 18:09:56 -0400 (EDT) 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 j9ELLWdE044061; Fri, 14 Oct 2005 14:21:32 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9ELLWrr044059; Fri, 14 Oct 2005 14:21:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9ELLVVJ044052 for ; Fri, 14 Oct 2005 14:21:32 -0700 (PDT) (envelope-from apache@newodin.ietf.org) Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EQWzb-0001ff-0B; Fri, 14 Oct 2005 17:21:31 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Subject: Last Call: 'Attribute Certificate Policies extension' to Proposed Standard Reply-to: iesg@ietf.org CC: Message-Id: Date: Fri, 14 Oct 2005 17:21:31 -0400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the Public-Key Infrastructure (X.509) WG to consider the following document: - 'Attribute Certificate Policies extension ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-10-28. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pkix-acpolicies-extn-06.txt From owner-ietf-pkix@mail.imc.org Sun Oct 16 16:59:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERFbZ-0004qj-J3 for pkix-archive@megatron.ietf.org; Sun, 16 Oct 2005 16:59:46 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23663 for ; Sun, 16 Oct 2005 16:59:33 -0400 (EDT) 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 j9GK8Fcl086064; Sun, 16 Oct 2005 13:08:15 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9GK8FZx086063; Sun, 16 Oct 2005 13:08:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9GK8B3O086031 for ; Sun, 16 Oct 2005 13:08:12 -0700 (PDT) (envelope-from tgindin@us.ibm.com) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j9GK8250021928 for ; Sun, 16 Oct 2005 16:08:02 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j9GK820w108072 for ; Sun, 16 Oct 2005 16:08:02 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j9GK82fF002204 for ; Sun, 16 Oct 2005 16:08:02 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j9GK82iP002199; Sun, 16 Oct 2005 16:08:02 -0400 In-Reply-To: To: Simon Josefsson Cc: Russ Housley , ietf-pkix@imc.org MIME-Version: 1.0 Subject: Re: Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08) X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Tom Gindin Message-ID: Date: Sun, 16 Oct 2005 16:08:00 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.5.4FP1 HF2|August 30, 2005) at 10/16/2005 16:08:01, Serialize complete at 10/16/2005 16:08:01 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Simon: Given the way that distribution points work, I don't understand the point of using IPKIX for CRL's with distribution points. Shouldn't the distribution point contain the URL anyway, and if so what good is the extra DNS step? I guess it might be useful for some non-distribution point CRL's (mainly those with issuer alternate names), but for distribution point CRL's it gains a little flexibility at the cost of both security and performance. I must defer to other members of the PKIX WG as to how frequently a CRL has an issuer alternate name without any distribution points, as I myself have no recollection of ever seeing such a CRL. My original reason for commenting was that 2538-bis has owner name rules for certificates, but not for CRL's, while section 2.3 lists both CRL's and certificates as permitted OID's which are apparently intended for the PKIX type. CRL rules would seem to be less application-specific than TLS or S/MIME, and thus more appropriately found in 2538-bis or 3280-bis than anywhere else. You have adopted the three application-specific guidelines from draft-josefsson-pkix-dns-00.txt in 2538-bis, even though I don't see why any SSL or TLS client would use the DNS to fetch a server certificate when it's exchanged within the protocol anyway. IMHO S/MIME certificates in the DNS are more likely to be useful. On a lower level, the binary coding in 2.3 makes little sense. Either it's 06 03 55 04 nn, or it's just 55 04 nn - in either case a leading x makes sense, but not in front of the length. Tom Gindin Simon Josefsson 10/14/2005 08:34 AM To: Tom Gindin/Watson/IBM@IBMUS cc: Russ Housley , ietf-pkix@imc.org Subject: Re: Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08) Tom Gindin writes: > Russ: > > In the current 2538-bis draft, section 2 contains OID's for both > certificates and CRL's (although not AC's), while section 3 profiles owner > names for certificates and not for CRL's. Does this really make sense, > especially given that there doesn't seem to be any place where owner names > for CRL's are profiled? If CERT RR are to be used by PKIX, I believe you would need an PKIX Operational Protocols for DNS, such as: http://josefsson.org/rfc2538bis/draft-josefsson-pkix-dns-00.txt That document should mandate exact owner name rules used for particular applications, and could describe how CRLs stored in DNS would be used. I don't think that kind of detail should go into RFC 2538bis. Your concerns would be applicable to that document. > Also, I think we all realize that most current certificates don't > fit in 512 bytes, and if the size of standard RSA keys increases the > certificates will grow more since every certificate contains both a > subject public key and a signature whose size is no smaller than the CA's > key. CRL's actually fit better (a sample one I have with a 1024-bit key > has a size of about 350 bytes + 37 bytes for each entry, changing to 39 > for revocation times after 2000), but they have to be distribution point > CRL's and they have to be quite small. If Phill's point about MTU size is > relevant, a CRL with more than about 30 entries revoked won't fit into > that window - and that doesn't guarantee that 30 will. The document address this problem through the IPKIX type. Thanks, Simon > Tom Gindin > > > > > > > Russ Housley > 10/13/2005 11:30 AM > > To: Tom Gindin/Watson/IBM@IBMUS > cc: ietf-pkix@imc.org, simon@josefsson.org > Subject: Re: Storing Certificates in the DNS > (draft-ietf-dnsext-rfc2538bis-08) > > > Tom: > > Thanks for the review. I do not think that this kind of guidance belongs > in draft-ietf-dnsext-rfc2538bis, but it does belong in 3280bis. > > Russ > > > At 06:38 PM 10/12/2005, Tom Gindin wrote: > >> Russ: >> >> Are there any guidelines for CRL owner names, since they're >>covered in the draft although DNS distribution points aren't detailed in >>RFC 3280? If there aren't any, IMHO a reasonable rule would be that if >>any sequence member of the distribution point name is a domain name (not > a >>URI), that should be used. Also (and lower in precedence), if any >>sequence member of the distribution point name is an RFC 822 address, its >>standard translation should be used. I doubt if URI's will work without >>conflicts. >> I don't know if these count as "concerns". >> >> Tom Gindin >>P.S. The opinions above are mine, and not necessarily those of my >>employer. From owner-ietf-pkix@mail.imc.org Mon Oct 17 16:09:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERbIT-0005Rx-Sz for pkix-archive@megatron.ietf.org; Mon, 17 Oct 2005 16:09:26 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08119 for ; Mon, 17 Oct 2005 16:09:18 -0400 (EDT) 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 j9HJPgoV059682; Mon, 17 Oct 2005 12:25:42 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9HJPg2w059681; Mon, 17 Oct 2005 12:25:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9HJPfoW059675 for ; Mon, 17 Oct 2005 12:25:42 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 18155 invoked by uid 0); 17 Oct 2005 19:25:35 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (84.233.132.123) by woodstock.binhost.com with SMTP; 17 Oct 2005 19:25:35 -0000 Message-Id: <6.2.1.2.2.20051017152017.04f32780@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 17 Oct 2005 15:21:31 -0400 To: ietf-pkix@imc.org From: Russ Housley Subject: draft-adams-cmpaltcert-07.txt published as RFC 4212 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I thought the PKIX WG would like to know that draft-adams-cmpaltcert-07.txt was published as RFC 4212. Russ From owner-ietf-pkix@mail.imc.org Tue Oct 18 12:58:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERums-0005Bo-1i for pkix-archive@megatron.ietf.org; Tue, 18 Oct 2005 12:58:07 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14348 for ; Tue, 18 Oct 2005 12:57:57 -0400 (EDT) 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 j9IG7V4f091273; Tue, 18 Oct 2005 09:07:31 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9IG7VwE091272; Tue, 18 Oct 2005 09:07:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9IG7UQV091261 for ; Tue, 18 Oct 2005 09:07:31 -0700 (PDT) (envelope-from kent@bbn.com) 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 j9IG7NIE022863 for ; Tue, 18 Oct 2005 12:07:24 -0400 (EDT) Mime-Version: 1.0 Message-Id: Date: Tue, 18 Oct 2005 12:07:25 -0400 To: ietf-pkix@imc.org From: Stephen Kent Subject: agenda items 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: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks, Please send Tim and me you requests for agenda slots this week. We will be using a new tool to post the agenda directly, as opposed to the old method that involved the IETF Secretariat as an intermediary. This should yield faster turnaround, and allow us to make changes incrementally. Steve From owner-ietf-pkix@mail.imc.org Thu Oct 20 09:45:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESajn-0003tQ-Ir for pkix-archive@megatron.ietf.org; Thu, 20 Oct 2005 09:45:44 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12394 for ; Thu, 20 Oct 2005 09:45:32 -0400 (EDT) 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 j9KCoBdP008066; Thu, 20 Oct 2005 05:50:11 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9KCoBUG008065; Thu, 20 Oct 2005 05:50:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from whisky.linagora.com (whisky.linagora.com [62.23.27.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KCo9nQ008057 for ; Thu, 20 Oct 2005 05:50:10 -0700 (PDT) (envelope-from yquenechdu@linagora.com) Received: from localhost (localhost [127.0.0.1]) by whisky.linagora.com (Postfix) with ESMTP id 733C21D737B for ; Thu, 20 Oct 2005 12:50:07 +0000 (UTC) Received: from whisky.linagora.com ([127.0.0.1]) by localhost (whisky [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05768-04 for ; Thu, 20 Oct 2005 14:50:00 +0200 (CEST) Received: from tomate.linagora.lan (sgi2.linagora.com [195.68.36.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by whisky.linagora.com (Postfix) with ESMTP id 43A111D7499 for ; Thu, 20 Oct 2005 14:50:00 +0200 (CEST) Received: from 192.168.1.254 (proxying for 145.242.3.30) (SquirrelMail authenticated user yquenechdu@linagora.com) by tomate.linagora.lan with HTTP; Thu, 20 Oct 2005 14:50:06 +0200 (CEST) Message-ID: <60478.192.168.1.254.1129812606.squirrel@tomate.linagora.lan> Date: Thu, 20 Oct 2005 14:50:06 +0200 (CEST) Subject: Little question about CRL From: yquenechdu@linagora.com To: ietf-pkix@imc.org User-Agent: SquirrelMail/1.4.5 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at linagora.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi, Why a LCR contains two fields identical, a field signatureAlgorithm for CertificatList and another field signature for TBSList Knowing that "This field MUST contain the same algorithm to identify ace the signature field in the sequence tbsCertList" Thank you for your answers Yannick Quenec'hdu From owner-ietf-pkix@mail.imc.org Thu Oct 20 14:43:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESfOE-0007nW-UZ for pkix-archive@megatron.ietf.org; Thu, 20 Oct 2005 14:43:49 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05966 for ; Thu, 20 Oct 2005 14:43:36 -0400 (EDT) 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 j9KHl5Zg039176; Thu, 20 Oct 2005 10:47:05 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9KHl5Cs039175; Thu, 20 Oct 2005 10:47:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9KHl2dI039168 for ; Thu, 20 Oct 2005 10:47:03 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from champagne.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j9KHl0i23433; Thu, 20 Oct 2005 19:47:00 +0200 (MEST) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/2.4); Thu, 20 Oct 2005 19:47:01 +0200 (MET DST) 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 TAA27768; Thu, 20 Oct 2005 19:46:55 +0200 (MET DST) Message-ID: <4357D80F.80105@edelweb.fr> Date: Thu, 20 Oct 2005 19:46:55 +0200 From: Peter Sylvester User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: denis.pinkas@bull.net CC: Tim Polk , hartmans-ietf@mit.edu, dengberg@corestreet.com, shitchings@corestreet.com, john.hines@tumbleweed.com, mmyers@fastq.com, david.cooper@nist.gov, housley@vigilsec.com, trevorf@microsoft.com, ambarish@malpani.biz, ietf-pkix@imc.org Subject: Re: SCVP editors' draft References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040607080909030404090701" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040607080909030404090701 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit > A point related to a topic that interests Peter. In section 3.3 the > text states: > > “Conforming SCVP server implementations MUST process the requestorRef > > value if present”. > > This is incorrect, since it is only a requirement if the SCVP server > is performing relaying. > Good question, here is one thought. It could occur that a server was erroneously presented with a reference that carries its own id. If this came from another server that relayed to it, the final response may have two authentication envelopes with identical identifiers. Or, the responder field of this response would be the same as the one that will further down encapsulate it. C -> A(1) -> B -> A(2) B receives response from A2, ancapsulates or relays it to A1, and A1 includes this in its respones to C. If I have to keep this structure for some long term, I might have problems to explain the difference between A1 and A2. I don't know whether this really presents a problem. maybe someone on the pkix list has an opinion, I'll CC it. -- 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. --------------ms040607080909030404090701 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 MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMDIwMTc0NjU1WjAjBgkqhkiG9w0B CQQxFgQUdQi0mozNdG9K+u2EBhk+GEDE7FAwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGA1HQMimZgT0Cg2zUX ZIEhYfaW1wlg3u88d4dfxepdFk6bbNAF9yqbbA4V3Ame6tGl2xOmJgQNkjM8Gg0n8BP9N0Tb 6GLzYpIBJUb0fuLeqQdhB89s9t1RM3CFu02f+lwfYW4ZS8sGqMqNI1c5+O2TTBv+vzcff5M2 n0HkJd8eSu0AAAAAAAA= --------------ms040607080909030404090701-- From owner-ietf-pkix@mail.imc.org Fri Oct 21 11:35:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESyvS-0001Xq-9g for pkix-archive@megatron.ietf.org; Fri, 21 Oct 2005 11:35:23 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10755 for ; Fri, 21 Oct 2005 11:35:10 -0400 (EDT) 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 j9LEnIoo014687; Fri, 21 Oct 2005 07:49:18 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9LEnI6D014685; Fri, 21 Oct 2005 07:49:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9LEnEis014655 for ; Fri, 21 Oct 2005 07:49:14 -0700 (PDT) (envelope-from david.cooper@nist.gov) 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 j9LEmuBT025312; Fri, 21 Oct 2005 10:48:57 -0400 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 j9LEmfG3015833; Fri, 21 Oct 2005 10:48:43 -0400 (EDT) Message-ID: <4358FFCE.4080907@nist.gov> Date: Fri, 21 Oct 2005 10:48:46 -0400 From: "David A. Cooper" 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: Peter Sylvester CC: denis.pinkas@bull.net, ietf-pkix@imc.org Subject: Re: SCVP editors' draft References: <4357D80F.80105@edelweb.fr> In-Reply-To: <4357D80F.80105@edelweb.fr> Content-Type: text/plain; charset=windows-1252; format=flowed X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA10755 For an SCVP server that does not perform relaying, the server MUST=20 process the requestorRef value if it is present in the request, but the=20 processing requirements are very simple. From section 4.7: If the SCVP client includes a requestorRef value in the request,=20 then the SCVP server MUST return the same value if the server is generating a non-cached=20 response. Section 7 imposes further requirements for the processing of the=20 requestorRef item but, as the first paragraph of section 7 explicitly=20 states, these further processing requirements only apply to servers that=20 implement relay. Dave Peter Sylvester wrote: >> A point related to a topic that interests Peter. In section 3.3 the=20 >> text states: >> >> =93Conforming SCVP server implementations MUST process the requestorRe= f >> >> value if present=94. >> >> This is incorrect, since it is only a requirement if the SCVP server=20 >> is performing relaying. >> > Good question, here is one thought. > > It could occur that a server was erroneously presented with a reference > that carries its own id. If this came from another server that relayed=20 > to it, > the final response may have two authentication envelopes with identical > identifiers. Or, the responder field of this response would be the same > as the one that will further down encapsulate it. > > C -> A(1) -> B -> A(2) > > B receives response from A2, ancapsulates or relays it to A1, and A1 > includes this in its respones to C. > > If I have to keep this structure for some long term, I might have > problems to explain the difference between A1 and A2. > > I don't know whether this really presents a problem. > > maybe someone on the pkix list has an opinion, I'll CC it. > From owner-ietf-pkix@mail.imc.org Fri Oct 21 12:38:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESzuv-0005VY-Nz for pkix-archive@megatron.ietf.org; Fri, 21 Oct 2005 12:38:53 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17645 for ; Fri, 21 Oct 2005 12:38:41 -0400 (EDT) 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 j9LFu8bL026012; Fri, 21 Oct 2005 08:56:08 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9LFu89T026011; Fri, 21 Oct 2005 08:56:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9LFu7uA026002 for ; Fri, 21 Oct 2005 08:56:07 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 13320 invoked by uid 0); 21 Oct 2005 15:56:01 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.34.88) by woodstock.binhost.com with SMTP; 21 Oct 2005 15:56:01 -0000 Message-Id: <6.2.1.2.2.20051021103341.04bd69e0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 21 Oct 2005 10:34:31 -0400 To: yquenechdu@linagora.com From: Russ Housley Subject: Re: Little question about CRL Cc: ietf-pkix@imc.org In-Reply-To: <60478.192.168.1.254.1129812606.squirrel@tomate.linagora.la n> References: <60478.192.168.1.254.1129812606.squirrel@tomate.linagora.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This same structure is used for the X.509 certificate itself. One of the values is covered by the signature, and the other is not. Russ At 08:50 AM 10/20/2005, yquenechdu@linagora.com wrote: >Hi, > >Why a LCR contains two fields identical, a field signatureAlgorithm for >CertificatList and another field signature for TBSList > >Knowing that "This field MUST contain the same algorithm to identify ace the >signature field in the sequence tbsCertList" > >Thank you for your answers >Yannick Quenec'hdu From owner-ietf-pkix@mail.imc.org Fri Oct 21 12:55:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET0BG-0008EY-Gr for pkix-archive@megatron.ietf.org; Fri, 21 Oct 2005 12:55:46 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18512 for ; Fri, 21 Oct 2005 12:55:34 -0400 (EDT) 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 j9LGKsAW030109; Fri, 21 Oct 2005 09:20:54 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9LGKsS4030108; Fri, 21 Oct 2005 09:20:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from whisky.linagora.com (whisky.linagora.com [62.23.27.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9LGKqUG030079 for ; Fri, 21 Oct 2005 09:20:52 -0700 (PDT) (envelope-from yquenechdu@linagora.com) Received: from localhost (localhost [127.0.0.1]) by whisky.linagora.com (Postfix) with ESMTP id 2CD7E1CF004; Fri, 21 Oct 2005 16:20:50 +0000 (UTC) Received: from whisky.linagora.com ([127.0.0.1]) by localhost (whisky [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19383-10; Fri, 21 Oct 2005 18:20:43 +0200 (CEST) Received: from tomate.linagora.lan (sgi2.linagora.com [195.68.36.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by whisky.linagora.com (Postfix) with ESMTP id 2A3B21DADC8; Fri, 21 Oct 2005 18:20:41 +0200 (CEST) Received: from 192.168.1.254 (proxying for 145.242.3.30) (SquirrelMail authenticated user yquenechdu@linagora.com) by tomate.linagora.lan with HTTP; Fri, 21 Oct 2005 18:20:48 +0200 (CEST) Message-ID: <32866.192.168.1.254.1129911648.squirrel@tomate.linagora.lan> In-Reply-To: <6.2.1.2.2.20051021103341.04bd69e0@mail.binhost.com> References: <60478.192.168.1.254.1129812606.squirrel@tomate.linagora.lan> <6.2.1.2.2.20051021103341.04bd69e0@mail.binhost.com> Date: Fri, 21 Oct 2005 18:20:48 +0200 (CEST) Subject: Re: Little question about CRL From: yquenechdu@linagora.com To: "Russ Housley" Cc: yquenechdu@linagora.com, ietf-pkix@imc.org User-Agent: SquirrelMail/1.4.5 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at linagora.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi, I had understood that. What I seek to understand it is the goal to have indicated the field signature in the LCR. Thanks Yannick Quenec'hdu. > This same structure is used for the X.509 certificate itself. One of the > values is covered by the signature, and the other is not. > > Russ > > At 08:50 AM 10/20/2005, yquenechdu@linagora.com wrote: > >>Hi, >> >>Why a LCR contains two fields identical, a field signatureAlgorithm for >>CertificatList and another field signature for TBSList >> >>Knowing that "This field MUST contain the same algorithm to identify ace >> the >>signature field in the sequence tbsCertList" >> >>Thank you for your answers >>Yannick Quenec'hdu > > > From owner-ietf-pkix@mail.imc.org Tue Oct 25 12:54:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUS3v-0002by-QQ for pkix-archive@megatron.ietf.org; Tue, 25 Oct 2005 12:54:11 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04777 for ; Tue, 25 Oct 2005 12:53:57 -0400 (EDT) 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 j9PFqtEi017962; Tue, 25 Oct 2005 08:52:55 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9PFqtL4017961; Tue, 25 Oct 2005 08:52:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9PFqsHw017944 for ; Tue, 25 Oct 2005 08:52:54 -0700 (PDT) (envelope-from kent@bbn.com) 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 j9PFqjIC015042 for ; Tue, 25 Oct 2005 11:52:46 -0400 (EDT) Mime-Version: 1.0 Message-Id: Date: Tue, 25 Oct 2005 11:52:47 -0400 To: ietf-pkix@imc.org From: Stephen Kent Subject: agenda 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: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks, Based on requests I have received, a preliminary PKIX WG Agenda has been posted at the IETF web site: http://www3.ietf.org/proceedings/05nov/agenda/pkix.htm Please contact me with any requested changes. Steve From owner-ietf-pkix@mail.imc.org Tue Oct 25 16:34:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUVVY-0007EV-O1 for pkix-archive@megatron.ietf.org; Tue, 25 Oct 2005 16:34:56 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01927 for ; Tue, 25 Oct 2005 16:34:40 -0400 (EDT) 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 j9PJo3QH042603; Tue, 25 Oct 2005 12:50:03 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9PJo3sK042602; Tue, 25 Oct 2005 12:50:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9PJo2o7042578 for ; Tue, 25 Oct 2005 12:50:03 -0700 (PDT) (envelope-from mlee@newodin.ietf.org) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EUUo5-0007jT-OJ; Tue, 25 Oct 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-cmc-compl-02.txt Message-Id: Date: Tue, 25 Oct 2005 15:50:01 -0400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : CMC Complience Document Author(s) : M. Myers, J. Schaad Filename : draft-ietf-pkix-cmc-compl-02.txt Pages : 16 Date : 2005-10-25 This document provides a set of compliance statements about the CMC (Certificate Management over CMS) enrollment protocol. The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents. This document provides the information needed to make a compliant version of CMC A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmc-compl-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-cmc-compl-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-cmc-compl-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-25131726.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-cmc-compl-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-cmc-compl-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-25131726.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix@mail.imc.org Tue Oct 25 16:36:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUVX3-0008Kl-Vx for pkix-archive@megatron.ietf.org; Tue, 25 Oct 2005 16:36:30 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02725 for ; Tue, 25 Oct 2005 16:36:14 -0400 (EDT) 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 j9PJo2gD042594; Tue, 25 Oct 2005 12:50:02 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9PJo2OW042592; Tue, 25 Oct 2005 12:50:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9PJo1lN042576 for ; Tue, 25 Oct 2005 12:50:02 -0700 (PDT) (envelope-from mlee@newodin.ietf.org) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EUUo5-0007iV-DQ; Tue, 25 Oct 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-scvp-21.txt Message-Id: Date: Tue, 25 Oct 2005 15:50:01 -0400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Standard Certificate Validation Protocol (SCVP) Author(s) : A. Malpani, et al. Filename : draft-ietf-pkix-scvp-21.txt Pages : 78 Date : 2005-10-25 SCVP allows a client to delegate certificate path construction and certificate path validation to a server. The path construction or validation (e.g. making sure that none of the certificates in the path are revoked) is performed according to a validation policy, which contains one or more trust anchors. It allows simplification of client implementations and use of a set of predefined validation policies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-21.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-scvp-21.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-scvp-21.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-25110437.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-scvp-21.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-scvp-21.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-25110437.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix@mail.imc.org Tue Oct 25 16:36:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUVXN-00005I-Eg for pkix-archive@megatron.ietf.org; Tue, 25 Oct 2005 16:36:49 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02775 for ; Tue, 25 Oct 2005 16:36:33 -0400 (EDT) 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 j9PJo2qG042593; Tue, 25 Oct 2005 12:50:02 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9PJo2jg042588; Tue, 25 Oct 2005 12:50:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9PJo1qU042577 for ; Tue, 25 Oct 2005 12:50:02 -0700 (PDT) (envelope-from mlee@newodin.ietf.org) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EUUo5-0007jJ-MU; Tue, 25 Oct 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-2797-bis-03.txt Message-Id: Date: Tue, 25 Oct 2005 15:50:01 -0400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Certificate Management Messages over CMS Author(s) : M. Myers, J. Schaad Filename : draft-ietf-pkix-2797-bis-03.txt Pages : 75 Date : 2005-10-25 This document defines the base syntax for CMC, a Certificate Management protocol using CMS (Cryptographic Message Syntax). This protocol addresses two immediate needs within the Internet PKI community: 1. The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key Crytpography Standard), and 2. The need in S/MIME (Secure MIME) for a certificate enrollment protocol for DSA-signed certificates with Diffie-Hellman public keys. CMC also requires the use of the transport document and the requirements usage document along with this document for a full definition. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-2797-bis-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-2797-bis-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-2797-bis-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-25131158.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-2797-bis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-2797-bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-25131158.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix@mail.imc.org Tue Oct 25 17:43:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUWa0-0000Hk-Sy for pkix-archive@megatron.ietf.org; Tue, 25 Oct 2005 17:43:36 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16526 for ; Tue, 25 Oct 2005 17:43:19 -0400 (EDT) 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 j9PL42Eg049221; Tue, 25 Oct 2005 14:04:02 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9PL42Vj049220; Tue, 25 Oct 2005 14:04:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9PL416O049214 for ; Tue, 25 Oct 2005 14:04:01 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 4002 invoked by uid 0); 25 Oct 2005 21:03:52 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.34.180) by woodstock.binhost.com with SMTP; 25 Oct 2005 21:03:52 -0000 Message-Id: <7.0.0.10.2.20051025164030.061cdfb0@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta) Date: Tue, 25 Oct 2005 17:03:55 -0400 To: ietf-pkix@imc.org From: Russ Housley Subject: Public key validation and Proof of possession Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id RAA16526 Dear PKIX WG: The draft NIST SP 800-56 defines the requirements for "Recipient=20 Assurance of Static Public Key Validity." See Section 5.6.2.2, where it = says: The recipient of a static public key shall obtain assurance of its va= lidity in one or more of the following ways: 1. Recipient Full Validation - The recipient performs a successful= full public key validation (see Sections 5.6.2.4 and 5.6.2.5). 2. TTP Full Validation =96 The recipient receives assurance that a= trusted third party (trusted by the recipient) has performed a=20 successful full public key validation (see Sections 5.6.2.4 and 5.6.2.5). 3. TTP Generation =96 The recipient receives assurance that a=20 trusted third party (trusted by the recipient) has ge nerated the=20 public/private key pair in accordance with Section 5.6.1 and has provided the=20 key pair to the owner. It seems to me that option 2 was include to allow a CA to perform the=20 public key validation once, and then any party that makes use of the=20 certificate need not do it again. From a system performance=20 perspective, this seems highly desirable. In some highly assured implementation environments, it seems=20 desirable for there to me an indication in the certificate that this=20 action was taken by the CA. One could determine which certification=20 policies require the CA to take this action, but that means that the=20 list of certification policies would be continually adjusted by an=20 administrator. I would prefer a non-critical extension that declared=20 that this action was taken by the CA. The draft NIST SP 800-56, Section 5.6.3.2 discusses the requirement=20 for "Recipient Assurance of the Owner's Possession of a Static=20 Private Key." That is, the topic we have been discussing for years=20 on this list, calling it proof of possession. RFC 3647 includes a=20 place in the certification policy to discuss this topic. (RFC 3647,=20 Section 3.2.1: Method to prove possession of private key.) Again, in some highly assured implementation environments, it seems=20 desirable for there to me an indication in the certificate that proof=20 of possession was performed by the CA. I think it could be part of=20 the same non-critical extension proposed above. I therefore propose that the PKIX WG generate a standards-track RFC=20 to define a certificate extension to provide these indications. I=20 propose a very simple syntax: id-pe-caChecks OBJECT IDENTIFIER ::=3D { id-pe } CAChecks ::=3D BIT STRING { publicKeyValadation (0), proofOfPossession (1) } Do others think this is a useful extension? Russ From owner-ietf-pkix@mail.imc.org Wed Oct 26 09:18:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUlAK-0000q7-1w for pkix-archive@megatron.ietf.org; Wed, 26 Oct 2005 09:18:04 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18931 for ; Wed, 26 Oct 2005 09:17:48 -0400 (EDT) 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 j9QCVJw8045494; Wed, 26 Oct 2005 05:31:19 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QCVJ5R045492; Wed, 26 Oct 2005 05:31:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9QCVIcp045425 for ; Wed, 26 Oct 2005 05:31:18 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Oct 2005 13:31:12 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Public key validation and Proof of possession Date: Wed, 26 Oct 2005 13:30:14 +0100 Message-ID: Thread-Topic: Public key validation and Proof of possession Thread-Index: AcXZra4Ui3+0TMi3SmWvP9uCPeoMFQAePPSA From: "Stefan Santesson" To: "Russ Housley" , X-OriginalArrivalTime: 26 Oct 2005 12:31:12.0564 (UTC) FILETIME=[26937740:01C5DA29] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j9QCVIcp045487 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Russ, I'm not sure whether this is useful or not. I have some questions though. On public key validation (arithmetic properties): It seems to me that the key validation tests specified in 5.6.2.4 and 5.6.2.5 are rather trivial to do locally ( 2= -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Russ Housley > Sent: den 25 oktober 2005 23:04 > To: ietf-pkix@imc.org > Subject: Public key validation and Proof of possession > > > Dear PKIX WG: > > The draft NIST SP 800-56 defines the requirements for "Recipient > Assurance of Static Public Key Validity." See Section 5.6.2.2, where it > says: > > The recipient of a static public key shall obtain assurance of its > validity > in one or more of the following ways: > > 1. Recipient Full Validation - The recipient performs a successful > full > public key validation (see Sections 5.6.2.4 and 5.6.2.5). > > 2. TTP Full Validation - The recipient receives assurance that a > trusted > third party (trusted by the recipient) has performed a > successful full > public key validation (see Sections 5.6.2.4 and 5.6.2.5). > > 3. TTP Generation - The recipient receives assurance that a > trusted third > party (trusted by the recipient) has ge nerated the > public/private key > pair in accordance with Section 5.6.1 and has provided the > key pair to > the owner. > > It seems to me that option 2 was include to allow a CA to perform the > public key validation once, and then any party that makes use of the > certificate need not do it again. From a system performance > perspective, this seems highly desirable. > > In some highly assured implementation environments, it seems > desirable for there to me an indication in the certificate that this > action was taken by the CA. One could determine which certification > policies require the CA to take this action, but that means that the > list of certification policies would be continually adjusted by an > administrator. I would prefer a non-critical extension that declared > that this action was taken by the CA. > > The draft NIST SP 800-56, Section 5.6.3.2 discusses the requirement > for "Recipient Assurance of the Owner's Possession of a Static > Private Key." That is, the topic we have been discussing for years > on this list, calling it proof of possession. RFC 3647 includes a > place in the certification policy to discuss this topic. (RFC 3647, > Section 3.2.1: Method to prove possession of private key.) > > Again, in some highly assured implementation environments, it seems > desirable for there to me an indication in the certificate that proof > of possession was performed by the CA. I think it could be part of > the same non-critical extension proposed above. > > I therefore propose that the PKIX WG generate a standards-track RFC > to define a certificate extension to provide these indications. I > propose a very simple syntax: > > id-pe-caChecks OBJECT IDENTIFIER ::= { id-pe } > > CAChecks ::= BIT STRING { > publicKeyValadation (0), > proofOfPossession (1) } > > Do others think this is a useful extension? > > Russ From owner-ietf-pkix@mail.imc.org Wed Oct 26 10:04:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUltN-0007PL-0e for pkix-archive@megatron.ietf.org; Wed, 26 Oct 2005 10:04:37 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21503 for ; Wed, 26 Oct 2005 10:04:21 -0400 (EDT) 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 j9QDBThS048668; Wed, 26 Oct 2005 06:11:29 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QDBTK1048667; Wed, 26 Oct 2005 06:11:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9QDBQJX048650 for ; Wed, 26 Oct 2005 06:11:28 -0700 (PDT) (envelope-from denis.pinkas@bull.net) 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 PAA36000; Wed, 26 Oct 2005 15:28:35 +0200 Importance: Normal X-Priority: 3 (Normal) Subject: RE: Public key validation and Proof of possession MIME-Version: 1.0 From: denis.pinkas@bull.net To: "Stefan Santesson" Cc: "Russ Housley" , Date: Wed, 26 Oct 2005 15:11:54 +0200 Message-ID: X-MIMETrack: Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 26/10/2005 15:11:55 MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: base64 PEZPTlQgZmFjZT0iRGVmYXVsdCBTYW5zIFNlcmlmLCBWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNh LCBzYW5zLXNlcmlmIiBzaXplPTI+PFA+UnVzcyBhbmQgU3RlZmFuLDwvUD48UD5UaGlzIGlzIGFu IGludGVycmVzdGluZyBpc3N1ZS4gVGhhbmtzIGZvciByYWlzaW5nIGl0LjwvUD48UD4odGV4dCBk ZWxldGVkKTxCUj48QlI+U28gc2luY2UgUE9QIGFsd2F5cyBNVVNUIGJlIHBlcmZvcm1lZCBieSB0 aGUgQ0EgdGhlcmUgc2VlbXMgbm90IHRvIGJlPEJSPnRoZSBuZWVkIGZvciBkaXZlcnNlIHBvbGlj aWVzIChQT1AgYW5kIG5vbiBQT1ApLjxCUj48L1A+PFA+T25jZSB1cG9uIGEgdGltZSwgaW4gdGhl IGVhcmx5IHllYXJzIG9mIFBLSSwgUkZDIDI0NTkgc3RhdGVkIHRoYXQgc2VudGVuY2UgdGhhdCB3 YXMgYmxpbmRseSBjb3BpZWQgZnJvbSBkb2N1bWVudCB0byBkb2N1bWVudC48L1A+PFA+SW4gdGhl c2UgZWFybHkgeWVhcnMsIG1vc3QgKGlmIG5vdCBhbGwpIHNlY3VyaXR5IHByb3RvY29scyB3ZXJl IGJhZGx5IGRlc2lnbmVkIGFuZCB0aHVzIGZvciB0aGVtIHRvIHJlbWFpbnMgc2VjdXJlPEJSPnRo ZSBvbmx5IHdheSB3YXMgdG8gaW5jbHVkZSB0aGUgTVVTVCBjb25kaXRpb24uPC9QPjxQPkhvd2V2 ZXIgc2luY2UgdGhlbiwgdGhlIGVhcnRoIGhhcyByb3RhdGVkIGFuZCBhdCBsZWFzdCB0aGVyZSBu b3cgZXhpc3RzIG9uZSZuYnNwO2Nhc2Ugd2hlcmUgUE9QIGlzIG5vIG1vcmUgbmVlZGVkIHdpdGhv dXQgYW55IHNlY3VyaXR5IHRocmVhdC48L1A+PFA+VGhpcyBjYXNlIHdhcyBpbnRyb2R1Y2VkIGJ5 IFMvTUlNRSB3aXRoIHRoZSBvcHRpb25hbGx5IHNpZ25lZCBhdHRyaWJ1dGUgRVNTQ2VydElELiA8 L1A+PFA+SXQgd2FzIHRoZW4gdGFrZW4gYnkgRVRTSSB3aXRoIHRoZSBtYW5kYXRvcnkgRVNTQ2V0 cnRJRCAob3IgaWlzIGVxdWl2YWxlbnQgdGhhdCBkb2VzIG5vdCBtYW5kYXRlIHRoZSB1c2Ugb2Yg U0hBLTEpLjwvUD48UD5SRkMgMzEyNiBzcGVjaWZpZXMgdGhhdCBmb3JtYXQuPC9QPjxQPlRha2lu ZyBpbnRvIGNvbnNpZGVyYXRpb24gdGhlc2UgZmFjdHMsIHRoaXMgbWVhbnMgdGhhdCB0aGVyZSBl eGlzdHMgYXQgbGVhc3Qgb25lIGNhc2Ugd2hlcmUgUE9QIGRvZXMgbm90IG5lZWQgdG8gYmUgcGVy Zm9ybWVkIGFueW1vcmUuIDwvUD48UD5UaGVyZSBzdGlsbCBleGlzdHMgY2FzZXMgd2hlcmUgaXQg bmVlZHMgdG8gYmUgcGVyZm9ybWVkLCBpbiBwYXJ0aWN1bGFyIHdoZW4gdGhlIGNlcnRpZmljYXRl IGlzIHVzZWQgZm9yIGVuY3J5cHRpb24gcHVycG9zZXMuPC9QPjxQPkkmbmJzcDtiZWxpZXZlIHRo YXQgUE9QIGlzIG1hbmRhdG9yeSB3aGVuIHRoZSBrZXkgaXMgdXNlZCBmb3IgZW5jcnlwdGlvbiBw dXJwb3Nlcy48L1A+PFA+SSBiZWxpZXZlIHRoYXQgUE9QIGlzIE5PVCBSRVFVSVJFRCB3aGVuIHRo ZSBrZXkgaXMgdXNlZCBmb3Igbm9uIHJlcHVkaWF0aW9uIHB1cnBvc2VzIChlLmcuIFJGQyAzMTI2 IGlzIHVzZWQpLjwvUD48UD5XaGVuIHRoZSBrZXkgaXMgdXNlZCBmb3IgYXV0aGVudGljYXRpb24g cHVycG9zZXMsIHRoZW4gZGVwZW5kaW5nIHVwb24gdGhlIGNoYXJhY3RlcmlzdGljcyBvZiB0aGUg cHJvdG9jb2wsPEJSPml0IE1BWSBiZSByZXF1aXJlZCBvciBub3QuIFNvIGluIHRoYXQgY2FzZSBv bmx5LCBpdCB3b3VsZCBtYWtlIHNlbnNlIHRvIHN1cHBvcnQgdGhlIGV4dGVuc2lvbiBwcm9wb3Nl ZCBieSBSdXNzLjwvUD48UD5EZW5pczwvUD48UD49PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvUD48UD5E byB5b3UgYWdyZWUgd2l0aCB0aGVzZSBvYnNlcnZhdGlvbnMgb3IgaGF2ZSBJIG1pc3NlZCBzb21l dGhpbmc/PEJSPjxCUj48QlI+U3RlZmFuIFNhbnRlc3NvbjxCUj5Qcm9ncmFtIE1hbmFnZXIsIFN0 YW5kYXJkcyBMaWFpc29uPEJSPldpbmRvd3MgU2VjdXJpdHk8QlI+IDxCUj48QlI+Jmd0OyAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj4mZ3Q7IEZyb206IG93bmVyLWlldGYtcGtpeEBtYWls LmltYy5vcmc8QlI+W21haWx0bzpvd25lci1pZXRmLXBraXhAbWFpbC5pbWMub3JnXTxCUj4mZ3Q7 IE9uIEJlaGFsZiBPZiBSdXNzIEhvdXNsZXk8QlI+Jmd0OyBTZW50OiBkZW4gMjUgb2t0b2JlciAy MDA1IDIzOjA0PEJSPiZndDsgVG86IGlldGYtcGtpeEBpbWMub3JnPEJSPiZndDsgU3ViamVjdDog UHVibGljIGtleSB2YWxpZGF0aW9uIGFuZCBQcm9vZiBvZiBwb3NzZXNzaW9uPEJSPiZndDsgPEJS PiZndDsgPEJSPiZndDsgRGVhciBQS0lYIFdHOjxCUj4mZ3Q7IDxCUj4mZ3Q7IFRoZSBkcmFmdCBO SVNUIFNQIDgwMC01NiBkZWZpbmVzIHRoZSByZXF1aXJlbWVudHMgZm9yICJSZWNpcGllbnQ8QlI+ Jmd0OyBBc3N1cmFuY2Ugb2YgU3RhdGljIFB1YmxpYyBLZXkgVmFsaWRpdHkuIiAgU2VlIFNlY3Rp b24gNS42LjIuMiwgd2hlcmU8QlI+aXQ8QlI+Jmd0OyBzYXlzOjxCUj4mZ3Q7IDxCUj4mZ3Q7ICAg ICBUaGUgcmVjaXBpZW50IG9mIGEgc3RhdGljIHB1YmxpYyBrZXkgc2hhbGwgb2J0YWluIGFzc3Vy YW5jZSBvZiBpdHM8QlI+Jmd0OyB2YWxpZGl0eTxCUj4mZ3Q7ICAgICBpbiBvbmUgb3IgbW9yZSBv ZiB0aGUgZm9sbG93aW5nIHdheXM6PEJSPiZndDsgPEJSPiZndDsgICAgICAgIDEuIFJlY2lwaWVu dCBGdWxsIFZhbGlkYXRpb24gLSBUaGUgcmVjaXBpZW50IHBlcmZvcm1zIGE8QlI+c3VjY2Vzc2Z1 bDxCUj4mZ3Q7IGZ1bGw8QlI+Jmd0OyAgICAgICAgICAgcHVibGljIGtleSB2YWxpZGF0aW9uIChz ZWUgU2VjdGlvbnMgNS42LjIuNCBhbmQgNS42LjIuNSkuPEJSPiZndDsgPEJSPiZndDsgICAgICAg IDIuIFRUUCBGdWxsIFZhbGlkYXRpb24gLSBUaGUgcmVjaXBpZW50IHJlY2VpdmVzIGFzc3VyYW5j ZSB0aGF0PEJSPmE8QlI+Jmd0OyB0cnVzdGVkPEJSPiZndDsgICAgICAgICAgIHRoaXJkIHBhcnR5 ICh0cnVzdGVkIGJ5IHRoZSByZWNpcGllbnQpIGhhcyBwZXJmb3JtZWQgYTxCUj4mZ3Q7IHN1Y2Nl c3NmdWwgZnVsbDxCUj4mZ3Q7ICAgICAgICAgICBwdWJsaWMga2V5IHZhbGlkYXRpb24gKHNlZSBT ZWN0aW9ucyA1LjYuMi40IGFuZCA1LjYuMi41KS48QlI+Jmd0OyA8QlI+Jmd0OyAgICAgICAgMy4g VFRQIEdlbmVyYXRpb24gLSBUaGUgcmVjaXBpZW50IHJlY2VpdmVzIGFzc3VyYW5jZSB0aGF0IGE8 QlI+Jmd0OyB0cnVzdGVkIHRoaXJkPEJSPiZndDsgICAgICAgICAgIHBhcnR5ICh0cnVzdGVkIGJ5 IHRoZSByZWNpcGllbnQpIGhhcyBnZSBuZXJhdGVkIHRoZTxCUj4mZ3Q7IHB1YmxpYy9wcml2YXRl IGtleTxCUj4mZ3Q7ICAgICAgICAgICBwYWlyIGluIGFjY29yZGFuY2Ugd2l0aCBTZWN0aW9uIDUu Ni4xIGFuZCBoYXMgcHJvdmlkZWQgdGhlPEJSPiZndDsga2V5IHBhaXIgdG88QlI+Jmd0OyAgICAg ICAgICAgdGhlIG93bmVyLjxCUj4mZ3Q7IDxCUj4mZ3Q7IEl0IHNlZW1zIHRvIG1lIHRoYXQgb3B0 aW9uIDIgd2FzIGluY2x1ZGUgdG8gYWxsb3cgYSBDQSB0byBwZXJmb3JtIHRoZTxCUj4mZ3Q7IHB1 YmxpYyBrZXkgdmFsaWRhdGlvbiBvbmNlLCBhbmQgdGhlbiBhbnkgcGFydHkgdGhhdCBtYWtlcyB1 c2Ugb2YgdGhlPEJSPiZndDsgY2VydGlmaWNhdGUgbmVlZCBub3QgZG8gaXQgYWdhaW4uICBGcm9t IGEgc3lzdGVtIHBlcmZvcm1hbmNlPEJSPiZndDsgcGVyc3BlY3RpdmUsIHRoaXMgc2VlbXMgaGln aGx5IGRlc2lyYWJsZS48QlI+Jmd0OyA8QlI+Jmd0OyBJbiBzb21lIGhpZ2hseSBhc3N1cmVkIGlt cGxlbWVudGF0aW9uIGVudmlyb25tZW50cywgaXQgc2VlbXM8QlI+Jmd0OyBkZXNpcmFibGUgZm9y IHRoZXJlIHRvIG1lIGFuIGluZGljYXRpb24gaW4gdGhlIGNlcnRpZmljYXRlIHRoYXQgdGhpczxC Uj4mZ3Q7IGFjdGlvbiB3YXMgdGFrZW4gYnkgdGhlIENBLiAgT25lIGNvdWxkIGRldGVybWluZSB3 aGljaCBjZXJ0aWZpY2F0aW9uPEJSPiZndDsgcG9saWNpZXMgcmVxdWlyZSB0aGUgQ0EgdG8gdGFr ZSB0aGlzIGFjdGlvbiwgYnV0IHRoYXQgbWVhbnMgdGhhdCB0aGU8QlI+Jmd0OyBsaXN0IG9mIGNl cnRpZmljYXRpb24gcG9saWNpZXMgd291bGQgYmUgY29udGludWFsbHkgYWRqdXN0ZWQgYnkgYW48 QlI+Jmd0OyBhZG1pbmlzdHJhdG9yLiAgSSB3b3VsZCBwcmVmZXIgYSBub24tY3JpdGljYWwgZXh0 ZW5zaW9uIHRoYXQgZGVjbGFyZWQ8QlI+Jmd0OyB0aGF0IHRoaXMgYWN0aW9uIHdhcyB0YWtlbiBi eSB0aGUgQ0EuPEJSPiZndDsgPEJSPiZndDsgVGhlIGRyYWZ0IE5JU1QgU1AgODAwLTU2LCBTZWN0 aW9uIDUuNi4zLjIgZGlzY3Vzc2VzIHRoZSByZXF1aXJlbWVudDxCUj4mZ3Q7IGZvciAiUmVjaXBp ZW50IEFzc3VyYW5jZSBvZiB0aGUgT3duZXIncyBQb3NzZXNzaW9uIG9mIGEgU3RhdGljPEJSPiZn dDsgUHJpdmF0ZSBLZXkuIiAgVGhhdCBpcywgdGhlIHRvcGljIHdlIGhhdmUgYmVlbiBkaXNjdXNz aW5nIGZvciB5ZWFyczxCUj4mZ3Q7IG9uIHRoaXMgbGlzdCwgY2FsbGluZyBpdCBwcm9vZiBvZiBw b3NzZXNzaW9uLiAgUkZDIDM2NDcgaW5jbHVkZXMgYTxCUj4mZ3Q7IHBsYWNlIGluIHRoZSBjZXJ0 aWZpY2F0aW9uIHBvbGljeSB0byBkaXNjdXNzIHRoaXMgdG9waWMuICAoUkZDIDM2NDcsPEJSPiZn dDsgU2VjdGlvbiAzLjIuMTogTWV0aG9kIHRvIHByb3ZlIHBvc3Nlc3Npb24gb2YgcHJpdmF0ZSBr ZXkuKTxCUj4mZ3Q7IDxCUj4mZ3Q7IEFnYWluLCBpbiBzb21lIGhpZ2hseSBhc3N1cmVkIGltcGxl bWVudGF0aW9uIGVudmlyb25tZW50cywgaXQgc2VlbXM8QlI+Jmd0OyBkZXNpcmFibGUgZm9yIHRo ZXJlIHRvIG1lIGFuIGluZGljYXRpb24gaW4gdGhlIGNlcnRpZmljYXRlIHRoYXQgcHJvb2Y8QlI+ Jmd0OyBvZiBwb3NzZXNzaW9uIHdhcyBwZXJmb3JtZWQgYnkgdGhlIENBLiAgSSB0aGluayBpdCBj b3VsZCBiZSBwYXJ0IG9mPEJSPiZndDsgdGhlIHNhbWUgbm9uLWNyaXRpY2FsIGV4dGVuc2lvbiBw cm9wb3NlZCBhYm92ZS48QlI+Jmd0OyA8QlI+Jmd0OyBJIHRoZXJlZm9yZSBwcm9wb3NlIHRoYXQg dGhlIFBLSVggV0cgZ2VuZXJhdGUgYSBzdGFuZGFyZHMtdHJhY2sgUkZDPEJSPiZndDsgdG8gZGVm aW5lIGEgY2VydGlmaWNhdGUgZXh0ZW5zaW9uIHRvIHByb3ZpZGUgdGhlc2UgaW5kaWNhdGlvbnMu ICBJPEJSPiZndDsgcHJvcG9zZSBhIHZlcnkgc2ltcGxlIHN5bnRheDo8QlI+Jmd0OyA8QlI+Jmd0 OyAgICAgaWQtcGUtY2FDaGVja3MgT0JKRUNUIElERU5USUZJRVIgOjo9ICB7IGlkLXBlICZsdDtU QkQmZ3Q7IH08QlI+Jmd0OyA8QlI+Jmd0OyAgICAgQ0FDaGVja3MgOjo9IEJJVCBTVFJJTkcgezxC Uj4mZ3Q7ICAgICAgICBwdWJsaWNLZXlWYWxhZGF0aW9uICAgICAoMCksPEJSPiZndDsgICAgICAg IHByb29mT2ZQb3NzZXNzaW9uICAgICAgICgxKSB9PEJSPiZndDsgPEJSPiZndDsgRG8gb3RoZXJz IHRoaW5rIHRoaXMgaXMgYSB1c2VmdWwgZXh0ZW5zaW9uPzxCUj4mZ3Q7IDxCUj4mZ3Q7IFJ1c3M8 QlI+PEJSPjxCUj48L1A+PC9GT05UPg== From owner-ietf-pkix@mail.imc.org Wed Oct 26 10:22:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUmAM-0001z0-Eq for pkix-archive@megatron.ietf.org; Wed, 26 Oct 2005 10:22:10 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22848 for ; Wed, 26 Oct 2005 10:21:54 -0400 (EDT) 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 j9QDfRI2051853; Wed, 26 Oct 2005 06:41:27 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QDfRXG051852; Wed, 26 Oct 2005 06:41:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9QDfQ1G051835 for ; Wed, 26 Oct 2005 06:41:26 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 18148 invoked by uid 0); 26 Oct 2005 13:41:23 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.171.123) by woodstock.binhost.com with SMTP; 26 Oct 2005 13:41:23 -0000 Message-Id: <7.0.0.10.2.20051026094029.0623d9f8@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta) Date: Wed, 26 Oct 2005 09:40:58 -0400 To: denis.pinkas@bull.net, "Stefan Santesson" From: Russ Housley Subject: RE: Public key validation and Proof of possession Cc: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis: Are you speaking in support of the extension that I proposed? Russ At 09:11 AM 10/26/2005, denis.pinkas@bull.net wrote: >Russ and Stefan, > >This is an interresting issue. Thanks for raising it. > >(text deleted) > >So since POP always MUST be performed by the CA there seems not to be >the need for diverse policies (POP and non POP). > >Once upon a time, in the early years of PKI, RFC 2459 stated that >sentence that was blindly copied from document to document. > >In these early years, most (if not all) security protocols were >badly designed and thus for them to remains secure >the only way was to include the MUST condition. > >However since then, the earth has rotated and at least there now >exists one case where POP is no more needed without any security threat. > >This case was introduced by S/MIME with the optionally signed >attribute ESSCertID. > >It was then taken by ETSI with the mandatory ESSCetrtID (or iis >equivalent that does not mandate the use of SHA-1). > >RFC 3126 specifies that format. > >Taking into consideration these facts, this means that there exists >at least one case where POP does not need to be performed anymore. > >There still exists cases where it needs to be performed, in >particular when the certificate is used for encryption purposes. > >I believe that POP is mandatory when the key is used for encryption purposes. > >I believe that POP is NOT REQUIRED when the key is used for non >repudiation purposes (e.g. RFC 3126 is used). > >When the key is used for authentication purposes, then depending >upon the characteristics of the protocol, >it MAY be required or not. So in that case only, it would make sense >to support the extension proposed by Russ. > >Denis > >============================================================================= > >Do you agree with these observations or have I missed something? > > >Stefan Santesson >Program Manager, Standards Liaison >Windows Security > > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org >[mailto:owner-ietf-pkix@mail.imc.org] > > On Behalf Of Russ Housley > > Sent: den 25 oktober 2005 23:04 > > To: ietf-pkix@imc.org > > Subject: Public key validation and Proof of possession > > > > > > Dear PKIX WG: > > > > The draft NIST SP 800-56 defines the requirements for "Recipient > > Assurance of Static Public Key Validity." See Section 5.6.2.2, where >it > > says: > > > > The recipient of a static public key shall obtain assurance of its > > validity > > in one or more of the following ways: > > > > 1. Recipient Full Validation - The recipient performs a >successful > > full > > public key validation (see Sections 5.6.2.4 and 5.6.2.5). > > > > 2. TTP Full Validation - The recipient receives assurance that >a > > trusted > > third party (trusted by the recipient) has performed a > > successful full > > public key validation (see Sections 5.6.2.4 and 5.6.2.5). > > > > 3. TTP Generation - The recipient receives assurance that a > > trusted third > > party (trusted by the recipient) has ge nerated the > > public/private key > > pair in accordance with Section 5.6.1 and has provided the > > key pair to > > the owner. > > > > It seems to me that option 2 was include to allow a CA to perform the > > public key validation once, and then any party that makes use of the > > certificate need not do it again. From a system performance > > perspective, this seems highly desirable. > > > > In some highly assured implementation environments, it seems > > desirable for there to me an indication in the certificate that this > > action was taken by the CA. One could determine which certification > > policies require the CA to take this action, but that means that the > > list of certification policies would be continually adjusted by an > > administrator. I would prefer a non-critical extension that declared > > that this action was taken by the CA. > > > > The draft NIST SP 800-56, Section 5.6.3.2 discusses the requirement > > for "Recipient Assurance of the Owner's Possession of a Static > > Private Key." That is, the topic we have been discussing for years > > on this list, calling it proof of possession. RFC 3647 includes a > > place in the certification policy to discuss this topic. (RFC 3647, > > Section 3.2.1: Method to prove possession of private key.) > > > > Again, in some highly assured implementation environments, it seems > > desirable for there to me an indication in the certificate that proof > > of possession was performed by the CA. I think it could be part of > > the same non-critical extension proposed above. > > > > I therefore propose that the PKIX WG generate a standards-track RFC > > to define a certificate extension to provide these indications. I > > propose a very simple syntax: > > > > id-pe-caChecks OBJECT IDENTIFIER ::= { id-pe } > > > > CAChecks ::= BIT STRING { > > publicKeyValadation (0), > > proofOfPossession (1) } > > > > Do others think this is a useful extension? > > > > Russ > From owner-ietf-pkix@mail.imc.org Wed Oct 26 10:29:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUmHg-0000Du-Bp for pkix-archive@megatron.ietf.org; Wed, 26 Oct 2005 10:29:44 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23394 for ; Wed, 26 Oct 2005 10:29:28 -0400 (EDT) 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 j9QDfQAd051843; Wed, 26 Oct 2005 06:41:26 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QDfQxH051842; Wed, 26 Oct 2005 06:41:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9QDfQgR051832 for ; Wed, 26 Oct 2005 06:41:26 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 18145 invoked by uid 0); 26 Oct 2005 13:41:22 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.171.123) by woodstock.binhost.com with SMTP; 26 Oct 2005 13:41:22 -0000 Message-Id: <7.0.0.10.2.20051026093506.0622e838@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta) Date: Wed, 26 Oct 2005 09:39:08 -0400 To: "Stefan Santesson" , From: Russ Housley Subject: RE: Public key validation and Proof of possession In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stefan: >On public key validation (arithmetic properties): >It seems to me that the key validation tests specified in 5.6.2.4 and >5.6.2.5 are rather trivial to do locally ( 2=for FFC), at least compared to the cost of using this key for anything >useful. I wonder if the cost of making this test isn't actually lower >than parsing the certificate to obtain the assurance from the CA. In low power devices (such as smartcards), avoiding the y^q exponentiation because the relying party is sure that the CA has already performed this check seems useful. >On Proof-of-possession: >Section 5.6.3. of SP 800-56 states: >"For example, this Recommendation requires that parties obtain assurance >that they actually possess their own static private keys, and a binding >authority is required to obtain assurance of an owner's possession of >the appropriate static private key before binding an identifier to the >owner's static public key." > >So since POP always MUST be performed by the CA there seems not to be >the need for diverse policies (POP and non POP). > >Do you agree with these observations or have I missed something? If the first idea is accepted, the proposed extension is no larger by adding the additional bit to indicate that the CA performed POP. The positive statement could be useful. Russ From owner-ietf-pkix@mail.imc.org Wed Oct 26 11:14:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUmyk-0002gA-CQ for pkix-archive@megatron.ietf.org; Wed, 26 Oct 2005 11:14:16 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00164 for ; Wed, 26 Oct 2005 11:13:58 -0400 (EDT) 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 j9QESrlC058257; Wed, 26 Oct 2005 07:28:53 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QESrx6058256; Wed, 26 Oct 2005 07:28:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9QESqP8058234 for ; Wed, 26 Oct 2005 07:28:52 -0700 (PDT) (envelope-from denis.pinkas@bull.net) 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 QAA60612; Wed, 26 Oct 2005 16:45:58 +0200 Importance: Normal X-Priority: 3 (Normal) Subject: RE: Public key validation and Proof of possession MIME-Version: 1.0 From: denis.pinkas@bull.net To: Russ Housley Cc: "Stefan Santesson" , Date: Wed, 26 Oct 2005 16:29:17 +0200 Message-ID: X-MIMETrack: Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 26/10/2005 16:29:18 MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: base64 PEZPTlQgZmFjZT0iRGVmYXVsdCBTYW5zIFNlcmlmLCBWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNh LCBzYW5zLXNlcmlmIiBzaXplPTI+PFA+PEJSPkRlbmlzOjxCUj48QlI+QXJlIHlvdSBzcGVha2lu ZyBpbiBzdXBwb3J0IG9mIHRoZSBleHRlbnNpb24gdGhhdCBJIHByb3Bvc2VkPzxCUj48QlI+UnVz czwvUD48UD49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PC9QPjxQPlRoZSBhbnN3ZXIgaXMgeWVzIGZvciBwcm9vZk9mUG9zc2Vzc2lvbiAoMSkuIFNp bmNlIEkgaGF2ZSBub3QgeWV0IHJlYWQgdGhlIE5JU1QgZHJhZnQsPEJSPkkgaGF2ZSBubyBvcGlu aW9uIGF0IHRoaXMgdGltZSBvbiBwdWJsaWNLZXlWYWxpZGF0aW9uICgwKS48L1A+PFA+RGVuaXM8 L1A+PFA+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PTwvUD48UD5BdCAwOToxMSBBTSAxMC8yNi8yMDA1LCBkZW5pcy5waW5rYXNAYnVsbC5uZXQgd3Jv dGU6PEJSPjxCUj4mZ3Q7UnVzcyBhbmQgU3RlZmFuLDxCUj4mZ3Q7PEJSPiZndDtUaGlzIGlzIGFu IGludGVycmVzdGluZyBpc3N1ZS4gVGhhbmtzIGZvciByYWlzaW5nIGl0LjxCUj4mZ3Q7PEJSPiZn dDsodGV4dCBkZWxldGVkKTxCUj4mZ3Q7PEJSPiZndDtTbyBzaW5jZSBQT1AgYWx3YXlzIE1VU1Qg YmUgcGVyZm9ybWVkIGJ5IHRoZSBDQSB0aGVyZSBzZWVtcyBub3QgdG8gYmU8QlI+Jmd0O3RoZSBu ZWVkIGZvciBkaXZlcnNlIHBvbGljaWVzIChQT1AgYW5kIG5vbiBQT1ApLjxCUj4mZ3Q7PEJSPiZn dDtPbmNlIHVwb24gYSB0aW1lLCBpbiB0aGUgZWFybHkgeWVhcnMgb2YgUEtJLCBSRkMgMjQ1OSBz dGF0ZWQgdGhhdCA8QlI+Jmd0O3NlbnRlbmNlIHRoYXQgd2FzIGJsaW5kbHkgY29waWVkIGZyb20g ZG9jdW1lbnQgdG8gZG9jdW1lbnQuPEJSPiZndDs8QlI+Jmd0O0luIHRoZXNlIGVhcmx5IHllYXJz LCBtb3N0IChpZiBub3QgYWxsKSBzZWN1cml0eSBwcm90b2NvbHMgd2VyZSA8QlI+Jmd0O2JhZGx5 IGRlc2lnbmVkIGFuZCB0aHVzIGZvciB0aGVtIHRvIHJlbWFpbnMgc2VjdXJlPEJSPiZndDt0aGUg b25seSB3YXkgd2FzIHRvIGluY2x1ZGUgdGhlIE1VU1QgY29uZGl0aW9uLjxCUj4mZ3Q7PEJSPiZn dDtIb3dldmVyIHNpbmNlIHRoZW4sIHRoZSBlYXJ0aCBoYXMgcm90YXRlZCBhbmQgYXQgbGVhc3Qg dGhlcmUgbm93IDxCUj4mZ3Q7ZXhpc3RzIG9uZSBjYXNlIHdoZXJlIFBPUCBpcyBubyBtb3JlIG5l ZWRlZCB3aXRob3V0IGFueSBzZWN1cml0eSB0aHJlYXQuPEJSPiZndDs8QlI+Jmd0O1RoaXMgY2Fz ZSB3YXMgaW50cm9kdWNlZCBieSBTL01JTUUgd2l0aCB0aGUgb3B0aW9uYWxseSBzaWduZWQgPEJS PiZndDthdHRyaWJ1dGUgRVNTQ2VydElELjxCUj4mZ3Q7PEJSPiZndDtJdCB3YXMgdGhlbiB0YWtl biBieSBFVFNJIHdpdGggdGhlIG1hbmRhdG9yeSBFU1NDZXRydElEIChvciBpaXMgPEJSPiZndDtl cXVpdmFsZW50IHRoYXQgZG9lcyBub3QgbWFuZGF0ZSB0aGUgdXNlIG9mIFNIQS0xKS48QlI+Jmd0 OzxCUj4mZ3Q7UkZDIDMxMjYgc3BlY2lmaWVzIHRoYXQgZm9ybWF0LjxCUj4mZ3Q7PEJSPiZndDtU YWtpbmcgaW50byBjb25zaWRlcmF0aW9uIHRoZXNlIGZhY3RzLCB0aGlzIG1lYW5zIHRoYXQgdGhl cmUgZXhpc3RzIDxCUj4mZ3Q7YXQgbGVhc3Qgb25lIGNhc2Ugd2hlcmUgUE9QIGRvZXMgbm90IG5l ZWQgdG8gYmUgcGVyZm9ybWVkIGFueW1vcmUuPEJSPiZndDs8QlI+Jmd0O1RoZXJlIHN0aWxsIGV4 aXN0cyBjYXNlcyB3aGVyZSBpdCBuZWVkcyB0byBiZSBwZXJmb3JtZWQsIGluIDxCUj4mZ3Q7cGFy dGljdWxhciB3aGVuIHRoZSBjZXJ0aWZpY2F0ZSBpcyB1c2VkIGZvciBlbmNyeXB0aW9uIHB1cnBv c2VzLjxCUj4mZ3Q7PEJSPiZndDtJIGJlbGlldmUgdGhhdCBQT1AgaXMgbWFuZGF0b3J5IHdoZW4g dGhlIGtleSBpcyB1c2VkIGZvciBlbmNyeXB0aW9uIHB1cnBvc2VzLjxCUj4mZ3Q7PEJSPiZndDtJ IGJlbGlldmUgdGhhdCBQT1AgaXMgTk9UIFJFUVVJUkVEIHdoZW4gdGhlIGtleSBpcyB1c2VkIGZv ciBub24gPEJSPiZndDtyZXB1ZGlhdGlvbiBwdXJwb3NlcyAoZS5nLiBSRkMgMzEyNiBpcyB1c2Vk KS48QlI+Jmd0OzxCUj4mZ3Q7V2hlbiB0aGUga2V5IGlzIHVzZWQgZm9yIGF1dGhlbnRpY2F0aW9u IHB1cnBvc2VzLCB0aGVuIGRlcGVuZGluZyA8QlI+Jmd0O3Vwb24gdGhlIGNoYXJhY3RlcmlzdGlj cyBvZiB0aGUgcHJvdG9jb2wsPEJSPiZndDtpdCBNQVkgYmUgcmVxdWlyZWQgb3Igbm90LiBTbyBp biB0aGF0IGNhc2Ugb25seSwgaXQgd291bGQgbWFrZSBzZW5zZSA8QlI+Jmd0O3RvIHN1cHBvcnQg dGhlIGV4dGVuc2lvbiBwcm9wb3NlZCBieSBSdXNzLjxCUj4mZ3Q7PEJSPiZndDtEZW5pczxCUj4m Z3Q7PEJSPiZndDs9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxCUj4mZ3Q7PEJSPiZndDtEbyB5b3UgYWdy ZWUgd2l0aCB0aGVzZSBvYnNlcnZhdGlvbnMgb3IgaGF2ZSBJIG1pc3NlZCBzb21ldGhpbmc/PEJS PiZndDs8QlI+Jmd0OzxCUj4mZ3Q7U3RlZmFuIFNhbnRlc3NvbjxCUj4mZ3Q7UHJvZ3JhbSBNYW5h Z2VyLCBTdGFuZGFyZHMgTGlhaXNvbjxCUj4mZ3Q7V2luZG93cyBTZWN1cml0eTxCUj4mZ3Q7PEJS PiZndDs8QlI+Jmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPEJSPiZndDsgJmd0 OyBGcm9tOiBvd25lci1pZXRmLXBraXhAbWFpbC5pbWMub3JnPEJSPiZndDtbbWFpbHRvOm93bmVy LWlldGYtcGtpeEBtYWlsLmltYy5vcmddPEJSPiZndDsgJmd0OyBPbiBCZWhhbGYgT2YgUnVzcyBI b3VzbGV5PEJSPiZndDsgJmd0OyBTZW50OiBkZW4gMjUgb2t0b2JlciAyMDA1IDIzOjA0PEJSPiZn dDsgJmd0OyBUbzogaWV0Zi1wa2l4QGltYy5vcmc8QlI+Jmd0OyAmZ3Q7IFN1YmplY3Q6IFB1Ymxp YyBrZXkgdmFsaWRhdGlvbiBhbmQgUHJvb2Ygb2YgcG9zc2Vzc2lvbjxCUj4mZ3Q7ICZndDs8QlI+ Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyBEZWFyIFBLSVggV0c6PEJSPiZndDsgJmd0OzxCUj4mZ3Q7 ICZndDsgVGhlIGRyYWZ0IE5JU1QgU1AgODAwLTU2IGRlZmluZXMgdGhlIHJlcXVpcmVtZW50cyBm b3IgIlJlY2lwaWVudDxCUj4mZ3Q7ICZndDsgQXNzdXJhbmNlIG9mIFN0YXRpYyBQdWJsaWMgS2V5 IFZhbGlkaXR5LiIgU2VlIFNlY3Rpb24gNS42LjIuMiwgd2hlcmU8QlI+Jmd0O2l0PEJSPiZndDsg Jmd0OyBzYXlzOjxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IFRoZSByZWNpcGllbnQgb2YgYSBz dGF0aWMgcHVibGljIGtleSBzaGFsbCBvYnRhaW4gYXNzdXJhbmNlIG9mIGl0czxCUj4mZ3Q7ICZn dDsgdmFsaWRpdHk8QlI+Jmd0OyAmZ3Q7IGluIG9uZSBvciBtb3JlIG9mIHRoZSBmb2xsb3dpbmcg d2F5czo8QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAxLiBSZWNpcGllbnQgRnVsbCBWYWxpZGF0 aW9uIC0gVGhlIHJlY2lwaWVudCBwZXJmb3JtcyBhPEJSPiZndDtzdWNjZXNzZnVsPEJSPiZndDsg Jmd0OyBmdWxsPEJSPiZndDsgJmd0OyBwdWJsaWMga2V5IHZhbGlkYXRpb24gKHNlZSBTZWN0aW9u cyA1LjYuMi40IGFuZCA1LjYuMi41KS48QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAyLiBUVFAg RnVsbCBWYWxpZGF0aW9uIC0gVGhlIHJlY2lwaWVudCByZWNlaXZlcyBhc3N1cmFuY2UgdGhhdDxC Uj4mZ3Q7YTxCUj4mZ3Q7ICZndDsgdHJ1c3RlZDxCUj4mZ3Q7ICZndDsgdGhpcmQgcGFydHkgKHRy dXN0ZWQgYnkgdGhlIHJlY2lwaWVudCkgaGFzIHBlcmZvcm1lZCBhPEJSPiZndDsgJmd0OyBzdWNj ZXNzZnVsIGZ1bGw8QlI+Jmd0OyAmZ3Q7IHB1YmxpYyBrZXkgdmFsaWRhdGlvbiAoc2VlIFNlY3Rp b25zIDUuNi4yLjQgYW5kIDUuNi4yLjUpLjxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IDMuIFRU UCBHZW5lcmF0aW9uIC0gVGhlIHJlY2lwaWVudCByZWNlaXZlcyBhc3N1cmFuY2UgdGhhdCBhPEJS PiZndDsgJmd0OyB0cnVzdGVkIHRoaXJkPEJSPiZndDsgJmd0OyBwYXJ0eSAodHJ1c3RlZCBieSB0 aGUgcmVjaXBpZW50KSBoYXMgZ2UgbmVyYXRlZCB0aGU8QlI+Jmd0OyAmZ3Q7IHB1YmxpYy9wcml2 YXRlIGtleTxCUj4mZ3Q7ICZndDsgcGFpciBpbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA1LjYu MSBhbmQgaGFzIHByb3ZpZGVkIHRoZTxCUj4mZ3Q7ICZndDsga2V5IHBhaXIgdG88QlI+Jmd0OyAm Z3Q7IHRoZSBvd25lci48QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyBJdCBzZWVtcyB0byBtZSB0 aGF0IG9wdGlvbiAyIHdhcyBpbmNsdWRlIHRvIGFsbG93IGEgQ0EgdG8gcGVyZm9ybSB0aGU8QlI+ Jmd0OyAmZ3Q7IHB1YmxpYyBrZXkgdmFsaWRhdGlvbiBvbmNlLCBhbmQgdGhlbiBhbnkgcGFydHkg dGhhdCBtYWtlcyB1c2Ugb2YgdGhlPEJSPiZndDsgJmd0OyBjZXJ0aWZpY2F0ZSBuZWVkIG5vdCBk byBpdCBhZ2Fpbi4gRnJvbSBhIHN5c3RlbSBwZXJmb3JtYW5jZTxCUj4mZ3Q7ICZndDsgcGVyc3Bl Y3RpdmUsIHRoaXMgc2VlbXMgaGlnaGx5IGRlc2lyYWJsZS48QlI+Jmd0OyAmZ3Q7PEJSPiZndDsg Jmd0OyBJbiBzb21lIGhpZ2hseSBhc3N1cmVkIGltcGxlbWVudGF0aW9uIGVudmlyb25tZW50cywg aXQgc2VlbXM8QlI+Jmd0OyAmZ3Q7IGRlc2lyYWJsZSBmb3IgdGhlcmUgdG8gbWUgYW4gaW5kaWNh dGlvbiBpbiB0aGUgY2VydGlmaWNhdGUgdGhhdCB0aGlzPEJSPiZndDsgJmd0OyBhY3Rpb24gd2Fz IHRha2VuIGJ5IHRoZSBDQS4gT25lIGNvdWxkIGRldGVybWluZSB3aGljaCBjZXJ0aWZpY2F0aW9u PEJSPiZndDsgJmd0OyBwb2xpY2llcyByZXF1aXJlIHRoZSBDQSB0byB0YWtlIHRoaXMgYWN0aW9u LCBidXQgdGhhdCBtZWFucyB0aGF0IHRoZTxCUj4mZ3Q7ICZndDsgbGlzdCBvZiBjZXJ0aWZpY2F0 aW9uIHBvbGljaWVzIHdvdWxkIGJlIGNvbnRpbnVhbGx5IGFkanVzdGVkIGJ5IGFuPEJSPiZndDsg Jmd0OyBhZG1pbmlzdHJhdG9yLiBJIHdvdWxkIHByZWZlciBhIG5vbi1jcml0aWNhbCBleHRlbnNp b24gdGhhdCBkZWNsYXJlZDxCUj4mZ3Q7ICZndDsgdGhhdCB0aGlzIGFjdGlvbiB3YXMgdGFrZW4g YnkgdGhlIENBLjxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IFRoZSBkcmFmdCBOSVNUIFNQIDgw MC01NiwgU2VjdGlvbiA1LjYuMy4yIGRpc2N1c3NlcyB0aGUgcmVxdWlyZW1lbnQ8QlI+Jmd0OyAm Z3Q7IGZvciAiUmVjaXBpZW50IEFzc3VyYW5jZSBvZiB0aGUgT3duZXIncyBQb3NzZXNzaW9uIG9m IGEgU3RhdGljPEJSPiZndDsgJmd0OyBQcml2YXRlIEtleS4iIFRoYXQgaXMsIHRoZSB0b3BpYyB3 ZSBoYXZlIGJlZW4gZGlzY3Vzc2luZyBmb3IgeWVhcnM8QlI+Jmd0OyAmZ3Q7IG9uIHRoaXMgbGlz dCwgY2FsbGluZyBpdCBwcm9vZiBvZiBwb3NzZXNzaW9uLiBSRkMgMzY0NyBpbmNsdWRlcyBhPEJS PiZndDsgJmd0OyBwbGFjZSBpbiB0aGUgY2VydGlmaWNhdGlvbiBwb2xpY3kgdG8gZGlzY3VzcyB0 aGlzIHRvcGljLiAoUkZDIDM2NDcsPEJSPiZndDsgJmd0OyBTZWN0aW9uIDMuMi4xOiBNZXRob2Qg dG8gcHJvdmUgcG9zc2Vzc2lvbiBvZiBwcml2YXRlIGtleS4pPEJSPiZndDsgJmd0OzxCUj4mZ3Q7 ICZndDsgQWdhaW4sIGluIHNvbWUgaGlnaGx5IGFzc3VyZWQgaW1wbGVtZW50YXRpb24gZW52aXJv bm1lbnRzLCBpdCBzZWVtczxCUj4mZ3Q7ICZndDsgZGVzaXJhYmxlIGZvciB0aGVyZSB0byBtZSBh biBpbmRpY2F0aW9uIGluIHRoZSBjZXJ0aWZpY2F0ZSB0aGF0IHByb29mPEJSPiZndDsgJmd0OyBv ZiBwb3NzZXNzaW9uIHdhcyBwZXJmb3JtZWQgYnkgdGhlIENBLiBJIHRoaW5rIGl0IGNvdWxkIGJl IHBhcnQgb2Y8QlI+Jmd0OyAmZ3Q7IHRoZSBzYW1lIG5vbi1jcml0aWNhbCBleHRlbnNpb24gcHJv cG9zZWQgYWJvdmUuPEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgSSB0aGVyZWZvcmUgcHJvcG9z ZSB0aGF0IHRoZSBQS0lYIFdHIGdlbmVyYXRlIGEgc3RhbmRhcmRzLXRyYWNrIFJGQzxCUj4mZ3Q7 ICZndDsgdG8gZGVmaW5lIGEgY2VydGlmaWNhdGUgZXh0ZW5zaW9uIHRvIHByb3ZpZGUgdGhlc2Ug aW5kaWNhdGlvbnMuIEk8QlI+Jmd0OyAmZ3Q7IHByb3Bvc2UgYSB2ZXJ5IHNpbXBsZSBzeW50YXg6 PEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgaWQtcGUtY2FDaGVja3MgT0JKRUNUIElERU5USUZJ RVIgOjo9IHsgaWQtcGUgJmx0O1RCRCZndDsgfTxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IENB Q2hlY2tzIDo6PSAgICBCSVQgU1RSSU5HIHs8QlI+Jmd0OyAmZ3Q7IHB1YmxpY0tleVZhbGFkYXRp b24gKDApLDxCUj4mZ3Q7ICZndDsgcHJvb2ZPZlBvc3Nlc3Npb24gKDEpIH08QlI+Jmd0OyAmZ3Q7 PEJSPiZndDsgJmd0OyBEbyBvdGhlcnMgdGhpbmsgdGhpcyBpcyBhIHVzZWZ1bCBleHRlbnNpb24/ PEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgUnVzczxCUj4mZ3Q7PEJSPjxCUj48L1A+PC9GT05U Pg== From owner-ietf-pkix@mail.imc.org Wed Oct 26 11:26:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUnB0-0002DC-Az for pkix-archive@megatron.ietf.org; Wed, 26 Oct 2005 11:26:55 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01144 for ; Wed, 26 Oct 2005 11:26:37 -0400 (EDT) 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 j9QEjRBE059963; Wed, 26 Oct 2005 07:45:27 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QEjRUk059962; Wed, 26 Oct 2005 07:45:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9QEjPNG059952 for ; Wed, 26 Oct 2005 07:45:25 -0700 (PDT) (envelope-from denis.pinkas@bull.net) 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 RAA41408; Wed, 26 Oct 2005 17:02:29 +0200 Importance: Normal X-Priority: 3 (Normal) Subject: RE: Public key validation and Proof of possession MIME-Version: 1.0 From: denis.pinkas@bull.net To: "Bob Bell \(rtbell\)" Cc: "Stefan Santesson" , "Russ Housley" , Date: Wed, 26 Oct 2005 16:45:47 +0200 Message-ID: X-MIMETrack: Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 26/10/2005 16:45:49 MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: base64 PEZPTlQgZmFjZT0iRGVmYXVsdCBTYW5zIFNlcmlmLCBWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNh LCBzYW5zLXNlcmlmIiBzaXplPTI+PERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9 NDA1MjQzNjEzLTI2MTAyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+ RGVuaXMgLSA8L0ZPTlQ+PC9TUEFOPjwvRElWPjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFO IGNsYXNzPTQwNTI0MzYxMy0yNjEwMjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYg c2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+PERJViBkaXI9bHRyIGFsaWduPWxlZnQ+ PFNQQU4gY2xhc3M9NDA1MjQzNjEzLTI2MTAyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAw MDBmZiBzaXplPTI+SSBoYXZlIGEgcXVlc3Rpb24uIEl0IHdvdWxkIHNlZW0gdG8gbWUgdGhhdCBm b3Igbm9uLXJlcHVkaWF0aW9uIGFzIHdpdGggdGhlIG90aGVyIG1vZGVzIGZvciB0aGUgY2VydCwg d2l0aG91dCB0aGUgUE9QIHN0ZXAsIHRoZXJlIGlzIG5vIHdheSB0byBwcm92ZSB0aGF0IEkgYXMg dGhlIHByZXNlbnRlciBvZiB0aGUgQ2VydCBhbSB0cnVseSBlbnRpdGxlZCB0byBjbGFpbSB0aGF0 IGNlcnQgYXMgbWluZS4gU2luY2UgYSBjZXJ0IGlzIHB1YmxpYyBpbmZvcm1hdGlvbiwgYXZhaWxh YmxlIGZyb20gbXVsdGlwbGUgc291cmNlcyBwcmVzdW1hYmx5LCB0aGVuIGFueW9uZSBtYXkgYWNx dWlyZSB0aGUgY2VydC4gSXQgaXMgb25seSBieSBiZWluZyBhYmxlIHRvIHByb3ZlIHRoYXQgSSBo YXZlIHRoZSBwcml2YXRlIGtleSB0aHJvdWdoIFBPUCBhbSBJIGFibGUgdG8gYXNzZXJ0IHRoYXQg dGhlIGNlcnQgaXMgaW4gZmFjdCBNWSBpZGVudGl0eS48L0ZPTlQ+PC9TUEFOPjwvRElWPjxESVYg ZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTQwNTI0MzYxMy0yNjEwMjAwNT48Rk9OVCBm YWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+ PERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NDA1MjQzNjEzLTI2MTAyMDA1PjxG T05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+QW0gSSBtaXNzaW5nIHNvbWV0aGlu ZyBoZXJlPzwvRk9OVD48L1NQQU4+PC9ESVY+PERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4g Y2xhc3M9NDA1MjQzNjEzLTI2MTAyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZj48 L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNs YXNzPTQwNTI0MzYxMy0yNjEwMjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmY+PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L0ZPTlQ+PC9TUEFO PjwvRElWPjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTQwNTI0MzYxMy0yNjEw MjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmY+PC9GT05UPjwvU1BBTj4mbmJzcDs8 L0RJVj48RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz00MDUyNDM2MTMtMjYxMDIw MDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMDAwPk1heSZuYnNwO0kgc2F5LCB5ZXMgPyA6 LSk8L0ZPTlQ+PC9TUEFOPjwvRElWPjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNz PTQwNTI0MzYxMy0yNjEwMjAwNT48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD48L1NQQU4+Jm5ic3A7 PC9ESVY+PERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NDA1MjQzNjEzLTI2MTAy MDA1PjxGT05UIGZhY2U9QXJpYWw+QW4gZW50aXR5IE1VU1Qgc3RpbGwgZGVtb25zdHJhdGUgd2hv IGl0IGlzLCBpbiBvcmRlciB0byBnZXQmbmJzcDt0aGUgYXBwcm9wcmlhdGUgbmFtZSBpbiB0aGUg Y2VydGlmaWNhdGUgKHN1YmplY3QgZmllbGQpLjwvRk9OVD48L1NQQU4+PC9ESVY+PERJViBkaXI9 bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NDA1MjQzNjEzLTI2MTAyMDA1PjxGT05UIGZhY2U9 QXJpYWw+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj48RElWIGRpcj1sdHIgYWxpZ249bGVmdD48 U1BBTiBjbGFzcz00MDUyNDM2MTMtMjYxMDIwMDU+PEZPTlQgZmFjZT1BcmlhbD5JbiB0aGUgY2Fz ZSBvZiBub24gcmVwdWRpYXRpb24sIGlmJm5ic3A7YW4gZW50aXR5Jm5ic3A7cHJlc2VudHMgYSBw dWJsaWMga2V5IHRoYXQgaXMgbm90IGl0cywgdGhlbiBoZSBlbnRpdHkmbmJzcDtkb2VzIG5vdCBr bm93IHRoZSBjb3JyZXNwb25kaW5nIHByaXZhdGUga2V5LCA8L0ZPTlQ+PC9TUEFOPjwvRElWPjxE SVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTQwNTI0MzYxMy0yNjEwMjAwNT48Rk9O VCBmYWNlPUFyaWFsPmFuZCBoZW5jZSZuYnNwO2lzJm5ic3A7dW5hYmxlIHRvIHVzZSB0aGUgY2Vy dGlmaWNhdGUuIFNpbmNlIHVzaW5nIFJGQyAzMTI2LCB0aGUgaGFzaCBvZiB0aGUgY2VydGlmaWNh dGUgKG9yIHRlaCBjZXJ0aWZpY2F0ZSkgTVVTVCBiZSBwcm90ZWN0ZWQgPC9GT05UPjwvU1BBTj48 L0RJVj48RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz00MDUyNDM2MTMtMjYxMDIw MDU+PEZPTlQgZmFjZT1BcmlhbD5ieSB0aGUgZGlnaXRhbCBzaWduYXR1cmUsIHN1YnN0aXR1dGlv biBvZiBhIGNlcnRpZmljYXRlIGJ5IGFub3RoZXIgdGhhdCB3b3VsZCBjb250YWluIHRoZSBzYW1l IHB1YmxpYyBrZXkgd291bGQgYmUgaW1tZWRpYXRlbHkgZGV0ZWN0ZWQuPC9GT05UPjwvU1BBTj48 L0RJVj48RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz00MDUyNDM2MTMtMjYxMDIw MDU+PEZPTlQgZmFjZT1BcmlhbD48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPjxESVYgZGlyPWx0 ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTQwNTI0MzYxMy0yNjEwMjAwNT48Rk9OVCBmYWNlPUFy aWFsPiJPbGQiIHByb3RvY29scyB3ZXJlIG5vIHVzaW5nIGNlcnRpZmljYXRlcy4gVGhlbiBjZXJ0 aWZpY2F0ZXMgd2VyZSZuYnNwO2FkZGVkLCBidXQmbmJzcDtleHRlcm5hbCB0byB0aGUgc2VjdXJp dHkgcHJvdG9jb2wgKCJ1bnByb3RlY3RlZCIpLjwvRk9OVD48L1NQQU4+PC9ESVY+PERJViBkaXI9 bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NDA1MjQzNjEzLTI2MTAyMDA1PjxGT05UIGZhY2U9 QXJpYWw+VGhlIHJpZ2h0IHRoaW5nIGlzIHRvIHByb3RlY3QgdGhlIGNlcnRpZmljYXRlIGJ5IHRo ZSBkaWdpdGFsIHNpZ25hdHVyZSwgYXMgUkZDIDMxMjYgaXMgZG9pbmcuIE5vdGUgdGhhdCB0aGlz IGFsbG93cyB0byBjZXJ0aWZ5IHRoZSBzYW1lIHB1YmxpYyBrZXkgPC9GT05UPjwvU1BBTj48L0RJ Vj48RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz00MDUyNDM2MTMtMjYxMDIwMDU+ PEZPTlQgZmFjZT1BcmlhbD53aXRoIGRpZmZlcmVudCBhdHRyaWJ1dGVzIGZyb20gZGlmZmVyZW50 IENBcy48L0ZPTlQ+PC9TUEFOPjwvRElWPjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNs YXNzPTQwNTI0MzYxMy0yNjEwMjAwNT48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD48L1NQQU4+Jm5i c3A7PC9ESVY+PERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NDA1MjQzNjEzLTI2 MTAyMDA1PjxGT05UIGZhY2U9QXJpYWw+U28gUE9QIGFsb25lLCBpcyB1bmFibGUgdG8gc29sdmUg dGhlIHN1c2JzdGl0dXRpb24gb2Ygb25lIGNlcnRpZmljYXRlIGZyb20gYSB1c2VyIGJ5IGFub3Ro ZXIgbGVnaXRpbWF0ZSZuYnNwO2NlcnRpZmljYXRlIGZyb20gdGhlIHNhbWUgdXNlciA8L0ZPTlQ+ PC9TUEFOPjwvRElWPjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTQwNTI0MzYx My0yNjEwMjAwNT48Rk9OVCBmYWNlPUFyaWFsPndpdGggdGhlIHNhbWUgcHVibGljIGtleSBpbiBp dCwgPC9GT05UPjwvU1BBTj48U1BBTiBjbGFzcz00MDUyNDM2MTMtMjYxMDIwMDU+PEZPTlQgZmFj ZT1BcmlhbD5idXQgd2l0aCBhIGRpZmZlcmVudCBuYW1lIGluIGl0LCBvciBkaWZmZXJlbnQgYXR0 cmlidXRlcyBpbiBpdC48L0ZPTlQ+PC9TUEFOPjwvRElWPjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0 PjxTUEFOIGNsYXNzPTQwNTI0MzYxMy0yNjEwMjAwNT48L1NQQU4+PFNQQU4gY2xhc3M9NDA1MjQz NjEzLTI2MTAyMDA1PjwvU1BBTj48U1BBTiBjbGFzcz00MDUyNDM2MTMtMjYxMDIwMDU+PC9TUEFO PjxTUEFOIGNsYXNzPTQwNTI0MzYxMy0yNjEwMjAwNT48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD48 L1NQQU4+Jm5ic3A7PC9ESVY+PERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NDA1 MjQzNjEzLTI2MTAyMDA1PjxGT05UIGZhY2U9QXJpYWw+RGVuaXM8L0ZPTlQ+PC9TUEFOPjwvRElW PjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTQwNTI0MzYxMy0yNjEwMjAwNT48 L1NQQU4+PFNQQU4gY2xhc3M9NDA1MjQzNjEzLTI2MTAyMDA1PjwvU1BBTj48U1BBTiBjbGFzcz00 MDUyNDM2MTMtMjYxMDIwMDU+PC9TUEFOPjxTUEFOIGNsYXNzPTQwNTI0MzYxMy0yNjEwMjAwNT48 L1NQQU4+PFNQQU4gY2xhc3M9NDA1MjQzNjEzLTI2MTAyMDA1PjwvU1BBTj48U1BBTiBjbGFzcz00 MDUyNDM2MTMtMjYxMDIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmPjwvRk9OVD48 L1NQQU4+Jm5ic3A7PC9ESVY+PERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NDA1 MjQzNjEzLTI2MTAyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PC9G T05UPjwvU1BBTj4mbmJzcDs8L0RJVj48RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFz cz00MDUyNDM2MTMtMjYxMDIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9 Mj5Cb2IgQmVsbDwvRk9OVD48L1NQQU4+PC9ESVY+PEJSPjxCTE9DS1FVT1RFIGRpcj1sdHIgPiAg PERJViBjbGFzcz1PdXRsb29rTWVzc2FnZUhlYWRlciBsYW5nPWVuLXVzIGRpcj1sdHIgYWxpZ249 bGVmdD4gIDxIUiB0YWJJbmRleD0tMT4gIDxGT05UIGZhY2U9VGFob21hIHNpemU9Mj48Qj5Gcm9t OjwvQj4gb3duZXItaWV0Zi1wa2l4QG1haWwuaW1jLm9yZyAgIFttYWlsdG86b3duZXItaWV0Zi1w a2l4QG1haWwuaW1jLm9yZ10gPEI+T24gQmVoYWxmIE9mICAgPC9CPmRlbmlzLnBpbmthc0BidWxs Lm5ldDxCUj48Qj5TZW50OjwvQj4gV2VkbmVzZGF5LCBPY3RvYmVyIDI2LCAyMDA1ICAgMDc6MTI8 QlI+PEI+VG86PC9CPiBTdGVmYW4gU2FudGVzc29uPEJSPjxCPkNjOjwvQj4gUnVzcyBIb3VzbGV5 OyAgIGlldGYtcGtpeEBpbWMub3JnPEJSPjxCPlN1YmplY3Q6PC9CPiBSRTogUHVibGljIGtleSB2 YWxpZGF0aW9uIGFuZCBQcm9vZiBvZiAgIHBvc3Nlc3Npb248QlI+PC9GT05UPjxCUj48L0RJVj4g IDxESVY+PC9ESVY+PEZPTlQgICAgICAgICAgICBmYWNlPSJEZWZhdWx0IFNhbnMgU2VyaWYsIFZl cmRhbmEsIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiIHNpemU9MiAgPiAgPFA+UnVzcyBh bmQgU3RlZmFuLDwvUD4gIDxQPlRoaXMgaXMgYW4gaW50ZXJyZXN0aW5nIGlzc3VlLiBUaGFua3Mg Zm9yIHJhaXNpbmcgaXQuPC9QPiAgPFA+KHRleHQgZGVsZXRlZCk8QlI+PEJSPlNvIHNpbmNlIFBP UCBhbHdheXMgTVVTVCBiZSBwZXJmb3JtZWQgYnkgdGhlIENBIHRoZXJlICAgc2VlbXMgbm90IHRv IGJlPEJSPnRoZSBuZWVkIGZvciBkaXZlcnNlIHBvbGljaWVzIChQT1AgYW5kIG5vbiBQT1ApLjxC Uj48L1A+ICA8UD5PbmNlIHVwb24gYSB0aW1lLCBpbiB0aGUgZWFybHkgeWVhcnMgb2YgUEtJLCBS RkMgMjQ1OSBzdGF0ZWQgdGhhdCBzZW50ZW5jZSAgIHRoYXQgd2FzIGJsaW5kbHkgY29waWVkIGZy b20gZG9jdW1lbnQgdG8gZG9jdW1lbnQuPC9QPiAgPFA+SW4gdGhlc2UgZWFybHkgeWVhcnMsIG1v c3QgKGlmIG5vdCBhbGwpIHNlY3VyaXR5IHByb3RvY29scyB3ZXJlIGJhZGx5ICAgZGVzaWduZWQg YW5kIHRodXMgZm9yIHRoZW0gdG8gcmVtYWlucyBzZWN1cmU8QlI+dGhlIG9ubHkgd2F5IHdhcyB0 byBpbmNsdWRlICAgdGhlIE1VU1QgY29uZGl0aW9uLjwvUD4gIDxQPkhvd2V2ZXIgc2luY2UgdGhl biwgdGhlIGVhcnRoIGhhcyByb3RhdGVkIGFuZCBhdCBsZWFzdCB0aGVyZSBub3cgZXhpc3RzICAg b25lJm5ic3A7Y2FzZSB3aGVyZSBQT1AgaXMgbm8gbW9yZSBuZWVkZWQgd2l0aG91dCBhbnkgc2Vj dXJpdHkgdGhyZWF0LjwvUD4gIDxQPlRoaXMgY2FzZSB3YXMgaW50cm9kdWNlZCBieSBTL01JTUUg d2l0aCB0aGUgb3B0aW9uYWxseSBzaWduZWQgYXR0cmlidXRlICAgRVNTQ2VydElELiA8L1A+ICA8 UD5JdCB3YXMgdGhlbiB0YWtlbiBieSBFVFNJIHdpdGggdGhlIG1hbmRhdG9yeSBFU1NDZXRydElE IChvciBpaXMgZXF1aXZhbGVudCAgIHRoYXQgZG9lcyBub3QgbWFuZGF0ZSB0aGUgdXNlIG9mIFNI QS0xKS48L1A+ICA8UD5SRkMgMzEyNiBzcGVjaWZpZXMgdGhhdCBmb3JtYXQuPC9QPiAgPFA+VGFr aW5nIGludG8gY29uc2lkZXJhdGlvbiB0aGVzZSBmYWN0cywgdGhpcyBtZWFucyB0aGF0IHRoZXJl IGV4aXN0cyBhdCAgIGxlYXN0IG9uZSBjYXNlIHdoZXJlIFBPUCBkb2VzIG5vdCBuZWVkIHRvIGJl IHBlcmZvcm1lZCBhbnltb3JlLiA8L1A+ICA8UD5UaGVyZSBzdGlsbCBleGlzdHMgY2FzZXMgd2hl cmUgaXQgbmVlZHMgdG8gYmUgcGVyZm9ybWVkLCBpbiBwYXJ0aWN1bGFyIHdoZW4gICB0aGUgY2Vy dGlmaWNhdGUgaXMgdXNlZCBmb3IgZW5jcnlwdGlvbiBwdXJwb3Nlcy48L1A+ICA8UD5JJm5ic3A7 YmVsaWV2ZSB0aGF0IFBPUCBpcyBtYW5kYXRvcnkgd2hlbiB0aGUga2V5IGlzIHVzZWQgZm9yIGVu Y3J5cHRpb24gICBwdXJwb3Nlcy48L1A+ICA8UD5JIGJlbGlldmUgdGhhdCBQT1AgaXMgTk9UIFJF UVVJUkVEIHdoZW4gdGhlIGtleSBpcyB1c2VkIGZvciBub24gcmVwdWRpYXRpb24gICBwdXJwb3Nl cyAoZS5nLiBSRkMgMzEyNiBpcyB1c2VkKS48L1A+ICA8UD5XaGVuIHRoZSBrZXkgaXMgdXNlZCBm b3IgYXV0aGVudGljYXRpb24gcHVycG9zZXMsIHRoZW4gZGVwZW5kaW5nIHVwb24gdGhlICAgY2hh cmFjdGVyaXN0aWNzIG9mIHRoZSBwcm90b2NvbCw8QlI+aXQgTUFZIGJlIHJlcXVpcmVkIG9yIG5v dC4gU28gaW4gdGhhdCBjYXNlICAgb25seSwgaXQgd291bGQgbWFrZSBzZW5zZSB0byBzdXBwb3J0 IHRoZSBleHRlbnNpb24gcHJvcG9zZWQgYnkgUnVzcy48L1A+ICA8UD5EZW5pczwvUD4gIDxQPj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PC9QPiAgPFA+RG8geW91IGFncmVlIHdpdGggdGhlc2Ugb2JzZXJ2 YXRpb25zIG9yIGhhdmUgSSBtaXNzZWQgICBzb21ldGhpbmc/PEJSPjxCUj48QlI+U3RlZmFuIFNh bnRlc3NvbjxCUj5Qcm9ncmFtIE1hbmFnZXIsIFN0YW5kYXJkcyAgIExpYWlzb248QlI+V2luZG93 cyBTZWN1cml0eTxCUj48QlI+PEJSPiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+ Jmd0OyAgIEZyb206ICAgb3duZXItaWV0Zi1wa2l4QG1haWwuaW1jLm9yZzxCUj5bbWFpbHRvOm93 bmVyLWlldGYtcGtpeEBtYWlsLmltYy5vcmddPEJSPiZndDsgICBPbiBCZWhhbGYgT2YgUnVzcyBI b3VzbGV5PEJSPiZndDsgU2VudDogZGVuIDI1IG9rdG9iZXIgMjAwNSAyMzowNDxCUj4mZ3Q7IFRv OiAgIGlldGYtcGtpeEBpbWMub3JnPEJSPiZndDsgU3ViamVjdDogUHVibGljIGtleSB2YWxpZGF0 aW9uIGFuZCBQcm9vZiBvZiAgIHBvc3Nlc3Npb248QlI+Jmd0OyA8QlI+Jmd0OyA8QlI+Jmd0OyBE ZWFyIFBLSVggV0c6PEJSPiZndDsgPEJSPiZndDsgVGhlIGRyYWZ0ICAgTklTVCBTUCA4MDAtNTYg ZGVmaW5lcyB0aGUgcmVxdWlyZW1lbnRzIGZvciAiUmVjaXBpZW50PEJSPiZndDsgQXNzdXJhbmNl IG9mICAgU3RhdGljIFB1YmxpYyBLZXkgVmFsaWRpdHkuIiBTZWUgU2VjdGlvbiA1LjYuMi4yLCB3 aGVyZTxCUj5pdDxCUj4mZ3Q7ICAgc2F5czo8QlI+Jmd0OyA8QlI+Jmd0OyBUaGUgcmVjaXBpZW50 IG9mIGEgc3RhdGljIHB1YmxpYyBrZXkgc2hhbGwgb2J0YWluICAgYXNzdXJhbmNlIG9mIGl0czxC Uj4mZ3Q7IHZhbGlkaXR5PEJSPiZndDsgaW4gb25lIG9yIG1vcmUgb2YgdGhlIGZvbGxvd2luZyAg IHdheXM6PEJSPiZndDsgPEJSPiZndDsgMS4gUmVjaXBpZW50IEZ1bGwgVmFsaWRhdGlvbiAtIFRo ZSByZWNpcGllbnQgcGVyZm9ybXMgICBhPEJSPnN1Y2Nlc3NmdWw8QlI+Jmd0OyBmdWxsPEJSPiZn dDsgcHVibGljIGtleSB2YWxpZGF0aW9uIChzZWUgU2VjdGlvbnMgICA1LjYuMi40IGFuZCA1LjYu Mi41KS48QlI+Jmd0OyA8QlI+Jmd0OyAyLiBUVFAgRnVsbCBWYWxpZGF0aW9uIC0gVGhlIHJlY2lw aWVudCAgIHJlY2VpdmVzIGFzc3VyYW5jZSB0aGF0PEJSPmE8QlI+Jmd0OyB0cnVzdGVkPEJSPiZn dDsgdGhpcmQgcGFydHkgKHRydXN0ZWQgYnkgICB0aGUgcmVjaXBpZW50KSBoYXMgcGVyZm9ybWVk IGE8QlI+Jmd0OyBzdWNjZXNzZnVsIGZ1bGw8QlI+Jmd0OyBwdWJsaWMga2V5ICAgdmFsaWRhdGlv biAoc2VlIFNlY3Rpb25zIDUuNi4yLjQgYW5kIDUuNi4yLjUpLjxCUj4mZ3Q7IDxCUj4mZ3Q7IDMu IFRUUCAgIEdlbmVyYXRpb24gLSBUaGUgcmVjaXBpZW50IHJlY2VpdmVzIGFzc3VyYW5jZSB0aGF0 IGE8QlI+Jmd0OyB0cnVzdGVkICAgdGhpcmQ8QlI+Jmd0OyBwYXJ0eSAodHJ1c3RlZCBieSB0aGUg cmVjaXBpZW50KSBoYXMgZ2UgbmVyYXRlZCB0aGU8QlI+Jmd0OyAgIHB1YmxpYy9wcml2YXRlIGtl eTxCUj4mZ3Q7IHBhaXIgaW4gYWNjb3JkYW5jZSB3aXRoIFNlY3Rpb24gNS42LjEgYW5kIGhhcyAg IHByb3ZpZGVkIHRoZTxCUj4mZ3Q7IGtleSBwYWlyIHRvPEJSPiZndDsgdGhlIG93bmVyLjxCUj4m Z3Q7IDxCUj4mZ3Q7IEl0IHNlZW1zICAgdG8gbWUgdGhhdCBvcHRpb24gMiB3YXMgaW5jbHVkZSB0 byBhbGxvdyBhIENBIHRvIHBlcmZvcm0gdGhlPEJSPiZndDsgcHVibGljICAga2V5IHZhbGlkYXRp b24gb25jZSwgYW5kIHRoZW4gYW55IHBhcnR5IHRoYXQgbWFrZXMgdXNlIG9mIHRoZTxCUj4mZ3Q7 ICAgY2VydGlmaWNhdGUgbmVlZCBub3QgZG8gaXQgYWdhaW4uIEZyb20gYSBzeXN0ZW0gcGVyZm9y bWFuY2U8QlI+Jmd0OyAgIHBlcnNwZWN0aXZlLCB0aGlzIHNlZW1zIGhpZ2hseSBkZXNpcmFibGUu PEJSPiZndDsgPEJSPiZndDsgSW4gc29tZSBoaWdobHkgICBhc3N1cmVkIGltcGxlbWVudGF0aW9u IGVudmlyb25tZW50cywgaXQgc2VlbXM8QlI+Jmd0OyBkZXNpcmFibGUgZm9yIHRoZXJlIHRvICAg bWUgYW4gaW5kaWNhdGlvbiBpbiB0aGUgY2VydGlmaWNhdGUgdGhhdCB0aGlzPEJSPiZndDsgYWN0 aW9uIHdhcyB0YWtlbiBieSB0aGUgICBDQS4gT25lIGNvdWxkIGRldGVybWluZSB3aGljaCBjZXJ0 aWZpY2F0aW9uPEJSPiZndDsgcG9saWNpZXMgcmVxdWlyZSB0aGUgQ0EgdG8gICB0YWtlIHRoaXMg YWN0aW9uLCBidXQgdGhhdCBtZWFucyB0aGF0IHRoZTxCUj4mZ3Q7IGxpc3Qgb2YgY2VydGlmaWNh dGlvbiAgIHBvbGljaWVzIHdvdWxkIGJlIGNvbnRpbnVhbGx5IGFkanVzdGVkIGJ5IGFuPEJSPiZn dDsgYWRtaW5pc3RyYXRvci4gSSB3b3VsZCAgIHByZWZlciBhIG5vbi1jcml0aWNhbCBleHRlbnNp b24gdGhhdCBkZWNsYXJlZDxCUj4mZ3Q7IHRoYXQgdGhpcyBhY3Rpb24gd2FzICAgdGFrZW4gYnkg dGhlIENBLjxCUj4mZ3Q7IDxCUj4mZ3Q7IFRoZSBkcmFmdCBOSVNUIFNQIDgwMC01NiwgU2VjdGlv biA1LjYuMy4yICAgZGlzY3Vzc2VzIHRoZSByZXF1aXJlbWVudDxCUj4mZ3Q7IGZvciAiUmVjaXBp ZW50IEFzc3VyYW5jZSBvZiB0aGUgT3duZXIncyAgIFBvc3Nlc3Npb24gb2YgYSBTdGF0aWM8QlI+ Jmd0OyBQcml2YXRlIEtleS4iIFRoYXQgaXMsIHRoZSB0b3BpYyB3ZSBoYXZlIGJlZW4gICBkaXNj dXNzaW5nIGZvciB5ZWFyczxCUj4mZ3Q7IG9uIHRoaXMgbGlzdCwgY2FsbGluZyBpdCBwcm9vZiBv ZiBwb3NzZXNzaW9uLiBSRkMgICAzNjQ3IGluY2x1ZGVzIGE8QlI+Jmd0OyBwbGFjZSBpbiB0aGUg Y2VydGlmaWNhdGlvbiBwb2xpY3kgdG8gZGlzY3VzcyB0aGlzICAgdG9waWMuIChSRkMgMzY0Nyw8 QlI+Jmd0OyBTZWN0aW9uIDMuMi4xOiBNZXRob2QgdG8gcHJvdmUgcG9zc2Vzc2lvbiBvZiBwcml2 YXRlICAga2V5Lik8QlI+Jmd0OyA8QlI+Jmd0OyBBZ2FpbiwgaW4gc29tZSBoaWdobHkgYXNzdXJl ZCBpbXBsZW1lbnRhdGlvbiAgIGVudmlyb25tZW50cywgaXQgc2VlbXM8QlI+Jmd0OyBkZXNpcmFi bGUgZm9yIHRoZXJlIHRvIG1lIGFuIGluZGljYXRpb24gaW4gdGhlICAgY2VydGlmaWNhdGUgdGhh dCBwcm9vZjxCUj4mZ3Q7IG9mIHBvc3Nlc3Npb24gd2FzIHBlcmZvcm1lZCBieSB0aGUgQ0EuIEkg dGhpbmsgICBpdCBjb3VsZCBiZSBwYXJ0IG9mPEJSPiZndDsgdGhlIHNhbWUgbm9uLWNyaXRpY2Fs IGV4dGVuc2lvbiBwcm9wb3NlZCAgIGFib3ZlLjxCUj4mZ3Q7IDxCUj4mZ3Q7IEkgdGhlcmVmb3Jl IHByb3Bvc2UgdGhhdCB0aGUgUEtJWCBXRyBnZW5lcmF0ZSBhICAgc3RhbmRhcmRzLXRyYWNrIFJG QzxCUj4mZ3Q7IHRvIGRlZmluZSBhIGNlcnRpZmljYXRlIGV4dGVuc2lvbiB0byBwcm92aWRlIHRo ZXNlICAgaW5kaWNhdGlvbnMuIEk8QlI+Jmd0OyBwcm9wb3NlIGEgdmVyeSBzaW1wbGUgc3ludGF4 OjxCUj4mZ3Q7IDxCUj4mZ3Q7ICAgaWQtcGUtY2FDaGVja3MgT0JKRUNUIElERU5USUZJRVIgOjo9 IHsgaWQtcGUgJmx0O1RCRCZndDsgfTxCUj4mZ3Q7IDxCUj4mZ3Q7ICAgQ0FDaGVja3MgOjo9IEJJ VCBTVFJJTkcgezxCUj4mZ3Q7IHB1YmxpY0tleVZhbGFkYXRpb24gKDApLDxCUj4mZ3Q7ICAgcHJv b2ZPZlBvc3Nlc3Npb24gKDEpIH08QlI+Jmd0OyA8QlI+Jmd0OyBEbyBvdGhlcnMgdGhpbmsgdGhp cyBpcyBhIHVzZWZ1bCAgIGV4dGVuc2lvbj88QlI+Jmd0OyA8QlI+Jmd0OyBSdXNzPEJSPjxCUj48 QlI+PC9QPjwvQkxPQ0tRVU9URT48L0ZPTlQ+PC9GT05UPg== From owner-ietf-pkix@mail.imc.org Wed Oct 26 11:27:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUnBG-0002X0-ME for pkix-archive@megatron.ietf.org; Wed, 26 Oct 2005 11:27:10 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01154 for ; Wed, 26 Oct 2005 11:26:54 -0400 (EDT) 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 j9QDdfYo051683; Wed, 26 Oct 2005 06:39:41 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QDdfn7051682; Wed, 26 Oct 2005 06:39:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9QDdf5G051666 for ; Wed, 26 Oct 2005 06:39:41 -0700 (PDT) (envelope-from rtbell@cisco.com) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 26 Oct 2005 06:39:36 -0700 X-IronPort-AV: i="3.97,253,1125903600"; d="scan'208,217"; a="356951658:sNHT42203604" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9QDdXJh013444; Wed, 26 Oct 2005 06:39:33 -0700 (PDT) Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 06:39:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5DA32.A835B7EB" Subject: RE: Public key validation and Proof of possession Date: Wed, 26 Oct 2005 06:39:15 -0700 Message-ID: Thread-Topic: Public key validation and Proof of possession Thread-Index: AcXaML9LBWr9WeBMSQyEgJjcAEGOhQAAYLpg From: "Bob Bell \(rtbell\)" To: , "Stefan Santesson" Cc: "Russ Housley" , X-OriginalArrivalTime: 26 Oct 2005 13:39:15.0900 (UTC) FILETIME=[A86F17C0:01C5DA32] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C5DA32.A835B7EB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Denis -=20 =20 I have a question. It would seem to me that for non-repudiation as with the other modes for the cert, without the POP step, there is no way to prove that I as the presenter of the Cert am truly entitled to claim that cert as mine. Since a cert is public information, available from multiple sources presumably, then anyone may acquire the cert. It is only by being able to prove that I have the private key through POP am I able to assert that the cert is in fact MY identity. =20 Am I missing something here? =20 Bob Bell ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of denis.pinkas@bull.net Sent: Wednesday, October 26, 2005 07:12 To: Stefan Santesson Cc: Russ Housley; ietf-pkix@imc.org Subject: RE: Public key validation and Proof of possession =09 =09 Russ and Stefan, This is an interresting issue. Thanks for raising it. (text deleted) =09 So since POP always MUST be performed by the CA there seems not to be the need for diverse policies (POP and non POP). =09 Once upon a time, in the early years of PKI, RFC 2459 stated that sentence that was blindly copied from document to document. In these early years, most (if not all) security protocols were badly designed and thus for them to remains secure the only way was to include the MUST condition. However since then, the earth has rotated and at least there now exists one case where POP is no more needed without any security threat. This case was introduced by S/MIME with the optionally signed attribute ESSCertID.=20 It was then taken by ETSI with the mandatory ESSCetrtID (or iis equivalent that does not mandate the use of SHA-1). RFC 3126 specifies that format. Taking into consideration these facts, this means that there exists at least one case where POP does not need to be performed anymore.=20 There still exists cases where it needs to be performed, in particular when the certificate is used for encryption purposes. I believe that POP is mandatory when the key is used for encryption purposes. I believe that POP is NOT REQUIRED when the key is used for non repudiation purposes (e.g. RFC 3126 is used). When the key is used for authentication purposes, then depending upon the characteristics of the protocol, it MAY be required or not. So in that case only, it would make sense to support the extension proposed by Russ. Denis =09 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D Do you agree with these observations or have I missed something? =09 =09 Stefan Santesson Program Manager, Standards Liaison Windows Security =09 =09 > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Russ Housley > Sent: den 25 oktober 2005 23:04 > To: ietf-pkix@imc.org > Subject: Public key validation and Proof of possession >=20 >=20 > Dear PKIX WG: >=20 > The draft NIST SP 800-56 defines the requirements for "Recipient > Assurance of Static Public Key Validity." See Section 5.6.2.2, where it > says: >=20 > The recipient of a static public key shall obtain assurance of its > validity > in one or more of the following ways: >=20 > 1. Recipient Full Validation - The recipient performs a successful > full > public key validation (see Sections 5.6.2.4 and 5.6.2.5). >=20 > 2. TTP Full Validation - The recipient receives assurance that a > trusted > third party (trusted by the recipient) has performed a > successful full > public key validation (see Sections 5.6.2.4 and 5.6.2.5). >=20 > 3. TTP Generation - The recipient receives assurance that a > trusted third > party (trusted by the recipient) has ge nerated the > public/private key > pair in accordance with Section 5.6.1 and has provided the > key pair to > the owner. >=20 > It seems to me that option 2 was include to allow a CA to perform the > public key validation once, and then any party that makes use of the > certificate need not do it again. From a system performance > perspective, this seems highly desirable. >=20 > In some highly assured implementation environments, it seems > desirable for there to me an indication in the certificate that this > action was taken by the CA. One could determine which certification > policies require the CA to take this action, but that means that the > list of certification policies would be continually adjusted by an > administrator. I would prefer a non-critical extension that declared > that this action was taken by the CA. >=20 > The draft NIST SP 800-56, Section 5.6.3.2 discusses the requirement > for "Recipient Assurance of the Owner's Possession of a Static > Private Key." That is, the topic we have been discussing for years > on this list, calling it proof of possession. RFC 3647 includes a > place in the certification policy to discuss this topic. (RFC 3647, > Section 3.2.1: Method to prove possession of private key.) >=20 > Again, in some highly assured implementation environments, it seems > desirable for there to me an indication in the certificate that proof > of possession was performed by the CA. I think it could be part of > the same non-critical extension proposed above. >=20 > I therefore propose that the PKIX WG generate a standards-track RFC > to define a certificate extension to provide these indications. I > propose a very simple syntax: >=20 > id-pe-caChecks OBJECT IDENTIFIER ::=3D { id-pe } >=20 > CAChecks ::=3D BIT STRING { > publicKeyValadation (0), > proofOfPossession (1) } >=20 > Do others think this is a useful extension? >=20 > Russ =09 =09 =09 ------_=_NextPart_001_01C5DA32.A835B7EB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Denis -
 
I have a question. It would seem to me that for = non-repudiation as with the other modes for the cert, without the POP = step,=20 there is no way to prove that I as the presenter of the Cert am truly = entitled=20 to claim that cert as mine. Since a cert is public information, = available from=20 multiple sources presumably, then anyone may acquire the cert. It is = only by=20 being able to prove that I have the private key through POP am I able to = assert=20 that the cert is in fact MY identity.
 
Am I missing something = here?
 
Bob Bell

From: owner-ietf-pkix@mail.imc.org = [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of=20 denis.pinkas@bull.net
Sent: Wednesday, October 26, 2005=20 07:12
To: Stefan Santesson
Cc: Russ Housley;=20 ietf-pkix@imc.org
Subject: RE: Public key validation and = Proof of=20 possession

Russ and Stefan,

This is an interresting issue. Thanks for raising it.

(text deleted)

So since POP always MUST be performed by the = CA there=20 seems not to be
the need for diverse policies (POP and non = POP).

Once upon a time, in the early years of PKI, RFC 2459 stated that = sentence=20 that was blindly copied from document to document.

In these early years, most (if not all) security protocols were = badly=20 designed and thus for them to remains secure
the only way was to = include=20 the MUST condition.

However since then, the earth has rotated and at least there now = exists=20 one case where POP is no more needed without any security = threat.

This case was introduced by S/MIME with the optionally signed = attribute=20 ESSCertID.

It was then taken by ETSI with the mandatory ESSCetrtID (or iis = equivalent=20 that does not mandate the use of SHA-1).

RFC 3126 specifies that format.

Taking into consideration these facts, this means that there exists = at=20 least one case where POP does not need to be performed anymore.

There still exists cases where it needs to be performed, in = particular when=20 the certificate is used for encryption purposes.

I believe that POP is mandatory when the key is used for = encryption=20 purposes.

I believe that POP is NOT REQUIRED when the key is used for non = repudiation=20 purposes (e.g. RFC 3126 is used).

When the key is used for authentication purposes, then depending = upon the=20 characteristics of the protocol,
it MAY be required or not. So in = that case=20 only, it would make sense to support the extension proposed by = Russ.

Denis

=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

Do you agree with these observations or have I missed=20 something?


Stefan Santesson
Program Manager, Standards=20 Liaison
Windows Security


> -----Original = Message-----
>=20 From:=20 = owner-ietf-pkix@mail.imc.org
[mailto:owner-ietf-pkix@mail.imc.org]
= >=20 On Behalf Of Russ Housley
> Sent: den 25 oktober 2005 = 23:04
> To:=20 ietf-pkix@imc.org
> Subject: Public key validation and Proof of=20 possession
>
>
> Dear PKIX WG:
>
> = The draft=20 NIST SP 800-56 defines the requirements for "Recipient
> = Assurance of=20 Static Public Key Validity." See Section 5.6.2.2, where
it
>=20 says:
>
> The recipient of a static public key shall = obtain=20 assurance of its
> validity
> in one or more of the = following=20 ways:
>
> 1. Recipient Full Validation - The recipient = performs=20 a
successful
> full
> public key validation (see = Sections=20 5.6.2.4 and 5.6.2.5).
>
> 2. TTP Full Validation - The = recipient=20 receives assurance that
a
> trusted
> third party = (trusted by=20 the recipient) has performed a
> successful full
> public = key=20 validation (see Sections 5.6.2.4 and 5.6.2.5).
>
> 3. TTP = Generation - The recipient receives assurance that a
> trusted=20 third
> party (trusted by the recipient) has ge nerated = the
>=20 public/private key
> pair in accordance with Section 5.6.1 and = has=20 provided the
> key pair to
> the owner.
>
> = It seems=20 to me that option 2 was include to allow a CA to perform the
> = public=20 key validation once, and then any party that makes use of the
>=20 certificate need not do it again. From a system performance
>=20 perspective, this seems highly desirable.
>
> In some = highly=20 assured implementation environments, it seems
> desirable for = there to=20 me an indication in the certificate that this
> action was taken = by the=20 CA. One could determine which certification
> policies require = the CA to=20 take this action, but that means that the
> list of = certification=20 policies would be continually adjusted by an
> administrator. I = would=20 prefer a non-critical extension that declared
> that this action = was=20 taken by the CA.
>
> The draft NIST SP 800-56, Section = 5.6.3.2=20 discusses the requirement
> for "Recipient Assurance of the = Owner's=20 Possession of a Static
> Private Key." That is, the topic we = have been=20 discussing for years
> on this list, calling it proof of = possession. RFC=20 3647 includes a
> place in the certification policy to discuss = this=20 topic. (RFC 3647,
> Section 3.2.1: Method to prove possession of = private=20 key.)
>
> Again, in some highly assured implementation=20 environments, it seems
> desirable for there to me an indication = in the=20 certificate that proof
> of possession was performed by the CA. = I think=20 it could be part of
> the same non-critical extension proposed=20 above.
>
> I therefore propose that the PKIX WG generate = a=20 standards-track RFC
> to define a certificate extension to = provide these=20 indications. I
> propose a very simple syntax:
>
>=20 id-pe-caChecks OBJECT IDENTIFIER ::=3D { id-pe <TBD> }
> =
>=20 CAChecks ::=3D BIT STRING {
> publicKeyValadation (0),
>=20 proofOfPossession (1) }
>
> Do others think this is a = useful=20 extension?
>
>=20 Russ


------_=_NextPart_001_01C5DA32.A835B7EB-- From owner-ietf-pkix@mail.imc.org Wed Oct 26 11:32:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUnG2-000774-8D for pkix-archive@megatron.ietf.org; Wed, 26 Oct 2005 11:32:06 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01510 for ; Wed, 26 Oct 2005 11:31:49 -0400 (EDT) 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 j9QEncvc060270; Wed, 26 Oct 2005 07:49:38 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QEncvB060269; Wed, 26 Oct 2005 07:49:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9QEnbqQ060258 for ; Wed, 26 Oct 2005 07:49:37 -0700 (PDT) (envelope-from denis.pinkas@bull.net) 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 RAA37038; Wed, 26 Oct 2005 17:06:51 +0200 Importance: Normal X-Priority: 3 (Normal) Subject: RE: Public key validation and Proof of possession MIME-Version: 1.0 From: denis.pinkas@bull.net To: Russ Housley Cc: "Stefan Santesson" , Date: Wed, 26 Oct 2005 16:50:10 +0200 Message-ID: X-MIMETrack: Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 26/10/2005 16:50:10 MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: base64 PEZPTlQgZmFjZT0iRGVmYXVsdCBTYW5zIFNlcmlmLCBWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNh LCBzYW5zLXNlcmlmIiBzaXplPTI+PERJVj48Rk9OVCBjb2xvcj0jMDA5OTAwPlJ1c3MsPC9GT05U PjwvRElWPjxQPjxGT05UIGNvbG9yPSMwMDk5MDA+TXkgcHJldmlvdXMgcmVwbHkgd2FzIHRvbyBj b25jaXNlLjwvRk9OVD48L1A+PFA+PEZPTlQgY29sb3I9IzAwOTkwMD5ZRVMsIEkgYW0gc3Vwb3J0 aXZlIG9mIHB1YmxpY0tleVZhbGFkYXRpb24gKDApLCBidXQgcGxlYXNlIGFsc28gbm90ZSBhcyBT ZWN1cml0eSBBcmVhIERpcmVjdG9yPEJSPnRoYXQgYSBjaGFuZ2UgdG8gMzI4MGJpcyBzaG91bGQg YWxzbyBiZSBkb25lIDogUE9QIHNob3VsZCBubyBtb3JlIGJlIG1hbmRhdGVkIGluIGFueSBjYXNl LjwvRk9OVD48L1A+PFA+PEZPTlQgY29sb3I9IzAwOTkwMD5EZW5pczwvRk9OVD48L1A+PFA+PEJS PkRlbmlzOjxCUj48QlI+QXJlIHlvdSBzcGVha2luZyBpbiBzdXBwb3J0IG9mIHRoZSBleHRlbnNp b24gdGhhdCBJIHByb3Bvc2VkPzxCUj48QlI+UnVzczxCUj48QlI+QXQgMDk6MTEgQU0gMTAvMjYv MjAwNSwgZGVuaXMucGlua2FzQGJ1bGwubmV0IHdyb3RlOjxCUj48QlI+Jmd0O1J1c3MgYW5kIFN0 ZWZhbiw8QlI+Jmd0OzxCUj4mZ3Q7VGhpcyBpcyBhbiBpbnRlcnJlc3RpbmcgaXNzdWUuIFRoYW5r cyBmb3IgcmFpc2luZyBpdC48QlI+Jmd0OzxCUj4mZ3Q7KHRleHQgZGVsZXRlZCk8QlI+Jmd0OzxC Uj4mZ3Q7U28gc2luY2UgUE9QIGFsd2F5cyBNVVNUIGJlIHBlcmZvcm1lZCBieSB0aGUgQ0EgdGhl cmUgc2VlbXMgbm90IHRvIGJlPEJSPiZndDt0aGUgbmVlZCBmb3IgZGl2ZXJzZSBwb2xpY2llcyAo UE9QIGFuZCBub24gUE9QKS48QlI+Jmd0OzxCUj4mZ3Q7T25jZSB1cG9uIGEgdGltZSwgaW4gdGhl IGVhcmx5IHllYXJzIG9mIFBLSSwgUkZDIDI0NTkgc3RhdGVkIHRoYXQgPEJSPiZndDtzZW50ZW5j ZSB0aGF0IHdhcyBibGluZGx5IGNvcGllZCBmcm9tIGRvY3VtZW50IHRvIGRvY3VtZW50LjxCUj4m Z3Q7PEJSPiZndDtJbiB0aGVzZSBlYXJseSB5ZWFycywgbW9zdCAoaWYgbm90IGFsbCkgc2VjdXJp dHkgcHJvdG9jb2xzIHdlcmUgPEJSPiZndDtiYWRseSBkZXNpZ25lZCBhbmQgdGh1cyBmb3IgdGhl bSB0byByZW1haW5zIHNlY3VyZTxCUj4mZ3Q7dGhlIG9ubHkgd2F5IHdhcyB0byBpbmNsdWRlIHRo ZSBNVVNUIGNvbmRpdGlvbi48QlI+Jmd0OzxCUj4mZ3Q7SG93ZXZlciBzaW5jZSB0aGVuLCB0aGUg ZWFydGggaGFzIHJvdGF0ZWQgYW5kIGF0IGxlYXN0IHRoZXJlIG5vdyA8QlI+Jmd0O2V4aXN0cyBv bmUgY2FzZSB3aGVyZSBQT1AgaXMgbm8gbW9yZSBuZWVkZWQgd2l0aG91dCBhbnkgc2VjdXJpdHkg dGhyZWF0LjxCUj4mZ3Q7PEJSPiZndDtUaGlzIGNhc2Ugd2FzIGludHJvZHVjZWQgYnkgUy9NSU1F IHdpdGggdGhlIG9wdGlvbmFsbHkgc2lnbmVkIDxCUj4mZ3Q7YXR0cmlidXRlIEVTU0NlcnRJRC48 QlI+Jmd0OzxCUj4mZ3Q7SXQgd2FzIHRoZW4gdGFrZW4gYnkgRVRTSSB3aXRoIHRoZSBtYW5kYXRv cnkgRVNTQ2V0cnRJRCAob3IgaWlzIDxCUj4mZ3Q7ZXF1aXZhbGVudCB0aGF0IGRvZXMgbm90IG1h bmRhdGUgdGhlIHVzZSBvZiBTSEEtMSkuPEJSPiZndDs8QlI+Jmd0O1JGQyAzMTI2IHNwZWNpZmll cyB0aGF0IGZvcm1hdC48QlI+Jmd0OzxCUj4mZ3Q7VGFraW5nIGludG8gY29uc2lkZXJhdGlvbiB0 aGVzZSBmYWN0cywgdGhpcyBtZWFucyB0aGF0IHRoZXJlIGV4aXN0cyA8QlI+Jmd0O2F0IGxlYXN0 IG9uZSBjYXNlIHdoZXJlIFBPUCBkb2VzIG5vdCBuZWVkIHRvIGJlIHBlcmZvcm1lZCBhbnltb3Jl LjxCUj4mZ3Q7PEJSPiZndDtUaGVyZSBzdGlsbCBleGlzdHMgY2FzZXMgd2hlcmUgaXQgbmVlZHMg dG8gYmUgcGVyZm9ybWVkLCBpbiA8QlI+Jmd0O3BhcnRpY3VsYXIgd2hlbiB0aGUgY2VydGlmaWNh dGUgaXMgdXNlZCBmb3IgZW5jcnlwdGlvbiBwdXJwb3Nlcy48QlI+Jmd0OzxCUj4mZ3Q7SSBiZWxp ZXZlIHRoYXQgUE9QIGlzIG1hbmRhdG9yeSB3aGVuIHRoZSBrZXkgaXMgdXNlZCBmb3IgZW5jcnlw dGlvbiBwdXJwb3Nlcy48QlI+Jmd0OzxCUj4mZ3Q7SSBiZWxpZXZlIHRoYXQgUE9QIGlzIE5PVCBS RVFVSVJFRCB3aGVuIHRoZSBrZXkgaXMgdXNlZCBmb3Igbm9uIDxCUj4mZ3Q7cmVwdWRpYXRpb24g cHVycG9zZXMgKGUuZy4gUkZDIDMxMjYgaXMgdXNlZCkuPEJSPiZndDs8QlI+Jmd0O1doZW4gdGhl IGtleSBpcyB1c2VkIGZvciBhdXRoZW50aWNhdGlvbiBwdXJwb3NlcywgdGhlbiBkZXBlbmRpbmcg PEJSPiZndDt1cG9uIHRoZSBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhlIHByb3RvY29sLDxCUj4mZ3Q7 aXQgTUFZIGJlIHJlcXVpcmVkIG9yIG5vdC4gU28gaW4gdGhhdCBjYXNlIG9ubHksIGl0IHdvdWxk IG1ha2Ugc2Vuc2UgPEJSPiZndDt0byBzdXBwb3J0IHRoZSBleHRlbnNpb24gcHJvcG9zZWQgYnkg UnVzcy48QlI+Jmd0OzxCUj4mZ3Q7RGVuaXM8QlI+Jmd0OzxCUj4mZ3Q7PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT08QlI+Jmd0OzxCUj4mZ3Q7RG8geW91IGFncmVlIHdpdGggdGhlc2Ugb2JzZXJ2YXRpb25z IG9yIGhhdmUgSSBtaXNzZWQgc29tZXRoaW5nPzxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0O1N0ZWZh biBTYW50ZXNzb248QlI+Jmd0O1Byb2dyYW0gTWFuYWdlciwgU3RhbmRhcmRzIExpYWlzb248QlI+ Jmd0O1dpbmRvd3MgU2VjdXJpdHk8QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDsgJmd0OyAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj4mZ3Q7ICZndDsgRnJvbTogb3duZXItaWV0Zi1wa2l4QG1h aWwuaW1jLm9yZzxCUj4mZ3Q7W21haWx0bzpvd25lci1pZXRmLXBraXhAbWFpbC5pbWMub3JnXTxC Uj4mZ3Q7ICZndDsgT24gQmVoYWxmIE9mIFJ1c3MgSG91c2xleTxCUj4mZ3Q7ICZndDsgU2VudDog ZGVuIDI1IG9rdG9iZXIgMjAwNSAyMzowNDxCUj4mZ3Q7ICZndDsgVG86IGlldGYtcGtpeEBpbWMu b3JnPEJSPiZndDsgJmd0OyBTdWJqZWN0OiBQdWJsaWMga2V5IHZhbGlkYXRpb24gYW5kIFByb29m IG9mIHBvc3Nlc3Npb248QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgRGVh ciBQS0lYIFdHOjxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IFRoZSBkcmFmdCBOSVNUIFNQIDgw MC01NiBkZWZpbmVzIHRoZSByZXF1aXJlbWVudHMgZm9yICJSZWNpcGllbnQ8QlI+Jmd0OyAmZ3Q7 IEFzc3VyYW5jZSBvZiBTdGF0aWMgUHVibGljIEtleSBWYWxpZGl0eS4iIFNlZSBTZWN0aW9uIDUu Ni4yLjIsIHdoZXJlPEJSPiZndDtpdDxCUj4mZ3Q7ICZndDsgc2F5czo8QlI+Jmd0OyAmZ3Q7PEJS PiZndDsgJmd0OyBUaGUgcmVjaXBpZW50IG9mIGEgc3RhdGljIHB1YmxpYyBrZXkgc2hhbGwgb2J0 YWluIGFzc3VyYW5jZSBvZiBpdHM8QlI+Jmd0OyAmZ3Q7IHZhbGlkaXR5PEJSPiZndDsgJmd0OyBp biBvbmUgb3IgbW9yZSBvZiB0aGUgZm9sbG93aW5nIHdheXM6PEJSPiZndDsgJmd0OzxCUj4mZ3Q7 ICZndDsgMS4gUmVjaXBpZW50IEZ1bGwgVmFsaWRhdGlvbiAtIFRoZSByZWNpcGllbnQgcGVyZm9y bXMgYTxCUj4mZ3Q7c3VjY2Vzc2Z1bDxCUj4mZ3Q7ICZndDsgZnVsbDxCUj4mZ3Q7ICZndDsgcHVi bGljIGtleSB2YWxpZGF0aW9uIChzZWUgU2VjdGlvbnMgNS42LjIuNCBhbmQgNS42LjIuNSkuPEJS PiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgMi4gVFRQIEZ1bGwgVmFsaWRhdGlvbiAtIFRoZSByZWNp cGllbnQgcmVjZWl2ZXMgYXNzdXJhbmNlIHRoYXQ8QlI+Jmd0O2E8QlI+Jmd0OyAmZ3Q7IHRydXN0 ZWQ8QlI+Jmd0OyAmZ3Q7IHRoaXJkIHBhcnR5ICh0cnVzdGVkIGJ5IHRoZSByZWNpcGllbnQpIGhh cyBwZXJmb3JtZWQgYTxCUj4mZ3Q7ICZndDsgc3VjY2Vzc2Z1bCBmdWxsPEJSPiZndDsgJmd0OyBw dWJsaWMga2V5IHZhbGlkYXRpb24gKHNlZSBTZWN0aW9ucyA1LjYuMi40IGFuZCA1LjYuMi41KS48 QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAzLiBUVFAgR2VuZXJhdGlvbiAtIFRoZSByZWNpcGll bnQgcmVjZWl2ZXMgYXNzdXJhbmNlIHRoYXQgYTxCUj4mZ3Q7ICZndDsgdHJ1c3RlZCB0aGlyZDxC Uj4mZ3Q7ICZndDsgcGFydHkgKHRydXN0ZWQgYnkgdGhlIHJlY2lwaWVudCkgaGFzIGdlIG5lcmF0 ZWQgdGhlPEJSPiZndDsgJmd0OyBwdWJsaWMvcHJpdmF0ZSBrZXk8QlI+Jmd0OyAmZ3Q7IHBhaXIg aW4gYWNjb3JkYW5jZSB3aXRoIFNlY3Rpb24gNS42LjEgYW5kIGhhcyBwcm92aWRlZCB0aGU8QlI+ Jmd0OyAmZ3Q7IGtleSBwYWlyIHRvPEJSPiZndDsgJmd0OyB0aGUgb3duZXIuPEJSPiZndDsgJmd0 OzxCUj4mZ3Q7ICZndDsgSXQgc2VlbXMgdG8gbWUgdGhhdCBvcHRpb24gMiB3YXMgaW5jbHVkZSB0 byBhbGxvdyBhIENBIHRvIHBlcmZvcm0gdGhlPEJSPiZndDsgJmd0OyBwdWJsaWMga2V5IHZhbGlk YXRpb24gb25jZSwgYW5kIHRoZW4gYW55IHBhcnR5IHRoYXQgbWFrZXMgdXNlIG9mIHRoZTxCUj4m Z3Q7ICZndDsgY2VydGlmaWNhdGUgbmVlZCBub3QgZG8gaXQgYWdhaW4uIEZyb20gYSBzeXN0ZW0g cGVyZm9ybWFuY2U8QlI+Jmd0OyAmZ3Q7IHBlcnNwZWN0aXZlLCB0aGlzIHNlZW1zIGhpZ2hseSBk ZXNpcmFibGUuPEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgSW4gc29tZSBoaWdobHkgYXNzdXJl ZCBpbXBsZW1lbnRhdGlvbiBlbnZpcm9ubWVudHMsIGl0IHNlZW1zPEJSPiZndDsgJmd0OyBkZXNp cmFibGUgZm9yIHRoZXJlIHRvIG1lIGFuIGluZGljYXRpb24gaW4gdGhlIGNlcnRpZmljYXRlIHRo YXQgdGhpczxCUj4mZ3Q7ICZndDsgYWN0aW9uIHdhcyB0YWtlbiBieSB0aGUgQ0EuIE9uZSBjb3Vs ZCBkZXRlcm1pbmUgd2hpY2ggY2VydGlmaWNhdGlvbjxCUj4mZ3Q7ICZndDsgcG9saWNpZXMgcmVx dWlyZSB0aGUgQ0EgdG8gdGFrZSB0aGlzIGFjdGlvbiwgYnV0IHRoYXQgbWVhbnMgdGhhdCB0aGU8 QlI+Jmd0OyAmZ3Q7IGxpc3Qgb2YgY2VydGlmaWNhdGlvbiBwb2xpY2llcyB3b3VsZCBiZSBjb250 aW51YWxseSBhZGp1c3RlZCBieSBhbjxCUj4mZ3Q7ICZndDsgYWRtaW5pc3RyYXRvci4gSSB3b3Vs ZCBwcmVmZXIgYSBub24tY3JpdGljYWwgZXh0ZW5zaW9uIHRoYXQgZGVjbGFyZWQ8QlI+Jmd0OyAm Z3Q7IHRoYXQgdGhpcyBhY3Rpb24gd2FzIHRha2VuIGJ5IHRoZSBDQS48QlI+Jmd0OyAmZ3Q7PEJS PiZndDsgJmd0OyBUaGUgZHJhZnQgTklTVCBTUCA4MDAtNTYsIFNlY3Rpb24gNS42LjMuMiBkaXNj dXNzZXMgdGhlIHJlcXVpcmVtZW50PEJSPiZndDsgJmd0OyBmb3IgIlJlY2lwaWVudCBBc3N1cmFu Y2Ugb2YgdGhlIE93bmVyJ3MgUG9zc2Vzc2lvbiBvZiBhIFN0YXRpYzxCUj4mZ3Q7ICZndDsgUHJp dmF0ZSBLZXkuIiBUaGF0IGlzLCB0aGUgdG9waWMgd2UgaGF2ZSBiZWVuIGRpc2N1c3NpbmcgZm9y IHllYXJzPEJSPiZndDsgJmd0OyBvbiB0aGlzIGxpc3QsIGNhbGxpbmcgaXQgcHJvb2Ygb2YgcG9z c2Vzc2lvbi4gUkZDIDM2NDcgaW5jbHVkZXMgYTxCUj4mZ3Q7ICZndDsgcGxhY2UgaW4gdGhlIGNl cnRpZmljYXRpb24gcG9saWN5IHRvIGRpc2N1c3MgdGhpcyB0b3BpYy4gKFJGQyAzNjQ3LDxCUj4m Z3Q7ICZndDsgU2VjdGlvbiAzLjIuMTogTWV0aG9kIHRvIHByb3ZlIHBvc3Nlc3Npb24gb2YgcHJp dmF0ZSBrZXkuKTxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IEFnYWluLCBpbiBzb21lIGhpZ2hs eSBhc3N1cmVkIGltcGxlbWVudGF0aW9uIGVudmlyb25tZW50cywgaXQgc2VlbXM8QlI+Jmd0OyAm Z3Q7IGRlc2lyYWJsZSBmb3IgdGhlcmUgdG8gbWUgYW4gaW5kaWNhdGlvbiBpbiB0aGUgY2VydGlm aWNhdGUgdGhhdCBwcm9vZjxCUj4mZ3Q7ICZndDsgb2YgcG9zc2Vzc2lvbiB3YXMgcGVyZm9ybWVk IGJ5IHRoZSBDQS4gSSB0aGluayBpdCBjb3VsZCBiZSBwYXJ0IG9mPEJSPiZndDsgJmd0OyB0aGUg c2FtZSBub24tY3JpdGljYWwgZXh0ZW5zaW9uIHByb3Bvc2VkIGFib3ZlLjxCUj4mZ3Q7ICZndDs8 QlI+Jmd0OyAmZ3Q7IEkgdGhlcmVmb3JlIHByb3Bvc2UgdGhhdCB0aGUgUEtJWCBXRyBnZW5lcmF0 ZSBhIHN0YW5kYXJkcy10cmFjayBSRkM8QlI+Jmd0OyAmZ3Q7IHRvIGRlZmluZSBhIGNlcnRpZmlj YXRlIGV4dGVuc2lvbiB0byBwcm92aWRlIHRoZXNlIGluZGljYXRpb25zLiBJPEJSPiZndDsgJmd0 OyBwcm9wb3NlIGEgdmVyeSBzaW1wbGUgc3ludGF4OjxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7 IGlkLXBlLWNhQ2hlY2tzIE9CSkVDVCBJREVOVElGSUVSIDo6PSB7IGlkLXBlICZsdDtUQkQmZ3Q7 IH08QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyBDQUNoZWNrcyA6Oj0gICAgQklUIFNUUklORyB7 PEJSPiZndDsgJmd0OyBwdWJsaWNLZXlWYWxhZGF0aW9uICgwKSw8QlI+Jmd0OyAmZ3Q7IHByb29m T2ZQb3NzZXNzaW9uICgxKSB9PEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgRG8gb3RoZXJzIHRo aW5rIHRoaXMgaXMgYSB1c2VmdWwgZXh0ZW5zaW9uPzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7 IFJ1c3M8QlI+Jmd0OzxCUj48QlI+PC9QPjwvRk9OVD4= From owner-ietf-pkix@mail.imc.org Wed Oct 26 11:35:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUnJi-0003AM-Aa for pkix-archive@megatron.ietf.org; Wed, 26 Oct 2005 11:35:55 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01760 for ; Wed, 26 Oct 2005 11:35:37 -0400 (EDT) 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 j9QEsIZh060574; Wed, 26 Oct 2005 07:54:18 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QEsI3a060573; Wed, 26 Oct 2005 07:54:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9QEsHhO060560 for ; Wed, 26 Oct 2005 07:54:17 -0700 (PDT) (envelope-from rtbell@cisco.com) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 26 Oct 2005 07:54:12 -0700 X-IronPort-AV: i="3.97,254,1125903600"; d="scan'208,217"; a="669423876:sNHT47124820" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9QEs2Jn029139; Wed, 26 Oct 2005 07:54:10 -0700 (PDT) Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 07:54:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5DA3D.1B60C823" Subject: RE: Public key validation and Proof of possession Date: Wed, 26 Oct 2005 07:54:01 -0700 Message-ID: Thread-Topic: Public key validation and Proof of possession Thread-Index: AcXaO+w0meeI4lA0T2G5tPAR9vIOAgAAQ0gg From: "Bob Bell \(rtbell\)" To: Cc: "Stefan Santesson" , "Russ Housley" , X-OriginalArrivalTime: 26 Oct 2005 14:54:03.0936 (UTC) FILETIME=[1B830A00:01C5DA3D] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C5DA3D.1B60C823 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Denis -=20 =20 Comment in line. ________________________________ From: denis.pinkas@bull.net [mailto:denis.pinkas@bull.net]=20 Sent: Wednesday, October 26, 2005 08:46 To: Bob Bell (rtbell) Cc: Stefan Santesson; Russ Housley; ietf-pkix@imc.org Subject: RE: Public key validation and Proof of possession =09 =09 =09 Denis -=20 =20 I have a question. It would seem to me that for non-repudiation as with the other modes for the cert, without the POP step, there is no way to prove that I as the presenter of the Cert am truly entitled to claim that cert as mine. Since a cert is public information, available from multiple sources presumably, then anyone may acquire the cert. It is only by being able to prove that I have the private key through POP am I able to assert that the cert is in fact MY identity. =20 Am I missing something here? =20 =09 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D =20 May I say, yes ? :-) =20 An entity MUST still demonstrate who it is, in order to get the appropriate name in the certificate (subject field). =20 In the case of non repudiation, if an entity presents a public key that is not its, then he entity does not know the corresponding private key,=20 and hence is unable to use the certificate. Since using RFC 3126, the hash of the certificate (or teh certificate) MUST be protected by the digital signature, substitution of a certificate by another that would contain the same public key would be immediately detected.=20 =20 Ok. So this is the POP step I thought you were advocating we did not need. My mistake. Thanks.=20 =20 "Old" protocols were no using certificates. Then certificates were added, but external to the security protocol ("unprotected"). The right thing is to protect the certificate by the digital signature, as RFC 3126 is doing. Note that this allows to certify the same public key=20 with different attributes from different CAs. =20 So POP alone, is unable to solve the susbstitution of one certificate from a user by another legitimate certificate from the same user=20 with the same public key in it, but with a different name in it, or different attributes in it. =20 Denis =20 =20 Bob Bell =09 ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of denis.pinkas@bull.net Sent: Wednesday, October 26, 2005 07:12 To: Stefan Santesson Cc: Russ Housley; ietf-pkix@imc.org Subject: RE: Public key validation and Proof of possession =09 =09 =09 Russ and Stefan, This is an interresting issue. Thanks for raising it. (text deleted) =09 So since POP always MUST be performed by the CA there seems not to be the need for diverse policies (POP and non POP). =09 Once upon a time, in the early years of PKI, RFC 2459 stated that sentence that was blindly copied from document to document. In these early years, most (if not all) security protocols were badly designed and thus for them to remains secure the only way was to include the MUST condition. However since then, the earth has rotated and at least there now exists one case where POP is no more needed without any security threat. This case was introduced by S/MIME with the optionally signed attribute ESSCertID.=20 It was then taken by ETSI with the mandatory ESSCetrtID (or iis equivalent that does not mandate the use of SHA-1). RFC 3126 specifies that format. Taking into consideration these facts, this means that there exists at least one case where POP does not need to be performed anymore.=20 There still exists cases where it needs to be performed, in particular when the certificate is used for encryption purposes. I believe that POP is mandatory when the key is used for encryption purposes. I believe that POP is NOT REQUIRED when the key is used for non repudiation purposes (e.g. RFC 3126 is used). When the key is used for authentication purposes, then depending upon the characteristics of the protocol, it MAY be required or not. So in that case only, it would make sense to support the extension proposed by Russ. Denis =09 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D Do you agree with these observations or have I missed something? =09 =09 Stefan Santesson Program Manager, Standards Liaison Windows Security =09 =09 > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Russ Housley > Sent: den 25 oktober 2005 23:04 > To: ietf-pkix@imc.org > Subject: Public key validation and Proof of possession >=20 >=20 > Dear PKIX WG: >=20 > The draft NIST SP 800-56 defines the requirements for "Recipient > Assurance of Static Public Key Validity." See Section 5.6.2.2, where it > says: >=20 > The recipient of a static public key shall obtain assurance of its > validity > in one or more of the following ways: >=20 > 1. Recipient Full Validation - The recipient performs a successful > full > public key validation (see Sections 5.6.2.4 and 5.6.2.5). >=20 > 2. TTP Full Validation - The recipient receives assurance that a > trusted > third party (trusted by the recipient) has performed a > successful full > public key validation (see Sections 5.6.2.4 and 5.6.2.5). >=20 > 3. TTP Generation - The recipient receives assurance that a > trusted third > party (trusted by the recipient) has ge nerated the > public/private key > pair in accordance with Section 5.6.1 and has provided the > key pair to > the owner. >=20 > It seems to me that option 2 was include to allow a CA to perform the > public key validation once, and then any party that makes use of the > certificate need not do it again. From a system performance > perspective, this seems highly desirable. >=20 > In some highly assured implementation environments, it seems > desirable for there to me an indication in the certificate that this > action was taken by the CA. One could determine which certification > policies require the CA to take this action, but that means that the > list of certification policies would be continually adjusted by an > administrator. I would prefer a non-critical extension that declared > that this action was taken by the CA. >=20 > The draft NIST SP 800-56, Section 5.6.3.2 discusses the requirement > for "Recipient Assurance of the Owner's Possession of a Static > Private Key." That is, the topic we have been discussing for years > on this list, calling it proof of possession. RFC 3647 includes a > place in the certification policy to discuss this topic. (RFC 3647, > Section 3.2.1: Method to prove possession of private key.) >=20 > Again, in some highly assured implementation environments, it seems > desirable for there to me an indication in the certificate that proof > of possession was performed by the CA. I think it could be part of > the same non-critical extension proposed above. >=20 > I therefore propose that the PKIX WG generate a standards-track RFC > to define a certificate extension to provide these indications. I > propose a very simple syntax: >=20 > id-pe-caChecks OBJECT IDENTIFIER ::=3D { id-pe } >=20 > CAChecks ::=3D BIT STRING { > publicKeyValadation (0), > proofOfPossession (1) } >=20 > Do others think this is a useful extension? >=20 > Russ =09 =09 =09 ------_=_NextPart_001_01C5DA3D.1B60C823 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Denis -
 
Comment in line.

From: denis.pinkas@bull.net=20 [mailto:denis.pinkas@bull.net]
Sent: Wednesday, October 26, = 2005=20 08:46
To: Bob Bell (rtbell)
Cc: Stefan Santesson; = Russ=20 Housley; ietf-pkix@imc.org
Subject: RE: Public key = validation and=20 Proof of possession

Denis -
 
I have a question. It would seem to me that = for=20 non-repudiation as with the other modes for the cert, without the POP = step,=20 there is no way to prove that I as the presenter of the Cert am truly = entitled=20 to claim that cert as mine. Since a cert is public information, = available from=20 multiple sources presumably, then anyone may acquire the cert. It is = only by=20 being able to prove that I have the private key through POP am I able = to=20 assert that the cert is in fact MY identity.
 
Am I missing something = here?
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
 
May I say, yes ? :-)
 
An entity MUST still demonstrate who it is, in order to = get the=20 appropriate name in the certificate (subject = field).
 
In the case of non repudiation, if an = entity presents a=20 public key that is not its, then he entity does not know the=20 corresponding private key,
and hence is unable to use the certificate. Since = using RFC=20 3126, the hash of the certificate (or teh certificate) MUST be = protected=20
by the digital signature, substitution of a certificate by = another that=20 would contain the same public key would be immediately detected. 
 
Ok. So = this is the POP=20 step I thought you were advocating we did not need. My mistake.=20 Thanks. 
 
"Old" protocols were no using certificates. Then certificates = were added, but external to the security protocol=20 ("unprotected").
The right thing is to protect the certificate by the digital = signature,=20 as RFC 3126 is doing. Note that this allows to certify the same public = key=20
with different attributes from different = CAs.
 
So POP alone, is unable to solve the susbstitution of one = certificate=20 from a user by another legitimate certificate from the same user=20
with the same public key in it, but with a different = name in it, or=20 different attributes in it.
 
Denis
 
 
Bob Bell

From:=20 owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On=20 Behalf Of denis.pinkas@bull.net
Sent: Wednesday, = October 26,=20 2005 07:12
To: Stefan Santesson
Cc: Russ = Housley;=20 ietf-pkix@imc.org
Subject: RE: Public key validation and = Proof of=20 possession

Russ and Stefan,

This is an interresting issue. Thanks for raising=20 it.

(text deleted)

So since POP always MUST be = performed=20 by the CA there seems not to be
the need for diverse policies = (POP and=20 non POP).

Once upon a time, in the early years of PKI, RFC = 2459 stated=20 that sentence that was blindly copied from document to = document.

In these early years, most (if not all) security = protocols=20 were badly designed and thus for them to remains secure
the only = way was=20 to include the MUST condition.

However since then, the earth has rotated and at = least there=20 now exists one case where POP is no more needed without any = security=20 threat.

This case was introduced by S/MIME with the = optionally=20 signed attribute ESSCertID.

It was then taken by ETSI with the mandatory = ESSCetrtID (or=20 iis equivalent that does not mandate the use of SHA-1).

RFC 3126 specifies that format.

Taking into consideration these facts, this means = that there=20 exists at least one case where POP does not need to be performed = anymore.=20

There still exists cases where it needs to be = performed, in=20 particular when the certificate is used for encryption = purposes.

I believe that POP is mandatory when the key = is used=20 for encryption purposes.

I believe that POP is NOT REQUIRED when the key is = used for=20 non repudiation purposes (e.g. RFC 3126 is used).

When the key is used for authentication purposes, = then=20 depending upon the characteristics of the protocol,
it MAY be = required or=20 not. So in that case only, it would make sense to support the = extension=20 proposed by Russ.

Denis

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

Do you agree with these observations or have I = missed=20 something?


Stefan Santesson
Program Manager, Standards = Liaison
Windows Security


> -----Original=20 Message-----
> From:=20 = owner-ietf-pkix@mail.imc.org
[mailto:owner-ietf-pkix@mail.imc.org]
= >=20 On Behalf Of Russ Housley
> Sent: den 25 oktober 2005 = 23:04
>=20 To: ietf-pkix@imc.org
> Subject: Public key validation and = Proof of=20 possession
>
>
> Dear PKIX WG:
>
> = The=20 draft NIST SP 800-56 defines the requirements for "Recipient
> = Assurance of Static Public Key Validity." See Section 5.6.2.2,=20 where
it
> says:
>
> The recipient of a static = public=20 key shall obtain assurance of its
> validity
> in one or = more of=20 the following ways:
>
> 1. Recipient Full Validation - = The=20 recipient performs a
successful
> full
> public key=20 validation (see Sections 5.6.2.4 and 5.6.2.5).
>
> 2. = TTP Full=20 Validation - The recipient receives assurance that
a
>=20 trusted
> third party (trusted by the recipient) has performed = a
> successful full
> public key validation (see = Sections=20 5.6.2.4 and 5.6.2.5).
>
> 3. TTP Generation - The = recipient=20 receives assurance that a
> trusted third
> party = (trusted by=20 the recipient) has ge nerated the
> public/private key
> = pair in=20 accordance with Section 5.6.1 and has provided the
> key pair=20 to
> the owner.
>
> It seems to me that option 2 = was=20 include to allow a CA to perform the
> public key validation = once, and=20 then any party that makes use of the
> certificate need not do = it=20 again. From a system performance
> perspective, this seems = highly=20 desirable.
>
> In some highly assured implementation=20 environments, it seems
> desirable for there to me an = indication in=20 the certificate that this
> action was taken by the CA. One = could=20 determine which certification
> policies require the CA to = take this=20 action, but that means that the
> list of certification = policies would=20 be continually adjusted by an
> administrator. I would prefer = a=20 non-critical extension that declared
> that this action was = taken by=20 the CA.
>
> The draft NIST SP 800-56, Section 5.6.3.2 = discusses=20 the requirement
> for "Recipient Assurance of the Owner's = Possession=20 of a Static
> Private Key." That is, the topic we have been = discussing=20 for years
> on this list, calling it proof of possession. RFC = 3647=20 includes a
> place in the certification policy to discuss this = topic.=20 (RFC 3647,
> Section 3.2.1: Method to prove possession of = private=20 key.)
>
> Again, in some highly assured implementation=20 environments, it seems
> desirable for there to me an = indication in=20 the certificate that proof
> of possession was performed by = the CA. I=20 think it could be part of
> the same non-critical extension = proposed=20 above.
>
> I therefore propose that the PKIX WG = generate a=20 standards-track RFC
> to define a certificate extension to = provide=20 these indications. I
> propose a very simple syntax:
> =
>=20 id-pe-caChecks OBJECT IDENTIFIER ::=3D { id-pe <TBD> }
> =
>=20 CAChecks ::=3D BIT STRING {
> publicKeyValadation (0),
> = proofOfPossession (1) }
>
> Do others think this is a = useful=20 extension?
>
>=20 Russ


------_=_NextPart_001_01C5DA3D.1B60C823-- From owner-ietf-pkix@mail.imc.org Wed Oct 26 11:53:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUnar-0003Dz-EX for pkix-archive@megatron.ietf.org; Wed, 26 Oct 2005 11:53:37 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03019 for ; Wed, 26 Oct 2005 11:53:20 -0400 (EDT) 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 j9QF2awG061480; Wed, 26 Oct 2005 08:02:36 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QF2a6Y061479; Wed, 26 Oct 2005 08:02:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from bcisse.com (209-204-118-122.sniparpa.net [209.204.118.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9QF2ZOS061473 for ; Wed, 26 Oct 2005 08:02:35 -0700 (PDT) (envelope-from sblakewilson@bcisse.com) Received: from simon (toronto-HSE-ppp4162903.sympatico.ca [70.51.152.37]) by bcisse.com; Wed, 26 Oct 2005 11:01:31 -0400 From: "Simon Blake-Wilson" To: "'Russ Housley'" , Subject: RE: Public key validation and Proof of possession Date: Wed, 26 Oct 2005 11:01:29 -0400 Message-ID: <04e001c5da3e$25cb11a0$0200a8c0@simon> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 MIME-Version: 1.0 In-Reply-To: <7.0.0.10.2.20051025164030.061cdfb0@vigilsec.com> Importance: Normal Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_04DC_01C5DA1C.9DD441C0" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_04DC_01C5DA1C.9DD441C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Russ, I have no problem with defining extensions for this, but I think it would need to be made very clear somewhere what checks must be performed if the public key validation extension is asserted. For DH for example, does it imply that subgroup membership ((g^x)^q=1 mod p) has been checked? Not all protocols use subgroups for DH, do they? Other algorithms are harder. What exactly does public key validation for RSA or NTRU or XYZ mean? I think the key here is that in some cases checking 0 -----Original Message----- > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Russ Housley > Sent: Tuesday, October 25, 2005 5:04 PM > To: ietf-pkix@imc.org > Subject: Public key validation and Proof of possession > > > > Dear PKIX WG: > > The draft NIST SP 800-56 defines the requirements for "Recipient > Assurance of Static Public Key Validity." See Section > 5.6.2.2, where it says: > > The recipient of a static public key shall obtain > assurance of its validity > in one or more of the following ways: > > 1. Recipient Full Validation - The recipient performs > a successful full > public key validation (see Sections 5.6.2.4 and 5.6.2.5). > > 2. TTP Full Validation - The recipient receives > assurance that a trusted > third party (trusted by the recipient) has performed a > successful full > public key validation (see Sections 5.6.2.4 and 5.6.2.5). > > 3. TTP Generation - The recipient receives assurance that a > trusted third > party (trusted by the recipient) has ge nerated the > public/private key > pair in accordance with Section 5.6.1 and has provided the > key pair to > the owner. > > It seems to me that option 2 was include to allow a CA to perform the > public key validation once, and then any party that makes use of the > certificate need not do it again. From a system performance > perspective, this seems highly desirable. > > In some highly assured implementation environments, it seems > desirable for there to me an indication in the certificate that this > action was taken by the CA. One could determine which certification > policies require the CA to take this action, but that means that the > list of certification policies would be continually adjusted by an > administrator. I would prefer a non-critical extension that declared > that this action was taken by the CA. > > The draft NIST SP 800-56, Section 5.6.3.2 discusses the requirement > for "Recipient Assurance of the Owner's Possession of a Static > Private Key." That is, the topic we have been discussing for years > on this list, calling it proof of possession. RFC 3647 includes a > place in the certification policy to discuss this topic. (RFC 3647, > Section 3.2.1: Method to prove possession of private key.) > > Again, in some highly assured implementation environments, it seems > desirable for there to me an indication in the certificate that proof > of possession was performed by the CA. I think it could be part of > the same non-critical extension proposed above. > > I therefore propose that the PKIX WG generate a standards-track RFC > to define a certificate extension to provide these indications. I > propose a very simple syntax: > > id-pe-caChecks OBJECT IDENTIFIER ::= { id-pe } > > CAChecks ::= BIT STRING { > publicKeyValadation (0), > proofOfPossession (1) } > > Do others think this is a useful extension? > > Russ > > ------=_NextPart_000_04DC_01C5DA1C.9DD441C0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6DCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggNiMIICy6ADAgECAhAL2gsXwT+JjqsJdHq0zi4zMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo4GwMIGtMA8GA1UdEwQIMAYBAf8CAQAw RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L3BjYTEuY3JsMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAQYwDQYJKoZIhvcNAQECBQAD gYEAAn2eb0VLOKC43ulTZCG85Ewrjx7+kkCs2Ao5aqEyISwHm6tZ/tJiGn1VOLA3c9z0B2ZjYr3h U3BSh+eo2FLpWy2q4d7PrDFU1IsZyNgjqO8EKzJ9LBgcyHyJqC538kTRZQpNdLXu0xuSc3QuiTs1 E3LnQDGa07LEq+dWvovj+xUwggQ9MIIDpqADAgECAhA22vJQKV5JPY1TSL01WJuyMA0GCSqGSIb3 DQEBBQUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA1MDIxMDAwMDAw MFoXDTA2MDIyNDIzNTk1OVowggEdMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTQwMgYDVQQLEytEaWdpdGFsIElEIENsYXNzIDEgLSBNaWNyb3NvZnQgRnVs bCBTZXJ2aWNlMRswGQYDVQQDFBJTaW1vbiBCbGFrZS1XaWxzb24xJjAkBgkqhkiG9w0BCQEWF3Ni bGFrZXdpbHNvbkBiY2lzc2UuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDN6+R2i/J/ txDR7EcMMo43UUJ8fcKREr4helpUy0hhHDWYVsX6UQuhocexOVyUyg0vCsYJGJOj+QMLDSwH1Xw5 8DuRyIFK8XkNcOTCxQ1xdPtnD91x29s8MVRLlkUp9+0v1y4D9Gzl/TL1ZyhvMbRwtHMWrkIZBaat qwORMHQehQIDAQABo4HLMIHIMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAzAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEFBQADgYEAipzxjTv6HdVgTktxvwN2jeI05aKsWuAjnJG3sdEY+jEiznR881t/YJOVWJJ4g8QG 8dISKvQALdH+1f0hIwFgBwVQ9qQhoVkOjU94Ypio5F1CAWdaIE9gB6BceZLsc8GOC6g7UJQ2lZDr BwoMaYSJ4XA7FWFwEUSNNhuUk9BLmNIxggQ+MIIEOgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNp Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgx SDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNv bmEgTm90IFZhbGlkYXRlZAIQNtryUCleST2NU0i9NVibsjAJBgUrDgMCGgUAoIICsjAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTEwMjYxNTAxMjlaMCMGCSqGSIb3 DQEJBDEWBBSlcvsFQhJwYJeI4tbJSxG3JcsC4TBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMH MAcGBSsOAwIaMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDAKBggqhkiG9w0CBTCB8gYJKwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3 LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5 ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVy c29uYSBOb3QgVmFsaWRhdGVkAhA22vJQKV5JPY1TSL01WJuyMIH0BgsqhkiG9w0BCRACCzGB5KCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBC eSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQNtryUCleST2NU0i9NVibsjAN BgkqhkiG9w0BAQEFAASBgG5IGcBRxcMq2VhYwv4gmcMgR7L6qJ0pzsMrdtNhQ4NE75JMzKmegf4X O0b4Re4mZdrZIqlUYZBQn3c5RnpH7CqFZ65zT/J/pf/0ypcklwEwD/ONKz9NiJxiPNgN2hJKolht zRFJcPj12o7Q953EQFSbkzr57zXZkShW2+BGRW6/AAAAAAAA ------=_NextPart_000_04DC_01C5DA1C.9DD441C0-- From owner-ietf-pkix@mail.imc.org Wed Oct 26 13:35:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUpBv-0004Wl-J5 for pkix-archive@megatron.ietf.org; Wed, 26 Oct 2005 13:35:59 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09334 for ; Wed, 26 Oct 2005 13:35:42 -0400 (EDT) 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 j9QGjXDG074191; Wed, 26 Oct 2005 09:45:33 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QGjXIW074190; Wed, 26 Oct 2005 09:45:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9QGjWEH074179 for ; Wed, 26 Oct 2005 09:45:33 -0700 (PDT) (envelope-from kent@bbn.com) 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 j9QGjMIG016631; Wed, 26 Oct 2005 12:45:25 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <7.0.0.10.2.20051025164030.061cdfb0@vigilsec.com> References: <7.0.0.10.2.20051025164030.061cdfb0@vigilsec.com> Date: Wed, 26 Oct 2005 12:45:24 -0400 To: Russ Housley From: Stephen Kent Subject: Re: Public key validation and Proof of possession Cc: ietf-pkix@imc.org 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: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, I think this is a good suggestion, and the extension should be a simple as you suggest. Relying on this being in a CP is asking a lot in management terms, as you noted. However, one might also address this by defining an IETF-standard CP that addresses just these issues, and allowing CAs to add that CP to whatever other CP that assert in an cert. How do you feel about that alternative? Steve From owner-ietf-pkix@mail.imc.org Wed Oct 26 15:33:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUr1a-0001XK-Cc for pkix-archive@megatron.ietf.org; Wed, 26 Oct 2005 15:33:26 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16933 for ; Wed, 26 Oct 2005 15:33:10 -0400 (EDT) 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 j9QInnEg088304; Wed, 26 Oct 2005 11:49:49 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QInnvR088303; Wed, 26 Oct 2005 11:49:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9QInl5R088296 for ; Wed, 26 Oct 2005 11:49:48 -0700 (PDT) (envelope-from tim.polk@nist.gov) 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 j9QInG0c030399; Wed, 26 Oct 2005 14:49:17 -0400 Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j9QIn5G4007441; Wed, 26 Oct 2005 14:49:08 -0400 (EDT) Message-Id: <5.1.0.14.2.20051026144124.040ce8d0@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 26 Oct 2005 14:52:50 -0400 To: denis.pinkas@bull.net From: Tim Polk Subject: RE: Public key validation and Proof of possession Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis,

I did a quick search for the offending statement in RFC 3280 as well as 3280bis, but could not find it.  Are you thinking of a statement in CMP or CRMF?

Thanks,

Tim


At 04:50 PM 10/26/2005 +0200, denis.pinkas@bull.net wrote:
Russ,

My previous reply was too concise.

YES, I am suportive of publicKeyValadation (0), but please also note as Security Area Director
that a change to 3280bis should also be done : POP should no more be mandated in any case.

Denis


Denis:

Are you speaking in support of the extension that I proposed?

Russ

At 09:11 AM 10/26/2005, denis.pinkas@bull.net wrote:

>Russ and Stefan,
>
>This is an interresting issue. Thanks for raising it.
>
>(text deleted)
>
>So since POP always MUST be performed by the CA there seems not to be
>the need for diverse policies (POP and non POP).
>
>Once upon a time, in the early years of PKI, RFC 2459 stated that
>sentence that was blindly copied from document to document.
>
>In these early years, most (if not all) security protocols were
>badly designed and thus for them to remains secure
>the only way was to include the MUST condition.
>
>However since then, the earth has rotated and at least there now
>exists one case where POP is no more needed without any security threat.
>
>This case was introduced by S/MIME with the optionally signed
>attribute ESSCertID.
>
>It was then taken by ETSI with the mandatory ESSCetrtID (or iis
>equivalent that does not mandate the use of SHA-1).
>
>RFC 3126 specifies that format.
>
>Taking into consideration these facts, this means that there exists
>at least one case where POP does not need to be performed anymore.
>
>There still exists cases where it needs to be performed, in
>particular when the certificate is used for encryption purposes.
>
>I believe that POP is mandatory when the key is used for encryption purposes.
>
>I believe that POP is NOT REQUIRED when the key is used for non
>repudiation purposes (e.g. RFC 3126 is used).
>
>When the key is used for authentication purposes, then depending
>upon the characteristics of the protocol,
>it MAY be required or not. So in that case only, it would make sense
>to support the extension proposed by Russ.
>
>Denis
>
>=============================================================================
>
>Do you agree with these observations or have I missed something?
>
>
>Stefan Santesson
>Program Manager, Standards Liaison
>Windows Security
>
>
> > -----Original Message-----
> > From: owner-ietf-pkix@mail.imc.org
>[mailto:owner-ietf-pkix@mail.imc.org]
> > On Behalf Of Russ Housley
> > Sent: den 25 oktober 2005 23:04
> > To: ietf-pkix@imc.org
> > Subject: Public key validation and Proof of possession
> >
> >
> > Dear PKIX WG:
> >
> > The draft NIST SP 800-56 defines the requirements for "Recipient
> > Assurance of Static Public Key Validity." See Section 5.6.2.2, where
>it
> > says:
> >
> > The recipient of a static public key shall obtain assurance of its
> > validity
> > in one or more of the following ways:
> >
> > 1. Recipient Full Validation - The recipient performs a
>successful
> > full
> > public key validation (see Sections 5.6.2.4 and 5.6.2.5).
> >
> > 2. TTP Full Validation - The recipient receives assurance that
>a
> > trusted
> > third party (trusted by the recipient) has performed a
> > successful full
> > public key validation (see Sections 5.6.2.4 and 5.6.2.5).
> >
> > 3. TTP Generation - The recipient receives assurance that a
> > trusted third
> > party (trusted by the recipient) has ge nerated the
> > public/private key
> > pair in accordance with Section 5.6.1 and has provided the
> > key pair to
> > the owner.
> >
> > It seems to me that option 2 was include to allow a CA to perform the
> > public key validation once, and then any party that makes use of the
> > certificate need not do it again. From a system performance
> > perspective, this seems highly desirable.
> >
> > In some highly assured implementation environments, it seems
> > desirable for there to me an indication in the certificate that this
> > action was taken by the CA. One could determine which certification
> > policies require the CA to take this action, but that means that the
> > list of certification policies would be continually adjusted by an
> > administrator. I would prefer a non-critical extension that declared
> > that this action was taken by the CA.
> >
> > The draft NIST SP 800-56, Section 5.6.3.2 discusses the requirement
> > for "Recipient Assurance of the Owner's Possession of a Static
> > Private Key." That is, the topic we have been discussing for years
> > on this list, calling it proof of possession. RFC 3647 includes a
> > place in the certification policy to discuss this topic. (RFC 3647,
> > Section 3.2.1: Method to prove possession of private key.)
> >
> > Again, in some highly assured implementation environments, it seems
> > desirable for there to me an indication in the certificate that proof
> > of possession was performed by the CA. I think it could be part of
> > the same non-critical extension proposed above.
> >
> > I therefore propose that the PKIX WG generate a standards-track RFC
> > to define a certificate extension to provide these indications. I
> > propose a very simple syntax:
> >
> > id-pe-caChecks OBJECT IDENTIFIER ::= { id-pe <TBD> }
> >
> > CAChecks ::= BIT STRING {
> > publicKeyValadation (0),
> > proofOfPossession (1) }
> >
> > Do others think this is a useful extension?
> >
> > Russ
>
From owner-ietf-pkix@mail.imc.org Wed Oct 26 15:37:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUr5q-00079X-FU for pkix-archive@megatron.ietf.org; Wed, 26 Oct 2005 15:37:50 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17134 for ; Wed, 26 Oct 2005 15:37:34 -0400 (EDT) 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 j9QIv3Cp089001; Wed, 26 Oct 2005 11:57:03 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QIv3WW089000; Wed, 26 Oct 2005 11:57:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9QIv2Fd088992 for ; Wed, 26 Oct 2005 11:57:02 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 21314 invoked by uid 0); 26 Oct 2005 18:56:55 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.181.94) by woodstock.binhost.com with SMTP; 26 Oct 2005 18:56:55 -0000 Message-Id: <7.0.0.10.2.20051026115805.05782370@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta) Date: Wed, 26 Oct 2005 12:11:20 -0400 To: "Simon Blake-Wilson" , From: Russ Housley Subject: RE: Public key validation and Proof of possession In-Reply-To: <04e001c5da3e$25cb11a0$0200a8c0@simon> References: <7.0.0.10.2.20051025164030.061cdfb0@vigilsec.com> <04e001c5da3e$25cb11a0$0200a8c0@simon> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Simon: I agree that the check need to be specified. And, we would require that successor documents to RFC 3279 would need to specify the criteria for setting the bit for that algorithm. In the development of ANSI X9.44, there was an informative annex on RSA Public-Key Validation and Plausibility Tests. I have not looked to see if it is in the most current version, but this is the checking that would be performed by the CA to set the bit. Russ At 11:01 AM 10/26/2005, Simon Blake-Wilson wrote: >Hi Russ, > >I have no problem with defining extensions for this, but I think it would >need to be made very clear somewhere what checks must be performed if the >public key validation extension is asserted. > >For DH for example, does it imply that subgroup membership ((g^x)^q=1 mod >p) has been checked? Not all protocols use subgroups for DH, do they? > >Other algorithms are harder. What exactly does public key validation for >RSA or NTRU or XYZ mean? > >I think the key here is that in some cases checking 0In others subgroup membership may also be needed. As a relying party I >need to know. > >I guess the checks that are performed could be specified in the CPS, but I >think it would be better put in the RFC itself. > >Best regards. Simon > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Russ Housley > > Sent: Tuesday, October 25, 2005 5:04 PM > > To: ietf-pkix@imc.org > > Subject: Public key validation and Proof of possession > > > > > > > > Dear PKIX WG: > > > > The draft NIST SP 800-56 defines the requirements for "Recipient > > Assurance of Static Public Key Validity." See Section > > 5.6.2.2, where it says: > > > > The recipient of a static public key shall obtain > > assurance of its validity > > in one or more of the following ways: > > > > 1. Recipient Full Validation - The recipient performs > > a successful full > > public key validation (see Sections 5.6.2.4 and 5.6.2.5). > > > > 2. TTP Full Validation - The recipient receives > > assurance that a trusted > > third party (trusted by the recipient) has performed a > > successful full > > public key validation (see Sections 5.6.2.4 and 5.6.2.5). > > > > 3. TTP Generation - The recipient receives assurance that a > > trusted third > > party (trusted by the recipient) has ge nerated the > > public/private key > > pair in accordance with Section 5.6.1 and has provided the > > key pair to > > the owner. > > > > It seems to me that option 2 was include to allow a CA to perform the > > public key validation once, and then any party that makes use of the > > certificate need not do it again. From a system performance > > perspective, this seems highly desirable. > > > > In some highly assured implementation environments, it seems > > desirable for there to me an indication in the certificate that this > > action was taken by the CA. One could determine which certification > > policies require the CA to take this action, but that means that the > > list of certification policies would be continually adjusted by an > > administrator. I would prefer a non-critical extension that declared > > that this action was taken by the CA. > > > > The draft NIST SP 800-56, Section 5.6.3.2 discusses the requirement > > for "Recipient Assurance of the Owner's Possession of a Static > > Private Key." That is, the topic we have been discussing for years > > on this list, calling it proof of possession. RFC 3647 includes a > > place in the certification policy to discuss this topic. (RFC 3647, > > Section 3.2.1: Method to prove possession of private key.) > > > > Again, in some highly assured implementation environments, it seems > > desirable for there to me an indication in the certificate that proof > > of possession was performed by the CA. I think it could be part of > > the same non-critical extension proposed above. > > > > I therefore propose that the PKIX WG generate a standards-track RFC > > to define a certificate extension to provide these indications. I > > propose a very simple syntax: > > > > id-pe-caChecks OBJECT IDENTIFIER ::= { id-pe } > > > > CAChecks ::= BIT STRING { > > publicKeyValadation (0), > > proofOfPossession (1) } > > > > Do others think this is a useful extension? > > > > Russ > > > > From owner-ietf-pkix@mail.imc.org Wed Oct 26 16:33:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUrxx-0000pa-3V for pkix-archive@megatron.ietf.org; Wed, 26 Oct 2005 16:33:45 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07194 for ; Wed, 26 Oct 2005 16:33:28 -0400 (EDT) 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 j9QJeqRk002749; Wed, 26 Oct 2005 12:40:52 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QJeqGR002748; Wed, 26 Oct 2005 12:40:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9QJeo6l002720 for ; Wed, 26 Oct 2005 12:40:51 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 32220 invoked by uid 0); 26 Oct 2005 19:40:44 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.238.33) by woodstock.binhost.com with SMTP; 26 Oct 2005 19:40:44 -0000 Message-Id: <7.0.0.10.2.20051026151352.05805b20@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta) Date: Wed, 26 Oct 2005 15:18:09 -0400 To: Stephen Kent From: Russ Housley Subject: Re: Public key validation and Proof of possession Cc: ietf-pkix@imc.org In-Reply-To: References: <7.0.0.10.2.20051025164030.061cdfb0@vigilsec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Steve: If I understand your proposal, you are suggesting a certificate policy OID that would be included in the certificate (in addition to any other certificate policy OID that is appropriate). This would be acceptable to me if it was only used in end-entity certificates. I think it could add complication to certificate policy mapping, which is already too messy. I note that the certificate policy OID does not offer the same granularity. The OID would only be included if the public key validation is performed and proof of possession is performed. Russ At 12:45 PM 10/26/2005, Stephen Kent wrote: >Russ, > >I think this is a good suggestion, and the extension should be a >simple as you suggest. Relying on this being in a CP is asking a >lot in management terms, as you noted. > >However, one might also address this by defining an IETF-standard CP >that addresses just these issues, and allowing CAs to add that CP to >whatever other CP that assert in an cert. How do you feel about >that alternative? > >Steve > From owner-ietf-pkix@mail.imc.org Wed Oct 26 18:04:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUtOA-0006FT-QF for pkix-archive@megatron.ietf.org; Wed, 26 Oct 2005 18:04:55 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29541 for ; Wed, 26 Oct 2005 18:04:37 -0400 (EDT) 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 j9QLO0IJ016401; Wed, 26 Oct 2005 14:24:00 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QLO07L016400; Wed, 26 Oct 2005 14:24:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9QLNxTN016388 for ; Wed, 26 Oct 2005 14:23:59 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Oct 2005 22:23:53 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Public key validation and Proof of possession Date: Wed, 26 Oct 2005 22:23:55 +0100 Message-ID: Thread-Topic: Public key validation and Proof of possession Thread-Index: AcXaVEuY1MpykbkXSEqSAAXbSHPD5AAHsNwA From: "Stefan Santesson" To: "Stephen Kent" , "Russ Housley" Cc: X-OriginalArrivalTime: 26 Oct 2005 21:23:53.0853 (UTC) FILETIME=[90FD22D0:01C5DA73] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j9QLO0TN016394 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Steve, Unfortunately this is not compliant with current path validation algorithm. When you test a certificate for a number of acceptable policies, path validation will accept the certificate if just one of these policies are supported by the path. There is no way to tell the standard path validation that a certificate is valid if a combination of policies are supported (e.g. IETF policy A + policy B) All policies expressed in a certificate must represent a complete policy declaration. Partial policies are not supported. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Stephen Kent > Sent: den 26 oktober 2005 18:45 > To: Russ Housley > Cc: ietf-pkix@imc.org > Subject: Re: Public key validation and Proof of possession > > > Russ, > > I think this is a good suggestion, and the extension should be a > simple as you suggest. Relying on this being in a CP is asking a lot > in management terms, as you noted. > > However, one might also address this by defining an IETF-standard CP > that addresses just these issues, and allowing CAs to add that CP to > whatever other CP that assert in an cert. How do you feel about that > alternative? > > Steve From owner-ietf-pkix@mail.imc.org Wed Oct 26 18:17:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUta7-0006cc-43 for pkix-archive@megatron.ietf.org; Wed, 26 Oct 2005 18:17:15 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00132 for ; Wed, 26 Oct 2005 18:16:58 -0400 (EDT) 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 j9QLbQw2018325; Wed, 26 Oct 2005 14:37:26 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QLbQOv018324; Wed, 26 Oct 2005 14:37:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9QLbPeV018317 for ; Wed, 26 Oct 2005 14:37:26 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Oct 2005 22:37:20 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Public key validation and Proof of possession Date: Wed, 26 Oct 2005 22:37:22 +0100 Message-ID: Thread-Topic: Public key validation and Proof of possession Thread-Index: AcXaMvyB6IsXcki9TCuQLks9qw9ECwAQK2rA From: "Stefan Santesson" To: "Russ Housley" , X-OriginalArrivalTime: 26 Oct 2005 21:37:20.0104 (UTC) FILETIME=[718D4680:01C5DA75] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j9QLbQeV018319 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Russ, I'm concerned that we are about to enter a dangerous path if we start defining extensions for policy aspects. If we open this can, there are many other potential candidates for policy expression extensions and I'm not sure we will help the deployment community by going down that path. I think this needs careful consideration and I'm not sure the benefit of this extension is worth the cost. My thought is that arithmetic property validation seems feasible even in a smart card today and even more, this test can easily be done in the system in which the smart card is used. Computation power is exponentially increasing and before this extension is generally adopted, this might very well be a completely redundant issue. POP of encryption keys seems to be such a generic requirement for CAs that even policy enforcement through trust anchor chaining might be sufficient in most cases. I think it would be good to have some discussions in Vancouver if this can be fitted into the pkix agenda. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: den 26 oktober 2005 15:39 > To: Stefan Santesson; ietf-pkix@imc.org > Subject: RE: Public key validation and Proof of possession > > Stefan: > > >On public key validation (arithmetic properties): > >It seems to me that the key validation tests specified in 5.6.2.4 and > >5.6.2.5 are rather trivial to do locally ( 2= >for FFC), at least compared to the cost of using this key for anything > >useful. I wonder if the cost of making this test isn't actually lower > >than parsing the certificate to obtain the assurance from the CA. > > In low power devices (such as smartcards), avoiding the y^q > exponentiation because the relying party is sure that the CA has > already performed this check seems useful. > > >On Proof-of-possession: > >Section 5.6.3. of SP 800-56 states: > >"For example, this Recommendation requires that parties obtain assurance > >that they actually possess their own static private keys, and a binding > >authority is required to obtain assurance of an owner's possession of > >the appropriate static private key before binding an identifier to the > >owner's static public key." > > > >So since POP always MUST be performed by the CA there seems not to be > >the need for diverse policies (POP and non POP). > > > >Do you agree with these observations or have I missed something? > > If the first idea is accepted, the proposed extension is no larger by > adding the additional bit to indicate that the CA performed POP. The > positive statement could be useful. > > Russ From owner-ietf-pkix@mail.imc.org Wed Oct 26 19:29:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUuhn-00033b-IM for pkix-archive@megatron.ietf.org; Wed, 26 Oct 2005 19:29:15 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20585 for ; Wed, 26 Oct 2005 19:28:58 -0400 (EDT) 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 j9QMo2Hi025343; Wed, 26 Oct 2005 15:50:02 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QMo2Rf025342; Wed, 26 Oct 2005 15:50:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9QMo1Na025334 for ; Wed, 26 Oct 2005 15:50:02 -0700 (PDT) (envelope-from mlee@newodin.ietf.org) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EUu5p-0005Ys-C3; Wed, 26 Oct 2005 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-cmc-trans-04.txt Message-Id: Date: Wed, 26 Oct 2005 18:50:01 -0400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Certificate Management over CMS (CMC) Transport Protocols Author(s) : J. Schaad, M. Myers Filename : draft-ietf-pkix-cmc-trans-04.txt Pages : 7 Date : 2005-10-26 This document defines a number of transport mechanisms that are used to move CMC (Certificate Managment over CMS (Cryptographic Message Syntax)) messages. The transport mechanisms described in this document are: HTTP, file, mail and TCP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmc-trans-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-cmc-trans-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-cmc-trans-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-26154458.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-cmc-trans-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-cmc-trans-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-26154458.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix@mail.imc.org Wed Oct 26 21:09:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUwGt-00060Q-GH for pkix-archive@megatron.ietf.org; Wed, 26 Oct 2005 21:09:35 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12408 for ; Wed, 26 Oct 2005 21:09:20 -0400 (EDT) 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 j9R0KjEq035697; Wed, 26 Oct 2005 17:20:45 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9R0KjZG035696; Wed, 26 Oct 2005 17:20:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9R0Ki7d035671 for ; Wed, 26 Oct 2005 17:20:45 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [10.84.130.29] (dommiel.bbn.com [192.1.122.15]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j9R0KaIG009599; Wed, 26 Oct 2005 20:20:38 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <7.0.0.10.2.20051026151352.05805b20@vigilsec.com> References: <7.0.0.10.2.20051025164030.061cdfb0@vigilsec.com> <7.0.0.10.2.20051026151352.05805b20@vigilsec.com> Date: Wed, 26 Oct 2005 20:17:33 -0400 To: Russ Housley From: Stephen Kent Subject: Re: Public key validation and Proof of possession Cc: ietf-pkix@imc.org 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: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 3:18 PM -0400 10/26/05, Russ Housley wrote: >Steve: > >If I understand your proposal, you are suggesting a certificate >policy OID that would be included in the certificate (in addition to >any other certificate policy OID that is appropriate). This would >be acceptable to me if it was only used in end-entity certificates. >I think it could add complication to certificate policy mapping, >which is already too messy. > >I note that the certificate policy OID does not offer the same >granularity. The OID would only be included if the public key >validation is performed and proof of possession is performed. > >Russ > I envisioned two policies, one for each of PoP and PKV. However, If Stefan's observation about policies is correct (I admit to having not checked first), then this is not a viable alternative to your proposal, even independent of the policy mapping complexity concerns your cited. Steve From owner-ietf-pkix@mail.imc.org Thu Oct 27 07:13:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV5hh-0004MQ-Tm for pkix-archive@megatron.ietf.org; Thu, 27 Oct 2005 07:13:54 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21848 for ; Thu, 27 Oct 2005 07:13:36 -0400 (EDT) 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 j9RAOJpI093580; Thu, 27 Oct 2005 03:24:19 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9RAOJJq093579; Thu, 27 Oct 2005 03:24:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9RAOH7j093556 for ; Thu, 27 Oct 2005 03:24:18 -0700 (PDT) (envelope-from denis.pinkas@bull.net) 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 MAA16652; Thu, 27 Oct 2005 12:41:31 +0200 Importance: Normal X-Priority: 3 (Normal) Subject: RE: Public key validation and Proof of possession MIME-Version: 1.0 From: denis.pinkas@bull.net To: Tim Polk Cc: ietf-pkix@imc.org Date: Thu, 27 Oct 2005 12:24:49 +0200 Message-ID: X-MIMETrack: Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 27/10/2005 12:24:50 MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: base64 PEZPTlQgZmFjZT0iRGVmYXVsdCBTYW5zIFNlcmlmLCBWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNh LCBzYW5zLXNlcmlmIiBzaXplPTI+PFA+PEJSPkRlbmlzLDxicj48YnI+SSBkaWQgYSBxdWljayBz ZWFyY2ggZm9yIHRoZSBvZmZlbmRpbmcgc3RhdGVtZW50IGluIFJGQyAzMjgwIGFzIHdlbGwgYXMz MjgwYmlzLCBidXQgY291bGQgbm90IGZpbmQgaXQuJm5ic3A7IEFyZSB5b3UgdGhpbmtpbmcgb2Yg YSBzdGF0ZW1lbnQgaW5DTVAgb3IgQ1JNRj88YnI+PC9QPjxQPj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT08L1A+PFA+U29ycnkuIE15IG1pc3Rha2UuIEl0IHdhcyBS RkMgNDIxMCAoQ01QKSB0aGF0IHN0YXRlcyA6PC9QPjxQPiJIb3dldmVyLCBpdCBpcyBSRVFVSVJF RCB0aGF0IENBcy9SQXMgTVVTVCBlbmZvcmNlIFBPUCBieSBzb21lIG1lYW5zIGJlY2F1c2UgdGhl cmUgYXJlIGN1cnJlbnRseTxCUj5tYW55IG5vbi1QS0lYIG9wZXJhdGlvbmFsIHByb3RvY29scyBp biB1c2UgKHZhcmlvdXMgZWxlY3Ryb25pYyBtYWlsIHByb3RvY29scyBhcmUgb25lIGV4YW1wbGUp IDxCUj50aGF0IGRvIG5vdCBleHBsaWNpdGx5IGNoZWNrIHRoZSBiaW5kaW5nIGJldHdlZW4gdGhl IGVuZCBlbnRpdHkgYW5kIHRoZSBwcml2YXRlIGtleS48U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVu OiB5ZXMiPiZuYnNwOyA8QlI+PC9TUEFOPlVudGlsIG9wZXJhdGlvbmFsIHByb3RvY29scyB0aGF0 IGRvIHZlcmlmeSB0aGUgYmluZGluZyAoZm9yIHNpZ25hdHVyZSwgZW5jcnlwdGlvbiwgYW5kIGtl eSBhZ3JlZW1lbnQga2V5IHBhaXJzKSBleGlzdCwgPEJSPmFuZCBhcmUgdWJpcXVpdG91cywgdGhp cyBiaW5kaW5nIGNhbiBvbmx5IGJlIGFzc3VtZWQgdG8gaGF2ZSBiZWVuIHZlcmlmaWVkIGJ5IHRo ZSBDQS9SQS4iPC9QPjxQPlRodXMgbm8gImNoYW5nZSIgcmVxdWlyZWQmbmJzcDtpbiZuYnNwOzMy ODBiaXMsIGJ1dCBvbmx5IGFuIGFkZGl0aW9uLjwvUD48UD5EZW5pczwvUD48UD49PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9QPjxQPlRoYW5rcyw8YnI+PGJyPlRp bTxicj48YnI+PGJyPkF0IDA0OjUwIFBNIDEwLzI2LzIwMDUgKzAyMDAsIGRlbmlzLnBpbmthc0Bi dWxsLm5ldCB3cm90ZTo8YnI+PC9QPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPWNpdGUg Y2l0ZT0iIj48Zm9udCBmYWNlPSJWZXJkYW5hIiBzaXplPTIgY29sb3I9IiMwMDk5MDAiPlJ1c3Ms PC9mb250Pjxmb250IGZhY2U9IlZlcmRhbmEiIHNpemU9Mj48YnI+PGJyPjwvZm9udD48Zm9udCBm YWNlPSJWZXJkYW5hIiBzaXplPTIgY29sb3I9IiMwMDk5MDAiPk15IHByZXZpb3VzIHJlcGx5IHdh c3RvbyBjb25jaXNlLjxicj48L2ZvbnQ+PGZvbnQgZmFjZT0iVmVyZGFuYSIgc2l6ZT0yPjxicj48 L2ZvbnQ+PGZvbnQgZmFjZT0iVmVyZGFuYSIgc2l6ZT0yIGNvbG9yPSIjMDA5OTAwIj5ZRVMsIEkg YW0gc3Vwb3J0aXZlIG9mcHVibGljS2V5VmFsYWRhdGlvbiAoMCksIGJ1dCBwbGVhc2UgYWxzbyBu b3RlIGFzIFNlY3VyaXR5IEFyZWFEaXJlY3Rvcjxicj50aGF0IGEgY2hhbmdlIHRvIDMyODBiaXMg c2hvdWxkIGFsc28gYmUgZG9uZSA6IFBPUCBzaG91bGQgbm8gbW9yZSBiZW1hbmRhdGVkIGluIGFu eSBjYXNlLjxicj48L2ZvbnQ+PGZvbnQgZmFjZT0iVmVyZGFuYSIgc2l6ZT0yPjxicj48L2ZvbnQ+ PGZvbnQgZmFjZT0iVmVyZGFuYSIgc2l6ZT0yIGNvbG9yPSIjMDA5OTAwIj5EZW5pczxicj48L2Zv bnQ+PGZvbnQgZmFjZT0iVmVyZGFuYSIgc2l6ZT0yPjxicj48YnI+RGVuaXM6PGJyPjxicj5BcmUg eW91IHNwZWFraW5nIGluIHN1cHBvcnQgb2YgdGhlIGV4dGVuc2lvbiB0aGF0IEkgcHJvcG9zZWQ/ PGJyPjxicj5SdXNzPGJyPjxicj5BdCAwOToxMSBBTSAxMC8yNi8yMDA1LCBkZW5pcy5waW5rYXNA YnVsbC5uZXQgd3JvdGU6PGJyPjxicj4mZ3Q7UnVzcyBhbmQgU3RlZmFuLDxicj4mZ3Q7PGJyPiZn dDtUaGlzIGlzIGFuIGludGVycmVzdGluZyBpc3N1ZS4gVGhhbmtzIGZvciByYWlzaW5nIGl0Ljxi cj4mZ3Q7PGJyPiZndDsodGV4dCBkZWxldGVkKTxicj4mZ3Q7PGJyPiZndDtTbyBzaW5jZSBQT1Ag YWx3YXlzIE1VU1QgYmUgcGVyZm9ybWVkIGJ5IHRoZSBDQSB0aGVyZSBzZWVtcyBub3QgdG9iZTxi cj4mZ3Q7dGhlIG5lZWQgZm9yIGRpdmVyc2UgcG9saWNpZXMgKFBPUCBhbmQgbm9uIFBPUCkuPGJy PiZndDs8YnI+Jmd0O09uY2UgdXBvbiBhIHRpbWUsIGluIHRoZSBlYXJseSB5ZWFycyBvZiBQS0ks IFJGQyAyNDU5IHN0YXRlZCB0aGF0PGJyPiZndDtzZW50ZW5jZSB0aGF0IHdhcyBibGluZGx5IGNv cGllZCBmcm9tIGRvY3VtZW50IHRvIGRvY3VtZW50Ljxicj4mZ3Q7PGJyPiZndDtJbiB0aGVzZSBl YXJseSB5ZWFycywgbW9zdCAoaWYgbm90IGFsbCkgc2VjdXJpdHkgcHJvdG9jb2xzIHdlcmUgPGJy PiZndDtiYWRseSBkZXNpZ25lZCBhbmQgdGh1cyBmb3IgdGhlbSB0byByZW1haW5zIHNlY3VyZTxi cj4mZ3Q7dGhlIG9ubHkgd2F5IHdhcyB0byBpbmNsdWRlIHRoZSBNVVNUIGNvbmRpdGlvbi48YnI+ Jmd0Ozxicj4mZ3Q7SG93ZXZlciBzaW5jZSB0aGVuLCB0aGUgZWFydGggaGFzIHJvdGF0ZWQgYW5k IGF0IGxlYXN0IHRoZXJlIG5vdzxicj4mZ3Q7ZXhpc3RzIG9uZSBjYXNlIHdoZXJlIFBPUCBpcyBu byBtb3JlIG5lZWRlZCB3aXRob3V0IGFueSBzZWN1cml0eXRocmVhdC48YnI+Jmd0Ozxicj4mZ3Q7 VGhpcyBjYXNlIHdhcyBpbnRyb2R1Y2VkIGJ5IFMvTUlNRSB3aXRoIHRoZSBvcHRpb25hbGx5IHNp Z25lZCA8YnI+Jmd0O2F0dHJpYnV0ZSBFU1NDZXJ0SUQuPGJyPiZndDs8YnI+Jmd0O0l0IHdhcyB0 aGVuIHRha2VuIGJ5IEVUU0kgd2l0aCB0aGUgbWFuZGF0b3J5IEVTU0NldHJ0SUQgKG9yIGlpcyA8 YnI+Jmd0O2VxdWl2YWxlbnQgdGhhdCBkb2VzIG5vdCBtYW5kYXRlIHRoZSB1c2Ugb2YgU0hBLTEp Ljxicj4mZ3Q7PGJyPiZndDtSRkMgMzEyNiBzcGVjaWZpZXMgdGhhdCBmb3JtYXQuPGJyPiZndDs8 YnI+Jmd0O1Rha2luZyBpbnRvIGNvbnNpZGVyYXRpb24gdGhlc2UgZmFjdHMsIHRoaXMgbWVhbnMg dGhhdCB0aGVyZSBleGlzdHM8YnI+Jmd0O2F0IGxlYXN0IG9uZSBjYXNlIHdoZXJlIFBPUCBkb2Vz IG5vdCBuZWVkIHRvIGJlIHBlcmZvcm1lZGFueW1vcmUuPGJyPiZndDs8YnI+Jmd0O1RoZXJlIHN0 aWxsIGV4aXN0cyBjYXNlcyB3aGVyZSBpdCBuZWVkcyB0byBiZSBwZXJmb3JtZWQsIGluIDxicj4m Z3Q7cGFydGljdWxhciB3aGVuIHRoZSBjZXJ0aWZpY2F0ZSBpcyB1c2VkIGZvciBlbmNyeXB0aW9u IHB1cnBvc2VzLjxicj4mZ3Q7PGJyPiZndDtJIGJlbGlldmUgdGhhdCBQT1AgaXMgbWFuZGF0b3J5 IHdoZW4gdGhlIGtleSBpcyB1c2VkIGZvciBlbmNyeXB0aW9ucHVycG9zZXMuPGJyPiZndDs8YnI+ Jmd0O0kgYmVsaWV2ZSB0aGF0IFBPUCBpcyBOT1QgUkVRVUlSRUQgd2hlbiB0aGUga2V5IGlzIHVz ZWQgZm9yIG5vbiA8YnI+Jmd0O3JlcHVkaWF0aW9uIHB1cnBvc2VzIChlLmcuIFJGQyAzMTI2IGlz IHVzZWQpLjxicj4mZ3Q7PGJyPiZndDtXaGVuIHRoZSBrZXkgaXMgdXNlZCBmb3IgYXV0aGVudGlj YXRpb24gcHVycG9zZXMsIHRoZW4gZGVwZW5kaW5nPGJyPiZndDt1cG9uIHRoZSBjaGFyYWN0ZXJp c3RpY3Mgb2YgdGhlIHByb3RvY29sLDxicj4mZ3Q7aXQgTUFZIGJlIHJlcXVpcmVkIG9yIG5vdC4g U28gaW4gdGhhdCBjYXNlIG9ubHksIGl0IHdvdWxkIG1ha2Ugc2Vuc2U8YnI+Jmd0O3RvIHN1cHBv cnQgdGhlIGV4dGVuc2lvbiBwcm9wb3NlZCBieSBSdXNzLjxicj4mZ3Q7PGJyPiZndDtEZW5pczxi cj4mZ3Q7PGJyPiZndDs9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4mZ3Q7PGJyPiZndDtEbyB5b3Ug YWdyZWUgd2l0aCB0aGVzZSBvYnNlcnZhdGlvbnMgb3IgaGF2ZSBJIG1pc3NlZCBzb21ldGhpbmc/ PGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7U3RlZmFuIFNhbnRlc3Nvbjxicj4mZ3Q7UHJvZ3JhbSBN YW5hZ2VyLCBTdGFuZGFyZHMgTGlhaXNvbjxicj4mZ3Q7V2luZG93cyBTZWN1cml0eTxicj4mZ3Q7 PGJyPiZndDs8YnI+Jmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPiZndDsg Jmd0OyBGcm9tOiBvd25lci1pZXRmLXBraXhAbWFpbC5pbWMub3JnPGJyPiZndDtbPEEgaHJlZj0i bWFpbHRvOm93bmVyLWlldGYtcGtpeEBtYWlsLmltYy5vcmciIHRhcmdldD1ibGFuayAgZXVkb3Jh PSJhdXRvdXJsIj5tYWlsdG86b3duZXItaWV0Zi1wa2l4QG1haWwuaW1jLm9yZzwvYT5dPGJyPiZn dDsgJmd0OyBPbiBCZWhhbGYgT2YgUnVzcyBIb3VzbGV5PGJyPiZndDsgJmd0OyBTZW50OiBkZW4g MjUgb2t0b2JlciAyMDA1IDIzOjA0PGJyPiZndDsgJmd0OyBUbzogaWV0Zi1wa2l4QGltYy5vcmc8 YnI+Jmd0OyAmZ3Q7IFN1YmplY3Q6IFB1YmxpYyBrZXkgdmFsaWRhdGlvbiBhbmQgUHJvb2Ygb2Yg cG9zc2Vzc2lvbjxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyBEZWFyIFBL SVggV0c6PGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgVGhlIGRyYWZ0IE5JU1QgU1AgODAwLTU2 IGRlZmluZXMgdGhlIHJlcXVpcmVtZW50cyBmb3IiUmVjaXBpZW50PGJyPiZndDsgJmd0OyBBc3N1 cmFuY2Ugb2YgU3RhdGljIFB1YmxpYyBLZXkgVmFsaWRpdHkuIiBTZWUgU2VjdGlvbjUuNi4yLjIs IHdoZXJlPGJyPiZndDtpdDxicj4mZ3Q7ICZndDsgc2F5czo8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsg Jmd0OyBUaGUgcmVjaXBpZW50IG9mIGEgc3RhdGljIHB1YmxpYyBrZXkgc2hhbGwgb2J0YWluIGFz c3VyYW5jZSBvZml0czxicj4mZ3Q7ICZndDsgdmFsaWRpdHk8YnI+Jmd0OyAmZ3Q7IGluIG9uZSBv ciBtb3JlIG9mIHRoZSBmb2xsb3dpbmcgd2F5czo8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyAx LiBSZWNpcGllbnQgRnVsbCBWYWxpZGF0aW9uIC0gVGhlIHJlY2lwaWVudCBwZXJmb3JtcyBhPGJy PiZndDtzdWNjZXNzZnVsPGJyPiZndDsgJmd0OyBmdWxsPGJyPiZndDsgJmd0OyBwdWJsaWMga2V5 IHZhbGlkYXRpb24gKHNlZSBTZWN0aW9ucyA1LjYuMi40IGFuZCA1LjYuMi41KS48YnI+Jmd0OyAm Z3Q7PGJyPiZndDsgJmd0OyAyLiBUVFAgRnVsbCBWYWxpZGF0aW9uIC0gVGhlIHJlY2lwaWVudCBy ZWNlaXZlcyBhc3N1cmFuY2V0aGF0PGJyPiZndDthPGJyPiZndDsgJmd0OyB0cnVzdGVkPGJyPiZn dDsgJmd0OyB0aGlyZCBwYXJ0eSAodHJ1c3RlZCBieSB0aGUgcmVjaXBpZW50KSBoYXMgcGVyZm9y bWVkIGE8YnI+Jmd0OyAmZ3Q7IHN1Y2Nlc3NmdWwgZnVsbDxicj4mZ3Q7ICZndDsgcHVibGljIGtl eSB2YWxpZGF0aW9uIChzZWUgU2VjdGlvbnMgNS42LjIuNCBhbmQgNS42LjIuNSkuPGJyPiZndDsg Jmd0Ozxicj4mZ3Q7ICZndDsgMy4gVFRQIEdlbmVyYXRpb24gLSBUaGUgcmVjaXBpZW50IHJlY2Vp dmVzIGFzc3VyYW5jZSB0aGF0YTxicj4mZ3Q7ICZndDsgdHJ1c3RlZCB0aGlyZDxicj4mZ3Q7ICZn dDsgcGFydHkgKHRydXN0ZWQgYnkgdGhlIHJlY2lwaWVudCkgaGFzIGdlIG5lcmF0ZWQgdGhlPGJy PiZndDsgJmd0OyBwdWJsaWMvcHJpdmF0ZSBrZXk8YnI+Jmd0OyAmZ3Q7IHBhaXIgaW4gYWNjb3Jk YW5jZSB3aXRoIFNlY3Rpb24gNS42LjEgYW5kIGhhcyBwcm92aWRlZCB0aGU8YnI+Jmd0OyAmZ3Q7 IGtleSBwYWlyIHRvPGJyPiZndDsgJmd0OyB0aGUgb3duZXIuPGJyPiZndDsgJmd0Ozxicj4mZ3Q7 ICZndDsgSXQgc2VlbXMgdG8gbWUgdGhhdCBvcHRpb24gMiB3YXMgaW5jbHVkZSB0byBhbGxvdyBh IENBIHRvcGVyZm9ybSB0aGU8YnI+Jmd0OyAmZ3Q7IHB1YmxpYyBrZXkgdmFsaWRhdGlvbiBvbmNl LCBhbmQgdGhlbiBhbnkgcGFydHkgdGhhdCBtYWtlcyB1c2VvZiB0aGU8YnI+Jmd0OyAmZ3Q7IGNl cnRpZmljYXRlIG5lZWQgbm90IGRvIGl0IGFnYWluLiBGcm9tIGEgc3lzdGVtcGVyZm9ybWFuY2U8 YnI+Jmd0OyAmZ3Q7IHBlcnNwZWN0aXZlLCB0aGlzIHNlZW1zIGhpZ2hseSBkZXNpcmFibGUuPGJy PiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgSW4gc29tZSBoaWdobHkgYXNzdXJlZCBpbXBsZW1lbnRh dGlvbiBlbnZpcm9ubWVudHMsIGl0c2VlbXM8YnI+Jmd0OyAmZ3Q7IGRlc2lyYWJsZSBmb3IgdGhl cmUgdG8gbWUgYW4gaW5kaWNhdGlvbiBpbiB0aGUgY2VydGlmaWNhdGUgdGhhdHRoaXM8YnI+Jmd0 OyAmZ3Q7IGFjdGlvbiB3YXMgdGFrZW4gYnkgdGhlIENBLiBPbmUgY291bGQgZGV0ZXJtaW5lIHdo aWNoY2VydGlmaWNhdGlvbjxicj4mZ3Q7ICZndDsgcG9saWNpZXMgcmVxdWlyZSB0aGUgQ0EgdG8g dGFrZSB0aGlzIGFjdGlvbiwgYnV0IHRoYXQgbWVhbnN0aGF0IHRoZTxicj4mZ3Q7ICZndDsgbGlz dCBvZiBjZXJ0aWZpY2F0aW9uIHBvbGljaWVzIHdvdWxkIGJlIGNvbnRpbnVhbGx5IGFkanVzdGVk IGJ5YW48YnI+Jmd0OyAmZ3Q7IGFkbWluaXN0cmF0b3IuIEkgd291bGQgcHJlZmVyIGEgbm9uLWNy aXRpY2FsIGV4dGVuc2lvbiB0aGF0ZGVjbGFyZWQ8YnI+Jmd0OyAmZ3Q7IHRoYXQgdGhpcyBhY3Rp b24gd2FzIHRha2VuIGJ5IHRoZSBDQS48YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyBUaGUgZHJh ZnQgTklTVCBTUCA4MDAtNTYsIFNlY3Rpb24gNS42LjMuMiBkaXNjdXNzZXMgdGhlcmVxdWlyZW1l bnQ8YnI+Jmd0OyAmZ3Q7IGZvciAiUmVjaXBpZW50IEFzc3VyYW5jZSBvZiB0aGUgT3duZXIncyBQ b3NzZXNzaW9uIG9mIGFTdGF0aWM8YnI+Jmd0OyAmZ3Q7IFByaXZhdGUgS2V5LiIgVGhhdCBpcywg dGhlIHRvcGljIHdlIGhhdmUgYmVlbiBkaXNjdXNzaW5nZm9yIHllYXJzPGJyPiZndDsgJmd0OyBv biB0aGlzIGxpc3QsIGNhbGxpbmcgaXQgcHJvb2Ygb2YgcG9zc2Vzc2lvbi4gUkZDIDM2NDcgaW5j bHVkZXNhPGJyPiZndDsgJmd0OyBwbGFjZSBpbiB0aGUgY2VydGlmaWNhdGlvbiBwb2xpY3kgdG8g ZGlzY3VzcyB0aGlzIHRvcGljLiAoUkZDMzY0Nyw8YnI+Jmd0OyAmZ3Q7IFNlY3Rpb24gMy4yLjE6 IE1ldGhvZCB0byBwcm92ZSBwb3NzZXNzaW9uIG9mIHByaXZhdGUga2V5Lik8YnI+Jmd0OyAmZ3Q7 PGJyPiZndDsgJmd0OyBBZ2FpbiwgaW4gc29tZSBoaWdobHkgYXNzdXJlZCBpbXBsZW1lbnRhdGlv biBlbnZpcm9ubWVudHMsIGl0c2VlbXM8YnI+Jmd0OyAmZ3Q7IGRlc2lyYWJsZSBmb3IgdGhlcmUg dG8gbWUgYW4gaW5kaWNhdGlvbiBpbiB0aGUgY2VydGlmaWNhdGUgdGhhdHByb29mPGJyPiZndDsg Jmd0OyBvZiBwb3NzZXNzaW9uIHdhcyBwZXJmb3JtZWQgYnkgdGhlIENBLiBJIHRoaW5rIGl0IGNv dWxkIGJlIHBhcnRvZjxicj4mZ3Q7ICZndDsgdGhlIHNhbWUgbm9uLWNyaXRpY2FsIGV4dGVuc2lv biBwcm9wb3NlZCBhYm92ZS48YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyBJIHRoZXJlZm9yZSBw cm9wb3NlIHRoYXQgdGhlIFBLSVggV0cgZ2VuZXJhdGUgYSBzdGFuZGFyZHMtdHJhY2tSRkM8YnI+ Jmd0OyAmZ3Q7IHRvIGRlZmluZSBhIGNlcnRpZmljYXRlIGV4dGVuc2lvbiB0byBwcm92aWRlIHRo ZXNlIGluZGljYXRpb25zLkk8YnI+Jmd0OyAmZ3Q7IHByb3Bvc2UgYSB2ZXJ5IHNpbXBsZSBzeW50 YXg6PGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgaWQtcGUtY2FDaGVja3MgT0JKRUNUIElERU5U SUZJRVIgOjo9IHsgaWQtcGUgJmx0O1RCRCZndDsgfTxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7 IENBQ2hlY2tzIDo6PSAgICBCSVQgU1RSSU5HIHs8YnI+Jmd0OyAmZ3Q7IHB1YmxpY0tleVZhbGFk YXRpb24gKDApLDxicj4mZ3Q7ICZndDsgcHJvb2ZPZlBvc3Nlc3Npb24gKDEpIH08YnI+Jmd0OyAm Z3Q7PGJyPiZndDsgJmd0OyBEbyBvdGhlcnMgdGhpbmsgdGhpcyBpcyBhIHVzZWZ1bCBleHRlbnNp b24/PGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgUnVzczxicj4mZ3Q7PGJyPjwvZm9udD48L2Js b2NrcXVvdGU+PC9GT05UPg== From owner-ietf-pkix@mail.imc.org Thu Oct 27 10:32:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV8nm-0007F0-Pq for pkix-archive@megatron.ietf.org; Thu, 27 Oct 2005 10:32:22 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03161 for ; Thu, 27 Oct 2005 10:32:05 -0400 (EDT) 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 j9RDb94E012251; Thu, 27 Oct 2005 06:37:09 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9RDb9Wc012250; Thu, 27 Oct 2005 06:37:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9RDb8L1012240 for ; Thu, 27 Oct 2005 06:37:08 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 14486 invoked by uid 0); 27 Oct 2005 13:37:04 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.238.33) by woodstock.binhost.com with SMTP; 27 Oct 2005 13:37:04 -0000 Message-Id: <7.0.0.10.2.20051027092241.05814258@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta) Date: Thu, 27 Oct 2005 09:37:03 -0400 To: "Stefan Santesson" , From: Russ Housley Subject: RE: Public key validation and Proof of possession In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stefan: I think that there will always be low end devices. Consider the history. - Personal computers used to be very simple systems, especially before the IBM PC. Remember the Intel 8080? A very large machine had 32 Kbytes of RAM, and non-volatile storage was 8-inch floppy disk. - Hand-held computers were originally very low-end computers. They have come a long way, and the power management has significantly helped with battery life. - Mobile phones did not really include Internet capabilities at first, but when they were added, WAP was used to accommodate the low-end processing environment. When 32-bit processors appeared in mobile phones, mainstream Internet protocols were used in favor of WAP. - Smartcards are still low-end processors. As you point out, they are getting more powerful all the time. - RFID are very low-power devices. I'm sure that more capabilities will be added over time. But right now, certificate parsing and validation is probably beyond their capabilities. As they become more capable, I think that certificate-based protocols are appropriate in this environment. In summary, I do not think it is unreasonable to consider features for low-end devices. I believe that there will always be new low-end devices appearing, and at some point they may need to handle certificates. Russ At 05:37 PM 10/26/2005, Stefan Santesson wrote: >Russ, > >I'm concerned that we are about to enter a dangerous path if we start >defining extensions for policy aspects. If we open this can, there are >many other potential candidates for policy expression extensions and I'm >not sure we will help the deployment community by going down that path. > >I think this needs careful consideration and I'm not sure the benefit of >this extension is worth the cost. > >My thought is that arithmetic property validation seems feasible even in >a smart card today and even more, this test can easily be done in the >system in which the smart card is used. Computation power is >exponentially increasing and before this extension is generally adopted, >this might very well be a completely redundant issue. > >POP of encryption keys seems to be such a generic requirement for CAs >that even policy enforcement through trust anchor chaining might be >sufficient in most cases. > >I think it would be good to have some discussions in Vancouver if this >can be fitted into the pkix agenda. > > >Stefan Santesson >Program Manager, Standards Liaison >Windows Security > > > > -----Original Message----- > > From: Russ Housley [mailto:housley@vigilsec.com] > > Sent: den 26 oktober 2005 15:39 > > To: Stefan Santesson; ietf-pkix@imc.org > > Subject: RE: Public key validation and Proof of possession > > > > Stefan: > > > > >On public key validation (arithmetic properties): > > >It seems to me that the key validation tests specified in 5.6.2.4 and > > >5.6.2.5 are rather trivial to do locally ( 2= > >for FFC), at least compared to the cost of using this key for >anything > > >useful. I wonder if the cost of making this test isn't actually lower > > >than parsing the certificate to obtain the assurance from the CA. > > > > In low power devices (such as smartcards), avoiding the y^q > > exponentiation because the relying party is sure that the CA has > > already performed this check seems useful. > > > > >On Proof-of-possession: > > >Section 5.6.3. of SP 800-56 states: > > >"For example, this Recommendation requires that parties obtain >assurance > > >that they actually possess their own static private keys, and a >binding > > >authority is required to obtain assurance of an owner's possession of > > >the appropriate static private key before binding an identifier to >the > > >owner's static public key." > > > > > >So since POP always MUST be performed by the CA there seems not to be > > >the need for diverse policies (POP and non POP). > > > > > >Do you agree with these observations or have I missed something? > > > > If the first idea is accepted, the proposed extension is no larger by > > adding the additional bit to indicate that the CA performed POP. The > > positive statement could be useful. > > > > Russ From owner-ietf-pkix@mail.imc.org Thu Oct 27 13:01:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVB7s-0003y3-I8 for pkix-archive@megatron.ietf.org; Thu, 27 Oct 2005 13:01:16 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15588 for ; Thu, 27 Oct 2005 13:00:58 -0400 (EDT) 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 j9RFpiYv028248; Thu, 27 Oct 2005 08:51:44 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9RFpiTi028247; Thu, 27 Oct 2005 08:51:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9RFpgdm028218 for ; Thu, 27 Oct 2005 08:51:42 -0700 (PDT) (envelope-from denis.pinkas@bull.net) 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 SAA14958 for ; Thu, 27 Oct 2005 18:09:01 +0200 Importance: Normal X-Priority: 3 (Normal) Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-21.txt MIME-Version: 1.0 From: denis.pinkas@bull.net To: ietf-pkix@imc.org Date: Thu, 27 Oct 2005 17:52:19 +0200 Message-ID: X-MIMETrack: Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 27/10/2005 17:52:20 Content-Type: multipart/mixed; boundary="=_mixed 00573005C12570A7_=" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=_mixed 00573005C12570A7_= MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 PEZPTlQgZmFjZT0iRGVmYXVsdCBTYW5zIFNlcmlmLCBWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNh LCBzYW5zLXNlcmlmIiBzaXplPTI+PERJVj48UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJ TjogMGNtIDBjbSAwcHQ7IG1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0 b20tYWx0OiBhdXRvIj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTog RU4tVVMiPjxGT05UIHNpemU9Mz48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPlRvIHRoZSBs aXN0LDwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwvUD48UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1B UkdJTjogMGNtIDBjbSAwcHQ7IG1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1i b3R0b20tYWx0OiBhdXRvIj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFn ZTogRU4tVVMiPjxGT05UIHNpemU9Mz48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjwvRk9O VD48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvUD48UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJ TjogMGNtIDBjbSAwcHQ7IG1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0 b20tYWx0OiBhdXRvIj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTog RU4tVVMiPjxGT05UIHNpemU9Mz48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkhlcmUgYXJl IGEgZmV3IGNvbW1lbnRzIG9uIHRoZSBsYXN0IGRyYWZ0LjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwv UD48UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQ7IG1zby1tYXJn aW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0b20tYWx0OiBhdXRvIj48U1BBTiBsYW5n PUVOLVVTIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tVVMiPjxGT05UIGZhY2U9IlRpbWVz IE5ldyBSb21hbiIgc2l6ZT0zPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9QPjxQIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdDsgbXNvLW1hcmdpbi10b3AtYWx0OiBhdXRv OyBtc28tbWFyZ2luLWJvdHRvbS1hbHQ6IGF1dG8iPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9Im1z by1hbnNpLWxhbmd1YWdlOiBFTi1VUyI+PEZPTlQgc2l6ZT0zPjxGT05UIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+VGhlIGNvbmZ1c2lvbiBiZXR3ZWVuIHZhbGlkYXRpb25BbGcgYW5kIFZhbGlkYXRp b25Qb2xpY3kgc3RpbGwgZXhpc3RzLjw/eG1sOm5hbWVzcGFjZSBwcmVmaXggPSBvIG5zID0gInVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgLz48bzpwPjwvbzpwPjwvRk9O VD48L0ZPTlQ+PC9TUEFOPjwvUD48UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNt IDBjbSAwcHQ7IG1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0b20tYWx0 OiBhdXRvIj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tVVMi PjxGT05UIHNpemU9Mz48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjwvRk9OVD48L0ZPTlQ+ PC9TUEFOPiZuYnNwOzwvUD48UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBj bSAwcHQ7IG1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0b20tYWx0OiBh dXRvIj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tVVMiPjxG T05UIHNpemU9Mz48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPk9uIG9uZSBzaWRlIChzZWN0 aW9uIDYuNykgaXQgaXMgc2FpZCB0aGF0IGl0IGlzIG5vdCBtYW5kYXRvcnkgZm9yIGEgc2VydmVy IHRvIHN1cHBvcnQgdGhlJm5ic3A7ImRlZmF1bHQgdmFsaWRhdGlvbiBwb2xpY3kiIGJ1dCBpdCBp cyBzdGlsbCBuZWNlc3NhcnkgZm9yIGEgc2VydmVyIHRvIHN1cHBvcnQgYWxsIGl0cyBwYXJhbWV0 ZXJzICE8QlI+PC9GT05UPjwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0ibXNv LWFuc2ktbGFuZ3VhZ2U6IEVOLVVTIj48Rk9OVCBzaXplPTM+PEZPTlQgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj5JZiB3ZSBoYWQgYSBidW5kbGUgdG8gaW5jbHVkZSBhbGwgd2hhdCBpcyBzcGVjaWZp YyB0byB0aGlzJm5ic3A7ImRlZmF1bHQgdmFsaWRhdGlvbiBwb2xpY3kiLCB0aGVuIHdlIGNvdWxk IG1ha2UgaXQgb3B0aW9uYWwgZm9yIHRoZSBzZXJ2ZXIuPG86cD48L286cD48L0ZPTlQ+PC9GT05U PjwvU1BBTj48L1A+PFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0 OyBtc28tbWFyZ2luLXRvcC1hbHQ6IGF1dG87IG1zby1tYXJnaW4tYm90dG9tLWFsdDogYXV0byI+ PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTIj48Rk9OVCBz aXplPTM+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48L0ZPTlQ+PC9GT05UPjwvU1BBTj4m bmJzcDs8L1A+PFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0OyBt c28tbWFyZ2luLXRvcC1hbHQ6IGF1dG87IG1zby1tYXJnaW4tYm90dG9tLWFsdDogYXV0byI+PFNQ QU4gbGFuZz1FTi1VUyBzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTIj48Rk9OVD48Rk9O VCBmYWNlPSJEZWZhdWx0IE1vbm9zcGFjZSwgQ291cmllciBOZXcsIENvdXJpZXIsIG1vbm9zcGFj ZSI+VGhlIHN5bnRheCBvZiB0aGUgdmFsaWRhdGlvblBvbGljeSBpdGVtIGlzOiA8bzpwPjwvbzpw PjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwvUD48UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJ TjogMGNtIDBjbSAwcHQ7IG1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0 b20tYWx0OiBhdXRvIj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTog RU4tVVMiPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PEZPTlQgc2l6ZT0zPjxGT05UIGZh Y2U9IkRlZmF1bHQgTW9ub3NwYWNlLCBDb3VyaWVyIE5ldywgQ291cmllciwgbW9ub3NwYWNlIiBz aXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFZhbGlkYXRpb25Qb2xpY3kgOjo9IFNFUVVF TkNFIHsgPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB2YWxpZGF0aW9u UG9sUmVmJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFZhbGlkYXRpb25Qb2xSZWYsIDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgdmFsaWRhdGlvbkFsZyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBbMF0gVmFsaWRhdGlvbkFsZyBPUFRJT05BTCwgPEJSPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1c2VyUG9saWN5U2V0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFsxXSBTRVFVRU5DRSBTSVpFICgxLi5NQVgpIE9G IE9CSkVDVCA8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElERU5USUZJRVIg T1BUSU9OQUwsIDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5oaWJp dFBvbGljeU1hcHBpbmcmbmJzcDsgWzJdIEJPT0xFQU4gT1BUSU9OQUwsIDxCUj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVxdWlyZUV4cGxpY2l0UG9saWN5IFszXSBCT09M RUFOIE9QVElPTkFMLCA8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlu aGliaXRBbnlQb2xpY3kmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWzRdIEJPT0xFQU4g T1BUSU9OQUwsIDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHJ1c3RB bmNob3JzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFs1XSBUcnVzdEFuY2hvcnMgT1BUSU9OQUwsIDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsga2V5VXNhZ2VzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFs2XSBTRVFVRU5DRSBvZiBL ZXlVc2FnZSBPUFRJT05BTCwgPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBleHRlbmRlZEtleVVzYWdlcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbN10gU0VRVUVOQ0Ug T0YgS2V5UHVycG9zZUlkIE9QVElPTkFMIH08L0ZPTlQ+IDxvOnA+PC9vOnA+PC9GT05UPjwvRk9O VD48L1NQQU4+PC9QPjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBw dDsgbXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28tbWFyZ2luLWJvdHRvbS1hbHQ6IGF1dG8i PjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUyI+PEZPTlQg c2l6ZT0zPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PC9GT05UPjwvRk9OVD48L1NQQU4+ Jm5ic3A7PC9QPjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdDsg bXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28tbWFyZ2luLWJvdHRvbS1hbHQ6IGF1dG8iPjxT UEFOIGxhbmc9RU4tVVMgc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUyI+PEZPTlQgc2l6 ZT0zPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+VGhlIHRleHQgc3RhdGVzOiCTQXQgYSBt aW5pbXVtLCBjb25mb3JtaW5nIFNDVlAgY2xpZW50IGltcGxlbWVudGF0aW9ucyBNVVNUIHN1cHBv cnQgdGhlIFZhbGlkYXRpb25Qb2xSZWYgaXRlbS6UIDxCUj48L0ZPTlQ+PC9GT05UPjwvU1BBTj48 U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tVVMiPjxGT05UIHNp emU9Mz48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkl0IGFsc28gc3RhdGVzOiAmbmJzcDsm bmJzcDsgIldoZXJlIGEgdmFsaWRhdGlvbiBwb2xpY3kgc3VwcG9ydHMgYWRkaXRpb25hbCBwb2xp Y3ktc3BlY2lmaWMgcGFyYW1ldGVyIHNldHRpbmdzLCB0aGVzZSB2YWx1ZXMgYXJlIHNwZWNpZmll ZCB1c2luZyB0aGUgdmFsUG9sUGFyYW1zIGl0ZW0iLjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwvUD48 UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQ7IG1zby1tYXJnaW4t dG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0b20tYWx0OiBhdXRvIj48U1BBTiBsYW5nPUVO LVVTIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tVVMiPjxGT05UIHNpemU9Mz48Rk9OVCBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1NQ QU4+PC9QPjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdDsgbXNv LW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28tbWFyZ2luLWJvdHRvbS1hbHQ6IGF1dG8iPjxTUEFO IGxhbmc9RU4tVVMgc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUyI+PEZPTlQgc2l6ZT0z PjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+VGhlc2UgcG9saWN5LXNwZWNpZmljIHBhcmFt ZXRlciBzZXR0aW5ncyBhcmUgbm90IEFERElUSU9OQUwgdG8gYW55dGhpbmcgc2luY2UgdGhleSBh cmUgdGhlIG9ubHkgcGFyYW1ldGVycyBhbmQgYWxsIHRoZSBvdGhlcnMsIHN1cHBvc2VkIHRvIGJl IHVzZWQgZm9yIHRoZXkgc28tY2FsbGVkIGRlZmF1bHQgdmFsaWRhdGlvbiBwb2xpY3kgYXJlIHNp bXBseSBpZ25vcmVkLjxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1NQQU4+PC9QPjxQIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdDsgbXNvLW1hcmdpbi10b3AtYWx0 OiBhdXRvOyBtc28tbWFyZ2luLWJvdHRvbS1hbHQ6IGF1dG8iPjxTUEFOIGxhbmc9RU4tVVMgc3R5 bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUyI+PEZPTlQgc2l6ZT0zPjxGT05UIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+PC9GT05UPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9QPjxQIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdDsgbXNvLW1hcmdpbi10b3AtYWx0OiBh dXRvOyBtc28tbWFyZ2luLWJvdHRvbS1hbHQ6IGF1dG8iPjxGT05UIHNpemU9Mz48Rk9OVCBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9Im1zby1hbnNpLWxhbmd1 YWdlOiBFTi1VUyI+VGhlIG5hbWUgdmFsaWRhdGlvbiBwb2xpY3kgaXMgb25lIG1vcmUgbGV2ZWwg b2YgY29tcGxleGl0eSB0aGF0IGFsbCBzZXJ2ZXJzIHdvdWxkIGhhdmUgdG8gc3VwcG9ydC4gVGhl cmUgd2lsbCBub3QgYmUgbWFueSBzZXJ2ZXIgaW1wbGVtZW50YXRpb25zIGNvbXBsaWFudCB3aXRo IHRoaXMgc3BlY2lmaWNhdGlvbiAhIDxCUj48L1NQQU4+PC9GT05UPjwvRk9OVD48U1BBTiBsYW5n PUVOLVVTIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tVVMiPjxGT05UIHNpemU9Mz48Rk9O VCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPk5vdGUgYWxzbyB0aGF0IHRoZSAibmFtZSB2YWxpZGF0 aW9uIGFsZ29yaXRobSIgaXMgZXhjbHVzaXZlIG9mIHRoZSAiYmFzaWMgdmFsaWRhdGlvbiBhbGdv cml0aG0iLiBUaGlzIGRvZXMgbm90IHdvcmsuPG86cD48L286cD48L0ZPTlQ+PC9GT05UPjwvU1BB Tj48L1A+PFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0OyBtc28t bWFyZ2luLXRvcC1hbHQ6IGF1dG87IG1zby1tYXJnaW4tYm90dG9tLWFsdDogYXV0byI+PFNQQU4g bGFuZz1FTi1VUyBzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTIj48Rk9OVCBzaXplPTM+ PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48L0ZPTlQ+PC9GT05UPjwvU1BBTj4mbmJzcDs8 L1A+PFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0OyBtc28tbWFy Z2luLXRvcC1hbHQ6IGF1dG87IG1zby1tYXJnaW4tYm90dG9tLWFsdDogYXV0byI+PFNQQU4gbGFu Zz1FTi1VUyBzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTIj48Rk9OVCBzaXplPTM+PEZP TlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5Gb3IgdGhlIENWUmVzcG9uc2UgdGhlIGNvbmZpZ3Vy YXRpb25JZCAod2FzIHBvbGljeUlEKSBpcyBzdGlsbCBhbiBvZGQgb2JqZWN0LjxvOnA+PC9vOnA+ PC9GT05UPjwvRk9OVD48L1NQQU4+PC9QPjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lO OiAwY20gMGNtIDBwdDsgbXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28tbWFyZ2luLWJvdHRv bS1hbHQ6IGF1dG8iPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBF Ti1VUyI+PEZPTlQgc2l6ZT0zPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PC9GT05UPjwv Rk9OVD48L1NQQU4+Jm5ic3A7PC9QPjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAw Y20gMGNtIDBwdDsgbXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28tbWFyZ2luLWJvdHRvbS1h bHQ6IGF1dG8iPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1V UyI+PEZPTlQgc2l6ZT0zPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+VGhlIHRleHQgc3Rh dGVzOiAmbmJzcDsmbmJzcDsgVGhlIGNvbmZpZ3VyYXRpb24gSUQgcmVwcmVzZW50cyB0aGUgdmVy c2lvbiBvZiB0aGUgZGVmYXVsdCA8U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNw OzwvU1BBTj52YWxpZGF0aW9uIHBvbGljeSB0aGF0IHdhcyB1c2VkIGJ5IHRoZSBTQ1ZQIHNlcnZl ciB3aGVuIGl0IHByb2Nlc3NlZCB0aGUgcmVxdWVzdC4mbmJzcDsgU2VlIHNlY3Rpb24gNi40IGZv ciBkZXRhaWxzLiA8bzpwPjwvbzpwPjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwvUD48UCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQ7IG1zby1tYXJnaW4tdG9wLWFsdDog YXV0bzsgbXNvLW1hcmdpbi1ib3R0b20tYWx0OiBhdXRvIj48Rk9OVCBzaXplPTM+PEZPTlQgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJtc28tYW5zaS1sYW5n dWFnZTogRU4tVVMiPlNpbmNlIHRoaXMgaXRlbSBpcyBzcGVjaWZpYyB0byB0aGUgZGVmYXVsdCB2 YWxpZGF0aW9uIHBvbGljeSBpdCBjYW5ub3QgYmUgbWFuZGF0b3J5LCBidXQgaXQgaXMgISA8L1NQ QU4+PG86cD48L286cD48L0ZPTlQ+PC9GT05UPjwvUD48UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 Ik1BUkdJTjogMGNtIDBjbSAwcHQ7IG1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdp bi1ib3R0b20tYWx0OiBhdXRvIj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJtc28tYW5zaS1sYW5n dWFnZTogRU4tVVMiPjxGT05UIHNpemU9Mz48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjwv Rk9OVD48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvUD48UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1B UkdJTjogMGNtIDBjbSAwcHQ7IG1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1i b3R0b20tYWx0OiBhdXRvIj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFn ZTogRU4tVVMiPjxGT05UIHNpemU9Mz48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPlRoZW4g aG93IGNhbiB3ZSBoYXZlIGEgdmVyc2lvbiBvZiBhIHZhbGlkYXRpb24gcG9saWN5ID8/PzxvOnA+ PC9vOnA+PC9GT05UPjwvRk9OVD48L1NQQU4+PC9QPjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0i TUFSR0lOOiAwY20gMGNtIDBwdDsgbXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28tbWFyZ2lu LWJvdHRvbS1hbHQ6IGF1dG8iPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9Im1zby1hbnNpLWxhbmd1 YWdlOiBFTi1VUyI+PEZPTlQgc2l6ZT0zPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+VGhl IGV4cGxhbmF0aW9ucyBmcm9tIDYuNCBkbyBub3QgaGVscCB0byB1bmRlcnN0YW5kLjxvOnA+PC9v OnA+PC9GT05UPjwvRk9OVD48L1NQQU4+PC9QPjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFS R0lOOiAwY20gMGNtIDBwdDsgbXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28tbWFyZ2luLWJv dHRvbS1hbHQ6IGF1dG8iPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdl OiBFTi1VUyI+PEZPTlQgc2l6ZT0zPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PC9GT05U PjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9QPjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lO OiAwY20gMGNtIDBwdDsgbXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28tbWFyZ2luLWJvdHRv bS1hbHQ6IGF1dG8iPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBF Ti1VUyI+PEZPTlQgc2l6ZT0zPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+RGVzcGl0ZSBt eSByZXF1ZXN0IG1hZGUgYW1vbmcgb3RoZXIgcmVxdWVzdHMgIldoYXQgbmVlZHMgdG8gYmUgaW1w bGVtZW50ZWQgdG8gYmUgYWJsZSB0byBzYXkgdGhhdCA8U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVu OiB5ZXMiPiZuYnNwOzwvU1BBTj50aGUgaW1wbGVtZW50YXRpb24gaXMgKG9ubHkpIERQViBjb25m b3JtYW50ID8iIHRoZSBkb2N1bWVudCBkb2VzIG5vdCBtYWtlIGEgY2xlYXIgZGlzdGluY3Rpb24g b24gdGhlIHJlcXVpcmVtZW50cyB0aGF0IGFyZSBvbmx5IG5lY2Vzc2FyeSBmb3IgRFBWLiA8L0ZP TlQ+PC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFn ZTogRU4tVVMiPjxGT05UIHNpemU9Mz48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPlRoaXMg Y29tZXMgZnJvbSB0aGUgZmFjdCB0aGF0IHR3byBkaWZmZXJlbnQgZG9jdW1lbnRzIHdvdWxkIGhh dmUgYmVlbiBtdWNoIGJldHRlciwgYnV0IGJlY2F1c2Ugc29tZSBwZW9wbGUgd2FudGVkIHRvIG1h aW50YWluIHRoZSBhY3JvbnltIFNDVlAgdGhpcyBoYXMgbm90IGJlZW4gZG9uZS4gPC9GT05UPjwv Rk9OVD48L1NQQU4+PC9QPjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNt IDBwdDsgbXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28tbWFyZ2luLWJvdHRvbS1hbHQ6IGF1 dG8iPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUyI+PEZP TlQgc2l6ZT0zPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PC9GT05UPjwvRk9OVD48L1NQ QU4+Jm5ic3A7PC9QPjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBw dDsgbXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28tbWFyZ2luLWJvdHRvbS1hbHQ6IGF1dG8i PjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUyI+PEZPTlQg c2l6ZT0zPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+RGlkIGV2ZXJ5Ym9keSBub3RpY2Vk IHRoYXQgIlMiIGRvZXMgbm90IG1lYW4gIlNpbXBsZSIgYW55bW9yZSwgYnV0ICJTdGFuZGFyZCIs IG9uY2UgYWdhaW4gdG8ga2VlcCB0aGUgYWNyb255bS48L0ZPTlQ+PC9GT05UPjwvU1BBTj48L1A+ PFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0OyBtc28tbWFyZ2lu LXRvcC1hbHQ6IGF1dG87IG1zby1tYXJnaW4tYm90dG9tLWFsdDogYXV0byI+PFNQQU4gbGFuZz1F Ti1VUyBzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTIj48L1NQQU4+PFNQQU4gbGFuZz1F Ti1VUyBzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTIj48Rk9OVCBzaXplPTM+PEZPTlQg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48bzpwPjwvbzpwPjwvRk9OVD48L0ZPTlQ+PC9TUEFOPiZu YnNwOzwvUD48UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQ7IG1z by1tYXJnaW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0b20tYWx0OiBhdXRvIj48U1BB TiBsYW5nPUVOLVVTIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tVVMiPjxGT05UIHNpemU9 Mz48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkEgdmVyeSBtaW5vciBwb2ludDogaW4gc2Vj dGlvbiA0LjggdGhlcmUgaXMgbm8gd2F5IHRvIGtub3cgd2hhdCB0aGUgaXRlbSByZXByZXNlbnRz IGFtb25nIHRoZSB0aHJlZSBjaG9pY2VzIG9mZmVyZWQgdG8gdGhlIHNlcnZlci48bzpwPjwvbzpw PjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwvUD48UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJ TjogMGNtIDBjbSAwcHQ7IG1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0 b20tYWx0OiBhdXRvIj48Rk9OVCBzaXplPTM+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tVVMiPjwvU1BBTj48 L0ZPTlQ+PC9GT05UPiZuYnNwOzwvUD48UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjog MGNtIDBjbSAwcHQ7IG1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0b20t YWx0OiBhdXRvIj48Rk9OVCBzaXplPTM+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48U1BB TiBsYW5nPUVOLVVTIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tVVMiPkZpbmFsbHksIHNp bmNlIHRoaXMgZG9jdW1lbnQgd2FzIGNyZWF0ZWQgaW4gdGhlIHByZXZpb3VzIGNlbnR1cnksIHdl IGhhZCBubyBwcm9ibGVtIHdpdGggU0hBLTEgYXQgdGhhdCB0aW1lIGFuZCBoZW5jZSB3ZSB1c2Vk IEVTU0NlcnRJRC4gSG93ZXZlciwgRVNTQ2VydElEIG1hbmRhdGVzIHRoZSB1c2Ugb2YgU0hBLTEu IDwvU1BBTj48bzpwPjwvbzpwPjwvRk9OVD48L0ZPTlQ+PC9QPjxQIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdDsgbXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28t bWFyZ2luLWJvdHRvbS1hbHQ6IGF1dG8iPjxGT05UIHNpemU9Mz48Rk9OVCBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1V UyI+SSB3b3VsZCBwcm9wb3NlIHRvIGFsbG93IHRvIHVzZSA8L1NQQU4+dGhlclNpZ25pbmdDZXJ0 aWZpY2F0IDxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUyI+ YXMgZGVmaW5lZCBpbiBSRkMgMzEyNi48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwv UD48UFJFPmlkLWFhLWV0cy1vdGhlclNpZ0NlcnQgT0JKRUNUIElERU5USUZJRVIgOjo9IHsgaXNv KDEpPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyBtZW1iZXItYm9keSgyKSB1cyg4NDApIHJzYWRzaSgx MTM1NDkpIHBrY3MoMSkgcGtjczkoOSk8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNtaW1lKDE2KSBp ZC1hYSgyKSAxOSB9PG86cD48L286cD48L1BSRT48L0RJVj48RElWPkRlbmlzPEJSPjwvRElWPjxG T05UIGNvbG9yPSM5OTAwOTk+LS0tLS1vd25lci1pZXRmLXBraXhAbWFpbC5pbWMub3JnIHdyb3Rl OiAtLS0tLTxCUj48QlI+PC9GT05UPlRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmc8QlI+RnJvbTog SW50ZXJuZXQtRHJhZnRzQGlldGYub3JnPEJSPlNlbnQgYnk6IG93bmVyLWlldGYtcGtpeEBtYWls LmltYy5vcmc8QlI+RGF0ZTogMjUvMTAvMjAwNSAwOTo1MFBNPEJSPmNjOiBpZXRmLXBraXhAaW1j Lm9yZzxCUj5TdWJqZWN0OiBJLUQgQUNUSU9OOmRyYWZ0LWlldGYtcGtpeC1zY3ZwLTIxLnR4dDxC Uj48QlI+PFBSRT5BIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24t bGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRl bSBvZiB0aGUgUHVibGljLUtleSBJbmZyYXN0cnVjdHVyZSAoWC41MDkpIFdvcmtpbmcgR3JvdXAg b2YgdGhlIElFVEYuCVRpdGxlCQk6IFN0YW5kYXJkIENlcnRpZmljYXRlIFZhbGlkYXRpb24gUHJv dG9jb2wgKFNDVlApCUF1dGhvcihzKQk6IEEuIE1hbHBhbmksIGV0IGFsLglGaWxlbmFtZQk6IGRy YWZ0LWlldGYtcGtpeC1zY3ZwLTIxLnR4dAlQYWdlcwkJOiA3OAlEYXRlCQk6IDIwMDUtMTAtMjUJ U0NWUCBhbGxvd3MgYSBjbGllbnQgdG8gZGVsZWdhdGUgY2VydGlmaWNhdGUgcGF0aCBjb25zdHJ1 Y3Rpb24gYW5kICAgY2VydGlmaWNhdGUgcGF0aCB2YWxpZGF0aW9uIHRvIGEgc2VydmVyLiAgVGhl IHBhdGggY29uc3RydWN0aW9uIG9yICAgdmFsaWRhdGlvbiAoZS5nLiBtYWtpbmcgc3VyZSB0aGF0 IG5vbmUgb2YgdGhlIGNlcnRpZmljYXRlcyBpbiB0aGUgICBwYXRoIGFyZSByZXZva2VkKSBpcyBw ZXJmb3JtZWQgYWNjb3JkaW5nIHRvIGEgdmFsaWRhdGlvbiBwb2xpY3ksICAgd2hpY2ggY29udGFp bnMgb25lIG9yIG1vcmUgdHJ1c3QgYW5jaG9ycy4gIEl0IGFsbG93cyBzaW1wbGlmaWNhdGlvbiAg IG9mIGNsaWVudCBpbXBsZW1lbnRhdGlvbnMgYW5kIHVzZSBvZiBhIHNldCBvZiBwcmVkZWZpbmVk IHZhbGlkYXRpb24gICBwb2xpY2llcy5BIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczo8 YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXBr aXgtc2N2cC0yMS50eHQiIHRhcmdldD1ibGFuaz5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1pZXRmLXBraXgtc2N2cC0yMS50eHQ8L2E+VG8gcmVtb3ZlIHlvdXJzZWxm IGZyb20gdGhlIEktRCBBbm5vdW5jZW1lbnQgbGlzdCwgc2VuZCBhIG1lc3NhZ2UgdG8gaS1kLWFu bm91bmNlLXJlcXVlc3RAaWV0Zi5vcmcgd2l0aCB0aGUgd29yZCB1bnN1YnNjcmliZSBpbiB0aGUg Ym9keSBvZiB0aGUgbWVzc2FnZS4gIFlvdSBjYW4gYWxzbyB2aXNpdCA8QSBocmVmPSJodHRwczov L3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9JLUQtYW5ub3VuY2UiIHRhcmdldD1ibGFu ayA+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vSS1ELWFubm91bmNlPC9h PiB0byBjaGFuZ2UgeW91ciBzdWJzY3JpcHRpb24gc2V0dGluZ3MuSW50ZXJuZXQtRHJhZnRzIGFy ZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQLiBMb2dpbiB3aXRoIHRoZSB1c2VybmFt ZSJhbm9ueW1vdXMiIGFuZCBhIHBhc3N3b3JkIG9mIHlvdXIgZS1tYWlsIGFkZHJlc3MuIEFmdGVy IGxvZ2dpbmcgaW4sdHlwZSAiY2QgaW50ZXJuZXQtZHJhZnRzIiBhbmQgdGhlbgkiZ2V0IGRyYWZ0 LWlldGYtcGtpeC1zY3ZwLTIxLnR4dCIuQSBsaXN0IG9mIEludGVybmV0LURyYWZ0cyBkaXJlY3Rv cmllcyBjYW4gYmUgZm91bmQgaW48YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5o dG1sIiB0YXJnZXQ9Ymxhbms+aHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbDwvYT4gb3Ig PEEgaHJlZj0iZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQiIHRhcmdl dD1ibGFuayA+ZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQ8L2E+SW50 ZXJuZXQtRHJhZnRzIGNhbiBhbHNvIGJlIG9idGFpbmVkIGJ5IGUtbWFpbC5TZW5kIGEgbWVzc2Fn ZSB0bzoJbWFpbHNlcnZAaWV0Zi5vcmcuSW4gdGhlIGJvZHkgdHlwZToJIkZJTEUgL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1pZXRmLXBraXgtc2N2cC0yMS50eHQiLglOT1RFOglUaGUgbWFpbCBzZXJ2 ZXIgYXQgaWV0Zi5vcmcgY2FuIHJldHVybiB0aGUgZG9jdW1lbnQgaW4JTUlNRS1lbmNvZGVkIGZv cm0gYnkgdXNpbmcgdGhlICJtcGFjayIgdXRpbGl0eS4gIFRvIHVzZSB0aGlzCWZlYXR1cmUsIGlu c2VydCB0aGUgY29tbWFuZCAiRU5DT0RJTkcgbWltZSIgYmVmb3JlIHRoZSAiRklMRSIJY29tbWFu ZC4gIFRvIGRlY29kZSB0aGUgcmVzcG9uc2UocyksIHlvdSB3aWxsIG5lZWQgIm11bnBhY2siIG9y CWEgTUlNRS1jb21wbGlhbnQgbWFpbCByZWFkZXIuICBEaWZmZXJlbnQgTUlNRS1jb21wbGlhbnQg bWFpbCByZWFkZXJzCWV4aGliaXQgZGlmZmVyZW50IGJlaGF2aW9yLCBlc3BlY2lhbGx5IHdoZW4g ZGVhbGluZyB3aXRoCSJtdWx0aXBhcnQiIE1JTUUgbWVzc2FnZXMgKGkuZS4gZG9jdW1lbnRzIHdo aWNoIGhhdmUgYmVlbiBzcGxpdAl1cCBpbnRvIG11bHRpcGxlIG1lc3NhZ2VzKSwgc28gY2hlY2sg eW91ciBsb2NhbCBkb2N1bWVudGF0aW9uIG9uCWhvdyB0byBtYW5pcHVsYXRlIHRoZXNlIG1lc3Nh Z2VzLgkJCQlCZWxvdyBpcyB0aGUgZGF0YSB3aGljaCB3aWxsIGVuYWJsZSBhIE1JTUUgY29tcGxp YW50IG1haWwgcmVhZGVyaW1wbGVtZW50YXRpb24gdG8gYXV0b21hdGljYWxseSByZXRyaWV2ZSB0 aGUgQVNDSUkgdmVyc2lvbiBvZiB0aGVJbnRlcm5ldC1EcmFmdC48L1BSRT48UD48QSBocmVmPSJm dHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtcGtpeC1zY3ZwLTIx LnR4dCIgdGFyZ2V0PWJsYW5rID5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWlldGYtcGtpeC1zY3ZwLTIxLnR4dDwvQT48L1A+PC9GT05UPg0K --=_mixed 00573005C12570A7_= Content-Type: application/octet-stream; name="draft-ietf-pkix-scvp-21.txt" Content-Disposition: attachment; filename="draft-ietf-pkix-scvp-21.txt" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDQpDb250ZW50LUlEOgk8MjAwNS0xMC0yNTExMDQzNy5J LURAaWV0Zi5vcmc+DQo= --=_mixed 00573005C12570A7_=-- From owner-ietf-pkix@mail.imc.org Thu Oct 27 14:47:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVCmb-0007k3-Hy for pkix-archive@megatron.ietf.org; Thu, 27 Oct 2005 14:47:25 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22070 for ; Thu, 27 Oct 2005 14:47:06 -0400 (EDT) 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 j9RHik0e041731; Thu, 27 Oct 2005 10:44:46 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9RHikHv041730; Thu, 27 Oct 2005 10:44:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9RHiiUZ041717 for ; Thu, 27 Oct 2005 10:44:45 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Oct 2005 18:44:39 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Public key validation and Proof of possession Date: Thu, 27 Oct 2005 18:44:37 +0100 Message-ID: Thread-Topic: Public key validation and Proof of possession Thread-Index: AcXa+45Q6DRaJyr3TcOZGsFK8X2zKwAIJ6Qg From: "Stefan Santesson" To: "Russ Housley" , X-OriginalArrivalTime: 27 Oct 2005 17:44:39.0211 (UTC) FILETIME=[1A9FCFB0:01C5DB1E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j9RHijUZ041723 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Russ, Yes, there may definitely be new low-end devices. But how many low-end devices do validate a large number of certificates from other entities on its own? Have you considered using the qcStatement extension in RFC 3739, it's actually designed to deal with things like this. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: den 27 oktober 2005 15:37 > To: Stefan Santesson; ietf-pkix@imc.org > Subject: RE: Public key validation and Proof of possession > > Stefan: > > I think that there will always be low end devices. Consider the history. > > - Personal computers used to be very simple systems, especially > before the IBM PC. Remember the Intel 8080? A very large machine > had 32 Kbytes of RAM, and non-volatile storage was 8-inch floppy disk. > > - Hand-held computers were originally very low-end computers. They > have come a long way, and the power management has significantly > helped with battery life. > > - Mobile phones did not really include Internet capabilities at > first, but when they were added, WAP was used to accommodate the > low-end processing environment. When 32-bit processors appeared in > mobile phones, mainstream Internet protocols were used in favor of WAP. > > - Smartcards are still low-end processors. As you point out, they > are getting more powerful all the time. > > - RFID are very low-power devices. I'm sure that more capabilities > will be added over time. But right now, certificate parsing and > validation is probably beyond their capabilities. As they become > more capable, I think that certificate-based protocols are > appropriate in this environment. > > In summary, I do not think it is unreasonable to consider features > for low-end devices. I believe that there will always be new low-end > devices appearing, and at some point they may need to handle certificates. > > Russ > > At 05:37 PM 10/26/2005, Stefan Santesson wrote: > >Russ, > > > >I'm concerned that we are about to enter a dangerous path if we start > >defining extensions for policy aspects. If we open this can, there are > >many other potential candidates for policy expression extensions and I'm > >not sure we will help the deployment community by going down that path. > > > >I think this needs careful consideration and I'm not sure the benefit of > >this extension is worth the cost. > > > >My thought is that arithmetic property validation seems feasible even in > >a smart card today and even more, this test can easily be done in the > >system in which the smart card is used. Computation power is > >exponentially increasing and before this extension is generally adopted, > >this might very well be a completely redundant issue. > > > >POP of encryption keys seems to be such a generic requirement for CAs > >that even policy enforcement through trust anchor chaining might be > >sufficient in most cases. > > > >I think it would be good to have some discussions in Vancouver if this > >can be fitted into the pkix agenda. > > > > > >Stefan Santesson > >Program Manager, Standards Liaison > >Windows Security > > > > > > > -----Original Message----- > > > From: Russ Housley [mailto:housley@vigilsec.com] > > > Sent: den 26 oktober 2005 15:39 > > > To: Stefan Santesson; ietf-pkix@imc.org > > > Subject: RE: Public key validation and Proof of possession > > > > > > Stefan: > > > > > > >On public key validation (arithmetic properties): > > > >It seems to me that the key validation tests specified in 5.6.2.4 and > > > >5.6.2.5 are rather trivial to do locally ( 2= > > >for FFC), at least compared to the cost of using this key for > >anything > > > >useful. I wonder if the cost of making this test isn't actually lower > > > >than parsing the certificate to obtain the assurance from the CA. > > > > > > In low power devices (such as smartcards), avoiding the y^q > > > exponentiation because the relying party is sure that the CA has > > > already performed this check seems useful. > > > > > > >On Proof-of-possession: > > > >Section 5.6.3. of SP 800-56 states: > > > >"For example, this Recommendation requires that parties obtain > >assurance > > > >that they actually possess their own static private keys, and a > >binding > > > >authority is required to obtain assurance of an owner's possession of > > > >the appropriate static private key before binding an identifier to > >the > > > >owner's static public key." > > > > > > > >So since POP always MUST be performed by the CA there seems not to be > > > >the need for diverse policies (POP and non POP). > > > > > > > >Do you agree with these observations or have I missed something? > > > > > > If the first idea is accepted, the proposed extension is no larger by > > > adding the additional bit to indicate that the CA performed POP. The > > > positive statement could be useful. > > > > > > Russ From owner-ietf-pkix@mail.imc.org Thu Oct 27 14:56:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVCuu-0003vC-Og for pkix-archive@megatron.ietf.org; Thu, 27 Oct 2005 14:56:00 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22450 for ; Thu, 27 Oct 2005 14:55:42 -0400 (EDT) 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 j9RI9fbS044015; Thu, 27 Oct 2005 11:09:41 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9RI9f0P044014; Thu, 27 Oct 2005 11:09:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9RI9e3M044006 for ; Thu, 27 Oct 2005 11:09:40 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 11655 invoked by uid 0); 27 Oct 2005 17:57:45 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.238.33) by woodstock.binhost.com with SMTP; 27 Oct 2005 17:57:45 -0000 Message-Id: <7.0.0.10.2.20051027135635.058dac78@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta) Date: Thu, 27 Oct 2005 13:57:48 -0400 To: "Stefan Santesson" , From: Russ Housley Subject: RE: Public key validation and Proof of possession In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have not assumed that the certificates would be Qualified Certificates. I do not think that the qcStatement extension should be used in non-Qualified Certificates. Russ At 01:44 PM 10/27/2005, Stefan Santesson wrote: >Have you considered using the qcStatement extension in RFC 3739, it's >actually designed to deal with things like this. From owner-ietf-pkix@mail.imc.org Thu Oct 27 14:57:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVCwd-0005ZJ-OH for pkix-archive@megatron.ietf.org; Thu, 27 Oct 2005 14:57:47 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22590 for ; Thu, 27 Oct 2005 14:57:29 -0400 (EDT) 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 j9RICnJD044580; Thu, 27 Oct 2005 11:12:49 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9RICn5g044579; Thu, 27 Oct 2005 11:12:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9RIClo7044524 for ; Thu, 27 Oct 2005 11:12:48 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Oct 2005 19:12:41 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Public key validation and Proof of possession Date: Thu, 27 Oct 2005 19:12:40 +0100 Message-ID: Thread-Topic: Public key validation and Proof of possession Thread-Index: AcXbIA44A6qHkx1iSVCPVNmwN99CYgAAMN3Q From: "Stefan Santesson" To: "Russ Housley" , X-OriginalArrivalTime: 27 Oct 2005 18:12:41.0879 (UTC) FILETIME=[05929270:01C5DB22] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j9RICmo7044569 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I don't see why not. When RFC 3739 was updated from 3039, one of the purposes was to clarify that the components of the standard is not limited for use in QC. "This specification is intended to support this class of certificates, but its scope is not limited to this application." For example, if you want to include a reference to a picture in a non QC you could use the biomentricInfo ext of RFC 3739 instead of defining a new extension for non QC use. Same for the RFC 3739 defined attributes etc. The qcStatement extension already defines a framework for adding more granular information of policy aspects that is already defined by a certificate policy but which can not be explicitly decoded from a CP OID. It would certainly satisfy SP 800-56. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: den 27 oktober 2005 19:58 > To: Stefan Santesson; ietf-pkix@imc.org > Subject: RE: Public key validation and Proof of possession > > I have not assumed that the certificates would be Qualified Certificates. > > I do not think that the qcStatement extension should be used in > non-Qualified Certificates. > > Russ > > At 01:44 PM 10/27/2005, Stefan Santesson wrote: > >Have you considered using the qcStatement extension in RFC 3739, it's > >actually designed to deal with things like this. From owner-ietf-pkix@mail.imc.org Thu Oct 27 15:27:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVDPU-0000b7-48 for pkix-archive@megatron.ietf.org; Thu, 27 Oct 2005 15:27:36 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24094 for ; Thu, 27 Oct 2005 15:27:19 -0400 (EDT) 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 j9RIaOH0047032; Thu, 27 Oct 2005 11:36:24 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9RIaOLY047031; Thu, 27 Oct 2005 11:36:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9RIaNZ5047024 for ; Thu, 27 Oct 2005 11:36:24 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 5446 invoked by uid 0); 27 Oct 2005 18:35:31 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.238.33) by woodstock.binhost.com with SMTP; 27 Oct 2005 18:35:31 -0000 Message-Id: <7.0.0.10.2.20051027142805.058da930@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta) Date: Thu, 27 Oct 2005 14:35:34 -0400 To: "Stefan Santesson" From: Russ Housley Subject: RE: Public key validation and Proof of possession Cc: ietf-pkix@imc.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stefan: I guess that qcStatements leads one to think QC, just from the name. That aside, what would the difference be to an implementor? In one case, a new OID for an extension must be recognized. In the other case, a new OID must be recognized within the qcStatements extension. This is a bigger deal to an implementor if they do not already support the extensions specified in RFC 3739. That said, if the PKIX WG is happier with this being defined as a standards-track qcStatement it will meet my needs. Russ At 02:12 PM 10/27/2005, Stefan Santesson wrote: >I don't see why not. > >When RFC 3739 was updated from 3039, one of the purposes was to clarify >that the components of the standard is not limited for use in QC. > >"This specification is intended to support this class of certificates, >but its scope is not limited to this application." > >For example, if you want to include a reference to a picture in a non QC >you could use the biomentricInfo ext of RFC 3739 instead of defining a >new extension for non QC use. Same for the RFC 3739 defined attributes >etc. > >The qcStatement extension already defines a framework for adding more >granular information of policy aspects that is already defined by a >certificate policy but which can not be explicitly decoded from a CP >OID. > >It would certainly satisfy SP 800-56. > > > >Stefan Santesson >Program Manager, Standards Liaison >Windows Security > > > > -----Original Message----- > > From: Russ Housley [mailto:housley@vigilsec.com] > > Sent: den 27 oktober 2005 19:58 > > To: Stefan Santesson; ietf-pkix@imc.org > > Subject: RE: Public key validation and Proof of possession > > > > I have not assumed that the certificates would be Qualified >Certificates. > > > > I do not think that the qcStatement extension should be used in > > non-Qualified Certificates. > > > > Russ > > > > At 01:44 PM 10/27/2005, Stefan Santesson wrote: > > >Have you considered using the qcStatement extension in RFC 3739, it's > > >actually designed to deal with things like this. From owner-ietf-pkix@mail.imc.org Thu Oct 27 15:36:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVDXq-0004zs-Vc for pkix-archive@megatron.ietf.org; Thu, 27 Oct 2005 15:36:15 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24557 for ; Thu, 27 Oct 2005 15:35:57 -0400 (EDT) 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 j9RIpirJ048625; Thu, 27 Oct 2005 11:51:44 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9RIpipq048624; Thu, 27 Oct 2005 11:51:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9RIphKH048614 for ; Thu, 27 Oct 2005 11:51:43 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Oct 2005 19:51:37 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Public key validation and Proof of possession Date: Thu, 27 Oct 2005 19:51:36 +0100 Message-ID: Thread-Topic: Public key validation and Proof of possession Thread-Index: AcXbJVgdZnUCBujsQLmqdTDyau88sQAAGFBQ From: "Stefan Santesson" To: "Russ Housley" Cc: X-OriginalArrivalTime: 27 Oct 2005 18:51:37.0821 (UTC) FILETIME=[75E708D0:01C5DB27] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j9RIpiKH048618 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit It is not a proposal. I just wanted to add it to the picture. I'm just generally worried about adding new extensions for every specific certificate policy aspect that can be argued to be useful to have explicitly encoded. If we go that path, we may need to consider a common framework for it. qcStatement is one, suitable or not. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: den 27 oktober 2005 20:36 > To: Stefan Santesson > Cc: ietf-pkix@imc.org > Subject: RE: Public key validation and Proof of possession > > Stefan: > > I guess that qcStatements leads one to think QC, just from the name. > > That aside, what would the difference be to an implementor? In one > case, a new OID for an extension must be recognized. In the other > case, a new OID must be recognized within the qcStatements > extension. This is a bigger deal to an implementor if they do not > already support the extensions specified in RFC 3739. > > That said, if the PKIX WG is happier with this being defined as a > standards-track qcStatement it will meet my needs. > > Russ > > > At 02:12 PM 10/27/2005, Stefan Santesson wrote: > >I don't see why not. > > > >When RFC 3739 was updated from 3039, one of the purposes was to clarify > >that the components of the standard is not limited for use in QC. > > > >"This specification is intended to support this class of certificates, > >but its scope is not limited to this application." > > > >For example, if you want to include a reference to a picture in a non QC > >you could use the biomentricInfo ext of RFC 3739 instead of defining a > >new extension for non QC use. Same for the RFC 3739 defined attributes > >etc. > > > >The qcStatement extension already defines a framework for adding more > >granular information of policy aspects that is already defined by a > >certificate policy but which can not be explicitly decoded from a CP > >OID. > > > >It would certainly satisfy SP 800-56. > > > > > > > >Stefan Santesson > >Program Manager, Standards Liaison > >Windows Security > > > > > > > -----Original Message----- > > > From: Russ Housley [mailto:housley@vigilsec.com] > > > Sent: den 27 oktober 2005 19:58 > > > To: Stefan Santesson; ietf-pkix@imc.org > > > Subject: RE: Public key validation and Proof of possession > > > > > > I have not assumed that the certificates would be Qualified > >Certificates. > > > > > > I do not think that the qcStatement extension should be used in > > > non-Qualified Certificates. > > > > > > Russ > > > > > > At 01:44 PM 10/27/2005, Stefan Santesson wrote: > > > >Have you considered using the qcStatement extension in RFC 3739, it's > > > >actually designed to deal with things like this. From owner-ietf-pkix@mail.imc.org Thu Oct 27 18:09:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVFwE-0005eY-VQ for pkix-archive@megatron.ietf.org; Thu, 27 Oct 2005 18:09:35 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20531 for ; Thu, 27 Oct 2005 18:09:17 -0400 (EDT) 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 j9RLJ25I070619; Thu, 27 Oct 2005 14:19:02 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9RLJ2MA070618; Thu, 27 Oct 2005 14:19:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9RLJ1RU070610 for ; Thu, 27 Oct 2005 14:19:02 -0700 (PDT) (envelope-from tdchayes@gmail.com) Received: by xproxy.gmail.com with SMTP id t6so63657wxc for ; Thu, 27 Oct 2005 14:18:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=clMF7uKYxWpEGM1k60jbL1RaRc2g8Oy4T3RPbbnUrOU+FAetoHEi0CPCk8JbPS36BUgFJG9unNQfS8uWnMSQEwxl4TSu544t/Cg6/rws9kY48P9KE1uhISkDT3wh6rfhzZR5myIlCK9R+8uAcWWqEAyGgYXnPC5vlrd6PaHg1lk= Received: by 10.65.137.14 with SMTP id p14mr1566531qbn; Thu, 27 Oct 2005 14:18:56 -0700 (PDT) Received: by 10.65.141.18 with HTTP; Thu, 27 Oct 2005 14:18:56 -0700 (PDT) Message-ID: <4701d76c0510271418p28eb9362l8cfcdeba1182a6fc@mail.gmail.com> Date: Thu, 27 Oct 2005 14:18:56 -0700 From: Terry Hayes To: ietf-pkix@imc.org Subject: RE: Public key validation and Proof of possession In-Reply-To: <4701d76c0510271416i3e73cf63i74696df0009477cb@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_48544_14365955.1130447936580" References: <4701d76c0510271416i3e73cf63i74696df0009477cb@mail.gmail.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ------=_Part_48544_14365955.1130447936580 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable What's wrong with defining a new policy qualifier? id-qt-ietf-pkix-key-validation-performed id-qt-ietf-pkix-proof-of-posession-performed (owner-posession-of-key-assured?) These would generally be asserted only in the end-entity certificates. Terry Hayes On 10/27/05, Stefan Santesson wrote: > > > It is not a proposal. > I just wanted to add it to the picture. > > I'm just generally worried about adding new extensions for every > specific certificate policy aspect that can be argued to be useful to > have explicitly encoded. > > If we go that path, we may need to consider a common framework for it. > qcStatement is one, suitable or not. > > > Stefan Santesson > Program Manager, Standards Liaison > Windows Security > > > ------=_Part_48544_14365955.1130447936580 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
What's wrong with defining a new policy qualifier?
 
id-qt-ietf-pkix-key-validation-performed
id-qt-ietf-pkix-proof-of-posession-performed (owner-posession-of-key-a= ssured?)
 
These would generally be asserted only in the end-entity certificates.=
 
Terry Hayes

 
On 10/27/05, Stefan Santesson <stefans@= microsoft.com > wrote:=20

It is not a proposal.
I j= ust wanted to add it to the picture.

I'm just generally worried abou= t adding new extensions for every=20
specific certificate policy aspect that can be argued to be useful tohave explicitly encoded.

If we go that path, we may need to consid= er a common framework for it.
qcStatement is one, suitable or not.


Stefan Santesson
Program Manager, Standards Liaison
Windows S= ecurity


------=_Part_48544_14365955.1130447936580-- From owner-ietf-pkix@mail.imc.org Fri Oct 28 09:20:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVU9I-0004nk-IV for pkix-archive@megatron.ietf.org; Fri, 28 Oct 2005 09:20:01 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14010 for ; Fri, 28 Oct 2005 09:19:41 -0400 (EDT) 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 j9SCZ5Sv062316; Fri, 28 Oct 2005 05:35:05 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9SCZ5sK062315; Fri, 28 Oct 2005 05:35:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from srv1.int.stroeder.com (168-11-124-83.dsl.3u.net [83.124.11.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9SCZ3ge062293 for ; Fri, 28 Oct 2005 05:35:04 -0700 (PDT) (envelope-from michael@stroeder.com) Received: from localhost (localhost [127.0.0.1]) by srv1.int.stroeder.com (Postfix) with ESMTP id DCFB71F03 for ; Fri, 28 Oct 2005 14:34:56 +0200 (CEST) Received: from srv1.int.stroeder.com ([127.0.0.1]) by localhost (srv1 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13790-10 for ; Fri, 28 Oct 2005 14:34:41 +0200 (CEST) Received: from [10.1.1.5] (unknown [10.1.1.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Michael Stroeder", Issuer "Thawte Personal Freemail Issuing CA" (not verified)) by srv1.int.stroeder.com (Postfix) with ESMTP id CCC511F02 for ; Fri, 28 Oct 2005 14:34:40 +0200 (CEST) Message-ID: <4361C74A.1080900@stroeder.com> Date: Fri, 28 Oct 2005 08:38:02 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: Public key validation and Proof of possession References: In-Reply-To: X-Enigmail-Version: 0.92.1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at int.stroeder.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Stefan Santesson wrote: > > I'm concerned that we are about to enter a dangerous path if we start > defining extensions for policy aspects. A very valid concern. > If we open this can, there are > many other potential candidates for policy expression extensions and I'm > not sure we will help the deployment community by going down that path. I couldn't agree more. How about candidates like "Power and air conditioning", "Water exposures" and "Fire prevention and protection". I'm pretty sure a relying participant should be able to check these aspects automagically. ;-) > I think this needs careful consideration and I'm not sure the benefit of > this extension is worth the cost. It's my impression that X.509v3 extensions are not fully supported in today's implementations anyway. Therefore each new extension will likely not be adopted by implementors but will complicate the standards. > My thought is that arithmetic property validation seems feasible even in > a smart card today and even more, this test can easily be done in the > system in which the smart card is used. Computation power is > exponentially increasing and before this extension is generally adopted, > this might very well be a completely redundant issue. +1 Ciao, Michael. From owner-ietf-pkix@mail.imc.org Fri Oct 28 09:21:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVUAI-0005B7-JB for pkix-archive@megatron.ietf.org; Fri, 28 Oct 2005 09:21:02 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14038 for ; Fri, 28 Oct 2005 09:20:39 -0400 (EDT) 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 j9SCZCPm062332; Fri, 28 Oct 2005 05:35:12 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9SCZCmu062331; Fri, 28 Oct 2005 05:35:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from srv1.int.stroeder.com (168-11-124-83.dsl.3u.net [83.124.11.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9SCZAub062319 for ; Fri, 28 Oct 2005 05:35:11 -0700 (PDT) (envelope-from michael@stroeder.com) Received: from localhost (localhost [127.0.0.1]) by srv1.int.stroeder.com (Postfix) with ESMTP id 69ED31EF8 for ; Fri, 28 Oct 2005 14:35:05 +0200 (CEST) Received: from srv1.int.stroeder.com ([127.0.0.1]) by localhost (srv1 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14417-05 for ; Fri, 28 Oct 2005 14:34:52 +0200 (CEST) Received: from [10.1.1.5] (unknown [10.1.1.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Michael Stroeder", Issuer "Thawte Personal Freemail Issuing CA" (not verified)) by srv1.int.stroeder.com (Postfix) with ESMTP id B67681F06 for ; Fri, 28 Oct 2005 14:34:41 +0200 (CEST) Message-ID: <4361C8DC.2020906@stroeder.com> Date: Fri, 28 Oct 2005 08:44:44 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: Public key validation and Proof of possession References: <7.0.0.10.2.20051027092241.05814258@vigilsec.com> In-Reply-To: <7.0.0.10.2.20051027092241.05814258@vigilsec.com> X-Enigmail-Version: 0.92.1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at int.stroeder.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Russ Housley wrote: > > - Smartcards are still low-end processors. As you point out, they are > getting more powerful all the time. In a real-world project I'd prefer to spend more money for a more powerful smartcard over messing around with applications which are badly implemented because the standards are getting too complicated. > - RFID are very low-power devices. I'm sure that more capabilities will > be added over time. But right now, certificate parsing and validation > is probably beyond their capabilities. As they become more capable, I > think that certificate-based protocols are appropriate in this environment. > > In summary, I do not think it is unreasonable to consider features for > low-end devices. I believe that there will always be new low-end > devices appearing, and at some point they may need to handle certificates. But extending high-end certificate-based protocols to cover low-end devices likely will make the protocols too complex to be ever securely implemented. => PKIX should be limited to where it's applicable in the real world. Ciao, Michael. From owner-ietf-pkix@mail.imc.org Fri Oct 28 10:29:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVVEl-0001t7-6K for pkix-archive@megatron.ietf.org; Fri, 28 Oct 2005 10:29:43 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20244 for ; Fri, 28 Oct 2005 10:29:25 -0400 (EDT) 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 j9SDaVNQ067805; Fri, 28 Oct 2005 06:36:31 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9SDaVrG067804; Fri, 28 Oct 2005 06:36:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9SDaUBt067797 for ; Fri, 28 Oct 2005 06:36:31 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 9AC30E0049; Fri, 28 Oct 2005 09:36:28 -0400 (EDT) To: ietf-pkix@imc.org Cc: jhutz@cmu.edu Subject: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos From: Sam Hartman Date: Fri, 28 Oct 2005 09:12:06 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) Content-Type: multipart/mixed; boundary="=-=-=" MIME-Version: 1.0 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=-=-= 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. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from MIME-Version: 1.0 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: 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 ; 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 ; 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: ietf-krb-wg-outgoing@anl.gov Received: from mailhost.anl.gov (localhost [127.0.0.1]) by localhost.ctd.anl.gov (Postfix) with ESMTP id E87EA26D for ; 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: ietf-krb-wg@anl.gov Delivered-To: ietf-krb-wg@anl.gov Received: from mailhost.anl.gov (localhost [127.0.0.1]) by localhost.ctd.anl.gov (Postfix) with ESMTP id 5D96227F for ; 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 ; 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 ; 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/qQraCNyY7Gmr6mlG7xV3U@JHUTZ-DYN0.PC.CS.CMU.EDU [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=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 23 Oct 2005 22:06:05 -0400 (EDT) Date: Sun, 23 Oct 2005 22:06:00 -0400 From: Jeffrey Hutzelman To: ietf-krb-wg@anl.gov Cc: Jeffrey Hutzelman Subject: LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos Message-ID: <6F5E31C582712026A72741F6@bistromath.pc.cs.cmu.edu> Originator-Info: login-token=Mulberry:01ouPFOwxLOq/uLj281WH1qjlV/GYpFz4PWPOg2GM=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) Sender: owner-ietf-krb-wg@mailhost.anl.gov 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, ietf-krb-wg@anl.gov, 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) Chair, IETF Kerberos Working Group Carnegie Mellon University - Pittsburgh, PA --=-=-=-- From owner-ietf-pkix@mail.imc.org Fri Oct 28 12:34:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVXBd-0006Uh-0x for pkix-archive@megatron.ietf.org; Fri, 28 Oct 2005 12:34:37 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27657 for ; Fri, 28 Oct 2005 12:34:19 -0400 (EDT) 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 j9SFqZaE097977; Fri, 28 Oct 2005 08:52:35 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9SFqZPG097976; Fri, 28 Oct 2005 08:52:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9SFqYuU097968 for ; Fri, 28 Oct 2005 08:52:35 -0700 (PDT) (envelope-from todd.glassey@att.net) Received: from 204.127.135.59 ([204.127.135.59]) by worldnet.att.net (mtiwmhc12) with SMTP id <2005102815521811200ehespe>; Fri, 28 Oct 2005 15:52:28 +0000 Received: from [64.127.102.91] by 204.127.135.59; Fri, 28 Oct 2005 15:52:17 +0000 From: todd.glassey@att.net To: Michael Ströder , ietf-pkix@imc.org Subject: Re: Public key validation and Proof of possession Date: Fri, 28 Oct 2005 15:52:17 +0000 Message-Id: <102820051552.16936.43624930000B600E000042282160280651970A9C9C0E0409D20B0B019B@att.net> X-Mailer: AT&T Message Center Version 1 (Feb 14 2005) X-Authenticated-Sender: dG9kZC5nbGFzc2V5QGF0dC5uZXQ= Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: -------------- Original message ---------------------- From: Michael Ströder > > Stefan Santesson wrote: > > > > I'm concerned that we are about to enter a dangerous path if we start > > defining extensions for policy aspects. > > A very valid concern. Depends on whether your actually defining the operations policies or the framework for their definition... > > > If we open this can, there are > > many other potential candidates for policy expression extensions and I'm > > not sure we will help the deployment community by going down that path. > > I couldn't agree more. I would disagree. In fact I claim its negligent of this body to not define these. > > How about candidates like "Power and air conditioning", "Water > exposures" and "Fire prevention and protection". I'm pretty sure a > relying participant should be able to check these aspects automagically. ;-) > > > I think this needs careful consideration and I'm not sure the benefit of > > this extension is worth the cost. > > It's my impression that X.509v3 extensions are not fully supported in > today's implementations anyway. Therefore each new extension will likely > not be adopted by implementors but will complicate the standards. > > > My thought is that arithmetic property validation seems feasible even in > > a smart card today and even more, this test can easily be done in the > > system in which the smart card is used. Computation power is > > exponentially increasing and before this extension is generally adopted, > > this might very well be a completely redundant issue. > > +1 > > Ciao, Michael. > From owner-ietf-pkix@mail.imc.org Fri Oct 28 16:19:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVahC-00052l-7j for pkix-archive@megatron.ietf.org; Fri, 28 Oct 2005 16:19:26 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14539 for ; Fri, 28 Oct 2005 16:19:06 -0400 (EDT) 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 j9SJPpl1023861; Fri, 28 Oct 2005 12:25:51 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9SJPpMA023860; Fri, 28 Oct 2005 12:25:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9SJPpeF023851 for ; Fri, 28 Oct 2005 12:25:51 -0700 (PDT) (envelope-from david.cooper@nist.gov) 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 j9SJPkMN016260 for ; Fri, 28 Oct 2005 15:25:48 -0400 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 j9SJPGG3004833 for ; Fri, 28 Oct 2005 15:25:20 -0400 (EDT) Message-ID: <43627B2C.5000908@nist.gov> Date: Fri, 28 Oct 2005 15:25:32 -0400 From: "David A. Cooper" 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: pkix Subject: Re: draft-ietf-pkix-scvp-21.txt References: In-Reply-To: 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: david.cooper@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit All, For those who are interested, I have created a diff file that highlights the differences between draft-ietf-pkix-scvp-20.txt and draft-ietf-pkix-scvp-21.txt. It is available at http://csrc.nist.gov/pki/documents/PKIX/wdiff_draft-ietf-pkix-scvp-20_to_21.html. Dave Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. > > Title : Standard Certificate Validation Protocol (SCVP) > Author(s) : A. Malpani, et al. > Filename : draft-ietf-pkix-scvp-21.txt > Pages : 78 > Date : 2005-10-25 > >SCVP allows a client to delegate certificate path construction and > certificate path validation to a server. The path construction or > validation (e.g. making sure that none of the certificates in the > path are revoked) is performed according to a validation policy, > which contains one or more trust anchors. It allows simplification > of client implementations and use of a set of predefined validation > policies. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-21.txt > > From owner-ietf-pkix@mail.imc.org Fri Oct 28 17:28:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVbmU-0001VC-Kb for pkix-archive@megatron.ietf.org; Fri, 28 Oct 2005 17:28:58 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20887 for ; Fri, 28 Oct 2005 17:28:41 -0400 (EDT) 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 j9SKlNu9033361; Fri, 28 Oct 2005 13:47:23 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9SKlNTm033360; Fri, 28 Oct 2005 13:47:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9SKlMhG033349 for ; Fri, 28 Oct 2005 13:47:22 -0700 (PDT) (envelope-from kent@bbn.com) 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 j9SKkqIg016087; Fri, 28 Oct 2005 16:47:12 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <4361C8DC.2020906@stroeder.com> References: <7.0.0.10.2.20051027092241.05814258@vigilsec.com> <4361C8DC.2020906@stroeder.com> Date: Fri, 28 Oct 2005 14:44:19 -0400 To: Michael =?iso-8859-1?Q?Str=F6der?= From: Stephen Kent Subject: Re: Public key validation and Proof of possession Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j9SKlMhG033355 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id RAA20887 At 8:44 AM +0200 10/28/05, Michael Str=F6der wrote: >Russ Housley wrote: >> >> - Smartcards are still low-end processors. As you point out, they ar= e >> getting more powerful all the time. > >In a real-world project I'd prefer to spend more money for a more >powerful smartcard over messing around with applications which are badly >implemented because the standards are getting too complicated. a fair choice, IF you get to make it. But in many=20 contexts organizations will issue smart cards and=20 users will have no option to spend more for a=20 more powerful model. the decision on how much to=20 spend will be made by the organization, with=20 little of no input from users. > >> - RFID are very low-power devices. I'm sure that more capabilities w= ill >> be added over time. But right now, certificate parsing and validatio= n >> is probably beyond their capabilities. As they become more capable, = I >> think that certificate-based protocols are appropriate in this enviro= nment. >> >> In summary, I do not think it is unreasonable to consider features fo= r >> low-end devices. I believe that there will always be new low-end >> devices appearing, and at some point they may need to handle certific= ates. > >But extending high-end certificate-based protocols to cover low-end >devices likely will make the protocols too complex to be ever securely >implemented. >=3D> PKIX should be limited to where it's applicable in the real world. I suspect that many of us agree that making a=20 standard too complex does have the potential to=20 reduce security. the problem is always deciding=20 where to draw the line. Steve From owner-ietf-pkix@mail.imc.org Fri Oct 28 18:09:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVcPa-0002V5-6g for pkix-archive@megatron.ietf.org; Fri, 28 Oct 2005 18:09:22 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22761 for ; Fri, 28 Oct 2005 18:09:04 -0400 (EDT) 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 j9SLS6S0038858; Fri, 28 Oct 2005 14:28:06 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9SLS6qH038857; Fri, 28 Oct 2005 14:28:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9SLS5Mb038838 for ; Fri, 28 Oct 2005 14:28:05 -0700 (PDT) (envelope-from kent@bbn.com) 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 j9SLRuIE017929; Fri, 28 Oct 2005 17:27:59 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <4701d76c0510271418p28eb9362l8cfcdeba1182a6fc@mail.gmail.com> References: <4701d76c0510271416i3e73cf63i74696df0009477cb@mail.gmail.com> <4701d76c0510271418p28eb9362l8cfcdeba1182a6fc@mail.gmail.com> Date: Fri, 28 Oct 2005 14:48:46 -0400 To: Terry Hayes From: Stephen Kent Subject: RE: Public key validation and Proof of possession Cc: ietf-pkix@imc.org Content-Type: multipart/alternative; boundary="============_-1081587606==_ma============" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --============_-1081587606==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 2:18 PM -0700 10/27/05, Terry Hayes wrote: >What's wrong with defining a new policy qualifier? > >id-qt-ietf-pkix-key-validation-performed >id-qt-ietf-pkix-proof-of-posession-performed (owner-posession-of-key-assured?) > >These would generally be asserted only in the end-entity certificates. > >Terry Hayes > 3280 suggests that policy qualifiers NOT be used in general. If we adopted this approach we would have to revisit that advice. "To promote interoperability, this profile RECOMMENDS that policy information terms consist of only an OID. Where an OID alone is insufficient, this profile strongly recommends that use of qualifiers be limited to those identified in this section." Steve --============_-1081587606==_ma============ Content-Type: text/html; charset="us-ascii" RE: Public key validation and Proof of possession
At 2:18 PM -0700 10/27/05, Terry Hayes wrote:
What's wrong with defining a new policy qualifier?
 
id-qt-ietf-pkix-key-validation-performed
id-qt-ietf-pkix-proof-of-posession-performed (owner-posession-of-key-assured?)
 
These would generally be asserted only in the end-entity certificates.
 
Terry Hayes


3280 suggests that policy qualifiers NOT be used in general. If we adopted this approach we would have to revisit that advice.

   "To promote interoperability, this profile RECOMMENDS that policy
   information terms consist of only an OID.  Where an OID alone is
   insufficient, this profile strongly recommends that use of
   qualifiers be limited to those identified in this section."


Steve
--============_-1081587606==_ma============-- From owner-ietf-pkix@mail.imc.org Fri Oct 28 18:19:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVcZi-0000yv-Sk for pkix-archive@megatron.ietf.org; Fri, 28 Oct 2005 18:19:50 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23402 for ; Fri, 28 Oct 2005 18:19:33 -0400 (EDT) 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 j9SLS4Hn038849; Fri, 28 Oct 2005 14:28:04 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9SLS4Cv038848; Fri, 28 Oct 2005 14:28:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9SLS3Lq038835 for ; Fri, 28 Oct 2005 14:28:03 -0700 (PDT) (envelope-from kent@bbn.com) 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 j9SLRuIC017929; Fri, 28 Oct 2005 17:27:57 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <4361C8DC.2020906@stroeder.com> References: <7.0.0.10.2.20051027092241.05814258@vigilsec.com> <4361C8DC.2020906@stroeder.com> Date: Fri, 28 Oct 2005 14:44:19 -0400 To: Michael =?iso-8859-1?Q?Str=F6der?= From: Stephen Kent Subject: Re: Public key validation and Proof of possession Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j9SLS3Lq038843 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id SAA23402 At 8:44 AM +0200 10/28/05, Michael Str=F6der wrote: >Russ Housley wrote: >> >> - Smartcards are still low-end processors. As you point out, they ar= e >> getting more powerful all the time. > >In a real-world project I'd prefer to spend more money for a more >powerful smartcard over messing around with applications which are badly >implemented because the standards are getting too complicated. a fair choice, IF you get to make it. But in many=20 contexts organizations will issue smart cards and=20 users will have no option to spend more for a=20 more powerful model. the decision on how much to=20 spend will be made by the organization, with=20 little of no input from users. > >> - RFID are very low-power devices. I'm sure that more capabilities w= ill >> be added over time. But right now, certificate parsing and validatio= n >> is probably beyond their capabilities. As they become more capable, = I >> think that certificate-based protocols are appropriate in this enviro= nment. >> >> In summary, I do not think it is unreasonable to consider features fo= r >> low-end devices. I believe that there will always be new low-end >> devices appearing, and at some point they may need to handle certific= ates. > >But extending high-end certificate-based protocols to cover low-end >devices likely will make the protocols too complex to be ever securely >implemented. >=3D> PKIX should be limited to where it's applicable in the real world. I suspect that many of us agree that making a=20 standard too complex does have the potential to=20 reduce security. the problem is always deciding=20 where to draw the line. Steve From owner-ietf-pkix@mail.imc.org Mon Oct 31 13:59:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWes4-0001pu-JU for pkix-archive@megatron.ietf.org; Mon, 31 Oct 2005 13:59:04 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29174 for ; Mon, 31 Oct 2005 13:58:45 -0500 (EST) 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 j9VHpkNZ091865; Mon, 31 Oct 2005 09:51:46 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9VHpk3I091864; Mon, 31 Oct 2005 09:51:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9VHpjlL091855 for ; Mon, 31 Oct 2005 09:51:46 -0800 (PST) (envelope-from kent@bbn.com) 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 j9VHpbIG008722 for ; Mon, 31 Oct 2005 12:51:39 -0500 (EST) Mime-Version: 1.0 Message-Id: Date: Mon, 31 Oct 2005 12:51:48 -0500 To: ietf-pkix@imc.org From: Stephen Kent Subject: updated agenda 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: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: http://www3.ietf.org/proceedings/05nov/agenda/pkix.htm 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 j9VHpkNZ091865; Mon, 31 Oct 2005 09:51:46 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9VHpk3I091864; Mon, 31 Oct 2005 09:51:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9VHpjlL091855 for ; Mon, 31 Oct 2005 09:51:46 -0800 (PST) (envelope-from kent@bbn.com) 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 j9VHpbIG008722 for ; Mon, 31 Oct 2005 12:51:39 -0500 (EST) Mime-Version: 1.0 Message-Id: Date: Mon, 31 Oct 2005 12:51:48 -0500 To: ietf-pkix@imc.org From: Stephen Kent Subject: updated agenda 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: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: http://www3.ietf.org/proceedings/05nov/agenda/pkix.htm 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 j9SLS6S0038858; Fri, 28 Oct 2005 14:28:06 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9SLS6qH038857; Fri, 28 Oct 2005 14:28:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9SLS5Mb038838 for ; Fri, 28 Oct 2005 14:28:05 -0700 (PDT) (envelope-from kent@bbn.com) 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 j9SLRuIE017929; Fri, 28 Oct 2005 17:27:59 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <4701d76c0510271418p28eb9362l8cfcdeba1182a6fc@mail.gmail.com> References: <4701d76c0510271416i3e73cf63i74696df0009477cb@mail.gmail.com> <4701d76c0510271418p28eb9362l8cfcdeba1182a6fc@mail.gmail.com> Date: Fri, 28 Oct 2005 14:48:46 -0400 To: Terry Hayes From: Stephen Kent Subject: RE: Public key validation and Proof of possession Cc: ietf-pkix@imc.org Content-Type: multipart/alternative; boundary="============_-1081587606==_ma============" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --============_-1081587606==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 2:18 PM -0700 10/27/05, Terry Hayes wrote: >What's wrong with defining a new policy qualifier? > >id-qt-ietf-pkix-key-validation-performed >id-qt-ietf-pkix-proof-of-posession-performed (owner-posession-of-key-assured?) > >These would generally be asserted only in the end-entity certificates. > >Terry Hayes > 3280 suggests that policy qualifiers NOT be used in general. If we adopted this approach we would have to revisit that advice. "To promote interoperability, this profile RECOMMENDS that policy information terms consist of only an OID. Where an OID alone is insufficient, this profile strongly recommends that use of qualifiers be limited to those identified in this section." Steve --============_-1081587606==_ma============ Content-Type: text/html; charset="us-ascii" RE: Public key validation and Proof of possession
At 2:18 PM -0700 10/27/05, Terry Hayes wrote:
What's wrong with defining a new policy qualifier?
 
id-qt-ietf-pkix-key-validation-performed
id-qt-ietf-pkix-proof-of-posession-performed (owner-posession-of-key-assured?)
 
These would generally be asserted only in the end-entity certificates.
 
Terry Hayes


3280 suggests that policy qualifiers NOT be used in general. If we adopted this approach we would have to revisit that advice.

   "To promote interoperability, this profile RECOMMENDS that policy
   information terms consist of only an OID.  Where an OID alone is
   insufficient, this profile strongly recommends that use of
   qualifiers be limited to those identified in this section."


Steve
--============_-1081587606==_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 j9SLS4Hn038849; Fri, 28 Oct 2005 14:28:04 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9SLS4Cv038848; Fri, 28 Oct 2005 14:28:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9SLS3Lq038835 for ; Fri, 28 Oct 2005 14:28:03 -0700 (PDT) (envelope-from kent@bbn.com) 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 j9SLRuIC017929; Fri, 28 Oct 2005 17:27:57 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <4361C8DC.2020906@stroeder.com> References: <7.0.0.10.2.20051027092241.05814258@vigilsec.com> <4361C8DC.2020906@stroeder.com> Date: Fri, 28 Oct 2005 14:44:19 -0400 To: Michael =?iso-8859-1?Q?Str=F6der?= From: Stephen Kent Subject: Re: Public key validation and Proof of possession Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j9SLS3Lq038843 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 8:44 AM +0200 10/28/05, Michael Ströder wrote: >Russ Housley wrote: >> >> - Smartcards are still low-end processors. As you point out, they are >> getting more powerful all the time. > >In a real-world project I'd prefer to spend more money for a more >powerful smartcard over messing around with applications which are badly >implemented because the standards are getting too complicated. a fair choice, IF you get to make it. But in many contexts organizations will issue smart cards and users will have no option to spend more for a more powerful model. the decision on how much to spend will be made by the organization, with little of no input from users. > >> - RFID are very low-power devices. I'm sure that more capabilities will >> be added over time. But right now, certificate parsing and validation >> is probably beyond their capabilities. As they become more capable, I >> think that certificate-based protocols are appropriate in this environment. >> >> In summary, I do not think it is unreasonable to consider features for >> low-end devices. I believe that there will always be new low-end >> devices appearing, and at some point they may need to handle certificates. > >But extending high-end certificate-based protocols to cover low-end >devices likely will make the protocols too complex to be ever securely >implemented. >=> PKIX should be limited to where it's applicable in the real world. I suspect that many of us agree that making a standard too complex does have the potential to reduce security. the problem is always deciding where to draw the line. 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 j9SKlNu9033361; Fri, 28 Oct 2005 13:47:23 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9SKlNTm033360; Fri, 28 Oct 2005 13:47:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9SKlMhG033349 for ; Fri, 28 Oct 2005 13:47:22 -0700 (PDT) (envelope-from kent@bbn.com) 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 j9SKkqIg016087; Fri, 28 Oct 2005 16:47:12 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <4361C8DC.2020906@stroeder.com> References: <7.0.0.10.2.20051027092241.05814258@vigilsec.com> <4361C8DC.2020906@stroeder.com> Date: Fri, 28 Oct 2005 14:44:19 -0400 To: Michael =?iso-8859-1?Q?Str=F6der?= From: Stephen Kent Subject: Re: Public key validation and Proof of possession Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j9SKlMhG033355 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 8:44 AM +0200 10/28/05, Michael Ströder wrote: >Russ Housley wrote: >> >> - Smartcards are still low-end processors. As you point out, they are >> getting more powerful all the time. > >In a real-world project I'd prefer to spend more money for a more >powerful smartcard over messing around with applications which are badly >implemented because the standards are getting too complicated. a fair choice, IF you get to make it. But in many contexts organizations will issue smart cards and users will have no option to spend more for a more powerful model. the decision on how much to spend will be made by the organization, with little of no input from users. > >> - RFID are very low-power devices. I'm sure that more capabilities will >> be added over time. But right now, certificate parsing and validation >> is probably beyond their capabilities. As they become more capable, I >> think that certificate-based protocols are appropriate in this environment. >> >> In summary, I do not think it is unreasonable to consider features for >> low-end devices. I believe that there will always be new low-end >> devices appearing, and at some point they may need to handle certificates. > >But extending high-end certificate-based protocols to cover low-end >devices likely will make the protocols too complex to be ever securely >implemented. >=> PKIX should be limited to where it's applicable in the real world. I suspect that many of us agree that making a standard too complex does have the potential to reduce security. the problem is always deciding where to draw the line. 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 j9SJPpl1023861; Fri, 28 Oct 2005 12:25:51 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9SJPpMA023860; Fri, 28 Oct 2005 12:25:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9SJPpeF023851 for ; Fri, 28 Oct 2005 12:25:51 -0700 (PDT) (envelope-from david.cooper@nist.gov) 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 j9SJPkMN016260 for ; Fri, 28 Oct 2005 15:25:48 -0400 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 j9SJPGG3004833 for ; Fri, 28 Oct 2005 15:25:20 -0400 (EDT) Message-ID: <43627B2C.5000908@nist.gov> Date: Fri, 28 Oct 2005 15:25:32 -0400 From: "David A. Cooper" 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: pkix Subject: Re: draft-ietf-pkix-scvp-21.txt References: In-Reply-To: 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: david.cooper@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, For those who are interested, I have created a diff file that highlights the differences between draft-ietf-pkix-scvp-20.txt and draft-ietf-pkix-scvp-21.txt. It is available at http://csrc.nist.gov/pki/documents/PKIX/wdiff_draft-ietf-pkix-scvp-20_to_21.html. Dave Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. > > Title : Standard Certificate Validation Protocol (SCVP) > Author(s) : A. Malpani, et al. > Filename : draft-ietf-pkix-scvp-21.txt > Pages : 78 > Date : 2005-10-25 > >SCVP allows a client to delegate certificate path construction and > certificate path validation to a server. The path construction or > validation (e.g. making sure that none of the certificates in the > path are revoked) is performed according to a validation policy, > which contains one or more trust anchors. It allows simplification > of client implementations and use of a set of predefined validation > policies. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-21.txt > > 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 j9SFqZaE097977; Fri, 28 Oct 2005 08:52:35 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9SFqZPG097976; Fri, 28 Oct 2005 08:52:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9SFqYuU097968 for ; Fri, 28 Oct 2005 08:52:35 -0700 (PDT) (envelope-from todd.glassey@att.net) Received: from 204.127.135.59 ([204.127.135.59]) by worldnet.att.net (mtiwmhc12) with SMTP id <2005102815521811200ehespe>; Fri, 28 Oct 2005 15:52:28 +0000 Received: from [64.127.102.91] by 204.127.135.59; Fri, 28 Oct 2005 15:52:17 +0000 From: todd.glassey@att.net To: Michael Ströder , ietf-pkix@imc.org Subject: Re: Public key validation and Proof of possession Date: Fri, 28 Oct 2005 15:52:17 +0000 Message-Id: <102820051552.16936.43624930000B600E000042282160280651970A9C9C0E0409D20B0B019B@att.net> X-Mailer: AT&T Message Center Version 1 (Feb 14 2005) X-Authenticated-Sender: dG9kZC5nbGFzc2V5QGF0dC5uZXQ= Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: -------------- Original message ---------------------- From: Michael Ströder > > Stefan Santesson wrote: > > > > I'm concerned that we are about to enter a dangerous path if we start > > defining extensions for policy aspects. > > A very valid concern. Depends on whether your actually defining the operations policies or the framework for their definition... > > > If we open this can, there are > > many other potential candidates for policy expression extensions and I'm > > not sure we will help the deployment community by going down that path. > > I couldn't agree more. I would disagree. In fact I claim its negligent of this body to not define these. > > How about candidates like "Power and air conditioning", "Water > exposures" and "Fire prevention and protection". I'm pretty sure a > relying participant should be able to check these aspects automagically. ;-) > > > I think this needs careful consideration and I'm not sure the benefit of > > this extension is worth the cost. > > It's my impression that X.509v3 extensions are not fully supported in > today's implementations anyway. Therefore each new extension will likely > not be adopted by implementors but will complicate the standards. > > > My thought is that arithmetic property validation seems feasible even in > > a smart card today and even more, this test can easily be done in the > > system in which the smart card is used. Computation power is > > exponentially increasing and before this extension is generally adopted, > > this might very well be a completely redundant issue. > > +1 > > Ciao, Michael. > 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 j9SDaVNQ067805; Fri, 28 Oct 2005 06:36:31 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9SDaVrG067804; Fri, 28 Oct 2005 06:36:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9SDaUBt067797 for ; Fri, 28 Oct 2005 06:36:31 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 9AC30E0049; Fri, 28 Oct 2005 09:36:28 -0400 (EDT) To: ietf-pkix@imc.org Cc: jhutz@cmu.edu Subject: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos From: Sam Hartman Date: Fri, 28 Oct 2005 09:12:06 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) Content-Type: multipart/mixed; boundary="=-=-=" MIME-Version: 1.0 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=-=-= 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. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from 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: 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 ; 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 ; 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: ietf-krb-wg-outgoing@anl.gov Received: from mailhost.anl.gov (localhost [127.0.0.1]) by localhost.ctd.anl.gov (Postfix) with ESMTP id E87EA26D for ; 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: ietf-krb-wg@anl.gov Delivered-To: ietf-krb-wg@anl.gov Received: from mailhost.anl.gov (localhost [127.0.0.1]) by localhost.ctd.anl.gov (Postfix) with ESMTP id 5D96227F for ; 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 ; 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 ; 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/qQraCNyY7Gmr6mlG7xV3U@JHUTZ-DYN0.PC.CS.CMU.EDU [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=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 23 Oct 2005 22:06:05 -0400 (EDT) Date: Sun, 23 Oct 2005 22:06:00 -0400 From: Jeffrey Hutzelman To: ietf-krb-wg@anl.gov Cc: Jeffrey Hutzelman Subject: LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos Message-ID: <6F5E31C582712026A72741F6@bistromath.pc.cs.cmu.edu> Originator-Info: login-token=Mulberry:01ouPFOwxLOq/uLj281WH1qjlV/GYpFz4PWPOg2GM=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) Sender: owner-ietf-krb-wg@mailhost.anl.gov 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, ietf-krb-wg@anl.gov, 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) Chair, IETF Kerberos Working Group Carnegie Mellon University - Pittsburgh, PA --=-=-=-- 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 j9SCZCPm062332; Fri, 28 Oct 2005 05:35:12 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9SCZCmu062331; Fri, 28 Oct 2005 05:35:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from srv1.int.stroeder.com (168-11-124-83.dsl.3u.net [83.124.11.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9SCZAub062319 for ; Fri, 28 Oct 2005 05:35:11 -0700 (PDT) (envelope-from michael@stroeder.com) Received: from localhost (localhost [127.0.0.1]) by srv1.int.stroeder.com (Postfix) with ESMTP id 69ED31EF8 for ; Fri, 28 Oct 2005 14:35:05 +0200 (CEST) Received: from srv1.int.stroeder.com ([127.0.0.1]) by localhost (srv1 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14417-05 for ; Fri, 28 Oct 2005 14:34:52 +0200 (CEST) Received: from [10.1.1.5] (unknown [10.1.1.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Michael Stroeder", Issuer "Thawte Personal Freemail Issuing CA" (not verified)) by srv1.int.stroeder.com (Postfix) with ESMTP id B67681F06 for ; Fri, 28 Oct 2005 14:34:41 +0200 (CEST) Message-ID: <4361C8DC.2020906@stroeder.com> Date: Fri, 28 Oct 2005 08:44:44 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: Public key validation and Proof of possession References: <7.0.0.10.2.20051027092241.05814258@vigilsec.com> In-Reply-To: <7.0.0.10.2.20051027092241.05814258@vigilsec.com> X-Enigmail-Version: 0.92.1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at int.stroeder.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ Housley wrote: > > - Smartcards are still low-end processors. As you point out, they are > getting more powerful all the time. In a real-world project I'd prefer to spend more money for a more powerful smartcard over messing around with applications which are badly implemented because the standards are getting too complicated. > - RFID are very low-power devices. I'm sure that more capabilities will > be added over time. But right now, certificate parsing and validation > is probably beyond their capabilities. As they become more capable, I > think that certificate-based protocols are appropriate in this environment. > > In summary, I do not think it is unreasonable to consider features for > low-end devices. I believe that there will always be new low-end > devices appearing, and at some point they may need to handle certificates. But extending high-end certificate-based protocols to cover low-end devices likely will make the protocols too complex to be ever securely implemented. => PKIX should be limited to where it's applicable in the real world. Ciao, Michael. 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 j9SCZ5Sv062316; Fri, 28 Oct 2005 05:35:05 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9SCZ5sK062315; Fri, 28 Oct 2005 05:35:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from srv1.int.stroeder.com (168-11-124-83.dsl.3u.net [83.124.11.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9SCZ3ge062293 for ; Fri, 28 Oct 2005 05:35:04 -0700 (PDT) (envelope-from michael@stroeder.com) Received: from localhost (localhost [127.0.0.1]) by srv1.int.stroeder.com (Postfix) with ESMTP id DCFB71F03 for ; Fri, 28 Oct 2005 14:34:56 +0200 (CEST) Received: from srv1.int.stroeder.com ([127.0.0.1]) by localhost (srv1 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13790-10 for ; Fri, 28 Oct 2005 14:34:41 +0200 (CEST) Received: from [10.1.1.5] (unknown [10.1.1.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Michael Stroeder", Issuer "Thawte Personal Freemail Issuing CA" (not verified)) by srv1.int.stroeder.com (Postfix) with ESMTP id CCC511F02 for ; Fri, 28 Oct 2005 14:34:40 +0200 (CEST) Message-ID: <4361C74A.1080900@stroeder.com> Date: Fri, 28 Oct 2005 08:38:02 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: Public key validation and Proof of possession References: In-Reply-To: X-Enigmail-Version: 0.92.1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at int.stroeder.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stefan Santesson wrote: > > I'm concerned that we are about to enter a dangerous path if we start > defining extensions for policy aspects. A very valid concern. > If we open this can, there are > many other potential candidates for policy expression extensions and I'm > not sure we will help the deployment community by going down that path. I couldn't agree more. How about candidates like "Power and air conditioning", "Water exposures" and "Fire prevention and protection". I'm pretty sure a relying participant should be able to check these aspects automagically. ;-) > I think this needs careful consideration and I'm not sure the benefit of > this extension is worth the cost. It's my impression that X.509v3 extensions are not fully supported in today's implementations anyway. Therefore each new extension will likely not be adopted by implementors but will complicate the standards. > My thought is that arithmetic property validation seems feasible even in > a smart card today and even more, this test can easily be done in the > system in which the smart card is used. Computation power is > exponentially increasing and before this extension is generally adopted, > this might very well be a completely redundant issue. +1 Ciao, Michael. 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 j9RLJ25I070619; Thu, 27 Oct 2005 14:19:02 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9RLJ2MA070618; Thu, 27 Oct 2005 14:19:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9RLJ1RU070610 for ; Thu, 27 Oct 2005 14:19:02 -0700 (PDT) (envelope-from tdchayes@gmail.com) Received: by xproxy.gmail.com with SMTP id t6so63657wxc for ; Thu, 27 Oct 2005 14:18:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=clMF7uKYxWpEGM1k60jbL1RaRc2g8Oy4T3RPbbnUrOU+FAetoHEi0CPCk8JbPS36BUgFJG9unNQfS8uWnMSQEwxl4TSu544t/Cg6/rws9kY48P9KE1uhISkDT3wh6rfhzZR5myIlCK9R+8uAcWWqEAyGgYXnPC5vlrd6PaHg1lk= Received: by 10.65.137.14 with SMTP id p14mr1566531qbn; Thu, 27 Oct 2005 14:18:56 -0700 (PDT) Received: by 10.65.141.18 with HTTP; Thu, 27 Oct 2005 14:18:56 -0700 (PDT) Message-ID: <4701d76c0510271418p28eb9362l8cfcdeba1182a6fc@mail.gmail.com> Date: Thu, 27 Oct 2005 14:18:56 -0700 From: Terry Hayes To: ietf-pkix@imc.org Subject: RE: Public key validation and Proof of possession In-Reply-To: <4701d76c0510271416i3e73cf63i74696df0009477cb@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_48544_14365955.1130447936580" References: <4701d76c0510271416i3e73cf63i74696df0009477cb@mail.gmail.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ------=_Part_48544_14365955.1130447936580 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline What's wrong with defining a new policy qualifier? id-qt-ietf-pkix-key-validation-performed id-qt-ietf-pkix-proof-of-posession-performed (owner-posession-of-key-assured?) These would generally be asserted only in the end-entity certificates. Terry Hayes On 10/27/05, Stefan Santesson wrote: > > > It is not a proposal. > I just wanted to add it to the picture. > > I'm just generally worried about adding new extensions for every > specific certificate policy aspect that can be argued to be useful to > have explicitly encoded. > > If we go that path, we may need to consider a common framework for it. > qcStatement is one, suitable or not. > > > Stefan Santesson > Program Manager, Standards Liaison > Windows Security > > > ------=_Part_48544_14365955.1130447936580 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
What's wrong with defining a new policy qualifier?
 
id-qt-ietf-pkix-key-validation-performed
id-qt-ietf-pkix-proof-of-posession-performed (owner-posession-of-key-a= ssured?)
 
These would generally be asserted only in the end-entity certificates.=
 
Terry Hayes

 
On 10/27/05, Stefan Santesson <stefans@= microsoft.com > wrote:=20

It is not a proposal.
I j= ust wanted to add it to the picture.

I'm just generally worried abou= t adding new extensions for every=20
specific certificate policy aspect that can be argued to be useful tohave explicitly encoded.

If we go that path, we may need to consid= er a common framework for it.
qcStatement is one, suitable or not.


Stefan Santesson
Program Manager, Standards Liaison
Windows S= ecurity


------=_Part_48544_14365955.1130447936580-- 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 j9RIpirJ048625; Thu, 27 Oct 2005 11:51:44 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9RIpipq048624; Thu, 27 Oct 2005 11:51:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9RIphKH048614 for ; Thu, 27 Oct 2005 11:51:43 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Oct 2005 19:51:37 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Public key validation and Proof of possession Date: Thu, 27 Oct 2005 19:51:36 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Public key validation and Proof of possession Thread-Index: AcXbJVgdZnUCBujsQLmqdTDyau88sQAAGFBQ From: "Stefan Santesson" To: "Russ Housley" Cc: X-OriginalArrivalTime: 27 Oct 2005 18:51:37.0821 (UTC) FILETIME=[75E708D0:01C5DB27] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j9RIpiKH048618 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It is not a proposal. I just wanted to add it to the picture. I'm just generally worried about adding new extensions for every specific certificate policy aspect that can be argued to be useful to have explicitly encoded. If we go that path, we may need to consider a common framework for it. qcStatement is one, suitable or not. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: den 27 oktober 2005 20:36 > To: Stefan Santesson > Cc: ietf-pkix@imc.org > Subject: RE: Public key validation and Proof of possession > > Stefan: > > I guess that qcStatements leads one to think QC, just from the name. > > That aside, what would the difference be to an implementor? In one > case, a new OID for an extension must be recognized. In the other > case, a new OID must be recognized within the qcStatements > extension. This is a bigger deal to an implementor if they do not > already support the extensions specified in RFC 3739. > > That said, if the PKIX WG is happier with this being defined as a > standards-track qcStatement it will meet my needs. > > Russ > > > At 02:12 PM 10/27/2005, Stefan Santesson wrote: > >I don't see why not. > > > >When RFC 3739 was updated from 3039, one of the purposes was to clarify > >that the components of the standard is not limited for use in QC. > > > >"This specification is intended to support this class of certificates, > >but its scope is not limited to this application." > > > >For example, if you want to include a reference to a picture in a non QC > >you could use the biomentricInfo ext of RFC 3739 instead of defining a > >new extension for non QC use. Same for the RFC 3739 defined attributes > >etc. > > > >The qcStatement extension already defines a framework for adding more > >granular information of policy aspects that is already defined by a > >certificate policy but which can not be explicitly decoded from a CP > >OID. > > > >It would certainly satisfy SP 800-56. > > > > > > > >Stefan Santesson > >Program Manager, Standards Liaison > >Windows Security > > > > > > > -----Original Message----- > > > From: Russ Housley [mailto:housley@vigilsec.com] > > > Sent: den 27 oktober 2005 19:58 > > > To: Stefan Santesson; ietf-pkix@imc.org > > > Subject: RE: Public key validation and Proof of possession > > > > > > I have not assumed that the certificates would be Qualified > >Certificates. > > > > > > I do not think that the qcStatement extension should be used in > > > non-Qualified Certificates. > > > > > > Russ > > > > > > At 01:44 PM 10/27/2005, Stefan Santesson wrote: > > > >Have you considered using the qcStatement extension in RFC 3739, it's > > > >actually designed to deal with things like this. 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 j9RIaOH0047032; Thu, 27 Oct 2005 11:36:24 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9RIaOLY047031; Thu, 27 Oct 2005 11:36:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9RIaNZ5047024 for ; Thu, 27 Oct 2005 11:36:24 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 5446 invoked by uid 0); 27 Oct 2005 18:35:31 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.238.33) by woodstock.binhost.com with SMTP; 27 Oct 2005 18:35:31 -0000 Message-Id: <7.0.0.10.2.20051027142805.058da930@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta) Date: Thu, 27 Oct 2005 14:35:34 -0400 To: "Stefan Santesson" From: Russ Housley Subject: RE: Public key validation and Proof of possession Cc: ietf-pkix@imc.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stefan: I guess that qcStatements leads one to think QC, just from the name. That aside, what would the difference be to an implementor? In one case, a new OID for an extension must be recognized. In the other case, a new OID must be recognized within the qcStatements extension. This is a bigger deal to an implementor if they do not already support the extensions specified in RFC 3739. That said, if the PKIX WG is happier with this being defined as a standards-track qcStatement it will meet my needs. Russ At 02:12 PM 10/27/2005, Stefan Santesson wrote: >I don't see why not. > >When RFC 3739 was updated from 3039, one of the purposes was to clarify >that the components of the standard is not limited for use in QC. > >"This specification is intended to support this class of certificates, >but its scope is not limited to this application." > >For example, if you want to include a reference to a picture in a non QC >you could use the biomentricInfo ext of RFC 3739 instead of defining a >new extension for non QC use. Same for the RFC 3739 defined attributes >etc. > >The qcStatement extension already defines a framework for adding more >granular information of policy aspects that is already defined by a >certificate policy but which can not be explicitly decoded from a CP >OID. > >It would certainly satisfy SP 800-56. > > > >Stefan Santesson >Program Manager, Standards Liaison >Windows Security > > > > -----Original Message----- > > From: Russ Housley [mailto:housley@vigilsec.com] > > Sent: den 27 oktober 2005 19:58 > > To: Stefan Santesson; ietf-pkix@imc.org > > Subject: RE: Public key validation and Proof of possession > > > > I have not assumed that the certificates would be Qualified >Certificates. > > > > I do not think that the qcStatement extension should be used in > > non-Qualified Certificates. > > > > Russ > > > > At 01:44 PM 10/27/2005, Stefan Santesson wrote: > > >Have you considered using the qcStatement extension in RFC 3739, it's > > >actually designed to deal with things like this. 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 j9RICnJD044580; Thu, 27 Oct 2005 11:12:49 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9RICn5g044579; Thu, 27 Oct 2005 11:12:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9RIClo7044524 for ; Thu, 27 Oct 2005 11:12:48 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Oct 2005 19:12:41 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Public key validation and Proof of possession Date: Thu, 27 Oct 2005 19:12:40 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Public key validation and Proof of possession Thread-Index: AcXbIA44A6qHkx1iSVCPVNmwN99CYgAAMN3Q From: "Stefan Santesson" To: "Russ Housley" , X-OriginalArrivalTime: 27 Oct 2005 18:12:41.0879 (UTC) FILETIME=[05929270:01C5DB22] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j9RICmo7044569 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I don't see why not. When RFC 3739 was updated from 3039, one of the purposes was to clarify that the components of the standard is not limited for use in QC. "This specification is intended to support this class of certificates, but its scope is not limited to this application." For example, if you want to include a reference to a picture in a non QC you could use the biomentricInfo ext of RFC 3739 instead of defining a new extension for non QC use. Same for the RFC 3739 defined attributes etc. The qcStatement extension already defines a framework for adding more granular information of policy aspects that is already defined by a certificate policy but which can not be explicitly decoded from a CP OID. It would certainly satisfy SP 800-56. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: den 27 oktober 2005 19:58 > To: Stefan Santesson; ietf-pkix@imc.org > Subject: RE: Public key validation and Proof of possession > > I have not assumed that the certificates would be Qualified Certificates. > > I do not think that the qcStatement extension should be used in > non-Qualified Certificates. > > Russ > > At 01:44 PM 10/27/2005, Stefan Santesson wrote: > >Have you considered using the qcStatement extension in RFC 3739, it's > >actually designed to deal with things like this. 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 j9RI9fbS044015; Thu, 27 Oct 2005 11:09:41 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9RI9f0P044014; Thu, 27 Oct 2005 11:09:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9RI9e3M044006 for ; Thu, 27 Oct 2005 11:09:40 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 11655 invoked by uid 0); 27 Oct 2005 17:57:45 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.238.33) by woodstock.binhost.com with SMTP; 27 Oct 2005 17:57:45 -0000 Message-Id: <7.0.0.10.2.20051027135635.058dac78@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta) Date: Thu, 27 Oct 2005 13:57:48 -0400 To: "Stefan Santesson" , From: Russ Housley Subject: RE: Public key validation and Proof of possession In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have not assumed that the certificates would be Qualified Certificates. I do not think that the qcStatement extension should be used in non-Qualified Certificates. Russ At 01:44 PM 10/27/2005, Stefan Santesson wrote: >Have you considered using the qcStatement extension in RFC 3739, it's >actually designed to deal with things like this. 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 j9RHik0e041731; Thu, 27 Oct 2005 10:44:46 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9RHikHv041730; Thu, 27 Oct 2005 10:44:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9RHiiUZ041717 for ; Thu, 27 Oct 2005 10:44:45 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Oct 2005 18:44:39 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Public key validation and Proof of possession Date: Thu, 27 Oct 2005 18:44:37 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Public key validation and Proof of possession Thread-Index: AcXa+45Q6DRaJyr3TcOZGsFK8X2zKwAIJ6Qg From: "Stefan Santesson" To: "Russ Housley" , X-OriginalArrivalTime: 27 Oct 2005 17:44:39.0211 (UTC) FILETIME=[1A9FCFB0:01C5DB1E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j9RHijUZ041723 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, Yes, there may definitely be new low-end devices. But how many low-end devices do validate a large number of certificates from other entities on its own? Have you considered using the qcStatement extension in RFC 3739, it's actually designed to deal with things like this. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: den 27 oktober 2005 15:37 > To: Stefan Santesson; ietf-pkix@imc.org > Subject: RE: Public key validation and Proof of possession > > Stefan: > > I think that there will always be low end devices. Consider the history. > > - Personal computers used to be very simple systems, especially > before the IBM PC. Remember the Intel 8080? A very large machine > had 32 Kbytes of RAM, and non-volatile storage was 8-inch floppy disk. > > - Hand-held computers were originally very low-end computers. They > have come a long way, and the power management has significantly > helped with battery life. > > - Mobile phones did not really include Internet capabilities at > first, but when they were added, WAP was used to accommodate the > low-end processing environment. When 32-bit processors appeared in > mobile phones, mainstream Internet protocols were used in favor of WAP. > > - Smartcards are still low-end processors. As you point out, they > are getting more powerful all the time. > > - RFID are very low-power devices. I'm sure that more capabilities > will be added over time. But right now, certificate parsing and > validation is probably beyond their capabilities. As they become > more capable, I think that certificate-based protocols are > appropriate in this environment. > > In summary, I do not think it is unreasonable to consider features > for low-end devices. I believe that there will always be new low-end > devices appearing, and at some point they may need to handle certificates. > > Russ > > At 05:37 PM 10/26/2005, Stefan Santesson wrote: > >Russ, > > > >I'm concerned that we are about to enter a dangerous path if we start > >defining extensions for policy aspects. If we open this can, there are > >many other potential candidates for policy expression extensions and I'm > >not sure we will help the deployment community by going down that path. > > > >I think this needs careful consideration and I'm not sure the benefit of > >this extension is worth the cost. > > > >My thought is that arithmetic property validation seems feasible even in > >a smart card today and even more, this test can easily be done in the > >system in which the smart card is used. Computation power is > >exponentially increasing and before this extension is generally adopted, > >this might very well be a completely redundant issue. > > > >POP of encryption keys seems to be such a generic requirement for CAs > >that even policy enforcement through trust anchor chaining might be > >sufficient in most cases. > > > >I think it would be good to have some discussions in Vancouver if this > >can be fitted into the pkix agenda. > > > > > >Stefan Santesson > >Program Manager, Standards Liaison > >Windows Security > > > > > > > -----Original Message----- > > > From: Russ Housley [mailto:housley@vigilsec.com] > > > Sent: den 26 oktober 2005 15:39 > > > To: Stefan Santesson; ietf-pkix@imc.org > > > Subject: RE: Public key validation and Proof of possession > > > > > > Stefan: > > > > > > >On public key validation (arithmetic properties): > > > >It seems to me that the key validation tests specified in 5.6.2.4 and > > > >5.6.2.5 are rather trivial to do locally ( 2= > > >for FFC), at least compared to the cost of using this key for > >anything > > > >useful. I wonder if the cost of making this test isn't actually lower > > > >than parsing the certificate to obtain the assurance from the CA. > > > > > > In low power devices (such as smartcards), avoiding the y^q > > > exponentiation because the relying party is sure that the CA has > > > already performed this check seems useful. > > > > > > >On Proof-of-possession: > > > >Section 5.6.3. of SP 800-56 states: > > > >"For example, this Recommendation requires that parties obtain > >assurance > > > >that they actually possess their own static private keys, and a > >binding > > > >authority is required to obtain assurance of an owner's possession of > > > >the appropriate static private key before binding an identifier to > >the > > > >owner's static public key." > > > > > > > >So since POP always MUST be performed by the CA there seems not to be > > > >the need for diverse policies (POP and non POP). > > > > > > > >Do you agree with these observations or have I missed something? > > > > > > If the first idea is accepted, the proposed extension is no larger by > > > adding the additional bit to indicate that the CA performed POP. The > > > positive statement could be useful. > > > > > > 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 j9RFpiYv028248; Thu, 27 Oct 2005 08:51:44 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9RFpiTi028247; Thu, 27 Oct 2005 08:51:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9RFpgdm028218 for ; Thu, 27 Oct 2005 08:51:42 -0700 (PDT) (envelope-from denis.pinkas@bull.net) 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 SAA14958 for ; Thu, 27 Oct 2005 18:09:01 +0200 Importance: Normal X-Priority: 3 (Normal) Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-21.txt MIME-Version: 1.0 From: denis.pinkas@bull.net To: ietf-pkix@imc.org Date: Thu, 27 Oct 2005 17:52:19 +0200 Message-ID: X-MIMETrack: Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 27/10/2005 17:52:20 Content-Type: multipart/mixed; boundary="=_mixed 00573005C12570A7_=" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=_mixed 00573005C12570A7_= MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 PEZPTlQgZmFjZT0iRGVmYXVsdCBTYW5zIFNlcmlmLCBWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNh LCBzYW5zLXNlcmlmIiBzaXplPTI+PERJVj48UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJ TjogMGNtIDBjbSAwcHQ7IG1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0 b20tYWx0OiBhdXRvIj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTog RU4tVVMiPjxGT05UIHNpemU9Mz48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPlRvIHRoZSBs aXN0LDwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwvUD48UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1B UkdJTjogMGNtIDBjbSAwcHQ7IG1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1i b3R0b20tYWx0OiBhdXRvIj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFn ZTogRU4tVVMiPjxGT05UIHNpemU9Mz48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjwvRk9O VD48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvUD48UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJ TjogMGNtIDBjbSAwcHQ7IG1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0 b20tYWx0OiBhdXRvIj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTog RU4tVVMiPjxGT05UIHNpemU9Mz48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkhlcmUgYXJl IGEgZmV3IGNvbW1lbnRzIG9uIHRoZSBsYXN0IGRyYWZ0LjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwv UD48UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQ7IG1zby1tYXJn aW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0b20tYWx0OiBhdXRvIj48U1BBTiBsYW5n PUVOLVVTIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tVVMiPjxGT05UIGZhY2U9IlRpbWVz IE5ldyBSb21hbiIgc2l6ZT0zPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9QPjxQIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdDsgbXNvLW1hcmdpbi10b3AtYWx0OiBhdXRv OyBtc28tbWFyZ2luLWJvdHRvbS1hbHQ6IGF1dG8iPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9Im1z by1hbnNpLWxhbmd1YWdlOiBFTi1VUyI+PEZPTlQgc2l6ZT0zPjxGT05UIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+VGhlIGNvbmZ1c2lvbiBiZXR3ZWVuIHZhbGlkYXRpb25BbGcgYW5kIFZhbGlkYXRp b25Qb2xpY3kgc3RpbGwgZXhpc3RzLjw/eG1sOm5hbWVzcGFjZSBwcmVmaXggPSBvIG5zID0gInVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgLz48bzpwPjwvbzpwPjwvRk9O VD48L0ZPTlQ+PC9TUEFOPjwvUD48UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNt IDBjbSAwcHQ7IG1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0b20tYWx0 OiBhdXRvIj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tVVMi PjxGT05UIHNpemU9Mz48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjwvRk9OVD48L0ZPTlQ+ PC9TUEFOPiZuYnNwOzwvUD48UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBj bSAwcHQ7IG1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0b20tYWx0OiBh dXRvIj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tVVMiPjxG T05UIHNpemU9Mz48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPk9uIG9uZSBzaWRlIChzZWN0 aW9uIDYuNykgaXQgaXMgc2FpZCB0aGF0IGl0IGlzIG5vdCBtYW5kYXRvcnkgZm9yIGEgc2VydmVy IHRvIHN1cHBvcnQgdGhlJm5ic3A7ImRlZmF1bHQgdmFsaWRhdGlvbiBwb2xpY3kiIGJ1dCBpdCBp cyBzdGlsbCBuZWNlc3NhcnkgZm9yIGEgc2VydmVyIHRvIHN1cHBvcnQgYWxsIGl0cyBwYXJhbWV0 ZXJzICE8QlI+PC9GT05UPjwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0ibXNv LWFuc2ktbGFuZ3VhZ2U6IEVOLVVTIj48Rk9OVCBzaXplPTM+PEZPTlQgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj5JZiB3ZSBoYWQgYSBidW5kbGUgdG8gaW5jbHVkZSBhbGwgd2hhdCBpcyBzcGVjaWZp YyB0byB0aGlzJm5ic3A7ImRlZmF1bHQgdmFsaWRhdGlvbiBwb2xpY3kiLCB0aGVuIHdlIGNvdWxk IG1ha2UgaXQgb3B0aW9uYWwgZm9yIHRoZSBzZXJ2ZXIuPG86cD48L286cD48L0ZPTlQ+PC9GT05U PjwvU1BBTj48L1A+PFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0 OyBtc28tbWFyZ2luLXRvcC1hbHQ6IGF1dG87IG1zby1tYXJnaW4tYm90dG9tLWFsdDogYXV0byI+ PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTIj48Rk9OVCBz aXplPTM+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48L0ZPTlQ+PC9GT05UPjwvU1BBTj4m bmJzcDs8L1A+PFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0OyBt c28tbWFyZ2luLXRvcC1hbHQ6IGF1dG87IG1zby1tYXJnaW4tYm90dG9tLWFsdDogYXV0byI+PFNQ QU4gbGFuZz1FTi1VUyBzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTIj48Rk9OVD48Rk9O VCBmYWNlPSJEZWZhdWx0IE1vbm9zcGFjZSwgQ291cmllciBOZXcsIENvdXJpZXIsIG1vbm9zcGFj ZSI+VGhlIHN5bnRheCBvZiB0aGUgdmFsaWRhdGlvblBvbGljeSBpdGVtIGlzOiA8bzpwPjwvbzpw PjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwvUD48UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJ TjogMGNtIDBjbSAwcHQ7IG1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0 b20tYWx0OiBhdXRvIj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTog RU4tVVMiPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PEZPTlQgc2l6ZT0zPjxGT05UIGZh Y2U9IkRlZmF1bHQgTW9ub3NwYWNlLCBDb3VyaWVyIE5ldywgQ291cmllciwgbW9ub3NwYWNlIiBz aXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFZhbGlkYXRpb25Qb2xpY3kgOjo9IFNFUVVF TkNFIHsgPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB2YWxpZGF0aW9u UG9sUmVmJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFZhbGlkYXRpb25Qb2xSZWYsIDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgdmFsaWRhdGlvbkFsZyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBbMF0gVmFsaWRhdGlvbkFsZyBPUFRJT05BTCwgPEJSPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1c2VyUG9saWN5U2V0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFsxXSBTRVFVRU5DRSBTSVpFICgxLi5NQVgpIE9G IE9CSkVDVCA8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElERU5USUZJRVIg T1BUSU9OQUwsIDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5oaWJp dFBvbGljeU1hcHBpbmcmbmJzcDsgWzJdIEJPT0xFQU4gT1BUSU9OQUwsIDxCUj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVxdWlyZUV4cGxpY2l0UG9saWN5IFszXSBCT09M RUFOIE9QVElPTkFMLCA8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlu aGliaXRBbnlQb2xpY3kmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWzRdIEJPT0xFQU4g T1BUSU9OQUwsIDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHJ1c3RB bmNob3JzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFs1XSBUcnVzdEFuY2hvcnMgT1BUSU9OQUwsIDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsga2V5VXNhZ2VzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFs2XSBTRVFVRU5DRSBvZiBL ZXlVc2FnZSBPUFRJT05BTCwgPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBleHRlbmRlZEtleVVzYWdlcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbN10gU0VRVUVOQ0Ug T0YgS2V5UHVycG9zZUlkIE9QVElPTkFMIH08L0ZPTlQ+IDxvOnA+PC9vOnA+PC9GT05UPjwvRk9O VD48L1NQQU4+PC9QPjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBw dDsgbXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28tbWFyZ2luLWJvdHRvbS1hbHQ6IGF1dG8i PjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUyI+PEZPTlQg c2l6ZT0zPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PC9GT05UPjwvRk9OVD48L1NQQU4+ Jm5ic3A7PC9QPjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdDsg bXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28tbWFyZ2luLWJvdHRvbS1hbHQ6IGF1dG8iPjxT UEFOIGxhbmc9RU4tVVMgc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUyI+PEZPTlQgc2l6 ZT0zPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+VGhlIHRleHQgc3RhdGVzOiCTQXQgYSBt aW5pbXVtLCBjb25mb3JtaW5nIFNDVlAgY2xpZW50IGltcGxlbWVudGF0aW9ucyBNVVNUIHN1cHBv cnQgdGhlIFZhbGlkYXRpb25Qb2xSZWYgaXRlbS6UIDxCUj48L0ZPTlQ+PC9GT05UPjwvU1BBTj48 U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tVVMiPjxGT05UIHNp emU9Mz48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkl0IGFsc28gc3RhdGVzOiAmbmJzcDsm bmJzcDsgIldoZXJlIGEgdmFsaWRhdGlvbiBwb2xpY3kgc3VwcG9ydHMgYWRkaXRpb25hbCBwb2xp Y3ktc3BlY2lmaWMgcGFyYW1ldGVyIHNldHRpbmdzLCB0aGVzZSB2YWx1ZXMgYXJlIHNwZWNpZmll ZCB1c2luZyB0aGUgdmFsUG9sUGFyYW1zIGl0ZW0iLjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwvUD48 UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQ7IG1zby1tYXJnaW4t dG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0b20tYWx0OiBhdXRvIj48U1BBTiBsYW5nPUVO LVVTIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tVVMiPjxGT05UIHNpemU9Mz48Rk9OVCBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1NQ QU4+PC9QPjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdDsgbXNv LW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28tbWFyZ2luLWJvdHRvbS1hbHQ6IGF1dG8iPjxTUEFO IGxhbmc9RU4tVVMgc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUyI+PEZPTlQgc2l6ZT0z PjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+VGhlc2UgcG9saWN5LXNwZWNpZmljIHBhcmFt ZXRlciBzZXR0aW5ncyBhcmUgbm90IEFERElUSU9OQUwgdG8gYW55dGhpbmcgc2luY2UgdGhleSBh cmUgdGhlIG9ubHkgcGFyYW1ldGVycyBhbmQgYWxsIHRoZSBvdGhlcnMsIHN1cHBvc2VkIHRvIGJl IHVzZWQgZm9yIHRoZXkgc28tY2FsbGVkIGRlZmF1bHQgdmFsaWRhdGlvbiBwb2xpY3kgYXJlIHNp bXBseSBpZ25vcmVkLjxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1NQQU4+PC9QPjxQIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdDsgbXNvLW1hcmdpbi10b3AtYWx0 OiBhdXRvOyBtc28tbWFyZ2luLWJvdHRvbS1hbHQ6IGF1dG8iPjxTUEFOIGxhbmc9RU4tVVMgc3R5 bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUyI+PEZPTlQgc2l6ZT0zPjxGT05UIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+PC9GT05UPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9QPjxQIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdDsgbXNvLW1hcmdpbi10b3AtYWx0OiBh dXRvOyBtc28tbWFyZ2luLWJvdHRvbS1hbHQ6IGF1dG8iPjxGT05UIHNpemU9Mz48Rk9OVCBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9Im1zby1hbnNpLWxhbmd1 YWdlOiBFTi1VUyI+VGhlIG5hbWUgdmFsaWRhdGlvbiBwb2xpY3kgaXMgb25lIG1vcmUgbGV2ZWwg b2YgY29tcGxleGl0eSB0aGF0IGFsbCBzZXJ2ZXJzIHdvdWxkIGhhdmUgdG8gc3VwcG9ydC4gVGhl cmUgd2lsbCBub3QgYmUgbWFueSBzZXJ2ZXIgaW1wbGVtZW50YXRpb25zIGNvbXBsaWFudCB3aXRo IHRoaXMgc3BlY2lmaWNhdGlvbiAhIDxCUj48L1NQQU4+PC9GT05UPjwvRk9OVD48U1BBTiBsYW5n PUVOLVVTIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tVVMiPjxGT05UIHNpemU9Mz48Rk9O VCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPk5vdGUgYWxzbyB0aGF0IHRoZSAibmFtZSB2YWxpZGF0 aW9uIGFsZ29yaXRobSIgaXMgZXhjbHVzaXZlIG9mIHRoZSAiYmFzaWMgdmFsaWRhdGlvbiBhbGdv cml0aG0iLiBUaGlzIGRvZXMgbm90IHdvcmsuPG86cD48L286cD48L0ZPTlQ+PC9GT05UPjwvU1BB Tj48L1A+PFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0OyBtc28t bWFyZ2luLXRvcC1hbHQ6IGF1dG87IG1zby1tYXJnaW4tYm90dG9tLWFsdDogYXV0byI+PFNQQU4g bGFuZz1FTi1VUyBzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTIj48Rk9OVCBzaXplPTM+ PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48L0ZPTlQ+PC9GT05UPjwvU1BBTj4mbmJzcDs8 L1A+PFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0OyBtc28tbWFy Z2luLXRvcC1hbHQ6IGF1dG87IG1zby1tYXJnaW4tYm90dG9tLWFsdDogYXV0byI+PFNQQU4gbGFu Zz1FTi1VUyBzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTIj48Rk9OVCBzaXplPTM+PEZP TlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5Gb3IgdGhlIENWUmVzcG9uc2UgdGhlIGNvbmZpZ3Vy YXRpb25JZCAod2FzIHBvbGljeUlEKSBpcyBzdGlsbCBhbiBvZGQgb2JqZWN0LjxvOnA+PC9vOnA+ PC9GT05UPjwvRk9OVD48L1NQQU4+PC9QPjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lO OiAwY20gMGNtIDBwdDsgbXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28tbWFyZ2luLWJvdHRv bS1hbHQ6IGF1dG8iPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBF Ti1VUyI+PEZPTlQgc2l6ZT0zPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PC9GT05UPjwv Rk9OVD48L1NQQU4+Jm5ic3A7PC9QPjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAw Y20gMGNtIDBwdDsgbXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28tbWFyZ2luLWJvdHRvbS1h bHQ6IGF1dG8iPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1V UyI+PEZPTlQgc2l6ZT0zPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+VGhlIHRleHQgc3Rh dGVzOiAmbmJzcDsmbmJzcDsgVGhlIGNvbmZpZ3VyYXRpb24gSUQgcmVwcmVzZW50cyB0aGUgdmVy c2lvbiBvZiB0aGUgZGVmYXVsdCA8U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNw OzwvU1BBTj52YWxpZGF0aW9uIHBvbGljeSB0aGF0IHdhcyB1c2VkIGJ5IHRoZSBTQ1ZQIHNlcnZl ciB3aGVuIGl0IHByb2Nlc3NlZCB0aGUgcmVxdWVzdC4mbmJzcDsgU2VlIHNlY3Rpb24gNi40IGZv ciBkZXRhaWxzLiA8bzpwPjwvbzpwPjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwvUD48UCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQ7IG1zby1tYXJnaW4tdG9wLWFsdDog YXV0bzsgbXNvLW1hcmdpbi1ib3R0b20tYWx0OiBhdXRvIj48Rk9OVCBzaXplPTM+PEZPTlQgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJtc28tYW5zaS1sYW5n dWFnZTogRU4tVVMiPlNpbmNlIHRoaXMgaXRlbSBpcyBzcGVjaWZpYyB0byB0aGUgZGVmYXVsdCB2 YWxpZGF0aW9uIHBvbGljeSBpdCBjYW5ub3QgYmUgbWFuZGF0b3J5LCBidXQgaXQgaXMgISA8L1NQ QU4+PG86cD48L286cD48L0ZPTlQ+PC9GT05UPjwvUD48UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 Ik1BUkdJTjogMGNtIDBjbSAwcHQ7IG1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdp bi1ib3R0b20tYWx0OiBhdXRvIj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJtc28tYW5zaS1sYW5n dWFnZTogRU4tVVMiPjxGT05UIHNpemU9Mz48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjwv Rk9OVD48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvUD48UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1B UkdJTjogMGNtIDBjbSAwcHQ7IG1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1i b3R0b20tYWx0OiBhdXRvIj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFn ZTogRU4tVVMiPjxGT05UIHNpemU9Mz48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPlRoZW4g aG93IGNhbiB3ZSBoYXZlIGEgdmVyc2lvbiBvZiBhIHZhbGlkYXRpb24gcG9saWN5ID8/PzxvOnA+ PC9vOnA+PC9GT05UPjwvRk9OVD48L1NQQU4+PC9QPjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0i TUFSR0lOOiAwY20gMGNtIDBwdDsgbXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28tbWFyZ2lu LWJvdHRvbS1hbHQ6IGF1dG8iPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9Im1zby1hbnNpLWxhbmd1 YWdlOiBFTi1VUyI+PEZPTlQgc2l6ZT0zPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+VGhl IGV4cGxhbmF0aW9ucyBmcm9tIDYuNCBkbyBub3QgaGVscCB0byB1bmRlcnN0YW5kLjxvOnA+PC9v OnA+PC9GT05UPjwvRk9OVD48L1NQQU4+PC9QPjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFS R0lOOiAwY20gMGNtIDBwdDsgbXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28tbWFyZ2luLWJv dHRvbS1hbHQ6IGF1dG8iPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdl OiBFTi1VUyI+PEZPTlQgc2l6ZT0zPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PC9GT05U PjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9QPjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lO OiAwY20gMGNtIDBwdDsgbXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28tbWFyZ2luLWJvdHRv bS1hbHQ6IGF1dG8iPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBF Ti1VUyI+PEZPTlQgc2l6ZT0zPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+RGVzcGl0ZSBt eSByZXF1ZXN0IG1hZGUgYW1vbmcgb3RoZXIgcmVxdWVzdHMgIldoYXQgbmVlZHMgdG8gYmUgaW1w bGVtZW50ZWQgdG8gYmUgYWJsZSB0byBzYXkgdGhhdCA8U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVu OiB5ZXMiPiZuYnNwOzwvU1BBTj50aGUgaW1wbGVtZW50YXRpb24gaXMgKG9ubHkpIERQViBjb25m b3JtYW50ID8iIHRoZSBkb2N1bWVudCBkb2VzIG5vdCBtYWtlIGEgY2xlYXIgZGlzdGluY3Rpb24g b24gdGhlIHJlcXVpcmVtZW50cyB0aGF0IGFyZSBvbmx5IG5lY2Vzc2FyeSBmb3IgRFBWLiA8L0ZP TlQ+PC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFn ZTogRU4tVVMiPjxGT05UIHNpemU9Mz48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPlRoaXMg Y29tZXMgZnJvbSB0aGUgZmFjdCB0aGF0IHR3byBkaWZmZXJlbnQgZG9jdW1lbnRzIHdvdWxkIGhh dmUgYmVlbiBtdWNoIGJldHRlciwgYnV0IGJlY2F1c2Ugc29tZSBwZW9wbGUgd2FudGVkIHRvIG1h aW50YWluIHRoZSBhY3JvbnltIFNDVlAgdGhpcyBoYXMgbm90IGJlZW4gZG9uZS4gPC9GT05UPjwv Rk9OVD48L1NQQU4+PC9QPjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNt IDBwdDsgbXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28tbWFyZ2luLWJvdHRvbS1hbHQ6IGF1 dG8iPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUyI+PEZP TlQgc2l6ZT0zPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PC9GT05UPjwvRk9OVD48L1NQ QU4+Jm5ic3A7PC9QPjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBw dDsgbXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28tbWFyZ2luLWJvdHRvbS1hbHQ6IGF1dG8i PjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUyI+PEZPTlQg c2l6ZT0zPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+RGlkIGV2ZXJ5Ym9keSBub3RpY2Vk IHRoYXQgIlMiIGRvZXMgbm90IG1lYW4gIlNpbXBsZSIgYW55bW9yZSwgYnV0ICJTdGFuZGFyZCIs IG9uY2UgYWdhaW4gdG8ga2VlcCB0aGUgYWNyb255bS48L0ZPTlQ+PC9GT05UPjwvU1BBTj48L1A+ PFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0OyBtc28tbWFyZ2lu LXRvcC1hbHQ6IGF1dG87IG1zby1tYXJnaW4tYm90dG9tLWFsdDogYXV0byI+PFNQQU4gbGFuZz1F Ti1VUyBzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTIj48L1NQQU4+PFNQQU4gbGFuZz1F Ti1VUyBzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTIj48Rk9OVCBzaXplPTM+PEZPTlQg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48bzpwPjwvbzpwPjwvRk9OVD48L0ZPTlQ+PC9TUEFOPiZu YnNwOzwvUD48UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQ7IG1z by1tYXJnaW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0b20tYWx0OiBhdXRvIj48U1BB TiBsYW5nPUVOLVVTIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tVVMiPjxGT05UIHNpemU9 Mz48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkEgdmVyeSBtaW5vciBwb2ludDogaW4gc2Vj dGlvbiA0LjggdGhlcmUgaXMgbm8gd2F5IHRvIGtub3cgd2hhdCB0aGUgaXRlbSByZXByZXNlbnRz IGFtb25nIHRoZSB0aHJlZSBjaG9pY2VzIG9mZmVyZWQgdG8gdGhlIHNlcnZlci48bzpwPjwvbzpw PjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwvUD48UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJ TjogMGNtIDBjbSAwcHQ7IG1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0 b20tYWx0OiBhdXRvIj48Rk9OVCBzaXplPTM+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tVVMiPjwvU1BBTj48 L0ZPTlQ+PC9GT05UPiZuYnNwOzwvUD48UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjog MGNtIDBjbSAwcHQ7IG1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0b20t YWx0OiBhdXRvIj48Rk9OVCBzaXplPTM+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48U1BB TiBsYW5nPUVOLVVTIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tVVMiPkZpbmFsbHksIHNp bmNlIHRoaXMgZG9jdW1lbnQgd2FzIGNyZWF0ZWQgaW4gdGhlIHByZXZpb3VzIGNlbnR1cnksIHdl IGhhZCBubyBwcm9ibGVtIHdpdGggU0hBLTEgYXQgdGhhdCB0aW1lIGFuZCBoZW5jZSB3ZSB1c2Vk IEVTU0NlcnRJRC4gSG93ZXZlciwgRVNTQ2VydElEIG1hbmRhdGVzIHRoZSB1c2Ugb2YgU0hBLTEu IDwvU1BBTj48bzpwPjwvbzpwPjwvRk9OVD48L0ZPTlQ+PC9QPjxQIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdDsgbXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28t bWFyZ2luLWJvdHRvbS1hbHQ6IGF1dG8iPjxGT05UIHNpemU9Mz48Rk9OVCBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1V UyI+SSB3b3VsZCBwcm9wb3NlIHRvIGFsbG93IHRvIHVzZSA8L1NQQU4+dGhlclNpZ25pbmdDZXJ0 aWZpY2F0IDxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUyI+ YXMgZGVmaW5lZCBpbiBSRkMgMzEyNi48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwv UD48UFJFPmlkLWFhLWV0cy1vdGhlclNpZ0NlcnQgT0JKRUNUIElERU5USUZJRVIgOjo9IHsgaXNv KDEpPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyBtZW1iZXItYm9keSgyKSB1cyg4NDApIHJzYWRzaSgx MTM1NDkpIHBrY3MoMSkgcGtjczkoOSk8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNtaW1lKDE2KSBp ZC1hYSgyKSAxOSB9PG86cD48L286cD48L1BSRT48L0RJVj48RElWPkRlbmlzPEJSPjwvRElWPjxG T05UIGNvbG9yPSM5OTAwOTk+LS0tLS1vd25lci1pZXRmLXBraXhAbWFpbC5pbWMub3JnIHdyb3Rl OiAtLS0tLTxCUj48QlI+PC9GT05UPlRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmc8QlI+RnJvbTog SW50ZXJuZXQtRHJhZnRzQGlldGYub3JnPEJSPlNlbnQgYnk6IG93bmVyLWlldGYtcGtpeEBtYWls LmltYy5vcmc8QlI+RGF0ZTogMjUvMTAvMjAwNSAwOTo1MFBNPEJSPmNjOiBpZXRmLXBraXhAaW1j Lm9yZzxCUj5TdWJqZWN0OiBJLUQgQUNUSU9OOmRyYWZ0LWlldGYtcGtpeC1zY3ZwLTIxLnR4dDxC Uj48QlI+PFBSRT5BIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24t bGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRl bSBvZiB0aGUgUHVibGljLUtleSBJbmZyYXN0cnVjdHVyZSAoWC41MDkpIFdvcmtpbmcgR3JvdXAg b2YgdGhlIElFVEYuCVRpdGxlCQk6IFN0YW5kYXJkIENlcnRpZmljYXRlIFZhbGlkYXRpb24gUHJv dG9jb2wgKFNDVlApCUF1dGhvcihzKQk6IEEuIE1hbHBhbmksIGV0IGFsLglGaWxlbmFtZQk6IGRy YWZ0LWlldGYtcGtpeC1zY3ZwLTIxLnR4dAlQYWdlcwkJOiA3OAlEYXRlCQk6IDIwMDUtMTAtMjUJ U0NWUCBhbGxvd3MgYSBjbGllbnQgdG8gZGVsZWdhdGUgY2VydGlmaWNhdGUgcGF0aCBjb25zdHJ1 Y3Rpb24gYW5kICAgY2VydGlmaWNhdGUgcGF0aCB2YWxpZGF0aW9uIHRvIGEgc2VydmVyLiAgVGhl IHBhdGggY29uc3RydWN0aW9uIG9yICAgdmFsaWRhdGlvbiAoZS5nLiBtYWtpbmcgc3VyZSB0aGF0 IG5vbmUgb2YgdGhlIGNlcnRpZmljYXRlcyBpbiB0aGUgICBwYXRoIGFyZSByZXZva2VkKSBpcyBw ZXJmb3JtZWQgYWNjb3JkaW5nIHRvIGEgdmFsaWRhdGlvbiBwb2xpY3ksICAgd2hpY2ggY29udGFp bnMgb25lIG9yIG1vcmUgdHJ1c3QgYW5jaG9ycy4gIEl0IGFsbG93cyBzaW1wbGlmaWNhdGlvbiAg IG9mIGNsaWVudCBpbXBsZW1lbnRhdGlvbnMgYW5kIHVzZSBvZiBhIHNldCBvZiBwcmVkZWZpbmVk IHZhbGlkYXRpb24gICBwb2xpY2llcy5BIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczo8 YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXBr aXgtc2N2cC0yMS50eHQiIHRhcmdldD1ibGFuaz5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1pZXRmLXBraXgtc2N2cC0yMS50eHQ8L2E+VG8gcmVtb3ZlIHlvdXJzZWxm IGZyb20gdGhlIEktRCBBbm5vdW5jZW1lbnQgbGlzdCwgc2VuZCBhIG1lc3NhZ2UgdG8gaS1kLWFu bm91bmNlLXJlcXVlc3RAaWV0Zi5vcmcgd2l0aCB0aGUgd29yZCB1bnN1YnNjcmliZSBpbiB0aGUg Ym9keSBvZiB0aGUgbWVzc2FnZS4gIFlvdSBjYW4gYWxzbyB2aXNpdCA8QSBocmVmPSJodHRwczov L3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9JLUQtYW5ub3VuY2UiIHRhcmdldD1ibGFu ayA+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vSS1ELWFubm91bmNlPC9h PiB0byBjaGFuZ2UgeW91ciBzdWJzY3JpcHRpb24gc2V0dGluZ3MuSW50ZXJuZXQtRHJhZnRzIGFy ZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQLiBMb2dpbiB3aXRoIHRoZSB1c2VybmFt ZSJhbm9ueW1vdXMiIGFuZCBhIHBhc3N3b3JkIG9mIHlvdXIgZS1tYWlsIGFkZHJlc3MuIEFmdGVy IGxvZ2dpbmcgaW4sdHlwZSAiY2QgaW50ZXJuZXQtZHJhZnRzIiBhbmQgdGhlbgkiZ2V0IGRyYWZ0 LWlldGYtcGtpeC1zY3ZwLTIxLnR4dCIuQSBsaXN0IG9mIEludGVybmV0LURyYWZ0cyBkaXJlY3Rv cmllcyBjYW4gYmUgZm91bmQgaW48YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5o dG1sIiB0YXJnZXQ9Ymxhbms+aHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbDwvYT4gb3Ig PEEgaHJlZj0iZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQiIHRhcmdl dD1ibGFuayA+ZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQ8L2E+SW50 ZXJuZXQtRHJhZnRzIGNhbiBhbHNvIGJlIG9idGFpbmVkIGJ5IGUtbWFpbC5TZW5kIGEgbWVzc2Fn ZSB0bzoJbWFpbHNlcnZAaWV0Zi5vcmcuSW4gdGhlIGJvZHkgdHlwZToJIkZJTEUgL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1pZXRmLXBraXgtc2N2cC0yMS50eHQiLglOT1RFOglUaGUgbWFpbCBzZXJ2 ZXIgYXQgaWV0Zi5vcmcgY2FuIHJldHVybiB0aGUgZG9jdW1lbnQgaW4JTUlNRS1lbmNvZGVkIGZv cm0gYnkgdXNpbmcgdGhlICJtcGFjayIgdXRpbGl0eS4gIFRvIHVzZSB0aGlzCWZlYXR1cmUsIGlu c2VydCB0aGUgY29tbWFuZCAiRU5DT0RJTkcgbWltZSIgYmVmb3JlIHRoZSAiRklMRSIJY29tbWFu ZC4gIFRvIGRlY29kZSB0aGUgcmVzcG9uc2UocyksIHlvdSB3aWxsIG5lZWQgIm11bnBhY2siIG9y CWEgTUlNRS1jb21wbGlhbnQgbWFpbCByZWFkZXIuICBEaWZmZXJlbnQgTUlNRS1jb21wbGlhbnQg bWFpbCByZWFkZXJzCWV4aGliaXQgZGlmZmVyZW50IGJlaGF2aW9yLCBlc3BlY2lhbGx5IHdoZW4g ZGVhbGluZyB3aXRoCSJtdWx0aXBhcnQiIE1JTUUgbWVzc2FnZXMgKGkuZS4gZG9jdW1lbnRzIHdo aWNoIGhhdmUgYmVlbiBzcGxpdAl1cCBpbnRvIG11bHRpcGxlIG1lc3NhZ2VzKSwgc28gY2hlY2sg eW91ciBsb2NhbCBkb2N1bWVudGF0aW9uIG9uCWhvdyB0byBtYW5pcHVsYXRlIHRoZXNlIG1lc3Nh Z2VzLgkJCQlCZWxvdyBpcyB0aGUgZGF0YSB3aGljaCB3aWxsIGVuYWJsZSBhIE1JTUUgY29tcGxp YW50IG1haWwgcmVhZGVyaW1wbGVtZW50YXRpb24gdG8gYXV0b21hdGljYWxseSByZXRyaWV2ZSB0 aGUgQVNDSUkgdmVyc2lvbiBvZiB0aGVJbnRlcm5ldC1EcmFmdC48L1BSRT48UD48QSBocmVmPSJm dHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtcGtpeC1zY3ZwLTIx LnR4dCIgdGFyZ2V0PWJsYW5rID5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWlldGYtcGtpeC1zY3ZwLTIxLnR4dDwvQT48L1A+PC9GT05UPg0K --=_mixed 00573005C12570A7_= Content-Type: application/octet-stream; name="draft-ietf-pkix-scvp-21.txt" Content-Disposition: attachment; filename="draft-ietf-pkix-scvp-21.txt" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDQpDb250ZW50LUlEOgk8MjAwNS0xMC0yNTExMDQzNy5J LURAaWV0Zi5vcmc+DQo= --=_mixed 00573005C12570A7_=-- 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 j9RDb94E012251; Thu, 27 Oct 2005 06:37:09 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9RDb9Wc012250; Thu, 27 Oct 2005 06:37:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9RDb8L1012240 for ; Thu, 27 Oct 2005 06:37:08 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 14486 invoked by uid 0); 27 Oct 2005 13:37:04 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.238.33) by woodstock.binhost.com with SMTP; 27 Oct 2005 13:37:04 -0000 Message-Id: <7.0.0.10.2.20051027092241.05814258@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta) Date: Thu, 27 Oct 2005 09:37:03 -0400 To: "Stefan Santesson" , From: Russ Housley Subject: RE: Public key validation and Proof of possession In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stefan: I think that there will always be low end devices. Consider the history. - Personal computers used to be very simple systems, especially before the IBM PC. Remember the Intel 8080? A very large machine had 32 Kbytes of RAM, and non-volatile storage was 8-inch floppy disk. - Hand-held computers were originally very low-end computers. They have come a long way, and the power management has significantly helped with battery life. - Mobile phones did not really include Internet capabilities at first, but when they were added, WAP was used to accommodate the low-end processing environment. When 32-bit processors appeared in mobile phones, mainstream Internet protocols were used in favor of WAP. - Smartcards are still low-end processors. As you point out, they are getting more powerful all the time. - RFID are very low-power devices. I'm sure that more capabilities will be added over time. But right now, certificate parsing and validation is probably beyond their capabilities. As they become more capable, I think that certificate-based protocols are appropriate in this environment. In summary, I do not think it is unreasonable to consider features for low-end devices. I believe that there will always be new low-end devices appearing, and at some point they may need to handle certificates. Russ At 05:37 PM 10/26/2005, Stefan Santesson wrote: >Russ, > >I'm concerned that we are about to enter a dangerous path if we start >defining extensions for policy aspects. If we open this can, there are >many other potential candidates for policy expression extensions and I'm >not sure we will help the deployment community by going down that path. > >I think this needs careful consideration and I'm not sure the benefit of >this extension is worth the cost. > >My thought is that arithmetic property validation seems feasible even in >a smart card today and even more, this test can easily be done in the >system in which the smart card is used. Computation power is >exponentially increasing and before this extension is generally adopted, >this might very well be a completely redundant issue. > >POP of encryption keys seems to be such a generic requirement for CAs >that even policy enforcement through trust anchor chaining might be >sufficient in most cases. > >I think it would be good to have some discussions in Vancouver if this >can be fitted into the pkix agenda. > > >Stefan Santesson >Program Manager, Standards Liaison >Windows Security > > > > -----Original Message----- > > From: Russ Housley [mailto:housley@vigilsec.com] > > Sent: den 26 oktober 2005 15:39 > > To: Stefan Santesson; ietf-pkix@imc.org > > Subject: RE: Public key validation and Proof of possession > > > > Stefan: > > > > >On public key validation (arithmetic properties): > > >It seems to me that the key validation tests specified in 5.6.2.4 and > > >5.6.2.5 are rather trivial to do locally ( 2= > >for FFC), at least compared to the cost of using this key for >anything > > >useful. I wonder if the cost of making this test isn't actually lower > > >than parsing the certificate to obtain the assurance from the CA. > > > > In low power devices (such as smartcards), avoiding the y^q > > exponentiation because the relying party is sure that the CA has > > already performed this check seems useful. > > > > >On Proof-of-possession: > > >Section 5.6.3. of SP 800-56 states: > > >"For example, this Recommendation requires that parties obtain >assurance > > >that they actually possess their own static private keys, and a >binding > > >authority is required to obtain assurance of an owner's possession of > > >the appropriate static private key before binding an identifier to >the > > >owner's static public key." > > > > > >So since POP always MUST be performed by the CA there seems not to be > > >the need for diverse policies (POP and non POP). > > > > > >Do you agree with these observations or have I missed something? > > > > If the first idea is accepted, the proposed extension is no larger by > > adding the additional bit to indicate that the CA performed POP. The > > positive statement could be useful. > > > > 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 j9RAOJpI093580; Thu, 27 Oct 2005 03:24:19 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9RAOJJq093579; Thu, 27 Oct 2005 03:24:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9RAOH7j093556 for ; Thu, 27 Oct 2005 03:24:18 -0700 (PDT) (envelope-from denis.pinkas@bull.net) 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 MAA16652; Thu, 27 Oct 2005 12:41:31 +0200 Importance: Normal X-Priority: 3 (Normal) Subject: RE: Public key validation and Proof of possession MIME-Version: 1.0 From: denis.pinkas@bull.net To: Tim Polk Cc: ietf-pkix@imc.org Date: Thu, 27 Oct 2005 12:24:49 +0200 Message-ID: X-MIMETrack: Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 27/10/2005 12:24:50 MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: PEZPTlQgZmFjZT0iRGVmYXVsdCBTYW5zIFNlcmlmLCBWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNh LCBzYW5zLXNlcmlmIiBzaXplPTI+PFA+PEJSPkRlbmlzLDxicj48YnI+SSBkaWQgYSBxdWljayBz ZWFyY2ggZm9yIHRoZSBvZmZlbmRpbmcgc3RhdGVtZW50IGluIFJGQyAzMjgwIGFzIHdlbGwgYXMz MjgwYmlzLCBidXQgY291bGQgbm90IGZpbmQgaXQuJm5ic3A7IEFyZSB5b3UgdGhpbmtpbmcgb2Yg YSBzdGF0ZW1lbnQgaW5DTVAgb3IgQ1JNRj88YnI+PC9QPjxQPj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT08L1A+PFA+U29ycnkuIE15IG1pc3Rha2UuIEl0IHdhcyBS RkMgNDIxMCAoQ01QKSB0aGF0IHN0YXRlcyA6PC9QPjxQPiJIb3dldmVyLCBpdCBpcyBSRVFVSVJF RCB0aGF0IENBcy9SQXMgTVVTVCBlbmZvcmNlIFBPUCBieSBzb21lIG1lYW5zIGJlY2F1c2UgdGhl cmUgYXJlIGN1cnJlbnRseTxCUj5tYW55IG5vbi1QS0lYIG9wZXJhdGlvbmFsIHByb3RvY29scyBp biB1c2UgKHZhcmlvdXMgZWxlY3Ryb25pYyBtYWlsIHByb3RvY29scyBhcmUgb25lIGV4YW1wbGUp IDxCUj50aGF0IGRvIG5vdCBleHBsaWNpdGx5IGNoZWNrIHRoZSBiaW5kaW5nIGJldHdlZW4gdGhl IGVuZCBlbnRpdHkgYW5kIHRoZSBwcml2YXRlIGtleS48U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVu OiB5ZXMiPiZuYnNwOyA8QlI+PC9TUEFOPlVudGlsIG9wZXJhdGlvbmFsIHByb3RvY29scyB0aGF0 IGRvIHZlcmlmeSB0aGUgYmluZGluZyAoZm9yIHNpZ25hdHVyZSwgZW5jcnlwdGlvbiwgYW5kIGtl eSBhZ3JlZW1lbnQga2V5IHBhaXJzKSBleGlzdCwgPEJSPmFuZCBhcmUgdWJpcXVpdG91cywgdGhp cyBiaW5kaW5nIGNhbiBvbmx5IGJlIGFzc3VtZWQgdG8gaGF2ZSBiZWVuIHZlcmlmaWVkIGJ5IHRo ZSBDQS9SQS4iPC9QPjxQPlRodXMgbm8gImNoYW5nZSIgcmVxdWlyZWQmbmJzcDtpbiZuYnNwOzMy ODBiaXMsIGJ1dCBvbmx5IGFuIGFkZGl0aW9uLjwvUD48UD5EZW5pczwvUD48UD49PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9QPjxQPlRoYW5rcyw8YnI+PGJyPlRp bTxicj48YnI+PGJyPkF0IDA0OjUwIFBNIDEwLzI2LzIwMDUgKzAyMDAsIGRlbmlzLnBpbmthc0Bi dWxsLm5ldCB3cm90ZTo8YnI+PC9QPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPWNpdGUg Y2l0ZT0iIj48Zm9udCBmYWNlPSJWZXJkYW5hIiBzaXplPTIgY29sb3I9IiMwMDk5MDAiPlJ1c3Ms PC9mb250Pjxmb250IGZhY2U9IlZlcmRhbmEiIHNpemU9Mj48YnI+PGJyPjwvZm9udD48Zm9udCBm YWNlPSJWZXJkYW5hIiBzaXplPTIgY29sb3I9IiMwMDk5MDAiPk15IHByZXZpb3VzIHJlcGx5IHdh c3RvbyBjb25jaXNlLjxicj48L2ZvbnQ+PGZvbnQgZmFjZT0iVmVyZGFuYSIgc2l6ZT0yPjxicj48 L2ZvbnQ+PGZvbnQgZmFjZT0iVmVyZGFuYSIgc2l6ZT0yIGNvbG9yPSIjMDA5OTAwIj5ZRVMsIEkg YW0gc3Vwb3J0aXZlIG9mcHVibGljS2V5VmFsYWRhdGlvbiAoMCksIGJ1dCBwbGVhc2UgYWxzbyBu b3RlIGFzIFNlY3VyaXR5IEFyZWFEaXJlY3Rvcjxicj50aGF0IGEgY2hhbmdlIHRvIDMyODBiaXMg c2hvdWxkIGFsc28gYmUgZG9uZSA6IFBPUCBzaG91bGQgbm8gbW9yZSBiZW1hbmRhdGVkIGluIGFu eSBjYXNlLjxicj48L2ZvbnQ+PGZvbnQgZmFjZT0iVmVyZGFuYSIgc2l6ZT0yPjxicj48L2ZvbnQ+ PGZvbnQgZmFjZT0iVmVyZGFuYSIgc2l6ZT0yIGNvbG9yPSIjMDA5OTAwIj5EZW5pczxicj48L2Zv bnQ+PGZvbnQgZmFjZT0iVmVyZGFuYSIgc2l6ZT0yPjxicj48YnI+RGVuaXM6PGJyPjxicj5BcmUg eW91IHNwZWFraW5nIGluIHN1cHBvcnQgb2YgdGhlIGV4dGVuc2lvbiB0aGF0IEkgcHJvcG9zZWQ/ PGJyPjxicj5SdXNzPGJyPjxicj5BdCAwOToxMSBBTSAxMC8yNi8yMDA1LCBkZW5pcy5waW5rYXNA YnVsbC5uZXQgd3JvdGU6PGJyPjxicj4mZ3Q7UnVzcyBhbmQgU3RlZmFuLDxicj4mZ3Q7PGJyPiZn dDtUaGlzIGlzIGFuIGludGVycmVzdGluZyBpc3N1ZS4gVGhhbmtzIGZvciByYWlzaW5nIGl0Ljxi cj4mZ3Q7PGJyPiZndDsodGV4dCBkZWxldGVkKTxicj4mZ3Q7PGJyPiZndDtTbyBzaW5jZSBQT1Ag YWx3YXlzIE1VU1QgYmUgcGVyZm9ybWVkIGJ5IHRoZSBDQSB0aGVyZSBzZWVtcyBub3QgdG9iZTxi cj4mZ3Q7dGhlIG5lZWQgZm9yIGRpdmVyc2UgcG9saWNpZXMgKFBPUCBhbmQgbm9uIFBPUCkuPGJy PiZndDs8YnI+Jmd0O09uY2UgdXBvbiBhIHRpbWUsIGluIHRoZSBlYXJseSB5ZWFycyBvZiBQS0ks IFJGQyAyNDU5IHN0YXRlZCB0aGF0PGJyPiZndDtzZW50ZW5jZSB0aGF0IHdhcyBibGluZGx5IGNv cGllZCBmcm9tIGRvY3VtZW50IHRvIGRvY3VtZW50Ljxicj4mZ3Q7PGJyPiZndDtJbiB0aGVzZSBl YXJseSB5ZWFycywgbW9zdCAoaWYgbm90IGFsbCkgc2VjdXJpdHkgcHJvdG9jb2xzIHdlcmUgPGJy PiZndDtiYWRseSBkZXNpZ25lZCBhbmQgdGh1cyBmb3IgdGhlbSB0byByZW1haW5zIHNlY3VyZTxi cj4mZ3Q7dGhlIG9ubHkgd2F5IHdhcyB0byBpbmNsdWRlIHRoZSBNVVNUIGNvbmRpdGlvbi48YnI+ Jmd0Ozxicj4mZ3Q7SG93ZXZlciBzaW5jZSB0aGVuLCB0aGUgZWFydGggaGFzIHJvdGF0ZWQgYW5k IGF0IGxlYXN0IHRoZXJlIG5vdzxicj4mZ3Q7ZXhpc3RzIG9uZSBjYXNlIHdoZXJlIFBPUCBpcyBu byBtb3JlIG5lZWRlZCB3aXRob3V0IGFueSBzZWN1cml0eXRocmVhdC48YnI+Jmd0Ozxicj4mZ3Q7 VGhpcyBjYXNlIHdhcyBpbnRyb2R1Y2VkIGJ5IFMvTUlNRSB3aXRoIHRoZSBvcHRpb25hbGx5IHNp Z25lZCA8YnI+Jmd0O2F0dHJpYnV0ZSBFU1NDZXJ0SUQuPGJyPiZndDs8YnI+Jmd0O0l0IHdhcyB0 aGVuIHRha2VuIGJ5IEVUU0kgd2l0aCB0aGUgbWFuZGF0b3J5IEVTU0NldHJ0SUQgKG9yIGlpcyA8 YnI+Jmd0O2VxdWl2YWxlbnQgdGhhdCBkb2VzIG5vdCBtYW5kYXRlIHRoZSB1c2Ugb2YgU0hBLTEp Ljxicj4mZ3Q7PGJyPiZndDtSRkMgMzEyNiBzcGVjaWZpZXMgdGhhdCBmb3JtYXQuPGJyPiZndDs8 YnI+Jmd0O1Rha2luZyBpbnRvIGNvbnNpZGVyYXRpb24gdGhlc2UgZmFjdHMsIHRoaXMgbWVhbnMg dGhhdCB0aGVyZSBleGlzdHM8YnI+Jmd0O2F0IGxlYXN0IG9uZSBjYXNlIHdoZXJlIFBPUCBkb2Vz IG5vdCBuZWVkIHRvIGJlIHBlcmZvcm1lZGFueW1vcmUuPGJyPiZndDs8YnI+Jmd0O1RoZXJlIHN0 aWxsIGV4aXN0cyBjYXNlcyB3aGVyZSBpdCBuZWVkcyB0byBiZSBwZXJmb3JtZWQsIGluIDxicj4m Z3Q7cGFydGljdWxhciB3aGVuIHRoZSBjZXJ0aWZpY2F0ZSBpcyB1c2VkIGZvciBlbmNyeXB0aW9u IHB1cnBvc2VzLjxicj4mZ3Q7PGJyPiZndDtJIGJlbGlldmUgdGhhdCBQT1AgaXMgbWFuZGF0b3J5 IHdoZW4gdGhlIGtleSBpcyB1c2VkIGZvciBlbmNyeXB0aW9ucHVycG9zZXMuPGJyPiZndDs8YnI+ Jmd0O0kgYmVsaWV2ZSB0aGF0IFBPUCBpcyBOT1QgUkVRVUlSRUQgd2hlbiB0aGUga2V5IGlzIHVz ZWQgZm9yIG5vbiA8YnI+Jmd0O3JlcHVkaWF0aW9uIHB1cnBvc2VzIChlLmcuIFJGQyAzMTI2IGlz IHVzZWQpLjxicj4mZ3Q7PGJyPiZndDtXaGVuIHRoZSBrZXkgaXMgdXNlZCBmb3IgYXV0aGVudGlj YXRpb24gcHVycG9zZXMsIHRoZW4gZGVwZW5kaW5nPGJyPiZndDt1cG9uIHRoZSBjaGFyYWN0ZXJp c3RpY3Mgb2YgdGhlIHByb3RvY29sLDxicj4mZ3Q7aXQgTUFZIGJlIHJlcXVpcmVkIG9yIG5vdC4g U28gaW4gdGhhdCBjYXNlIG9ubHksIGl0IHdvdWxkIG1ha2Ugc2Vuc2U8YnI+Jmd0O3RvIHN1cHBv cnQgdGhlIGV4dGVuc2lvbiBwcm9wb3NlZCBieSBSdXNzLjxicj4mZ3Q7PGJyPiZndDtEZW5pczxi cj4mZ3Q7PGJyPiZndDs9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4mZ3Q7PGJyPiZndDtEbyB5b3Ug YWdyZWUgd2l0aCB0aGVzZSBvYnNlcnZhdGlvbnMgb3IgaGF2ZSBJIG1pc3NlZCBzb21ldGhpbmc/ PGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7U3RlZmFuIFNhbnRlc3Nvbjxicj4mZ3Q7UHJvZ3JhbSBN YW5hZ2VyLCBTdGFuZGFyZHMgTGlhaXNvbjxicj4mZ3Q7V2luZG93cyBTZWN1cml0eTxicj4mZ3Q7 PGJyPiZndDs8YnI+Jmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPiZndDsg Jmd0OyBGcm9tOiBvd25lci1pZXRmLXBraXhAbWFpbC5pbWMub3JnPGJyPiZndDtbPEEgaHJlZj0i bWFpbHRvOm93bmVyLWlldGYtcGtpeEBtYWlsLmltYy5vcmciIHRhcmdldD1ibGFuayAgZXVkb3Jh PSJhdXRvdXJsIj5tYWlsdG86b3duZXItaWV0Zi1wa2l4QG1haWwuaW1jLm9yZzwvYT5dPGJyPiZn dDsgJmd0OyBPbiBCZWhhbGYgT2YgUnVzcyBIb3VzbGV5PGJyPiZndDsgJmd0OyBTZW50OiBkZW4g MjUgb2t0b2JlciAyMDA1IDIzOjA0PGJyPiZndDsgJmd0OyBUbzogaWV0Zi1wa2l4QGltYy5vcmc8 YnI+Jmd0OyAmZ3Q7IFN1YmplY3Q6IFB1YmxpYyBrZXkgdmFsaWRhdGlvbiBhbmQgUHJvb2Ygb2Yg cG9zc2Vzc2lvbjxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyBEZWFyIFBL SVggV0c6PGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgVGhlIGRyYWZ0IE5JU1QgU1AgODAwLTU2 IGRlZmluZXMgdGhlIHJlcXVpcmVtZW50cyBmb3IiUmVjaXBpZW50PGJyPiZndDsgJmd0OyBBc3N1 cmFuY2Ugb2YgU3RhdGljIFB1YmxpYyBLZXkgVmFsaWRpdHkuIiBTZWUgU2VjdGlvbjUuNi4yLjIs IHdoZXJlPGJyPiZndDtpdDxicj4mZ3Q7ICZndDsgc2F5czo8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsg Jmd0OyBUaGUgcmVjaXBpZW50IG9mIGEgc3RhdGljIHB1YmxpYyBrZXkgc2hhbGwgb2J0YWluIGFz c3VyYW5jZSBvZml0czxicj4mZ3Q7ICZndDsgdmFsaWRpdHk8YnI+Jmd0OyAmZ3Q7IGluIG9uZSBv ciBtb3JlIG9mIHRoZSBmb2xsb3dpbmcgd2F5czo8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyAx LiBSZWNpcGllbnQgRnVsbCBWYWxpZGF0aW9uIC0gVGhlIHJlY2lwaWVudCBwZXJmb3JtcyBhPGJy PiZndDtzdWNjZXNzZnVsPGJyPiZndDsgJmd0OyBmdWxsPGJyPiZndDsgJmd0OyBwdWJsaWMga2V5 IHZhbGlkYXRpb24gKHNlZSBTZWN0aW9ucyA1LjYuMi40IGFuZCA1LjYuMi41KS48YnI+Jmd0OyAm Z3Q7PGJyPiZndDsgJmd0OyAyLiBUVFAgRnVsbCBWYWxpZGF0aW9uIC0gVGhlIHJlY2lwaWVudCBy ZWNlaXZlcyBhc3N1cmFuY2V0aGF0PGJyPiZndDthPGJyPiZndDsgJmd0OyB0cnVzdGVkPGJyPiZn dDsgJmd0OyB0aGlyZCBwYXJ0eSAodHJ1c3RlZCBieSB0aGUgcmVjaXBpZW50KSBoYXMgcGVyZm9y bWVkIGE8YnI+Jmd0OyAmZ3Q7IHN1Y2Nlc3NmdWwgZnVsbDxicj4mZ3Q7ICZndDsgcHVibGljIGtl eSB2YWxpZGF0aW9uIChzZWUgU2VjdGlvbnMgNS42LjIuNCBhbmQgNS42LjIuNSkuPGJyPiZndDsg Jmd0Ozxicj4mZ3Q7ICZndDsgMy4gVFRQIEdlbmVyYXRpb24gLSBUaGUgcmVjaXBpZW50IHJlY2Vp dmVzIGFzc3VyYW5jZSB0aGF0YTxicj4mZ3Q7ICZndDsgdHJ1c3RlZCB0aGlyZDxicj4mZ3Q7ICZn dDsgcGFydHkgKHRydXN0ZWQgYnkgdGhlIHJlY2lwaWVudCkgaGFzIGdlIG5lcmF0ZWQgdGhlPGJy PiZndDsgJmd0OyBwdWJsaWMvcHJpdmF0ZSBrZXk8YnI+Jmd0OyAmZ3Q7IHBhaXIgaW4gYWNjb3Jk YW5jZSB3aXRoIFNlY3Rpb24gNS42LjEgYW5kIGhhcyBwcm92aWRlZCB0aGU8YnI+Jmd0OyAmZ3Q7 IGtleSBwYWlyIHRvPGJyPiZndDsgJmd0OyB0aGUgb3duZXIuPGJyPiZndDsgJmd0Ozxicj4mZ3Q7 ICZndDsgSXQgc2VlbXMgdG8gbWUgdGhhdCBvcHRpb24gMiB3YXMgaW5jbHVkZSB0byBhbGxvdyBh IENBIHRvcGVyZm9ybSB0aGU8YnI+Jmd0OyAmZ3Q7IHB1YmxpYyBrZXkgdmFsaWRhdGlvbiBvbmNl LCBhbmQgdGhlbiBhbnkgcGFydHkgdGhhdCBtYWtlcyB1c2VvZiB0aGU8YnI+Jmd0OyAmZ3Q7IGNl cnRpZmljYXRlIG5lZWQgbm90IGRvIGl0IGFnYWluLiBGcm9tIGEgc3lzdGVtcGVyZm9ybWFuY2U8 YnI+Jmd0OyAmZ3Q7IHBlcnNwZWN0aXZlLCB0aGlzIHNlZW1zIGhpZ2hseSBkZXNpcmFibGUuPGJy PiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgSW4gc29tZSBoaWdobHkgYXNzdXJlZCBpbXBsZW1lbnRh dGlvbiBlbnZpcm9ubWVudHMsIGl0c2VlbXM8YnI+Jmd0OyAmZ3Q7IGRlc2lyYWJsZSBmb3IgdGhl cmUgdG8gbWUgYW4gaW5kaWNhdGlvbiBpbiB0aGUgY2VydGlmaWNhdGUgdGhhdHRoaXM8YnI+Jmd0 OyAmZ3Q7IGFjdGlvbiB3YXMgdGFrZW4gYnkgdGhlIENBLiBPbmUgY291bGQgZGV0ZXJtaW5lIHdo aWNoY2VydGlmaWNhdGlvbjxicj4mZ3Q7ICZndDsgcG9saWNpZXMgcmVxdWlyZSB0aGUgQ0EgdG8g dGFrZSB0aGlzIGFjdGlvbiwgYnV0IHRoYXQgbWVhbnN0aGF0IHRoZTxicj4mZ3Q7ICZndDsgbGlz dCBvZiBjZXJ0aWZpY2F0aW9uIHBvbGljaWVzIHdvdWxkIGJlIGNvbnRpbnVhbGx5IGFkanVzdGVk IGJ5YW48YnI+Jmd0OyAmZ3Q7IGFkbWluaXN0cmF0b3IuIEkgd291bGQgcHJlZmVyIGEgbm9uLWNy aXRpY2FsIGV4dGVuc2lvbiB0aGF0ZGVjbGFyZWQ8YnI+Jmd0OyAmZ3Q7IHRoYXQgdGhpcyBhY3Rp b24gd2FzIHRha2VuIGJ5IHRoZSBDQS48YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyBUaGUgZHJh ZnQgTklTVCBTUCA4MDAtNTYsIFNlY3Rpb24gNS42LjMuMiBkaXNjdXNzZXMgdGhlcmVxdWlyZW1l bnQ8YnI+Jmd0OyAmZ3Q7IGZvciAiUmVjaXBpZW50IEFzc3VyYW5jZSBvZiB0aGUgT3duZXIncyBQ b3NzZXNzaW9uIG9mIGFTdGF0aWM8YnI+Jmd0OyAmZ3Q7IFByaXZhdGUgS2V5LiIgVGhhdCBpcywg dGhlIHRvcGljIHdlIGhhdmUgYmVlbiBkaXNjdXNzaW5nZm9yIHllYXJzPGJyPiZndDsgJmd0OyBv biB0aGlzIGxpc3QsIGNhbGxpbmcgaXQgcHJvb2Ygb2YgcG9zc2Vzc2lvbi4gUkZDIDM2NDcgaW5j bHVkZXNhPGJyPiZndDsgJmd0OyBwbGFjZSBpbiB0aGUgY2VydGlmaWNhdGlvbiBwb2xpY3kgdG8g ZGlzY3VzcyB0aGlzIHRvcGljLiAoUkZDMzY0Nyw8YnI+Jmd0OyAmZ3Q7IFNlY3Rpb24gMy4yLjE6 IE1ldGhvZCB0byBwcm92ZSBwb3NzZXNzaW9uIG9mIHByaXZhdGUga2V5Lik8YnI+Jmd0OyAmZ3Q7 PGJyPiZndDsgJmd0OyBBZ2FpbiwgaW4gc29tZSBoaWdobHkgYXNzdXJlZCBpbXBsZW1lbnRhdGlv biBlbnZpcm9ubWVudHMsIGl0c2VlbXM8YnI+Jmd0OyAmZ3Q7IGRlc2lyYWJsZSBmb3IgdGhlcmUg dG8gbWUgYW4gaW5kaWNhdGlvbiBpbiB0aGUgY2VydGlmaWNhdGUgdGhhdHByb29mPGJyPiZndDsg Jmd0OyBvZiBwb3NzZXNzaW9uIHdhcyBwZXJmb3JtZWQgYnkgdGhlIENBLiBJIHRoaW5rIGl0IGNv dWxkIGJlIHBhcnRvZjxicj4mZ3Q7ICZndDsgdGhlIHNhbWUgbm9uLWNyaXRpY2FsIGV4dGVuc2lv biBwcm9wb3NlZCBhYm92ZS48YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyBJIHRoZXJlZm9yZSBw cm9wb3NlIHRoYXQgdGhlIFBLSVggV0cgZ2VuZXJhdGUgYSBzdGFuZGFyZHMtdHJhY2tSRkM8YnI+ Jmd0OyAmZ3Q7IHRvIGRlZmluZSBhIGNlcnRpZmljYXRlIGV4dGVuc2lvbiB0byBwcm92aWRlIHRo ZXNlIGluZGljYXRpb25zLkk8YnI+Jmd0OyAmZ3Q7IHByb3Bvc2UgYSB2ZXJ5IHNpbXBsZSBzeW50 YXg6PGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgaWQtcGUtY2FDaGVja3MgT0JKRUNUIElERU5U SUZJRVIgOjo9IHsgaWQtcGUgJmx0O1RCRCZndDsgfTxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7 IENBQ2hlY2tzIDo6PSAgICBCSVQgU1RSSU5HIHs8YnI+Jmd0OyAmZ3Q7IHB1YmxpY0tleVZhbGFk YXRpb24gKDApLDxicj4mZ3Q7ICZndDsgcHJvb2ZPZlBvc3Nlc3Npb24gKDEpIH08YnI+Jmd0OyAm Z3Q7PGJyPiZndDsgJmd0OyBEbyBvdGhlcnMgdGhpbmsgdGhpcyBpcyBhIHVzZWZ1bCBleHRlbnNp b24/PGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgUnVzczxicj4mZ3Q7PGJyPjwvZm9udD48L2Js b2NrcXVvdGU+PC9GT05UPg== 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 j9R0KjEq035697; Wed, 26 Oct 2005 17:20:45 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9R0KjZG035696; Wed, 26 Oct 2005 17:20:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9R0Ki7d035671 for ; Wed, 26 Oct 2005 17:20:45 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [10.84.130.29] (dommiel.bbn.com [192.1.122.15]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j9R0KaIG009599; Wed, 26 Oct 2005 20:20:38 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <7.0.0.10.2.20051026151352.05805b20@vigilsec.com> References: <7.0.0.10.2.20051025164030.061cdfb0@vigilsec.com> <7.0.0.10.2.20051026151352.05805b20@vigilsec.com> Date: Wed, 26 Oct 2005 20:17:33 -0400 To: Russ Housley From: Stephen Kent Subject: Re: Public key validation and Proof of possession Cc: ietf-pkix@imc.org 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: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 3:18 PM -0400 10/26/05, Russ Housley wrote: >Steve: > >If I understand your proposal, you are suggesting a certificate >policy OID that would be included in the certificate (in addition to >any other certificate policy OID that is appropriate). This would >be acceptable to me if it was only used in end-entity certificates. >I think it could add complication to certificate policy mapping, >which is already too messy. > >I note that the certificate policy OID does not offer the same >granularity. The OID would only be included if the public key >validation is performed and proof of possession is performed. > >Russ > I envisioned two policies, one for each of PoP and PKV. However, If Stefan's observation about policies is correct (I admit to having not checked first), then this is not a viable alternative to your proposal, even independent of the policy mapping complexity concerns your cited. 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 j9QMo2Hi025343; Wed, 26 Oct 2005 15:50:02 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QMo2Rf025342; Wed, 26 Oct 2005 15:50:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9QMo1Na025334 for ; Wed, 26 Oct 2005 15:50:02 -0700 (PDT) (envelope-from mlee@newodin.ietf.org) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EUu5p-0005Ys-C3; Wed, 26 Oct 2005 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-cmc-trans-04.txt Message-Id: Date: Wed, 26 Oct 2005 18:50:01 -0400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Certificate Management over CMS (CMC) Transport Protocols Author(s) : J. Schaad, M. Myers Filename : draft-ietf-pkix-cmc-trans-04.txt Pages : 7 Date : 2005-10-26 This document defines a number of transport mechanisms that are used to move CMC (Certificate Managment over CMS (Cryptographic Message Syntax)) messages. The transport mechanisms described in this document are: HTTP, file, mail and TCP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmc-trans-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-cmc-trans-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-cmc-trans-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-26154458.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-cmc-trans-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-cmc-trans-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-26154458.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9QLbQw2018325; Wed, 26 Oct 2005 14:37:26 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QLbQOv018324; Wed, 26 Oct 2005 14:37:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9QLbPeV018317 for ; Wed, 26 Oct 2005 14:37:26 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Oct 2005 22:37:20 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Public key validation and Proof of possession Date: Wed, 26 Oct 2005 22:37:22 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Public key validation and Proof of possession Thread-Index: AcXaMvyB6IsXcki9TCuQLks9qw9ECwAQK2rA From: "Stefan Santesson" To: "Russ Housley" , X-OriginalArrivalTime: 26 Oct 2005 21:37:20.0104 (UTC) FILETIME=[718D4680:01C5DA75] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j9QLbQeV018319 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, I'm concerned that we are about to enter a dangerous path if we start defining extensions for policy aspects. If we open this can, there are many other potential candidates for policy expression extensions and I'm not sure we will help the deployment community by going down that path. I think this needs careful consideration and I'm not sure the benefit of this extension is worth the cost. My thought is that arithmetic property validation seems feasible even in a smart card today and even more, this test can easily be done in the system in which the smart card is used. Computation power is exponentially increasing and before this extension is generally adopted, this might very well be a completely redundant issue. POP of encryption keys seems to be such a generic requirement for CAs that even policy enforcement through trust anchor chaining might be sufficient in most cases. I think it would be good to have some discussions in Vancouver if this can be fitted into the pkix agenda. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: den 26 oktober 2005 15:39 > To: Stefan Santesson; ietf-pkix@imc.org > Subject: RE: Public key validation and Proof of possession > > Stefan: > > >On public key validation (arithmetic properties): > >It seems to me that the key validation tests specified in 5.6.2.4 and > >5.6.2.5 are rather trivial to do locally ( 2= >for FFC), at least compared to the cost of using this key for anything > >useful. I wonder if the cost of making this test isn't actually lower > >than parsing the certificate to obtain the assurance from the CA. > > In low power devices (such as smartcards), avoiding the y^q > exponentiation because the relying party is sure that the CA has > already performed this check seems useful. > > >On Proof-of-possession: > >Section 5.6.3. of SP 800-56 states: > >"For example, this Recommendation requires that parties obtain assurance > >that they actually possess their own static private keys, and a binding > >authority is required to obtain assurance of an owner's possession of > >the appropriate static private key before binding an identifier to the > >owner's static public key." > > > >So since POP always MUST be performed by the CA there seems not to be > >the need for diverse policies (POP and non POP). > > > >Do you agree with these observations or have I missed something? > > If the first idea is accepted, the proposed extension is no larger by > adding the additional bit to indicate that the CA performed POP. The > positive statement could be useful. > > 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 j9QLO0IJ016401; Wed, 26 Oct 2005 14:24:00 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QLO07L016400; Wed, 26 Oct 2005 14:24:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9QLNxTN016388 for ; Wed, 26 Oct 2005 14:23:59 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Oct 2005 22:23:53 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Public key validation and Proof of possession Date: Wed, 26 Oct 2005 22:23:55 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Public key validation and Proof of possession Thread-Index: AcXaVEuY1MpykbkXSEqSAAXbSHPD5AAHsNwA From: "Stefan Santesson" To: "Stephen Kent" , "Russ Housley" Cc: X-OriginalArrivalTime: 26 Oct 2005 21:23:53.0853 (UTC) FILETIME=[90FD22D0:01C5DA73] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j9QLO0TN016394 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Steve, Unfortunately this is not compliant with current path validation algorithm. When you test a certificate for a number of acceptable policies, path validation will accept the certificate if just one of these policies are supported by the path. There is no way to tell the standard path validation that a certificate is valid if a combination of policies are supported (e.g. IETF policy A + policy B) All policies expressed in a certificate must represent a complete policy declaration. Partial policies are not supported. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Stephen Kent > Sent: den 26 oktober 2005 18:45 > To: Russ Housley > Cc: ietf-pkix@imc.org > Subject: Re: Public key validation and Proof of possession > > > Russ, > > I think this is a good suggestion, and the extension should be a > simple as you suggest. Relying on this being in a CP is asking a lot > in management terms, as you noted. > > However, one might also address this by defining an IETF-standard CP > that addresses just these issues, and allowing CAs to add that CP to > whatever other CP that assert in an cert. How do you feel about that > alternative? > > 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 j9QJeqRk002749; Wed, 26 Oct 2005 12:40:52 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QJeqGR002748; Wed, 26 Oct 2005 12:40:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9QJeo6l002720 for ; Wed, 26 Oct 2005 12:40:51 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 32220 invoked by uid 0); 26 Oct 2005 19:40:44 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.238.33) by woodstock.binhost.com with SMTP; 26 Oct 2005 19:40:44 -0000 Message-Id: <7.0.0.10.2.20051026151352.05805b20@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta) Date: Wed, 26 Oct 2005 15:18:09 -0400 To: Stephen Kent From: Russ Housley Subject: Re: Public key validation and Proof of possession Cc: ietf-pkix@imc.org In-Reply-To: References: <7.0.0.10.2.20051025164030.061cdfb0@vigilsec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Steve: If I understand your proposal, you are suggesting a certificate policy OID that would be included in the certificate (in addition to any other certificate policy OID that is appropriate). This would be acceptable to me if it was only used in end-entity certificates. I think it could add complication to certificate policy mapping, which is already too messy. I note that the certificate policy OID does not offer the same granularity. The OID would only be included if the public key validation is performed and proof of possession is performed. Russ At 12:45 PM 10/26/2005, Stephen Kent wrote: >Russ, > >I think this is a good suggestion, and the extension should be a >simple as you suggest. Relying on this being in a CP is asking a >lot in management terms, as you noted. > >However, one might also address this by defining an IETF-standard CP >that addresses just these issues, and allowing CAs to add that CP to >whatever other CP that assert in an cert. How do you feel about >that alternative? > >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 j9QIv3Cp089001; Wed, 26 Oct 2005 11:57:03 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QIv3WW089000; Wed, 26 Oct 2005 11:57:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9QIv2Fd088992 for ; Wed, 26 Oct 2005 11:57:02 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 21314 invoked by uid 0); 26 Oct 2005 18:56:55 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.181.94) by woodstock.binhost.com with SMTP; 26 Oct 2005 18:56:55 -0000 Message-Id: <7.0.0.10.2.20051026115805.05782370@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta) Date: Wed, 26 Oct 2005 12:11:20 -0400 To: "Simon Blake-Wilson" , From: Russ Housley Subject: RE: Public key validation and Proof of possession In-Reply-To: <04e001c5da3e$25cb11a0$0200a8c0@simon> References: <7.0.0.10.2.20051025164030.061cdfb0@vigilsec.com> <04e001c5da3e$25cb11a0$0200a8c0@simon> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Simon: I agree that the check need to be specified. And, we would require that successor documents to RFC 3279 would need to specify the criteria for setting the bit for that algorithm. In the development of ANSI X9.44, there was an informative annex on RSA Public-Key Validation and Plausibility Tests. I have not looked to see if it is in the most current version, but this is the checking that would be performed by the CA to set the bit. Russ At 11:01 AM 10/26/2005, Simon Blake-Wilson wrote: >Hi Russ, > >I have no problem with defining extensions for this, but I think it would >need to be made very clear somewhere what checks must be performed if the >public key validation extension is asserted. > >For DH for example, does it imply that subgroup membership ((g^x)^q=1 mod >p) has been checked? Not all protocols use subgroups for DH, do they? > >Other algorithms are harder. What exactly does public key validation for >RSA or NTRU or XYZ mean? > >I think the key here is that in some cases checking 0In others subgroup membership may also be needed. As a relying party I >need to know. > >I guess the checks that are performed could be specified in the CPS, but I >think it would be better put in the RFC itself. > >Best regards. Simon > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Russ Housley > > Sent: Tuesday, October 25, 2005 5:04 PM > > To: ietf-pkix@imc.org > > Subject: Public key validation and Proof of possession > > > > > > > > Dear PKIX WG: > > > > The draft NIST SP 800-56 defines the requirements for "Recipient > > Assurance of Static Public Key Validity." See Section > > 5.6.2.2, where it says: > > > > The recipient of a static public key shall obtain > > assurance of its validity > > in one or more of the following ways: > > > > 1. Recipient Full Validation - The recipient performs > > a successful full > > public key validation (see Sections 5.6.2.4 and 5.6.2.5). > > > > 2. TTP Full Validation - The recipient receives > > assurance that a trusted > > third party (trusted by the recipient) has performed a > > successful full > > public key validation (see Sections 5.6.2.4 and 5.6.2.5). > > > > 3. TTP Generation - The recipient receives assurance that a > > trusted third > > party (trusted by the recipient) has ge nerated the > > public/private key > > pair in accordance with Section 5.6.1 and has provided the > > key pair to > > the owner. > > > > It seems to me that option 2 was include to allow a CA to perform the > > public key validation once, and then any party that makes use of the > > certificate need not do it again. From a system performance > > perspective, this seems highly desirable. > > > > In some highly assured implementation environments, it seems > > desirable for there to me an indication in the certificate that this > > action was taken by the CA. One could determine which certification > > policies require the CA to take this action, but that means that the > > list of certification policies would be continually adjusted by an > > administrator. I would prefer a non-critical extension that declared > > that this action was taken by the CA. > > > > The draft NIST SP 800-56, Section 5.6.3.2 discusses the requirement > > for "Recipient Assurance of the Owner's Possession of a Static > > Private Key." That is, the topic we have been discussing for years > > on this list, calling it proof of possession. RFC 3647 includes a > > place in the certification policy to discuss this topic. (RFC 3647, > > Section 3.2.1: Method to prove possession of private key.) > > > > Again, in some highly assured implementation environments, it seems > > desirable for there to me an indication in the certificate that proof > > of possession was performed by the CA. I think it could be part of > > the same non-critical extension proposed above. > > > > I therefore propose that the PKIX WG generate a standards-track RFC > > to define a certificate extension to provide these indications. I > > propose a very simple syntax: > > > > id-pe-caChecks OBJECT IDENTIFIER ::= { id-pe } > > > > CAChecks ::= BIT STRING { > > publicKeyValadation (0), > > proofOfPossession (1) } > > > > Do others think this is a useful extension? > > > > 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 j9QInnEg088304; Wed, 26 Oct 2005 11:49:49 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QInnvR088303; Wed, 26 Oct 2005 11:49:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9QInl5R088296 for ; Wed, 26 Oct 2005 11:49:48 -0700 (PDT) (envelope-from tim.polk@nist.gov) 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 j9QInG0c030399; Wed, 26 Oct 2005 14:49:17 -0400 Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j9QIn5G4007441; Wed, 26 Oct 2005 14:49:08 -0400 (EDT) Message-Id: <5.1.0.14.2.20051026144124.040ce8d0@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 26 Oct 2005 14:52:50 -0400 To: denis.pinkas@bull.neT From: Tim Polk Subject: RE: Public key validation and Proof of possession Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis,

I did a quick search for the offending statement in RFC 3280 as well as 3280bis, but could not find it.  Are you thinking of a statement in CMP or CRMF?

Thanks,

Tim


At 04:50 PM 10/26/2005 +0200, denis.pinkas@bull.net wrote:
Russ,

My previous reply was too concise.

YES, I am suportive of publicKeyValadation (0), but please also note as Security Area Director
that a change to 3280bis should also be done : POP should no more be mandated in any case.

Denis


Denis:

Are you speaking in support of the extension that I proposed?

Russ

At 09:11 AM 10/26/2005, denis.pinkas@bull.net wrote:

>Russ and Stefan,
>
>This is an interresting issue. Thanks for raising it.
>
>(text deleted)
>
>So since POP always MUST be performed by the CA there seems not to be
>the need for diverse policies (POP and non POP).
>
>Once upon a time, in the early years of PKI, RFC 2459 stated that
>sentence that was blindly copied from document to document.
>
>In these early years, most (if not all) security protocols were
>badly designed and thus for them to remains secure
>the only way was to include the MUST condition.
>
>However since then, the earth has rotated and at least there now
>exists one case where POP is no more needed without any security threat.
>
>This case was introduced by S/MIME with the optionally signed
>attribute ESSCertID.
>
>It was then taken by ETSI with the mandatory ESSCetrtID (or iis
>equivalent that does not mandate the use of SHA-1).
>
>RFC 3126 specifies that format.
>
>Taking into consideration these facts, this means that there exists
>at least one case where POP does not need to be performed anymore.
>
>There still exists cases where it needs to be performed, in
>particular when the certificate is used for encryption purposes.
>
>I believe that POP is mandatory when the key is used for encryption purposes.
>
>I believe that POP is NOT REQUIRED when the key is used for non
>repudiation purposes (e.g. RFC 3126 is used).
>
>When the key is used for authentication purposes, then depending
>upon the characteristics of the protocol,
>it MAY be required or not. So in that case only, it would make sense
>to support the extension proposed by Russ.
>
>Denis
>
>=============================================================================
>
>Do you agree with these observations or have I missed something?
>
>
>Stefan Santesson
>Program Manager, Standards Liaison
>Windows Security
>
>
> > -----Original Message-----
> > From: owner-ietf-pkix@mail.imc.org
>[mailto:owner-ietf-pkix@mail.imc.org]
> > On Behalf Of Russ Housley
> > Sent: den 25 oktober 2005 23:04
> > To: ietf-pkix@imc.org
> > Subject: Public key validation and Proof of possession
> >
> >
> > Dear PKIX WG:
> >
> > The draft NIST SP 800-56 defines the requirements for "Recipient
> > Assurance of Static Public Key Validity." See Section 5.6.2.2, where
>it
> > says:
> >
> > The recipient of a static public key shall obtain assurance of its
> > validity
> > in one or more of the following ways:
> >
> > 1. Recipient Full Validation - The recipient performs a
>successful
> > full
> > public key validation (see Sections 5.6.2.4 and 5.6.2.5).
> >
> > 2. TTP Full Validation - The recipient receives assurance that
>a
> > trusted
> > third party (trusted by the recipient) has performed a
> > successful full
> > public key validation (see Sections 5.6.2.4 and 5.6.2.5).
> >
> > 3. TTP Generation - The recipient receives assurance that a
> > trusted third
> > party (trusted by the recipient) has ge nerated the
> > public/private key
> > pair in accordance with Section 5.6.1 and has provided the
> > key pair to
> > the owner.
> >
> > It seems to me that option 2 was include to allow a CA to perform the
> > public key validation once, and then any party that makes use of the
> > certificate need not do it again. From a system performance
> > perspective, this seems highly desirable.
> >
> > In some highly assured implementation environments, it seems
> > desirable for there to me an indication in the certificate that this
> > action was taken by the CA. One could determine which certification
> > policies require the CA to take this action, but that means that the
> > list of certification policies would be continually adjusted by an
> > administrator. I would prefer a non-critical extension that declared
> > that this action was taken by the CA.
> >
> > The draft NIST SP 800-56, Section 5.6.3.2 discusses the requirement
> > for "Recipient Assurance of the Owner's Possession of a Static
> > Private Key." That is, the topic we have been discussing for years
> > on this list, calling it proof of possession. RFC 3647 includes a
> > place in the certification policy to discuss this topic. (RFC 3647,
> > Section 3.2.1: Method to prove possession of private key.)
> >
> > Again, in some highly assured implementation environments, it seems
> > desirable for there to me an indication in the certificate that proof
> > of possession was performed by the CA. I think it could be part of
> > the same non-critical extension proposed above.
> >
> > I therefore propose that the PKIX WG generate a standards-track RFC
> > to define a certificate extension to provide these indications. I
> > propose a very simple syntax:
> >
> > id-pe-caChecks OBJECT IDENTIFIER ::= { id-pe <TBD> }
> >
> > CAChecks ::= BIT STRING {
> > publicKeyValadation (0),
> > proofOfPossession (1) }
> >
> > Do others think this is a useful extension?
> >
> > 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 j9QGjXDG074191; Wed, 26 Oct 2005 09:45:33 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QGjXIW074190; Wed, 26 Oct 2005 09:45:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9QGjWEH074179 for ; Wed, 26 Oct 2005 09:45:33 -0700 (PDT) (envelope-from kent@bbn.com) 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 j9QGjMIG016631; Wed, 26 Oct 2005 12:45:25 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <7.0.0.10.2.20051025164030.061cdfb0@vigilsec.com> References: <7.0.0.10.2.20051025164030.061cdfb0@vigilsec.com> Date: Wed, 26 Oct 2005 12:45:24 -0400 To: Russ Housley From: Stephen Kent Subject: Re: Public key validation and Proof of possession Cc: ietf-pkix@imc.org 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: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, I think this is a good suggestion, and the extension should be a simple as you suggest. Relying on this being in a CP is asking a lot in management terms, as you noted. However, one might also address this by defining an IETF-standard CP that addresses just these issues, and allowing CAs to add that CP to whatever other CP that assert in an cert. How do you feel about that alternative? 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 j9QF2awG061480; Wed, 26 Oct 2005 08:02:36 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QF2a6Y061479; Wed, 26 Oct 2005 08:02:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from bcisse.com (209-204-118-122.sniparpa.net [209.204.118.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9QF2ZOS061473 for ; Wed, 26 Oct 2005 08:02:35 -0700 (PDT) (envelope-from sblakewilson@bcisse.com) Received: from simon (toronto-HSE-ppp4162903.sympatico.ca [70.51.152.37]) by bcisse.com; Wed, 26 Oct 2005 11:01:31 -0400 From: "Simon Blake-Wilson" To: "'Russ Housley'" , Subject: RE: Public key validation and Proof of possession Date: Wed, 26 Oct 2005 11:01:29 -0400 Message-ID: <04e001c5da3e$25cb11a0$0200a8c0@simon> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 MIME-Version: 1.0 In-Reply-To: <7.0.0.10.2.20051025164030.061cdfb0@vigilsec.com> Importance: Normal Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_04DC_01C5DA1C.9DD441C0" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_04DC_01C5DA1C.9DD441C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Russ, I have no problem with defining extensions for this, but I think it would need to be made very clear somewhere what checks must be performed if the public key validation extension is asserted. For DH for example, does it imply that subgroup membership ((g^x)^q=1 mod p) has been checked? Not all protocols use subgroups for DH, do they? Other algorithms are harder. What exactly does public key validation for RSA or NTRU or XYZ mean? I think the key here is that in some cases checking 0 -----Original Message----- > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Russ Housley > Sent: Tuesday, October 25, 2005 5:04 PM > To: ietf-pkix@imc.org > Subject: Public key validation and Proof of possession > > > > Dear PKIX WG: > > The draft NIST SP 800-56 defines the requirements for "Recipient > Assurance of Static Public Key Validity." See Section > 5.6.2.2, where it says: > > The recipient of a static public key shall obtain > assurance of its validity > in one or more of the following ways: > > 1. Recipient Full Validation - The recipient performs > a successful full > public key validation (see Sections 5.6.2.4 and 5.6.2.5). > > 2. TTP Full Validation - The recipient receives > assurance that a trusted > third party (trusted by the recipient) has performed a > successful full > public key validation (see Sections 5.6.2.4 and 5.6.2.5). > > 3. TTP Generation - The recipient receives assurance that a > trusted third > party (trusted by the recipient) has ge nerated the > public/private key > pair in accordance with Section 5.6.1 and has provided the > key pair to > the owner. > > It seems to me that option 2 was include to allow a CA to perform the > public key validation once, and then any party that makes use of the > certificate need not do it again. From a system performance > perspective, this seems highly desirable. > > In some highly assured implementation environments, it seems > desirable for there to me an indication in the certificate that this > action was taken by the CA. One could determine which certification > policies require the CA to take this action, but that means that the > list of certification policies would be continually adjusted by an > administrator. I would prefer a non-critical extension that declared > that this action was taken by the CA. > > The draft NIST SP 800-56, Section 5.6.3.2 discusses the requirement > for "Recipient Assurance of the Owner's Possession of a Static > Private Key." That is, the topic we have been discussing for years > on this list, calling it proof of possession. RFC 3647 includes a > place in the certification policy to discuss this topic. (RFC 3647, > Section 3.2.1: Method to prove possession of private key.) > > Again, in some highly assured implementation environments, it seems > desirable for there to me an indication in the certificate that proof > of possession was performed by the CA. I think it could be part of > the same non-critical extension proposed above. > > I therefore propose that the PKIX WG generate a standards-track RFC > to define a certificate extension to provide these indications. I > propose a very simple syntax: > > id-pe-caChecks OBJECT IDENTIFIER ::= { id-pe } > > CAChecks ::= BIT STRING { > publicKeyValadation (0), > proofOfPossession (1) } > > Do others think this is a useful extension? > > Russ > > ------=_NextPart_000_04DC_01C5DA1C.9DD441C0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6DCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggNiMIICy6ADAgECAhAL2gsXwT+JjqsJdHq0zi4zMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo4GwMIGtMA8GA1UdEwQIMAYBAf8CAQAw RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L3BjYTEuY3JsMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAQYwDQYJKoZIhvcNAQECBQAD gYEAAn2eb0VLOKC43ulTZCG85Ewrjx7+kkCs2Ao5aqEyISwHm6tZ/tJiGn1VOLA3c9z0B2ZjYr3h U3BSh+eo2FLpWy2q4d7PrDFU1IsZyNgjqO8EKzJ9LBgcyHyJqC538kTRZQpNdLXu0xuSc3QuiTs1 E3LnQDGa07LEq+dWvovj+xUwggQ9MIIDpqADAgECAhA22vJQKV5JPY1TSL01WJuyMA0GCSqGSIb3 DQEBBQUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA1MDIxMDAwMDAw MFoXDTA2MDIyNDIzNTk1OVowggEdMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTQwMgYDVQQLEytEaWdpdGFsIElEIENsYXNzIDEgLSBNaWNyb3NvZnQgRnVs bCBTZXJ2aWNlMRswGQYDVQQDFBJTaW1vbiBCbGFrZS1XaWxzb24xJjAkBgkqhkiG9w0BCQEWF3Ni bGFrZXdpbHNvbkBiY2lzc2UuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDN6+R2i/J/ txDR7EcMMo43UUJ8fcKREr4helpUy0hhHDWYVsX6UQuhocexOVyUyg0vCsYJGJOj+QMLDSwH1Xw5 8DuRyIFK8XkNcOTCxQ1xdPtnD91x29s8MVRLlkUp9+0v1y4D9Gzl/TL1ZyhvMbRwtHMWrkIZBaat qwORMHQehQIDAQABo4HLMIHIMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAzAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEFBQADgYEAipzxjTv6HdVgTktxvwN2jeI05aKsWuAjnJG3sdEY+jEiznR881t/YJOVWJJ4g8QG 8dISKvQALdH+1f0hIwFgBwVQ9qQhoVkOjU94Ypio5F1CAWdaIE9gB6BceZLsc8GOC6g7UJQ2lZDr BwoMaYSJ4XA7FWFwEUSNNhuUk9BLmNIxggQ+MIIEOgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNp Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgx SDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNv bmEgTm90IFZhbGlkYXRlZAIQNtryUCleST2NU0i9NVibsjAJBgUrDgMCGgUAoIICsjAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTEwMjYxNTAxMjlaMCMGCSqGSIb3 DQEJBDEWBBSlcvsFQhJwYJeI4tbJSxG3JcsC4TBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMH MAcGBSsOAwIaMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDAKBggqhkiG9w0CBTCB8gYJKwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3 LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5 ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVy c29uYSBOb3QgVmFsaWRhdGVkAhA22vJQKV5JPY1TSL01WJuyMIH0BgsqhkiG9w0BCRACCzGB5KCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBC eSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQNtryUCleST2NU0i9NVibsjAN BgkqhkiG9w0BAQEFAASBgG5IGcBRxcMq2VhYwv4gmcMgR7L6qJ0pzsMrdtNhQ4NE75JMzKmegf4X O0b4Re4mZdrZIqlUYZBQn3c5RnpH7CqFZ65zT/J/pf/0ypcklwEwD/ONKz9NiJxiPNgN2hJKolht zRFJcPj12o7Q953EQFSbkzr57zXZkShW2+BGRW6/AAAAAAAA ------=_NextPart_000_04DC_01C5DA1C.9DD441C0-- 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 j9QEsIZh060574; Wed, 26 Oct 2005 07:54:18 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QEsI3a060573; Wed, 26 Oct 2005 07:54:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9QEsHhO060560 for ; Wed, 26 Oct 2005 07:54:17 -0700 (PDT) (envelope-from rtbell@cisco.com) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 26 Oct 2005 07:54:12 -0700 X-IronPort-AV: i="3.97,254,1125903600"; d="scan'208,217"; a="669423876:sNHT47124820" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9QEs2Jn029139; Wed, 26 Oct 2005 07:54:10 -0700 (PDT) Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 07:54:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5DA3D.1B60C823" Subject: RE: Public key validation and Proof of possession Date: Wed, 26 Oct 2005 07:54:01 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Public key validation and Proof of possession Thread-Index: AcXaO+w0meeI4lA0T2G5tPAR9vIOAgAAQ0gg From: "Bob Bell \(rtbell\)" To: Cc: "Stefan Santesson" , "Russ Housley" , X-OriginalArrivalTime: 26 Oct 2005 14:54:03.0936 (UTC) FILETIME=[1B830A00:01C5DA3D] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C5DA3D.1B60C823 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Denis -=20 =20 Comment in line. ________________________________ From: denis.pinkas@bull.net [mailto:denis.pinkas@bull.net]=20 Sent: Wednesday, October 26, 2005 08:46 To: Bob Bell (rtbell) Cc: Stefan Santesson; Russ Housley; ietf-pkix@imc.org Subject: RE: Public key validation and Proof of possession =09 =09 =09 Denis -=20 =20 I have a question. It would seem to me that for non-repudiation as with the other modes for the cert, without the POP step, there is no way to prove that I as the presenter of the Cert am truly entitled to claim that cert as mine. Since a cert is public information, available from multiple sources presumably, then anyone may acquire the cert. It is only by being able to prove that I have the private key through POP am I able to assert that the cert is in fact MY identity. =20 Am I missing something here? =20 =09 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D =20 May I say, yes ? :-) =20 An entity MUST still demonstrate who it is, in order to get the appropriate name in the certificate (subject field). =20 In the case of non repudiation, if an entity presents a public key that is not its, then he entity does not know the corresponding private key,=20 and hence is unable to use the certificate. Since using RFC 3126, the hash of the certificate (or teh certificate) MUST be protected by the digital signature, substitution of a certificate by another that would contain the same public key would be immediately detected.=20 =20 Ok. So this is the POP step I thought you were advocating we did not need. My mistake. Thanks.=20 =20 "Old" protocols were no using certificates. Then certificates were added, but external to the security protocol ("unprotected"). The right thing is to protect the certificate by the digital signature, as RFC 3126 is doing. Note that this allows to certify the same public key=20 with different attributes from different CAs. =20 So POP alone, is unable to solve the susbstitution of one certificate from a user by another legitimate certificate from the same user=20 with the same public key in it, but with a different name in it, or different attributes in it. =20 Denis =20 =20 Bob Bell =09 ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of denis.pinkas@bull.net Sent: Wednesday, October 26, 2005 07:12 To: Stefan Santesson Cc: Russ Housley; ietf-pkix@imc.org Subject: RE: Public key validation and Proof of possession =09 =09 =09 Russ and Stefan, This is an interresting issue. Thanks for raising it. (text deleted) =09 So since POP always MUST be performed by the CA there seems not to be the need for diverse policies (POP and non POP). =09 Once upon a time, in the early years of PKI, RFC 2459 stated that sentence that was blindly copied from document to document. In these early years, most (if not all) security protocols were badly designed and thus for them to remains secure the only way was to include the MUST condition. However since then, the earth has rotated and at least there now exists one case where POP is no more needed without any security threat. This case was introduced by S/MIME with the optionally signed attribute ESSCertID.=20 It was then taken by ETSI with the mandatory ESSCetrtID (or iis equivalent that does not mandate the use of SHA-1). RFC 3126 specifies that format. Taking into consideration these facts, this means that there exists at least one case where POP does not need to be performed anymore.=20 There still exists cases where it needs to be performed, in particular when the certificate is used for encryption purposes. I believe that POP is mandatory when the key is used for encryption purposes. I believe that POP is NOT REQUIRED when the key is used for non repudiation purposes (e.g. RFC 3126 is used). When the key is used for authentication purposes, then depending upon the characteristics of the protocol, it MAY be required or not. So in that case only, it would make sense to support the extension proposed by Russ. Denis =09 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D Do you agree with these observations or have I missed something? =09 =09 Stefan Santesson Program Manager, Standards Liaison Windows Security =09 =09 > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Russ Housley > Sent: den 25 oktober 2005 23:04 > To: ietf-pkix@imc.org > Subject: Public key validation and Proof of possession >=20 >=20 > Dear PKIX WG: >=20 > The draft NIST SP 800-56 defines the requirements for "Recipient > Assurance of Static Public Key Validity." See Section 5.6.2.2, where it > says: >=20 > The recipient of a static public key shall obtain assurance of its > validity > in one or more of the following ways: >=20 > 1. Recipient Full Validation - The recipient performs a successful > full > public key validation (see Sections 5.6.2.4 and 5.6.2.5). >=20 > 2. TTP Full Validation - The recipient receives assurance that a > trusted > third party (trusted by the recipient) has performed a > successful full > public key validation (see Sections 5.6.2.4 and 5.6.2.5). >=20 > 3. TTP Generation - The recipient receives assurance that a > trusted third > party (trusted by the recipient) has ge nerated the > public/private key > pair in accordance with Section 5.6.1 and has provided the > key pair to > the owner. >=20 > It seems to me that option 2 was include to allow a CA to perform the > public key validation once, and then any party that makes use of the > certificate need not do it again. From a system performance > perspective, this seems highly desirable. >=20 > In some highly assured implementation environments, it seems > desirable for there to me an indication in the certificate that this > action was taken by the CA. One could determine which certification > policies require the CA to take this action, but that means that the > list of certification policies would be continually adjusted by an > administrator. I would prefer a non-critical extension that declared > that this action was taken by the CA. >=20 > The draft NIST SP 800-56, Section 5.6.3.2 discusses the requirement > for "Recipient Assurance of the Owner's Possession of a Static > Private Key." That is, the topic we have been discussing for years > on this list, calling it proof of possession. RFC 3647 includes a > place in the certification policy to discuss this topic. (RFC 3647, > Section 3.2.1: Method to prove possession of private key.) >=20 > Again, in some highly assured implementation environments, it seems > desirable for there to me an indication in the certificate that proof > of possession was performed by the CA. I think it could be part of > the same non-critical extension proposed above. >=20 > I therefore propose that the PKIX WG generate a standards-track RFC > to define a certificate extension to provide these indications. I > propose a very simple syntax: >=20 > id-pe-caChecks OBJECT IDENTIFIER ::=3D { id-pe } >=20 > CAChecks ::=3D BIT STRING { > publicKeyValadation (0), > proofOfPossession (1) } >=20 > Do others think this is a useful extension? >=20 > Russ =09 =09 =09 ------_=_NextPart_001_01C5DA3D.1B60C823 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Denis -
 
Comment in line.

From: denis.pinkas@bull.net=20 [mailto:denis.pinkas@bull.net]
Sent: Wednesday, October 26, = 2005=20 08:46
To: Bob Bell (rtbell)
Cc: Stefan Santesson; = Russ=20 Housley; ietf-pkix@imc.org
Subject: RE: Public key = validation and=20 Proof of possession

Denis -
 
I have a question. It would seem to me that = for=20 non-repudiation as with the other modes for the cert, without the POP = step,=20 there is no way to prove that I as the presenter of the Cert am truly = entitled=20 to claim that cert as mine. Since a cert is public information, = available from=20 multiple sources presumably, then anyone may acquire the cert. It is = only by=20 being able to prove that I have the private key through POP am I able = to=20 assert that the cert is in fact MY identity.
 
Am I missing something = here?
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
 
May I say, yes ? :-)
 
An entity MUST still demonstrate who it is, in order to = get the=20 appropriate name in the certificate (subject = field).
 
In the case of non repudiation, if an = entity presents a=20 public key that is not its, then he entity does not know the=20 corresponding private key,
and hence is unable to use the certificate. Since = using RFC=20 3126, the hash of the certificate (or teh certificate) MUST be = protected=20
by the digital signature, substitution of a certificate by = another that=20 would contain the same public key would be immediately detected. 
 
Ok. So = this is the POP=20 step I thought you were advocating we did not need. My mistake.=20 Thanks. 
 
"Old" protocols were no using certificates. Then certificates = were added, but external to the security protocol=20 ("unprotected").
The right thing is to protect the certificate by the digital = signature,=20 as RFC 3126 is doing. Note that this allows to certify the same public = key=20
with different attributes from different = CAs.
 
So POP alone, is unable to solve the susbstitution of one = certificate=20 from a user by another legitimate certificate from the same user=20
with the same public key in it, but with a different = name in it, or=20 different attributes in it.
 
Denis
 
 
Bob Bell

From:=20 owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On=20 Behalf Of denis.pinkas@bull.net
Sent: Wednesday, = October 26,=20 2005 07:12
To: Stefan Santesson
Cc: Russ = Housley;=20 ietf-pkix@imc.org
Subject: RE: Public key validation and = Proof of=20 possession

Russ and Stefan,

This is an interresting issue. Thanks for raising=20 it.

(text deleted)

So since POP always MUST be = performed=20 by the CA there seems not to be
the need for diverse policies = (POP and=20 non POP).

Once upon a time, in the early years of PKI, RFC = 2459 stated=20 that sentence that was blindly copied from document to = document.

In these early years, most (if not all) security = protocols=20 were badly designed and thus for them to remains secure
the only = way was=20 to include the MUST condition.

However since then, the earth has rotated and at = least there=20 now exists one case where POP is no more needed without any = security=20 threat.

This case was introduced by S/MIME with the = optionally=20 signed attribute ESSCertID.

It was then taken by ETSI with the mandatory = ESSCetrtID (or=20 iis equivalent that does not mandate the use of SHA-1).

RFC 3126 specifies that format.

Taking into consideration these facts, this means = that there=20 exists at least one case where POP does not need to be performed = anymore.=20

There still exists cases where it needs to be = performed, in=20 particular when the certificate is used for encryption = purposes.

I believe that POP is mandatory when the key = is used=20 for encryption purposes.

I believe that POP is NOT REQUIRED when the key is = used for=20 non repudiation purposes (e.g. RFC 3126 is used).

When the key is used for authentication purposes, = then=20 depending upon the characteristics of the protocol,
it MAY be = required or=20 not. So in that case only, it would make sense to support the = extension=20 proposed by Russ.

Denis

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

Do you agree with these observations or have I = missed=20 something?


Stefan Santesson
Program Manager, Standards = Liaison
Windows Security


> -----Original=20 Message-----
> From:=20 = owner-ietf-pkix@mail.imc.org
[mailto:owner-ietf-pkix@mail.imc.org]
= >=20 On Behalf Of Russ Housley
> Sent: den 25 oktober 2005 = 23:04
>=20 To: ietf-pkix@imc.org
> Subject: Public key validation and = Proof of=20 possession
>
>
> Dear PKIX WG:
>
> = The=20 draft NIST SP 800-56 defines the requirements for "Recipient
> = Assurance of Static Public Key Validity." See Section 5.6.2.2,=20 where
it
> says:
>
> The recipient of a static = public=20 key shall obtain assurance of its
> validity
> in one or = more of=20 the following ways:
>
> 1. Recipient Full Validation - = The=20 recipient performs a
successful
> full
> public key=20 validation (see Sections 5.6.2.4 and 5.6.2.5).
>
> 2. = TTP Full=20 Validation - The recipient receives assurance that
a
>=20 trusted
> third party (trusted by the recipient) has performed = a
> successful full
> public key validation (see = Sections=20 5.6.2.4 and 5.6.2.5).
>
> 3. TTP Generation - The = recipient=20 receives assurance that a
> trusted third
> party = (trusted by=20 the recipient) has ge nerated the
> public/private key
> = pair in=20 accordance with Section 5.6.1 and has provided the
> key pair=20 to
> the owner.
>
> It seems to me that option 2 = was=20 include to allow a CA to perform the
> public key validation = once, and=20 then any party that makes use of the
> certificate need not do = it=20 again. From a system performance
> perspective, this seems = highly=20 desirable.
>
> In some highly assured implementation=20 environments, it seems
> desirable for there to me an = indication in=20 the certificate that this
> action was taken by the CA. One = could=20 determine which certification
> policies require the CA to = take this=20 action, but that means that the
> list of certification = policies would=20 be continually adjusted by an
> administrator. I would prefer = a=20 non-critical extension that declared
> that this action was = taken by=20 the CA.
>
> The draft NIST SP 800-56, Section 5.6.3.2 = discusses=20 the requirement
> for "Recipient Assurance of the Owner's = Possession=20 of a Static
> Private Key." That is, the topic we have been = discussing=20 for years
> on this list, calling it proof of possession. RFC = 3647=20 includes a
> place in the certification policy to discuss this = topic.=20 (RFC 3647,
> Section 3.2.1: Method to prove possession of = private=20 key.)
>
> Again, in some highly assured implementation=20 environments, it seems
> desirable for there to me an = indication in=20 the certificate that proof
> of possession was performed by = the CA. I=20 think it could be part of
> the same non-critical extension = proposed=20 above.
>
> I therefore propose that the PKIX WG = generate a=20 standards-track RFC
> to define a certificate extension to = provide=20 these indications. I
> propose a very simple syntax:
> =
>=20 id-pe-caChecks OBJECT IDENTIFIER ::=3D { id-pe <TBD> }
> =
>=20 CAChecks ::=3D BIT STRING {
> publicKeyValadation (0),
> = proofOfPossession (1) }
>
> Do others think this is a = useful=20 extension?
>
>=20 Russ


------_=_NextPart_001_01C5DA3D.1B60C823-- 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 j9QEncvc060270; Wed, 26 Oct 2005 07:49:38 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QEncvB060269; Wed, 26 Oct 2005 07:49:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9QEnbqQ060258 for ; Wed, 26 Oct 2005 07:49:37 -0700 (PDT) (envelope-from denis.pinkas@bull.net) 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 RAA37038; Wed, 26 Oct 2005 17:06:51 +0200 Importance: Normal X-Priority: 3 (Normal) Subject: RE: Public key validation and Proof of possession MIME-Version: 1.0 From: denis.pinkas@bull.net To: Russ Housley Cc: "Stefan Santesson" , Date: Wed, 26 Oct 2005 16:50:10 +0200 Message-ID: X-MIMETrack: Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 26/10/2005 16:50:10 MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: PEZPTlQgZmFjZT0iRGVmYXVsdCBTYW5zIFNlcmlmLCBWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNh LCBzYW5zLXNlcmlmIiBzaXplPTI+PERJVj48Rk9OVCBjb2xvcj0jMDA5OTAwPlJ1c3MsPC9GT05U PjwvRElWPjxQPjxGT05UIGNvbG9yPSMwMDk5MDA+TXkgcHJldmlvdXMgcmVwbHkgd2FzIHRvbyBj b25jaXNlLjwvRk9OVD48L1A+PFA+PEZPTlQgY29sb3I9IzAwOTkwMD5ZRVMsIEkgYW0gc3Vwb3J0 aXZlIG9mIHB1YmxpY0tleVZhbGFkYXRpb24gKDApLCBidXQgcGxlYXNlIGFsc28gbm90ZSBhcyBT ZWN1cml0eSBBcmVhIERpcmVjdG9yPEJSPnRoYXQgYSBjaGFuZ2UgdG8gMzI4MGJpcyBzaG91bGQg YWxzbyBiZSBkb25lIDogUE9QIHNob3VsZCBubyBtb3JlIGJlIG1hbmRhdGVkIGluIGFueSBjYXNl LjwvRk9OVD48L1A+PFA+PEZPTlQgY29sb3I9IzAwOTkwMD5EZW5pczwvRk9OVD48L1A+PFA+PEJS PkRlbmlzOjxCUj48QlI+QXJlIHlvdSBzcGVha2luZyBpbiBzdXBwb3J0IG9mIHRoZSBleHRlbnNp b24gdGhhdCBJIHByb3Bvc2VkPzxCUj48QlI+UnVzczxCUj48QlI+QXQgMDk6MTEgQU0gMTAvMjYv MjAwNSwgZGVuaXMucGlua2FzQGJ1bGwubmV0IHdyb3RlOjxCUj48QlI+Jmd0O1J1c3MgYW5kIFN0 ZWZhbiw8QlI+Jmd0OzxCUj4mZ3Q7VGhpcyBpcyBhbiBpbnRlcnJlc3RpbmcgaXNzdWUuIFRoYW5r cyBmb3IgcmFpc2luZyBpdC48QlI+Jmd0OzxCUj4mZ3Q7KHRleHQgZGVsZXRlZCk8QlI+Jmd0OzxC Uj4mZ3Q7U28gc2luY2UgUE9QIGFsd2F5cyBNVVNUIGJlIHBlcmZvcm1lZCBieSB0aGUgQ0EgdGhl cmUgc2VlbXMgbm90IHRvIGJlPEJSPiZndDt0aGUgbmVlZCBmb3IgZGl2ZXJzZSBwb2xpY2llcyAo UE9QIGFuZCBub24gUE9QKS48QlI+Jmd0OzxCUj4mZ3Q7T25jZSB1cG9uIGEgdGltZSwgaW4gdGhl IGVhcmx5IHllYXJzIG9mIFBLSSwgUkZDIDI0NTkgc3RhdGVkIHRoYXQgPEJSPiZndDtzZW50ZW5j ZSB0aGF0IHdhcyBibGluZGx5IGNvcGllZCBmcm9tIGRvY3VtZW50IHRvIGRvY3VtZW50LjxCUj4m Z3Q7PEJSPiZndDtJbiB0aGVzZSBlYXJseSB5ZWFycywgbW9zdCAoaWYgbm90IGFsbCkgc2VjdXJp dHkgcHJvdG9jb2xzIHdlcmUgPEJSPiZndDtiYWRseSBkZXNpZ25lZCBhbmQgdGh1cyBmb3IgdGhl bSB0byByZW1haW5zIHNlY3VyZTxCUj4mZ3Q7dGhlIG9ubHkgd2F5IHdhcyB0byBpbmNsdWRlIHRo ZSBNVVNUIGNvbmRpdGlvbi48QlI+Jmd0OzxCUj4mZ3Q7SG93ZXZlciBzaW5jZSB0aGVuLCB0aGUg ZWFydGggaGFzIHJvdGF0ZWQgYW5kIGF0IGxlYXN0IHRoZXJlIG5vdyA8QlI+Jmd0O2V4aXN0cyBv bmUgY2FzZSB3aGVyZSBQT1AgaXMgbm8gbW9yZSBuZWVkZWQgd2l0aG91dCBhbnkgc2VjdXJpdHkg dGhyZWF0LjxCUj4mZ3Q7PEJSPiZndDtUaGlzIGNhc2Ugd2FzIGludHJvZHVjZWQgYnkgUy9NSU1F IHdpdGggdGhlIG9wdGlvbmFsbHkgc2lnbmVkIDxCUj4mZ3Q7YXR0cmlidXRlIEVTU0NlcnRJRC48 QlI+Jmd0OzxCUj4mZ3Q7SXQgd2FzIHRoZW4gdGFrZW4gYnkgRVRTSSB3aXRoIHRoZSBtYW5kYXRv cnkgRVNTQ2V0cnRJRCAob3IgaWlzIDxCUj4mZ3Q7ZXF1aXZhbGVudCB0aGF0IGRvZXMgbm90IG1h bmRhdGUgdGhlIHVzZSBvZiBTSEEtMSkuPEJSPiZndDs8QlI+Jmd0O1JGQyAzMTI2IHNwZWNpZmll cyB0aGF0IGZvcm1hdC48QlI+Jmd0OzxCUj4mZ3Q7VGFraW5nIGludG8gY29uc2lkZXJhdGlvbiB0 aGVzZSBmYWN0cywgdGhpcyBtZWFucyB0aGF0IHRoZXJlIGV4aXN0cyA8QlI+Jmd0O2F0IGxlYXN0 IG9uZSBjYXNlIHdoZXJlIFBPUCBkb2VzIG5vdCBuZWVkIHRvIGJlIHBlcmZvcm1lZCBhbnltb3Jl LjxCUj4mZ3Q7PEJSPiZndDtUaGVyZSBzdGlsbCBleGlzdHMgY2FzZXMgd2hlcmUgaXQgbmVlZHMg dG8gYmUgcGVyZm9ybWVkLCBpbiA8QlI+Jmd0O3BhcnRpY3VsYXIgd2hlbiB0aGUgY2VydGlmaWNh dGUgaXMgdXNlZCBmb3IgZW5jcnlwdGlvbiBwdXJwb3Nlcy48QlI+Jmd0OzxCUj4mZ3Q7SSBiZWxp ZXZlIHRoYXQgUE9QIGlzIG1hbmRhdG9yeSB3aGVuIHRoZSBrZXkgaXMgdXNlZCBmb3IgZW5jcnlw dGlvbiBwdXJwb3Nlcy48QlI+Jmd0OzxCUj4mZ3Q7SSBiZWxpZXZlIHRoYXQgUE9QIGlzIE5PVCBS RVFVSVJFRCB3aGVuIHRoZSBrZXkgaXMgdXNlZCBmb3Igbm9uIDxCUj4mZ3Q7cmVwdWRpYXRpb24g cHVycG9zZXMgKGUuZy4gUkZDIDMxMjYgaXMgdXNlZCkuPEJSPiZndDs8QlI+Jmd0O1doZW4gdGhl IGtleSBpcyB1c2VkIGZvciBhdXRoZW50aWNhdGlvbiBwdXJwb3NlcywgdGhlbiBkZXBlbmRpbmcg PEJSPiZndDt1cG9uIHRoZSBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhlIHByb3RvY29sLDxCUj4mZ3Q7 aXQgTUFZIGJlIHJlcXVpcmVkIG9yIG5vdC4gU28gaW4gdGhhdCBjYXNlIG9ubHksIGl0IHdvdWxk IG1ha2Ugc2Vuc2UgPEJSPiZndDt0byBzdXBwb3J0IHRoZSBleHRlbnNpb24gcHJvcG9zZWQgYnkg UnVzcy48QlI+Jmd0OzxCUj4mZ3Q7RGVuaXM8QlI+Jmd0OzxCUj4mZ3Q7PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT08QlI+Jmd0OzxCUj4mZ3Q7RG8geW91IGFncmVlIHdpdGggdGhlc2Ugb2JzZXJ2YXRpb25z IG9yIGhhdmUgSSBtaXNzZWQgc29tZXRoaW5nPzxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0O1N0ZWZh biBTYW50ZXNzb248QlI+Jmd0O1Byb2dyYW0gTWFuYWdlciwgU3RhbmRhcmRzIExpYWlzb248QlI+ Jmd0O1dpbmRvd3MgU2VjdXJpdHk8QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDsgJmd0OyAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj4mZ3Q7ICZndDsgRnJvbTogb3duZXItaWV0Zi1wa2l4QG1h aWwuaW1jLm9yZzxCUj4mZ3Q7W21haWx0bzpvd25lci1pZXRmLXBraXhAbWFpbC5pbWMub3JnXTxC Uj4mZ3Q7ICZndDsgT24gQmVoYWxmIE9mIFJ1c3MgSG91c2xleTxCUj4mZ3Q7ICZndDsgU2VudDog ZGVuIDI1IG9rdG9iZXIgMjAwNSAyMzowNDxCUj4mZ3Q7ICZndDsgVG86IGlldGYtcGtpeEBpbWMu b3JnPEJSPiZndDsgJmd0OyBTdWJqZWN0OiBQdWJsaWMga2V5IHZhbGlkYXRpb24gYW5kIFByb29m IG9mIHBvc3Nlc3Npb248QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgRGVh ciBQS0lYIFdHOjxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IFRoZSBkcmFmdCBOSVNUIFNQIDgw MC01NiBkZWZpbmVzIHRoZSByZXF1aXJlbWVudHMgZm9yICJSZWNpcGllbnQ8QlI+Jmd0OyAmZ3Q7 IEFzc3VyYW5jZSBvZiBTdGF0aWMgUHVibGljIEtleSBWYWxpZGl0eS4iIFNlZSBTZWN0aW9uIDUu Ni4yLjIsIHdoZXJlPEJSPiZndDtpdDxCUj4mZ3Q7ICZndDsgc2F5czo8QlI+Jmd0OyAmZ3Q7PEJS PiZndDsgJmd0OyBUaGUgcmVjaXBpZW50IG9mIGEgc3RhdGljIHB1YmxpYyBrZXkgc2hhbGwgb2J0 YWluIGFzc3VyYW5jZSBvZiBpdHM8QlI+Jmd0OyAmZ3Q7IHZhbGlkaXR5PEJSPiZndDsgJmd0OyBp biBvbmUgb3IgbW9yZSBvZiB0aGUgZm9sbG93aW5nIHdheXM6PEJSPiZndDsgJmd0OzxCUj4mZ3Q7 ICZndDsgMS4gUmVjaXBpZW50IEZ1bGwgVmFsaWRhdGlvbiAtIFRoZSByZWNpcGllbnQgcGVyZm9y bXMgYTxCUj4mZ3Q7c3VjY2Vzc2Z1bDxCUj4mZ3Q7ICZndDsgZnVsbDxCUj4mZ3Q7ICZndDsgcHVi bGljIGtleSB2YWxpZGF0aW9uIChzZWUgU2VjdGlvbnMgNS42LjIuNCBhbmQgNS42LjIuNSkuPEJS PiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgMi4gVFRQIEZ1bGwgVmFsaWRhdGlvbiAtIFRoZSByZWNp cGllbnQgcmVjZWl2ZXMgYXNzdXJhbmNlIHRoYXQ8QlI+Jmd0O2E8QlI+Jmd0OyAmZ3Q7IHRydXN0 ZWQ8QlI+Jmd0OyAmZ3Q7IHRoaXJkIHBhcnR5ICh0cnVzdGVkIGJ5IHRoZSByZWNpcGllbnQpIGhh cyBwZXJmb3JtZWQgYTxCUj4mZ3Q7ICZndDsgc3VjY2Vzc2Z1bCBmdWxsPEJSPiZndDsgJmd0OyBw dWJsaWMga2V5IHZhbGlkYXRpb24gKHNlZSBTZWN0aW9ucyA1LjYuMi40IGFuZCA1LjYuMi41KS48 QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAzLiBUVFAgR2VuZXJhdGlvbiAtIFRoZSByZWNpcGll bnQgcmVjZWl2ZXMgYXNzdXJhbmNlIHRoYXQgYTxCUj4mZ3Q7ICZndDsgdHJ1c3RlZCB0aGlyZDxC Uj4mZ3Q7ICZndDsgcGFydHkgKHRydXN0ZWQgYnkgdGhlIHJlY2lwaWVudCkgaGFzIGdlIG5lcmF0 ZWQgdGhlPEJSPiZndDsgJmd0OyBwdWJsaWMvcHJpdmF0ZSBrZXk8QlI+Jmd0OyAmZ3Q7IHBhaXIg aW4gYWNjb3JkYW5jZSB3aXRoIFNlY3Rpb24gNS42LjEgYW5kIGhhcyBwcm92aWRlZCB0aGU8QlI+ Jmd0OyAmZ3Q7IGtleSBwYWlyIHRvPEJSPiZndDsgJmd0OyB0aGUgb3duZXIuPEJSPiZndDsgJmd0 OzxCUj4mZ3Q7ICZndDsgSXQgc2VlbXMgdG8gbWUgdGhhdCBvcHRpb24gMiB3YXMgaW5jbHVkZSB0 byBhbGxvdyBhIENBIHRvIHBlcmZvcm0gdGhlPEJSPiZndDsgJmd0OyBwdWJsaWMga2V5IHZhbGlk YXRpb24gb25jZSwgYW5kIHRoZW4gYW55IHBhcnR5IHRoYXQgbWFrZXMgdXNlIG9mIHRoZTxCUj4m Z3Q7ICZndDsgY2VydGlmaWNhdGUgbmVlZCBub3QgZG8gaXQgYWdhaW4uIEZyb20gYSBzeXN0ZW0g cGVyZm9ybWFuY2U8QlI+Jmd0OyAmZ3Q7IHBlcnNwZWN0aXZlLCB0aGlzIHNlZW1zIGhpZ2hseSBk ZXNpcmFibGUuPEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgSW4gc29tZSBoaWdobHkgYXNzdXJl ZCBpbXBsZW1lbnRhdGlvbiBlbnZpcm9ubWVudHMsIGl0IHNlZW1zPEJSPiZndDsgJmd0OyBkZXNp cmFibGUgZm9yIHRoZXJlIHRvIG1lIGFuIGluZGljYXRpb24gaW4gdGhlIGNlcnRpZmljYXRlIHRo YXQgdGhpczxCUj4mZ3Q7ICZndDsgYWN0aW9uIHdhcyB0YWtlbiBieSB0aGUgQ0EuIE9uZSBjb3Vs ZCBkZXRlcm1pbmUgd2hpY2ggY2VydGlmaWNhdGlvbjxCUj4mZ3Q7ICZndDsgcG9saWNpZXMgcmVx dWlyZSB0aGUgQ0EgdG8gdGFrZSB0aGlzIGFjdGlvbiwgYnV0IHRoYXQgbWVhbnMgdGhhdCB0aGU8 QlI+Jmd0OyAmZ3Q7IGxpc3Qgb2YgY2VydGlmaWNhdGlvbiBwb2xpY2llcyB3b3VsZCBiZSBjb250 aW51YWxseSBhZGp1c3RlZCBieSBhbjxCUj4mZ3Q7ICZndDsgYWRtaW5pc3RyYXRvci4gSSB3b3Vs ZCBwcmVmZXIgYSBub24tY3JpdGljYWwgZXh0ZW5zaW9uIHRoYXQgZGVjbGFyZWQ8QlI+Jmd0OyAm Z3Q7IHRoYXQgdGhpcyBhY3Rpb24gd2FzIHRha2VuIGJ5IHRoZSBDQS48QlI+Jmd0OyAmZ3Q7PEJS PiZndDsgJmd0OyBUaGUgZHJhZnQgTklTVCBTUCA4MDAtNTYsIFNlY3Rpb24gNS42LjMuMiBkaXNj dXNzZXMgdGhlIHJlcXVpcmVtZW50PEJSPiZndDsgJmd0OyBmb3IgIlJlY2lwaWVudCBBc3N1cmFu Y2Ugb2YgdGhlIE93bmVyJ3MgUG9zc2Vzc2lvbiBvZiBhIFN0YXRpYzxCUj4mZ3Q7ICZndDsgUHJp dmF0ZSBLZXkuIiBUaGF0IGlzLCB0aGUgdG9waWMgd2UgaGF2ZSBiZWVuIGRpc2N1c3NpbmcgZm9y IHllYXJzPEJSPiZndDsgJmd0OyBvbiB0aGlzIGxpc3QsIGNhbGxpbmcgaXQgcHJvb2Ygb2YgcG9z c2Vzc2lvbi4gUkZDIDM2NDcgaW5jbHVkZXMgYTxCUj4mZ3Q7ICZndDsgcGxhY2UgaW4gdGhlIGNl cnRpZmljYXRpb24gcG9saWN5IHRvIGRpc2N1c3MgdGhpcyB0b3BpYy4gKFJGQyAzNjQ3LDxCUj4m Z3Q7ICZndDsgU2VjdGlvbiAzLjIuMTogTWV0aG9kIHRvIHByb3ZlIHBvc3Nlc3Npb24gb2YgcHJp dmF0ZSBrZXkuKTxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IEFnYWluLCBpbiBzb21lIGhpZ2hs eSBhc3N1cmVkIGltcGxlbWVudGF0aW9uIGVudmlyb25tZW50cywgaXQgc2VlbXM8QlI+Jmd0OyAm Z3Q7IGRlc2lyYWJsZSBmb3IgdGhlcmUgdG8gbWUgYW4gaW5kaWNhdGlvbiBpbiB0aGUgY2VydGlm aWNhdGUgdGhhdCBwcm9vZjxCUj4mZ3Q7ICZndDsgb2YgcG9zc2Vzc2lvbiB3YXMgcGVyZm9ybWVk IGJ5IHRoZSBDQS4gSSB0aGluayBpdCBjb3VsZCBiZSBwYXJ0IG9mPEJSPiZndDsgJmd0OyB0aGUg c2FtZSBub24tY3JpdGljYWwgZXh0ZW5zaW9uIHByb3Bvc2VkIGFib3ZlLjxCUj4mZ3Q7ICZndDs8 QlI+Jmd0OyAmZ3Q7IEkgdGhlcmVmb3JlIHByb3Bvc2UgdGhhdCB0aGUgUEtJWCBXRyBnZW5lcmF0 ZSBhIHN0YW5kYXJkcy10cmFjayBSRkM8QlI+Jmd0OyAmZ3Q7IHRvIGRlZmluZSBhIGNlcnRpZmlj YXRlIGV4dGVuc2lvbiB0byBwcm92aWRlIHRoZXNlIGluZGljYXRpb25zLiBJPEJSPiZndDsgJmd0 OyBwcm9wb3NlIGEgdmVyeSBzaW1wbGUgc3ludGF4OjxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7 IGlkLXBlLWNhQ2hlY2tzIE9CSkVDVCBJREVOVElGSUVSIDo6PSB7IGlkLXBlICZsdDtUQkQmZ3Q7 IH08QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyBDQUNoZWNrcyA6Oj0gICAgQklUIFNUUklORyB7 PEJSPiZndDsgJmd0OyBwdWJsaWNLZXlWYWxhZGF0aW9uICgwKSw8QlI+Jmd0OyAmZ3Q7IHByb29m T2ZQb3NzZXNzaW9uICgxKSB9PEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgRG8gb3RoZXJzIHRo aW5rIHRoaXMgaXMgYSB1c2VmdWwgZXh0ZW5zaW9uPzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7 IFJ1c3M8QlI+Jmd0OzxCUj48QlI+PC9QPjwvRk9OVD4= 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 j9QEjRBE059963; Wed, 26 Oct 2005 07:45:27 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QEjRUk059962; Wed, 26 Oct 2005 07:45:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9QEjPNG059952 for ; Wed, 26 Oct 2005 07:45:25 -0700 (PDT) (envelope-from denis.pinkas@bull.net) 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 RAA41408; Wed, 26 Oct 2005 17:02:29 +0200 Importance: Normal X-Priority: 3 (Normal) Subject: RE: Public key validation and Proof of possession MIME-Version: 1.0 From: denis.pinkas@bull.net To: "Bob Bell \(rtbell\)" Cc: "Stefan Santesson" , "Russ Housley" , Date: Wed, 26 Oct 2005 16:45:47 +0200 Message-ID: X-MIMETrack: Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 26/10/2005 16:45:49 MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: PEZPTlQgZmFjZT0iRGVmYXVsdCBTYW5zIFNlcmlmLCBWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNh LCBzYW5zLXNlcmlmIiBzaXplPTI+PERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9 NDA1MjQzNjEzLTI2MTAyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+ RGVuaXMgLSA8L0ZPTlQ+PC9TUEFOPjwvRElWPjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFO IGNsYXNzPTQwNTI0MzYxMy0yNjEwMjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYg c2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+PERJViBkaXI9bHRyIGFsaWduPWxlZnQ+ PFNQQU4gY2xhc3M9NDA1MjQzNjEzLTI2MTAyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAw MDBmZiBzaXplPTI+SSBoYXZlIGEgcXVlc3Rpb24uIEl0IHdvdWxkIHNlZW0gdG8gbWUgdGhhdCBm b3Igbm9uLXJlcHVkaWF0aW9uIGFzIHdpdGggdGhlIG90aGVyIG1vZGVzIGZvciB0aGUgY2VydCwg d2l0aG91dCB0aGUgUE9QIHN0ZXAsIHRoZXJlIGlzIG5vIHdheSB0byBwcm92ZSB0aGF0IEkgYXMg dGhlIHByZXNlbnRlciBvZiB0aGUgQ2VydCBhbSB0cnVseSBlbnRpdGxlZCB0byBjbGFpbSB0aGF0 IGNlcnQgYXMgbWluZS4gU2luY2UgYSBjZXJ0IGlzIHB1YmxpYyBpbmZvcm1hdGlvbiwgYXZhaWxh YmxlIGZyb20gbXVsdGlwbGUgc291cmNlcyBwcmVzdW1hYmx5LCB0aGVuIGFueW9uZSBtYXkgYWNx dWlyZSB0aGUgY2VydC4gSXQgaXMgb25seSBieSBiZWluZyBhYmxlIHRvIHByb3ZlIHRoYXQgSSBo YXZlIHRoZSBwcml2YXRlIGtleSB0aHJvdWdoIFBPUCBhbSBJIGFibGUgdG8gYXNzZXJ0IHRoYXQg dGhlIGNlcnQgaXMgaW4gZmFjdCBNWSBpZGVudGl0eS48L0ZPTlQ+PC9TUEFOPjwvRElWPjxESVYg ZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTQwNTI0MzYxMy0yNjEwMjAwNT48Rk9OVCBm YWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+ PERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NDA1MjQzNjEzLTI2MTAyMDA1PjxG T05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+QW0gSSBtaXNzaW5nIHNvbWV0aGlu ZyBoZXJlPzwvRk9OVD48L1NQQU4+PC9ESVY+PERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4g Y2xhc3M9NDA1MjQzNjEzLTI2MTAyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZj48 L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNs YXNzPTQwNTI0MzYxMy0yNjEwMjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmY+PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L0ZPTlQ+PC9TUEFO PjwvRElWPjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTQwNTI0MzYxMy0yNjEw MjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmY+PC9GT05UPjwvU1BBTj4mbmJzcDs8 L0RJVj48RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz00MDUyNDM2MTMtMjYxMDIw MDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMDAwPk1heSZuYnNwO0kgc2F5LCB5ZXMgPyA6 LSk8L0ZPTlQ+PC9TUEFOPjwvRElWPjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNz PTQwNTI0MzYxMy0yNjEwMjAwNT48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD48L1NQQU4+Jm5ic3A7 PC9ESVY+PERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NDA1MjQzNjEzLTI2MTAy MDA1PjxGT05UIGZhY2U9QXJpYWw+QW4gZW50aXR5IE1VU1Qgc3RpbGwgZGVtb25zdHJhdGUgd2hv IGl0IGlzLCBpbiBvcmRlciB0byBnZXQmbmJzcDt0aGUgYXBwcm9wcmlhdGUgbmFtZSBpbiB0aGUg Y2VydGlmaWNhdGUgKHN1YmplY3QgZmllbGQpLjwvRk9OVD48L1NQQU4+PC9ESVY+PERJViBkaXI9 bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NDA1MjQzNjEzLTI2MTAyMDA1PjxGT05UIGZhY2U9 QXJpYWw+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj48RElWIGRpcj1sdHIgYWxpZ249bGVmdD48 U1BBTiBjbGFzcz00MDUyNDM2MTMtMjYxMDIwMDU+PEZPTlQgZmFjZT1BcmlhbD5JbiB0aGUgY2Fz ZSBvZiBub24gcmVwdWRpYXRpb24sIGlmJm5ic3A7YW4gZW50aXR5Jm5ic3A7cHJlc2VudHMgYSBw dWJsaWMga2V5IHRoYXQgaXMgbm90IGl0cywgdGhlbiBoZSBlbnRpdHkmbmJzcDtkb2VzIG5vdCBr bm93IHRoZSBjb3JyZXNwb25kaW5nIHByaXZhdGUga2V5LCA8L0ZPTlQ+PC9TUEFOPjwvRElWPjxE SVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTQwNTI0MzYxMy0yNjEwMjAwNT48Rk9O VCBmYWNlPUFyaWFsPmFuZCBoZW5jZSZuYnNwO2lzJm5ic3A7dW5hYmxlIHRvIHVzZSB0aGUgY2Vy dGlmaWNhdGUuIFNpbmNlIHVzaW5nIFJGQyAzMTI2LCB0aGUgaGFzaCBvZiB0aGUgY2VydGlmaWNh dGUgKG9yIHRlaCBjZXJ0aWZpY2F0ZSkgTVVTVCBiZSBwcm90ZWN0ZWQgPC9GT05UPjwvU1BBTj48 L0RJVj48RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz00MDUyNDM2MTMtMjYxMDIw MDU+PEZPTlQgZmFjZT1BcmlhbD5ieSB0aGUgZGlnaXRhbCBzaWduYXR1cmUsIHN1YnN0aXR1dGlv biBvZiBhIGNlcnRpZmljYXRlIGJ5IGFub3RoZXIgdGhhdCB3b3VsZCBjb250YWluIHRoZSBzYW1l IHB1YmxpYyBrZXkgd291bGQgYmUgaW1tZWRpYXRlbHkgZGV0ZWN0ZWQuPC9GT05UPjwvU1BBTj48 L0RJVj48RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz00MDUyNDM2MTMtMjYxMDIw MDU+PEZPTlQgZmFjZT1BcmlhbD48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPjxESVYgZGlyPWx0 ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTQwNTI0MzYxMy0yNjEwMjAwNT48Rk9OVCBmYWNlPUFy aWFsPiJPbGQiIHByb3RvY29scyB3ZXJlIG5vIHVzaW5nIGNlcnRpZmljYXRlcy4gVGhlbiBjZXJ0 aWZpY2F0ZXMgd2VyZSZuYnNwO2FkZGVkLCBidXQmbmJzcDtleHRlcm5hbCB0byB0aGUgc2VjdXJp dHkgcHJvdG9jb2wgKCJ1bnByb3RlY3RlZCIpLjwvRk9OVD48L1NQQU4+PC9ESVY+PERJViBkaXI9 bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NDA1MjQzNjEzLTI2MTAyMDA1PjxGT05UIGZhY2U9 QXJpYWw+VGhlIHJpZ2h0IHRoaW5nIGlzIHRvIHByb3RlY3QgdGhlIGNlcnRpZmljYXRlIGJ5IHRo ZSBkaWdpdGFsIHNpZ25hdHVyZSwgYXMgUkZDIDMxMjYgaXMgZG9pbmcuIE5vdGUgdGhhdCB0aGlz IGFsbG93cyB0byBjZXJ0aWZ5IHRoZSBzYW1lIHB1YmxpYyBrZXkgPC9GT05UPjwvU1BBTj48L0RJ Vj48RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz00MDUyNDM2MTMtMjYxMDIwMDU+ PEZPTlQgZmFjZT1BcmlhbD53aXRoIGRpZmZlcmVudCBhdHRyaWJ1dGVzIGZyb20gZGlmZmVyZW50 IENBcy48L0ZPTlQ+PC9TUEFOPjwvRElWPjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNs YXNzPTQwNTI0MzYxMy0yNjEwMjAwNT48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD48L1NQQU4+Jm5i c3A7PC9ESVY+PERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NDA1MjQzNjEzLTI2 MTAyMDA1PjxGT05UIGZhY2U9QXJpYWw+U28gUE9QIGFsb25lLCBpcyB1bmFibGUgdG8gc29sdmUg dGhlIHN1c2JzdGl0dXRpb24gb2Ygb25lIGNlcnRpZmljYXRlIGZyb20gYSB1c2VyIGJ5IGFub3Ro ZXIgbGVnaXRpbWF0ZSZuYnNwO2NlcnRpZmljYXRlIGZyb20gdGhlIHNhbWUgdXNlciA8L0ZPTlQ+ PC9TUEFOPjwvRElWPjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTQwNTI0MzYx My0yNjEwMjAwNT48Rk9OVCBmYWNlPUFyaWFsPndpdGggdGhlIHNhbWUgcHVibGljIGtleSBpbiBp dCwgPC9GT05UPjwvU1BBTj48U1BBTiBjbGFzcz00MDUyNDM2MTMtMjYxMDIwMDU+PEZPTlQgZmFj ZT1BcmlhbD5idXQgd2l0aCBhIGRpZmZlcmVudCBuYW1lIGluIGl0LCBvciBkaWZmZXJlbnQgYXR0 cmlidXRlcyBpbiBpdC48L0ZPTlQ+PC9TUEFOPjwvRElWPjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0 PjxTUEFOIGNsYXNzPTQwNTI0MzYxMy0yNjEwMjAwNT48L1NQQU4+PFNQQU4gY2xhc3M9NDA1MjQz NjEzLTI2MTAyMDA1PjwvU1BBTj48U1BBTiBjbGFzcz00MDUyNDM2MTMtMjYxMDIwMDU+PC9TUEFO PjxTUEFOIGNsYXNzPTQwNTI0MzYxMy0yNjEwMjAwNT48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD48 L1NQQU4+Jm5ic3A7PC9ESVY+PERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NDA1 MjQzNjEzLTI2MTAyMDA1PjxGT05UIGZhY2U9QXJpYWw+RGVuaXM8L0ZPTlQ+PC9TUEFOPjwvRElW PjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTQwNTI0MzYxMy0yNjEwMjAwNT48 L1NQQU4+PFNQQU4gY2xhc3M9NDA1MjQzNjEzLTI2MTAyMDA1PjwvU1BBTj48U1BBTiBjbGFzcz00 MDUyNDM2MTMtMjYxMDIwMDU+PC9TUEFOPjxTUEFOIGNsYXNzPTQwNTI0MzYxMy0yNjEwMjAwNT48 L1NQQU4+PFNQQU4gY2xhc3M9NDA1MjQzNjEzLTI2MTAyMDA1PjwvU1BBTj48U1BBTiBjbGFzcz00 MDUyNDM2MTMtMjYxMDIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmPjwvRk9OVD48 L1NQQU4+Jm5ic3A7PC9ESVY+PERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NDA1 MjQzNjEzLTI2MTAyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PC9G T05UPjwvU1BBTj4mbmJzcDs8L0RJVj48RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFz cz00MDUyNDM2MTMtMjYxMDIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9 Mj5Cb2IgQmVsbDwvRk9OVD48L1NQQU4+PC9ESVY+PEJSPjxCTE9DS1FVT1RFIGRpcj1sdHIgPiAg PERJViBjbGFzcz1PdXRsb29rTWVzc2FnZUhlYWRlciBsYW5nPWVuLXVzIGRpcj1sdHIgYWxpZ249 bGVmdD4gIDxIUiB0YWJJbmRleD0tMT4gIDxGT05UIGZhY2U9VGFob21hIHNpemU9Mj48Qj5Gcm9t OjwvQj4gb3duZXItaWV0Zi1wa2l4QG1haWwuaW1jLm9yZyAgIFttYWlsdG86b3duZXItaWV0Zi1w a2l4QG1haWwuaW1jLm9yZ10gPEI+T24gQmVoYWxmIE9mICAgPC9CPmRlbmlzLnBpbmthc0BidWxs Lm5ldDxCUj48Qj5TZW50OjwvQj4gV2VkbmVzZGF5LCBPY3RvYmVyIDI2LCAyMDA1ICAgMDc6MTI8 QlI+PEI+VG86PC9CPiBTdGVmYW4gU2FudGVzc29uPEJSPjxCPkNjOjwvQj4gUnVzcyBIb3VzbGV5 OyAgIGlldGYtcGtpeEBpbWMub3JnPEJSPjxCPlN1YmplY3Q6PC9CPiBSRTogUHVibGljIGtleSB2 YWxpZGF0aW9uIGFuZCBQcm9vZiBvZiAgIHBvc3Nlc3Npb248QlI+PC9GT05UPjxCUj48L0RJVj4g IDxESVY+PC9ESVY+PEZPTlQgICAgICAgICAgICBmYWNlPSJEZWZhdWx0IFNhbnMgU2VyaWYsIFZl cmRhbmEsIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiIHNpemU9MiAgPiAgPFA+UnVzcyBh bmQgU3RlZmFuLDwvUD4gIDxQPlRoaXMgaXMgYW4gaW50ZXJyZXN0aW5nIGlzc3VlLiBUaGFua3Mg Zm9yIHJhaXNpbmcgaXQuPC9QPiAgPFA+KHRleHQgZGVsZXRlZCk8QlI+PEJSPlNvIHNpbmNlIFBP UCBhbHdheXMgTVVTVCBiZSBwZXJmb3JtZWQgYnkgdGhlIENBIHRoZXJlICAgc2VlbXMgbm90IHRv IGJlPEJSPnRoZSBuZWVkIGZvciBkaXZlcnNlIHBvbGljaWVzIChQT1AgYW5kIG5vbiBQT1ApLjxC Uj48L1A+ICA8UD5PbmNlIHVwb24gYSB0aW1lLCBpbiB0aGUgZWFybHkgeWVhcnMgb2YgUEtJLCBS RkMgMjQ1OSBzdGF0ZWQgdGhhdCBzZW50ZW5jZSAgIHRoYXQgd2FzIGJsaW5kbHkgY29waWVkIGZy b20gZG9jdW1lbnQgdG8gZG9jdW1lbnQuPC9QPiAgPFA+SW4gdGhlc2UgZWFybHkgeWVhcnMsIG1v c3QgKGlmIG5vdCBhbGwpIHNlY3VyaXR5IHByb3RvY29scyB3ZXJlIGJhZGx5ICAgZGVzaWduZWQg YW5kIHRodXMgZm9yIHRoZW0gdG8gcmVtYWlucyBzZWN1cmU8QlI+dGhlIG9ubHkgd2F5IHdhcyB0 byBpbmNsdWRlICAgdGhlIE1VU1QgY29uZGl0aW9uLjwvUD4gIDxQPkhvd2V2ZXIgc2luY2UgdGhl biwgdGhlIGVhcnRoIGhhcyByb3RhdGVkIGFuZCBhdCBsZWFzdCB0aGVyZSBub3cgZXhpc3RzICAg b25lJm5ic3A7Y2FzZSB3aGVyZSBQT1AgaXMgbm8gbW9yZSBuZWVkZWQgd2l0aG91dCBhbnkgc2Vj dXJpdHkgdGhyZWF0LjwvUD4gIDxQPlRoaXMgY2FzZSB3YXMgaW50cm9kdWNlZCBieSBTL01JTUUg d2l0aCB0aGUgb3B0aW9uYWxseSBzaWduZWQgYXR0cmlidXRlICAgRVNTQ2VydElELiA8L1A+ICA8 UD5JdCB3YXMgdGhlbiB0YWtlbiBieSBFVFNJIHdpdGggdGhlIG1hbmRhdG9yeSBFU1NDZXRydElE IChvciBpaXMgZXF1aXZhbGVudCAgIHRoYXQgZG9lcyBub3QgbWFuZGF0ZSB0aGUgdXNlIG9mIFNI QS0xKS48L1A+ICA8UD5SRkMgMzEyNiBzcGVjaWZpZXMgdGhhdCBmb3JtYXQuPC9QPiAgPFA+VGFr aW5nIGludG8gY29uc2lkZXJhdGlvbiB0aGVzZSBmYWN0cywgdGhpcyBtZWFucyB0aGF0IHRoZXJl IGV4aXN0cyBhdCAgIGxlYXN0IG9uZSBjYXNlIHdoZXJlIFBPUCBkb2VzIG5vdCBuZWVkIHRvIGJl IHBlcmZvcm1lZCBhbnltb3JlLiA8L1A+ICA8UD5UaGVyZSBzdGlsbCBleGlzdHMgY2FzZXMgd2hl cmUgaXQgbmVlZHMgdG8gYmUgcGVyZm9ybWVkLCBpbiBwYXJ0aWN1bGFyIHdoZW4gICB0aGUgY2Vy dGlmaWNhdGUgaXMgdXNlZCBmb3IgZW5jcnlwdGlvbiBwdXJwb3Nlcy48L1A+ICA8UD5JJm5ic3A7 YmVsaWV2ZSB0aGF0IFBPUCBpcyBtYW5kYXRvcnkgd2hlbiB0aGUga2V5IGlzIHVzZWQgZm9yIGVu Y3J5cHRpb24gICBwdXJwb3Nlcy48L1A+ICA8UD5JIGJlbGlldmUgdGhhdCBQT1AgaXMgTk9UIFJF UVVJUkVEIHdoZW4gdGhlIGtleSBpcyB1c2VkIGZvciBub24gcmVwdWRpYXRpb24gICBwdXJwb3Nl cyAoZS5nLiBSRkMgMzEyNiBpcyB1c2VkKS48L1A+ICA8UD5XaGVuIHRoZSBrZXkgaXMgdXNlZCBm b3IgYXV0aGVudGljYXRpb24gcHVycG9zZXMsIHRoZW4gZGVwZW5kaW5nIHVwb24gdGhlICAgY2hh cmFjdGVyaXN0aWNzIG9mIHRoZSBwcm90b2NvbCw8QlI+aXQgTUFZIGJlIHJlcXVpcmVkIG9yIG5v dC4gU28gaW4gdGhhdCBjYXNlICAgb25seSwgaXQgd291bGQgbWFrZSBzZW5zZSB0byBzdXBwb3J0 IHRoZSBleHRlbnNpb24gcHJvcG9zZWQgYnkgUnVzcy48L1A+ICA8UD5EZW5pczwvUD4gIDxQPj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PC9QPiAgPFA+RG8geW91IGFncmVlIHdpdGggdGhlc2Ugb2JzZXJ2 YXRpb25zIG9yIGhhdmUgSSBtaXNzZWQgICBzb21ldGhpbmc/PEJSPjxCUj48QlI+U3RlZmFuIFNh bnRlc3NvbjxCUj5Qcm9ncmFtIE1hbmFnZXIsIFN0YW5kYXJkcyAgIExpYWlzb248QlI+V2luZG93 cyBTZWN1cml0eTxCUj48QlI+PEJSPiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+ Jmd0OyAgIEZyb206ICAgb3duZXItaWV0Zi1wa2l4QG1haWwuaW1jLm9yZzxCUj5bbWFpbHRvOm93 bmVyLWlldGYtcGtpeEBtYWlsLmltYy5vcmddPEJSPiZndDsgICBPbiBCZWhhbGYgT2YgUnVzcyBI b3VzbGV5PEJSPiZndDsgU2VudDogZGVuIDI1IG9rdG9iZXIgMjAwNSAyMzowNDxCUj4mZ3Q7IFRv OiAgIGlldGYtcGtpeEBpbWMub3JnPEJSPiZndDsgU3ViamVjdDogUHVibGljIGtleSB2YWxpZGF0 aW9uIGFuZCBQcm9vZiBvZiAgIHBvc3Nlc3Npb248QlI+Jmd0OyA8QlI+Jmd0OyA8QlI+Jmd0OyBE ZWFyIFBLSVggV0c6PEJSPiZndDsgPEJSPiZndDsgVGhlIGRyYWZ0ICAgTklTVCBTUCA4MDAtNTYg ZGVmaW5lcyB0aGUgcmVxdWlyZW1lbnRzIGZvciAiUmVjaXBpZW50PEJSPiZndDsgQXNzdXJhbmNl IG9mICAgU3RhdGljIFB1YmxpYyBLZXkgVmFsaWRpdHkuIiBTZWUgU2VjdGlvbiA1LjYuMi4yLCB3 aGVyZTxCUj5pdDxCUj4mZ3Q7ICAgc2F5czo8QlI+Jmd0OyA8QlI+Jmd0OyBUaGUgcmVjaXBpZW50 IG9mIGEgc3RhdGljIHB1YmxpYyBrZXkgc2hhbGwgb2J0YWluICAgYXNzdXJhbmNlIG9mIGl0czxC Uj4mZ3Q7IHZhbGlkaXR5PEJSPiZndDsgaW4gb25lIG9yIG1vcmUgb2YgdGhlIGZvbGxvd2luZyAg IHdheXM6PEJSPiZndDsgPEJSPiZndDsgMS4gUmVjaXBpZW50IEZ1bGwgVmFsaWRhdGlvbiAtIFRo ZSByZWNpcGllbnQgcGVyZm9ybXMgICBhPEJSPnN1Y2Nlc3NmdWw8QlI+Jmd0OyBmdWxsPEJSPiZn dDsgcHVibGljIGtleSB2YWxpZGF0aW9uIChzZWUgU2VjdGlvbnMgICA1LjYuMi40IGFuZCA1LjYu Mi41KS48QlI+Jmd0OyA8QlI+Jmd0OyAyLiBUVFAgRnVsbCBWYWxpZGF0aW9uIC0gVGhlIHJlY2lw aWVudCAgIHJlY2VpdmVzIGFzc3VyYW5jZSB0aGF0PEJSPmE8QlI+Jmd0OyB0cnVzdGVkPEJSPiZn dDsgdGhpcmQgcGFydHkgKHRydXN0ZWQgYnkgICB0aGUgcmVjaXBpZW50KSBoYXMgcGVyZm9ybWVk IGE8QlI+Jmd0OyBzdWNjZXNzZnVsIGZ1bGw8QlI+Jmd0OyBwdWJsaWMga2V5ICAgdmFsaWRhdGlv biAoc2VlIFNlY3Rpb25zIDUuNi4yLjQgYW5kIDUuNi4yLjUpLjxCUj4mZ3Q7IDxCUj4mZ3Q7IDMu IFRUUCAgIEdlbmVyYXRpb24gLSBUaGUgcmVjaXBpZW50IHJlY2VpdmVzIGFzc3VyYW5jZSB0aGF0 IGE8QlI+Jmd0OyB0cnVzdGVkICAgdGhpcmQ8QlI+Jmd0OyBwYXJ0eSAodHJ1c3RlZCBieSB0aGUg cmVjaXBpZW50KSBoYXMgZ2UgbmVyYXRlZCB0aGU8QlI+Jmd0OyAgIHB1YmxpYy9wcml2YXRlIGtl eTxCUj4mZ3Q7IHBhaXIgaW4gYWNjb3JkYW5jZSB3aXRoIFNlY3Rpb24gNS42LjEgYW5kIGhhcyAg IHByb3ZpZGVkIHRoZTxCUj4mZ3Q7IGtleSBwYWlyIHRvPEJSPiZndDsgdGhlIG93bmVyLjxCUj4m Z3Q7IDxCUj4mZ3Q7IEl0IHNlZW1zICAgdG8gbWUgdGhhdCBvcHRpb24gMiB3YXMgaW5jbHVkZSB0 byBhbGxvdyBhIENBIHRvIHBlcmZvcm0gdGhlPEJSPiZndDsgcHVibGljICAga2V5IHZhbGlkYXRp b24gb25jZSwgYW5kIHRoZW4gYW55IHBhcnR5IHRoYXQgbWFrZXMgdXNlIG9mIHRoZTxCUj4mZ3Q7 ICAgY2VydGlmaWNhdGUgbmVlZCBub3QgZG8gaXQgYWdhaW4uIEZyb20gYSBzeXN0ZW0gcGVyZm9y bWFuY2U8QlI+Jmd0OyAgIHBlcnNwZWN0aXZlLCB0aGlzIHNlZW1zIGhpZ2hseSBkZXNpcmFibGUu PEJSPiZndDsgPEJSPiZndDsgSW4gc29tZSBoaWdobHkgICBhc3N1cmVkIGltcGxlbWVudGF0aW9u IGVudmlyb25tZW50cywgaXQgc2VlbXM8QlI+Jmd0OyBkZXNpcmFibGUgZm9yIHRoZXJlIHRvICAg bWUgYW4gaW5kaWNhdGlvbiBpbiB0aGUgY2VydGlmaWNhdGUgdGhhdCB0aGlzPEJSPiZndDsgYWN0 aW9uIHdhcyB0YWtlbiBieSB0aGUgICBDQS4gT25lIGNvdWxkIGRldGVybWluZSB3aGljaCBjZXJ0 aWZpY2F0aW9uPEJSPiZndDsgcG9saWNpZXMgcmVxdWlyZSB0aGUgQ0EgdG8gICB0YWtlIHRoaXMg YWN0aW9uLCBidXQgdGhhdCBtZWFucyB0aGF0IHRoZTxCUj4mZ3Q7IGxpc3Qgb2YgY2VydGlmaWNh dGlvbiAgIHBvbGljaWVzIHdvdWxkIGJlIGNvbnRpbnVhbGx5IGFkanVzdGVkIGJ5IGFuPEJSPiZn dDsgYWRtaW5pc3RyYXRvci4gSSB3b3VsZCAgIHByZWZlciBhIG5vbi1jcml0aWNhbCBleHRlbnNp b24gdGhhdCBkZWNsYXJlZDxCUj4mZ3Q7IHRoYXQgdGhpcyBhY3Rpb24gd2FzICAgdGFrZW4gYnkg dGhlIENBLjxCUj4mZ3Q7IDxCUj4mZ3Q7IFRoZSBkcmFmdCBOSVNUIFNQIDgwMC01NiwgU2VjdGlv biA1LjYuMy4yICAgZGlzY3Vzc2VzIHRoZSByZXF1aXJlbWVudDxCUj4mZ3Q7IGZvciAiUmVjaXBp ZW50IEFzc3VyYW5jZSBvZiB0aGUgT3duZXIncyAgIFBvc3Nlc3Npb24gb2YgYSBTdGF0aWM8QlI+ Jmd0OyBQcml2YXRlIEtleS4iIFRoYXQgaXMsIHRoZSB0b3BpYyB3ZSBoYXZlIGJlZW4gICBkaXNj dXNzaW5nIGZvciB5ZWFyczxCUj4mZ3Q7IG9uIHRoaXMgbGlzdCwgY2FsbGluZyBpdCBwcm9vZiBv ZiBwb3NzZXNzaW9uLiBSRkMgICAzNjQ3IGluY2x1ZGVzIGE8QlI+Jmd0OyBwbGFjZSBpbiB0aGUg Y2VydGlmaWNhdGlvbiBwb2xpY3kgdG8gZGlzY3VzcyB0aGlzICAgdG9waWMuIChSRkMgMzY0Nyw8 QlI+Jmd0OyBTZWN0aW9uIDMuMi4xOiBNZXRob2QgdG8gcHJvdmUgcG9zc2Vzc2lvbiBvZiBwcml2 YXRlICAga2V5Lik8QlI+Jmd0OyA8QlI+Jmd0OyBBZ2FpbiwgaW4gc29tZSBoaWdobHkgYXNzdXJl ZCBpbXBsZW1lbnRhdGlvbiAgIGVudmlyb25tZW50cywgaXQgc2VlbXM8QlI+Jmd0OyBkZXNpcmFi bGUgZm9yIHRoZXJlIHRvIG1lIGFuIGluZGljYXRpb24gaW4gdGhlICAgY2VydGlmaWNhdGUgdGhh dCBwcm9vZjxCUj4mZ3Q7IG9mIHBvc3Nlc3Npb24gd2FzIHBlcmZvcm1lZCBieSB0aGUgQ0EuIEkg dGhpbmsgICBpdCBjb3VsZCBiZSBwYXJ0IG9mPEJSPiZndDsgdGhlIHNhbWUgbm9uLWNyaXRpY2Fs IGV4dGVuc2lvbiBwcm9wb3NlZCAgIGFib3ZlLjxCUj4mZ3Q7IDxCUj4mZ3Q7IEkgdGhlcmVmb3Jl IHByb3Bvc2UgdGhhdCB0aGUgUEtJWCBXRyBnZW5lcmF0ZSBhICAgc3RhbmRhcmRzLXRyYWNrIFJG QzxCUj4mZ3Q7IHRvIGRlZmluZSBhIGNlcnRpZmljYXRlIGV4dGVuc2lvbiB0byBwcm92aWRlIHRo ZXNlICAgaW5kaWNhdGlvbnMuIEk8QlI+Jmd0OyBwcm9wb3NlIGEgdmVyeSBzaW1wbGUgc3ludGF4 OjxCUj4mZ3Q7IDxCUj4mZ3Q7ICAgaWQtcGUtY2FDaGVja3MgT0JKRUNUIElERU5USUZJRVIgOjo9 IHsgaWQtcGUgJmx0O1RCRCZndDsgfTxCUj4mZ3Q7IDxCUj4mZ3Q7ICAgQ0FDaGVja3MgOjo9IEJJ VCBTVFJJTkcgezxCUj4mZ3Q7IHB1YmxpY0tleVZhbGFkYXRpb24gKDApLDxCUj4mZ3Q7ICAgcHJv b2ZPZlBvc3Nlc3Npb24gKDEpIH08QlI+Jmd0OyA8QlI+Jmd0OyBEbyBvdGhlcnMgdGhpbmsgdGhp cyBpcyBhIHVzZWZ1bCAgIGV4dGVuc2lvbj88QlI+Jmd0OyA8QlI+Jmd0OyBSdXNzPEJSPjxCUj48 QlI+PC9QPjwvQkxPQ0tRVU9URT48L0ZPTlQ+PC9GT05UPg== 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 j9QESrlC058257; Wed, 26 Oct 2005 07:28:53 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QESrx6058256; Wed, 26 Oct 2005 07:28:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9QESqP8058234 for ; Wed, 26 Oct 2005 07:28:52 -0700 (PDT) (envelope-from denis.pinkas@bull.net) 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 QAA60612; Wed, 26 Oct 2005 16:45:58 +0200 Importance: Normal X-Priority: 3 (Normal) Subject: RE: Public key validation and Proof of possession MIME-Version: 1.0 From: denis.pinkas@bull.net To: Russ Housley Cc: "Stefan Santesson" , Date: Wed, 26 Oct 2005 16:29:17 +0200 Message-ID: X-MIMETrack: Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 26/10/2005 16:29:18 MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: PEZPTlQgZmFjZT0iRGVmYXVsdCBTYW5zIFNlcmlmLCBWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNh LCBzYW5zLXNlcmlmIiBzaXplPTI+PFA+PEJSPkRlbmlzOjxCUj48QlI+QXJlIHlvdSBzcGVha2lu ZyBpbiBzdXBwb3J0IG9mIHRoZSBleHRlbnNpb24gdGhhdCBJIHByb3Bvc2VkPzxCUj48QlI+UnVz czwvUD48UD49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PC9QPjxQPlRoZSBhbnN3ZXIgaXMgeWVzIGZvciBwcm9vZk9mUG9zc2Vzc2lvbiAoMSkuIFNp bmNlIEkgaGF2ZSBub3QgeWV0IHJlYWQgdGhlIE5JU1QgZHJhZnQsPEJSPkkgaGF2ZSBubyBvcGlu aW9uIGF0IHRoaXMgdGltZSBvbiBwdWJsaWNLZXlWYWxpZGF0aW9uICgwKS48L1A+PFA+RGVuaXM8 L1A+PFA+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PTwvUD48UD5BdCAwOToxMSBBTSAxMC8yNi8yMDA1LCBkZW5pcy5waW5rYXNAYnVsbC5uZXQgd3Jv dGU6PEJSPjxCUj4mZ3Q7UnVzcyBhbmQgU3RlZmFuLDxCUj4mZ3Q7PEJSPiZndDtUaGlzIGlzIGFu IGludGVycmVzdGluZyBpc3N1ZS4gVGhhbmtzIGZvciByYWlzaW5nIGl0LjxCUj4mZ3Q7PEJSPiZn dDsodGV4dCBkZWxldGVkKTxCUj4mZ3Q7PEJSPiZndDtTbyBzaW5jZSBQT1AgYWx3YXlzIE1VU1Qg YmUgcGVyZm9ybWVkIGJ5IHRoZSBDQSB0aGVyZSBzZWVtcyBub3QgdG8gYmU8QlI+Jmd0O3RoZSBu ZWVkIGZvciBkaXZlcnNlIHBvbGljaWVzIChQT1AgYW5kIG5vbiBQT1ApLjxCUj4mZ3Q7PEJSPiZn dDtPbmNlIHVwb24gYSB0aW1lLCBpbiB0aGUgZWFybHkgeWVhcnMgb2YgUEtJLCBSRkMgMjQ1OSBz dGF0ZWQgdGhhdCA8QlI+Jmd0O3NlbnRlbmNlIHRoYXQgd2FzIGJsaW5kbHkgY29waWVkIGZyb20g ZG9jdW1lbnQgdG8gZG9jdW1lbnQuPEJSPiZndDs8QlI+Jmd0O0luIHRoZXNlIGVhcmx5IHllYXJz LCBtb3N0IChpZiBub3QgYWxsKSBzZWN1cml0eSBwcm90b2NvbHMgd2VyZSA8QlI+Jmd0O2JhZGx5 IGRlc2lnbmVkIGFuZCB0aHVzIGZvciB0aGVtIHRvIHJlbWFpbnMgc2VjdXJlPEJSPiZndDt0aGUg b25seSB3YXkgd2FzIHRvIGluY2x1ZGUgdGhlIE1VU1QgY29uZGl0aW9uLjxCUj4mZ3Q7PEJSPiZn dDtIb3dldmVyIHNpbmNlIHRoZW4sIHRoZSBlYXJ0aCBoYXMgcm90YXRlZCBhbmQgYXQgbGVhc3Qg dGhlcmUgbm93IDxCUj4mZ3Q7ZXhpc3RzIG9uZSBjYXNlIHdoZXJlIFBPUCBpcyBubyBtb3JlIG5l ZWRlZCB3aXRob3V0IGFueSBzZWN1cml0eSB0aHJlYXQuPEJSPiZndDs8QlI+Jmd0O1RoaXMgY2Fz ZSB3YXMgaW50cm9kdWNlZCBieSBTL01JTUUgd2l0aCB0aGUgb3B0aW9uYWxseSBzaWduZWQgPEJS PiZndDthdHRyaWJ1dGUgRVNTQ2VydElELjxCUj4mZ3Q7PEJSPiZndDtJdCB3YXMgdGhlbiB0YWtl biBieSBFVFNJIHdpdGggdGhlIG1hbmRhdG9yeSBFU1NDZXRydElEIChvciBpaXMgPEJSPiZndDtl cXVpdmFsZW50IHRoYXQgZG9lcyBub3QgbWFuZGF0ZSB0aGUgdXNlIG9mIFNIQS0xKS48QlI+Jmd0 OzxCUj4mZ3Q7UkZDIDMxMjYgc3BlY2lmaWVzIHRoYXQgZm9ybWF0LjxCUj4mZ3Q7PEJSPiZndDtU YWtpbmcgaW50byBjb25zaWRlcmF0aW9uIHRoZXNlIGZhY3RzLCB0aGlzIG1lYW5zIHRoYXQgdGhl cmUgZXhpc3RzIDxCUj4mZ3Q7YXQgbGVhc3Qgb25lIGNhc2Ugd2hlcmUgUE9QIGRvZXMgbm90IG5l ZWQgdG8gYmUgcGVyZm9ybWVkIGFueW1vcmUuPEJSPiZndDs8QlI+Jmd0O1RoZXJlIHN0aWxsIGV4 aXN0cyBjYXNlcyB3aGVyZSBpdCBuZWVkcyB0byBiZSBwZXJmb3JtZWQsIGluIDxCUj4mZ3Q7cGFy dGljdWxhciB3aGVuIHRoZSBjZXJ0aWZpY2F0ZSBpcyB1c2VkIGZvciBlbmNyeXB0aW9uIHB1cnBv c2VzLjxCUj4mZ3Q7PEJSPiZndDtJIGJlbGlldmUgdGhhdCBQT1AgaXMgbWFuZGF0b3J5IHdoZW4g dGhlIGtleSBpcyB1c2VkIGZvciBlbmNyeXB0aW9uIHB1cnBvc2VzLjxCUj4mZ3Q7PEJSPiZndDtJ IGJlbGlldmUgdGhhdCBQT1AgaXMgTk9UIFJFUVVJUkVEIHdoZW4gdGhlIGtleSBpcyB1c2VkIGZv ciBub24gPEJSPiZndDtyZXB1ZGlhdGlvbiBwdXJwb3NlcyAoZS5nLiBSRkMgMzEyNiBpcyB1c2Vk KS48QlI+Jmd0OzxCUj4mZ3Q7V2hlbiB0aGUga2V5IGlzIHVzZWQgZm9yIGF1dGhlbnRpY2F0aW9u IHB1cnBvc2VzLCB0aGVuIGRlcGVuZGluZyA8QlI+Jmd0O3Vwb24gdGhlIGNoYXJhY3RlcmlzdGlj cyBvZiB0aGUgcHJvdG9jb2wsPEJSPiZndDtpdCBNQVkgYmUgcmVxdWlyZWQgb3Igbm90LiBTbyBp biB0aGF0IGNhc2Ugb25seSwgaXQgd291bGQgbWFrZSBzZW5zZSA8QlI+Jmd0O3RvIHN1cHBvcnQg dGhlIGV4dGVuc2lvbiBwcm9wb3NlZCBieSBSdXNzLjxCUj4mZ3Q7PEJSPiZndDtEZW5pczxCUj4m Z3Q7PEJSPiZndDs9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxCUj4mZ3Q7PEJSPiZndDtEbyB5b3UgYWdy ZWUgd2l0aCB0aGVzZSBvYnNlcnZhdGlvbnMgb3IgaGF2ZSBJIG1pc3NlZCBzb21ldGhpbmc/PEJS PiZndDs8QlI+Jmd0OzxCUj4mZ3Q7U3RlZmFuIFNhbnRlc3NvbjxCUj4mZ3Q7UHJvZ3JhbSBNYW5h Z2VyLCBTdGFuZGFyZHMgTGlhaXNvbjxCUj4mZ3Q7V2luZG93cyBTZWN1cml0eTxCUj4mZ3Q7PEJS PiZndDs8QlI+Jmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPEJSPiZndDsgJmd0 OyBGcm9tOiBvd25lci1pZXRmLXBraXhAbWFpbC5pbWMub3JnPEJSPiZndDtbbWFpbHRvOm93bmVy LWlldGYtcGtpeEBtYWlsLmltYy5vcmddPEJSPiZndDsgJmd0OyBPbiBCZWhhbGYgT2YgUnVzcyBI b3VzbGV5PEJSPiZndDsgJmd0OyBTZW50OiBkZW4gMjUgb2t0b2JlciAyMDA1IDIzOjA0PEJSPiZn dDsgJmd0OyBUbzogaWV0Zi1wa2l4QGltYy5vcmc8QlI+Jmd0OyAmZ3Q7IFN1YmplY3Q6IFB1Ymxp YyBrZXkgdmFsaWRhdGlvbiBhbmQgUHJvb2Ygb2YgcG9zc2Vzc2lvbjxCUj4mZ3Q7ICZndDs8QlI+ Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyBEZWFyIFBLSVggV0c6PEJSPiZndDsgJmd0OzxCUj4mZ3Q7 ICZndDsgVGhlIGRyYWZ0IE5JU1QgU1AgODAwLTU2IGRlZmluZXMgdGhlIHJlcXVpcmVtZW50cyBm b3IgIlJlY2lwaWVudDxCUj4mZ3Q7ICZndDsgQXNzdXJhbmNlIG9mIFN0YXRpYyBQdWJsaWMgS2V5 IFZhbGlkaXR5LiIgU2VlIFNlY3Rpb24gNS42LjIuMiwgd2hlcmU8QlI+Jmd0O2l0PEJSPiZndDsg Jmd0OyBzYXlzOjxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IFRoZSByZWNpcGllbnQgb2YgYSBz dGF0aWMgcHVibGljIGtleSBzaGFsbCBvYnRhaW4gYXNzdXJhbmNlIG9mIGl0czxCUj4mZ3Q7ICZn dDsgdmFsaWRpdHk8QlI+Jmd0OyAmZ3Q7IGluIG9uZSBvciBtb3JlIG9mIHRoZSBmb2xsb3dpbmcg d2F5czo8QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAxLiBSZWNpcGllbnQgRnVsbCBWYWxpZGF0 aW9uIC0gVGhlIHJlY2lwaWVudCBwZXJmb3JtcyBhPEJSPiZndDtzdWNjZXNzZnVsPEJSPiZndDsg Jmd0OyBmdWxsPEJSPiZndDsgJmd0OyBwdWJsaWMga2V5IHZhbGlkYXRpb24gKHNlZSBTZWN0aW9u cyA1LjYuMi40IGFuZCA1LjYuMi41KS48QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAyLiBUVFAg RnVsbCBWYWxpZGF0aW9uIC0gVGhlIHJlY2lwaWVudCByZWNlaXZlcyBhc3N1cmFuY2UgdGhhdDxC Uj4mZ3Q7YTxCUj4mZ3Q7ICZndDsgdHJ1c3RlZDxCUj4mZ3Q7ICZndDsgdGhpcmQgcGFydHkgKHRy dXN0ZWQgYnkgdGhlIHJlY2lwaWVudCkgaGFzIHBlcmZvcm1lZCBhPEJSPiZndDsgJmd0OyBzdWNj ZXNzZnVsIGZ1bGw8QlI+Jmd0OyAmZ3Q7IHB1YmxpYyBrZXkgdmFsaWRhdGlvbiAoc2VlIFNlY3Rp b25zIDUuNi4yLjQgYW5kIDUuNi4yLjUpLjxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IDMuIFRU UCBHZW5lcmF0aW9uIC0gVGhlIHJlY2lwaWVudCByZWNlaXZlcyBhc3N1cmFuY2UgdGhhdCBhPEJS PiZndDsgJmd0OyB0cnVzdGVkIHRoaXJkPEJSPiZndDsgJmd0OyBwYXJ0eSAodHJ1c3RlZCBieSB0 aGUgcmVjaXBpZW50KSBoYXMgZ2UgbmVyYXRlZCB0aGU8QlI+Jmd0OyAmZ3Q7IHB1YmxpYy9wcml2 YXRlIGtleTxCUj4mZ3Q7ICZndDsgcGFpciBpbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA1LjYu MSBhbmQgaGFzIHByb3ZpZGVkIHRoZTxCUj4mZ3Q7ICZndDsga2V5IHBhaXIgdG88QlI+Jmd0OyAm Z3Q7IHRoZSBvd25lci48QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyBJdCBzZWVtcyB0byBtZSB0 aGF0IG9wdGlvbiAyIHdhcyBpbmNsdWRlIHRvIGFsbG93IGEgQ0EgdG8gcGVyZm9ybSB0aGU8QlI+ Jmd0OyAmZ3Q7IHB1YmxpYyBrZXkgdmFsaWRhdGlvbiBvbmNlLCBhbmQgdGhlbiBhbnkgcGFydHkg dGhhdCBtYWtlcyB1c2Ugb2YgdGhlPEJSPiZndDsgJmd0OyBjZXJ0aWZpY2F0ZSBuZWVkIG5vdCBk byBpdCBhZ2Fpbi4gRnJvbSBhIHN5c3RlbSBwZXJmb3JtYW5jZTxCUj4mZ3Q7ICZndDsgcGVyc3Bl Y3RpdmUsIHRoaXMgc2VlbXMgaGlnaGx5IGRlc2lyYWJsZS48QlI+Jmd0OyAmZ3Q7PEJSPiZndDsg Jmd0OyBJbiBzb21lIGhpZ2hseSBhc3N1cmVkIGltcGxlbWVudGF0aW9uIGVudmlyb25tZW50cywg aXQgc2VlbXM8QlI+Jmd0OyAmZ3Q7IGRlc2lyYWJsZSBmb3IgdGhlcmUgdG8gbWUgYW4gaW5kaWNh dGlvbiBpbiB0aGUgY2VydGlmaWNhdGUgdGhhdCB0aGlzPEJSPiZndDsgJmd0OyBhY3Rpb24gd2Fz IHRha2VuIGJ5IHRoZSBDQS4gT25lIGNvdWxkIGRldGVybWluZSB3aGljaCBjZXJ0aWZpY2F0aW9u PEJSPiZndDsgJmd0OyBwb2xpY2llcyByZXF1aXJlIHRoZSBDQSB0byB0YWtlIHRoaXMgYWN0aW9u LCBidXQgdGhhdCBtZWFucyB0aGF0IHRoZTxCUj4mZ3Q7ICZndDsgbGlzdCBvZiBjZXJ0aWZpY2F0 aW9uIHBvbGljaWVzIHdvdWxkIGJlIGNvbnRpbnVhbGx5IGFkanVzdGVkIGJ5IGFuPEJSPiZndDsg Jmd0OyBhZG1pbmlzdHJhdG9yLiBJIHdvdWxkIHByZWZlciBhIG5vbi1jcml0aWNhbCBleHRlbnNp b24gdGhhdCBkZWNsYXJlZDxCUj4mZ3Q7ICZndDsgdGhhdCB0aGlzIGFjdGlvbiB3YXMgdGFrZW4g YnkgdGhlIENBLjxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IFRoZSBkcmFmdCBOSVNUIFNQIDgw MC01NiwgU2VjdGlvbiA1LjYuMy4yIGRpc2N1c3NlcyB0aGUgcmVxdWlyZW1lbnQ8QlI+Jmd0OyAm Z3Q7IGZvciAiUmVjaXBpZW50IEFzc3VyYW5jZSBvZiB0aGUgT3duZXIncyBQb3NzZXNzaW9uIG9m IGEgU3RhdGljPEJSPiZndDsgJmd0OyBQcml2YXRlIEtleS4iIFRoYXQgaXMsIHRoZSB0b3BpYyB3 ZSBoYXZlIGJlZW4gZGlzY3Vzc2luZyBmb3IgeWVhcnM8QlI+Jmd0OyAmZ3Q7IG9uIHRoaXMgbGlz dCwgY2FsbGluZyBpdCBwcm9vZiBvZiBwb3NzZXNzaW9uLiBSRkMgMzY0NyBpbmNsdWRlcyBhPEJS PiZndDsgJmd0OyBwbGFjZSBpbiB0aGUgY2VydGlmaWNhdGlvbiBwb2xpY3kgdG8gZGlzY3VzcyB0 aGlzIHRvcGljLiAoUkZDIDM2NDcsPEJSPiZndDsgJmd0OyBTZWN0aW9uIDMuMi4xOiBNZXRob2Qg dG8gcHJvdmUgcG9zc2Vzc2lvbiBvZiBwcml2YXRlIGtleS4pPEJSPiZndDsgJmd0OzxCUj4mZ3Q7 ICZndDsgQWdhaW4sIGluIHNvbWUgaGlnaGx5IGFzc3VyZWQgaW1wbGVtZW50YXRpb24gZW52aXJv bm1lbnRzLCBpdCBzZWVtczxCUj4mZ3Q7ICZndDsgZGVzaXJhYmxlIGZvciB0aGVyZSB0byBtZSBh biBpbmRpY2F0aW9uIGluIHRoZSBjZXJ0aWZpY2F0ZSB0aGF0IHByb29mPEJSPiZndDsgJmd0OyBv ZiBwb3NzZXNzaW9uIHdhcyBwZXJmb3JtZWQgYnkgdGhlIENBLiBJIHRoaW5rIGl0IGNvdWxkIGJl IHBhcnQgb2Y8QlI+Jmd0OyAmZ3Q7IHRoZSBzYW1lIG5vbi1jcml0aWNhbCBleHRlbnNpb24gcHJv cG9zZWQgYWJvdmUuPEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgSSB0aGVyZWZvcmUgcHJvcG9z ZSB0aGF0IHRoZSBQS0lYIFdHIGdlbmVyYXRlIGEgc3RhbmRhcmRzLXRyYWNrIFJGQzxCUj4mZ3Q7 ICZndDsgdG8gZGVmaW5lIGEgY2VydGlmaWNhdGUgZXh0ZW5zaW9uIHRvIHByb3ZpZGUgdGhlc2Ug aW5kaWNhdGlvbnMuIEk8QlI+Jmd0OyAmZ3Q7IHByb3Bvc2UgYSB2ZXJ5IHNpbXBsZSBzeW50YXg6 PEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgaWQtcGUtY2FDaGVja3MgT0JKRUNUIElERU5USUZJ RVIgOjo9IHsgaWQtcGUgJmx0O1RCRCZndDsgfTxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IENB Q2hlY2tzIDo6PSAgICBCSVQgU1RSSU5HIHs8QlI+Jmd0OyAmZ3Q7IHB1YmxpY0tleVZhbGFkYXRp b24gKDApLDxCUj4mZ3Q7ICZndDsgcHJvb2ZPZlBvc3Nlc3Npb24gKDEpIH08QlI+Jmd0OyAmZ3Q7 PEJSPiZndDsgJmd0OyBEbyBvdGhlcnMgdGhpbmsgdGhpcyBpcyBhIHVzZWZ1bCBleHRlbnNpb24/ PEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgUnVzczxCUj4mZ3Q7PEJSPjxCUj48L1A+PC9GT05U Pg== 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 j9QDfQAd051843; Wed, 26 Oct 2005 06:41:26 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QDfQxH051842; Wed, 26 Oct 2005 06:41:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9QDfQgR051832 for ; Wed, 26 Oct 2005 06:41:26 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 18145 invoked by uid 0); 26 Oct 2005 13:41:22 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.171.123) by woodstock.binhost.com with SMTP; 26 Oct 2005 13:41:22 -0000 Message-Id: <7.0.0.10.2.20051026093506.0622e838@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta) Date: Wed, 26 Oct 2005 09:39:08 -0400 To: "Stefan Santesson" , From: Russ Housley Subject: RE: Public key validation and Proof of possession In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stefan: >On public key validation (arithmetic properties): >It seems to me that the key validation tests specified in 5.6.2.4 and >5.6.2.5 are rather trivial to do locally ( 2=for FFC), at least compared to the cost of using this key for anything >useful. I wonder if the cost of making this test isn't actually lower >than parsing the certificate to obtain the assurance from the CA. In low power devices (such as smartcards), avoiding the y^q exponentiation because the relying party is sure that the CA has already performed this check seems useful. >On Proof-of-possession: >Section 5.6.3. of SP 800-56 states: >"For example, this Recommendation requires that parties obtain assurance >that they actually possess their own static private keys, and a binding >authority is required to obtain assurance of an owner's possession of >the appropriate static private key before binding an identifier to the >owner's static public key." > >So since POP always MUST be performed by the CA there seems not to be >the need for diverse policies (POP and non POP). > >Do you agree with these observations or have I missed something? If the first idea is accepted, the proposed extension is no larger by adding the additional bit to indicate that the CA performed POP. The positive statement could be useful. 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 j9QDfRI2051853; Wed, 26 Oct 2005 06:41:27 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QDfRXG051852; Wed, 26 Oct 2005 06:41:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9QDfQ1G051835 for ; Wed, 26 Oct 2005 06:41:26 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 18148 invoked by uid 0); 26 Oct 2005 13:41:23 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.171.123) by woodstock.binhost.com with SMTP; 26 Oct 2005 13:41:23 -0000 Message-Id: <7.0.0.10.2.20051026094029.0623d9f8@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta) Date: Wed, 26 Oct 2005 09:40:58 -0400 To: denis.pinkas@bull.net, "Stefan Santesson" From: Russ Housley Subject: RE: Public key validation and Proof of possession Cc: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis: Are you speaking in support of the extension that I proposed? Russ At 09:11 AM 10/26/2005, denis.pinkas@bull.net wrote: >Russ and Stefan, > >This is an interresting issue. Thanks for raising it. > >(text deleted) > >So since POP always MUST be performed by the CA there seems not to be >the need for diverse policies (POP and non POP). > >Once upon a time, in the early years of PKI, RFC 2459 stated that >sentence that was blindly copied from document to document. > >In these early years, most (if not all) security protocols were >badly designed and thus for them to remains secure >the only way was to include the MUST condition. > >However since then, the earth has rotated and at least there now >exists one case where POP is no more needed without any security threat. > >This case was introduced by S/MIME with the optionally signed >attribute ESSCertID. > >It was then taken by ETSI with the mandatory ESSCetrtID (or iis >equivalent that does not mandate the use of SHA-1). > >RFC 3126 specifies that format. > >Taking into consideration these facts, this means that there exists >at least one case where POP does not need to be performed anymore. > >There still exists cases where it needs to be performed, in >particular when the certificate is used for encryption purposes. > >I believe that POP is mandatory when the key is used for encryption purposes. > >I believe that POP is NOT REQUIRED when the key is used for non >repudiation purposes (e.g. RFC 3126 is used). > >When the key is used for authentication purposes, then depending >upon the characteristics of the protocol, >it MAY be required or not. So in that case only, it would make sense >to support the extension proposed by Russ. > >Denis > >============================================================================= > >Do you agree with these observations or have I missed something? > > >Stefan Santesson >Program Manager, Standards Liaison >Windows Security > > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org >[mailto:owner-ietf-pkix@mail.imc.org] > > On Behalf Of Russ Housley > > Sent: den 25 oktober 2005 23:04 > > To: ietf-pkix@imc.org > > Subject: Public key validation and Proof of possession > > > > > > Dear PKIX WG: > > > > The draft NIST SP 800-56 defines the requirements for "Recipient > > Assurance of Static Public Key Validity." See Section 5.6.2.2, where >it > > says: > > > > The recipient of a static public key shall obtain assurance of its > > validity > > in one or more of the following ways: > > > > 1. Recipient Full Validation - The recipient performs a >successful > > full > > public key validation (see Sections 5.6.2.4 and 5.6.2.5). > > > > 2. TTP Full Validation - The recipient receives assurance that >a > > trusted > > third party (trusted by the recipient) has performed a > > successful full > > public key validation (see Sections 5.6.2.4 and 5.6.2.5). > > > > 3. TTP Generation - The recipient receives assurance that a > > trusted third > > party (trusted by the recipient) has ge nerated the > > public/private key > > pair in accordance with Section 5.6.1 and has provided the > > key pair to > > the owner. > > > > It seems to me that option 2 was include to allow a CA to perform the > > public key validation once, and then any party that makes use of the > > certificate need not do it again. From a system performance > > perspective, this seems highly desirable. > > > > In some highly assured implementation environments, it seems > > desirable for there to me an indication in the certificate that this > > action was taken by the CA. One could determine which certification > > policies require the CA to take this action, but that means that the > > list of certification policies would be continually adjusted by an > > administrator. I would prefer a non-critical extension that declared > > that this action was taken by the CA. > > > > The draft NIST SP 800-56, Section 5.6.3.2 discusses the requirement > > for "Recipient Assurance of the Owner's Possession of a Static > > Private Key." That is, the topic we have been discussing for years > > on this list, calling it proof of possession. RFC 3647 includes a > > place in the certification policy to discuss this topic. (RFC 3647, > > Section 3.2.1: Method to prove possession of private key.) > > > > Again, in some highly assured implementation environments, it seems > > desirable for there to me an indication in the certificate that proof > > of possession was performed by the CA. I think it could be part of > > the same non-critical extension proposed above. > > > > I therefore propose that the PKIX WG generate a standards-track RFC > > to define a certificate extension to provide these indications. I > > propose a very simple syntax: > > > > id-pe-caChecks OBJECT IDENTIFIER ::= { id-pe } > > > > CAChecks ::= BIT STRING { > > publicKeyValadation (0), > > proofOfPossession (1) } > > > > Do others think this is a useful extension? > > > > 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 j9QDdfYo051683; Wed, 26 Oct 2005 06:39:41 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QDdfn7051682; Wed, 26 Oct 2005 06:39:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9QDdf5G051666 for ; Wed, 26 Oct 2005 06:39:41 -0700 (PDT) (envelope-from rtbell@cisco.com) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 26 Oct 2005 06:39:36 -0700 X-IronPort-AV: i="3.97,253,1125903600"; d="scan'208,217"; a="356951658:sNHT42203604" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9QDdXJh013444; Wed, 26 Oct 2005 06:39:33 -0700 (PDT) Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 06:39:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5DA32.A835B7EB" Subject: RE: Public key validation and Proof of possession Date: Wed, 26 Oct 2005 06:39:15 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Public key validation and Proof of possession Thread-Index: AcXaML9LBWr9WeBMSQyEgJjcAEGOhQAAYLpg From: "Bob Bell \(rtbell\)" To: , "Stefan Santesson" Cc: "Russ Housley" , X-OriginalArrivalTime: 26 Oct 2005 13:39:15.0900 (UTC) FILETIME=[A86F17C0:01C5DA32] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C5DA32.A835B7EB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Denis -=20 =20 I have a question. It would seem to me that for non-repudiation as with the other modes for the cert, without the POP step, there is no way to prove that I as the presenter of the Cert am truly entitled to claim that cert as mine. Since a cert is public information, available from multiple sources presumably, then anyone may acquire the cert. It is only by being able to prove that I have the private key through POP am I able to assert that the cert is in fact MY identity. =20 Am I missing something here? =20 Bob Bell ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of denis.pinkas@bull.net Sent: Wednesday, October 26, 2005 07:12 To: Stefan Santesson Cc: Russ Housley; ietf-pkix@imc.org Subject: RE: Public key validation and Proof of possession =09 =09 Russ and Stefan, This is an interresting issue. Thanks for raising it. (text deleted) =09 So since POP always MUST be performed by the CA there seems not to be the need for diverse policies (POP and non POP). =09 Once upon a time, in the early years of PKI, RFC 2459 stated that sentence that was blindly copied from document to document. In these early years, most (if not all) security protocols were badly designed and thus for them to remains secure the only way was to include the MUST condition. However since then, the earth has rotated and at least there now exists one case where POP is no more needed without any security threat. This case was introduced by S/MIME with the optionally signed attribute ESSCertID.=20 It was then taken by ETSI with the mandatory ESSCetrtID (or iis equivalent that does not mandate the use of SHA-1). RFC 3126 specifies that format. Taking into consideration these facts, this means that there exists at least one case where POP does not need to be performed anymore.=20 There still exists cases where it needs to be performed, in particular when the certificate is used for encryption purposes. I believe that POP is mandatory when the key is used for encryption purposes. I believe that POP is NOT REQUIRED when the key is used for non repudiation purposes (e.g. RFC 3126 is used). When the key is used for authentication purposes, then depending upon the characteristics of the protocol, it MAY be required or not. So in that case only, it would make sense to support the extension proposed by Russ. Denis =09 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D Do you agree with these observations or have I missed something? =09 =09 Stefan Santesson Program Manager, Standards Liaison Windows Security =09 =09 > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Russ Housley > Sent: den 25 oktober 2005 23:04 > To: ietf-pkix@imc.org > Subject: Public key validation and Proof of possession >=20 >=20 > Dear PKIX WG: >=20 > The draft NIST SP 800-56 defines the requirements for "Recipient > Assurance of Static Public Key Validity." See Section 5.6.2.2, where it > says: >=20 > The recipient of a static public key shall obtain assurance of its > validity > in one or more of the following ways: >=20 > 1. Recipient Full Validation - The recipient performs a successful > full > public key validation (see Sections 5.6.2.4 and 5.6.2.5). >=20 > 2. TTP Full Validation - The recipient receives assurance that a > trusted > third party (trusted by the recipient) has performed a > successful full > public key validation (see Sections 5.6.2.4 and 5.6.2.5). >=20 > 3. TTP Generation - The recipient receives assurance that a > trusted third > party (trusted by the recipient) has ge nerated the > public/private key > pair in accordance with Section 5.6.1 and has provided the > key pair to > the owner. >=20 > It seems to me that option 2 was include to allow a CA to perform the > public key validation once, and then any party that makes use of the > certificate need not do it again. From a system performance > perspective, this seems highly desirable. >=20 > In some highly assured implementation environments, it seems > desirable for there to me an indication in the certificate that this > action was taken by the CA. One could determine which certification > policies require the CA to take this action, but that means that the > list of certification policies would be continually adjusted by an > administrator. I would prefer a non-critical extension that declared > that this action was taken by the CA. >=20 > The draft NIST SP 800-56, Section 5.6.3.2 discusses the requirement > for "Recipient Assurance of the Owner's Possession of a Static > Private Key." That is, the topic we have been discussing for years > on this list, calling it proof of possession. RFC 3647 includes a > place in the certification policy to discuss this topic. (RFC 3647, > Section 3.2.1: Method to prove possession of private key.) >=20 > Again, in some highly assured implementation environments, it seems > desirable for there to me an indication in the certificate that proof > of possession was performed by the CA. I think it could be part of > the same non-critical extension proposed above. >=20 > I therefore propose that the PKIX WG generate a standards-track RFC > to define a certificate extension to provide these indications. I > propose a very simple syntax: >=20 > id-pe-caChecks OBJECT IDENTIFIER ::=3D { id-pe } >=20 > CAChecks ::=3D BIT STRING { > publicKeyValadation (0), > proofOfPossession (1) } >=20 > Do others think this is a useful extension? >=20 > Russ =09 =09 =09 ------_=_NextPart_001_01C5DA32.A835B7EB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Denis -
 
I have a question. It would seem to me that for = non-repudiation as with the other modes for the cert, without the POP = step,=20 there is no way to prove that I as the presenter of the Cert am truly = entitled=20 to claim that cert as mine. Since a cert is public information, = available from=20 multiple sources presumably, then anyone may acquire the cert. It is = only by=20 being able to prove that I have the private key through POP am I able to = assert=20 that the cert is in fact MY identity.
 
Am I missing something = here?
 
Bob Bell

From: owner-ietf-pkix@mail.imc.org = [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of=20 denis.pinkas@bull.net
Sent: Wednesday, October 26, 2005=20 07:12
To: Stefan Santesson
Cc: Russ Housley;=20 ietf-pkix@imc.org
Subject: RE: Public key validation and = Proof of=20 possession

Russ and Stefan,

This is an interresting issue. Thanks for raising it.

(text deleted)

So since POP always MUST be performed by the = CA there=20 seems not to be
the need for diverse policies (POP and non = POP).

Once upon a time, in the early years of PKI, RFC 2459 stated that = sentence=20 that was blindly copied from document to document.

In these early years, most (if not all) security protocols were = badly=20 designed and thus for them to remains secure
the only way was to = include=20 the MUST condition.

However since then, the earth has rotated and at least there now = exists=20 one case where POP is no more needed without any security = threat.

This case was introduced by S/MIME with the optionally signed = attribute=20 ESSCertID.

It was then taken by ETSI with the mandatory ESSCetrtID (or iis = equivalent=20 that does not mandate the use of SHA-1).

RFC 3126 specifies that format.

Taking into consideration these facts, this means that there exists = at=20 least one case where POP does not need to be performed anymore.

There still exists cases where it needs to be performed, in = particular when=20 the certificate is used for encryption purposes.

I believe that POP is mandatory when the key is used for = encryption=20 purposes.

I believe that POP is NOT REQUIRED when the key is used for non = repudiation=20 purposes (e.g. RFC 3126 is used).

When the key is used for authentication purposes, then depending = upon the=20 characteristics of the protocol,
it MAY be required or not. So in = that case=20 only, it would make sense to support the extension proposed by = Russ.

Denis

=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

Do you agree with these observations or have I missed=20 something?


Stefan Santesson
Program Manager, Standards=20 Liaison
Windows Security


> -----Original = Message-----
>=20 From:=20 = owner-ietf-pkix@mail.imc.org
[mailto:owner-ietf-pkix@mail.imc.org]
= >=20 On Behalf Of Russ Housley
> Sent: den 25 oktober 2005 = 23:04
> To:=20 ietf-pkix@imc.org
> Subject: Public key validation and Proof of=20 possession
>
>
> Dear PKIX WG:
>
> = The draft=20 NIST SP 800-56 defines the requirements for "Recipient
> = Assurance of=20 Static Public Key Validity." See Section 5.6.2.2, where
it
>=20 says:
>
> The recipient of a static public key shall = obtain=20 assurance of its
> validity
> in one or more of the = following=20 ways:
>
> 1. Recipient Full Validation - The recipient = performs=20 a
successful
> full
> public key validation (see = Sections=20 5.6.2.4 and 5.6.2.5).
>
> 2. TTP Full Validation - The = recipient=20 receives assurance that
a
> trusted
> third party = (trusted by=20 the recipient) has performed a
> successful full
> public = key=20 validation (see Sections 5.6.2.4 and 5.6.2.5).
>
> 3. TTP = Generation - The recipient receives assurance that a
> trusted=20 third
> party (trusted by the recipient) has ge nerated = the
>=20 public/private key
> pair in accordance with Section 5.6.1 and = has=20 provided the
> key pair to
> the owner.
>
> = It seems=20 to me that option 2 was include to allow a CA to perform the
> = public=20 key validation once, and then any party that makes use of the
>=20 certificate need not do it again. From a system performance
>=20 perspective, this seems highly desirable.
>
> In some = highly=20 assured implementation environments, it seems
> desirable for = there to=20 me an indication in the certificate that this
> action was taken = by the=20 CA. One could determine which certification
> policies require = the CA to=20 take this action, but that means that the
> list of = certification=20 policies would be continually adjusted by an
> administrator. I = would=20 prefer a non-critical extension that declared
> that this action = was=20 taken by the CA.
>
> The draft NIST SP 800-56, Section = 5.6.3.2=20 discusses the requirement
> for "Recipient Assurance of the = Owner's=20 Possession of a Static
> Private Key." That is, the topic we = have been=20 discussing for years
> on this list, calling it proof of = possession. RFC=20 3647 includes a
> place in the certification policy to discuss = this=20 topic. (RFC 3647,
> Section 3.2.1: Method to prove possession of = private=20 key.)
>
> Again, in some highly assured implementation=20 environments, it seems
> desirable for there to me an indication = in the=20 certificate that proof
> of possession was performed by the CA. = I think=20 it could be part of
> the same non-critical extension proposed=20 above.
>
> I therefore propose that the PKIX WG generate = a=20 standards-track RFC
> to define a certificate extension to = provide these=20 indications. I
> propose a very simple syntax:
>
>=20 id-pe-caChecks OBJECT IDENTIFIER ::=3D { id-pe <TBD> }
> =
>=20 CAChecks ::=3D BIT STRING {
> publicKeyValadation (0),
>=20 proofOfPossession (1) }
>
> Do others think this is a = useful=20 extension?
>
>=20 Russ


------_=_NextPart_001_01C5DA32.A835B7EB-- 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 j9QDBThS048668; Wed, 26 Oct 2005 06:11:29 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QDBTK1048667; Wed, 26 Oct 2005 06:11:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9QDBQJX048650 for ; Wed, 26 Oct 2005 06:11:28 -0700 (PDT) (envelope-from denis.pinkas@bull.net) 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 PAA36000; Wed, 26 Oct 2005 15:28:35 +0200 Importance: Normal X-Priority: 3 (Normal) Subject: RE: Public key validation and Proof of possession MIME-Version: 1.0 From: denis.pinkas@bull.net To: "Stefan Santesson" Cc: "Russ Housley" , Date: Wed, 26 Oct 2005 15:11:54 +0200 Message-ID: X-MIMETrack: Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 26/10/2005 15:11:55 MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: PEZPTlQgZmFjZT0iRGVmYXVsdCBTYW5zIFNlcmlmLCBWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNh LCBzYW5zLXNlcmlmIiBzaXplPTI+PFA+UnVzcyBhbmQgU3RlZmFuLDwvUD48UD5UaGlzIGlzIGFu IGludGVycmVzdGluZyBpc3N1ZS4gVGhhbmtzIGZvciByYWlzaW5nIGl0LjwvUD48UD4odGV4dCBk ZWxldGVkKTxCUj48QlI+U28gc2luY2UgUE9QIGFsd2F5cyBNVVNUIGJlIHBlcmZvcm1lZCBieSB0 aGUgQ0EgdGhlcmUgc2VlbXMgbm90IHRvIGJlPEJSPnRoZSBuZWVkIGZvciBkaXZlcnNlIHBvbGlj aWVzIChQT1AgYW5kIG5vbiBQT1ApLjxCUj48L1A+PFA+T25jZSB1cG9uIGEgdGltZSwgaW4gdGhl IGVhcmx5IHllYXJzIG9mIFBLSSwgUkZDIDI0NTkgc3RhdGVkIHRoYXQgc2VudGVuY2UgdGhhdCB3 YXMgYmxpbmRseSBjb3BpZWQgZnJvbSBkb2N1bWVudCB0byBkb2N1bWVudC48L1A+PFA+SW4gdGhl c2UgZWFybHkgeWVhcnMsIG1vc3QgKGlmIG5vdCBhbGwpIHNlY3VyaXR5IHByb3RvY29scyB3ZXJl IGJhZGx5IGRlc2lnbmVkIGFuZCB0aHVzIGZvciB0aGVtIHRvIHJlbWFpbnMgc2VjdXJlPEJSPnRo ZSBvbmx5IHdheSB3YXMgdG8gaW5jbHVkZSB0aGUgTVVTVCBjb25kaXRpb24uPC9QPjxQPkhvd2V2 ZXIgc2luY2UgdGhlbiwgdGhlIGVhcnRoIGhhcyByb3RhdGVkIGFuZCBhdCBsZWFzdCB0aGVyZSBu b3cgZXhpc3RzIG9uZSZuYnNwO2Nhc2Ugd2hlcmUgUE9QIGlzIG5vIG1vcmUgbmVlZGVkIHdpdGhv dXQgYW55IHNlY3VyaXR5IHRocmVhdC48L1A+PFA+VGhpcyBjYXNlIHdhcyBpbnRyb2R1Y2VkIGJ5 IFMvTUlNRSB3aXRoIHRoZSBvcHRpb25hbGx5IHNpZ25lZCBhdHRyaWJ1dGUgRVNTQ2VydElELiA8 L1A+PFA+SXQgd2FzIHRoZW4gdGFrZW4gYnkgRVRTSSB3aXRoIHRoZSBtYW5kYXRvcnkgRVNTQ2V0 cnRJRCAob3IgaWlzIGVxdWl2YWxlbnQgdGhhdCBkb2VzIG5vdCBtYW5kYXRlIHRoZSB1c2Ugb2Yg U0hBLTEpLjwvUD48UD5SRkMgMzEyNiBzcGVjaWZpZXMgdGhhdCBmb3JtYXQuPC9QPjxQPlRha2lu ZyBpbnRvIGNvbnNpZGVyYXRpb24gdGhlc2UgZmFjdHMsIHRoaXMgbWVhbnMgdGhhdCB0aGVyZSBl eGlzdHMgYXQgbGVhc3Qgb25lIGNhc2Ugd2hlcmUgUE9QIGRvZXMgbm90IG5lZWQgdG8gYmUgcGVy Zm9ybWVkIGFueW1vcmUuIDwvUD48UD5UaGVyZSBzdGlsbCBleGlzdHMgY2FzZXMgd2hlcmUgaXQg bmVlZHMgdG8gYmUgcGVyZm9ybWVkLCBpbiBwYXJ0aWN1bGFyIHdoZW4gdGhlIGNlcnRpZmljYXRl IGlzIHVzZWQgZm9yIGVuY3J5cHRpb24gcHVycG9zZXMuPC9QPjxQPkkmbmJzcDtiZWxpZXZlIHRo YXQgUE9QIGlzIG1hbmRhdG9yeSB3aGVuIHRoZSBrZXkgaXMgdXNlZCBmb3IgZW5jcnlwdGlvbiBw dXJwb3Nlcy48L1A+PFA+SSBiZWxpZXZlIHRoYXQgUE9QIGlzIE5PVCBSRVFVSVJFRCB3aGVuIHRo ZSBrZXkgaXMgdXNlZCBmb3Igbm9uIHJlcHVkaWF0aW9uIHB1cnBvc2VzIChlLmcuIFJGQyAzMTI2 IGlzIHVzZWQpLjwvUD48UD5XaGVuIHRoZSBrZXkgaXMgdXNlZCBmb3IgYXV0aGVudGljYXRpb24g cHVycG9zZXMsIHRoZW4gZGVwZW5kaW5nIHVwb24gdGhlIGNoYXJhY3RlcmlzdGljcyBvZiB0aGUg cHJvdG9jb2wsPEJSPml0IE1BWSBiZSByZXF1aXJlZCBvciBub3QuIFNvIGluIHRoYXQgY2FzZSBv bmx5LCBpdCB3b3VsZCBtYWtlIHNlbnNlIHRvIHN1cHBvcnQgdGhlIGV4dGVuc2lvbiBwcm9wb3Nl ZCBieSBSdXNzLjwvUD48UD5EZW5pczwvUD48UD49PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvUD48UD5E byB5b3UgYWdyZWUgd2l0aCB0aGVzZSBvYnNlcnZhdGlvbnMgb3IgaGF2ZSBJIG1pc3NlZCBzb21l dGhpbmc/PEJSPjxCUj48QlI+U3RlZmFuIFNhbnRlc3NvbjxCUj5Qcm9ncmFtIE1hbmFnZXIsIFN0 YW5kYXJkcyBMaWFpc29uPEJSPldpbmRvd3MgU2VjdXJpdHk8QlI+IDxCUj48QlI+Jmd0OyAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj4mZ3Q7IEZyb206IG93bmVyLWlldGYtcGtpeEBtYWls LmltYy5vcmc8QlI+W21haWx0bzpvd25lci1pZXRmLXBraXhAbWFpbC5pbWMub3JnXTxCUj4mZ3Q7 IE9uIEJlaGFsZiBPZiBSdXNzIEhvdXNsZXk8QlI+Jmd0OyBTZW50OiBkZW4gMjUgb2t0b2JlciAy MDA1IDIzOjA0PEJSPiZndDsgVG86IGlldGYtcGtpeEBpbWMub3JnPEJSPiZndDsgU3ViamVjdDog UHVibGljIGtleSB2YWxpZGF0aW9uIGFuZCBQcm9vZiBvZiBwb3NzZXNzaW9uPEJSPiZndDsgPEJS PiZndDsgPEJSPiZndDsgRGVhciBQS0lYIFdHOjxCUj4mZ3Q7IDxCUj4mZ3Q7IFRoZSBkcmFmdCBO SVNUIFNQIDgwMC01NiBkZWZpbmVzIHRoZSByZXF1aXJlbWVudHMgZm9yICJSZWNpcGllbnQ8QlI+ Jmd0OyBBc3N1cmFuY2Ugb2YgU3RhdGljIFB1YmxpYyBLZXkgVmFsaWRpdHkuIiAgU2VlIFNlY3Rp b24gNS42LjIuMiwgd2hlcmU8QlI+aXQ8QlI+Jmd0OyBzYXlzOjxCUj4mZ3Q7IDxCUj4mZ3Q7ICAg ICBUaGUgcmVjaXBpZW50IG9mIGEgc3RhdGljIHB1YmxpYyBrZXkgc2hhbGwgb2J0YWluIGFzc3Vy YW5jZSBvZiBpdHM8QlI+Jmd0OyB2YWxpZGl0eTxCUj4mZ3Q7ICAgICBpbiBvbmUgb3IgbW9yZSBv ZiB0aGUgZm9sbG93aW5nIHdheXM6PEJSPiZndDsgPEJSPiZndDsgICAgICAgIDEuIFJlY2lwaWVu dCBGdWxsIFZhbGlkYXRpb24gLSBUaGUgcmVjaXBpZW50IHBlcmZvcm1zIGE8QlI+c3VjY2Vzc2Z1 bDxCUj4mZ3Q7IGZ1bGw8QlI+Jmd0OyAgICAgICAgICAgcHVibGljIGtleSB2YWxpZGF0aW9uIChz ZWUgU2VjdGlvbnMgNS42LjIuNCBhbmQgNS42LjIuNSkuPEJSPiZndDsgPEJSPiZndDsgICAgICAg IDIuIFRUUCBGdWxsIFZhbGlkYXRpb24gLSBUaGUgcmVjaXBpZW50IHJlY2VpdmVzIGFzc3VyYW5j ZSB0aGF0PEJSPmE8QlI+Jmd0OyB0cnVzdGVkPEJSPiZndDsgICAgICAgICAgIHRoaXJkIHBhcnR5 ICh0cnVzdGVkIGJ5IHRoZSByZWNpcGllbnQpIGhhcyBwZXJmb3JtZWQgYTxCUj4mZ3Q7IHN1Y2Nl c3NmdWwgZnVsbDxCUj4mZ3Q7ICAgICAgICAgICBwdWJsaWMga2V5IHZhbGlkYXRpb24gKHNlZSBT ZWN0aW9ucyA1LjYuMi40IGFuZCA1LjYuMi41KS48QlI+Jmd0OyA8QlI+Jmd0OyAgICAgICAgMy4g VFRQIEdlbmVyYXRpb24gLSBUaGUgcmVjaXBpZW50IHJlY2VpdmVzIGFzc3VyYW5jZSB0aGF0IGE8 QlI+Jmd0OyB0cnVzdGVkIHRoaXJkPEJSPiZndDsgICAgICAgICAgIHBhcnR5ICh0cnVzdGVkIGJ5 IHRoZSByZWNpcGllbnQpIGhhcyBnZSBuZXJhdGVkIHRoZTxCUj4mZ3Q7IHB1YmxpYy9wcml2YXRl IGtleTxCUj4mZ3Q7ICAgICAgICAgICBwYWlyIGluIGFjY29yZGFuY2Ugd2l0aCBTZWN0aW9uIDUu Ni4xIGFuZCBoYXMgcHJvdmlkZWQgdGhlPEJSPiZndDsga2V5IHBhaXIgdG88QlI+Jmd0OyAgICAg ICAgICAgdGhlIG93bmVyLjxCUj4mZ3Q7IDxCUj4mZ3Q7IEl0IHNlZW1zIHRvIG1lIHRoYXQgb3B0 aW9uIDIgd2FzIGluY2x1ZGUgdG8gYWxsb3cgYSBDQSB0byBwZXJmb3JtIHRoZTxCUj4mZ3Q7IHB1 YmxpYyBrZXkgdmFsaWRhdGlvbiBvbmNlLCBhbmQgdGhlbiBhbnkgcGFydHkgdGhhdCBtYWtlcyB1 c2Ugb2YgdGhlPEJSPiZndDsgY2VydGlmaWNhdGUgbmVlZCBub3QgZG8gaXQgYWdhaW4uICBGcm9t IGEgc3lzdGVtIHBlcmZvcm1hbmNlPEJSPiZndDsgcGVyc3BlY3RpdmUsIHRoaXMgc2VlbXMgaGln aGx5IGRlc2lyYWJsZS48QlI+Jmd0OyA8QlI+Jmd0OyBJbiBzb21lIGhpZ2hseSBhc3N1cmVkIGlt cGxlbWVudGF0aW9uIGVudmlyb25tZW50cywgaXQgc2VlbXM8QlI+Jmd0OyBkZXNpcmFibGUgZm9y IHRoZXJlIHRvIG1lIGFuIGluZGljYXRpb24gaW4gdGhlIGNlcnRpZmljYXRlIHRoYXQgdGhpczxC Uj4mZ3Q7IGFjdGlvbiB3YXMgdGFrZW4gYnkgdGhlIENBLiAgT25lIGNvdWxkIGRldGVybWluZSB3 aGljaCBjZXJ0aWZpY2F0aW9uPEJSPiZndDsgcG9saWNpZXMgcmVxdWlyZSB0aGUgQ0EgdG8gdGFr ZSB0aGlzIGFjdGlvbiwgYnV0IHRoYXQgbWVhbnMgdGhhdCB0aGU8QlI+Jmd0OyBsaXN0IG9mIGNl cnRpZmljYXRpb24gcG9saWNpZXMgd291bGQgYmUgY29udGludWFsbHkgYWRqdXN0ZWQgYnkgYW48 QlI+Jmd0OyBhZG1pbmlzdHJhdG9yLiAgSSB3b3VsZCBwcmVmZXIgYSBub24tY3JpdGljYWwgZXh0 ZW5zaW9uIHRoYXQgZGVjbGFyZWQ8QlI+Jmd0OyB0aGF0IHRoaXMgYWN0aW9uIHdhcyB0YWtlbiBi eSB0aGUgQ0EuPEJSPiZndDsgPEJSPiZndDsgVGhlIGRyYWZ0IE5JU1QgU1AgODAwLTU2LCBTZWN0 aW9uIDUuNi4zLjIgZGlzY3Vzc2VzIHRoZSByZXF1aXJlbWVudDxCUj4mZ3Q7IGZvciAiUmVjaXBp ZW50IEFzc3VyYW5jZSBvZiB0aGUgT3duZXIncyBQb3NzZXNzaW9uIG9mIGEgU3RhdGljPEJSPiZn dDsgUHJpdmF0ZSBLZXkuIiAgVGhhdCBpcywgdGhlIHRvcGljIHdlIGhhdmUgYmVlbiBkaXNjdXNz aW5nIGZvciB5ZWFyczxCUj4mZ3Q7IG9uIHRoaXMgbGlzdCwgY2FsbGluZyBpdCBwcm9vZiBvZiBw b3NzZXNzaW9uLiAgUkZDIDM2NDcgaW5jbHVkZXMgYTxCUj4mZ3Q7IHBsYWNlIGluIHRoZSBjZXJ0 aWZpY2F0aW9uIHBvbGljeSB0byBkaXNjdXNzIHRoaXMgdG9waWMuICAoUkZDIDM2NDcsPEJSPiZn dDsgU2VjdGlvbiAzLjIuMTogTWV0aG9kIHRvIHByb3ZlIHBvc3Nlc3Npb24gb2YgcHJpdmF0ZSBr ZXkuKTxCUj4mZ3Q7IDxCUj4mZ3Q7IEFnYWluLCBpbiBzb21lIGhpZ2hseSBhc3N1cmVkIGltcGxl bWVudGF0aW9uIGVudmlyb25tZW50cywgaXQgc2VlbXM8QlI+Jmd0OyBkZXNpcmFibGUgZm9yIHRo ZXJlIHRvIG1lIGFuIGluZGljYXRpb24gaW4gdGhlIGNlcnRpZmljYXRlIHRoYXQgcHJvb2Y8QlI+ Jmd0OyBvZiBwb3NzZXNzaW9uIHdhcyBwZXJmb3JtZWQgYnkgdGhlIENBLiAgSSB0aGluayBpdCBj b3VsZCBiZSBwYXJ0IG9mPEJSPiZndDsgdGhlIHNhbWUgbm9uLWNyaXRpY2FsIGV4dGVuc2lvbiBw cm9wb3NlZCBhYm92ZS48QlI+Jmd0OyA8QlI+Jmd0OyBJIHRoZXJlZm9yZSBwcm9wb3NlIHRoYXQg dGhlIFBLSVggV0cgZ2VuZXJhdGUgYSBzdGFuZGFyZHMtdHJhY2sgUkZDPEJSPiZndDsgdG8gZGVm aW5lIGEgY2VydGlmaWNhdGUgZXh0ZW5zaW9uIHRvIHByb3ZpZGUgdGhlc2UgaW5kaWNhdGlvbnMu ICBJPEJSPiZndDsgcHJvcG9zZSBhIHZlcnkgc2ltcGxlIHN5bnRheDo8QlI+Jmd0OyA8QlI+Jmd0 OyAgICAgaWQtcGUtY2FDaGVja3MgT0JKRUNUIElERU5USUZJRVIgOjo9ICB7IGlkLXBlICZsdDtU QkQmZ3Q7IH08QlI+Jmd0OyA8QlI+Jmd0OyAgICAgQ0FDaGVja3MgOjo9IEJJVCBTVFJJTkcgezxC Uj4mZ3Q7ICAgICAgICBwdWJsaWNLZXlWYWxhZGF0aW9uICAgICAoMCksPEJSPiZndDsgICAgICAg IHByb29mT2ZQb3NzZXNzaW9uICAgICAgICgxKSB9PEJSPiZndDsgPEJSPiZndDsgRG8gb3RoZXJz IHRoaW5rIHRoaXMgaXMgYSB1c2VmdWwgZXh0ZW5zaW9uPzxCUj4mZ3Q7IDxCUj4mZ3Q7IFJ1c3M8 QlI+PEJSPjxCUj48L1A+PC9GT05UPg== 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 j9QCVJw8045494; Wed, 26 Oct 2005 05:31:19 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QCVJ5R045492; Wed, 26 Oct 2005 05:31:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9QCVIcp045425 for ; Wed, 26 Oct 2005 05:31:18 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Oct 2005 13:31:12 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Public key validation and Proof of possession Date: Wed, 26 Oct 2005 13:30:14 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Public key validation and Proof of possession Thread-Index: AcXZra4Ui3+0TMi3SmWvP9uCPeoMFQAePPSA From: "Stefan Santesson" To: "Russ Housley" , X-OriginalArrivalTime: 26 Oct 2005 12:31:12.0564 (UTC) FILETIME=[26937740:01C5DA29] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j9QCVIcp045487 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, I'm not sure whether this is useful or not. I have some questions though. On public key validation (arithmetic properties): It seems to me that the key validation tests specified in 5.6.2.4 and 5.6.2.5 are rather trivial to do locally ( 2= -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Russ Housley > Sent: den 25 oktober 2005 23:04 > To: ietf-pkix@imc.org > Subject: Public key validation and Proof of possession > > > Dear PKIX WG: > > The draft NIST SP 800-56 defines the requirements for "Recipient > Assurance of Static Public Key Validity." See Section 5.6.2.2, where it > says: > > The recipient of a static public key shall obtain assurance of its > validity > in one or more of the following ways: > > 1. Recipient Full Validation - The recipient performs a successful > full > public key validation (see Sections 5.6.2.4 and 5.6.2.5). > > 2. TTP Full Validation - The recipient receives assurance that a > trusted > third party (trusted by the recipient) has performed a > successful full > public key validation (see Sections 5.6.2.4 and 5.6.2.5). > > 3. TTP Generation - The recipient receives assurance that a > trusted third > party (trusted by the recipient) has ge nerated the > public/private key > pair in accordance with Section 5.6.1 and has provided the > key pair to > the owner. > > It seems to me that option 2 was include to allow a CA to perform the > public key validation once, and then any party that makes use of the > certificate need not do it again. From a system performance > perspective, this seems highly desirable. > > In some highly assured implementation environments, it seems > desirable for there to me an indication in the certificate that this > action was taken by the CA. One could determine which certification > policies require the CA to take this action, but that means that the > list of certification policies would be continually adjusted by an > administrator. I would prefer a non-critical extension that declared > that this action was taken by the CA. > > The draft NIST SP 800-56, Section 5.6.3.2 discusses the requirement > for "Recipient Assurance of the Owner's Possession of a Static > Private Key." That is, the topic we have been discussing for years > on this list, calling it proof of possession. RFC 3647 includes a > place in the certification policy to discuss this topic. (RFC 3647, > Section 3.2.1: Method to prove possession of private key.) > > Again, in some highly assured implementation environments, it seems > desirable for there to me an indication in the certificate that proof > of possession was performed by the CA. I think it could be part of > the same non-critical extension proposed above. > > I therefore propose that the PKIX WG generate a standards-track RFC > to define a certificate extension to provide these indications. I > propose a very simple syntax: > > id-pe-caChecks OBJECT IDENTIFIER ::= { id-pe } > > CAChecks ::= BIT STRING { > publicKeyValadation (0), > proofOfPossession (1) } > > Do others think this is a useful extension? > > 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 j9PL42Eg049221; Tue, 25 Oct 2005 14:04:02 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9PL42Vj049220; Tue, 25 Oct 2005 14:04:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9PL416O049214 for ; Tue, 25 Oct 2005 14:04:01 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 4002 invoked by uid 0); 25 Oct 2005 21:03:52 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.34.180) by woodstock.binhost.com with SMTP; 25 Oct 2005 21:03:52 -0000 Message-Id: <7.0.0.10.2.20051025164030.061cdfb0@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta) Date: Tue, 25 Oct 2005 17:03:55 -0400 To: ietf-pkix@imc.org From: Russ Housley Subject: Public key validation and Proof of possession Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear PKIX WG: The draft NIST SP 800-56 defines the requirements for "Recipient Assurance of Static Public Key Validity." See Section 5.6.2.2, where it says: The recipient of a static public key shall obtain assurance of its validity in one or more of the following ways: 1. Recipient Full Validation - The recipient performs a successful full public key validation (see Sections 5.6.2.4 and 5.6.2.5). 2. TTP Full Validation – The recipient receives assurance that a trusted third party (trusted by the recipient) has performed a successful full public key validation (see Sections 5.6.2.4 and 5.6.2.5). 3. TTP Generation – The recipient receives assurance that a trusted third party (trusted by the recipient) has ge nerated the public/private key pair in accordance with Section 5.6.1 and has provided the key pair to the owner. It seems to me that option 2 was include to allow a CA to perform the public key validation once, and then any party that makes use of the certificate need not do it again. From a system performance perspective, this seems highly desirable. In some highly assured implementation environments, it seems desirable for there to me an indication in the certificate that this action was taken by the CA. One could determine which certification policies require the CA to take this action, but that means that the list of certification policies would be continually adjusted by an administrator. I would prefer a non-critical extension that declared that this action was taken by the CA. The draft NIST SP 800-56, Section 5.6.3.2 discusses the requirement for "Recipient Assurance of the Owner's Possession of a Static Private Key." That is, the topic we have been discussing for years on this list, calling it proof of possession. RFC 3647 includes a place in the certification policy to discuss this topic. (RFC 3647, Section 3.2.1: Method to prove possession of private key.) Again, in some highly assured implementation environments, it seems desirable for there to me an indication in the certificate that proof of possession was performed by the CA. I think it could be part of the same non-critical extension proposed above. I therefore propose that the PKIX WG generate a standards-track RFC to define a certificate extension to provide these indications. I propose a very simple syntax: id-pe-caChecks OBJECT IDENTIFIER ::= { id-pe } CAChecks ::= BIT STRING { publicKeyValadation (0), proofOfPossession (1) } Do others think this is a useful extension? 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 j9PJo3QH042603; Tue, 25 Oct 2005 12:50:03 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9PJo3sK042602; Tue, 25 Oct 2005 12:50:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9PJo2o7042578 for ; Tue, 25 Oct 2005 12:50:03 -0700 (PDT) (envelope-from mlee@newodin.ietf.org) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EUUo5-0007jT-OJ; Tue, 25 Oct 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-cmc-compl-02.txt Message-Id: Date: Tue, 25 Oct 2005 15:50:01 -0400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : CMC Complience Document Author(s) : M. Myers, J. Schaad Filename : draft-ietf-pkix-cmc-compl-02.txt Pages : 16 Date : 2005-10-25 This document provides a set of compliance statements about the CMC (Certificate Management over CMS) enrollment protocol. The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents. This document provides the information needed to make a compliant version of CMC A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmc-compl-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-cmc-compl-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-cmc-compl-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-25131726.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-cmc-compl-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-cmc-compl-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-25131726.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9PJo2gD042594; Tue, 25 Oct 2005 12:50:02 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9PJo2OW042592; Tue, 25 Oct 2005 12:50:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9PJo1lN042576 for ; Tue, 25 Oct 2005 12:50:02 -0700 (PDT) (envelope-from mlee@newodin.ietf.org) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EUUo5-0007iV-DQ; Tue, 25 Oct 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-scvp-21.txt Message-Id: Date: Tue, 25 Oct 2005 15:50:01 -0400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Standard Certificate Validation Protocol (SCVP) Author(s) : A. Malpani, et al. Filename : draft-ietf-pkix-scvp-21.txt Pages : 78 Date : 2005-10-25 SCVP allows a client to delegate certificate path construction and certificate path validation to a server. The path construction or validation (e.g. making sure that none of the certificates in the path are revoked) is performed according to a validation policy, which contains one or more trust anchors. It allows simplification of client implementations and use of a set of predefined validation policies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-21.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-scvp-21.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-scvp-21.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-25110437.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-scvp-21.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-scvp-21.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-25110437.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9PJo2qG042593; Tue, 25 Oct 2005 12:50:02 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9PJo2jg042588; Tue, 25 Oct 2005 12:50:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9PJo1qU042577 for ; Tue, 25 Oct 2005 12:50:02 -0700 (PDT) (envelope-from mlee@newodin.ietf.org) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EUUo5-0007jJ-MU; Tue, 25 Oct 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-2797-bis-03.txt Message-Id: Date: Tue, 25 Oct 2005 15:50:01 -0400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Certificate Management Messages over CMS Author(s) : M. Myers, J. Schaad Filename : draft-ietf-pkix-2797-bis-03.txt Pages : 75 Date : 2005-10-25 This document defines the base syntax for CMC, a Certificate Management protocol using CMS (Cryptographic Message Syntax). This protocol addresses two immediate needs within the Internet PKI community: 1. The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key Crytpography Standard), and 2. The need in S/MIME (Secure MIME) for a certificate enrollment protocol for DSA-signed certificates with Diffie-Hellman public keys. CMC also requires the use of the transport document and the requirements usage document along with this document for a full definition. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-2797-bis-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-2797-bis-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-2797-bis-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-25131158.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-2797-bis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-2797-bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-25131158.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9PFqtEi017962; Tue, 25 Oct 2005 08:52:55 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9PFqtL4017961; Tue, 25 Oct 2005 08:52:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9PFqsHw017944 for ; Tue, 25 Oct 2005 08:52:54 -0700 (PDT) (envelope-from kent@bbn.com) 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 j9PFqjIC015042 for ; Tue, 25 Oct 2005 11:52:46 -0400 (EDT) Mime-Version: 1.0 Message-Id: Date: Tue, 25 Oct 2005 11:52:47 -0400 To: ietf-pkix@imc.org From: Stephen Kent Subject: agenda 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: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks, Based on requests I have received, a preliminary PKIX WG Agenda has been posted at the IETF web site: http://www3.ietf.org/proceedings/05nov/agenda/pkix.htm Please contact me with any requested changes. 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 j9LGKsAW030109; Fri, 21 Oct 2005 09:20:54 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9LGKsS4030108; Fri, 21 Oct 2005 09:20:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from whisky.linagora.com (whisky.linagora.com [62.23.27.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9LGKqUG030079 for ; Fri, 21 Oct 2005 09:20:52 -0700 (PDT) (envelope-from yquenechdu@linagora.com) Received: from localhost (localhost [127.0.0.1]) by whisky.linagora.com (Postfix) with ESMTP id 2CD7E1CF004; Fri, 21 Oct 2005 16:20:50 +0000 (UTC) Received: from whisky.linagora.com ([127.0.0.1]) by localhost (whisky [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19383-10; Fri, 21 Oct 2005 18:20:43 +0200 (CEST) Received: from tomate.linagora.lan (sgi2.linagora.com [195.68.36.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by whisky.linagora.com (Postfix) with ESMTP id 2A3B21DADC8; Fri, 21 Oct 2005 18:20:41 +0200 (CEST) Received: from 192.168.1.254 (proxying for 145.242.3.30) (SquirrelMail authenticated user yquenechdu@linagora.com) by tomate.linagora.lan with HTTP; Fri, 21 Oct 2005 18:20:48 +0200 (CEST) Message-ID: <32866.192.168.1.254.1129911648.squirrel@tomate.linagora.lan> In-Reply-To: <6.2.1.2.2.20051021103341.04bd69e0@mail.binhost.com> References: <60478.192.168.1.254.1129812606.squirrel@tomate.linagora.lan> <6.2.1.2.2.20051021103341.04bd69e0@mail.binhost.com> Date: Fri, 21 Oct 2005 18:20:48 +0200 (CEST) Subject: Re: Little question about CRL From: yquenechdu@linagora.com To: "Russ Housley" Cc: yquenechdu@linagora.com, ietf-pkix@imc.org User-Agent: SquirrelMail/1.4.5 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at linagora.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, I had understood that. What I seek to understand it is the goal to have indicated the field signature in the LCR. Thanks Yannick Quenec'hdu. > This same structure is used for the X.509 certificate itself. One of the > values is covered by the signature, and the other is not. > > Russ > > At 08:50 AM 10/20/2005, yquenechdu@linagora.com wrote: > >>Hi, >> >>Why a LCR contains two fields identical, a field signatureAlgorithm for >>CertificatList and another field signature for TBSList >> >>Knowing that "This field MUST contain the same algorithm to identify ace >> the >>signature field in the sequence tbsCertList" >> >>Thank you for your answers >>Yannick Quenec'hdu > > > 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 j9LFu8bL026012; Fri, 21 Oct 2005 08:56:08 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9LFu89T026011; Fri, 21 Oct 2005 08:56:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9LFu7uA026002 for ; Fri, 21 Oct 2005 08:56:07 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 13320 invoked by uid 0); 21 Oct 2005 15:56:01 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.34.88) by woodstock.binhost.com with SMTP; 21 Oct 2005 15:56:01 -0000 Message-Id: <6.2.1.2.2.20051021103341.04bd69e0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 21 Oct 2005 10:34:31 -0400 To: yquenechdu@linagora.com From: Russ Housley Subject: Re: Little question about CRL Cc: ietf-pkix@imc.org In-Reply-To: <60478.192.168.1.254.1129812606.squirrel@tomate.linagora.la n> References: <60478.192.168.1.254.1129812606.squirrel@tomate.linagora.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This same structure is used for the X.509 certificate itself. One of the values is covered by the signature, and the other is not. Russ At 08:50 AM 10/20/2005, yquenechdu@linagora.com wrote: >Hi, > >Why a LCR contains two fields identical, a field signatureAlgorithm for >CertificatList and another field signature for TBSList > >Knowing that "This field MUST contain the same algorithm to identify ace the >signature field in the sequence tbsCertList" > >Thank you for your answers >Yannick Quenec'hdu 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 j9LEnIoo014687; Fri, 21 Oct 2005 07:49:18 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9LEnI6D014685; Fri, 21 Oct 2005 07:49:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9LEnEis014655 for ; Fri, 21 Oct 2005 07:49:14 -0700 (PDT) (envelope-from david.cooper@nist.gov) 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 j9LEmuBT025312; Fri, 21 Oct 2005 10:48:57 -0400 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 j9LEmfG3015833; Fri, 21 Oct 2005 10:48:43 -0400 (EDT) Message-ID: <4358FFCE.4080907@nist.gov> Date: Fri, 21 Oct 2005 10:48:46 -0400 From: "David A. Cooper" 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: Peter Sylvester CC: denis.pinkas@bull.net, ietf-pkix@imc.org Subject: Re: SCVP editors' draft References: <4357D80F.80105@edelweb.fr> In-Reply-To: <4357D80F.80105@edelweb.fr> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: For an SCVP server that does not perform relaying, the server MUST process the requestorRef value if it is present in the request, but the processing requirements are very simple. From section 4.7: If the SCVP client includes a requestorRef value in the request, then the SCVP server MUST return the same value if the server is generating a non-cached response. Section 7 imposes further requirements for the processing of the requestorRef item but, as the first paragraph of section 7 explicitly states, these further processing requirements only apply to servers that implement relay. Dave Peter Sylvester wrote: >> A point related to a topic that interests Peter. In section 3.3 the >> text states: >> >> “Conforming SCVP server implementations MUST process the requestorRef >> >> value if present”. >> >> This is incorrect, since it is only a requirement if the SCVP server >> is performing relaying. >> > Good question, here is one thought. > > It could occur that a server was erroneously presented with a reference > that carries its own id. If this came from another server that relayed > to it, > the final response may have two authentication envelopes with identical > identifiers. Or, the responder field of this response would be the same > as the one that will further down encapsulate it. > > C -> A(1) -> B -> A(2) > > B receives response from A2, ancapsulates or relays it to A1, and A1 > includes this in its respones to C. > > If I have to keep this structure for some long term, I might have > problems to explain the difference between A1 and A2. > > I don't know whether this really presents a problem. > > maybe someone on the pkix list has an opinion, I'll CC 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 j9KHl5Zg039176; Thu, 20 Oct 2005 10:47:05 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9KHl5Cs039175; Thu, 20 Oct 2005 10:47:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9KHl2dI039168 for ; Thu, 20 Oct 2005 10:47:03 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from champagne.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j9KHl0i23433; Thu, 20 Oct 2005 19:47:00 +0200 (MEST) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/2.4); Thu, 20 Oct 2005 19:47:01 +0200 (MET DST) 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 TAA27768; Thu, 20 Oct 2005 19:46:55 +0200 (MET DST) Message-ID: <4357D80F.80105@edelweb.fr> Date: Thu, 20 Oct 2005 19:46:55 +0200 From: Peter Sylvester User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: denis.pinkas@bull.net CC: Tim Polk , hartmans-ietf@mit.edu, dengberg@corestreet.com, shitchings@corestreet.com, john.hines@tumbleweed.com, mmyers@fastq.com, david.cooper@nist.gov, housley@vigilsec.com, trevorf@microsoft.com, ambarish@malpani.biz, ietf-pkix@imc.org Subject: Re: SCVP editors' draft References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040607080909030404090701" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040607080909030404090701 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit > A point related to a topic that interests Peter. In section 3.3 the > text states: > > “Conforming SCVP server implementations MUST process the requestorRef > > value if present”. > > This is incorrect, since it is only a requirement if the SCVP server > is performing relaying. > Good question, here is one thought. It could occur that a server was erroneously presented with a reference that carries its own id. If this came from another server that relayed to it, the final response may have two authentication envelopes with identical identifiers. Or, the responder field of this response would be the same as the one that will further down encapsulate it. C -> A(1) -> B -> A(2) B receives response from A2, ancapsulates or relays it to A1, and A1 includes this in its respones to C. If I have to keep this structure for some long term, I might have problems to explain the difference between A1 and A2. I don't know whether this really presents a problem. maybe someone on the pkix list has an opinion, I'll CC it. -- 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. --------------ms040607080909030404090701 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 MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMDIwMTc0NjU1WjAjBgkqhkiG9w0B CQQxFgQUdQi0mozNdG9K+u2EBhk+GEDE7FAwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGA1HQMimZgT0Cg2zUX ZIEhYfaW1wlg3u88d4dfxepdFk6bbNAF9yqbbA4V3Ame6tGl2xOmJgQNkjM8Gg0n8BP9N0Tb 6GLzYpIBJUb0fuLeqQdhB89s9t1RM3CFu02f+lwfYW4ZS8sGqMqNI1c5+O2TTBv+vzcff5M2 n0HkJd8eSu0AAAAAAAA= --------------ms040607080909030404090701-- 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 j9KCoBdP008066; Thu, 20 Oct 2005 05:50:11 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9KCoBUG008065; Thu, 20 Oct 2005 05:50:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from whisky.linagora.com (whisky.linagora.com [62.23.27.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9KCo9nQ008057 for ; Thu, 20 Oct 2005 05:50:10 -0700 (PDT) (envelope-from yquenechdu@linagora.com) Received: from localhost (localhost [127.0.0.1]) by whisky.linagora.com (Postfix) with ESMTP id 733C21D737B for ; Thu, 20 Oct 2005 12:50:07 +0000 (UTC) Received: from whisky.linagora.com ([127.0.0.1]) by localhost (whisky [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05768-04 for ; Thu, 20 Oct 2005 14:50:00 +0200 (CEST) Received: from tomate.linagora.lan (sgi2.linagora.com [195.68.36.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by whisky.linagora.com (Postfix) with ESMTP id 43A111D7499 for ; Thu, 20 Oct 2005 14:50:00 +0200 (CEST) Received: from 192.168.1.254 (proxying for 145.242.3.30) (SquirrelMail authenticated user yquenechdu@linagora.com) by tomate.linagora.lan with HTTP; Thu, 20 Oct 2005 14:50:06 +0200 (CEST) Message-ID: <60478.192.168.1.254.1129812606.squirrel@tomate.linagora.lan> Date: Thu, 20 Oct 2005 14:50:06 +0200 (CEST) Subject: Little question about CRL From: yquenechdu@linagora.com To: ietf-pkix@imc.org User-Agent: SquirrelMail/1.4.5 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at linagora.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, Why a LCR contains two fields identical, a field signatureAlgorithm for CertificatList and another field signature for TBSList Knowing that "This field MUST contain the same algorithm to identify ace the signature field in the sequence tbsCertList" Thank you for your answers Yannick Quenec'hdu 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 j9IG7V4f091273; Tue, 18 Oct 2005 09:07:31 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9IG7VwE091272; Tue, 18 Oct 2005 09:07:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9IG7UQV091261 for ; Tue, 18 Oct 2005 09:07:31 -0700 (PDT) (envelope-from kent@bbn.com) 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 j9IG7NIE022863 for ; Tue, 18 Oct 2005 12:07:24 -0400 (EDT) Mime-Version: 1.0 Message-Id: Date: Tue, 18 Oct 2005 12:07:25 -0400 To: ietf-pkix@imc.org From: Stephen Kent Subject: agenda items 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: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks, Please send Tim and me you requests for agenda slots this week. We will be using a new tool to post the agenda directly, as opposed to the old method that involved the IETF Secretariat as an intermediary. This should yield faster turnaround, and allow us to make changes incrementally. 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 j9HJPgoV059682; Mon, 17 Oct 2005 12:25:42 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9HJPg2w059681; Mon, 17 Oct 2005 12:25:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9HJPfoW059675 for ; Mon, 17 Oct 2005 12:25:42 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 18155 invoked by uid 0); 17 Oct 2005 19:25:35 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (84.233.132.123) by woodstock.binhost.com with SMTP; 17 Oct 2005 19:25:35 -0000 Message-Id: <6.2.1.2.2.20051017152017.04f32780@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 17 Oct 2005 15:21:31 -0400 To: ietf-pkix@imc.org From: Russ Housley Subject: draft-adams-cmpaltcert-07.txt published as RFC 4212 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I thought the PKIX WG would like to know that draft-adams-cmpaltcert-07.txt was published as RFC 4212. 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 j9GK8Fcl086064; Sun, 16 Oct 2005 13:08:15 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9GK8FZx086063; Sun, 16 Oct 2005 13:08:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9GK8B3O086031 for ; Sun, 16 Oct 2005 13:08:12 -0700 (PDT) (envelope-from tgindin@us.ibm.com) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j9GK8250021928 for ; Sun, 16 Oct 2005 16:08:02 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j9GK820w108072 for ; Sun, 16 Oct 2005 16:08:02 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j9GK82fF002204 for ; Sun, 16 Oct 2005 16:08:02 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j9GK82iP002199; Sun, 16 Oct 2005 16:08:02 -0400 In-Reply-To: To: Simon Josefsson Cc: Russ Housley , ietf-pkix@imc.org MIME-Version: 1.0 Subject: Re: Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08) X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Tom Gindin Message-ID: Date: Sun, 16 Oct 2005 16:08:00 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.5.4FP1 HF2|August 30, 2005) at 10/16/2005 16:08:01, Serialize complete at 10/16/2005 16:08:01 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Simon: Given the way that distribution points work, I don't understand the point of using IPKIX for CRL's with distribution points. Shouldn't the distribution point contain the URL anyway, and if so what good is the extra DNS step? I guess it might be useful for some non-distribution point CRL's (mainly those with issuer alternate names), but for distribution point CRL's it gains a little flexibility at the cost of both security and performance. I must defer to other members of the PKIX WG as to how frequently a CRL has an issuer alternate name without any distribution points, as I myself have no recollection of ever seeing such a CRL. My original reason for commenting was that 2538-bis has owner name rules for certificates, but not for CRL's, while section 2.3 lists both CRL's and certificates as permitted OID's which are apparently intended for the PKIX type. CRL rules would seem to be less application-specific than TLS or S/MIME, and thus more appropriately found in 2538-bis or 3280-bis than anywhere else. You have adopted the three application-specific guidelines from draft-josefsson-pkix-dns-00.txt in 2538-bis, even though I don't see why any SSL or TLS client would use the DNS to fetch a server certificate when it's exchanged within the protocol anyway. IMHO S/MIME certificates in the DNS are more likely to be useful. On a lower level, the binary coding in 2.3 makes little sense. Either it's 06 03 55 04 nn, or it's just 55 04 nn - in either case a leading x makes sense, but not in front of the length. Tom Gindin Simon Josefsson 10/14/2005 08:34 AM To: Tom Gindin/Watson/IBM@IBMUS cc: Russ Housley , ietf-pkix@imc.org Subject: Re: Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08) Tom Gindin writes: > Russ: > > In the current 2538-bis draft, section 2 contains OID's for both > certificates and CRL's (although not AC's), while section 3 profiles owner > names for certificates and not for CRL's. Does this really make sense, > especially given that there doesn't seem to be any place where owner names > for CRL's are profiled? If CERT RR are to be used by PKIX, I believe you would need an PKIX Operational Protocols for DNS, such as: http://josefsson.org/rfc2538bis/draft-josefsson-pkix-dns-00.txt That document should mandate exact owner name rules used for particular applications, and could describe how CRLs stored in DNS would be used. I don't think that kind of detail should go into RFC 2538bis. Your concerns would be applicable to that document. > Also, I think we all realize that most current certificates don't > fit in 512 bytes, and if the size of standard RSA keys increases the > certificates will grow more since every certificate contains both a > subject public key and a signature whose size is no smaller than the CA's > key. CRL's actually fit better (a sample one I have with a 1024-bit key > has a size of about 350 bytes + 37 bytes for each entry, changing to 39 > for revocation times after 2000), but they have to be distribution point > CRL's and they have to be quite small. If Phill's point about MTU size is > relevant, a CRL with more than about 30 entries revoked won't fit into > that window - and that doesn't guarantee that 30 will. The document address this problem through the IPKIX type. Thanks, Simon > Tom Gindin > > > > > > > Russ Housley > 10/13/2005 11:30 AM > > To: Tom Gindin/Watson/IBM@IBMUS > cc: ietf-pkix@imc.org, simon@josefsson.org > Subject: Re: Storing Certificates in the DNS > (draft-ietf-dnsext-rfc2538bis-08) > > > Tom: > > Thanks for the review. I do not think that this kind of guidance belongs > in draft-ietf-dnsext-rfc2538bis, but it does belong in 3280bis. > > Russ > > > At 06:38 PM 10/12/2005, Tom Gindin wrote: > >> Russ: >> >> Are there any guidelines for CRL owner names, since they're >>covered in the draft although DNS distribution points aren't detailed in >>RFC 3280? If there aren't any, IMHO a reasonable rule would be that if >>any sequence member of the distribution point name is a domain name (not > a >>URI), that should be used. Also (and lower in precedence), if any >>sequence member of the distribution point name is an RFC 822 address, its >>standard translation should be used. I doubt if URI's will work without >>conflicts. >> I don't know if these count as "concerns". >> >> Tom Gindin >>P.S. The opinions above are mine, and not necessarily those of my >>employer. 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 j9ELLWdE044061; Fri, 14 Oct 2005 14:21:32 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9ELLWrr044059; Fri, 14 Oct 2005 14:21:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9ELLVVJ044052 for ; Fri, 14 Oct 2005 14:21:32 -0700 (PDT) (envelope-from apache@newodin.ietf.org) Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EQWzb-0001ff-0B; Fri, 14 Oct 2005 17:21:31 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Subject: Last Call: 'Attribute Certificate Policies extension' to Proposed Standard Reply-to: iesg@ietf.org CC: Message-Id: Date: Fri, 14 Oct 2005 17:21:31 -0400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the Public-Key Infrastructure (X.509) WG to consider the following document: - 'Attribute Certificate Policies extension ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-10-28. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pkix-acpolicies-extn-06.txt 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 j9ECYWhf067151; Fri, 14 Oct 2005 05:34:32 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9ECYW3Z067150; Fri, 14 Oct 2005 05:34:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from yxa.extundo.com (root@178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9ECYSRR067116 for ; Fri, 14 Oct 2005 05:34:31 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j9ECYO7L002878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Oct 2005 14:34:25 +0200 From: Simon Josefsson To: Tom Gindin Cc: Russ Housley , ietf-pkix@imc.org Subject: Re: Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08) References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051014:tgindin@us.ibm.com::L+MFvcadOUkL4Y6c:16zJ X-Hashcash: 1:21:051014:housley@vigilsec.com::elVOWjJv2j7GeGwH:1HnE X-Hashcash: 1:21:051014:ietf-pkix@imc.org::Sz8rYUEwAto4tW1G:J3NK Date: Fri, 14 Oct 2005 14:34:23 +0200 In-Reply-To: (Tom Gindin's message of "Fri, 14 Oct 2005 07:50:52 -0400") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=1.2 required=5.0 tests=FORGED_RCVD_HELO, SUBJ_HAS_UNIQ_ID autolearn=no version=3.0.3 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yxa-iv X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tom Gindin writes: > Russ: > > In the current 2538-bis draft, section 2 contains OID's for both > certificates and CRL's (although not AC's), while section 3 profiles owner > names for certificates and not for CRL's. Does this really make sense, > especially given that there doesn't seem to be any place where owner names > for CRL's are profiled? If CERT RR are to be used by PKIX, I believe you would need an PKIX Operational Protocols for DNS, such as: http://josefsson.org/rfc2538bis/draft-josefsson-pkix-dns-00.txt That document should mandate exact owner name rules used for particular applications, and could describe how CRLs stored in DNS would be used. I don't think that kind of detail should go into RFC 2538bis. Your concerns would be applicable to that document. > Also, I think we all realize that most current certificates don't > fit in 512 bytes, and if the size of standard RSA keys increases the > certificates will grow more since every certificate contains both a > subject public key and a signature whose size is no smaller than the CA's > key. CRL's actually fit better (a sample one I have with a 1024-bit key > has a size of about 350 bytes + 37 bytes for each entry, changing to 39 > for revocation times after 2000), but they have to be distribution point > CRL's and they have to be quite small. If Phill's point about MTU size is > relevant, a CRL with more than about 30 entries revoked won't fit into > that window - and that doesn't guarantee that 30 will. The document address this problem through the IPKIX type. Thanks, Simon > Tom Gindin > > > > > > > Russ Housley > 10/13/2005 11:30 AM > > To: Tom Gindin/Watson/IBM@IBMUS > cc: ietf-pkix@imc.org, simon@josefsson.org > Subject: Re: Storing Certificates in the DNS > (draft-ietf-dnsext-rfc2538bis-08) > > > Tom: > > Thanks for the review. I do not think that this kind of guidance belongs > in draft-ietf-dnsext-rfc2538bis, but it does belong in 3280bis. > > Russ > > > At 06:38 PM 10/12/2005, Tom Gindin wrote: > >> Russ: >> >> Are there any guidelines for CRL owner names, since they're >>covered in the draft although DNS distribution points aren't detailed in >>RFC 3280? If there aren't any, IMHO a reasonable rule would be that if >>any sequence member of the distribution point name is a domain name (not > a >>URI), that should be used. Also (and lower in precedence), if any >>sequence member of the distribution point name is an RFC 822 address, its >>standard translation should be used. I doubt if URI's will work without >>conflicts. >> I don't know if these count as "concerns". >> >> Tom Gindin >>P.S. The opinions above are mine, and not necessarily those of my >>employer. 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 j9EBp7bt055662; Fri, 14 Oct 2005 04:51:07 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9EBp7h9055661; Fri, 14 Oct 2005 04:51:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9EBp4L0055612 for ; Fri, 14 Oct 2005 04:51:04 -0700 (PDT) (envelope-from tgindin@us.ibm.com) 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 j9EBoswV025411 for ; Fri, 14 Oct 2005 07:50:54 -0400 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 j9EBosDn109788 for ; Fri, 14 Oct 2005 07:50:54 -0400 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 j9EBosDh019145 for ; Fri, 14 Oct 2005 07:50:54 -0400 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 j9EBosXQ019141; Fri, 14 Oct 2005 07:50:54 -0400 In-Reply-To: <6.2.1.2.2.20051013112936.05c48280@mail.binhost.com> To: Russ Housley Cc: ietf-pkix@imc.org, simon@josefsson.org MIME-Version: 1.0 Subject: Re: Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08) X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Tom Gindin Message-ID: Date: Fri, 14 Oct 2005 07:50:52 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 10/14/2005 07:50:52, Serialize complete at 10/14/2005 07:50:52 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ: In the current 2538-bis draft, section 2 contains OID's for both certificates and CRL's (although not AC's), while section 3 profiles owner names for certificates and not for CRL's. Does this really make sense, especially given that there doesn't seem to be any place where owner names for CRL's are profiled? Also, I think we all realize that most current certificates don't fit in 512 bytes, and if the size of standard RSA keys increases the certificates will grow more since every certificate contains both a subject public key and a signature whose size is no smaller than the CA's key. CRL's actually fit better (a sample one I have with a 1024-bit key has a size of about 350 bytes + 37 bytes for each entry, changing to 39 for revocation times after 2000), but they have to be distribution point CRL's and they have to be quite small. If Phill's point about MTU size is relevant, a CRL with more than about 30 entries revoked won't fit into that window - and that doesn't guarantee that 30 will. Tom Gindin Russ Housley 10/13/2005 11:30 AM To: Tom Gindin/Watson/IBM@IBMUS cc: ietf-pkix@imc.org, simon@josefsson.org Subject: Re: Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08) Tom: Thanks for the review. I do not think that this kind of guidance belongs in draft-ietf-dnsext-rfc2538bis, but it does belong in 3280bis. Russ At 06:38 PM 10/12/2005, Tom Gindin wrote: > Russ: > > Are there any guidelines for CRL owner names, since they're >covered in the draft although DNS distribution points aren't detailed in >RFC 3280? If there aren't any, IMHO a reasonable rule would be that if >any sequence member of the distribution point name is a domain name (not a >URI), that should be used. Also (and lower in precedence), if any >sequence member of the distribution point name is an RFC 822 address, its >standard translation should be used. I doubt if URI's will work without >conflicts. > I don't know if these count as "concerns". > > Tom Gindin >P.S. The opinions above are mine, and not necessarily those of my >employer. 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 j9DGmerv042636; Thu, 13 Oct 2005 09:48:40 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9DGmeui042618; Thu, 13 Oct 2005 09:48:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9DGmbhI042608; Thu, 13 Oct 2005 09:48:38 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <101320051443.13707.434E72990005C3C50000358B2160281060970A9C9C0E0409D20B0B 019B@att.net> References: <101320051443.13707.434E72990005C3C50000358B2160281060970A9C9C0E0409D20B0B 019B@att.net> Date: Thu, 13 Oct 2005 09:48:35 -0700 To: todd.glassey@att.net From: Paul Hoffman Subject: RE: Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08) Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 2:43 PM +0000 10/13/05, todd.glassey@att.net wrote: >phb - NO ONE in their right mind would use DNS as the only >repository for storing certificates and this initiative and the >conversations in re of this idea are demonstrative of how little >PKIX has a grip on reality IMHO. Clearly storing certs for DNS in >DNS and possibly in some limited scope might work, but the reality >is why bother - the issue is in the trust and use models - something >which this group refuses to do... Reading the subject line of this thread shows that this effort comes from the DNSEXT WG, not this one. --Paul Hoffman, Director --VPN Consortium 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 j9DGG0UG032409; Thu, 13 Oct 2005 09:16:00 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9DGG08t032405; Thu, 13 Oct 2005 09:16:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9DGFx1G032379 for ; Thu, 13 Oct 2005 09:15:59 -0700 (PDT) (envelope-from todd.glassey@att.net) Received: from 204.127.135.58 ([204.127.135.58]) by worldnet.att.net (mtiwmhc11) with SMTP id <2005101316155311100n8tbae>; Thu, 13 Oct 2005 16:15:53 +0000 Received: from [64.127.102.91] by 204.127.135.58; Thu, 13 Oct 2005 16:15:51 +0000 From: todd.glassey@att.net To: Russ Housley Cc: ietf-pkix@imc.org, simon@josefsson.org Subject: RE: Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08) Date: Thu, 13 Oct 2005 16:15:51 +0000 Message-Id: <101320051615.20035.434E88370005122800004E432160281060970A9C9C0E0409D20B0B019B@att.net> X-Mailer: AT&T Message Center Version 1 (Feb 14 2005) X-Authenticated-Sender: dG9kZC5nbGFzc2V5QGF0dC5uZXQ= Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Yes Russ it is - there is so little difference between these WG's and their products, that its almost silly. Any use through the IETF of one groups' standards needs to be codified under the 'no repeating work or work related to another standard effort' rule that the IETF's bylaws clearly define. So - what can I say - this is yet another instance where someone wants to enable an enduser use model without bothering to actually document how that end-use model will work and under what constraints it will work - as to the separation issues between the WG's - when there were no standards, and there were no processes already in place - the IETF's shotgun approach was possibly warranted - but not anymore. And since this will likely really tee you off as a response, its my final one on the subject except to say that for some uses there are really good justifications for looking up certs through DNS services - just like there is with the e.64 phone numbers in DNS. Its just that DNS as a whole is not what it could be and well - what can I say. todd -------------- Original message ---------------------- From: Russ Housley > Todd: > > This is not a PKIX work product, so you comments are directed at the wrong > audience. > > Russ > > At 10:43 AM 10/13/2005, todd.glassey@att.net wrote: > >phb - NO ONE in their right mind would use DNS as the only repository for > >storing certificates and this initiative and the conversations in re of > >this idea are demonstrative of how little PKIX has a grip on reality IMHO. > >Clearly storing certs for DNS in DNS and possibly in some limited scope > >might work, but the reality is why bother - the issue is in the trust and > >use models - something which this group refuses to do... > > > >T. > > -------------- Original message ---------------------- > >From: "Hallam-Baker, Phillip" > > > > > > While storing certificates in the DNS makes sense in some applications I > > > would be concerned if this proposal was intended to make DNS the > > > recommended storage mechanism. > > > > > > The problem is that the original DNS protocol has a hard wired limit of > > > 512 bytes for a UDP packet after which it falls back to TCPIP. This > > > limitation has been eased in part by the DNSEXT work but the maximum UDP > > > packet size is still effectively limited by the Ethernet MTA in most > > > real world applications. If the application falls back to TCP it is much > > > simpler, cleaner and more effective to simply use HTTP which is designed > > > as a TCPIP protocol. > > > > > > In theory DNSEXT is deployed and TCPIP fallback for DNS works fine. The > > > practice is very different. The DNSEXT group has a habbit of faith based > > > deployment, i.e. if they declare the protocol deployed it is deployed. > > > > > > There are certainly cases where storing a cert in the DNS is useful but > > > it is important that the limitations of this approach be understood and > > > that it does not become another architectural fiat from the DNSEXT > > > group. > > > > > > > > > > -----Original Message----- > > > > From: owner-ietf-pkix@mail.imc.org > > > > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Tom Gindin > > > > Sent: Wednesday, October 12, 2005 6:39 PM > > > > To: Russ Housley > > > > Cc: ietf-pkix@imc.org; simon@josefsson.org > > > > Subject: Re: Storing Certificates in the DNS > > > > (draft-ietf-dnsext-rfc2538bis-08) > > > > > > > > > > > > Russ: > > > > > > > > Are there any guidelines for CRL owner names, since > > > > they're covered in the draft although DNS distribution points > > > > aren't detailed in RFC 3280? If there aren't any, IMHO a > > > > reasonable rule would be that if any sequence member of the > > > > distribution point name is a domain name (not a URI), that > > > > should be used. Also (and lower in precedence), if any > > > > sequence member of the distribution point name is an RFC 822 > > > > address, its standard translation should be used. I doubt if > > > > URI's will work without conflicts. > > > > I don't know if these count as "concerns". > > > > > > > > Tom Gindin > > > > P.S. The opinions above are mine, and not necessarily those of my > > > > employer. > > > > > > > > > > > > > > > > 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 j9DFbEEY019678; Thu, 13 Oct 2005 08:37:14 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9DFbEae019677; Thu, 13 Oct 2005 08:37:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9DFbDQF019671 for ; Thu, 13 Oct 2005 08:37:13 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 18605 invoked by uid 0); 13 Oct 2005 15:36:38 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.99.91) by woodstock.binhost.com with SMTP; 13 Oct 2005 15:36:38 -0000 Message-Id: <6.2.1.2.2.20051013113537.06447e10@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 13 Oct 2005 11:36:38 -0400 To: todd.glassey@att.net From: Russ Housley Subject: RE: Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08) Cc: ietf-pkix@imc.org, simon@josefsson.org In-Reply-To: <101320051443.13707.434E72990005C3C50000358B2160281060970A9 C9C0E0409D20B0B019B@att.net> References: <101320051443.13707.434E72990005C3C50000358B2160281060970A9C9C0E0409D20B0B019B@att.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Todd: This is not a PKIX work product, so you comments are directed at the wrong audience. Russ At 10:43 AM 10/13/2005, todd.glassey@att.net wrote: >phb - NO ONE in their right mind would use DNS as the only repository for >storing certificates and this initiative and the conversations in re of >this idea are demonstrative of how little PKIX has a grip on reality IMHO. >Clearly storing certs for DNS in DNS and possibly in some limited scope >might work, but the reality is why bother - the issue is in the trust and >use models - something which this group refuses to do... > >T. > -------------- Original message ---------------------- >From: "Hallam-Baker, Phillip" > > > > While storing certificates in the DNS makes sense in some applications I > > would be concerned if this proposal was intended to make DNS the > > recommended storage mechanism. > > > > The problem is that the original DNS protocol has a hard wired limit of > > 512 bytes for a UDP packet after which it falls back to TCPIP. This > > limitation has been eased in part by the DNSEXT work but the maximum UDP > > packet size is still effectively limited by the Ethernet MTA in most > > real world applications. If the application falls back to TCP it is much > > simpler, cleaner and more effective to simply use HTTP which is designed > > as a TCPIP protocol. > > > > In theory DNSEXT is deployed and TCPIP fallback for DNS works fine. The > > practice is very different. The DNSEXT group has a habbit of faith based > > deployment, i.e. if they declare the protocol deployed it is deployed. > > > > There are certainly cases where storing a cert in the DNS is useful but > > it is important that the limitations of this approach be understood and > > that it does not become another architectural fiat from the DNSEXT > > group. > > > > > > > -----Original Message----- > > > From: owner-ietf-pkix@mail.imc.org > > > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Tom Gindin > > > Sent: Wednesday, October 12, 2005 6:39 PM > > > To: Russ Housley > > > Cc: ietf-pkix@imc.org; simon@josefsson.org > > > Subject: Re: Storing Certificates in the DNS > > > (draft-ietf-dnsext-rfc2538bis-08) > > > > > > > > > Russ: > > > > > > Are there any guidelines for CRL owner names, since > > > they're covered in the draft although DNS distribution points > > > aren't detailed in RFC 3280? If there aren't any, IMHO a > > > reasonable rule would be that if any sequence member of the > > > distribution point name is a domain name (not a URI), that > > > should be used. Also (and lower in precedence), if any > > > sequence member of the distribution point name is an RFC 822 > > > address, its standard translation should be used. I doubt if > > > URI's will work without conflicts. > > > I don't know if these count as "concerns". > > > > > > Tom Gindin > > > P.S. The opinions above are mine, and not necessarily those of my > > > employer. > > > > > > > > > > > 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 j9DFV9ra017880; Thu, 13 Oct 2005 08:31:09 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9DFV9t4017877; Thu, 13 Oct 2005 08:31:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9DFV8VQ017848 for ; Thu, 13 Oct 2005 08:31:08 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 7422 invoked by uid 0); 13 Oct 2005 15:30:04 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.99.91) by woodstock.binhost.com with SMTP; 13 Oct 2005 15:30:04 -0000 Message-Id: <6.2.1.2.2.20051013112936.05c48280@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 13 Oct 2005 11:30:04 -0400 To: Tom Gindin From: Russ Housley Subject: Re: Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08) Cc: ietf-pkix@imc.org, simon@josefsson.org In-Reply-To: References: <6.2.1.2.2.20051010142255.06892020@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tom: Thanks for the review. I do not think that this kind of guidance belongs in draft-ietf-dnsext-rfc2538bis, but it does belong in 3280bis. Russ At 06:38 PM 10/12/2005, Tom Gindin wrote: > Russ: > > Are there any guidelines for CRL owner names, since they're >covered in the draft although DNS distribution points aren't detailed in >RFC 3280? If there aren't any, IMHO a reasonable rule would be that if >any sequence member of the distribution point name is a domain name (not a >URI), that should be used. Also (and lower in precedence), if any >sequence member of the distribution point name is an RFC 822 address, its >standard translation should be used. I doubt if URI's will work without >conflicts. > I don't know if these count as "concerns". > > Tom Gindin >P.S. The opinions above are mine, and not necessarily those of my >employer. 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 j9DEhnXq005390; Thu, 13 Oct 2005 07:43:49 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9DEhnvu005389; Thu, 13 Oct 2005 07:43:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9DEhmEZ005343 for ; Thu, 13 Oct 2005 07:43:48 -0700 (PDT) (envelope-from todd.glassey@att.net) Received: from 204.127.135.58 ([204.127.135.58]) by worldnet.att.net (mtiwmhc12) with SMTP id <2005101314433811200eemhme>; Thu, 13 Oct 2005 14:43:42 +0000 Received: from [64.127.102.91] by 204.127.135.58; Thu, 13 Oct 2005 14:43:37 +0000 From: todd.glassey@att.net To: "Hallam-Baker, Phillip" , "Tom Gindin" , "Russ Housley" Cc: , Subject: RE: Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08) Date: Thu, 13 Oct 2005 14:43:37 +0000 Message-Id: <101320051443.13707.434E72990005C3C50000358B2160281060970A9C9C0E0409D20B0B019B@att.net> X-Mailer: AT&T Message Center Version 1 (Feb 14 2005) X-Authenticated-Sender: dG9kZC5nbGFzc2V5QGF0dC5uZXQ= Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: phb - NO ONE in their right mind would use DNS as the only repository for storing certificates and this initiative and the conversations in re of this idea are demonstrative of how little PKIX has a grip on reality IMHO. Clearly storing certs for DNS in DNS and possibly in some limited scope might work, but the reality is why bother - the issue is in the trust and use models - something which this group refuses to do... T. -------------- Original message ---------------------- From: "Hallam-Baker, Phillip" > > While storing certificates in the DNS makes sense in some applications I > would be concerned if this proposal was intended to make DNS the > recommended storage mechanism. > > The problem is that the original DNS protocol has a hard wired limit of > 512 bytes for a UDP packet after which it falls back to TCPIP. This > limitation has been eased in part by the DNSEXT work but the maximum UDP > packet size is still effectively limited by the Ethernet MTA in most > real world applications. If the application falls back to TCP it is much > simpler, cleaner and more effective to simply use HTTP which is designed > as a TCPIP protocol. > > In theory DNSEXT is deployed and TCPIP fallback for DNS works fine. The > practice is very different. The DNSEXT group has a habbit of faith based > deployment, i.e. if they declare the protocol deployed it is deployed. > > There are certainly cases where storing a cert in the DNS is useful but > it is important that the limitations of this approach be understood and > that it does not become another architectural fiat from the DNSEXT > group. > > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Tom Gindin > > Sent: Wednesday, October 12, 2005 6:39 PM > > To: Russ Housley > > Cc: ietf-pkix@imc.org; simon@josefsson.org > > Subject: Re: Storing Certificates in the DNS > > (draft-ietf-dnsext-rfc2538bis-08) > > > > > > Russ: > > > > Are there any guidelines for CRL owner names, since > > they're covered in the draft although DNS distribution points > > aren't detailed in RFC 3280? If there aren't any, IMHO a > > reasonable rule would be that if any sequence member of the > > distribution point name is a domain name (not a URI), that > > should be used. Also (and lower in precedence), if any > > sequence member of the distribution point name is an RFC 822 > > address, its standard translation should be used. I doubt if > > URI's will work without conflicts. > > I don't know if these count as "concerns". > > > > Tom Gindin > > P.S. The opinions above are mine, and not necessarily those of my > > employer. > > > > > > > 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 j9D2NR99097135; Wed, 12 Oct 2005 19:23:27 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9D2NRpG097134; Wed, 12 Oct 2005 19:23:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9D2NQL2097127 for ; Wed, 12 Oct 2005 19:23:26 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by colibri.verisign.com (8.13.1/8.13.4) with ESMTP id j9D2NLNX007342; Wed, 12 Oct 2005 19:23:21 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Oct 2005 19:23:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08) Date: Wed, 12 Oct 2005 19:23:20 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD376D51AB@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08) Thread-Index: AcXPhxBGZ1gNKPvpTcWuwqYTEn+ixAACab6g From: "Hallam-Baker, Phillip" To: "Tom Gindin" , "Russ Housley" Cc: , X-OriginalArrivalTime: 13 Oct 2005 02:23:21.0293 (UTC) FILETIME=[14A267D0:01C5CF9D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j9D2NQL2097129 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: While storing certificates in the DNS makes sense in some applications I would be concerned if this proposal was intended to make DNS the recommended storage mechanism. The problem is that the original DNS protocol has a hard wired limit of 512 bytes for a UDP packet after which it falls back to TCPIP. This limitation has been eased in part by the DNSEXT work but the maximum UDP packet size is still effectively limited by the Ethernet MTA in most real world applications. If the application falls back to TCP it is much simpler, cleaner and more effective to simply use HTTP which is designed as a TCPIP protocol. In theory DNSEXT is deployed and TCPIP fallback for DNS works fine. The practice is very different. The DNSEXT group has a habbit of faith based deployment, i.e. if they declare the protocol deployed it is deployed. There are certainly cases where storing a cert in the DNS is useful but it is important that the limitations of this approach be understood and that it does not become another architectural fiat from the DNSEXT group. > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Tom Gindin > Sent: Wednesday, October 12, 2005 6:39 PM > To: Russ Housley > Cc: ietf-pkix@imc.org; simon@josefsson.org > Subject: Re: Storing Certificates in the DNS > (draft-ietf-dnsext-rfc2538bis-08) > > > Russ: > > Are there any guidelines for CRL owner names, since > they're covered in the draft although DNS distribution points > aren't detailed in RFC 3280? If there aren't any, IMHO a > reasonable rule would be that if any sequence member of the > distribution point name is a domain name (not a URI), that > should be used. Also (and lower in precedence), if any > sequence member of the distribution point name is an RFC 822 > address, its standard translation should be used. I doubt if > URI's will work without conflicts. > I don't know if these count as "concerns". > > Tom Gindin > P.S. The opinions above are mine, and not necessarily those of my > employer. > > > Received: from auriga.webchance-net.de (auriga.webchance-net.de [212.162.2.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9CNDQZ2082129 for ; Wed, 12 Oct 2005 16:13:27 -0700 (PDT) (envelope-from testuser@auriga.webchance-net.de) Received: from testuser by auriga.webchance-net.de with local (Exim 4.51 (FreeBSD)) id 1EPpmo-0006Km-41 for ietf-pkix-archive@imc.org; Thu, 13 Oct 2005 01:13:26 +0200 To: ietf-pkix-archive@imc.org Subject: eBay Safe Department Notice From: eBay Notice Content-Type: text/html Message-Id: Sender: Webchance Testuser Date: Thu, 13 Oct 2005 01:13:26 +0200
eBay
 
***eBay Safe Department Notice***
 

eBay Fraud Mediation Request

You have recieved this email because of some unusual activity in your account.In accordance with eBay's User Agreement and to ensure that your account has not been compromised, access to your account was limited. Your account access will remain limited until this issue has been resolved.

THE FRAUD ALERT ID CODE CONTAINED IN THIS MESSAGE WILL BE ATTACHED IN OUR FRAUD MEDIATION REQUEST FORM, IN ORDER TO VERIFY YOUR EBAY ACCOUNT REGISTRATION INFORMATIONS.

Fraud Alert ID CODE: 09714526
(Please save this Fraud Alert ID Code for your reference.)

To help speed up this process, please access the following form to complete the verification of your eBay account registration informations:

https://arribada.ebay.com/saw-cgi/eBayISAPI.dll?PaceCCInfo&SignIn&UsingSSL=1

.
Please Note:
If we do not receive the appropriate eBay account verification within 48 hours, then we will assume this eBay account is fraudulent and will be suspended.
The purpose of this verification is to ensure that your eBay account has not been fraudulently used and to combat the fraud from our community.

We appreciate your support and understanding, as we work together to keep eBay a safe place.

Thank you for using eBay!
The eBay Team

Please do not reply to this e-mail as this is only a notification. Mail sent to this address cannot be answered.



Copyright © 1999-2005 eBay. All rights reserved.
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 j9CMdCB8079346; Wed, 12 Oct 2005 15:39:12 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9CMdCoJ079345; Wed, 12 Oct 2005 15:39:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9CMd7Vc079333 for ; Wed, 12 Oct 2005 15:39:07 -0700 (PDT) (envelope-from tgindin@us.ibm.com) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j9CMd1Q4023760 for ; Wed, 12 Oct 2005 18:39:01 -0400 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 j9CMd16E103212 for ; Wed, 12 Oct 2005 18:39:01 -0400 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 j9CMd0ue028109 for ; Wed, 12 Oct 2005 18:39:00 -0400 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 j9CMd0p3028096; Wed, 12 Oct 2005 18:39:00 -0400 In-Reply-To: <6.2.1.2.2.20051010142255.06892020@mail.binhost.com> To: Russ Housley Cc: ietf-pkix@imc.org, simon@josefsson.org MIME-Version: 1.0 Subject: Re: Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08) X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Tom Gindin Message-ID: Date: Wed, 12 Oct 2005 18:38:58 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 10/12/2005 18:38:59, Serialize complete at 10/12/2005 18:38:59 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ: Are there any guidelines for CRL owner names, since they're covered in the draft although DNS distribution points aren't detailed in RFC 3280? If there aren't any, IMHO a reasonable rule would be that if any sequence member of the distribution point name is a domain name (not a URI), that should be used. Also (and lower in precedence), if any sequence member of the distribution point name is an RFC 822 address, its standard translation should be used. I doubt if URI's will work without conflicts. I don't know if these count as "concerns". Tom Gindin P.S. The opinions above are mine, and not necessarily those of my employer. 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 j9CK84cR066030; Wed, 12 Oct 2005 13:08:04 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9CK84L0066027; Wed, 12 Oct 2005 13:08:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9CK80L3066017 for ; Wed, 12 Oct 2005 13:08:01 -0700 (PDT) (envelope-from shu-jen.chang@nist.gov) 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 j9CJsijb011784; Wed, 12 Oct 2005 15:55:57 -0400 Received: from othello.nist.gov (othello.ncsl.nist.gov [129.6.54.41]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j9CJqTG4026166; Wed, 12 Oct 2005 15:52:29 -0400 (EDT) Message-Id: <5.1.1.5.2.20051012154229.0304b5d0@email.nist.gov> X-Sender: sjchang@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 12 Oct 2005 15:51:43 -0400 To: shu-jen.chang@nist.gov From: Shu-jen Chang Subject: Oops Re: Hash Workshop Program Ready and Posted Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_20986500==.ALT" X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: shu-jen.chang@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=====================_20986500==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Oops. I meant to hide the recipient list and just Blind CC them, but I forgot to do that before I hit the send key. Also, I was going to remove the attachment, but I got distracted and forgot to do that too. I am very sorry, especially to Professor Yao. Apologetically, Shu-jen Chang --=====================_20986500==.ALT Content-Type: text/html; charset="us-ascii" Oops. I meant to hide the recipient list and just Blind CC them, but I forgot to do that before I hit the send key. Also, I was going to remove the attachment, but I got distracted and forgot to do that too. I am very sorry, especially to Professor Yao.

Apologetically,
Shu-jen Chang
--=====================_20986500==.ALT-- 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 j9AIQS4M053355; Mon, 10 Oct 2005 11:26:28 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9AIQSr8053354; Mon, 10 Oct 2005 11:26:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j9AIQQZx053345 for ; Mon, 10 Oct 2005 11:26:27 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 6508 invoked by uid 0); 10 Oct 2005 18:25:13 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.183.78) by woodstock.binhost.com with SMTP; 10 Oct 2005 18:25:13 -0000 Message-Id: <6.2.1.2.2.20051010142255.06892020@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 10 Oct 2005 14:25:12 -0400 To: ietf-pkix@imc.org From: Russ Housley Subject: Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please take a look at draft-ietf-dnsext-rfc2538bis-08. It is on the agenda for the IESG telechat this Thursday. If anyone has any concerns, please notify me by Wednesday. 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 j92ID1JI087094; Sun, 2 Oct 2005 11:13:01 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j92ID1nP087093; Sun, 2 Oct 2005 11:13:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org 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 j92ID08r087087 for ; Sun, 2 Oct 2005 11:13:00 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 21344 invoked by uid 0); 2 Oct 2005 18:12:54 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (212.147.51.217) by woodstock.binhost.com with SMTP; 2 Oct 2005 18:12:54 -0000 Message-Id: <6.2.1.2.2.20051002140915.05d69c20@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 02 Oct 2005 14:10:47 -0400 To: "Ersin Gulacti" , ietf-pkix@imc.org From: Russ Housley Subject: Re: RFC for Certificate Store In-Reply-To: <20051002143239.C70C9BD65CA@uekae.uekae.gov.tr> References: <20051002143239.C70C9BD65CA@uekae.uekae.gov.tr> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It is in the RFC Editor queue:

2005-08-23      

draft-ietf-pkix-certstore-http-09.txt
EDIT
P. Gutmann
Internet X.509 Public Key Infrastructure Operational Protocols:
Certificate Store Access via HTTP
Bytes: 52680
Working Group: Public-Key Infrastructure (X.509)
At 10:33 AM 10/2/2005, Ersin Gulacti wrote:


Hello,

On the PKIX page it is declared that on Jun 2005 Certificate Store is
approved as Informational RFC. Unfortunately I couldn't find any documents
related to this RFC. Is it going to be released soon? Or better can
someone post a copy of it? We plan to implement a certificate store and I
would prefer to read a related RFC before starting our design.

Thanks.

Ersin Gulacti
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 j92EZQL3055292; Sun, 2 Oct 2005 07:35:26 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j92EZPFU055291; Sun, 2 Oct 2005 07:35:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from uekae.uekae.gov.tr (uekaegateway.mam.gov.tr [193.140.74.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j92EZOCn055285 for ; Sun, 2 Oct 2005 07:35:25 -0700 (PDT) (envelope-from egulacti@uekae.tubitak.gov.tr) Received: from www.uekae.tubitak.gov.tr (hitit.uekae.tubitak.gov.tr [192.168.5.6]) by uekae.uekae.gov.tr (UEKAE_MAIL_SERVER_V4) with ESMTP id 0DEBEBD65CA for ; Sun, 2 Oct 2005 17:32:39 +0300 (EEST) Received: from 85.96.157.50 (SquirrelMail authenticated user egulacti) by www.uekae.tubitak.gov.tr with HTTP; Sun, 2 Oct 2005 17:33:33 +0300 (EEST) Date: Sun, 2 Oct 2005 17:33:33 +0300 (EEST) Subject: RFC for Certificate Store From: "Ersin Gulacti" To: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-9 X-Priority: 3 (Normal) Importance: Normal Message-Id: <20051002143239.C70C9BD65CA@uekae.uekae.gov.tr> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j92EZPCn055286 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello, On the PKIX page it is declared that on Jun 2005 Certificate Store is approved as Informational RFC. Unfortunately I couldn't find any documents related to this RFC. Is it going to be released soon? Or better can someone post a copy of it? We plan to implement a certificate store and I would prefer to read a related RFC before starting our design. Thanks. Ersin Gulacti