From owner-ietf-pkix@mail.imc.org Fri Jun 02 18:28:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmI8X-0000oL-9I for pkix-archive@lists.ietf.org; Fri, 02 Jun 2006 18:28:57 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmI8U-0004wU-PG for pkix-archive@lists.ietf.org; Fri, 02 Jun 2006 18:28:57 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k52LT6BS029392; Fri, 2 Jun 2006 14:29:06 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k52LT6wW029391; Fri, 2 Jun 2006 14:29:06 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k52LT4hd029384 for ; Fri, 2 Jun 2006 14:29:05 -0700 (MST) (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); Fri, 2 Jun 2006 22:29:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6868B.922D5A85" Subject: Request for agenda items for next IETF in Montreal Date: Fri, 2 Jun 2006 22:29:02 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request for agenda items for next IETF in Montreal Thread-Index: AcaGi5FVe42aNExIS2mEBuVUe7WsrQ== From: "Stefan Santesson" To: X-OriginalArrivalTime: 02 Jun 2006 21:29:03.0526 (UTC) FILETIME=[9208BC60:01C6868B] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6868B.922D5A85 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At next IETF in Montreal we are going to have two PKIX sessions. =20 One PKIX only session, in the traditional form, and one joint session with the SIDR WG (Secure Inter-Domain Routing) At the joint PKIX/SIDR meeting, Steve Kent will give a 1 hour presentation on a PKI proposal. =20 I will however only manage the agenda for the PKIX only session. =20 Please let me know if you want to request a time slot for this meeting. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =20 ------_=_NextPart_001_01C6868B.922D5A85 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At next IETF in Montreal we are going to have two PKIX sessions.

 

One PKIX only session, in the traditional form, and = one joint session with the SIDR WG (Secure Inter-Domain = Routing)

At the joint PKIX/SIDR meeting, Steve Kent will give = a 1 hour presentation on a PKI proposal.

 

I will however only manage the agenda for the PKIX = only session.

 

Please let me know if you want to request a time slot = for this meeting.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

 

------_=_NextPart_001_01C6868B.922D5A85-- From owner-ietf-pkix@mail.imc.org Thu Jun 15 11:11:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqtVf-00052m-Ne for pkix-archive@lists.ietf.org; Thu, 15 Jun 2006 11:11:51 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqtVe-0000ZT-C6 for pkix-archive@lists.ietf.org; Thu, 15 Jun 2006 11:11:51 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5FEDPf0085845; Thu, 15 Jun 2006 07:13:25 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5FEDPWe085844; Thu, 15 Jun 2006 07:13:25 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5FEDOQX085803 for ; Thu, 15 Jun 2006 07:13:25 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5FEDIRx004082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Jun 2006 14:13:18 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fqsb0-0006sq-0Y; Thu, 15 Jun 2006 10:13:18 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Subject: Last Call: 'Lightweight OCSP Profile for High Volume Environments' to Informational RFC (draft-ietf-pkix-lightweight-ocsp-profile) Reply-to: iesg@ietf.org CC: Message-Id: Date: Thu, 15 Jun 2006 10:13:18 -0400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 The IESG has received a request from the Public-Key Infrastructure (X.509) WG to consider the following document: - 'Lightweight OCSP Profile for High Volume Environments ' as an Informational RFC 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 2006-06-29. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pkix-lightweight-ocsp-profile-05.txt From owner-ietf-pkix@mail.imc.org Fri Jun 16 11:12:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrFzu-0007fb-2U for pkix-archive@lists.ietf.org; Fri, 16 Jun 2006 11:12:34 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrEOo-00038N-0F for pkix-archive@lists.ietf.org; Fri, 16 Jun 2006 09:30:10 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FrDto-0002aX-IW for pkix-archive@lists.ietf.org; Fri, 16 Jun 2006 08:58:09 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5GBlNGR064551; Fri, 16 Jun 2006 04:47:23 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5GBlNG8064550; Fri, 16 Jun 2006 04:47:23 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5GBlMUB064530 for ; Fri, 16 Jun 2006 04:47:22 -0700 (MST) (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); Fri, 16 Jun 2006 12:47:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6913A.9D1E621C" Subject: RE: Request for agenda items for next IETF in Montreal Date: Fri, 16 Jun 2006 12:47:15 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request for agenda items for next IETF in Montreal thread-index: AcaGi5FVe42aNExIS2mEBuVUe7WsrQKrr3DA From: "Stefan Santesson" To: X-OriginalArrivalTime: 16 Jun 2006 11:47:15.0913 (UTC) FILETIME=[9D423390:01C6913A] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: -1.9 (-) X-Scan-Signature: cbb41f2dbf0f142369614756642005e3 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6913A.9D1E621C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would appreciate if editors of each wg document could send me a note about whether any of the editors will be at the PKIX meeting and how much time they need to make a status report. =20 Thanks =20 Stefan Santesson Senior Program Manager Windows Security, Standards ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: den 2 juni 2006 23:29 To: ietf-pkix@imc.org Subject: Request for agenda items for next IETF in Montreal =20 At next IETF in Montreal we are going to have two PKIX sessions. =20 One PKIX only session, in the traditional form, and one joint session with the SIDR WG (Secure Inter-Domain Routing) At the joint PKIX/SIDR meeting, Steve Kent will give a 1 hour presentation on a PKI proposal. =20 I will however only manage the agenda for the PKIX only session. =20 Please let me know if you want to request a time slot for this meeting. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =20 ------_=_NextPart_001_01C6913A.9D1E621C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would appreciate if editors of = each wg document could send me a note about whether any of the editors will be = at the PKIX meeting and how much time they need to make a status = report.

 

Thanks

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Stefan Santesson
Sent: den 2 juni 2006 = 23:29
To: ietf-pkix@imc.org
Subject: Request for = agenda items for next IETF in Montreal

 

At next IETF in Montreal we are going to have two PKIX sessions.

 

One PKIX only session, in the traditional form, and = one joint session with the SIDR WG (Secure Inter-Domain = Routing)

At the joint PKIX/SIDR meeting, Steve Kent will give = a 1 hour presentation on a PKI proposal.

 

I will however only manage the agenda for the PKIX = only session.

 

Please let me know if you want to request a time slot = for this meeting.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

 

------_=_NextPart_001_01C6913A.9D1E621C-- From owner-ietf-pkix@mail.imc.org Fri Jun 16 13:58:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrIai-00069X-LV for pkix-archive@lists.ietf.org; Fri, 16 Jun 2006 13:58:44 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrIah-0005mK-9s for pkix-archive@lists.ietf.org; Fri, 16 Jun 2006 13:58:44 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5GH8jtq032776; Fri, 16 Jun 2006 10:08:45 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5GH8jLf032775; Fri, 16 Jun 2006 10:08:45 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5GH8hdc032768 for ; Fri, 16 Jun 2006 10:08:44 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k5GH8U3X009701; Fri, 16 Jun 2006 13:08:31 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.6/8.13.6) with ESMTP id k5GH8BOM021775; Fri, 16 Jun 2006 13:08:11 -0400 (EDT) Message-ID: <4492E58E.9030501@nist.gov> Date: Fri, 16 Jun 2006 13:08:30 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: yquenechdu@linagora.com CC: pkix Subject: Re: [Fwd: draft-ietf-pkix-scvp-25.txt] References: <2047.10.0.0.1.1149092463.squirrel@tomate.linagora.lan> In-Reply-To: <2047.10.0.0.1.1149092463.squirrel@tomate.linagora.lan> 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 This was a typographical error. The text should have referred to section 3.11 (SCVP Request Authentication), which defines the id-kp-scvpClient OID, but the cross-reference did not get updated when a new subsection was added to section 3. yannick quenechdu wrote: >Hi, > >I would wish a clarification about section 3 : > >"If the extended key usage extension is present, it MUST contain either >the SCVP client OID (see Section 3.10) or another OID acceptable to the >SCVP server." > >I do not see the relation with section 3.10. It is necessary to use the >field RequestorText to indicate a OID for SCVP client ? > > From owner-ietf-pkix@mail.imc.org Fri Jun 16 14:21:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrIwi-0003c3-6Y for pkix-archive@lists.ietf.org; Fri, 16 Jun 2006 14:21:28 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrIwg-0008Re-M8 for pkix-archive@lists.ietf.org; Fri, 16 Jun 2006 14:21:28 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5GHdun2040251; Fri, 16 Jun 2006 10:39:56 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5GHdug5040250; Fri, 16 Jun 2006 10:39:56 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5GHdsu8040236 for ; Fri, 16 Jun 2006 10:39:55 -0700 (MST) (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); Fri, 16 Jun 2006 18:39:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6916B.E03064F2" Subject: WG Last Call: RFC3280bis Date: Fri, 16 Jun 2006 18:39:52 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Last Call: RFC3280bis thread-index: AcaRa9/PSg6uKi45SZ+HHXAxZPazQA== From: "Stefan Santesson" To: X-OriginalArrivalTime: 16 Jun 2006 17:39:53.0711 (UTC) FILETIME=[E049F7F0:01C6916B] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e This is a multi-part message in MIME format. ------_=_NextPart_001_01C6916B.E03064F2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, =20 This message initiates working group last call for "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" This document is currently available at: http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt. =20 =20 The last call will be two weeks. That is, Last Call for this document closes on or after July 3rd, 2006. =20 Since I'm co-editor, Steve Kent will determine WG consensus. =20 Thanks, =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =20 ------_=_NextPart_001_01C6916B.E03064F2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

This message initiates working group last =
call for "Internet X.509 Public Key Infrastructure, Certificate and =
Certificate Revocation List (CRL) =
Profile”

This document is = currently available at: http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt.&= nbsp;

 

The last call will = be two weeks.  That is, Last Call for this document closes on or after = July 3rd, 2006.

 

Since I’m = co-editor, Steve Kent will determine WG consensus.

 

Thanks,

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

 

------_=_NextPart_001_01C6916B.E03064F2-- From owner-ietf-pkix@mail.imc.org Fri Jun 16 16:20:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrKnY-00030Z-NF for pkix-archive@lists.ietf.org; Fri, 16 Jun 2006 16:20:08 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrKnX-0005HA-Af for pkix-archive@lists.ietf.org; Fri, 16 Jun 2006 16:20:08 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5GJcbOv069992; Fri, 16 Jun 2006 12:38:37 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5GJcbdD069991; Fri, 16 Jun 2006 12:38:37 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5GJcaRN069976 for ; Fri, 16 Jun 2006 12:38:37 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k5GJcWBo019756 for ; Fri, 16 Jun 2006 15:38:32 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.6/8.13.6) with ESMTP id k5GJbiOB028565 for ; Fri, 16 Jun 2006 15:37:44 -0400 (EDT) Message-ID: <4493089C.4040701@nist.gov> Date: Fri, 16 Jun 2006 15:38:04 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pkix Subject: draft-ietf-pkix-scvp-26.txt 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f All, I have just submitted draft 26 of SCVP for posting. The draft should be available soon, but in the meantime, I have posted a diff file highlighting the differences between drafts 24 and 26 (the only difference between drafts 24 and 25 was the correction of a typographical error in section 3.6). The diff file is available at http://csrc.nist.gov/pki/documents/PKIX/wdiff_draft-ietf-pkix-scvp-24_to_26.html. Drafts 24 and 26 differ in the following places: 1) Section 3: corrected cross-reference ("3.10" replaced by "3.11"). 2) Section 3.2.4.2.3 (Name Validation Algorithm): Matching rules for use with id-kp-serverAuth are now specified in the document rather than referring to the matching rules in RFC 2818 [HTTP-TLS]. (RFC 2818 is an Informational RFC and so SCVP could not include a normative reference to that document). 3) Section 3.6: "requestorName" replaced with "responderName". (This was the typographical error that was corrected in draft 25.) 4) Section 4: A new sentence was added to clarify that when a protected response is required, the SCVP server must use SignedData or AuthenticatedData even if the response is being sent over a protected transport (e.g., TLS). 5) Section 11.1 (Normative References): The reference to RFC 2818 was deleted. None of these changes to the document result in any changes to the protocol. Dave From owner-ietf-pkix@mail.imc.org Fri Jun 16 17:35:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrLy0-0001HN-9L for pkix-archive@lists.ietf.org; Fri, 16 Jun 2006 17:35:00 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrLll-0003nY-VD for pkix-archive@lists.ietf.org; Fri, 16 Jun 2006 17:22:24 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5GKgf0e086321; Fri, 16 Jun 2006 13:42:41 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5GKgfwq086320; Fri, 16 Jun 2006 13:42:41 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5GKge9K086292 for ; Fri, 16 Jun 2006 13:42:41 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.136.89]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FrL9G-0008Sj-5H for ietf-pkix@imc.org; Fri, 16 Jun 2006 16:42:34 -0400 Mime-Version: 1.0 Message-Id: Date: Fri, 16 Jun 2006 16:42:28 -0400 To: ietf-pkix@imc.org From: Stephen Kent Subject: last call for 3280bis Content-Type: multipart/alternative; boundary="============_-1061631940==_ma============" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 --============_-1061631940==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Folks, Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt) The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th. Steve --============_-1061631940==_ma============ Content-Type: text/html; charset="us-ascii" last call for 3280bis
Folks,

Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt)
 
The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th.

Steve
--============_-1061631940==_ma============-- From owner-ietf-pkix@mail.imc.org Mon Jun 19 10:10:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsKRi-00014y-7c for pkix-archive@lists.ietf.org; Mon, 19 Jun 2006 10:09:42 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsKKm-0008Ne-2d for pkix-archive@lists.ietf.org; Mon, 19 Jun 2006 10:02:33 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5JCvXCa067152; Mon, 19 Jun 2006 05:57:33 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5JCvXrX067151; Mon, 19 Jun 2006 05:57:33 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5JCvWQl067144 for ; Mon, 19 Jun 2006 05:57:32 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.192.42.43]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FsJJm-0008Bo-3O for ietf-pkix@imc.org; Mon, 19 Jun 2006 08:57:26 -0400 Mime-Version: 1.0 Message-Id: Date: Mon, 19 Jun 2006 02:27:46 -0400 To: ietf-pkix@imc.org From: Stephen Kent Subject: slight whoops Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.2 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 As you may have noticed, Stefan and I independently sent out last call notices for 3820bis, with slightly different closing dates. We have agreed to go with my date, so July 5th is the close of last call for 3280bis. Steve From owner-ietf-pkix@mail.imc.org Mon Jun 19 17:35:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsROv-0001lz-JA for pkix-archive@lists.ietf.org; Mon, 19 Jun 2006 17:35:17 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsROt-0002Fz-1n for pkix-archive@lists.ietf.org; Mon, 19 Jun 2006 17:35:17 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5JKnFKT060472; Mon, 19 Jun 2006 13:49:15 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5JKnFAu060471; Mon, 19 Jun 2006 13:49:15 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from csexchange1.corestreet.com (host200.58.41.216.conversent.net [216.41.58.200]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5JKnELS060441 for ; Mon, 19 Jun 2006 13:49:14 -0700 (MST) (envelope-from shitchings@corestreet.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: I-D ACTION:draft-ietf-pkix-sha2-dsa-ecdsa-00.txt Date: Mon, 19 Jun 2006 16:49:07 -0400 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_03AF_01C693C0.47A81700" Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-pkix-sha2-dsa-ecdsa-00.txt Thread-Index: AcaT26+2MLXK1X5zRxO2IesgECCEswABbr5A From: "Seth Hitchings" To: Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.1 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba This is a multi-part message in MIME format. ------=_NextPart_000_03AF_01C693C0.47A81700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Section 3.1 (DSA Signature Algorithm) lists both id-dsa-with-sha224 and id-dsa-with-sha256 as: joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101) csor(3) algorithms(4) id-dsa-with-sha2(3) 1 They're correctly identified (I think) in the ASN.1 module as 3.1 and 3.2, respectively. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, June 19, 2006 3:50 PM To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org Subject: I-D ACTION:draft-ietf-pkix-sha2-dsa-ecdsa-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA Author(s) : Q. Dang, et al. Filename : draft-ietf-pkix-sha2-dsa-ecdsa-00.txt Pages : Date : 2006-6-19 This document supplements RFC 3279. It specifies algorithm identifiers, and ASN.1 encoding rules for the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures when using SHA-224, SHA-256, 384 or SHA-512 as hashing algorithm. This specification applies to the Internet X.509 Public Key Infrastructure (PKI) when digital signatures are used to sign certificates and certificate revocation list (CRLs). The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha2-dsa-ecdsa-00.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-sha2-dsa-ecdsa-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-sha2-dsa-ecdsa-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_03AF_01C693C0.47A81700 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIVzCCAoIw ggHroAMCAQICAQQwDQYJKoZIhvcNAQEEBQAwUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0VxdWlm YXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0xMB4X DTk5MDYyMTA0MDAwMFoXDTIwMDYyMTA0MDAwMFowUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0Vx dWlmYXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0x MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOLxm8F7d33pOpX1oNF080GgyY9CLZWdTEaEbw tDXFhQMgxq9FpSFRRUHrFlg2Mm/iUGJk+f1RnKok2fSdgyqHCiHTEjg0bI0Ablqg2ULuGiGV+VJM VVrFDzhPRvpt+C411h186+LwsHWAyKkTrL6I7zpuq18qOGICsBJ7/o+mAwIDAQABo2YwZDARBglg hkgBhvhCAQEEBAMCAAcwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRKeDJSEdtZFjZe38EU NkBqR3xMoTAdBgNVHQ4EFgQUSngyUhHbWRY2Xt/BFDZAakd8TKEwDQYJKoZIhvcNAQEEBQADgYEA dVuomwMR5ulWTM35qUzADZrzzGVp5iV2zFm31lTDHc2ZrBndtIXV4D38YiCnhEtYZfHi+ZUhP/XU flgeR4dUPlihtbX4Ku9x57zD9rFJRuLXoGvlVnqaJ5h8RmIU58n8bgMSeYA4HUiCjfwX/iqWK7Vi pqY9vX+SWc1aKoKyN3kwggK8MIICJaADAgECAgIA2DANBgkqhkiG9w0BAQUFADBTMQswCQYDVQQG EwJVUzEcMBoGA1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1 cmUgZUJ1c2luZXNzIENBLTEwHhcNMDQwNjAyMTk1NzQyWhcNMjAwNjIxMDQwMDAwWjBSMQswCQYD VQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENl cnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr0HhHsWZ2xkS 6BbojMXvdGPoRJLcAs2nUBSZ6XnJvnHxBwVvRUkqrCSBwKBurhjqGqe3oOxh6tC6wUuGhwLdhyWT BSYO469PJUx02lyiohqUZ8u0yshCL35/lA+MkZubcmFxHsLlTPCkS/+A7PZwzIjKrLAUT0VmwNTL TYEg1F8CAwEAAaOBnzCBnDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFNjsf5MYxWYDwxBsPAT2 d4U+/wu2MB8GA1UdIwQYMBaAFEp4MlIR21kWNl7fwRQ2QGpHfEyhMA8GA1UdEwEB/wQFMAMBAf8w OQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5nZW90cnVzdC5jb20vY3Jscy9lYml6Y2ExLmNy bDANBgkqhkiG9w0BAQUFAAOBgQDCHD9PBDwPPDktSLC/jRpe9Crdpj8Cj7GB1od44j1D+5IJji+w rhuJ3tlR3p5MlzXGUEj8eFBtZymYBiWdLvIVqwMz2nYWBeFWXou6T+n4akcF708jM3MhFXP82ove f/xJzw9IzlVmI9DjDrkL2wXXw/IR5XTP2iQYPcbxento6zCCAw0wggJ2oAMCAQICAXwwDQYJKoZI hvcNAQEFBQAwUjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEpMCcGA1UE AxMgQ29yZVN0cmVldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDUwODI5MTQyNTQwWhcNMDYw OTEyMTQyNTQwWjBqMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMRcwFQYD VQQDEw5TZXRoIEhpdGNoaW5nczEoMCYGCSqGSIb3DQEJARYZc2hpdGNoaW5nc0Bjb3Jlc3RyZWV0 LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzZOhlCd/KDWl33RR6dW+YKFd8Kof1Uz8 9wJ3EevLEK73npZfKDj66mL6fQOL1Cv1RaQrucsm8ZB2bMvUDRvoeC1Te4xsHvxNyV8AoEbxYWsK QciJCNM5bd6kkpfgummUBCgUs7nze+FNhIzWGerlMUjcc37diSOD+FP24WXU+zUCAwEAAaOB2jCB 1zAOBgNVHQ8BAf8EBAMCBeAwPAYDVR0fBDUwMzAxoC+gLYYraHR0cDovL2NybC5nZW90cnVzdC5j b20vY3Jscy9jb3Jlc3RyZWV0LmNybDAkBgNVHREEHTAbgRlzaGl0Y2hpbmdzQGNvcmVzdHJlZXQu Y29tMB8GA1UdIwQYMBaAFNjsf5MYxWYDwxBsPAT2d4U+/wu2MEAGCCsGAQUFBwEBBDQwMjAwBggr BgEFBQcwAYYkaHR0cDovL2dlb3RydXN0LW9jc3AuY29yZXN0cmVldC5jb20vMA0GCSqGSIb3DQEB BQUAA4GBAHPT6HnJxaWD8+WdUL//eXEekqR0rio7r2OdTJ4VSrWZQRHMkWmOzG8aPvgGX7SMh0QZ TvcSBNY7h43m5fPNk7Jaxy+F3LbdwHu02NM/IiUBsLyn8XXi03Xekni5PT6aDuP/Egux3nnlKjej mMjDOVTNBwKwF/QfjP+QViQTO6hoMYICmTCCApUCAQEwVzBSMQswCQYDVQQGEwJVUzEYMBYGA1UE ChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENlcnRpZmljYXRlIEF1dGhv cml0eQIBfDAJBgUrDgMCGgUAoIIBmDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wNjA2MTkyMDQ5MDdaMCMGCSqGSIb3DQEJBDEWBBTFSBrGrSbb7ZipPU03Yc9KG39m ZjBmBgkrBgEEAYI3EAQxWTBXMFIxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9Db3JlU3RyZWV0IEx0 ZC4xKTAnBgNVBAMTIENvcmVTdHJlZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AgF8MGcGCSqGSIb3 DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO AwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMGgGCyqGSIb3DQEJEAILMVmg VzBSMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3Jl U3RyZWV0IENlcnRpZmljYXRlIEF1dGhvcml0eQIBfDANBgkqhkiG9w0BAQEFAASBgG8HPFCgVDNY rbDTRiwM90zZSSHPqapmTpKHK2bY7bfA0ZEF7ZJ7eM0jq/EGfYqy754xQrK92hvsUGdFvKVQjoZB c699cXA/LyOqJ9/XlPWQT6MJCn3wp0tYNf9qstF1m9Dvq1tOu9hkqbmXMuE7m5V6hHCeG1oM2Qb8 jIX9aMRXAAAAAAAA ------=_NextPart_000_03AF_01C693C0.47A81700-- From owner-ietf-pkix@mail.imc.org Mon Jun 19 17:42:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsRVu-0002oP-Vt for pkix-archive@lists.ietf.org; Mon, 19 Jun 2006 17:42:30 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsRVq-00038Y-HQ for pkix-archive@lists.ietf.org; Mon, 19 Jun 2006 17:42:30 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5JJo9En047998; Mon, 19 Jun 2006 12:50:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5JJo9jU047997; Mon, 19 Jun 2006 12:50:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5JJo8ia047973 for ; Mon, 19 Jun 2006 12:50:08 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5JJo2WR003167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FsPl3-0007ZO-V3; Mon, 19 Jun 2006 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-26.txt Message-Id: Date: Mon, 19 Jun 2006 15:50:01 -0400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.3 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 --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 : Server-based Certificate Validation Protocol (SCVP) Author(s) : A. Malpani, et al. Filename : draft-ietf-pkix-scvp-26.txt Pages : 84 Date : 2006-6-19 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-26.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-26.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-26.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: <2006-6-19130822.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-scvp-26.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-scvp-26.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-19130822.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix@mail.imc.org Mon Jun 19 17:45:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsRZA-0005N9-CX for pkix-archive@lists.ietf.org; Mon, 19 Jun 2006 17:45:52 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsR0m-0000v3-Jq for pkix-archive@lists.ietf.org; Mon, 19 Jun 2006 17:10:20 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FsQl7-0000Fk-7L for pkix-archive@lists.ietf.org; Mon, 19 Jun 2006 16:54:10 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5JJoBBr048015; Mon, 19 Jun 2006 12:50:11 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5JJoBIO048014; Mon, 19 Jun 2006 12:50:11 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5JJoA5J047974 for ; Mon, 19 Jun 2006 12:50:11 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5JJo2Hp007634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FsPl4-0007Zm-3w; Mon, 19 Jun 2006 15:50:02 -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-sha2-dsa-ecdsa-00.txt Message-Id: Date: Mon, 19 Jun 2006 15:50:02 -0400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: -2.6 (--) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA Author(s) : Q. Dang, et al. Filename : draft-ietf-pkix-sha2-dsa-ecdsa-00.txt Pages : Date : 2006-6-19 This document supplements RFC 3279. It specifies algorithm identifiers, and ASN.1 encoding rules for the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures when using SHA-224, SHA-256, 384 or SHA-512 as hashing algorithm. This specification applies to the Internet X.509 Public Key Infrastructure (PKI) when digital signatures are used to sign certificates and certificate revocation list (CRLs). The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha2-dsa-ecdsa-00.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-sha2-dsa-ecdsa-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-sha2-dsa-ecdsa-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-19134118.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-sha2-dsa-ecdsa-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-sha2-dsa-ecdsa-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-19134118.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix@mail.imc.org Mon Jun 19 20:20:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTyv-0003O3-EV for pkix-archive@lists.ietf.org; Mon, 19 Jun 2006 20:20:37 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsTyu-0007E9-St for pkix-archive@lists.ietf.org; Mon, 19 Jun 2006 20:20:37 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5JNBWkZ089463; Mon, 19 Jun 2006 16:11:32 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5JNBWCZ089462; Mon, 19 Jun 2006 16:11:32 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp102.biz.mail.re2.yahoo.com (smtp102.biz.mail.re2.yahoo.com [68.142.229.216]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k5JNBVaj089447 for ; Mon, 19 Jun 2006 16:11:31 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 10786 invoked from network); 19 Jun 2006 23:11:26 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@70.17.105.223 with login) by smtp102.biz.mail.re2.yahoo.com with SMTP; 19 Jun 2006 23:11:25 -0000 Reply-To: From: "Turner, Sean P." To: Subject: RE: I-D ACTION:draft-ietf-pkix-sha2-dsa-ecdsa-00.txt Date: Mon, 19 Jun 2006 19:10:58 -0400 Organization: IECA, Inc. Message-ID: <003401c693f5$a0039de0$0301a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaT4IUABkN6z3lrQc+Oiw9MAORuagADOfjA Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 A couple of comments: General: What is the relationship of this and the ECC PKALGS ID? Is the text that is common going to be removed? Is the other ID dead (it has expired but it's not clear that it won't be resurrected)? Is another draft being prepared for the Key Agreement Schemes? Keys/Parameters: The document only addresses the signatureAlgorithm/signatureVale/signature fields and points to RFC3279 for the ECDSA Public Key Encodings...but it seems like there ought to be an explicit indication of the algorithm the key can be used with in the subjectPublicKeyInfo field along with its parameters? They do this with DSA/RSA why not with ECDSA? Specific Sec 3 1st para last sentence: r field/fields Sec 3 4th para last sentence: r should/SHOULD Sec 3.1 1st para 2nd sentence r SHA2/SHA-2 Sec 3.2 bullets 1, 2, 3: r may/MAY Sec 3.2.1 1st para: r SHA 512/SHA512 spt -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, June 19, 2006 3:50 PM To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org Subject: I-D ACTION:draft-ietf-pkix-sha2-dsa-ecdsa-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA Author(s) : Q. Dang, et al. Filename : draft-ietf-pkix-sha2-dsa-ecdsa-00.txt Pages : Date : 2006-6-19 This document supplements RFC 3279. It specifies algorithm identifiers, and ASN.1 encoding rules for the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures when using SHA-224, SHA-256, 384 or SHA-512 as hashing algorithm. This specification applies to the Internet X.509 Public Key Infrastructure (PKI) when digital signatures are used to sign certificates and certificate revocation list (CRLs). The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha2-dsa-ecdsa-00.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-sha2-dsa-ecdsa-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-sha2-dsa-ecdsa-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-ietf-pkix@mail.imc.org Tue Jun 20 05:56:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fscy6-0004q2-UN for pkix-archive@lists.ietf.org; Tue, 20 Jun 2006 05:56:23 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fscy5-00080c-JZ for pkix-archive@lists.ietf.org; Tue, 20 Jun 2006 05:56:22 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5K8k5pS099958; Tue, 20 Jun 2006 01:46:05 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5K8k5rT099957; Tue, 20 Jun 2006 01:46:05 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from srv1.int.stroeder.com (60-17-124-83.dsl.3u.net [83.124.17.60]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5K8k3F2099927 for ; Tue, 20 Jun 2006 01:46:04 -0700 (MST) (envelope-from michael@stroeder.com) Received: from localhost (localhost [127.0.0.1]) by srv1.int.stroeder.com (Postfix) with ESMTP id D3F6C4166 for ; Tue, 20 Jun 2006 10:45: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 27429-08 for ; Tue, 20 Jun 2006 10:44:31 +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 did not present a certificate) by srv1.int.stroeder.com (Postfix) with ESMTP id B45734163 for ; Tue, 20 Jun 2006 10:44:30 +0200 (CEST) Message-ID: <4497B56B.6080500@stroeder.com> Date: Tue, 20 Jun 2006 10:44:27 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-03.txt References: In-Reply-To: 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: X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Reference to RFC 2253 should be updated since it was obsoleted by RFC 4514 recently. Ciao, Michael. 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 : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile > Author(s) : D. Cooper, et al. > Filename : draft-ietf-pkix-rfc3280bis-03.txt > Pages : 141 > Date : 2006-5-24 From owner-ietf-pkix@mail.imc.org Tue Jun 20 09:24:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsgDk-0005hW-8D for pkix-archive@lists.ietf.org; Tue, 20 Jun 2006 09:24:44 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsgDj-0008J9-Az for pkix-archive@lists.ietf.org; Tue, 20 Jun 2006 09:24:44 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5KCMxIS039828; Tue, 20 Jun 2006 05:22:59 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5KCMxdY039827; Tue, 20 Jun 2006 05:22:59 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5KCMv2K039812 for ; Tue, 20 Jun 2006 05:22:57 -0700 (MST) (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); Tue, 20 Jun 2006 13:22:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69464.4267ACF2" Subject: PKXIX draft agenda Date: Tue, 20 Jun 2006 13:22:55 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PKXIX draft agenda thread-index: AcaT9zRONeDYsIOCRrmh/diZJYCbnQAZ+Ybg From: "Stefan Santesson" To: Cc: "Stephen Kent" X-OriginalArrivalTime: 20 Jun 2006 12:22:56.0365 (UTC) FILETIME=[42B841D0:01C69464] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: f27aa5169a850f4f07ecb12d54c20028 This is a multi-part message in MIME format. ------_=_NextPart_001_01C69464.4267ACF2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 Here is the draft PKIX agenda for the 66th IETF. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =20 =20 --------------------------------------------- =20 PKIX WG (pkix-wg) http://ietf.org/html.charters/pkix-charter.html =20 =20 MONDAY, July 10, 2006 1520-1720 (Room 519b) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 CHAIR: Stephen Kent , Stefan Santesson =20 AGENDA: =20 1. WG Status and Direction =20 1.1 Document Status Review (5 min.) Stefan Santesson (WG co-chair) =20 Some WG documents are with the Ads, some are in RFC editors queue=20 and a few are still within the WG development process. (10 min.) =20 2. PKIX WG Specifications=20 =20 2.1 Simple Certificate Validation Protocol (SCVP) (10 min.) David Cooper (NIST) http://ietf.org/internet-drafts/draft-ietf-pkix-scvp-25.txt =20 This document is in AD evaluation state with some final issues still under discussion =20 2.2 3280bis (15 min.) David Cooper (NIST) =20 http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt =20 A new draft 03 was recently posted and WG last call has been initiated. =20 2.3 Algorithm IDs for Elliptic Curve Cryptography in PKIX (10 min.) Daniel Brown (Certicom) =20 http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-pkalgs-02.txt =20 Some issues concerning algorithm identifiers are yet to be determined =20 2.5 Subject Identification Method (SIM) [Agneda item not decided yet] (5 min.) Tim Polk (NIST) http://ietf.org/internet-drafts/draft-ietf-pkix-sim-07.txt =20 Past IETF last Call. A new draft is requested by IESG. =20 2.6 Additional Algorithms and Identifiers for DSA and ECDSA (5 min.) Tim Polk (NIST) =20 http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha2-dsa-ecdsa-00.tx t =20 A new -00 draft has just been posted. =20 =20 3. Related Specifications & Liaison Presentations =20 Time allowing, liaison presentations will be accommodated to ensure the PKIX WG is aware of related specifications currently progressing as individual drafts. =20 3.1 Including the AIA extension in attribute certificates (10 min) David Chadwick (University of Kent) =20 A presentation about including the AIA extension in attribute certificates,=20 and the requirement to find the superior AA of the AC issuer, as well as the=20 signing certificate of the issuer of the AC =20 =20 4. Joint PKIX/SIDR Meeting http://ietf.org/html.charters/sidr-charter.html =20 4.1 Address Space & As Number PKI (60 min.) Stephen Kent (BBN) =20 This presentation will review the current plans and status for creating a PKI that reflects the allocation of resources through Regional Internet Registries. The motivation for creation this PKI is to enable better security for Internet routing (BGP). =20 =20 =20 =20 ------_=_NextPart_001_01C69464.4267ACF2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

Here is the draft PKIX agenda for = the 66th IETF.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

 

 

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

 

PKIX WG = (pkix-wg)

http://ietf.org/= html.charters/pkix-charter.html

 

 

MONDAY, July 10, 2006 1520-1720 (Room = 519b)

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

 

CHAIR: Stephen Kent <kent@bbn.com>, = Stefan Santesson <stefans@microsoft.com>

 

AGENDA:

 

1. WG Status and = Direction

 

1.1 Document Status Review (5 = min.)

      Stefan = Santesson (WG co-chair)

 

      Some WG = documents are with the Ads, some are in RFC editors queue =

      and a few are = still within the WG development process. (10 = min.)

 

2. PKIX WG = Specifications

 

  2.1 Simple Certificate Validation Protocol (SCVP) (10 min.)

      David Cooper = (NIST)

        htt= p://ietf.org/internet-drafts/draft-ietf-pkix-scvp-25.txt

 

      This document = is in AD evaluation state with some final issues still under = discussion

 

  2.2 3280bis (15 = min.)

      David Cooper = (NIST)

        http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt<= o:p>

 

      A new draft 03 = was recently posted and WG last call has been = initiated.

 

  2.3 Algorithm IDs for Elliptic Curve Cryptography in PKIX (10 min.)

     Daniel Brown = (Certicom)

       http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-pkalgs-02.= txt

 

     Some issues = concerning algorithm identifiers are yet to be determined

 

  2.5 Subject Identification Method = (SIM) [Agneda item not decided yet] (5 min.)

      Tim Polk = (NIST)

        http= ://ietf.org/internet-drafts/draft-ietf-pkix-sim-07.txt

 

      Past IETF last = Call. A new draft is requested by IESG.

 

  2.6 Additional Algorithms and = Identifiers for DSA and ECDSA (5 min.)

      Tim Polk = (NIST)

       http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha2-dsa-ec= dsa-00.txt

 

     A new -00 draft = has just been posted.

 

 

3. Related Specifications & Liaison = Presentations

 

      Time allowing, liaison presentations will be accommodated to ensure = the

      PKIX WG is = aware of related specifications currently progressing = as

      individual = drafts.

 

  3.1 Including the AIA extension in = attribute certificates (10 min)

      David Chadwick = (University of = Kent)

 

      A presentation = about including the AIA extension in attribute certificates, =

      and the = requirement to find the superior AA of the AC issuer, as well as the =

      signing = certificate of the issuer of the AC

 

 

4. Joint PKIX/SIDR = Meeting

   http://ietf.org/= html.charters/sidr-charter.html

 

  4.1 Address Space & As Number = PKI (60 min.)

      Stephen Kent = (BBN)

 

     This = presentation will review the current plans and status for creating a = PKI

     that reflects the allocation of resources through Regional Internet = Registries.

     The motivation for = creation this PKI is to enable better security for = Internet

     routing = (BGP).

 

 

 

 

------_=_NextPart_001_01C69464.4267ACF2-- From owner-ietf-pkix@mail.imc.org Tue Jun 20 20:29:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsqb7-0003xY-5O for pkix-archive@lists.ietf.org; Tue, 20 Jun 2006 20:29:33 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsqb5-00035d-Pi for pkix-archive@lists.ietf.org; Tue, 20 Jun 2006 20:29:33 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5KNV91j075511; Tue, 20 Jun 2006 16:31:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5KNV9cb075510; Tue, 20 Jun 2006 16:31:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5KNV8SF075503 for ; Tue, 20 Jun 2006 16:31:08 -0700 (MST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (24-205-218-53.dhcp.crcy.nv.charter.com [24.205.218.53] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id k5KNV781069208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jun 2006 23:31:07 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <7.0.1.0.0.20060620160757.0414c9d0@OpenLDAP.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 20 Jun 2006 16:31:02 -0700 To: Michael Ströder From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-03.txt Cc: ietf-pkix@imc.org In-Reply-To: <4497B56B.6080500@stroeder.com> References: <4497B56B.6080500@stroeder.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 balder-227.proper.com id k5KNV91j075511 X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 At 01:44 AM 6/20/2006, Michael Str=F6der wrote: >Reference to RFC 2253 should be updated since it >was obsoleted by RFC 4514 recently. In the same vein... The document's reference to RFC 2247 should be replaced with a reference RFC 4419. RFC 4419 replaces that portion of RFC 2247 referenced. The document's reference to draft-ietf-ldapbis-strprep-07.txt should be updated to RFC 4518. The document's reference to RFC 2255 should be replaced with RFC 4516. THe document's reference to RFC 2587 should be replaced with RFC 4523. The document's reference to RFC 1778 should be removed (not used). The document's reference to RFC 2252 should be replaced with RFC 4512, which now specifies the syntax. The document's reference to RFC 2279 should be replaced with a reference to RFC 3629. Regarding the included ASN.1 modules, it might be appropriate to add a copyright comment, e.g.: -- Copyright (C) The Internet Society (2006). This version of =20 -- this ASN.1 module is part of RFC XXXX; see the RFC itself =20 -- for full legal notices. >Ciao, Michael. > >Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >> This draft is a work item of the Public-Key Infrastructure (X.509) Wor= king Group of the IETF. >>=20 >> Title : Internet X.509 Public Key Infrastructure Certi= ficate and Certificate Revocation List (CRL) Profile >> Author(s) : D. Cooper, et al. >> Filename : draft-ietf-pkix-rfc3280bis-03.txt >> Pages : 141 >> Date : 2006-5-24 From owner-ietf-pkix@mail.imc.org Wed Jun 21 12:33:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft5dm-0004is-3m for pkix-archive@lists.ietf.org; Wed, 21 Jun 2006 12:33:18 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft5dl-0005kx-LE for pkix-archive@lists.ietf.org; Wed, 21 Jun 2006 12:33:18 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5LFBC2t098753; Wed, 21 Jun 2006 08:11:12 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5LFBBXE098747; Wed, 21 Jun 2006 08:11:11 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp106.biz.mail.re2.yahoo.com (smtp106.biz.mail.re2.yahoo.com [206.190.52.175]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k5LFBACi098716 for ; Wed, 21 Jun 2006 08:11:10 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 17028 invoked from network); 21 Jun 2006 15:11:04 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@70.17.105.223 with login) by smtp106.biz.mail.re2.yahoo.com with SMTP; 21 Jun 2006 15:11:04 -0000 Reply-To: From: "Turner, Sean P." To: Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-03.txt Date: Wed, 21 Jun 2006 11:10:28 -0400 Organization: IECA, Inc. Message-ID: <02e701c69544$d53fc9c0$0301a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaVRNSF7z4+d1M7Q42pTFUyTJy++g== Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Comments as follows (r=replace): 1. Abstract: To the sentence beginning with "The X.509 v3 CRL format is described in detail," add "an Internet specific extension is defined,". AIA is an internet specific extension. 2. Sec 1 para 7 last sentence: replace a conforming certificate/conforming certificates. There are three cert examples in Appendix C. 3. Sec 1 last *, Sec 8, and Sec 10: r RFC 2510/RFC 4210 4. Sec 4 1st para last sentence: remove required to support a PKI. All of the internet defined extensions are optional so they can't be required to support a PKI for the internet community. 5. Sec 4.1.2.4 last para penultimate and last sentence: r section 7.1/section 7.1 and 7.3. 7.3 needs to be added as issuer names can be expressed using the domainComponent attribute. 6. Sec 4.2.1.2: Can we suggest using something other than SHA-1 for key id generation? How about striking SHA-1 from the methods and adding the new sentence to both: The hash algorithm employed can be the same algorithm paired with the signature algorithm (e.g., SHA-1, SHA-256, SHA-384). 7. Sec 4.2.1.6/4.1.2.6: The 2nd paragraph of 4.2.1.6 points out that since the SAN is bound to the public key that the CA MUST verify the each part of the SAN. I think a similar statement ought to be added to the subject section (4.1.2.6) to indicate that "All parts of the subject name MUST be verified by the CA as it is bound to the public key". 8. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT impose name constraints on ediPartyName or registeredID but the 14th para (the one before the ASN.1) indicates that ediPartyName and registeredId are not defined in this spec but MAY be defined in another spec. Sounds to me like it would be hard to convince a customer that you could write a name constraints that can ever be 3280bis compliant since whatever you wrote MUST NOT be imposed/implemented. It's not clear that the name constraints shouldn't be imposed because they're not defined in the spec or whether they should never ever be imposed. 9. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT impose name constraints on x400Address name forms but the last sentence in the 10th para last says X400Address MUST be applied to x.400 addresses. See #8. 10. Sec 4.2.2.1 4th to last para: r HTTP or LDAP URI/HTTP [RFC 1738] or LDAP [RFC 2255] URI. Makes it consistent with AIA in CRL section. 11. Sec 4.2.2.2 3rd to last para: r HTTP or LDAP URI/HTTP [RFC 1738] or LDAP [RFC 2255] URI. Makes it consistent with AIA sections. 12. Sec 5 3rd to last para: r This profile does not define any private Internet CRL extensions or CRL entry extensions/This profiles defines one CRL extension and no CRL entry extensions. AIA is defined in this spec. 13. Sec 5.2.5 8th para (one before the ASN.1): The sentence about the onlyContainsAttributeCerts seems to hang. Recommend adding "In either case" to the beginning of the sentence to address the case when either onlyContainsUserCerts or onlyContainsCACerts is set to TRUE. Additionally, recommend adding the following for completeness as a new last paragraph: "If the scope of the CRL only includes attribute certificates then the onlyContainsAttributeCerts MUST be set to TRUE and both onlyContainsUserCerts and onlyContainsCACerts MUST be set to FALSE." 14. Sec 5.2.7: Remove ASN.1. It's already referenced in the 1st para, duplication leads to errors, and the other sections that reused ASN.1 from certificate sections did not duplicate the ASN.1 (see AKI/IAN). 15. Sec 5.3.1: Can we add an ASN.1 comment to say the enumerated value #7 is never used? 16. Sec 4.2.1.6 1st para: r These identities may be included in addition to or in the place of the identity/These identities may be included in addition to or in the place of, in the case of non-CAs, the identity. The paragraph mixes SAN and IAN, but assumed the 2nd sentence addressed SAN. 17. Sec 4.2.1.6: Add the following to clarify that there is no dependency in this spec between SAN and IAN: This specification places no requirement on CAs, whose certificate includes Issuer Alterative name, to include Subject Alternative names in certificates issued by the CA. 18. Sec 4.2.1.7: Add the following three sentences to be explicit about the checks not made: Issuer Alternative names are not constrained by name constraints. If a CA certificate has a Subject Alternative name, the specification does not require CAs to populate the Issuer Alternative name in certificates issued by the CA. Further, the chain of Issuer Alternative and Subject Alternative names, as is done with issuer and subject names, is not checked during the certificate path validation algorithm in section 6. 19. Sec 5.2.2: Add the following: Issuer Alternative names are not constrained by name constraints. If a CA certificate has a Subject Alternative name, this specification does not require CAs to populate the Issuer Alternative name in CRLs issued by the CA. Feel free to wordsmith any of the suggested text. spt From owner-ietf-pkix@mail.imc.org Wed Jun 21 18:30:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtBDQ-0002oX-R6 for pkix-archive@lists.ietf.org; Wed, 21 Jun 2006 18:30:28 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtBDQ-0004Py-0V for pkix-archive@lists.ietf.org; Wed, 21 Jun 2006 18:30:28 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5LLN2ow006867; Wed, 21 Jun 2006 14:23:02 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5LLN2jN006866; Wed, 21 Jun 2006 14:23:02 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5LLN0EY006837 for ; Wed, 21 Jun 2006 14:23:00 -0700 (MST) (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, 21 Jun 2006 22:22:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69578.DB4D2429" Subject: RE: last call for 3280bis - escape clause Date: Wed, 21 Jun 2006 22:22:53 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: last call for 3280bis - escape clause thread-index: AcaRi3NPpHbHqjJkRuqLU85fpb+OdADywY5Q From: "Stefan Santesson" To: Cc: "Stephen Kent" X-OriginalArrivalTime: 21 Jun 2006 21:22:54.0165 (UTC) FILETIME=[DBB9F850:01C69578] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4a96669441ad70ecf6aebb4b47b971cd This is a multi-part message in MIME format. ------_=_NextPart_001_01C69578.DB4D2429 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As a last call comment on RFC 3280bis I would like to raise the question whether RFC 3280bis should include an escape clause clearly allowing relying parties to select what validation logic they deploy on certificate validation. =20 The background is the fact that many deployed PKIs are misconfigured.2 One such common misconfiguration is assignment of certificate policies and their inclusion in CA certificates. X.509 path processing requires policies in CA certificates to reflect the list of EE certificate policies that are valid for a path. Yet many deployments have included pure CA certificate policies in CA certificates, policies that are not included in any EE certificates and as such, policy processing is not possible in such PKIs. =20 Application wanting to use certificate policies in such PKI are simply forced to either fail or selectively neglect certain path processing rules. For a relying party such modification could be reasonable if the security implications has been well though through. However it is not clear if an implementation allowing such local configuration could be regarded as standard compliant. =20 There are more examples where deploying applications in misconfigured PKIs would need similar measures to work. =20 The pki4ipsec WG recently came to this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX WG. =20 The result was that the pki4ipsec profile included an escape clause as follows: =20 4.1. X.509 Certificates =20 Users deploying IKE and IPsec with certificates have often had little control over the capabilities of CAs available to them. Implementations of this specification may include configuration knobs to disable checks required by this specification in order to permit use with inflexible and/or noncompliant CAs. However, all checks on certificates exist for a specific reason involving the security of the entire system. Therefore, all checks MUST be enabled by default. Administrators and users ought to understand the security purpose for the various checks, and be clear on what security will be lost by disabling the check. =20 =20 I'm basically asking if RFC 3280bis path validation needs a similar escape clause or corresponding clarification that clearly allows local configuration of the validation logic. At least I think it is necessary to clearly allow such configuration of standards compliant applications as long as this is not the default functionality. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: den 16 juni 2006 22:42 To: ietf-pkix@imc.org Subject: last call for 3280bis =20 Folks, =20 Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt ) =20 The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th. =20 Steve ------_=_NextPart_001_01C69578.DB4D2429 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable last call for 3280bis

As a last call comment on RFC = 3280bis I would like to raise the question whether RFC 3280bis should include an = escape clause clearly allowing relying parties to select what validation logic = they deploy on certificate validation.

 

The background is the fact that = many deployed PKIs are misconfigured.2

One such common misconfiguration is assignment of certificate policies and their inclusion in CA = certificates.

X.509 path processing requires = policies in CA certificates to reflect the list of EE certificate policies that are = valid for a path. Yet many deployments have included pure CA certificate = policies in CA certificates, policies that are not included in any EE certificates = and as such, policy processing is not possible in such = PKIs.

 

Application wanting to use = certificate policies in such PKI are simply forced to either fail or selectively = neglect certain path processing rules. For a relying party such modification = could be reasonable if the security implications has been well though = through.

However it is not clear if an implementation allowing such local configuration could be regarded as = standard compliant.

 

There are more examples where = deploying applications in misconfigured PKIs would need similar measures to = work.

 

The pki4ipsec WG recently came to = this conclusion in their PKI profile and this lead to an intense debate which included = core participants from the PKIX WG.

 

The result was that the pki4ipsec = profile included an escape clause as follows:

 

4.1.  X.509 =
Certificates
 
   Users deploying IKE and IPsec =
with certificates have often had =
little
   control over the capabilities of =
CAs available to them.
   Implementations of this =
specification may include configuration =
knobs
   to disable checks required by =
this specification in order to =
permit
   use with inflexible and/or =
noncompliant CAs.  However, all checks =
on
   certificates exist for a =
specific reason involving the security =
of
   the entire system.  =
Therefore, all checks MUST be enabled by =
default.
   Administrators and users ought =
to understand the security purpose =
for
   the various checks, and be clear =
on what security will be lost =
by
   disabling the =
check.

 

 

I’m basically asking if RFC = 3280bis path validation needs a similar escape clause or corresponding = clarification that clearly allows local configuration of the validation = logic.

At least I think it is necessary to = clearly allow such configuration of standards compliant applications as long as = this is not the default functionality.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Stephen Kent
Sent: den 16 juni 2006 = 22:42
To: ietf-pkix@imc.org
Subject: last call for = 3280bis

 

Folks,

 

Based on the latest message from David Cooper, I am initiating = last call on "Internet X.509 Public Key Infrastructure, Certificate and = Certificate Revocation List (CRL) Profile" = (http://ietf.org/internet-drafts/draft-ietf-pki= x-rfc3280bis-03.txt)

 

The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many = folks), all comments must be received by July 5th.

 

Steve

------_=_NextPart_001_01C69578.DB4D2429-- From owner-ietf-pkix@mail.imc.org Thu Jun 22 03:40:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtJnq-0005Sj-JG for pkix-archive@lists.ietf.org; Thu, 22 Jun 2006 03:40:38 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtJnp-0000PF-6a for pkix-archive@lists.ietf.org; Thu, 22 Jun 2006 03:40:38 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5M6dWLT052137; Wed, 21 Jun 2006 23:39:32 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5M6dW19052136; Wed, 21 Jun 2006 23:39:32 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5M6dVUJ052130 for ; Wed, 21 Jun 2006 23:39:31 -0700 (MST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (24-205-218-53.dhcp.crcy.nv.charter.com [24.205.218.53] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id k5M6dUTj062145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 22 Jun 2006 06:39:30 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <7.0.1.0.0.20060621232234.0422a5d8@OpenLDAP.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 21 Jun 2006 23:39:58 -0700 To: ietf-pkix@imc.org From: "Kurt D. Zeilenga" Subject: stringprep in 3280bis In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 For various values, this I-D discusses how strings are to be prepared using various profiles of the StringPrep algorithm. However, the I-D fails to discuss whether the strings should be prepared as "stored" or "query" strings (see Section 4 of RFC 3490). The I-D should be revised so as to be clear which strings are to be treated as "stored" strings and which are to be treated as "query" strings. Off the cuff, I suspect the right thing to do is: 1) requiring each prepared string in a certificate/CRL be treated as "stored", and 2) prepared strings to be compared against prepared strings in a certificate/CRL to be treated as either "query" or "stored". This assures that each comparison between prepared strings involves at least one "stored" string. -- Kurt At 01:42 PM 6/16/2006, Stephen Kent wrote: >Folks, > >Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt) > >The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th. > >Steve From owner-ietf-pkix@mail.imc.org Thu Jun 22 09:49:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtPZF-00029L-Hy for pkix-archive@lists.ietf.org; Thu, 22 Jun 2006 09:49:57 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtPZE-0005rr-0C for pkix-archive@lists.ietf.org; Thu, 22 Jun 2006 09:49:57 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MCqUGK031868; Thu, 22 Jun 2006 05:52:30 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MCqUcf031867; Thu, 22 Jun 2006 05:52:30 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MCqSuq031849 for ; Thu, 22 Jun 2006 05:52:29 -0700 (MST) (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, 22 Jun 2006 13:52:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C695FA.B565663B" Subject: RE: last call for 3280bis - references Date: Thu, 22 Jun 2006 13:52:22 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: last call for 3280bis - references thread-index: AcaRi3NPpHbHqjJkRuqLU85fpb+OdAEbxWwQ From: "Stefan Santesson" To: "Stephen Kent" , X-OriginalArrivalTime: 22 Jun 2006 12:52:24.0838 (UTC) FILETIME=[B5A35260:01C695FA] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 This is a multi-part message in MIME format. ------_=_NextPart_001_01C695FA.B565663B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In general we need a work through of the reference section to get the references up to date. =20 Stefan Santesson Senior Program Manager Windows Security, Standards ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: den 16 juni 2006 22:42 To: ietf-pkix@imc.org Subject: last call for 3280bis =20 Folks, =20 Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt ) =20 The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th. =20 Steve ------_=_NextPart_001_01C695FA.B565663B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable last call for 3280bis

In general we need a work through = of the reference section to get the references up to = date.

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Stephen Kent
Sent: den 16 juni 2006 = 22:42
To: ietf-pkix@imc.org
Subject: last call for = 3280bis

 

Folks,

 

Based on the latest message from David Cooper, I am initiating = last call on "Internet X.509 Public Key Infrastructure, Certificate and = Certificate Revocation List (CRL) Profile" = (http://ietf.org/internet-drafts/draft-ietf-pki= x-rfc3280bis-03.txt)

 

The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many = folks), all comments must be received by July 5th.

 

Steve

------_=_NextPart_001_01C695FA.B565663B-- From owner-ietf-pkix@mail.imc.org Thu Jun 22 11:26:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtR4i-0000Di-Mq for pkix-archive@lists.ietf.org; Thu, 22 Jun 2006 11:26:32 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtR4e-0001rZ-6c for pkix-archive@lists.ietf.org; Thu, 22 Jun 2006 11:26:32 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MEUiIZ054214; Thu, 22 Jun 2006 07:30:44 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MEUiZa054213; Thu, 22 Jun 2006 07:30:44 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from csexchange1.corestreet.com (host200.58.41.216.conversent.net [216.41.58.200]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MEUh9C054176 for ; Thu, 22 Jun 2006 07:30:43 -0700 (MST) (envelope-from shitchings@corestreet.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: draft-ietf-pkix-scvp-26.txt Date: Thu, 22 Jun 2006 10:30:33 -0400 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0AB8_01C695E6.E4331ED0" Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-pkix-scvp-26.txt Thread-Index: AcaRfvKveO66k8aZRGyMmcjJ6nlwlgEiVwPA From: "Seth Hitchings" To: "David A. Cooper" , "pkix" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.1 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 This is a multi-part message in MIME format. ------=_NextPart_000_0AB8_01C695E6.E4331ED0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Should the CMS reference in section 11.1 be updated to RFC 3852? -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of David A. Cooper Sent: Friday, June 16, 2006 3:38 PM To: pkix Subject: draft-ietf-pkix-scvp-26.txt All, I have just submitted draft 26 of SCVP for posting. The draft should be available soon, but in the meantime, I have posted a diff file highlighting the differences between drafts 24 and 26 (the only difference between drafts 24 and 25 was the correction of a typographical error in section 3.6). The diff file is available at http://csrc.nist.gov/pki/documents/PKIX/wdiff_draft-ietf-pkix-scvp-24_to_26. html. Drafts 24 and 26 differ in the following places: 1) Section 3: corrected cross-reference ("3.10" replaced by "3.11"). 2) Section 3.2.4.2.3 (Name Validation Algorithm): Matching rules for use with id-kp-serverAuth are now specified in the document rather than referring to the matching rules in RFC 2818 [HTTP-TLS]. (RFC 2818 is an Informational RFC and so SCVP could not include a normative reference to that document). 3) Section 3.6: "requestorName" replaced with "responderName". (This was the typographical error that was corrected in draft 25.) 4) Section 4: A new sentence was added to clarify that when a protected response is required, the SCVP server must use SignedData or AuthenticatedData even if the response is being sent over a protected transport (e.g., TLS). 5) Section 11.1 (Normative References): The reference to RFC 2818 was deleted. None of these changes to the document result in any changes to the protocol. Dave ------=_NextPart_000_0AB8_01C695E6.E4331ED0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIVzCCAoIw ggHroAMCAQICAQQwDQYJKoZIhvcNAQEEBQAwUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0VxdWlm YXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0xMB4X DTk5MDYyMTA0MDAwMFoXDTIwMDYyMTA0MDAwMFowUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0Vx dWlmYXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0x MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOLxm8F7d33pOpX1oNF080GgyY9CLZWdTEaEbw tDXFhQMgxq9FpSFRRUHrFlg2Mm/iUGJk+f1RnKok2fSdgyqHCiHTEjg0bI0Ablqg2ULuGiGV+VJM VVrFDzhPRvpt+C411h186+LwsHWAyKkTrL6I7zpuq18qOGICsBJ7/o+mAwIDAQABo2YwZDARBglg hkgBhvhCAQEEBAMCAAcwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRKeDJSEdtZFjZe38EU NkBqR3xMoTAdBgNVHQ4EFgQUSngyUhHbWRY2Xt/BFDZAakd8TKEwDQYJKoZIhvcNAQEEBQADgYEA dVuomwMR5ulWTM35qUzADZrzzGVp5iV2zFm31lTDHc2ZrBndtIXV4D38YiCnhEtYZfHi+ZUhP/XU flgeR4dUPlihtbX4Ku9x57zD9rFJRuLXoGvlVnqaJ5h8RmIU58n8bgMSeYA4HUiCjfwX/iqWK7Vi pqY9vX+SWc1aKoKyN3kwggK8MIICJaADAgECAgIA2DANBgkqhkiG9w0BAQUFADBTMQswCQYDVQQG EwJVUzEcMBoGA1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1 cmUgZUJ1c2luZXNzIENBLTEwHhcNMDQwNjAyMTk1NzQyWhcNMjAwNjIxMDQwMDAwWjBSMQswCQYD VQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENl cnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr0HhHsWZ2xkS 6BbojMXvdGPoRJLcAs2nUBSZ6XnJvnHxBwVvRUkqrCSBwKBurhjqGqe3oOxh6tC6wUuGhwLdhyWT BSYO469PJUx02lyiohqUZ8u0yshCL35/lA+MkZubcmFxHsLlTPCkS/+A7PZwzIjKrLAUT0VmwNTL TYEg1F8CAwEAAaOBnzCBnDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFNjsf5MYxWYDwxBsPAT2 d4U+/wu2MB8GA1UdIwQYMBaAFEp4MlIR21kWNl7fwRQ2QGpHfEyhMA8GA1UdEwEB/wQFMAMBAf8w OQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5nZW90cnVzdC5jb20vY3Jscy9lYml6Y2ExLmNy bDANBgkqhkiG9w0BAQUFAAOBgQDCHD9PBDwPPDktSLC/jRpe9Crdpj8Cj7GB1od44j1D+5IJji+w rhuJ3tlR3p5MlzXGUEj8eFBtZymYBiWdLvIVqwMz2nYWBeFWXou6T+n4akcF708jM3MhFXP82ove f/xJzw9IzlVmI9DjDrkL2wXXw/IR5XTP2iQYPcbxento6zCCAw0wggJ2oAMCAQICAXwwDQYJKoZI hvcNAQEFBQAwUjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEpMCcGA1UE AxMgQ29yZVN0cmVldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDUwODI5MTQyNTQwWhcNMDYw OTEyMTQyNTQwWjBqMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMRcwFQYD VQQDEw5TZXRoIEhpdGNoaW5nczEoMCYGCSqGSIb3DQEJARYZc2hpdGNoaW5nc0Bjb3Jlc3RyZWV0 LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzZOhlCd/KDWl33RR6dW+YKFd8Kof1Uz8 9wJ3EevLEK73npZfKDj66mL6fQOL1Cv1RaQrucsm8ZB2bMvUDRvoeC1Te4xsHvxNyV8AoEbxYWsK QciJCNM5bd6kkpfgummUBCgUs7nze+FNhIzWGerlMUjcc37diSOD+FP24WXU+zUCAwEAAaOB2jCB 1zAOBgNVHQ8BAf8EBAMCBeAwPAYDVR0fBDUwMzAxoC+gLYYraHR0cDovL2NybC5nZW90cnVzdC5j b20vY3Jscy9jb3Jlc3RyZWV0LmNybDAkBgNVHREEHTAbgRlzaGl0Y2hpbmdzQGNvcmVzdHJlZXQu Y29tMB8GA1UdIwQYMBaAFNjsf5MYxWYDwxBsPAT2d4U+/wu2MEAGCCsGAQUFBwEBBDQwMjAwBggr BgEFBQcwAYYkaHR0cDovL2dlb3RydXN0LW9jc3AuY29yZXN0cmVldC5jb20vMA0GCSqGSIb3DQEB BQUAA4GBAHPT6HnJxaWD8+WdUL//eXEekqR0rio7r2OdTJ4VSrWZQRHMkWmOzG8aPvgGX7SMh0QZ TvcSBNY7h43m5fPNk7Jaxy+F3LbdwHu02NM/IiUBsLyn8XXi03Xekni5PT6aDuP/Egux3nnlKjej mMjDOVTNBwKwF/QfjP+QViQTO6hoMYICmTCCApUCAQEwVzBSMQswCQYDVQQGEwJVUzEYMBYGA1UE ChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENlcnRpZmljYXRlIEF1dGhv cml0eQIBfDAJBgUrDgMCGgUAoIIBmDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wNjA2MjIxNDMwMzNaMCMGCSqGSIb3DQEJBDEWBBQtWddj/xhrUQO1v6jY5Q4kqZJc STBmBgkrBgEEAYI3EAQxWTBXMFIxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9Db3JlU3RyZWV0IEx0 ZC4xKTAnBgNVBAMTIENvcmVTdHJlZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AgF8MGcGCSqGSIb3 DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO AwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMGgGCyqGSIb3DQEJEAILMVmg VzBSMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3Jl U3RyZWV0IENlcnRpZmljYXRlIEF1dGhvcml0eQIBfDANBgkqhkiG9w0BAQEFAASBgH1TCj1VuI07 8+CN5yRAxYcc8qlNy7o9wqd3yPaigGJyYSuStaeOog+1ElheaWUMnp/iNf9EjLvv8w6bqwvN1WWg YhPUDaoR9yoF7/k/fdl4G/FvRE62N2hWNs/fbIAi70hLJjQJCGd4OMbHrJ0rYXNZ16hvpbb74pPT ftihee9+AAAAAAAA ------=_NextPart_000_0AB8_01C695E6.E4331ED0-- From owner-ietf-pkix@mail.imc.org Thu Jun 22 14:55:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtUKb-0005Ff-Hi for pkix-archive@lists.ietf.org; Thu, 22 Jun 2006 14:55:09 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtUKa-0000x2-Kj for pkix-archive@lists.ietf.org; Thu, 22 Jun 2006 14:55:09 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MHv9q0006884; Thu, 22 Jun 2006 10:57:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MHv9eN006883; Thu, 22 Jun 2006 10:57:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sottsym2.entrust.com (sottsym2.entrust.com [216.191.252.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MHv8Bc006854 for ; Thu, 22 Jun 2006 10:57:08 -0700 (MST) (envelope-from sharon.boeyen@entrust.com) Received: from sottmxsecs3.entrust.com (unknown [216.191.252.14]) by sottsym2.entrust.com (Symantec Mail Security) with SMTP id 10202240002 for ; Thu, 22 Jun 2006 13:57:02 -0400 (EDT) Received: (qmail 26259 invoked from network); 22 Jun 2006 17:57:01 -0000 Received: from sharon.boeyen@entrust.com by sottmxsecs3.entrust.com with EntrustECS-Server-7.4;22 Jun 2006 17:57:01 -0000 Received: from sottmxs00.entrust.com (10.4.61.22) by sottmxsecs3.entrust.com with SMTP; 22 Jun 2006 17:57:00 -0000 Received: by sottmxs00.entrust.com with Internet Mail Service (5.5.2657.72) id ; Thu, 22 Jun 2006 13:57:01 -0400 Message-ID: <7A3E1242FA9989439AD1F9B2D71C287F09EAD1B2@sottmxs05.entrust.com> From: Sharon Boeyen To: "'Stefan Santesson'" , ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause Date: Thu, 22 Jun 2006 13:56:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69624.D29D3652" X-Brightmail-Tracker: AAAAAA== Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: abb8110dde048486ea2be9c769692569 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C69624.D29D3652 Content-Type: text/plain Stefan, if I understand your comment correctly I strongly believe such an escape clause cannot possibly be added because this would render 3280bis non-compliant with X.509. My understanding of your comment is that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found in EE certificates. Is that a correct understanding? If it is a correct understanding, then any such implementation is non-conformant to X.509. 3280 is a profile of X.509 and as such can mandate certain optional elements or exclude optional elements but cannot reverse the mandatory processing from X.509. Apologies if I've misunderstood your question. Cheers, Sharon -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Wednesday, June 21, 2006 5:23 PM To: ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause As a last call comment on RFC 3280bis I would like to raise the question whether RFC 3280bis should include an escape clause clearly allowing relying parties to select what validation logic they deploy on certificate validation. The background is the fact that many deployed PKIs are misconfigured.2 One such common misconfiguration is assignment of certificate policies and their inclusion in CA certificates. X.509 path processing requires policies in CA certificates to reflect the list of EE certificate policies that are valid for a path. Yet many deployments have included pure CA certificate policies in CA certificates, policies that are not included in any EE certificates and as such, policy processing is not possible in such PKIs. Application wanting to use certificate policies in such PKI are simply forced to either fail or selectively neglect certain path processing rules. For a relying party such modification could be reasonable if the security implications has been well though through. However it is not clear if an implementation allowing such local configuration could be regarded as standard compliant. There are more examples where deploying applications in misconfigured PKIs would need similar measures to work. The pki4ipsec WG recently came to this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX WG. The result was that the pki4ipsec profile included an escape clause as follows: 4.1. X.509 Certificates Users deploying IKE and IPsec with certificates have often had little control over the capabilities of CAs available to them. Implementations of this specification may include configuration knobs to disable checks required by this specification in order to permit use with inflexible and/or noncompliant CAs. However, all checks on certificates exist for a specific reason involving the security of the entire system. Therefore, all checks MUST be enabled by default. Administrators and users ought to understand the security purpose for the various checks, and be clear on what security will be lost by disabling the check. I'm basically asking if RFC 3280bis path validation needs a similar escape clause or corresponding clarification that clearly allows local configuration of the validation logic. At least I think it is necessary to clearly allow such configuration of standards compliant applications as long as this is not the default functionality. Stefan Santesson Senior Program Manager Windows Security, Standards _____ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: den 16 juni 2006 22:42 To: ietf-pkix@imc.org Subject: last call for 3280bis Folks, Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" ( http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt) The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th. Steve ------_=_NextPart_001_01C69624.D29D3652 Content-Type: text/html Message
Stefan, if I understand your comment correctly I strongly believe such an escape clause cannot possibly be added because this would render 3280bis non-compliant with X.509.
 
My understanding of your comment is that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found in EE certificates. Is that a correct understanding?
 
If it is a correct understanding, then any such implementation is non-conformant to X.509. 3280 is a profile of X.509 and as such can mandate certain optional elements or exclude optional elements but cannot reverse the mandatory processing from X.509.
 
Apologies if I've misunderstood your question.
 
Cheers,
Sharon
-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson
Sent: Wednesday, June 21, 2006 5:23 PM
To: ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call for 3280bis - escape clause

As a last call comment on RFC 3280bis I would like to raise the question whether RFC 3280bis should include an escape clause clearly allowing relying parties to select what validation logic they deploy on certificate validation.

 

The background is the fact that many deployed PKIs are misconfigured.2

One such common misconfiguration is assignment of certificate policies and their inclusion in CA certificates.

X.509 path processing requires policies in CA certificates to reflect the list of EE certificate policies that are valid for a path. Yet many deployments have included pure CA certificate policies in CA certificates, policies that are not included in any EE certificates and as such, policy processing is not possible in such PKIs.

 

Application wanting to use certificate policies in such PKI are simply forced to either fail or selectively neglect certain path processing rules. For a relying party such modification could be reasonable if the security implications has been well though through.

However it is not clear if an implementation allowing such local configuration could be regarded as standard compliant.

 

There are more examples where deploying applications in misconfigured PKIs would need similar measures to work.

 

The pki4ipsec WG recently came to this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX WG.

 

The result was that the pki4ipsec profile included an escape clause as follows:

 

4.1.  X.509 Certificates
 
   Users deploying IKE and IPsec with certificates have often had little
   control over the capabilities of CAs available to them.
   Implementations of this specification may include configuration knobs
   to disable checks required by this specification in order t
 o permit
   use with inflexible and/or noncompliant CAs.  However, all checks on
   certificates exist for a specific reason involving the security of
   the entire system.  Therefore, all checks MUST be enabled by default.
   Administrators and users ought to understand the security purpose for
   the various checks, and be clear on what security will be lost by
   disabling the check.

 

 

I'm basically asking if RFC 3280bis path validation needs a similar escape clause or corresponding clarification that clearly allows local configuration of the validation logic.

At least I think it is necessary to clearly allow such configuration of standards compliant applications as long as this is not the default functionality.

 

 

Stefan Santesson

Senior Program Manager

Windows Security, Standards

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent
Sent: den 16 juni 2006 22:42
To: ietf-pkix@imc.org
Subject: last call for 3280bis

 

Folks,

 

Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt)

 

The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th.

 

Steve

------_=_NextPart_001_01C69624.D29D3652-- From owner-ietf-pkix@mail.imc.org Thu Jun 22 15:16:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtUfN-0007BY-Vv for pkix-archive@lists.ietf.org; Thu, 22 Jun 2006 15:16:37 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtUfM-0000IL-Kc for pkix-archive@lists.ietf.org; Thu, 22 Jun 2006 15:16:37 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MIW2AL015867; Thu, 22 Jun 2006 11:32:02 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MIW2E7015866; Thu, 22 Jun 2006 11:32:02 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MIW1k2015847 for ; Thu, 22 Jun 2006 11:32:02 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k5MIVtNr002537; Thu, 22 Jun 2006 14:31:56 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.6/8.13.6) with ESMTP id k5MIVh7Q004261; Thu, 22 Jun 2006 14:31:43 -0400 (EDT) Message-ID: <449AE234.6060303@nist.gov> Date: Thu, 22 Jun 2006 14:32:20 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Seth Hitchings CC: pkix Subject: Re: draft-ietf-pkix-scvp-26.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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Seth Hitchings wrote: >Should the CMS reference in section 11.1 be updated to RFC 3852? > > Seth, Yes. I believe that the [CMS] reference should be updated from 3369 to 3852. Also, the [UTF8] reference should be updated from 2279 to 3629 and the [IKE] reference should be updated from 2409 to 4306. Updating the [UTF8] and [IKE] should only affect the References section. Updating the [CMS] reference will also require changing the ASN.1 in section 8 so that ContentInfo is imported from the CryptographicMessageSyntax2004 module rather than the CryptographicMessageSyntax, but I don't think that should cause any problems. Dave From owner-ietf-pkix@mail.imc.org Thu Jun 22 15:19:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtUiW-0008QM-J4 for pkix-archive@lists.ietf.org; Thu, 22 Jun 2006 15:19:52 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtUiT-0001Qi-Tf for pkix-archive@lists.ietf.org; Thu, 22 Jun 2006 15:19:52 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MIV3Ts015703; Thu, 22 Jun 2006 11:31:03 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MIV2Ds015702; Thu, 22 Jun 2006 11:31:02 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from imx2.tcd.ie (imx2.tcd.ie [134.226.1.156]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MIV1NV015673 for ; Thu, 22 Jun 2006 11:31:02 -0700 (MST) (envelope-from stephen.farrell@cs.tcd.ie) Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id AF4C06807D; Thu, 22 Jun 2006 19:30:55 +0100 (IST) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A05076A3367; Thu, 22 Jun 2006 19:30:55 +0100 Received: from [134.226.144.16] (unknown [134.226.144.16]) by imx2.tcd.ie (Postfix) with ESMTP id 847E16807D; Thu, 22 Jun 2006 19:30:55 +0100 (IST) Message-ID: <449AE1F9.6010007@cs.tcd.ie> Date: Thu, 22 Jun 2006 19:31:21 +0100 From: Stephen Farrell User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Sharon Boeyen Cc: "'Stefan Santesson'" , ietf-pkix@imc.org Subject: Re: last call for 3280bis - escape clause References: <7A3E1242FA9989439AD1F9B2D71C287F09EAD1B2@sottmxs05.entrust.com> In-Reply-To: <7A3E1242FA9989439AD1F9B2D71C287F09EAD1B2@sottmxs05.entrust.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A15076A3367 X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.56.3 VDF=8.1230) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.1 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 I guess I'd agree with Sharon's conclusion but for slightly different reasons. If people need such a different profile of x.509 or 3280bis then a different RFC is required IMO - given that 3280 exists it would be wrong for 3280bis to include such a change since you'd potentially punish 3280 implementers for being compliant. Stephen. Sharon Boeyen wrote: > Stefan, if I understand your comment correctly I strongly believe such > an escape clause cannot possibly be added because this would render > 3280bis non-compliant with X.509. > > My understanding of your comment is that the escape clause would enable > a path validation engine to process the certificate policy OIDs found in > CA certificates but ignore those found in EE certificates. Is that a > correct understanding? > > If it is a correct understanding, then any such implementation is > non-conformant to X.509. 3280 is a profile of X.509 and as such can > mandate certain optional elements or exclude optional elements but > cannot reverse the mandatory processing from X.509. > > Apologies if I've misunderstood your question. > > Cheers, > Sharon > > -----Original Message----- > *From:* owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] *On Behalf Of *Stefan Santesson > *Sent:* Wednesday, June 21, 2006 5:23 PM > *To:* ietf-pkix@imc.org > *Cc:* Stephen Kent > *Subject:* RE: last call for 3280bis - escape clause > > As a last call comment on RFC 3280bis I would like to raise the > question whether RFC 3280bis should include an escape clause clearly > allowing relying parties to select what validation logic they deploy > on certificate validation. > > > > The background is the fact that many deployed PKIs are misconfigured.2 > > One such common misconfiguration is assignment of certificate > policies and their inclusion in CA certificates. > > X.509 path processing requires policies in CA certificates to > reflect the list of EE certificate policies that are valid for a > path. Yet many deployments have included pure CA certificate > policies in CA certificates, policies that are not included in any > EE certificates and as such, policy processing is not possible in > such PKIs. > > > > Application wanting to use certificate policies in such PKI are > simply forced to either fail or selectively neglect certain path > processing rules. For a relying party such modification could be > reasonable if the security implications has been well though through. > > However it is not clear if an implementation allowing such local > configuration could be regarded as standard compliant. > > > > There are more examples where deploying applications in > misconfigured PKIs would need similar measures to work. > > > > The pki4ipsec WG recently came to this conclusion in their PKI > profile and this lead to an intense debate which included core > participants from the PKIX WG. > > > > The result was that the pki4ipsec profile included an escape clause > as follows: > > > > 4.1. X.509 Certificates > > > > Users deploying IKE and IPsec with certificates have often had little > > control over the capabilities of CAs available to them. > > Implementations of this specification may include configuration knobs > > to disable checks required by this specification in order t > o permit > > use with inflexible and/or noncompliant CAs. However, all checks on > > certificates exist for a specific reason involving the security of > > the entire system. Therefore, all checks MUST be enabled by default. > > Administrators and users ought to understand the security purpose for > > the various checks, and be clear on what security will be lost by > > disabling the check. > > > > > > I'm basically asking if RFC 3280bis path validation needs a similar > escape clause or corresponding clarification that clearly allows > local configuration of the validation logic. > > At least I think it is necessary to clearly allow such configuration > of standards compliant applications as long as this is not the > default functionality. > > > > > > **Stefan Santesson** > > Senior Program Manager > > **Windows Security, Standards** > > ------------------------------------------------------------------------ > > *From:* owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] *On Behalf Of *Stephen Kent > *Sent:* den 16 juni 2006 22:42 > *To:* ietf-pkix@imc.org > *Subject:* last call for 3280bis > > > > Folks, > > > > Based on the latest message from David Cooper, I am initiating last > call on "Internet X.509 Public Key Infrastructure, Certificate and > Certificate Revocation List (CRL) Profile" > (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt) > > > > The last call will last for two weeks. In deference to the U.S. > Independence Dya holiday (which means July 3rd is a holiday for many > folks), all comments must be received by July 5th. > > > > Steve > From owner-ietf-pkix@mail.imc.org Thu Jun 22 15:34:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtUwr-0003tu-Ql for pkix-archive@lists.ietf.org; Thu, 22 Jun 2006 15:34:41 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtUwq-00036x-SS for pkix-archive@lists.ietf.org; Thu, 22 Jun 2006 15:34:41 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MImdSa019852; Thu, 22 Jun 2006 11:48:39 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MImdJ6019851; Thu, 22 Jun 2006 11:48:39 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from ncsusraimge01.jnj.com (ncsusraimge01.jnj.com [148.177.2.21]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MImcx2019827 for ; Thu, 22 Jun 2006 11:48:38 -0700 (MST) (envelope-from RGuida@CORUS.JNJ.com) Received: from ncsusrawsa2.na.jnj.com ([10.4.21.2]) by ncsusraimge01.jnj.com (Switch-3.1.8/Switch-3.1.7) with SMTP id k5MIm87C010502; Thu, 22 Jun 2006 14:48:09 -0400 (EDT) Received: from (10.4.20.168) by ncsusrawsa2.na.jnj.com via smtp id 2901_8ebc393a_0221_11db_8f25_0002b3ec9bcc; Thu, 22 Jun 2006 15:01:48 -0400 Received: by NCSUSRAEXIMS1.na.jnj.com with Internet Mail Service (5.5.2658.3) id ; Thu, 22 Jun 2006 14:48:08 -0400 Message-ID: <8C9266D8DEC7B3439D3A49E5706844100AFAB931@jjcusnbexs4.na.jnj.com> From: "Guida, Richard [JJCUS]" To: Sharon Boeyen , "'Stefan Santesson'" , ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause Date: Thu, 22 Jun 2006 14:48:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.3) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6962C.6413C4C6" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.3 (/) X-Scan-Signature: 32604d42645517c44d778f1d111b40a6 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C6962C.6413C4C6 Content-Type: text/plain Stefan - perhaps I am missing something, but there is nothing that stops a relying party from writing software that would perform processing extensions only on CA certs as you propose. As Sharon properly notes, that would not be RFC3280 compliant - but a relying party can choose to be non-compliant if it wishes. And such non-compliance only puts the relying party at risk, not others - so that is a "good thing" relatively speaking. But in the final analysis, seems to me that Sharon is absolutely correct (assuming she and I are interpreting your proposal properly) - unless X.509 is redefined, this would remain a circumstance of non-compliance. And so it should be treated as such. Very best regards -- Rich Richard A. Guida Director, Information Security Johnson & Johnson Room GS8217 410 George Street New Brunswick, New Jersey 08901 Phone: 732 524 3785 -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon Boeyen Sent: Thursday, June 22, 2006 1:57 PM To: 'Stefan Santesson'; ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause Stefan, if I understand your comment correctly I strongly believe such an escape clause cannot possibly be added because this would render 3280bis non-compliant with X.509. My understanding of your comment is that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found in EE certificates. Is that a correct understanding? If it is a correct understanding, then any such implementation is non-conformant to X.509. 3280 is a profile of X.509 and as such can mandate certain optional elements or exclude optional elements but cannot reverse the mandatory processing from X.509. Apologies if I've misunderstood your question. Cheers, Sharon -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Wednesday, June 21, 2006 5:23 PM To: ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause As a last call comment on RFC 3280bis I would like to raise the question whether RFC 3280bis should include an escape clause clearly allowing relying parties to select what validation logic they deploy on certificate validation. The background is the fact that many deployed PKIs are misconfigured.2 One such common misconfiguration is assignment of certificate policies and their inclusion in CA certificates. X.509 path processing requires policies in CA certificates to reflect the list of EE certificate policies that are valid for a path. Yet many deployments have included pure CA certificate policies in CA certificates, policies that are not included in any EE certificates and as such, policy processing is not possible in such PKIs. Application wanting to use certificate policies in such PKI are simply forced to either fail or selectively neglect certain path processing rules. For a relying party such modification could be reasonable if the security implications has been well though through. However it is not clear if an implementation allowing such local configuration could be regarded as standard compliant. There are more examples where deploying applications in misconfigured PKIs would need similar measures to work. The pki4ipsec WG recently came to this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX WG. The result was that the pki4ipsec profile included an escape clause as follows: 4.1. X.509 Certificates Users deploying IKE and IPsec with certificates have often had little control over the capabilities of CAs available to them. Implementations of this specification may include configuration knobs to disable checks required by this specification in order t o permit use with inflexible and/or noncompliant CAs. However, all checks on certificates exist for a specific reason involving the security of the entire system. Therefore, all checks MUST be enabled by default. Administrators and users ought to understand the security purpose for the various checks, and be clear on what security will be lost by disabling the check. I'm basically asking if RFC 3280bis path validation needs a similar escape clause or corresponding clarification that clearly allows local configuration of the validation logic. At least I think it is necessary to clearly allow such configuration of standards compliant applications as long as this is not the default functionality. Stefan Santesson Senior Program Manager Windows Security, Standards _____ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: den 16 juni 2006 22:42 To: ietf-pkix@imc.org Subject: last call for 3280bis Folks, Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" ( http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt) The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th. Steve ------_=_NextPart_001_01C6962C.6413C4C6 Content-Type: text/html Message
Stefan - perhaps I am missing something, but there is nothing that stops a relying party from writing software that would perform processing extensions only on CA certs as you propose.  As Sharon properly notes, that would not be RFC3280 compliant - but a relying party can choose to be non-compliant if it wishes.  And such non-compliance only puts the relying party at risk, not others - so that is a "good thing" relatively speaking.  But in the final analysis, seems to me that Sharon is absolutely correct (assuming she and I are interpreting your proposal properly) - unless X.509 is redefined, this would remain a circumstance of non-compliance.  And so it should be treated as such.  Very best regards -- Rich
 
 

Richard A. Guida
Director, Information Security

Johnson & Johnson
Room GS8217
410 George Street
New Brunswick, New Jersey  08901
Phone:  732 524 3785

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon Boeyen
Sent: Thursday, June 22, 2006 1:57 PM
To: 'Stefan Santesson'; ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call for 3280bis - escape clause

Stefan, if I understand your comment correctly I strongly believe such an escape clause cannot possibly be added because this would render 3280bis non-compliant with X.509.
 
My understanding of your comment is that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found in EE certificates. Is that a correct understanding?
 
If it is a correct understanding, then any such implementation is non-conformant to X.509. 3280 is a profile of X.509 and as such can mandate certain optional elements or exclude optional elements but cannot reverse the mandatory processing from X.509.
 
Apologies if I've misunderstood your question.
 
Cheers,
Sharon
-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson
Sent: Wednesday, June 21, 2006 5:23 PM
To: ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call for 3280bis - escape clause

As a last call comment on RFC 3280bis I would like to raise the question whether RFC 3280bis should include an escape clause clearly allowing relying parties to select what validation logic they deploy on certificate validation.

 

The background is the fact that many deployed PKIs are misconfigured.2

One such common misconfiguration is assignment of certificate policies and their inclusion in CA certificates.

X.509 path processing requires policies in CA certificates to reflect the list of EE certificate policies that are valid for a path. Yet many deployments have included pure CA certificate policies in CA certificates, policies that are not included in any EE certificates and as such, policy processing is not possible in such PKIs.

 

Application wanting to use certificate policies in such PKI are simply forced to either fail or selectively neglect certain path processing rules. For a relying party such modification could be reasonable if the security implications has been well though through.

However it is not clear if an implementation allowing such local configuration could be regarded as standard compliant.

 

There are more examples where deploying applications in misconfigured PKIs would need similar measures to work.

 

The pki4ipsec WG recently came to this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX WG.

 

The result was that the pki4ipsec profile included an escape clause as follows:

 

4.1.  X.509 Certificates
 
   Users deploying IKE and IPsec with certificates have often had little
   control over the capabilities of CAs available to them.
   Implementations of this specification may include configuration knobs
   to disable checks required by this specification in orde!
 r t
 o permit
   use with inflexible and/or noncompliant CAs.  However, all checks on
   certificates exist for a specific reason involving the security of
   the entire system.  Therefore, all checks MUST be enabled by default.
   Administrators and users ought to understand the security purpose for
   the various checks, and be clear on what security will be lost by
   disabling the check.

 

 

I'm basically asking if RFC 3280bis path validation needs a similar escape clause or corresponding clarification that clearly allows local configuration of the validation logic.

At least I think it is necessary to clearly allow such configuration of standards compliant applications as long as this is not the default functionality.

 

 

Stefan Santesson

Senior Program Manager

Windows Security, Standards

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent
Sent: den 16 juni 2006 22:42
To: ietf-pkix@imc.org
Subject: last call for 3280bis

 

Folks,

 

Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt)

 

The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th.

 

Steve

------_=_NextPart_001_01C6962C.6413C4C6-- From owner-ietf-pkix@mail.imc.org Thu Jun 22 17:52:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtX6V-0008JT-S7 for pkix-archive@lists.ietf.org; Thu, 22 Jun 2006 17:52:48 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtX6U-0000YT-Np for pkix-archive@lists.ietf.org; Thu, 22 Jun 2006 17:52:47 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MKwe5t051373; Thu, 22 Jun 2006 13:58:40 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MKwegx051372; Thu, 22 Jun 2006 13:58:40 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MKwdiS051342 for ; Thu, 22 Jun 2006 13:58:39 -0700 (MST) (envelope-from chokhani@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6963F.1D4C93BD" Subject: RE: last call for 3280bis - escape clause Date: Thu, 22 Jun 2006 13:58:32 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C8790359D724@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: last call for 3280bis - escape clause Thread-Index: AcaWNVMoloaBo6PDT0CPPD74liD0jQAB/dsA From: "Santosh Chokhani" To: Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.3 (/) X-Scan-Signature: 73c195f10d656c831652e7a62eeeaf5a This is a multi-part message in MIME format. ------_=_NextPart_001_01C6963F.1D4C93BD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stefan, =20 I agree with sentiments voiced by Steve, Rich, and Sharon. =20 I have a simple solution to your concern from the relying party viewpoint. This observation is made with a long-held view of mine (and no one had provided a convincing logical or business argument) that the require explicit policy setting is a useless field. A relying party can always set acceptable policies to none. In that scenario, (require explicit policy) flag not withstanding, path validation will succeed. Now, the user can examine the end certificate policy. =20 You and I have had this discussion in another context. The basic premise is that if some field in the last certificate only is of interest and the "state" in the path validation process does not impact it, that need not be path of path validation engine. =20 Thus, you can judiciously use the 3280 Engine and obtain the result you seek. ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Guida, Richard [JJCUS] Sent: Thursday, June 22, 2006 2:48 PM To: Sharon Boeyen; 'Stefan Santesson'; ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause =20 Stefan - perhaps I am missing something, but there is nothing that stops a relying party from writing software that would perform processing extensions only on CA certs as you propose. As Sharon properly notes, that would not be RFC3280 compliant - but a relying party can choose to be non-compliant if it wishes. And such non-compliance only puts the relying party at risk, not others - so that is a "good thing" relatively speaking. But in the final analysis, seems to me that Sharon is absolutely correct (assuming she and I are interpreting your proposal properly) - unless X.509 is redefined, this would remain a circumstance of non-compliance. And so it should be treated as such. Very best regards -- Rich =20 =20 =20 Richard A. Guida=20 Director, Information Security=20 Johnson & Johnson=20 Room GS8217=20 410 George Street=20 New Brunswick, New Jersey 08901=20 Phone: 732 524 3785=20 -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon Boeyen Sent: Thursday, June 22, 2006 1:57 PM To: 'Stefan Santesson'; ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause Stefan, if I understand your comment correctly I strongly believe such an escape clause cannot possibly be added because this would render 3280bis non-compliant with X.509.=20 =20 My understanding of your comment is that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found in EE certificates. Is that a correct understanding?=20 =20 If it is a correct understanding, then any such implementation is non-conformant to X.509. 3280 is a profile of X.509 and as such can mandate certain optional elements or exclude optional elements but cannot reverse the mandatory processing from X.509. =20 Apologies if I've misunderstood your question. =20 Cheers, Sharon -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Wednesday, June 21, 2006 5:23 PM To: ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause As a last call comment on RFC 3280bis I would like to raise the question whether RFC 3280bis should include an escape clause clearly allowing relying parties to select what validation logic they deploy on certificate validation. =20 The background is the fact that many deployed PKIs are misconfigured.2 One such common misconfiguration is assignment of certificate policies and their inclusion in CA certificates. X.509 path processing requires policies in CA certificates to reflect the list of EE certificate policies that are valid for a path. Yet many deployments have included pure CA certificate policies in CA certificates, policies that are not included in any EE certificates and as such, policy processing is not possible in such PKIs. =20 Application wanting to use certificate policies in such PKI are simply forced to either fail or selectively neglect certain path processing rules. For a relying party such modification could be reasonable if the security implications has been well though through. However it is not clear if an implementation allowing such local configuration could be regarded as standard compliant. =20 There are more examples where deploying applications in misconfigured PKIs would need similar measures to work. =20 The pki4ipsec WG recently came to this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX WG. =20 The result was that the pki4ipsec profile included an escape clause as follows: =20 4.1. X.509 Certificates =20 Users deploying IKE and IPsec with certificates have often had little control over the capabilities of CAs available to them. Implementations of this specification may include configuration knobs to disable checks required by this specification in orde! r t o permit use with inflexible and/or noncompliant CAs. However, all checks on certificates exist for a specific reason involving the security of the entire system. Therefore, all checks MUST be enabled by default. Administrators and users ought to understand the security purpose for the various checks, and be clear on what security will be lost by disabling the check. =20 =20 I'm basically asking if RFC 3280bis path validation needs a similar escape clause or corresponding clarification that clearly allows local configuration of the validation logic. At least I think it is necessary to clearly allow such configuration of standards compliant applications as long as this is not the default functionality. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =09 ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: den 16 juni 2006 22:42 To: ietf-pkix@imc.org Subject: last call for 3280bis =20 Folks, =20 Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt ) =20 The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th. =20 Steve ------_=_NextPart_001_01C6963F.1D4C93BD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Stefan,

=

 

I agree with sentiments voiced by = Steve, Rich, and Sharon.

 

I have a simple solution to your = concern from the relying party viewpoint.  This observation is made with a long-held view of mine (and no one had provided a convincing logical or business argument) that the require explicit policy setting is a useless = field.  A relying party can always set acceptable policies to none. =  In that scenario, (require explicit policy) flag not withstanding, path = validation will succeed.  Now, the user can examine the end certificate = policy.

 

You and I have had this discussion = in another context.  The basic premise is that if some field in the = last certificate only is of interest and the “state” in the path validation process does not impact it, that need not be path of path = validation engine.

 

Thus, you can judiciously use the = 3280 Engine and obtain the result you seek.

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Guida, Richard = [JJCUS]
Sent: Thursday, June 22, = 2006 2:48 PM
To: Sharon Boeyen; = 'Stefan Santesson'; ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

 

Stefan - perhaps I am missing = something, but there is nothing that stops a relying party from writing software = that would perform processing extensions only on CA certs as you = propose.  As Sharon properly notes, that would not be RFC3280 compliant - but a relying = party can choose to be non-compliant if it wishes.  And such non-compliance = only puts the relying party at risk, not others - so that is a = "good thing" relatively speaking.  But in the final analysis, seems = to me that Sharon is absolutely correct (assuming she and I are interpreting your proposal properly) - unless X.509 is redefined, this would remain a = circumstance of non-compliance.  And so it should be treated as such.  = Very best regards -- Rich

 

 

 

Richard A. Guida
Director, Information Security =

Johnson & = Johnson
Room GS8217
410 George Street
New Brunswick, = New Jersey  08901
Phone:  732 524 3785

-----Original = Message-----
From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon Boeyen
Sent: Thursday, June 22, = 2006 1:57 PM
To: 'Stefan Santesson'; ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

Stefan, if I understand your = comment correctly I strongly believe such an escape clause cannot possibly be added = because this would render 3280bis non-compliant with X.509. =

 

My understanding of your comment is = that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found = in EE certificates. Is that a correct understanding? =

 

If it is a correct understanding, = then any such implementation is non-conformant to X.509. 3280 is a profile of = X.509 and as such can mandate certain optional elements or exclude optional = elements but cannot reverse the mandatory processing from = X.509.

 

Apologies if I've misunderstood = your question.

 

Cheers,

=

Sharon

-----Original = Message-----
From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson
Sent: Wednesday, June 21, = 2006 5:23 PM
To: ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

As a last call comment on RFC = 3280bis I would like to raise the question whether RFC 3280bis should include an = escape clause clearly allowing relying parties to select what validation logic = they deploy on certificate validation.

 

The background is the fact that = many deployed PKIs are misconfigured.2

One such common misconfiguration is assignment of certificate policies and their inclusion in CA = certificates.

X.509 path processing requires = policies in CA certificates to reflect the list of EE certificate policies that are = valid for a path. Yet many deployments have included pure CA certificate = policies in CA certificates, policies that are not included in any EE certificates = and as such, policy processing is not possible in such = PKIs.

 

Application wanting to use = certificate policies in such PKI are simply forced to either fail or selectively = neglect certain path processing rules. For a relying party such modification = could be reasonable if the security implications has been well though = through.

However it is not clear if an implementation allowing such local configuration could be regarded as = standard compliant.

 

There are more examples where = deploying applications in misconfigured PKIs would need similar measures to = work.

 

The pki4ipsec WG recently came to = this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX = WG.

 

The result was that the pki4ipsec = profile included an escape clause as follows:

 

4.1.  X.509 =
Certificates
 
   Users deploying IKE and IPsec =
with certificates have often had =
little
   control over the capabilities of =
CAs available to them.
   Implementations of this =
specification may include configuration =
knobs
   to disable checks required by =
this specification in orde!
 r =
t
 o =
permit
   use with inflexible and/or =
noncompliant CAs.  However, all checks =
on
   certificates exist for a =
specific reason involving the security =
of
   the entire system.  =
Therefore, all checks MUST be enabled by =
default.
   Administrators and users ought =
to understand the security purpose =
for
   the various checks, and be clear =
on what security will be lost =
by
   disabling the =
check.

 

 

I'm basically asking if RFC 3280bis = path validation needs a similar escape clause or corresponding clarification = that clearly allows local configuration of the validation = logic.

At least I think it is necessary to clearly allow such configuration of standards compliant applications as = long as this is not the default functionality.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Stephen Kent
Sent: den 16 juni 2006 = 22:42
To: ietf-pkix@imc.org
Subject: last call for = 3280bis

 

Folks,

 

Based on the latest message from David Cooper, I am initiating = last call on = "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation = List (CRL) Profile" (http://ietf.org/internet-drafts/draft-ietf-pki= x-rfc3280bis-03.txt)

 

The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many = folks), all comments must be received by July 5th.

 

Steve

------_=_NextPart_001_01C6963F.1D4C93BD-- From owner-ietf-pkix@mail.imc.org Thu Jun 22 18:42:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtXsJ-0001o1-LL for pkix-archive@lists.ietf.org; Thu, 22 Jun 2006 18:42:11 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtXsI-0002dK-5q for pkix-archive@lists.ietf.org; Thu, 22 Jun 2006 18:42:11 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MLq9fZ064809; Thu, 22 Jun 2006 14:52:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MLq9C7064808; Thu, 22 Jun 2006 14:52:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MLq8rC064801 for ; Thu, 22 Jun 2006 14:52:08 -0700 (MST) (envelope-from tim.polk@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k5MLpv3O017927; Thu, 22 Jun 2006 17:51:57 -0400 Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.13.6/8.13.6) with ESMTP id k5MLpHrc004380; Thu, 22 Jun 2006 17:51:18 -0400 (EDT) Message-Id: <5.1.0.14.2.20060622102208.02f3ffb0@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 22 Jun 2006 17:52:56 -0400 To: "Kurt D. Zeilenga" , ietf-pkix@imc.org From: Tim Polk Subject: Re: stringprep in 3280bis In-Reply-To: <7.0.1.0.0.20060621232234.0422a5d8@OpenLDAP.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Kurt, To be fair, the I-D does address stored strings in a couple of places, although we may have missed a reference. Please review the quotes below, along with a couple of alternatives for one update, to see if we have it right... Section 7.2 of this I-D includes the following text: >To accommodate > internationalized domain names in the current structure, conforming > implementations MUST convert internationalized domain names to the > ASCII Compatible Encoding (ACE) format as specified in section 4 of > RFC 3490 before storage in the dNSName field. Specifically, > conforming implementations MUST perform the conversion operation > specified in section 4 of RFC 3490 as follows: > > * in step 1, the domain name SHALL be considered a "stored > string"; (additional steps deleted) Sections 7.5 includes a reference to the text in 7.2. From 7.5: > Where the host-part (the domain of the addr-spec) contains an > internationalized name, the domain name MUST be converted from an IDN > to the ASCII Compatible Encoding (ACE) format as specified in section > 7.2. > > Two email addresses are considered to match if: > > 1) the local-part of each name is an exact match, AND > 2) the host-part of each name matches using a case-insensitive > ASCII comparison. I am probably missing some nuance, but this would seem to be sufficient for sections 7.2 and 7.5. In section 7.3, we did not specify "stored" versus "query", because it does not seem to apply. In this section 7.3, the domain component attribute contains only a single label, so we only perform the "ToASCII" operation. >To represent a label from an IDN in the distinguished > name, the implementation MUST perform the "ToASCII" label conversion > specified in section 4.1 of RFC 3490. As I said, the "ToASCII" operation doesn't seem to care about "stored" versus "query" so we didn't specify it. However, the "ToASCII" operation does require specification of two additional inputs: the AllowUnassigned flag, and the UseSTD3ASCIIRules flag. We dropped the ball here. We should have specified that the UseSTD3ASCIIRules flag should be set, and that AllowUassigned flag is *not* set. (That works out to be the same as "stored" anyway, doesn't it?) (1) How about the following revision to that sentence in 7.3: To represent a label from an IDN in the distinguished name, the implementation MUST perform the "ToASCII" label conversion specified in section 4.1 of RFC 3490, where the STD3ASCIIRules flag is set but AllowUnassigned flag is not set. (2) If I misinterpreted the specification of "ToASCII", and we do need to specify "stored" vs. "query", we could use this alternate text: To represent a label from an IDN in the distinguished name, the implementation MUST perform the "ToASCII" label conversion specified in section 4.1 of RFC 3490, where the string preparation is performed as a "stored" string. Am I correct that 7.2 and 7.5 are okay? What do you think of the alternatives for 7.3? Thanks, Tim At 11:39 PM 6/21/2006 -0700, Kurt D. Zeilenga wrote: >For various values, this I-D discusses how strings are to be >prepared using various profiles of the StringPrep algorithm. >However, the I-D fails to discuss whether the strings should >be prepared as "stored" or "query" strings (see Section 4 >of RFC 3490). The I-D should be revised so as to be clear >which strings are to be treated as "stored" strings and which >are to be treated as "query" strings. > >Off the cuff, I suspect the right thing to do is: > 1) requiring each prepared string in a certificate/CRL be > treated as "stored", and > 2) prepared strings to be compared against prepared strings > in a certificate/CRL to be treated as either "query" or "stored". >This assures that each comparison between prepared strings >involves at least one "stored" string. > >-- Kurt > >At 01:42 PM 6/16/2006, Stephen Kent wrote: > >Folks, > > > >Based on the latest message from David Cooper, I am initiating last call > on "Internet X.509 Public Key Infrastructure, Certificate and Certificate > Revocation List (CRL) Profile" > (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt) > > > >The last call will last for two weeks. In deference to the U.S. > Independence Dya holiday (which means July 3rd is a holiday for many > folks), all comments must be received by July 5th. > > > >Steve From owner-ietf-pkix@mail.imc.org Thu Jun 22 18:49:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtXzL-0003d3-04 for pkix-archive@lists.ietf.org; Thu, 22 Jun 2006 18:49:27 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtXzJ-0003Eb-Rx for pkix-archive@lists.ietf.org; Thu, 22 Jun 2006 18:49:26 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MM4Afg067280; Thu, 22 Jun 2006 15:04:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MM4ABT067279; Thu, 22 Jun 2006 15:04:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MM48wG067236 for ; Thu, 22 Jun 2006 15:04:09 -0700 (MST) (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, 22 Jun 2006 23:04:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69647.C3E2A6F5" Subject: RE: last call for 3280bis - escape clause Date: Thu, 22 Jun 2006 23:03:58 +0100 Message-ID: In-Reply-To: <8C9266D8DEC7B3439D3A49E5706844100AFAB931@jjcusnbexs4.na.jnj.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: last call for 3280bis - escape clause thread-index: AcaWLJScwSTyVxSgTKS7ldtF72iXKAAGcqWw From: "Stefan Santesson" To: "Guida, Richard [JJCUS]" , "Sharon Boeyen" , Cc: "Stephen Kent" X-OriginalArrivalTime: 22 Jun 2006 22:04:00.0569 (UTC) FILETIME=[C43B1A90:01C69647] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.3 (/) X-Scan-Signature: 99e9171ba9600a19593168acf7232900 This is a multi-part message in MIME format. ------_=_NextPart_001_01C69647.C3E2A6F5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think my initial statement was a bit misinterpreted. =20 I suggest no changes to RFC 3280 path processing. And of course, skipping mandatory checks would make the path processing non-conformant. =20 However. I have noticed that it is not clear to some people weather a conformant implementation are forced to always do conformant path processing, or if a conformant implementation can allow administrators to turn of certain checking. =20 What I say is mainly two things; 1) Misconfigured PKIs may sometimes force relying parties to do non conformant path processing or fail altogether. 2) A conformant implementation should be allowed to support also non-conformant processing as long as this is not the default behavior. =20 I think this is already allowed, but some implementers may not read it that way and therefore I'm asking if we should add a clarification like pki4ipsec did. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards ________________________________ From: Guida, Richard [JJCUS] [mailto:RGuida@CORUS.JNJ.com]=20 Sent: den 22 juni 2006 20:48 To: Sharon Boeyen; Stefan Santesson; ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause =20 Stefan - perhaps I am missing something, but there is nothing that stops a relying party from writing software that would perform processing extensions only on CA certs as you propose. As Sharon properly notes, that would not be RFC3280 compliant - but a relying party can choose to be non-compliant if it wishes. And such non-compliance only puts the relying party at risk, not others - so that is a "good thing" relatively speaking. But in the final analysis, seems to me that Sharon is absolutely correct (assuming she and I are interpreting your proposal properly) - unless X.509 is redefined, this would remain a circumstance of non-compliance. And so it should be treated as such. Very best regards -- Rich =20 =20 =20 Richard A. Guida=20 Director, Information Security=20 Johnson & Johnson=20 Room GS8217=20 410 George Street=20 New Brunswick, New Jersey 08901=20 Phone: 732 524 3785=20 -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon Boeyen Sent: Thursday, June 22, 2006 1:57 PM To: 'Stefan Santesson'; ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause Stefan, if I understand your comment correctly I strongly believe such an escape clause cannot possibly be added because this would render 3280bis non-compliant with X.509.=20 =20 My understanding of your comment is that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found in EE certificates. Is that a correct understanding?=20 =20 If it is a correct understanding, then any such implementation is non-conformant to X.509. 3280 is a profile of X.509 and as such can mandate certain optional elements or exclude optional elements but cannot reverse the mandatory processing from X.509. =20 Apologies if I've misunderstood your question. =20 Cheers, Sharon -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Wednesday, June 21, 2006 5:23 PM To: ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause As a last call comment on RFC 3280bis I would like to raise the question whether RFC 3280bis should include an escape clause clearly allowing relying parties to select what validation logic they deploy on certificate validation. =20 The background is the fact that many deployed PKIs are misconfigured.2 One such common misconfiguration is assignment of certificate policies and their inclusion in CA certificates. X.509 path processing requires policies in CA certificates to reflect the list of EE certificate policies that are valid for a path. Yet many deployments have included pure CA certificate policies in CA certificates, policies that are not included in any EE certificates and as such, policy processing is not possible in such PKIs. =20 Application wanting to use certificate policies in such PKI are simply forced to either fail or selectively neglect certain path processing rules. For a relying party such modification could be reasonable if the security implications has been well though through. However it is not clear if an implementation allowing such local configuration could be regarded as standard compliant. =20 There are more examples where deploying applications in misconfigured PKIs would need similar measures to work. =20 The pki4ipsec WG recently came to this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX WG. =20 The result was that the pki4ipsec profile included an escape clause as follows: =20 4.1. X.509 Certificates =20 Users deploying IKE and IPsec with certificates have often had little control over the capabilities of CAs available to them. Implementations of this specification may include configuration knobs to disable checks required by this specification in orde! r t o permit use with inflexible and/or noncompliant CAs. However, all checks on certificates exist for a specific reason involving the security of the entire system. Therefore, all checks MUST be enabled by default. Administrators and users ought to understand the security purpose for the various checks, and be clear on what security will be lost by disabling the check. =20 =20 I'm basically asking if RFC 3280bis path validation needs a similar escape clause or corresponding clarification that clearly allows local configuration of the validation logic. At least I think it is necessary to clearly allow such configuration of standards compliant applications as long as this is not the default functionality. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =09 ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: den 16 juni 2006 22:42 To: ietf-pkix@imc.org Subject: last call for 3280bis =20 Folks, =20 Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt ) =20 The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th. =20 Steve ------_=_NextPart_001_01C69647.C3E2A6F5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

I think my initial statement was a = bit misinterpreted.

 

I suggest no changes to RFC 3280 = path processing. And of course, skipping mandatory checks would make the path processing non-conformant.

 

However. I have noticed that it is = not clear to some people weather a conformant implementation are forced to = always do conformant path processing, or if a conformant implementation can allow administrators to turn of certain checking.

 

What I say is mainly two = things;

1)       = Misconfigured PKIs may sometimes force relying parties to do = non conformant path processing or fail = altogether.

2)       = A conformant implementation should be allowed to support = also non-conformant processing as long as this is not the default = behavior.

 

I think this is already allowed, = but some implementers may not read it that way and therefore I’m asking if = we should add a clarification like pki4ipsec = did.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: = Guida, Richard [JJCUS] [mailto:RGuida@CORUS.JNJ.com]
Sent: den 22 juni 2006 = 20:48
To: Sharon Boeyen; Stefan Santesson; ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

 

Stefan - perhaps I am missing = something, but there is nothing that stops a relying party from writing software = that would perform processing extensions only on CA certs as you = propose.  As Sharon properly notes, that would not be RFC3280 compliant - but a relying = party can choose to be non-compliant if it wishes.  And such non-compliance = only puts the relying party at risk, not others - so that is a = "good thing" relatively speaking.  But in the final analysis, seems = to me that Sharon is absolutely correct (assuming she and I are interpreting your proposal properly) - unless X.509 is redefined, this would remain a = circumstance of non-compliance.  And so it should be treated as such.  = Very best regards -- Rich

 

 

 

Richard A. Guida
Director, Information Security =

Johnson & = Johnson
Room GS8217
410 George Street
New Brunswick, = New Jersey  08901
Phone:  732 524 3785

-----Original = Message-----
From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon Boeyen
Sent: Thursday, June 22, = 2006 1:57 PM
To: 'Stefan Santesson'; ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

Stefan, if I understand your = comment correctly I strongly believe such an escape clause cannot possibly be added = because this would render 3280bis non-compliant with X.509. =

 

My understanding of your comment is = that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found = in EE certificates. Is that a correct understanding? =

 

If it is a correct understanding, = then any such implementation is non-conformant to X.509. 3280 is a profile of = X.509 and as such can mandate certain optional elements or exclude optional = elements but cannot reverse the mandatory processing from = X.509.

 

Apologies if I've misunderstood = your question.

 

Cheers,

=

Sharon

-----Original = Message-----
From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson
Sent: Wednesday, June 21, = 2006 5:23 PM
To: ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

As a last call comment on RFC = 3280bis I would like to raise the question whether RFC 3280bis should include an = escape clause clearly allowing relying parties to select what validation logic = they deploy on certificate validation.

 

The background is the fact that = many deployed PKIs are misconfigured.2

One such common misconfiguration is assignment of certificate policies and their inclusion in CA = certificates.

X.509 path processing requires = policies in CA certificates to reflect the list of EE certificate policies that are = valid for a path. Yet many deployments have included pure CA certificate = policies in CA certificates, policies that are not included in any EE certificates = and as such, policy processing is not possible in such = PKIs.

 

Application wanting to use = certificate policies in such PKI are simply forced to either fail or selectively = neglect certain path processing rules. For a relying party such modification = could be reasonable if the security implications has been well though = through.

However it is not clear if an = implementation allowing such local configuration could be regarded as standard = compliant.

 

There are more examples where = deploying applications in misconfigured PKIs would need similar measures to = work.

 

The pki4ipsec WG recently came to = this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX = WG.

 

The result was that the pki4ipsec = profile included an escape clause as follows:

 

4.1.  X.509 =
Certificates
 
   Users deploying IKE and IPsec =
with certificates have often had =
little
   control over the capabilities of =
CAs available to them.
   Implementations of this =
specification may include configuration =
knobs
   to disable checks required by =
this specification in orde!
 r =
t
 o =
permit
   use with inflexible and/or =
noncompliant CAs.  However, all checks =
on
   certificates exist for a =
specific reason involving the security =
of
   the entire system.  =
Therefore, all checks MUST be enabled by =
default.
   Administrators and users ought =
to understand the security purpose =
for
   the various checks, and be clear =
on what security will be lost =
by
   disabling the =
check.

 

 

I'm basically asking if RFC 3280bis = path validation needs a similar escape clause or corresponding clarification = that clearly allows local configuration of the validation = logic.

At least I think it is necessary to clearly allow such configuration of standards compliant applications as = long as this is not the default functionality.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Stephen Kent
Sent: den 16 juni 2006 = 22:42
To: ietf-pkix@imc.org
Subject: last call for = 3280bis

 

Folks,

 

Based on the latest message from David Cooper, I am initiating = last call on "Internet X.509 Public Key Infrastructure, Certificate and = Certificate Revocation List (CRL) Profile" = (http://ietf.org/internet-drafts/draft-ietf-pki= x-rfc3280bis-03.txt)

 

The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many = folks), all comments must be received by July 5th.

 

Steve

------_=_NextPart_001_01C69647.C3E2A6F5-- From owner-ietf-pkix@mail.imc.org Thu Jun 22 19:40:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtYn7-0004R7-K2 for pkix-archive@lists.ietf.org; Thu, 22 Jun 2006 19:40:53 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtYn6-0001hE-7J for pkix-archive@lists.ietf.org; Thu, 22 Jun 2006 19:40:53 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MMoDqL078475; Thu, 22 Jun 2006 15:50:13 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MMoDPb078474; Thu, 22 Jun 2006 15:50:13 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MMoCcK078444 for ; Thu, 22 Jun 2006 15:50:13 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5MMo2Hp029345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Jun 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FtXzu-0007u6-Dt; Thu, 22 Jun 2006 18:50:02 -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-srvsan-02.txt Message-Id: Date: Thu, 22 Jun 2006 18:50:02 -0400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.3 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure Subject Alternative Name for expression of service name Author(s) : S. Santesson Filename : draft-ietf-pkix-srvsan-02.txt Pages : 11 Date : 2006-6-22 This document defines a new name form for inclusion in the otherName filed of an X.509 Subject Alternative Name extension which allows a certificate subject to be associated with the service name and domain name components of a DNS Service Resource Record. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-srvsan-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-srvsan-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-srvsan-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: <2006-6-22162653.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-srvsan-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-srvsan-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-22162653.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix@mail.imc.org Thu Jun 22 20:28:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtZWq-0003oe-1z for pkix-archive@lists.ietf.org; Thu, 22 Jun 2006 20:28:08 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtZWo-0005xT-Lb for pkix-archive@lists.ietf.org; Thu, 22 Jun 2006 20:28:08 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MNgqXo091713; Thu, 22 Jun 2006 16:42:52 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MNgqwJ091712; Thu, 22 Jun 2006 16:42:52 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MNgps6091705 for ; Thu, 22 Jun 2006 16:42:52 -0700 (MST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (24-205-218-53.dhcp.crcy.nv.charter.com [24.205.218.53] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id k5MNgobs029939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Jun 2006 23:42:50 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <7.0.1.0.0.20060622153640.040ef5d8@OpenLDAP.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 22 Jun 2006 16:43:12 -0700 To: Tim Polk From: "Kurt D. Zeilenga" Subject: Re: stringprep in 3280bis Cc: ietf-pkix@imc.org In-Reply-To: <5.1.0.14.2.20060622102208.02f3ffb0@email.nist.gov> References: <5.1.0.14.2.20060622102208.02f3ffb0@email.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Tim, As far as nameprep goes, yes, AllowUnassigned is all about "stored" v. "query" strings. So, as you note, domain label preparation is mostly okay. (see below comments). However, I do note that 7.1 says nothing about "stored" v. "query" strings. In this case, as one implementation is preparing both strings in the comparison, treating both as "stored" should be fine. -- Kurt At 02:52 PM 6/22/2006, Tim Polk wrote: >>To accommodate >> internationalized domain names in the current structure, conforming >> implementations MUST convert internationalized domain names to the >> ASCII Compatible Encoding (ACE) format as specified in section 4 of >> RFC 3490 before storage in the dNSName field. Specifically, >> conforming implementations MUST perform the conversion operation >> specified in section 4 of RFC 3490 as follows: >> >> * in step 1, the domain name SHALL be considered a "stored >> string"; > (additional steps deleted) You might want to add: , hence the AllowUnassigned SHALL NOT be set. since nameprep uses this flag to indicate the string has "stored" handling. Likewise in subsequent bullet set in this section. >In section 7.3, we did not specify "stored" versus "query", because it does not seem to apply. In this section 7.3, the domain component attribute contains only a single label, so we only perform the "ToASCII" operation. It does (via AllowUnassigned). >>To represent a label from an IDN in the distinguished >> name, the implementation MUST perform the "ToASCII" label conversion >> specified in section 4.1 of RFC 3490. > >As I said, the "ToASCII" operation doesn't seem to care about "stored" versus "query" so we didn't specify it. However, the "ToASCII" operation does require specification of two additional inputs: the AllowUnassigned flag, and the UseSTD3ASCIIRules flag. We dropped the ball here. We should have specified that the UseSTD3ASCIIRules flag should be set, and that AllowUassigned flag is *not* set. (That works out to be the same as "stored" anyway, doesn't it?) Yes. >(1) How about the following revision to that sentence in 7.3: > >To represent a label from an IDN in the distinguished name, the implementation MUST perform the "ToASCII" label conversion specified in section 4.1 of RFC 3490, where the STD3ASCIIRules flag is set but AllowUnassigned flag is not set. >(2) If I misinterpreted the specification of "ToASCII", and we do need to specify "stored" vs. "query", we could use this alternate text: > >To represent a label from an IDN in the distinguished name, the implementation MUST perform the "ToASCII" label conversion specified in section 4.1 of RFC 3490, where the string preparation is performed as a "stored" string. I prefer language that explicitly says that the string is to be regarded as "stored" and (hence) the AllowUnassigned flag is not set (see my comment regarding 7.2 text). -- Kurt From owner-ietf-pkix@mail.imc.org Thu Jun 22 21:40:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftaeh-0001oM-SR for pkix-archive@lists.ietf.org; Thu, 22 Jun 2006 21:40:19 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftaeg-0002KF-Jm for pkix-archive@lists.ietf.org; Thu, 22 Jun 2006 21:40:19 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5N0dKtR005820; Thu, 22 Jun 2006 17:39:20 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5N0dKwu005818; Thu, 22 Jun 2006 17:39:20 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5N0dIFd005796 for ; Thu, 22 Jun 2006 17:39:18 -0700 (MST) (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); Fri, 23 Jun 2006 01:39:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6965D.732C5B0F" Subject: RE: last call for 3280bis - escape clause Date: Fri, 23 Jun 2006 01:39:12 +0100 Message-ID: In-Reply-To: <82D5657AE1F54347A734BDD33637C8790359D724@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: last call for 3280bis - escape clause thread-index: AcaWNVMoloaBo6PDT0CPPD74liD0jQAB/dsAAAeBmuA= From: "Stefan Santesson" To: "Santosh Chokhani" , X-OriginalArrivalTime: 23 Jun 2006 00:39:14.0040 (UTC) FILETIME=[737DFF80:01C6965D] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.3 (/) X-Scan-Signature: a9d67c3f17f3c6e4e04fa40d2f302fe3 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6965D.732C5B0F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Santosh, =20 There are 2 distinct reasons why your approach is not a generic solution to the problem. =20 1) The problem is generic and does not only apply to policy processing. The pki4ipsec issue was e.g. motivated from problems with EKU settings in existing certificates that does not satisfy new applications and usages. 2) If you need to test for a policy in the end certificate, that policy will not be valid unless supported by the path, regardless if policy constraints was set or not. =20 In the perfect world, compliant path processing will always do the job. In the real world, you may need to tweak the rules to make a new application fit into an existing infrastructure- =20 The question is still: Can a standards compliant implementation allow configuration of non conformant modifications to the validation process, or does that make the implementation as a whole non-conformant. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: den 22 juni 2006 22:59 To: ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause =20 Stefan, =20 I agree with sentiments voiced by Steve, Rich, and Sharon. =20 I have a simple solution to your concern from the relying party viewpoint. This observation is made with a long-held view of mine (and no one had provided a convincing logical or business argument) that the require explicit policy setting is a useless field. A relying party can always set acceptable policies to none. In that scenario, (require explicit policy) flag not withstanding, path validation will succeed. Now, the user can examine the end certificate policy. =20 You and I have had this discussion in another context. The basic premise is that if some field in the last certificate only is of interest and the "state" in the path validation process does not impact it, that need not be path of path validation engine. =20 Thus, you can judiciously use the 3280 Engine and obtain the result you seek. ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Guida, Richard [JJCUS] Sent: Thursday, June 22, 2006 2:48 PM To: Sharon Boeyen; 'Stefan Santesson'; ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause =20 Stefan - perhaps I am missing something, but there is nothing that stops a relying party from writing software that would perform processing extensions only on CA certs as you propose. As Sharon properly notes, that would not be RFC3280 compliant - but a relying party can choose to be non-compliant if it wishes. And such non-compliance only puts the relying party at risk, not others - so that is a "good thing" relatively speaking. But in the final analysis, seems to me that Sharon is absolutely correct (assuming she and I are interpreting your proposal properly) - unless X.509 is redefined, this would remain a circumstance of non-compliance. And so it should be treated as such. Very best regards -- Rich =20 =20 =20 Richard A. Guida=20 Director, Information Security=20 Johnson & Johnson=20 Room GS8217=20 410 George Street=20 New Brunswick, New Jersey 08901=20 Phone: 732 524 3785=20 -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon Boeyen Sent: Thursday, June 22, 2006 1:57 PM To: 'Stefan Santesson'; ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause Stefan, if I understand your comment correctly I strongly believe such an escape clause cannot possibly be added because this would render 3280bis non-compliant with X.509.=20 =20 My understanding of your comment is that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found in EE certificates. Is that a correct understanding?=20 =20 If it is a correct understanding, then any such implementation is non-conformant to X.509. 3280 is a profile of X.509 and as such can mandate certain optional elements or exclude optional elements but cannot reverse the mandatory processing from X.509. =20 Apologies if I've misunderstood your question. =20 Cheers, Sharon -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Wednesday, June 21, 2006 5:23 PM To: ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause As a last call comment on RFC 3280bis I would like to raise the question whether RFC 3280bis should include an escape clause clearly allowing relying parties to select what validation logic they deploy on certificate validation. =20 The background is the fact that many deployed PKIs are misconfigured.2 One such common misconfiguration is assignment of certificate policies and their inclusion in CA certificates. X.509 path processing requires policies in CA certificates to reflect the list of EE certificate policies that are valid for a path. Yet many deployments have included pure CA certificate policies in CA certificates, policies that are not included in any EE certificates and as such, policy processing is not possible in such PKIs. =20 Application wanting to use certificate policies in such PKI are simply forced to either fail or selectively neglect certain path processing rules. For a relying party such modification could be reasonable if the security implications has been well though through. However it is not clear if an implementation allowing such local configuration could be regarded as standard compliant. =20 There are more examples where deploying applications in misconfigured PKIs would need similar measures to work. =20 The pki4ipsec WG recently came to this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX WG. =20 The result was that the pki4ipsec profile included an escape clause as follows: =20 4.1. X.509 Certificates =20 Users deploying IKE and IPsec with certificates have often had little control over the capabilities of CAs available to them. Implementations of this specification may include configuration knobs to disable checks required by this specification in orde! r t o permit use with inflexible and/or noncompliant CAs. However, all checks on certificates exist for a specific reason involving the security of the entire system. Therefore, all checks MUST be enabled by default. Administrators and users ought to understand the security purpose for the various checks, and be clear on what security will be lost by disabling the check. =20 =20 I'm basically asking if RFC 3280bis path validation needs a similar escape clause or corresponding clarification that clearly allows local configuration of the validation logic. At least I think it is necessary to clearly allow such configuration of standards compliant applications as long as this is not the default functionality. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =09 ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: den 16 juni 2006 22:42 To: ietf-pkix@imc.org Subject: last call for 3280bis =20 Folks, =20 Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt ) =20 The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th. =20 Steve ------_=_NextPart_001_01C6965D.732C5B0F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Santosh,

 

There are 2 distinct reasons why = your approach is not a generic solution to the = problem.

 

1)       = The problem is generic and does not only apply to policy processing. The pki4ipsec issue was e.g. motivated from problems with = EKU settings in existing certificates that does not satisfy new applications = and usages.

2)       = If you need to test for a policy in the end certificate, = that policy will not be valid unless supported by the path, regardless if = policy constraints was set or not.

 

In the perfect world, compliant = path processing will always do the job. In the real world, you may need to = tweak the rules to make a new application fit into an existing = infrastructure-

 

The question is still: Can a = standards compliant implementation allow configuration of non conformant = modifications to the validation process, or does that make the implementation as a whole = non-conformant.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Santosh Chokhani
Sent: den 22 juni 2006 = 22:59
To: ietf-pkix@imc.org
Subject: RE: last call = for 3280bis - escape clause

 

Stefan,

=

 

I agree with sentiments voiced by = Steve, Rich, and Sharon.

 

I have a simple solution to your = concern from the relying party viewpoint.  This observation is made with a = long-held view of mine (and no one had provided a convincing logical or business argument) that the require explicit policy setting is a useless field. =  A relying party can always set acceptable policies to none.  In that scenario, (require explicit policy) flag not withstanding, path = validation will succeed.  Now, the user can examine the end certificate = policy.

 

You and I have had this discussion = in another context.  The basic premise is that if some field in the = last certificate only is of interest and the “state” in the path validation process does not impact it, that need not be path of path = validation engine.

 

Thus, you can judiciously use the = 3280 Engine and obtain the result you seek.

From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Guida, Richard [JJCUS]
Sent: Thursday, June 22, = 2006 2:48 PM
To: Sharon Boeyen; = 'Stefan Santesson'; ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

 

Stefan - perhaps I am missing = something, but there is nothing that stops a relying party from writing software = that would perform processing extensions only on CA certs as you = propose.  As Sharon properly notes, that would not be RFC3280 compliant - but a relying = party can choose to be non-compliant if it wishes.  And such non-compliance = only puts the relying party at risk, not others - so that is a = "good thing" relatively speaking.  But in the final analysis, seems = to me that Sharon is absolutely correct (assuming she and I are interpreting your proposal properly) - unless X.509 is redefined, this would remain a = circumstance of non-compliance.  And so it should be treated as such.  = Very best regards -- Rich

 

 

 

Richard A. Guida
Director, Information Security =

Johnson & = Johnson
Room GS8217
410 George Street
New Brunswick, = New Jersey  08901
Phone:  732 524 3785

-----Original = Message-----
From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon Boeyen
Sent: Thursday, June 22, = 2006 1:57 PM
To: 'Stefan Santesson'; ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

Stefan, if I understand your = comment correctly I strongly believe such an escape clause cannot possibly be = added because this would render 3280bis non-compliant with X.509. =

 

My understanding of your comment is = that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found = in EE certificates. Is that a correct understanding? =

 

If it is a correct understanding, = then any such implementation is non-conformant to X.509. 3280 is a profile of = X.509 and as such can mandate certain optional elements or exclude optional = elements but cannot reverse the mandatory processing from = X.509.

 

Apologies if I've misunderstood = your question.

 

Cheers,

=

Sharon

-----Original = Message-----
From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson
Sent: Wednesday, June 21, = 2006 5:23 PM
To: ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

As a last call comment on RFC = 3280bis I would like to raise the question whether RFC 3280bis should include an = escape clause clearly allowing relying parties to select what validation logic they = deploy on certificate validation.

 

The background is the fact that = many deployed PKIs are misconfigured.2

One such common misconfiguration is = assignment of certificate policies and their inclusion in CA = certificates.

X.509 path processing requires = policies in CA certificates to reflect the list of EE certificate policies that are = valid for a path. Yet many deployments have included pure CA certificate = policies in CA certificates, policies that are not included in any EE certificates = and as such, policy processing is not possible in such = PKIs.

 

Application wanting to use = certificate policies in such PKI are simply forced to either fail or selectively = neglect certain path processing rules. For a relying party such modification = could be reasonable if the security implications has been well though = through.

However it is not clear if an implementation allowing such local configuration could be regarded as = standard compliant.

 

There are more examples where = deploying applications in misconfigured PKIs would need similar measures to = work.

 

The pki4ipsec WG recently came to = this conclusion in their PKI profile and this lead to an intense debate which = included core participants from the PKIX WG.

 

The result was that the pki4ipsec = profile included an escape clause as follows:

 

4.1.  X.509 =
Certificates
 
   Users deploying IKE and IPsec =
with certificates have often had =
little
   control over the capabilities of =
CAs available to them.
   Implementations of this =
specification may include configuration =
knobs
   to disable checks required by =
this specification in orde!
 r =
t
 o =
permit
   use with inflexible and/or =
noncompliant CAs.  However, all checks =
on
   certificates exist for a =
specific reason involving the security =
of
   the entire system.  =
Therefore, all checks MUST be enabled by =
default.
   Administrators and users ought =
to understand the security purpose =
for
   the various checks, and be clear =
on what security will be lost =
by
   disabling the =
check.

 

 

I'm basically asking if RFC 3280bis = path validation needs a similar escape clause or corresponding clarification = that clearly allows local configuration of the validation = logic.

At least I think it is necessary to clearly allow such configuration of standards compliant applications as = long as this is not the default functionality.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Stephen Kent
Sent: den 16 juni 2006 = 22:42
To: ietf-pkix@imc.org
Subject: last call for = 3280bis

 

Folks,

 

Based on the latest message from David Cooper, I am initiating = last call on "Internet X.509 Public Key Infrastructure, Certificate and = Certificate Revocation List (CRL) Profile" = (http://ietf.org/internet-drafts/draft-ietf-pki= x-rfc3280bis-03.txt)

 

The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many = folks), all comments must be received by July 5th.

 

Steve

------_=_NextPart_001_01C6965D.732C5B0F-- From owner-ietf-pkix@mail.imc.org Thu Jun 22 21:47:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtalW-00070A-9P for pkix-archive@lists.ietf.org; Thu, 22 Jun 2006 21:47:22 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtalU-0004ZN-UX for pkix-archive@lists.ietf.org; Thu, 22 Jun 2006 21:47:22 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5N0lfAd007868; Thu, 22 Jun 2006 17:47:41 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5N0lfct007867; Thu, 22 Jun 2006 17:47:41 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5N0leg9007832 for ; Thu, 22 Jun 2006 17:47:41 -0700 (MST) (envelope-from chokhani@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6965F.1CC1663D" Subject: RE: last call for 3280bis - escape clause Date: Thu, 22 Jun 2006 17:47:35 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C8790359DA0E@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: last call for 3280bis - escape clause Thread-Index: AcaWNVMoloaBo6PDT0CPPD74liD0jQAB/dsAAAeBmuAAAJmXEA== From: "Santosh Chokhani" To: "Stefan Santesson" , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.3 (/) X-Scan-Signature: 38680ce676e2d0bb31e51d727f38ca39 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6965F.1CC1663D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stefan, =20 On disagree with you on 2. You seem to be asking for 2 and then saying that it is not valid. =20 A path validation profile (assuming we agree to ignore "require explicit policy") with setting acceptable policy set to anyPolicy is valid X.509 and 3280 configuration. In that case, there will not be a policy failure and relying party can always make additional checks. I encourage you to look at Section J.3 in Annex J of X.509. If you see any errors in Annex J, please let me know. =20 As to Standard compliant implementation putting itself in non-compliant mode, that is always acceptable. In that mode it will NOT be standard compliant; that is all. ________________________________ From: Stefan Santesson [mailto:stefans@microsoft.com]=20 Sent: Thursday, June 22, 2006 8:39 PM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause =20 Santosh, =20 There are 2 distinct reasons why your approach is not a generic solution to the problem. =20 1) The problem is generic and does not only apply to policy processing. The pki4ipsec issue was e.g. motivated from problems with EKU settings in existing certificates that does not satisfy new applications and usages. 2) If you need to test for a policy in the end certificate, that policy will not be valid unless supported by the path, regardless if policy constraints was set or not. =20 In the perfect world, compliant path processing will always do the job. In the real world, you may need to tweak the rules to make a new application fit into an existing infrastructure- =20 The question is still: Can a standards compliant implementation allow configuration of non conformant modifications to the validation process, or does that make the implementation as a whole non-conformant. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: den 22 juni 2006 22:59 To: ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause =20 Stefan, =20 I agree with sentiments voiced by Steve, Rich, and Sharon. =20 I have a simple solution to your concern from the relying party viewpoint. This observation is made with a long-held view of mine (and no one had provided a convincing logical or business argument) that the require explicit policy setting is a useless field. A relying party can always set acceptable policies to none. In that scenario, (require explicit policy) flag not withstanding, path validation will succeed. Now, the user can examine the end certificate policy. =20 You and I have had this discussion in another context. The basic premise is that if some field in the last certificate only is of interest and the "state" in the path validation process does not impact it, that need not be path of path validation engine. =20 Thus, you can judiciously use the 3280 Engine and obtain the result you seek. ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Guida, Richard [JJCUS] Sent: Thursday, June 22, 2006 2:48 PM To: Sharon Boeyen; 'Stefan Santesson'; ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause =20 Stefan - perhaps I am missing something, but there is nothing that stops a relying party from writing software that would perform processing extensions only on CA certs as you propose. As Sharon properly notes, that would not be RFC3280 compliant - but a relying party can choose to be non-compliant if it wishes. And such non-compliance only puts the relying party at risk, not others - so that is a "good thing" relatively speaking. But in the final analysis, seems to me that Sharon is absolutely correct (assuming she and I are interpreting your proposal properly) - unless X.509 is redefined, this would remain a circumstance of non-compliance. And so it should be treated as such. Very best regards -- Rich =20 =20 =20 Richard A. Guida=20 Director, Information Security=20 Johnson & Johnson=20 Room GS8217=20 410 George Street=20 New Brunswick, New Jersey 08901=20 Phone: 732 524 3785=20 -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon Boeyen Sent: Thursday, June 22, 2006 1:57 PM To: 'Stefan Santesson'; ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause Stefan, if I understand your comment correctly I strongly believe such an escape clause cannot possibly be added because this would render 3280bis non-compliant with X.509.=20 =20 My understanding of your comment is that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found in EE certificates. Is that a correct understanding?=20 =20 If it is a correct understanding, then any such implementation is non-conformant to X.509. 3280 is a profile of X.509 and as such can mandate certain optional elements or exclude optional elements but cannot reverse the mandatory processing from X.509. =20 Apologies if I've misunderstood your question. =20 Cheers, Sharon -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Wednesday, June 21, 2006 5:23 PM To: ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause As a last call comment on RFC 3280bis I would like to raise the question whether RFC 3280bis should include an escape clause clearly allowing relying parties to select what validation logic they deploy on certificate validation. =20 The background is the fact that many deployed PKIs are misconfigured.2 One such common misconfiguration is assignment of certificate policies and their inclusion in CA certificates. X.509 path processing requires policies in CA certificates to reflect the list of EE certificate policies that are valid for a path. Yet many deployments have included pure CA certificate policies in CA certificates, policies that are not included in any EE certificates and as such, policy processing is not possible in such PKIs. =20 Application wanting to use certificate policies in such PKI are simply forced to either fail or selectively neglect certain path processing rules. For a relying party such modification could be reasonable if the security implications has been well though through. However it is not clear if an implementation allowing such local configuration could be regarded as standard compliant. =20 There are more examples where deploying applications in misconfigured PKIs would need similar measures to work. =20 The pki4ipsec WG recently came to this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX WG. =20 The result was that the pki4ipsec profile included an escape clause as follows: =20 4.1. X.509 Certificates =20 Users deploying IKE and IPsec with certificates have often had little control over the capabilities of CAs available to them. Implementations of this specification may include configuration knobs to disable checks required by this specification in orde! r t o permit use with inflexible and/or noncompliant CAs. However, all checks on certificates exist for a specific reason involving the security of the entire system. Therefore, all checks MUST be enabled by default. Administrators and users ought to understand the security purpose for the various checks, and be clear on what security will be lost by disabling the check. =20 =20 I'm basically asking if RFC 3280bis path validation needs a similar escape clause or corresponding clarification that clearly allows local configuration of the validation logic. At least I think it is necessary to clearly allow such configuration of standards compliant applications as long as this is not the default functionality. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =09 ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: den 16 juni 2006 22:42 To: ietf-pkix@imc.org Subject: last call for 3280bis =20 Folks, =20 Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt ) =20 The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th. =20 Steve ------_=_NextPart_001_01C6965F.1CC1663D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Stefan,

=

 

On disagree with you on 2. =  You seem to be asking for 2 and then saying that it is not = valid.

 

A path validation profile (assuming = we agree to ignore “require explicit policy”) with setting = acceptable policy set to anyPolicy is valid X.509 and 3280 configuration.  In = that case, there will not be a policy failure and relying party can always make = additional checks.  I encourage you to look at Section J.3 in Annex J of = X.509.  If you see any errors in Annex J, please let me = know.

 

As to Standard compliant = implementation putting itself in non-compliant mode, that is always acceptable. =  In that mode it will NOT be standard compliant; that is = all.

From: = Stefan Santesson [mailto:stefans@microsoft.com]
Sent: Thursday, June 22, = 2006 8:39 PM
To: Santosh Chokhani; ietf-pkix@imc.org
Subject: RE: last call = for 3280bis - escape clause

 

Santosh,

 

There are 2 distinct reasons why = your approach is not a generic solution to the = problem.

 

1)       = The problem is generic and does not only apply to policy processing. The pki4ipsec issue was e.g. motivated from problems with = EKU settings in existing certificates that does not satisfy new applications = and usages.

2)       = If you need to test for a policy in the end certificate, = that policy will not be valid unless supported by the path, regardless if = policy constraints was set or not.

 

In the perfect world, compliant = path processing will always do the job. In the real world, you may need to = tweak the rules to make a new application fit into an existing = infrastructure-

 

The question is still: Can a = standards compliant implementation allow configuration of non conformant = modifications to the validation process, or does that make the implementation as a whole non-conformant.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Santosh Chokhani
Sent: den 22 juni 2006 = 22:59
To: ietf-pkix@imc.org
Subject: RE: last call = for 3280bis - escape clause

 

Stefan,

=

 

I agree with sentiments voiced by = Steve, Rich, and Sharon.

 

I have a simple solution to your = concern from the relying party viewpoint.  This observation is made with a long-held view of mine (and no one had provided a convincing logical or = business argument) that the require explicit policy setting is a useless field. =  A relying party can always set acceptable policies to none.  In that scenario, (require explicit policy) flag not withstanding, path = validation will succeed.  Now, the user can examine the end certificate = policy.

 

You and I have had this discussion = in another context.  The basic premise is that if some field in the = last certificate only is of interest and the “state” in the path validation process does not impact it, that need not be path of path = validation engine.

 

Thus, you can judiciously use the = 3280 Engine and obtain the result you seek.

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Guida, Richard = [JJCUS]
Sent: Thursday, June 22, = 2006 2:48 PM
To: Sharon Boeyen; = 'Stefan Santesson'; ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

 

Stefan - perhaps I am missing = something, but there is nothing that stops a relying party from writing software = that would perform processing extensions only on CA certs as you = propose.  As Sharon properly = notes, that would not be RFC3280 compliant - but a relying party can choose to = be non-compliant if it wishes.  And such non-compliance only puts the = relying party at risk, not others - so that is a "good thing" = relatively speaking.  But in the final analysis, seems to me that Sharon is absolutely correct = (assuming she and I are interpreting your proposal properly) - unless X.509 is redefined, this would remain a circumstance of non-compliance.  And = so it should be treated as such.  Very best regards -- = Rich

 

 

 

Richard A. Guida
Director, Information Security =

Johnson & = Johnson
Room GS8217
410 George Street
New Brunswick, = New Jersey  08901
Phone:  732 524 3785

-----Original = Message-----
From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon Boeyen
Sent: Thursday, June 22, = 2006 1:57 PM
To: 'Stefan Santesson'; ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

Stefan, if I understand your = comment correctly I strongly believe such an escape clause cannot possibly be = added because this would render 3280bis non-compliant with X.509. =

 

My understanding of your comment is = that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found = in EE certificates. Is that a correct understanding? =

 

If it is a correct understanding, = then any such implementation is non-conformant to X.509. 3280 is a profile of = X.509 and as such can mandate certain optional elements or exclude optional = elements but cannot reverse the mandatory processing from = X.509.

 

Apologies if I've misunderstood = your question.

 

Cheers,

=

Sharon

-----Original = Message-----
From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson
Sent: Wednesday, June 21, = 2006 5:23 PM
To: ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

As a last call comment on RFC = 3280bis I would like to raise the question whether RFC 3280bis should include an = escape clause clearly allowing relying parties to select what validation logic = they deploy on certificate validation.

 

The background is the fact that = many deployed PKIs are misconfigured.2

One such common misconfiguration is assignment of certificate policies and their inclusion in CA = certificates.

X.509 path processing requires = policies in CA certificates to reflect the list of EE certificate policies that are = valid for a path. Yet many deployments have included pure CA certificate = policies in CA certificates, policies that are not included in any EE certificates = and as such, policy processing is not possible in such = PKIs.

 

Application wanting to use = certificate policies in such PKI are simply forced to either fail or selectively = neglect certain path processing rules. For a relying party such modification = could be reasonable if the security implications has been well though = through.

However it is not clear if an implementation allowing such local configuration could be regarded as = standard compliant.

 

There are more examples where = deploying applications in misconfigured PKIs would need similar measures to = work.

 

The pki4ipsec WG recently came to = this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX = WG.

 

The result was that the pki4ipsec = profile included an escape clause as follows:

 

4.1.  X.509 =
Certificates
 
   Users deploying IKE and IPsec =
with certificates have often had =
little
   control over the capabilities of =
CAs available to them.
   Implementations of this =
specification may include configuration =
knobs
   to disable checks required by =
this specification in orde!
 r =
t
 o =
permit
   use with inflexible and/or =
noncompliant CAs.  However, all checks =
on
   certificates exist for a =
specific reason involving the security =
of
   the entire system.  =
Therefore, all checks MUST be enabled by =
default.
   Administrators and users ought =
to understand the security purpose =
for
   the various checks, and be clear =
on what security will be lost =
by
   disabling the =
check.

 

 

I'm basically asking if RFC 3280bis = path validation needs a similar escape clause or corresponding clarification = that clearly allows local configuration of the validation = logic.

At least I think it is necessary to clearly allow such configuration of standards compliant applications as = long as this is not the default functionality.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Stephen Kent
Sent: den 16 juni 2006 = 22:42
To: ietf-pkix@imc.org
Subject: last call for = 3280bis

 

Folks,

 

Based on the latest message from David Cooper, I am initiating = last call on "Internet X.509 Public Key Infrastructure, Certificate and = Certificate Revocation List (CRL) Profile" = (http://ietf.org/internet-drafts/draft-ietf-pki= x-rfc3280bis-03.txt)

 

The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many = folks), all comments must be received by July 5th.

 

Steve

------_=_NextPart_001_01C6965F.1CC1663D-- From owner-ietf-pkix@mail.imc.org Fri Jun 23 03:11:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtfpD-0006eV-1M for pkix-archive@lists.ietf.org; Fri, 23 Jun 2006 03:11:31 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtekK-0006bj-Cw for pkix-archive@lists.ietf.org; Fri, 23 Jun 2006 02:02:24 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FteZd-0001tR-Gx for pkix-archive@lists.ietf.org; Fri, 23 Jun 2006 01:51:23 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5N4o15Q071649; Thu, 22 Jun 2006 21:50:01 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5N4o1dm071648; Thu, 22 Jun 2006 21:50:01 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailipbo.ntcif.telstra.com.au (mailipbo.ntcif.telstra.com.au [202.12.233.29]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5N4nwH9071620 for ; Thu, 22 Jun 2006 21:49:59 -0700 (MST) (envelope-from James.H.Manger@team.telstra.com) Received: from webi.ntcif.telstra.com.au (HELO mailbi.ntcif.telstra.com.au) ([202.12.162.19]) by mailipbo.ntcif.telstra.com.au with ESMTP; 23 Jun 2006 14:49:57 +1000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.ntcif.telstra.com.au (Postfix) with ESMTP id 2A2B5FF82 for ; Fri, 23 Jun 2006 14:49:57 +1000 (EST) Received: from wsmsg2902.srv.dir.telstra.com (wsmsg2902.srv.dir.telstra.com [172.49.40.51]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id OAA25844 for ; Fri, 23 Jun 2006 14:49:56 +1000 (EST) Received: from WSMSG2103V.srv.dir.telstra.com ([172.49.40.20]) by wsmsg2902.srv.dir.telstra.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jun 2006 14:49:52 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Subject: SRV Name: draft-ietf-pkix-srvsan-02.txt: typos, examples Date: Fri, 23 Jun 2006 14:49:51 +1000 Message-ID: <6215401E01247448A306C54F499111F2C4AB35@WSMSG2103V.srv.dir.telstra.com> Thread-Topic: SRV Name: draft-ietf-pkix-srvsan-02.txt: typos, examples Thread-Index: AcaWWVJxh0AAs+BBSLGoi/jkDBS2aQAEuBXg From: "Manger, James H" To: X-OriginalArrivalTime: 23 Jun 2006 04:49:52.0590 (UTC) FILETIME=[772A9EE0:01C69680] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id k5N4o0H9071633 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: -2.6 (--) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Comments on draft-ietf-pkix-srvsan-02.txt 1. Abstract, page 1, typo: "filed" -> "field" 2. It would be nice if the full value of the id-on-dnsSRV object identifier was provided in this document, without requiring a separate lookup of RFC 3280. Add the following ASN.1 comment just above the id-on definition in Appendix A.1 (page 8), Appendix A.2 (page 8) and section 2 "Name Definitions" (page 3): -- id-pkix OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7} 3. Include an example with an IDN so it is immediately obvious that punycode is not used in an SRVName value. Add the following after the current example in section 2, page 4: Example: The "mail" service at nave.net (an IDN, which becomes xn--nave-6pa.net when encoded as an IDNA) would use the following 15-character SRVName value: _mail.nave.net Its 16-byte UTF-8 encoding is (in hex): 5F 6D 61 69 6C 2E 6E 61 C3 AF 76 65 2E 6E 65 74 4. Appendix A.2 (page 9), glitch: "permanentIdentifier" -> "srvName" 5. Why bother with the (SIZE (1..MAX)) restriction? Delete it. 6. SRVName is defined (in section 2) to have the form _Service.Name. The very next section violates that definition by allowing SRVName to hold just a service name or just a domain name. The syntax to hold a name is not necessarily the same syntax required to hold a matching rule for that name. This is a general fault with the construction of the nameConstraints extension so it does not need to be fixed in this specification (I am just having a rant). 7. Appendix A, page 7: "augmented with 1993 the UNIVERSAL Type" -> "augmented with the 1993 UNIVERSAL Type" 8. Appendix A. Are the modules names supposed to end with "..SAN88" and "..SAN93", or is it supposed to be "..ASN88" and "..ASN93"? -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Internet-Drafts@ietf.org Sent: Friday, 23 June 2006 8:50 AM To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org Subject: I-D ACTION:draft-ietf-pkix-srvsan-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure Subject Alternative Name for expression of service name Author(s) : S. Santesson Filename : draft-ietf-pkix-srvsan-02.txt Pages : 11 Date : 2006-6-22 This document defines a new name form for inclusion in the otherName filed of an X.509 Subject Alternative Name extension which allows a certificate subject to be associated with the service name and domain name components of a DNS Service Resource Record. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-srvsan-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-srvsan-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-srvsan-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. From owner-ietf-pkix@mail.imc.org Fri Jun 23 06:27:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtisP-0000ae-At for pkix-archive@lists.ietf.org; Fri, 23 Jun 2006 06:27:01 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtisN-0000qp-Sm for pkix-archive@lists.ietf.org; Fri, 23 Jun 2006 06:27:01 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5N9SV1o033764; Fri, 23 Jun 2006 02:28:31 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5N9SVIA033763; Fri, 23 Jun 2006 02:28:31 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5N9STHA033741 for ; Fri, 23 Jun 2006 02:28:29 -0700 (MST) (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); Fri, 23 Jun 2006 10:28:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C696A7.5F1E4C4B" Subject: RE: last call for 3280bis - escape clause Date: Fri, 23 Jun 2006 10:28:21 +0100 Message-ID: In-Reply-To: <82D5657AE1F54347A734BDD33637C8790359DA0E@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: last call for 3280bis - escape clause thread-index: AcaWNVMoloaBo6PDT0CPPD74liD0jQAB/dsAAAeBmuAAAJmXEAAN+MPw From: "Stefan Santesson" To: "Santosh Chokhani" , X-OriginalArrivalTime: 23 Jun 2006 09:28:23.0153 (UTC) FILETIME=[5F702E10:01C696A7] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.3 (/) X-Scan-Signature: fd51b29932ff50b682a542577cd0b7b1 This is a multi-part message in MIME format. ------_=_NextPart_001_01C696A7.5F1E4C4B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Santosh, =20 Yes, you are correct that the path will validate without any error in your example.=20 It will also have an empty set of valid policies. So accepting the EE certificate policies as valid (using that path) do require some kind of non-conformant policy checking. =20 I agree on your conclusion. However I have experienced implementers not feeling sure about this principle. Especially when it comes to configuration options enabled by an administrative UI and not just some mode switch in the OS. The escape clause in pki4ipsic was driven by this uncertainty. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards ________________________________ From: Santosh Chokhani [mailto:chokhani@orionsec.com]=20 Sent: den 23 juni 2006 02:48 To: Stefan Santesson; ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause =20 Stefan, =20 On disagree with you on 2. You seem to be asking for 2 and then saying that it is not valid. =20 A path validation profile (assuming we agree to ignore "require explicit policy") with setting acceptable policy set to anyPolicy is valid X.509 and 3280 configuration. In that case, there will not be a policy failure and relying party can always make additional checks. I encourage you to look at Section J.3 in Annex J of X.509. If you see any errors in Annex J, please let me know. =20 As to Standard compliant implementation putting itself in non-compliant mode, that is always acceptable. In that mode it will NOT be standard compliant; that is all. ________________________________ From: Stefan Santesson [mailto:stefans@microsoft.com]=20 Sent: Thursday, June 22, 2006 8:39 PM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause =20 Santosh, =20 There are 2 distinct reasons why your approach is not a generic solution to the problem. =20 1) The problem is generic and does not only apply to policy processing. The pki4ipsec issue was e.g. motivated from problems with EKU settings in existing certificates that does not satisfy new applications and usages. 2) If you need to test for a policy in the end certificate, that policy will not be valid unless supported by the path, regardless if policy constraints was set or not. =20 In the perfect world, compliant path processing will always do the job. In the real world, you may need to tweak the rules to make a new application fit into an existing infrastructure- =20 The question is still: Can a standards compliant implementation allow configuration of non conformant modifications to the validation process, or does that make the implementation as a whole non-conformant. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: den 22 juni 2006 22:59 To: ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause =20 Stefan, =20 I agree with sentiments voiced by Steve, Rich, and Sharon. =20 I have a simple solution to your concern from the relying party viewpoint. This observation is made with a long-held view of mine (and no one had provided a convincing logical or business argument) that the require explicit policy setting is a useless field. A relying party can always set acceptable policies to none. In that scenario, (require explicit policy) flag not withstanding, path validation will succeed. Now, the user can examine the end certificate policy. =20 You and I have had this discussion in another context. The basic premise is that if some field in the last certificate only is of interest and the "state" in the path validation process does not impact it, that need not be path of path validation engine. =20 Thus, you can judiciously use the 3280 Engine and obtain the result you seek. ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Guida, Richard [JJCUS] Sent: Thursday, June 22, 2006 2:48 PM To: Sharon Boeyen; 'Stefan Santesson'; ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause =20 Stefan - perhaps I am missing something, but there is nothing that stops a relying party from writing software that would perform processing extensions only on CA certs as you propose. As Sharon properly notes, that would not be RFC3280 compliant - but a relying party can choose to be non-compliant if it wishes. And such non-compliance only puts the relying party at risk, not others - so that is a "good thing" relatively speaking. But in the final analysis, seems to me that Sharon is absolutely correct (assuming she and I are interpreting your proposal properly) - unless X.509 is redefined, this would remain a circumstance of non-compliance. And so it should be treated as such. Very best regards -- Rich =20 =20 =20 Richard A. Guida=20 Director, Information Security=20 Johnson & Johnson=20 Room GS8217=20 410 George Street=20 New Brunswick, New Jersey 08901=20 Phone: 732 524 3785=20 -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon Boeyen Sent: Thursday, June 22, 2006 1:57 PM To: 'Stefan Santesson'; ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause Stefan, if I understand your comment correctly I strongly believe such an escape clause cannot possibly be added because this would render 3280bis non-compliant with X.509.=20 =20 My understanding of your comment is that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found in EE certificates. Is that a correct understanding?=20 =20 If it is a correct understanding, then any such implementation is non-conformant to X.509. 3280 is a profile of X.509 and as such can mandate certain optional elements or exclude optional elements but cannot reverse the mandatory processing from X.509. =20 Apologies if I've misunderstood your question. =20 Cheers, Sharon -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Wednesday, June 21, 2006 5:23 PM To: ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause As a last call comment on RFC 3280bis I would like to raise the question whether RFC 3280bis should include an escape clause clearly allowing relying parties to select what validation logic they deploy on certificate validation. =20 The background is the fact that many deployed PKIs are misconfigured.2 One such common misconfiguration is assignment of certificate policies and their inclusion in CA certificates. X.509 path processing requires policies in CA certificates to reflect the list of EE certificate policies that are valid for a path. Yet many deployments have included pure CA certificate policies in CA certificates, policies that are not included in any EE certificates and as such, policy processing is not possible in such PKIs. =20 Application wanting to use certificate policies in such PKI are simply forced to either fail or selectively neglect certain path processing rules. For a relying party such modification could be reasonable if the security implications has been well though through. However it is not clear if an implementation allowing such local configuration could be regarded as standard compliant. =20 There are more examples where deploying applications in misconfigured PKIs would need similar measures to work. =20 The pki4ipsec WG recently came to this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX WG. =20 The result was that the pki4ipsec profile included an escape clause as follows: =20 4.1. X.509 Certificates =20 Users deploying IKE and IPsec with certificates have often had little control over the capabilities of CAs available to them. Implementations of this specification may include configuration knobs to disable checks required by this specification in orde! r t o permit use with inflexible and/or noncompliant CAs. However, all checks on certificates exist for a specific reason involving the security of the entire system. Therefore, all checks MUST be enabled by default. Administrators and users ought to understand the security purpose for the various checks, and be clear on what security will be lost by disabling the check. =20 =20 I'm basically asking if RFC 3280bis path validation needs a similar escape clause or corresponding clarification that clearly allows local configuration of the validation logic. At least I think it is necessary to clearly allow such configuration of standards compliant applications as long as this is not the default functionality. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =09 ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: den 16 juni 2006 22:42 To: ietf-pkix@imc.org Subject: last call for 3280bis =20 Folks, =20 Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt ) =20 The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th. =20 Steve ------_=_NextPart_001_01C696A7.5F1E4C4B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Santosh,

 

Yes, you are correct that the path = will validate without any error in your example.

It will also have an empty set of = valid policies. So accepting the EE certificate policies as valid (using that = path) do require some kind of non-conformant policy = checking.

 

I agree on your conclusion. However = I have experienced implementers not feeling sure about this principle. = Especially when it comes to configuration options enabled by an administrative UI and = not just some mode switch in the OS.

The escape clause in pki4ipsic was = driven by this uncertainty.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: = Santosh Chokhani [mailto:chokhani@orionsec.com]
Sent: den 23 juni 2006 = 02:48
To: Stefan Santesson; ietf-pkix@imc.org
Subject: RE: last call = for 3280bis - escape clause

 

Stefan,

=

 

On disagree with you on 2. =  You seem to be asking for 2 and then saying that it is not = valid.

 

A path validation profile (assuming = we agree to ignore “require explicit policy”) with setting = acceptable policy set to anyPolicy is valid X.509 and 3280 configuration.  In = that case, there will not be a policy failure and relying party can always = make additional checks.  I encourage you to look at Section J.3 in Annex = J of X.509.  If you see any errors in Annex J, please let me = know.

 

As to Standard compliant = implementation putting itself in non-compliant mode, that is always acceptable. =  In that mode it will NOT be standard compliant; that is = all.

From: = Stefan Santesson [mailto:stefans@microsoft.com]
Sent: Thursday, June 22, = 2006 8:39 PM
To: Santosh Chokhani; ietf-pkix@imc.org
Subject: RE: last call = for 3280bis - escape clause

 

Santosh,

 

There are 2 distinct reasons why = your approach is not a generic solution to the = problem.

 

1)       = The problem is generic and does not only apply to policy processing. The pki4ipsec issue was e.g. motivated from problems with = EKU settings in existing certificates that does not satisfy new applications = and usages.

2)       = If you need to test for a policy in the end certificate, = that policy will not be valid unless supported by the path, regardless if = policy constraints was set or not.

 

In the perfect world, compliant = path processing will always do the job. In the real world, you may need to = tweak the rules to make a new application fit into an existing = infrastructure-

 

The question is still: Can a = standards compliant implementation allow configuration of non conformant = modifications to the validation process, or does that make the implementation as a whole non-conformant.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Santosh Chokhani
Sent: den 22 juni 2006 = 22:59
To: ietf-pkix@imc.org
Subject: RE: last call = for 3280bis - escape clause

 

Stefan,

=

 

I agree with sentiments voiced by = Steve, Rich, and Sharon.

 

I have a simple solution to your = concern from the relying party viewpoint.  This observation is made with a long-held view of mine (and no one had provided a convincing logical or business argument) that the require explicit policy setting is a useless = field.  A relying party can always set acceptable policies to none. =  In that scenario, (require explicit policy) flag not withstanding, path = validation will succeed.  Now, the user can examine the end certificate = policy.

 

You and I have had this discussion = in another context.  The basic premise is that if some field in the = last certificate only is of interest and the “state” in the path validation process does not impact it, that need not be path of path = validation engine.

 

Thus, you can judiciously use the = 3280 Engine and obtain the result you seek.

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Guida, Richard = [JJCUS]
Sent: Thursday, June 22, = 2006 2:48 PM
To: Sharon Boeyen; = 'Stefan Santesson'; ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

 

Stefan - perhaps I am missing = something, but there is nothing that stops a relying party from writing software = that would perform processing extensions only on CA certs as you = propose.  As Sharon properly notes, that would not be RFC3280 compliant - but a relying = party can choose to be non-compliant if it wishes.  And such non-compliance = only puts the relying party at risk, not others - so that is a = "good thing" relatively speaking.  But in the final analysis, seems = to me that Sharon is absolutely correct (assuming she and I are interpreting your proposal properly) - unless X.509 is redefined, this would remain a = circumstance of non-compliance.  And so it should be treated as such.  = Very best regards -- Rich

 

 

 

Richard A. Guida
Director, Information Security =

Johnson & = Johnson
Room GS8217
410 George Street
New Brunswick, = New Jersey  08901
Phone:  732 524 3785

-----Original = Message-----
From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon Boeyen
Sent: Thursday, June 22, = 2006 1:57 PM
To: 'Stefan Santesson'; ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

Stefan, if I understand your = comment correctly I strongly believe such an escape clause cannot possibly be = added because this would render 3280bis non-compliant with X.509. =

 

My understanding of your comment is = that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found = in EE certificates. Is that a correct understanding? =

 

If it is a correct understanding, = then any such implementation is non-conformant to X.509. 3280 is a profile of = X.509 and as such can mandate certain optional elements or exclude optional = elements but cannot reverse the mandatory processing from = X.509.

 

Apologies if I've misunderstood = your question.

 

Cheers,

=

Sharon

-----Original = Message-----
From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson
Sent: Wednesday, June 21, = 2006 5:23 PM
To: ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

As a last call comment on RFC = 3280bis I would like to raise the question whether RFC 3280bis should include an = escape clause clearly allowing relying parties to select what validation logic = they deploy on certificate validation.

 

The background is the fact that = many deployed PKIs are misconfigured.2

One such common misconfiguration is assignment of certificate policies and their inclusion in CA = certificates.

X.509 path processing requires = policies in CA certificates to reflect the list of EE certificate policies that are = valid for a path. Yet many deployments have included pure CA certificate = policies in CA certificates, policies that are not included in any EE certificates = and as such, policy processing is not possible in such = PKIs.

 

Application wanting to use = certificate policies in such PKI are simply forced to either fail or selectively = neglect certain path processing rules. For a relying party such modification = could be reasonable if the security implications has been well though = through.

However it is not clear if an implementation allowing such local configuration could be regarded as = standard compliant.

 

There are more examples where = deploying applications in misconfigured PKIs would need similar measures to = work.

 

The pki4ipsec WG recently came to = this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX = WG.

 

The result was that the pki4ipsec = profile included an escape clause as follows:

 

4.1.  X.509 =
Certificates
 
   Users deploying IKE and IPsec =
with certificates have often had =
little
   control over the capabilities of =
CAs available to them.
   Implementations of this =
specification may include configuration =
knobs
   to disable checks required by =
this specification in orde!
 r =
t
 o =
permit
   use with inflexible and/or =
noncompliant CAs.  However, all checks =
on
   certificates exist for a =
specific reason involving the security =
of
   the entire system.  =
Therefore, all checks MUST be enabled by =
default.
   Administrators and users ought =
to understand the security purpose =
for
   the various checks, and be clear =
on what security will be lost =
by
   disabling the =
check.

 

 

I'm basically asking if RFC 3280bis = path validation needs a similar escape clause or corresponding clarification = that clearly allows local configuration of the validation = logic.

At least I think it is necessary to clearly allow such configuration of standards compliant applications as = long as this is not the default functionality.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Stephen Kent
Sent: den 16 juni 2006 = 22:42
To: ietf-pkix@imc.org
Subject: last call for = 3280bis

 

Folks,

 

Based on the latest message from David Cooper, I am initiating = last call on "Internet X.509 Public Key Infrastructure, Certificate and = Certificate Revocation List (CRL) Profile" = (http://ietf.org/internet-drafts/draft-ietf-pki= x-rfc3280bis-03.txt)

 

The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many = folks), all comments must be received by July 5th.

 

Steve

------_=_NextPart_001_01C696A7.5F1E4C4B-- From owner-ietf-pkix@mail.imc.org Fri Jun 23 07:44:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftk5m-0003jB-PJ for pkix-archive@lists.ietf.org; Fri, 23 Jun 2006 07:44:54 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftk5l-00013r-4g for pkix-archive@lists.ietf.org; Fri, 23 Jun 2006 07:44:54 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5N9sWww039358; Fri, 23 Jun 2006 02:54:32 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5N9sWSq039357; Fri, 23 Jun 2006 02:54:32 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5N9sUv1039334 for ; Fri, 23 Jun 2006 02:54:31 -0700 (MST) (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); Fri, 23 Jun 2006 10:54:27 +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: SRV Name: draft-ietf-pkix-srvsan-02.txt: typos, examples Date: Fri, 23 Jun 2006 10:54:26 +0100 Message-ID: In-Reply-To: <6215401E01247448A306C54F499111F2C4AB35@WSMSG2103V.srv.dir.telstra.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SRV Name: draft-ietf-pkix-srvsan-02.txt: typos, examples thread-index: AcaWWVJxh0AAs+BBSLGoi/jkDBS2aQAEuBXgAA8httA= From: "Stefan Santesson" To: "Manger, James H" , X-OriginalArrivalTime: 23 Jun 2006 09:54:27.0346 (UTC) FILETIME=[03C51720:01C696AB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k5N9sVv1039352 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Thanks for the review James, Comments in-line, Stefan Santesson Senior Program Manager Windows Security, Standards -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Manger, James H Sent: den 23 juni 2006 06:50 To: ietf-pkix@imc.org Subject: SRV Name: draft-ietf-pkix-srvsan-02.txt: typos, examples Comments on draft-ietf-pkix-srvsan-02.txt 1. Abstract, page 1, typo: "filed" -> "field" Will be fixed 2. It would be nice if the full value of the id-on-dnsSRV object identifier was provided in this document, without requiring a separate lookup of RFC 3280. Add the following ASN.1 comment just above the id-on definition in Appendix A.1 (page 8), Appendix A.2 (page 8) and section 2 "Name Definitions" (page 3): -- id-pkix OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7} OK 3. Include an example with an IDN so it is immediately obvious that punycode is not used in an SRVName value. Add the following after the current example in section 2, page 4: Example: The "mail" service at nave.net (an IDN, which becomes xn--nave-6pa.net when encoded as an IDNA) would use the following 15-character SRVName value: _mail.nave.net Its 16-byte UTF-8 encoding is (in hex): 5F 6D 61 69 6C 2E 6E 61 C3 AF 76 65 2E 6E 65 74 Thanks for providing the sample. Looks fine to me. 4. Appendix A.2 (page 9), glitch: "permanentIdentifier" -> "srvName" OK I'm caught. Yes I borrowed some constructions from the PI draft. Thought I got that fixed. 5. Why bother with the (SIZE (1..MAX)) restriction? Delete it. It seems to be the custom to use it. I don't feel enough of an ASN.1 expert to have the correct answer. Someone else may have an opinon. I'll be happy to remove it as long as it works. 6. SRVName is defined (in section 2) to have the form _Service.Name. The very next section violates that definition by allowing SRVName to hold just a service name or just a domain name. The syntax to hold a name is not necessarily the same syntax required to hold a matching rule for that name. This is a general fault with the construction of the nameConstraints extension so it does not need to be fixed in this specification (I am just having a rant). Yes, as you state yourself. The actual name in SAN and matching data in name constraints have different syntax rules. Simply to avoid definition of wildcards. I think its fin as it is. 7. Appendix A, page 7: "augmented with 1993 the UNIVERSAL Type" -> "augmented with the 1993 UNIVERSAL Type" OK 8. Appendix A. Are the modules names supposed to end with "..SAN88" and "..SAN93", or is it supposed to be "..ASN88" and "..ASN93"? The current names are the names assigned by Russ, -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Internet-Drafts@ietf.org Sent: Friday, 23 June 2006 8:50 AM To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org Subject: I-D ACTION:draft-ietf-pkix-srvsan-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure Subject Alternative Name for expression of service name Author(s) : S. Santesson Filename : draft-ietf-pkix-srvsan-02.txt Pages : 11 Date : 2006-6-22 This document defines a new name form for inclusion in the otherName filed of an X.509 Subject Alternative Name extension which allows a certificate subject to be associated with the service name and domain name components of a DNS Service Resource Record. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-srvsan-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-srvsan-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-srvsan-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. From owner-ietf-pkix@mail.imc.org Fri Jun 23 08:42:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftkym-0000jm-By for pkix-archive@lists.ietf.org; Fri, 23 Jun 2006 08:41:44 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftkwa-0002V6-IA for pkix-archive@lists.ietf.org; Fri, 23 Jun 2006 08:39:30 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5NBiOrt065702; Fri, 23 Jun 2006 04:44:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5NBiOb2065701; Fri, 23 Jun 2006 04:44:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5NBiNHZ065677 for ; Fri, 23 Jun 2006 04:44:24 -0700 (MST) (envelope-from chokhani@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C696BA.DCDC9215" Subject: RE: last call for 3280bis - escape clause Date: Fri, 23 Jun 2006 04:44:17 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C8790359DB6E@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: last call for 3280bis - escape clause Thread-Index: AcaWNVMoloaBo6PDT0CPPD74liD0jQAB/dsAAAeBmuAAAJmXEAAN+MPwAAkZyFA= From: "Santosh Chokhani" To: Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.3 (/) X-Scan-Signature: 81468ae926437b8bac20657ee05e0894 This is a multi-part message in MIME format. ------_=_NextPart_001_01C696BA.DCDC9215 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stefan, =20 We seem to be converging. =20 The way the relying party should see it and that is why I find the path processing to be compliant with X.509 and 3280 is as follows: =20 The path is good for no policies. The relying party accepts a path that is not good for any policy and makes an additional check (which the standards permit) to see if the end certificate has the desired policy. =20 I hope this clarifies the standard compliance. ________________________________ From: Stefan Santesson [mailto:stefans@microsoft.com]=20 Sent: Friday, June 23, 2006 5:28 AM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause =20 Santosh, =20 Yes, you are correct that the path will validate without any error in your example.=20 It will also have an empty set of valid policies. So accepting the EE certificate policies as valid (using that path) do require some kind of non-conformant policy checking. =20 I agree on your conclusion. However I have experienced implementers not feeling sure about this principle. Especially when it comes to configuration options enabled by an administrative UI and not just some mode switch in the OS. The escape clause in pki4ipsic was driven by this uncertainty. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards ________________________________ From: Santosh Chokhani [mailto:chokhani@orionsec.com]=20 Sent: den 23 juni 2006 02:48 To: Stefan Santesson; ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause =20 Stefan, =20 On disagree with you on 2. You seem to be asking for 2 and then saying that it is not valid. =20 A path validation profile (assuming we agree to ignore "require explicit policy") with setting acceptable policy set to anyPolicy is valid X.509 and 3280 configuration. In that case, there will not be a policy failure and relying party can always make additional checks. I encourage you to look at Section J.3 in Annex J of X.509. If you see any errors in Annex J, please let me know. =20 As to Standard compliant implementation putting itself in non-compliant mode, that is always acceptable. In that mode it will NOT be standard compliant; that is all. ________________________________ From: Stefan Santesson [mailto:stefans@microsoft.com]=20 Sent: Thursday, June 22, 2006 8:39 PM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause =20 Santosh, =20 There are 2 distinct reasons why your approach is not a generic solution to the problem. =20 1) The problem is generic and does not only apply to policy processing. The pki4ipsec issue was e.g. motivated from problems with EKU settings in existing certificates that does not satisfy new applications and usages. 2) If you need to test for a policy in the end certificate, that policy will not be valid unless supported by the path, regardless if policy constraints was set or not. =20 In the perfect world, compliant path processing will always do the job. In the real world, you may need to tweak the rules to make a new application fit into an existing infrastructure- =20 The question is still: Can a standards compliant implementation allow configuration of non conformant modifications to the validation process, or does that make the implementation as a whole non-conformant. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: den 22 juni 2006 22:59 To: ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause =20 Stefan, =20 I agree with sentiments voiced by Steve, Rich, and Sharon. =20 I have a simple solution to your concern from the relying party viewpoint. This observation is made with a long-held view of mine (and no one had provided a convincing logical or business argument) that the require explicit policy setting is a useless field. A relying party can always set acceptable policies to none. In that scenario, (require explicit policy) flag not withstanding, path validation will succeed. Now, the user can examine the end certificate policy. =20 You and I have had this discussion in another context. The basic premise is that if some field in the last certificate only is of interest and the "state" in the path validation process does not impact it, that need not be path of path validation engine. =20 Thus, you can judiciously use the 3280 Engine and obtain the result you seek. ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Guida, Richard [JJCUS] Sent: Thursday, June 22, 2006 2:48 PM To: Sharon Boeyen; 'Stefan Santesson'; ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause =20 Stefan - perhaps I am missing something, but there is nothing that stops a relying party from writing software that would perform processing extensions only on CA certs as you propose. As Sharon properly notes, that would not be RFC3280 compliant - but a relying party can choose to be non-compliant if it wishes. And such non-compliance only puts the relying party at risk, not others - so that is a "good thing" relatively speaking. But in the final analysis, seems to me that Sharon is absolutely correct (assuming she and I are interpreting your proposal properly) - unless X.509 is redefined, this would remain a circumstance of non-compliance. And so it should be treated as such. Very best regards -- Rich =20 =20 =20 Richard A. Guida=20 Director, Information Security=20 Johnson & Johnson=20 Room GS8217=20 410 George Street=20 New Brunswick, New Jersey 08901=20 Phone: 732 524 3785=20 -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon Boeyen Sent: Thursday, June 22, 2006 1:57 PM To: 'Stefan Santesson'; ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause Stefan, if I understand your comment correctly I strongly believe such an escape clause cannot possibly be added because this would render 3280bis non-compliant with X.509.=20 =20 My understanding of your comment is that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found in EE certificates. Is that a correct understanding?=20 =20 If it is a correct understanding, then any such implementation is non-conformant to X.509. 3280 is a profile of X.509 and as such can mandate certain optional elements or exclude optional elements but cannot reverse the mandatory processing from X.509. =20 Apologies if I've misunderstood your question. =20 Cheers, Sharon -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Wednesday, June 21, 2006 5:23 PM To: ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause As a last call comment on RFC 3280bis I would like to raise the question whether RFC 3280bis should include an escape clause clearly allowing relying parties to select what validation logic they deploy on certificate validation. =20 The background is the fact that many deployed PKIs are misconfigured.2 One such common misconfiguration is assignment of certificate policies and their inclusion in CA certificates. X.509 path processing requires policies in CA certificates to reflect the list of EE certificate policies that are valid for a path. Yet many deployments have included pure CA certificate policies in CA certificates, policies that are not included in any EE certificates and as such, policy processing is not possible in such PKIs. =20 Application wanting to use certificate policies in such PKI are simply forced to either fail or selectively neglect certain path processing rules. For a relying party such modification could be reasonable if the security implications has been well though through. However it is not clear if an implementation allowing such local configuration could be regarded as standard compliant. =20 There are more examples where deploying applications in misconfigured PKIs would need similar measures to work. =20 The pki4ipsec WG recently came to this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX WG. =20 The result was that the pki4ipsec profile included an escape clause as follows: =20 4.1. X.509 Certificates =20 Users deploying IKE and IPsec with certificates have often had little control over the capabilities of CAs available to them. Implementations of this specification may include configuration knobs to disable checks required by this specification in orde! r t o permit use with inflexible and/or noncompliant CAs. However, all checks on certificates exist for a specific reason involving the security of the entire system. Therefore, all checks MUST be enabled by default. Administrators and users ought to understand the security purpose for the various checks, and be clear on what security will be lost by disabling the check. =20 =20 I'm basically asking if RFC 3280bis path validation needs a similar escape clause or corresponding clarification that clearly allows local configuration of the validation logic. At least I think it is necessary to clearly allow such configuration of standards compliant applications as long as this is not the default functionality. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =09 ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: den 16 juni 2006 22:42 To: ietf-pkix@imc.org Subject: last call for 3280bis =20 Folks, =20 Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt ) =20 The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th. =20 Steve ------_=_NextPart_001_01C696BA.DCDC9215 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Stefan,

=

 

We seem to be = converging.

 

The way the relying party should = see it and that is why I find the path processing to be compliant with X.509 = and 3280 is as follows:

 

The path is good for no = policies.  The relying party accepts a path that is not good for any policy and makes = an additional check (which the standards permit) to see if the end = certificate has the desired policy.

 

I hope this clarifies the standard compliance.

From: = Stefan Santesson [mailto:stefans@microsoft.com]
Sent: Friday, June 23, = 2006 5:28 AM
To: Santosh Chokhani; ietf-pkix@imc.org
Subject: RE: last call = for 3280bis - escape clause

 

Santosh,

 

Yes, you are correct that the path = will validate without any error in your example. =

It will also have an empty set of = valid policies. So accepting the EE certificate policies as valid (using that = path) do require some kind of non-conformant policy = checking.

 

I agree on your conclusion. However = I have experienced implementers not feeling sure about this principle. = Especially when it comes to configuration options enabled by an administrative UI and = not just some mode switch in the OS.

The escape clause in pki4ipsic was = driven by this uncertainty.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: = Santosh Chokhani [mailto:chokhani@orionsec.com]
Sent: den 23 juni 2006 = 02:48
To: Stefan Santesson; ietf-pkix@imc.org
Subject: RE: last call = for 3280bis - escape clause

 

Stefan,

=

 

On disagree with you on 2. =  You seem to be asking for 2 and then saying that it is not = valid.

 

A path validation profile (assuming = we agree to ignore “require explicit policy”) with setting = acceptable policy set to anyPolicy is valid X.509 and 3280 configuration.  In = that case, there will not be a policy failure and relying party can always = make additional checks.  I encourage you to look at Section J.3 in Annex = J of X.509.  If you see any errors in Annex J, please let me = know.

 

As to Standard compliant = implementation putting itself in non-compliant mode, that is always acceptable. =  In that mode it will NOT be standard compliant; that is = all.

From: = Stefan Santesson [mailto:stefans@microsoft.com]
Sent: Thursday, June 22, = 2006 8:39 PM
To: Santosh Chokhani; ietf-pkix@imc.org
Subject: RE: last call = for 3280bis - escape clause

 

Santosh,

 

There are 2 distinct reasons why = your approach is not a generic solution to the = problem.

 

1)       = The problem is generic and does not only apply to policy processing. The pki4ipsec issue was e.g. motivated from problems with = EKU settings in existing certificates that does not satisfy new applications = and usages.

2)       = If you need to test for a policy in the end certificate, = that policy will not be valid unless supported by the path, regardless if = policy constraints was set or not.

 

In the perfect world, compliant = path processing will always do the job. In the real world, you may need to = tweak the rules to make a new application fit into an existing = infrastructure-

 

The question is still: Can a = standards compliant implementation allow configuration of non conformant = modifications to the validation process, or does that make the implementation as a whole non-conformant.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Santosh Chokhani
Sent: den 22 juni 2006 = 22:59
To: ietf-pkix@imc.org
Subject: RE: last call = for 3280bis - escape clause

 

Stefan,

=

 

I agree with sentiments voiced by = Steve, Rich, and Sharon.

 

I have a simple solution to your = concern from the relying party viewpoint.  This observation is made with a = long-held view of mine (and no one had provided a convincing logical or business argument) that the require explicit policy setting is a useless field. =  A relying party can always set acceptable policies to none.  In that scenario, (require explicit policy) flag not withstanding, path = validation will succeed.  Now, the user can examine the end certificate = policy.

 

You and I have had this discussion = in another context.  The basic premise is that if some field in the = last certificate only is of interest and the “state” in the path validation process does not impact it, that need not be path of path = validation engine.

 

Thus, you can judiciously use the = 3280 Engine and obtain the result you seek.

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Guida, Richard = [JJCUS]
Sent: Thursday, June 22, = 2006 2:48 PM
To: Sharon Boeyen; = 'Stefan Santesson'; ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

 

Stefan - perhaps I am missing = something, but there is nothing that stops a relying party from writing software = that would perform processing extensions only on CA certs as you = propose.  As Sharon properly notes, that would not be RFC3280 compliant - but a relying = party can choose to be non-compliant if it wishes.  And such non-compliance = only puts the relying party at risk, not others - so that is a = "good thing" relatively speaking.  But in the final analysis, seems = to me that Sharon is absolutely correct (assuming she and I are interpreting your proposal properly) - unless X.509 is redefined, this would remain a = circumstance of non-compliance.  And so it should be treated as such.  = Very best regards -- Rich

 

 

 

Richard A. Guida
Director, Information Security =

Johnson & = Johnson
Room GS8217
410 George Street
New Brunswick, = New Jersey  08901
Phone:  732 524 3785

-----Original = Message-----
From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon Boeyen
Sent: Thursday, June 22, = 2006 1:57 PM
To: 'Stefan Santesson'; ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

Stefan, if I understand your = comment correctly I strongly believe such an escape clause cannot possibly be = added because this would render 3280bis non-compliant with X.509. =

 

My understanding of your comment is = that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found = in EE certificates. Is that a correct understanding? =

 

If it is a correct understanding, = then any such implementation is non-conformant to X.509. 3280 is a profile of = X.509 and as such can mandate certain optional elements or exclude optional = elements but cannot reverse the mandatory processing from = X.509.

 

Apologies if I've misunderstood = your question.

 

Cheers,

=

Sharon

-----Original = Message-----
From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson
Sent: Wednesday, June 21, = 2006 5:23 PM
To: ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

As a last call comment on RFC = 3280bis I would like to raise the question whether RFC 3280bis should include an = escape clause clearly allowing relying parties to select what validation logic = they deploy on certificate validation.

 

The background is the fact that = many deployed PKIs are misconfigured.2

One such common misconfiguration is assignment of certificate policies and their inclusion in CA = certificates.

X.509 path processing requires = policies in CA certificates to reflect the list of EE certificate policies that are = valid for a path. Yet many deployments have included pure CA certificate = policies in CA certificates, policies that are not included in any EE certificates = and as such, policy processing is not possible in such = PKIs.

 

Application wanting to use = certificate policies in such PKI are simply forced to either fail or selectively = neglect certain path processing rules. For a relying party such modification = could be reasonable if the security implications has been well though = through.

However it is not clear if an implementation allowing such local configuration could be regarded as = standard compliant.

 

There are more examples where = deploying applications in misconfigured PKIs would need similar measures to = work.

 

The pki4ipsec WG recently came to = this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX = WG.

 

The result was that the pki4ipsec = profile included an escape clause as follows:

 

4.1.  X.509 =
Certificates
 
   Users deploying IKE and IPsec =
with certificates have often had =
little
   control over the capabilities of =
CAs available to them.
   Implementations of this =
specification may include configuration =
knobs
   to disable checks required by =
this specification in orde!
 r =
t
 o =
permit
   use with inflexible and/or =
noncompliant CAs.  However, all checks =
on
   certificates exist for a =
specific reason involving the security =
of
   the entire system.  =
Therefore, all checks MUST be enabled by =
default.
   Administrators and users ought =
to understand the security purpose =
for
   the various checks, and be clear =
on what security will be lost =
by
   disabling the =
check.

 

 

I'm basically asking if RFC 3280bis = path validation needs a similar escape clause or corresponding clarification = that clearly allows local configuration of the validation = logic.

At least I think it is necessary to clearly allow such configuration of standards compliant applications as = long as this is not the default functionality.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Stephen Kent
Sent: den 16 juni 2006 = 22:42
To: ietf-pkix@imc.org
Subject: last call for = 3280bis

 

Folks,

 

Based on the latest message from David Cooper, I am initiating = last call on "Internet X.509 Public Key Infrastructure, Certificate and = Certificate Revocation List (CRL) Profile" = (http://ietf.org/internet-drafts/draft-ietf-pki= x-rfc3280bis-03.txt)

 

The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many = folks), all comments must be received by July 5th.

 

Steve

------_=_NextPart_001_01C696BA.DCDC9215-- From owner-ietf-pkix@mail.imc.org Fri Jun 23 08:58:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtlFG-00063t-Li for pkix-archive@lists.ietf.org; Fri, 23 Jun 2006 08:58:46 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtlFF-00048M-Ac for pkix-archive@lists.ietf.org; Fri, 23 Jun 2006 08:58:46 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5NC3e1F069973; Fri, 23 Jun 2006 05:03:40 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5NC3e7g069972; Fri, 23 Jun 2006 05:03:40 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from omta05ps.mx.bigpond.com (omta05ps.mx.bigpond.com [144.140.83.195]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5NC3dAY069950 for ; Fri, 23 Jun 2006 05:03:40 -0700 (MST) (envelope-from bradh@frogmouth.net) Received: from prionotes.cuneata.net ([61.9.204.42]) by omta05ps.mx.bigpond.com with ESMTP id <20060623120328.PCOK16234.omta05ps.mx.bigpond.com@prionotes.cuneata.net>; Fri, 23 Jun 2006 12:03:28 +0000 From: Brad Hards To: Sharon Boeyen Subject: Re: last call for 3280bis - escape clause Date: Fri, 23 Jun 2006 22:02:43 +1000 User-Agent: KMail/1.9.1 Cc: ietf-pkix@imc.org References: <7A3E1242FA9989439AD1F9B2D71C287F09EAD1B5@sottmxs05.entrust.com> In-Reply-To: <7A3E1242FA9989439AD1F9B2D71C287F09EAD1B5@sottmxs05.entrust.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart8723954.v22oNSQp9r"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200606232202.51448.bradh@frogmouth.net> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 --nextPart8723954.v22oNSQp9r Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 23 June 2006 21:12 pm, Sharon Boeyen wrote: > There should not be any escape clause in 3280bis for any non-conformant > behavior. 3280bis is a profile of X.509 - it is not a narrative to descri= be > various types of non-conformant behavior, regardless of what it is. Perhaps there might be a role for an Informational RFC that explains the=20 various issues that are a source of concern. Ideally it would provide some= =20 guidance on how to deal with the non-conformant behaviour. At the very leas= t=20 it could explain the consequences of particular courses of action. Brad --nextPart8723954.v22oNSQp9r Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBEm9hrGwwszQ/PZzgRAsYHAJ97yDRdQCj1Tsw6xGL+ZiJGZDCDMACfRt3k kVrwNyKjMIhq92lvDgd2xdU= =o2Dn -----END PGP SIGNATURE----- --nextPart8723954.v22oNSQp9r-- From owner-ietf-pkix@mail.imc.org Fri Jun 23 11:10:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtnIU-0003oQ-55 for pkix-archive@lists.ietf.org; Fri, 23 Jun 2006 11:10:14 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtkhX-0005uO-Ng for pkix-archive@lists.ietf.org; Fri, 23 Jun 2006 08:23:55 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtkUB-0000mb-F3 for pkix-archive@lists.ietf.org; Fri, 23 Jun 2006 08:10:09 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5NBCRZN058181; Fri, 23 Jun 2006 04:12:27 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5NBCRoe058180; Fri, 23 Jun 2006 04:12:27 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sottsym2.entrust.com (sottsym2.entrust.com [216.191.252.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5NBCPir058132 for ; Fri, 23 Jun 2006 04:12:25 -0700 (MST) (envelope-from sharon.boeyen@entrust.com) Received: from sottmxsecs3.entrust.com (unknown [216.191.252.14]) by sottsym2.entrust.com (Symantec Mail Security) with SMTP id D0D1811F6 for ; Fri, 23 Jun 2006 07:12:19 -0400 (EDT) Received: (qmail 28716 invoked from network); 23 Jun 2006 11:12:19 -0000 Received: from sharon.boeyen@entrust.com by sottmxsecs3.entrust.com with EntrustECS-Server-7.4;23 Jun 2006 11:12:19 -0000 Received: from sottmxs00.entrust.com (10.4.61.22) by sottmxsecs3.entrust.com with SMTP; 23 Jun 2006 11:12:17 -0000 Received: by sottmxs00.entrust.com with Internet Mail Service (5.5.2657.72) id ; Fri, 23 Jun 2006 07:12:18 -0400 Message-ID: <7A3E1242FA9989439AD1F9B2D71C287F09EAD1B5@sottmxs05.entrust.com> From: Sharon Boeyen To: "'Stefan Santesson'" , Santosh Chokhani , ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause Date: Fri, 23 Jun 2006 07:12:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C696B5.8CC0B636" X-Brightmail-Tracker: AAAAAA== Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: -2.5 (--) X-Scan-Signature: a3e5bce76cb320ccc764f9fd0d0fae2f This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C696B5.8CC0B636 Content-Type: text/plain There should not be any escape clause in 3280bis for any non-conformant behavior. 3280bis is a profile of X.509 - it is not a narrative to describe various types of non-conformant behavior, regardless of what it is. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Friday, June 23, 2006 5:28 AM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause Santosh, Yes, you are correct that the path will validate without any error in your example. It will also have an empty set of valid policies. So accepting the EE certificate policies as valid (using that path) do require some kind of non-conformant policy checking. I agree on your conclusion. However I have experienced implementers not feeling sure about this principle. Especially when it comes to configuration options enabled by an administrative UI and not just some mode switch in the OS. The escape clause in pki4ipsic was driven by this uncertainty. Stefan Santesson Senior Program Manager Windows Security, Standards _____ From: Santosh Chokhani [mailto:chokhani@orionsec.com] Sent: den 23 juni 2006 02:48 To: Stefan Santesson; ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause Stefan, On disagree with you on 2. You seem to be asking for 2 and then saying that it is not valid. A path validation profile (assuming we agree to ignore "require explicit policy") with setting acceptable policy set to anyPolicy is valid X.509 and 3280 configuration. In that case, there will not be a policy failure and relying party can always make additional checks. I encourage you to look at Section J.3 in Annex J of X.509. If you see any errors in Annex J, please let me know. As to Standard compliant implementation putting itself in non-compliant mode, that is always acceptable. In that mode it will NOT be standard compliant; that is all. _____ From: Stefan Santesson [mailto:stefans@microsoft.com] Sent: Thursday, June 22, 2006 8:39 PM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause Santosh, There are 2 distinct reasons why your approach is not a generic solution to the problem. 1) The problem is generic and does not only apply to policy processing. The pki4ipsec issue was e.g. motivated from problems with EKU settings in existing certificates that does not satisfy new applications and usages. 2) If you need to test for a policy in the end certificate, that policy will not be valid unless supported by the path, regardless if policy constraints was set or not. In the perfect world, compliant path processing will always do the job. In the real world, you may need to tweak the rules to make a new application fit into an existing infrastructure- The question is still: Can a standards compliant implementation allow configuration of non conformant modifications to the validation process, or does that make the implementation as a whole non-conformant. Stefan Santesson Senior Program Manager Windows Security, Standards _____ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: den 22 juni 2006 22:59 To: ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause Stefan, I agree with sentiments voiced by Steve, Rich, and Sharon. I have a simple solution to your concern from the relying party viewpoint. This observation is made with a long-held view of mine (and no one had provided a convincing logical or business argument) that the require explicit policy setting is a useless field. A relying party can always set acceptable policies to none. In that scenario, (require explicit policy) flag not withstanding, path validation will succeed. Now, the user can examine the end certificate policy. You and I have had this discussion in another context. The basic premise is that if some field in the last certificate only is of interest and the "state" in the path validation process does not impact it, that need not be path of path validation engine. Thus, you can judiciously use the 3280 Engine and obtain the result you seek. _____ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Guida, Richard [JJCUS] Sent: Thursday, June 22, 2006 2:48 PM To: Sharon Boeyen; 'Stefan Santesson'; ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause Stefan - perhaps I am missing something, but there is nothing that stops a relying party from writing software that would perform processing extensions only on CA certs as you propose. As Sharon properly notes, that would not be RFC3280 compliant - but a relying party can choose to be non-compliant if it wishes. And such non-compliance only puts the relying party at risk, not others - so that is a "good thing" relatively speaking. But in the final analysis, seems to me that Sharon is absolutely correct (assuming she and I are interpreting your proposal properly) - unless X.509 is redefined, this would remain a circumstance of non-compliance. And so it should be treated as such. Very best regards -- Rich Richard A. Guida Director, Information Security Johnson & Johnson Room GS8217 410 George Street New Brunswick, New Jersey 08901 Phone: 732 524 3785 -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon Boeyen Sent: Thursday, June 22, 2006 1:57 PM To: 'Stefan Santesson'; ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause Stefan, if I understand your comment correctly I strongly believe such an escape clause cannot possibly be added because this would render 3280bis non-compliant with X.509. My understanding of your comment is that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found in EE certificates. Is that a correct understanding? If it is a correct understanding, then any such implementation is non-conformant to X.509. 3280 is a profile of X.509 and as such can mandate certain optional elements or exclude optional elements but cannot reverse the mandatory processing from X.509. Apologies if I've misunderstood your question. Cheers, Sharon -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Wednesday, June 21, 2006 5:23 PM To: ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause As a last call comment on RFC 3280bis I would like to raise the question whether RFC 3280bis should include an escape clause clearly allowing relying parties to select what validation logic they deploy on certificate validation. The background is the fact that many deployed PKIs are misconfigured.2 One such common misconfiguration is assignment of certificate policies and their inclusion in CA certificates. X.509 path processing requires policies in CA certificates to reflect the list of EE certificate policies that are valid for a path. Yet many deployments have included pure CA certificate policies in CA certificates, policies that are not included in any EE certificates and as such, policy processing is not possible in such PKIs. Application wanting to use certificate policies in such PKI are simply forced to either fail or selectively neglect certain path processing rules. For a relying party such modification could be reasonable if the security implications has been well though through. However it is not clear if an implementation allowing such local configuration could be regarded as standard compliant. There are more examples where deploying applications in misconfigured PKIs would need similar measures to work. The pki4ipsec WG recently came to this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX WG. The result was that the pki4ipsec profile included an escape clause as follows: 4.1. X.509 Certificates Users deploying IKE and IPsec with certificates have often had little control over the capabilities of CAs available to them. Implementations of this specification may include configuration knobs to disable checks required by this specification in orde! r t o permit use with inflexible and/or noncompliant CAs. However, all checks on certificates exist for a specific reason involving the security of the entire system. Therefore, all checks MUST be enabled by default. Administrators and users ought to understand the security purpose for the various checks, and be clear on what security will be lost by disabling the check. I'm basically asking if RFC 3280bis path validation needs a similar escape clause or corresponding clarification that clearly allows local configuration of the validation logic. At least I think it is necessary to clearly allow such configuration of standards compliant applications as long as this is not the default functionality. Stefan Santesson Senior Program Manager Windows Security, Standards _____ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: den 16 juni 2006 22:42 To: ietf-pkix@imc.org Subject: last call for 3280bis Folks, Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" ( http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt) The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th. Steve ------_=_NextPart_001_01C696B5.8CC0B636 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message
There should not be any escape clause in 3280bis for any non-conformant = behavior.=20 3280bis is a profile of X.509 - it is not a narrative to describe = various types=20 of non-conformant behavior, regardless of what it is.
-----Original = Message-----
From:=20 owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf=20 Of Stefan Santesson
Sent: Friday, June 23, 2006 5:28=20 AM
To: Santosh Chokhani; ietf-pkix@imc.org
Subject: = RE: last=20 call for 3280bis - escape clause

Santosh,

 

Yes, you = are correct=20 that the path will validate without any error in your example.=20

It will = also have an=20 empty set of valid policies. So accepting the EE certificate policies = as valid=20 (using that path) do require some kind of non-conformant policy=20 checking.

 

I agree on = your=20 conclusion. However I have experienced implementers not feeling sure = about=20 this principle. Especially when it comes to configuration options = enabled by=20 an administrative UI and not just some mode switch in the=20 OS.

The escape = clause in=20 pki4ipsic was driven by this = uncertainty.

 

 

Stefan=20 Santesson

Senior = Program=20 Manager

Windows = Security,=20 Standards

From: Santosh=20 Chokhani [mailto:chokhani@orionsec.com]
Sent: den 23 juni 2006 = 02:48
To: Stefan Santesson;=20 ietf-pkix@imc.org
Subject:=20 RE: last call for 3280bis - escape = clause

 

Stefan,

 

On = disagree with you=20 on 2.  You seem to be asking for 2 and then saying that it is = not=20 valid.

 

A path = validation=20 profile (assuming we agree to ignore "require explicit policy") with = setting=20 acceptable policy set to anyPolicy is valid X.509 and 3280 = configuration.=20  In that case, there will not be a policy failure and relying = party can=20 always make additional checks.  I encourage you to look at = Section J.3 in=20 Annex J of X.509.  If you see any errors in Annex J, please let = me=20 know.

 

As to = Standard=20 compliant implementation putting itself in non-compliant mode, that = is always=20 acceptable.  In that mode it will NOT be standard compliant; = that is=20 all.

From: Stefan=20 Santesson [mailto:stefans@microsoft.com]
Sent: Thursday, June 22, 2006 = 8:39=20 PM
To: Santosh = Chokhani;=20 ietf-pkix@imc.org
Subject:=20 RE: last call for 3280bis - escape = clause

 

Santosh,

 

There are = 2 distinct=20 reasons why your approach is not a generic solution to the=20 problem.

 

1)      =20 The=20 problem is generic and does not only apply to policy processing. The = pki4ipsec=20 issue was e.g. motivated from problems with EKU settings in existing=20 certificates that does not satisfy new applications and=20 usages.

2)      =20 If you=20 need to test for a policy in the end certificate, that policy will = not be=20 valid unless supported by the path, regardless if policy constraints = was set=20 or not.

 

In the = perfect world,=20 compliant path processing will always do the job. In the real world, = you may=20 need to tweak the rules to make a new application fit into an = existing=20 infrastructure-

 

The = question is=20 still: Can a standards compliant implementation allow configuration = of non=20 conformant modifications to the validation process, or does that make = the=20 implementation as a whole = non-conformant.

 

 

Stefan=20 Santesson

Senior = Program=20 Manager

Windows = Security,=20 Standards

From:=20 owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Santosh = Chokhani
Sent: den 22 juni 2006 = 22:59
To: = ietf-pkix@imc.org
Subject: RE: last call for = 3280bis -=20 escape clause

 

Stefan,

 

I agree = with=20 sentiments voiced by Steve, Rich, and = Sharon.

 

I have a = simple=20 solution to your concern from the relying party viewpoint.  This = observation is made with a long-held view of mine (and no one had = provided a=20 convincing logical or business argument) that the require explicit = policy=20 setting is a useless field.  A relying party can always set = acceptable=20 policies to none.  In that scenario, (require explicit policy) = flag not=20 withstanding, path validation will succeed.  Now, the user can = examine=20 the end certificate policy.

 

You and I = have had=20 this discussion in another context.  The basic premise is that = if some=20 field in the last certificate only is of interest and the "state" in = the path=20 validation process does not impact it, that need not be path of path=20 validation engine.

 

Thus, you = can=20 judiciously use the 3280 Engine and obtain the result you=20 seek.

From:=20 owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Guida, Richard=20 [JJCUS]
Sent: = Thursday, June=20 22, 2006 2:48 PM
To: Sharon=20 Boeyen; 'Stefan Santesson'; ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call for = 3280bis -=20 escape clause

 

Stefan - = perhaps I am=20 missing something, but there is nothing that stops a relying party = from=20 writing software that would perform processing extensions only = on CA=20 certs as you propose.  As Sharon properly notes, that would = not be=20 RFC3280 compliant - but a relying party can choose to be = non-compliant if it=20 wishes.  And such non-compliance only puts the relying party at = risk, not=20 others - so that is a "good thing" relatively speaking.  = But in the=20 final analysis, seems to me that Sharon is absolutely correct = (assuming she=20 and I are interpreting your proposal properly) - unless X.509 is = redefined, this would remain a circumstance of non-compliance.  = And so it=20 should be treated as such.  Very best regards --=20 Rich

 

 

 

Richard A.=20 Guida
Director,=20 Information Security

Johnson=20 & Johnson
Room = GS8217=20
410 George Street=20
New Brunswick, = New Jersey  08901 =
Phone:  732 524=20 3785

-----Original=20 Message-----
From:=20 owner-ietf-pkix@mail.imc.org = [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon = Boeyen
Sent: Thursday, June 22, = 2006 1:57=20 PM
To: 'Stefan = Santesson';=20 ietf-pkix@imc.org
Cc:=20 Stephen Kent
Subject: RE:=20 last call for 3280bis - escape clause

Stefan, = if I=20 understand your comment correctly I strongly believe such an escape = clause=20 cannot possibly be added because this would render 3280bis = non-compliant=20 with X.509.

 

My = understanding of=20 your comment is that the escape clause would enable a path = validation engine=20 to process the certificate policy OIDs found in CA certificates but = ignore=20 those found in EE certificates. Is that a correct understanding?=20

 

If it is = a correct=20 understanding, then any such implementation is non-conformant to = X.509. 3280=20 is a profile of X.509 and as such can mandate certain optional = elements or=20 exclude optional elements but cannot reverse the mandatory = processing from=20 X.509.

 

Apologies if I've=20 misunderstood your question.

 

Cheers,

Sharon

-----Original=20 Message-----
From:=20 owner-ietf-pkix@mail.imc.org = [mailto:owner-ietf-pkix@mail.imc.org]=20 On Behalf Of = Stefan=20 Santesson
Sent:=20 Wednesday, June 21, 2006 5:23 PM
To: = ietf-pkix@imc.org
Cc: Stephen = Kent
Subject: RE: last call for = 3280bis -=20 escape clause

As a = last call=20 comment on RFC 3280bis I would like to raise the question whether = RFC=20 3280bis should include an escape clause clearly allowing relying = parties=20 to select what validation logic they deploy on certificate=20 validation.

 

The = background is=20 the fact that many deployed PKIs are=20 misconfigured.2

One = such common=20 misconfiguration is assignment of certificate policies and their = inclusion=20 in CA certificates.

X.509 = path=20 processing requires policies in CA certificates to reflect the = list of EE=20 certificate policies that are valid for a path. Yet many = deployments have=20 included pure CA certificate policies in CA certificates, = policies that=20 are not included in any EE certificates and as such, policy = processing is=20 not possible in such PKIs.

 

Application=20 wanting to use certificate policies in such PKI are simply forced = to=20 either fail or selectively neglect certain path processing rules. = For a=20 relying party such modification could be reasonable if the = security=20 implications has been well though = through.

However it is not=20 clear if an implementation allowing such local configuration = could be=20 regarded as standard compliant.

 

There = are more=20 examples where deploying applications in misconfigured PKIs would = need=20 similar measures to work.

 

The = pki4ipsec WG=20 recently came to this conclusion in their PKI profile and this = lead to an=20 intense debate which included core participants from the PKIX=20 WG.

 

The = result was=20 that the pki4ipsec profile included an escape clause as=20 follows:

 

4.1.  X.509 =
Certificates
 
   Users =
deploying IKE and IPsec with certificates have often had =
little
   control over the =
capabilities of CAs available to =
them.
   Implementations =
of this specification may include configuration =
knobs
   to disable checks =
required by this specification in =
orde!
 r =
t
 o =
permit
   use with =
inflexible and/or noncompliant CAs.  However, all checks =
on
   certificates =
exist for a specific reason involving the security =
of
   the entire =
system.  Therefore, all checks MUST be enabled by =
default.
   Administrators =
and users ought to understand the security purpose =
for
   the various =
checks, and be clear on what security will be lost =
by
   disabling the =
check.

 

 

I'm = basically=20 asking if RFC 3280bis path validation needs a similar escape = clause or=20 corresponding clarification that clearly allows local = configuration of the=20 validation logic.

At = least I think=20 it is necessary to clearly allow such configuration of standards = compliant=20 applications as long as this is not the default=20 functionality.

 

 

Stefan=20 Santesson

Senior Program=20 Manager

Windows=20 Security, = Standards

From:=20 owner-ietf-pkix@mail.imc.org = [mailto:owner-ietf-pkix@mail.imc.org]=20 On Behalf Of = Stephen=20 Kent
Sent: den = 16 juni=20 2006 22:42
To: = ietf-pkix@imc.org
Subject: last call for=20 3280bis

 

Folks,

 

Based on the latest message from David = Cooper, I=20 am initiating last call on "Internet X.509 Public Key = Infrastructure,=20 Certificate and Certificate Revocation List (CRL)=20 Profile" (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt<= /SPAN>)

 

The last call will last for two weeks. = In=20 deference to the U.S. Independence Dya holiday (which means July = 3rd is a=20 holiday for many folks), all comments must be received by July=20 5th.

 

Steve

= ------_=_NextPart_001_01C696B5.8CC0B636-- From owner-ietf-pkix@mail.imc.org Sat Jun 24 09:19:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu82Z-0006G8-T9 for pkix-archive@lists.ietf.org; Sat, 24 Jun 2006 09:19:11 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fu82V-0007Gn-G1 for pkix-archive@lists.ietf.org; Sat, 24 Jun 2006 09:19:11 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5OC9xq4027774; Sat, 24 Jun 2006 05:09:59 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5OC9xds027773; Sat, 24 Jun 2006 05:09:59 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5OC9uGD027749 for ; Sat, 24 Jun 2006 05:09:57 -0700 (MST) (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); Sat, 24 Jun 2006 13:09:56 +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: last call for 3280bis - escape clause Date: Sat, 24 Jun 2006 13:09:53 +0100 Message-ID: In-Reply-To: <200606232202.51448.bradh@frogmouth.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: last call for 3280bis - escape clause thread-index: AcaWxUtSUooUAJ+sTSCg55Dpx2HUugAwUwtQ From: "Stefan Santesson" To: "Brad Hards" , "Sharon Boeyen" Cc: X-OriginalArrivalTime: 24 Jun 2006 12:09:56.0039 (UTC) FILETIME=[1B42F570:01C69787] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k5OC9vGD027754 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Personally I feel positive about such initiative even though I fear the volume of debates it might cause. I would like to hear the rest of the WG on this. I do acknowledge that we are facing practical problems out there that the standard can't solve today. Stefan Santesson Senior Program Manager Windows Security, Standards -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Brad Hards Sent: den 23 juni 2006 14:03 To: Sharon Boeyen Cc: ietf-pkix@imc.org Subject: Re: last call for 3280bis - escape clause On Friday 23 June 2006 21:12 pm, Sharon Boeyen wrote: > There should not be any escape clause in 3280bis for any non-conformant > behavior. 3280bis is a profile of X.509 - it is not a narrative to describe > various types of non-conformant behavior, regardless of what it is. Perhaps there might be a role for an Informational RFC that explains the various issues that are a source of concern. Ideally it would provide some guidance on how to deal with the non-conformant behaviour. At the very least it could explain the consequences of particular courses of action. Brad From owner-ietf-pkix@mail.imc.org Sat Jun 24 09:19:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu82c-0006GK-Ix for pkix-archive@lists.ietf.org; Sat, 24 Jun 2006 09:19:14 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fu82Y-0007Gp-2W for pkix-archive@lists.ietf.org; Sat, 24 Jun 2006 09:19:14 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5OC4vDm026309; Sat, 24 Jun 2006 05:04:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5OC4vCJ026308; Sat, 24 Jun 2006 05:04:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5OC4sXM026284 for ; Sat, 24 Jun 2006 05:04:55 -0700 (MST) (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); Sat, 24 Jun 2006 13:04:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69786.668350C3" Subject: RE: last call for 3280bis - escape clause Date: Sat, 24 Jun 2006 13:04:50 +0100 Message-ID: In-Reply-To: <7A3E1242FA9989439AD1F9B2D71C287F09EAD1B5@sottmxs05.entrust.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: last call for 3280bis - escape clause thread-index: AcaWtewXOniEh36LRe+695QhbjS9hQA0Esgw From: "Stefan Santesson" To: "Sharon Boeyen" , "Santosh Chokhani" , X-OriginalArrivalTime: 24 Jun 2006 12:04:53.0184 (UTC) FILETIME=[66BEF400:01C69786] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.3 (/) X-Scan-Signature: 3c2f308c73d3221c0e72748732ce4acb This is a multi-part message in MIME format. ------_=_NextPart_001_01C69786.668350C3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sharon, =20 I fully agree. We should not describe any non conformant behavior. I hope you haven't interpreted my question in that manner. =20 Stefan Santesson Senior Program Manager Windows Security, Standards ________________________________ From: Sharon Boeyen [mailto:sharon.boeyen@entrust.com]=20 Sent: den 23 juni 2006 13:12 To: Stefan Santesson; Santosh Chokhani; ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause =20 There should not be any escape clause in 3280bis for any non-conformant behavior. 3280bis is a profile of X.509 - it is not a narrative to describe various types of non-conformant behavior, regardless of what it is.=20 -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Friday, June 23, 2006 5:28 AM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause Santosh, =20 Yes, you are correct that the path will validate without any error in your example.=20 It will also have an empty set of valid policies. So accepting the EE certificate policies as valid (using that path) do require some kind of non-conformant policy checking. =20 I agree on your conclusion. However I have experienced implementers not feeling sure about this principle. Especially when it comes to configuration options enabled by an administrative UI and not just some mode switch in the OS. The escape clause in pki4ipsic was driven by this uncertainty. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =09 ________________________________ From: Santosh Chokhani [mailto:chokhani@orionsec.com]=20 Sent: den 23 juni 2006 02:48 To: Stefan Santesson; ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause =20 Stefan, =20 On disagree with you on 2. You seem to be asking for 2 and then saying that it is not valid. =20 A path validation profile (assuming we agree to ignore "require explicit policy") with setting acceptable policy set to anyPolicy is valid X.509 and 3280 configuration. In that case, there will not be a policy failure and relying party can always make additional checks. I encourage you to look at Section J.3 in Annex J of X.509. If you see any errors in Annex J, please let me know. =20 As to Standard compliant implementation putting itself in non-compliant mode, that is always acceptable. In that mode it will NOT be standard compliant; that is all. =09 ________________________________ From: Stefan Santesson [mailto:stefans@microsoft.com]=20 Sent: Thursday, June 22, 2006 8:39 PM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause =20 Santosh, =20 There are 2 distinct reasons why your approach is not a generic solution to the problem. =20 1) The problem is generic and does not only apply to policy processing. The pki4ipsec issue was e.g. motivated from problems with EKU settings in existing certificates that does not satisfy new applications and usages. 2) If you need to test for a policy in the end certificate, that policy will not be valid unless supported by the path, regardless if policy constraints was set or not. =20 In the perfect world, compliant path processing will always do the job. In the real world, you may need to tweak the rules to make a new application fit into an existing infrastructure- =20 The question is still: Can a standards compliant implementation allow configuration of non conformant modifications to the validation process, or does that make the implementation as a whole non-conformant. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =09 ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: den 22 juni 2006 22:59 To: ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause =20 Stefan, =20 I agree with sentiments voiced by Steve, Rich, and Sharon. =20 I have a simple solution to your concern from the relying party viewpoint. This observation is made with a long-held view of mine (and no one had provided a convincing logical or business argument) that the require explicit policy setting is a useless field. A relying party can always set acceptable policies to none. In that scenario, (require explicit policy) flag not withstanding, path validation will succeed. Now, the user can examine the end certificate policy. =20 You and I have had this discussion in another context. The basic premise is that if some field in the last certificate only is of interest and the "state" in the path validation process does not impact it, that need not be path of path validation engine. =20 Thus, you can judiciously use the 3280 Engine and obtain the result you seek. =09 ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Guida, Richard [JJCUS] Sent: Thursday, June 22, 2006 2:48 PM To: Sharon Boeyen; 'Stefan Santesson'; ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause =20 Stefan - perhaps I am missing something, but there is nothing that stops a relying party from writing software that would perform processing extensions only on CA certs as you propose. As Sharon properly notes, that would not be RFC3280 compliant - but a relying party can choose to be non-compliant if it wishes. And such non-compliance only puts the relying party at risk, not others - so that is a "good thing" relatively speaking. But in the final analysis, seems to me that Sharon is absolutely correct (assuming she and I are interpreting your proposal properly) - unless X.509 is redefined, this would remain a circumstance of non-compliance. And so it should be treated as such. Very best regards -- Rich =20 =20 =20 Richard A. Guida=20 Director, Information Security=20 Johnson & Johnson=20 Room GS8217=20 410 George Street=20 New Brunswick, New Jersey 08901=20 Phone: 732 524 3785=20 -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon Boeyen Sent: Thursday, June 22, 2006 1:57 PM To: 'Stefan Santesson'; ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause Stefan, if I understand your comment correctly I strongly believe such an escape clause cannot possibly be added because this would render 3280bis non-compliant with X.509.=20 =20 My understanding of your comment is that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found in EE certificates. Is that a correct understanding?=20 =20 If it is a correct understanding, then any such implementation is non-conformant to X.509. 3280 is a profile of X.509 and as such can mandate certain optional elements or exclude optional elements but cannot reverse the mandatory processing from X.509. =20 Apologies if I've misunderstood your question. =20 Cheers, Sharon -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Wednesday, June 21, 2006 5:23 PM To: ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause As a last call comment on RFC 3280bis I would like to raise the question whether RFC 3280bis should include an escape clause clearly allowing relying parties to select what validation logic they deploy on certificate validation. =20 The background is the fact that many deployed PKIs are misconfigured.2 One such common misconfiguration is assignment of certificate policies and their inclusion in CA certificates. X.509 path processing requires policies in CA certificates to reflect the list of EE certificate policies that are valid for a path. Yet many deployments have included pure CA certificate policies in CA certificates, policies that are not included in any EE certificates and as such, policy processing is not possible in such PKIs. =20 Application wanting to use certificate policies in such PKI are simply forced to either fail or selectively neglect certain path processing rules. For a relying party such modification could be reasonable if the security implications has been well though through. However it is not clear if an implementation allowing such local configuration could be regarded as standard compliant. =20 There are more examples where deploying applications in misconfigured PKIs would need similar measures to work. =20 The pki4ipsec WG recently came to this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX WG. =20 The result was that the pki4ipsec profile included an escape clause as follows: =20 4.1. X.509 Certificates =20 Users deploying IKE and IPsec with certificates have often had little control over the capabilities of CAs available to them. Implementations of this specification may include configuration knobs to disable checks required by this specification in orde! r t o permit use with inflexible and/or noncompliant CAs. However, all checks on certificates exist for a specific reason involving the security of the entire system. Therefore, all checks MUST be enabled by default. Administrators and users ought to understand the security purpose for the various checks, and be clear on what security will be lost by disabling the check. =20 =20 I'm basically asking if RFC 3280bis path validation needs a similar escape clause or corresponding clarification that clearly allows local configuration of the validation logic. At least I think it is necessary to clearly allow such configuration of standards compliant applications as long as this is not the default functionality. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =09 ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: den 16 juni 2006 22:42 To: ietf-pkix@imc.org Subject: last call for 3280bis =20 Folks, =20 Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt ) =20 The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th. =20 Steve ------_=_NextPart_001_01C69786.668350C3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Sharon,

 

I fully agree. We should not = describe any non conformant behavior. I hope you haven’t interpreted my = question in that manner.

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: = Sharon Boeyen [mailto:sharon.boeyen@entrust.com]
Sent: den 23 juni 2006 = 13:12
To: Stefan Santesson; = Santosh Chokhani; ietf-pkix@imc.org
Subject: RE: last call = for 3280bis - escape clause

 

There should not be any escape = clause in 3280bis for any non-conformant behavior. 3280bis is a profile of X.509 - = it is not a narrative to describe various types of non-conformant behavior, regardless of what it is.

-----Original = Message-----
From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson
Sent: Friday, June 23, = 2006 5:28 AM
To: Santosh Chokhani; ietf-pkix@imc.org
Subject: RE: last call = for 3280bis - escape clause

Santosh,

 

Yes, you are correct that the path = will validate without any error in your example. =

It will also have an empty set of = valid policies. So accepting the EE certificate policies as valid (using that = path) do require some kind of non-conformant policy = checking.

 

I agree on your conclusion. However = I have experienced implementers not feeling sure about this principle. = Especially when it comes to configuration options enabled by an administrative UI and = not just some mode switch in the OS.

The escape clause in pki4ipsic was = driven by this uncertainty.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: = Santosh Chokhani [mailto:chokhani@orionsec.com]
Sent: den 23 juni 2006 = 02:48
To: Stefan Santesson; ietf-pkix@imc.org
Subject: RE: last call = for 3280bis - escape clause

 

Stefan,

=

 

On disagree with you on 2. =  You seem to be asking for 2 and then saying that it is not = valid.

 

A path validation profile (assuming = we agree to ignore "require explicit policy") with setting = acceptable policy set to anyPolicy is valid X.509 and 3280 configuration.  In that = case, there will not be a policy failure and relying party can always make = additional checks.  I encourage you to look at Section J.3 in Annex J of = X.509.  If you see any errors in Annex J, please let me = know.

 

As to Standard compliant = implementation putting itself in non-compliant mode, that is always acceptable. =  In that mode it will NOT be standard compliant; that is = all.

From: = Stefan Santesson [mailto:stefans@microsoft.com]
Sent: Thursday, June 22, = 2006 8:39 PM
To: Santosh Chokhani; ietf-pkix@imc.org
Subject: RE: last call = for 3280bis - escape clause

 

Santosh,

 

There are 2 distinct reasons why = your approach is not a generic solution to the = problem.

 

1)       = The problem is generic and does not only apply to policy processing. The pki4ipsec issue was e.g. motivated from problems with = EKU settings in existing certificates that does not satisfy new applications = and usages.

2)       = If you need to test for a policy in the end certificate, = that policy will not be valid unless supported by the path, regardless if = policy constraints was set or not.

 

In the perfect world, compliant = path processing will always do the job. In the real world, you may need to = tweak the rules to make a new application fit into an existing = infrastructure-

 

The question is still: Can a = standards compliant implementation allow configuration of non conformant = modifications to the validation process, or does that make the implementation as a whole = non-conformant.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Santosh Chokhani
Sent: den 22 juni 2006 = 22:59
To: ietf-pkix@imc.org
Subject: RE: last call = for 3280bis - escape clause

 

Stefan,

=

 

I agree with sentiments voiced by = Steve, Rich, and Sharon.

 

I have a simple solution to your = concern from the relying party viewpoint.  This observation is made with a long-held view of mine (and no one had provided a convincing logical or business argument) that the require explicit policy setting is a useless = field.  A relying party can always set acceptable policies to none. =  In that scenario, (require explicit policy) flag not withstanding, path = validation will succeed.  Now, the user can examine the end certificate = policy.

 

You and I have had this discussion = in another context.  The basic premise is that if some field in the = last certificate only is of interest and the "state" in the path validation process does not impact it, that need not be path of path = validation engine.

 

Thus, you can judiciously use the = 3280 Engine and obtain the result you seek.

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Guida, Richard = [JJCUS]
Sent: Thursday, June 22, = 2006 2:48 PM
To: Sharon Boeyen; = 'Stefan Santesson'; ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

 

Stefan - perhaps I am missing = something, but there is nothing that stops a relying party from writing software = that would perform processing extensions only on CA certs as you = propose.  As Sharon properly notes, that would not be RFC3280 compliant - but a relying = party can choose to be non-compliant if it wishes.  And such non-compliance = only puts the relying party at risk, not others - so that is a = "good thing" relatively speaking.  But in the final analysis, seems = to me that Sharon is absolutely correct (assuming she and I are interpreting your proposal properly) - unless X.509 is redefined, this would remain a = circumstance of non-compliance.  And so it should be treated as such.  = Very best regards -- Rich

 

 

 

Richard A. Guida
Director, Information Security =

Johnson & = Johnson
Room GS8217
410 George Street
New Brunswick, = New Jersey  08901
Phone:  732 524 3785

-----Original = Message-----
From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon Boeyen
Sent: Thursday, June 22, = 2006 1:57 PM
To: 'Stefan Santesson'; ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

Stefan, if I understand your = comment correctly I strongly believe such an escape clause cannot possibly be = added because this would render 3280bis non-compliant with X.509. =

 

My understanding of your comment is = that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found = in EE certificates. Is that a correct understanding? =

 

If it is a correct understanding, = then any such implementation is non-conformant to X.509. 3280 is a profile of = X.509 and as such can mandate certain optional elements or exclude optional = elements but cannot reverse the mandatory processing from = X.509.

 

Apologies if I've misunderstood = your question.

 

Cheers,

=

Sharon

-----Original = Message-----
From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson
Sent: Wednesday, June 21, = 2006 5:23 PM
To: ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

As a last call comment on RFC = 3280bis I would like to raise the question whether RFC 3280bis should include an = escape clause clearly allowing relying parties to select what validation logic = they deploy on certificate validation.

 

The background is the fact that = many deployed PKIs are misconfigured.2

One such common misconfiguration is assignment of certificate policies and their inclusion in CA = certificates.

X.509 path processing requires = policies in CA certificates to reflect the list of EE certificate policies that are = valid for a path. Yet many deployments have included pure CA certificate = policies in CA certificates, policies that are not included in any EE certificates = and as such, policy processing is not possible in such = PKIs.

 

Application wanting to use = certificate policies in such PKI are simply forced to either fail or selectively = neglect certain path processing rules. For a relying party such modification = could be reasonable if the security implications has been well though = through.

However it is not clear if an implementation allowing such local configuration could be regarded as = standard compliant.

 

There are more examples where = deploying applications in misconfigured PKIs would need similar measures to = work.

 

The pki4ipsec WG recently came to = this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX = WG.

 

The result was that the pki4ipsec = profile included an escape clause as follows:

 

4.1.  X.509 =
Certificates
 
   Users deploying IKE and IPsec =
with certificates have often had =
little
   control over the capabilities of =
CAs available to them.
   Implementations of this =
specification may include configuration =
knobs
   to disable checks required by =
this specification in orde!
 r =
t
 o =
permit
   use with inflexible and/or =
noncompliant CAs.  However, all checks =
on
   certificates exist for a =
specific reason involving the security =
of
   the entire system.  =
Therefore, all checks MUST be enabled by =
default.
   Administrators and users ought =
to understand the security purpose =
for
   the various checks, and be clear =
on what security will be lost =
by
   disabling the =
check.

 

 

I'm basically asking if RFC 3280bis = path validation needs a similar escape clause or corresponding clarification = that clearly allows local configuration of the validation = logic.

At least I think it is necessary to clearly allow such configuration of standards compliant applications as = long as this is not the default functionality.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Stephen Kent
Sent: den 16 juni 2006 = 22:42
To: ietf-pkix@imc.org
Subject: last call for = 3280bis

 

Folks,

 

Based on the latest message from David Cooper, I am initiating = last call on "Internet X.509 Public Key Infrastructure, Certificate and = Certificate Revocation List (CRL) Profile" = (http://ietf.org/internet-drafts/draft-ietf-pki= x-rfc3280bis-03.txt)

 

The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many = folks), all comments must be received by July 5th.

 

Steve

------_=_NextPart_001_01C69786.668350C3-- From owner-ietf-pkix@mail.imc.org Mon Jun 26 15:56:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuxBi-0006vU-M2 for pkix-archive@lists.ietf.org; Mon, 26 Jun 2006 15:56:02 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuxBh-0001aF-9y for pkix-archive@lists.ietf.org; Mon, 26 Jun 2006 15:56:02 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5QIp1TV035088; Mon, 26 Jun 2006 11:51:01 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5QIp1Oe035087; Mon, 26 Jun 2006 11:51:01 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5QIoxNC035063 for ; Mon, 26 Jun 2006 11:51:00 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k5QIop7k026704 for ; Mon, 26 Jun 2006 14:50:51 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.6/8.13.6) with ESMTP id k5QIoLq2017145 for ; Mon, 26 Jun 2006 14:50:21 -0400 (EDT) Message-ID: <44A02C9C.7050501@nist.gov> Date: Mon, 26 Jun 2006 14:51:08 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pkix Subject: draft-ietf-pkix-scvp-27.txt References: <449AE234.6060303@nist.gov> In-Reply-To: <449AE234.6060303@nist.gov> 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 All, On Friday, I submitted draft 27 of SCVP for posting. It contains the updated references mentioned below, but no other changes. A diff file comparing drafts 26 and 27 is available at http://csrc.nist.gov/pki/documents/PKIX/wdiff_draft-ietf-pkix-scvp-26_to_27.html. Dave David A. Cooper wrote: > Seth Hitchings wrote: > >> Should the CMS reference in section 11.1 be updated to RFC 3852? >> > Seth, > > Yes. I believe that the [CMS] reference should be updated from 3369 > to 3852. Also, the [UTF8] reference should be updated from 2279 to > 3629 and the [IKE] reference should be updated from 2409 to 4306. > > Updating the [UTF8] and [IKE] should only affect the References section. > > Updating the [CMS] reference will also require changing the ASN.1 in > section 8 so that ContentInfo is imported from the > CryptographicMessageSyntax2004 module rather than the > CryptographicMessageSyntax, but I don't think that should cause any > problems. > > Dave From owner-ietf-pkix@mail.imc.org Mon Jun 26 16:24:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuxd8-0004RX-Jg for pkix-archive@lists.ietf.org; Mon, 26 Jun 2006 16:24:22 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuxd7-00030p-7G for pkix-archive@lists.ietf.org; Mon, 26 Jun 2006 16:24:22 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5QJLwXj044656; Mon, 26 Jun 2006 12:21:58 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5QJLwXK044649; Mon, 26 Jun 2006 12:21:58 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5QJLveT044642 for ; Mon, 26 Jun 2006 12:21:57 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k5QJLpEQ012258 for ; Mon, 26 Jun 2006 15:21:52 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.6/8.13.6) with ESMTP id k5QJL4VP000441 for ; Mon, 26 Jun 2006 15:21:05 -0400 (EDT) Message-ID: <44A033D0.1080503@nist.gov> Date: Mon, 26 Jun 2006 15:21:52 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pkix Subject: draft-ietf-pkix-rfc3280bis-04.txt 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 All, On Friday, I submitted draft 4 of 3280bis for posting. A diff file highlighting the changes between drafts 3 and 4 is available at http://csrc.nist.gov/pki/documents/PKIX/draft3280bis-03todraft3280bis-04_diff.html. Draft 4 includes the following changes: 1. References to RFCs were updated as follows: RFC 2247 replaced with RFC 4519 RFC 2253 replaced with RFC 4514 RFC 2252 replaced with RFC 4512 RFC 2255 replaced with RFC 4516 RFC 2510 replaced with RFC 4210 RFC 2587 replaced with RFC 4523 draft-ietf-ldapbis-strprep-07.txt replaced with RFC 4518 2. All references to RFC 3279 now mention RFC 4055 and RFC 4491 as well. (All three RFCs are listed as informative references.) 3. Section 4.2.1.6 (subjectAltName): Reference to section 7.5 clarified to note that the section addresses email addresses that contain internationalized domain names rather than internationalized email addresses. 4. Section 4.2.1.7 (issuerAltName): Text added to clarify that the issuerAltName extension is not processed during certification path validation (i.e., it is not used in name chaining and name constraints are not enforced). 5. Section 4.2.1.10 (nameConstraints): Clarified that for DNS names, "host.example.com" is a match for the constraint "host.example.com". Also clarified that constraints of on the directoryName name form are not applied to the subject field if the subject contains an empty DN. 6. Section 7 (Processing Rules for Internationalized Names): made changes based on comments from Kurt Zeilenga. 7. Numerous minor typographic and syntactic errors were corrected. Dave From owner-ietf-pkix@mail.imc.org Mon Jun 26 17:16:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuyRg-0006C2-QJ for pkix-archive@lists.ietf.org; Mon, 26 Jun 2006 17:16:36 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuyRg-0007rr-5R for pkix-archive@lists.ietf.org; Mon, 26 Jun 2006 17:16:36 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5QKL4Mq064595; Mon, 26 Jun 2006 13:21:04 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5QKL417064594; Mon, 26 Jun 2006 13:21:04 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5QKL2nY064578 for ; Mon, 26 Jun 2006 13:21:03 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k5QKKqM5014974; Mon, 26 Jun 2006 16:20:53 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.6/8.13.6) with ESMTP id k5QKK2K1024833; Mon, 26 Jun 2006 16:20:07 -0400 (EDT) Message-ID: <44A041A2.8000808@nist.gov> Date: Mon, 26 Jun 2006 16:20:50 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: turners@ieca.com CC: pkix Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-03.txt References: <02e701c69544$d53fc9c0$0301a8c0@Wylie> In-Reply-To: <02e701c69544$d53fc9c0$0301a8c0@Wylie> 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Turner, Sean P. wrote: >Comments as follows (r=replace): > >1. Abstract: To the sentence beginning with "The X.509 v3 CRL format is >described in detail," add "an Internet specific extension is defined,". AIA >is an internet specific extension. > > Modified abstract to note that both standard and Internet-specific CRL extensions are described. >2. Sec 1 para 7 last sentence: replace a conforming certificate/conforming >certificates. There are three cert examples in Appendix C. > > Done. >3. Sec 1 last *, Sec 8, and Sec 10: r RFC 2510/RFC 4210 > > Done. >4. Sec 4 1st para last sentence: remove required to support a PKI. All of >the internet defined extensions are optional so they can't be required to >support a PKI for the internet community. > > The full sentence is "This section also defines private extensions required to support a PKI for the Internet community." These extensions (authorityInfoAccess an subjectInfoAccess) are needed even though it is not necessary to include them in all certificates. >5. Sec 4.1.2.4 last para penultimate and last sentence: r section >7.1/section 7.1 and 7.3. 7.3 needs to be added as issuer names can be >expressed using the domainComponent attribute. > > Section 7.1 has been modified to note that domainComponent attributes in DNs MUST be compared as specified in section 7.3. >6. Sec 4.2.1.2: Can we suggest using something other than SHA-1 for key id >generation? How about striking SHA-1 from the methods and adding the new >sentence to both: The hash algorithm employed can be the same algorithm >paired with the signature algorithm (e.g., SHA-1, SHA-256, SHA-384). > > Section 4.2.1.2 simply states that the two methods described are two common methods for generating key identifiers. The text explicitly does not restrict CAs to using these methods. It is also not clear why one would want to use SHA-256, SHA-384, etc. instead of SHA-1. There are no security issues associated with key identifiers, so it would seem that using a hash algorithm with a longer output would just make the certificates larger. >7. Sec 4.2.1.6/4.1.2.6: The 2nd paragraph of 4.2.1.6 points out that since >the SAN is bound to the public key that the CA MUST verify the each part of >the SAN. I think a similar statement ought to be added to the subject >section (4.1.2.6) to indicate that "All parts of the subject name MUST be >verified by the CA as it is bound to the public key". > > It is my understanding the the statement in 4.2.1.6 was added because there were cases in which CAs were verifying the name they included in the subject field but not names included in the subjectAltName extension. Are you aware of a similar problem with the subject field? >8. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT impose name >constraints on ediPartyName or registeredID but the 14th para (the one >before the ASN.1) indicates that ediPartyName and registeredId are not >defined in this spec but MAY be defined in another spec. Sounds to me like >it would be hard to convince a customer that you could write a name >constraints that can ever be 3280bis compliant since whatever you wrote MUST >NOT be imposed/implemented. It's not clear that the name constraints >shouldn't be imposed because they're not defined in the spec or whether they >should never ever be imposed. > > 3280bis states: The syntax and semantics for name constraints for otherName, ediPartyName, and registeredID are not defined by this specification, however syntax and semantics for name constraints for other name forms may be specified in other documents. A CA conforming to 3280bis MUST NOT impose name constraints on the x400Address, ediPartyName, or registeredID name forms. Period. However, just as [SRVSAN] specifies the syntax and semantics for name constraints on the SRVName name form, other documents could specify the syntax and semantics for name constraints on other name forms. Given that 3280bis forbids conforming CAs from imposing name constraints on the x400Address, ediPartyName, or registeredID name forms, it would seem to be inappropriate for another PKIX (or even IETF) document to specify syntax and semantics for name constraints on ediPartyName or registeredID name forms, but 3280bis is just one profile of X.509. A different profile of X.509 may permit the specification of name constraints on these name forms and may specify the syntax and semantics for imposing constraints on those name forms. While 3280bis states that conforming CAs MUST NOT impose name constraints on these name forms, conforming relying parties are permitted to implement the ability to process name constraints on these name forms since conforming relying parties are not restricted to only accepting certificates that are issued in conformance with 3280bis. >9. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT impose name >constraints on x400Address name forms but the last sentence in the 10th para >last says X400Address MUST be applied to x.400 addresses. See #8. > > While a conforming CA MUST not impose name constraints on the x400Address name form, a conforming relying party MAY implement the ability to process such constraints. As with any other name form, if a certificate includes name constraint on the x400Address name form and a subsequent certificate in the certification path includes a subjectAltName extension with an x400Address name, the relying party MUST either process the constraint or reject the certification path. >10. Sec 4.2.2.1 4th to last para: r HTTP or LDAP URI/HTTP [RFC 1738] or LDAP >[RFC 2255] URI. Makes it consistent with AIA in CRL section. > >11. Sec 4.2.2.2 3rd to last para: r HTTP or LDAP URI/HTTP [RFC 1738] or LDAP >[RFC 2255] URI. Makes it consistent with AIA sections. > > Done. Although 2255 was replaced with 4516. >12. Sec 5 3rd to last para: r This profile does not define any private >Internet CRL extensions or CRL entry extensions/This profiles defines one >CRL extension and no CRL entry extensions. AIA is defined in this spec. > > The sentence was replaced with the following: This profile defines one private Internet CRL extension but does not define any private CRL entry extensions. >13. Sec 5.2.5 8th para (one before the ASN.1): The sentence about the >onlyContainsAttributeCerts seems to hang. Recommend adding "In either case" >to the beginning of the sentence to address the case when either >onlyContainsUserCerts or onlyContainsCACerts is set to TRUE. Additionally, >recommend adding the following for completeness as a new last paragraph: "If >the scope of the CRL only includes attribute certificates then the >onlyContainsAttributeCerts MUST be set to TRUE and both >onlyContainsUserCerts and onlyContainsCACerts MUST be set to FALSE." > > This sentence was really meant to say that onlyContainsAttributeCerts MUST be set to FALSE in all cases, not just when either onlyContainsUserCerts or onlyContainsCACerts is set to TRUE. In order to make this more clear, the sentence about onlyContainsAttributeCerts has been moved to the end of the paragraph and now reads: Conforming CRLs issuers MUST set the onlyContainsAttributeCerts boolean to FALSE. >14. Sec 5.2.7: Remove ASN.1. It's already referenced in the 1st para, >duplication leads to errors, and the other sections that reused ASN.1 from >certificate sections did not duplicate the ASN.1 (see AKI/IAN). > > Done. >15. Sec 5.3.1: Can we add an ASN.1 comment to say the enumerated value #7 is >never used? > > Done. >16. Sec 4.2.1.6 1st para: r These identities may be included in addition to >or in the place of the identity/These identities may be included in addition >to or in the place of, in the case of non-CAs, the identity. The paragraph >mixes SAN and IAN, but assumed the 2nd sentence addressed SAN. > > Section 4.1.2.6 already very clearly states under what circumstances a non-empty DN is required. I don't think that information needs to be repeated here. >17. Sec 4.2.1.6: Add the following to clarify that there is no dependency in >this spec between SAN and IAN: This specification places no requirement on >CAs, whose certificate includes Issuer Alterative name, to include Subject >Alternative names in certificates issued by the CA. > > While this statement is certainly true, I don't understand the need to include it in section 4.2.1.6. Is there any reason that readers of 3280bis would believe that any certificate that includes an issuerAltName extension would also need to include a subjectAltName extension? >18. Sec 4.2.1.7: Add the following three sentences to be explicit about the >checks not made: Issuer Alternative names are not constrained by name >constraints. If a CA certificate has a Subject Alternative name, the >specification does not require CAs to populate the Issuer Alternative name >in certificates issued by the CA. Further, the chain of Issuer Alternative >and Subject Alternative names, as is done with issuer and subject names, is >not checked during the certificate path validation algorithm in section 6. > > The following was added to section 4.2.1.7: Issuer alternative names are not processed as part of the certification path validation algorithm in section 6. (That is, issuer alternative names are not used in name chaining and name constraints are not enforced.) >19. Sec 5.2.2: Add the following: Issuer Alternative names are not >constrained by name constraints. If a CA certificate has a Subject >Alternative name, this specification does not require CAs to populate the >Issuer Alternative name in CRLs issued by the CA. > > From owner-ietf-pkix@mail.imc.org Mon Jun 26 19:51:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv0rd-0003Nv-FI for pkix-archive@lists.ietf.org; Mon, 26 Jun 2006 19:51:33 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv0rc-0000HA-2N for pkix-archive@lists.ietf.org; Mon, 26 Jun 2006 19:51:33 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5QMo9Mj014645; Mon, 26 Jun 2006 15:50:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5QMo9uI014644; Mon, 26 Jun 2006 15:50:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5QMo8ZV014615 for ; Mon, 26 Jun 2006 15:50:08 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5QMo1UA011331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Jun 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fuzu5-0007zX-Oy; Mon, 26 Jun 2006 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-scvp-27.txt Message-Id: Date: Mon, 26 Jun 2006 18:50:01 -0400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.3 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 --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 : Server-based Certificate Validation Protocol (SCVP) Author(s) : A. Malpani, et al. Filename : draft-ietf-pkix-scvp-27.txt Pages : 84 Date : 2006-6-26 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-27.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-27.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-27.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: <2006-6-26162737.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-scvp-27.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-scvp-27.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-26162737.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix@mail.imc.org Tue Jun 27 16:29:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKBS-00088E-K0 for pkix-archive@lists.ietf.org; Tue, 27 Jun 2006 16:29:18 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvKBS-0006HY-Ia for pkix-archive@lists.ietf.org; Tue, 27 Jun 2006 16:29:18 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvKBM-0006SP-Ra for pkix-archive@lists.ietf.org; Tue, 27 Jun 2006 16:29:14 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5RJSOZU097004; Tue, 27 Jun 2006 12:28:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5RJSO22097001; Tue, 27 Jun 2006 12:28:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k5RJSML3096986 for ; Tue, 27 Jun 2006 12:28:22 -0700 (MST) (envelope-from housley@vigilsec.com) Received: (qmail 18744 invoked by uid 0); 27 Jun 2006 19:28:15 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.241.252.242) by woodstock.binhost.com with SMTP; 27 Jun 2006 19:28:15 -0000 Message-Id: <7.0.0.16.2.20060627152724.0766c500@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 27 Jun 2006 15:28:15 -0400 To: "Manger, James H" , From: Russ Housley Subject: RE: SRV Name: draft-ietf-pkix-srvsan-02.txt: typos, examples In-Reply-To: References: <6215401E01247448A306C54F499111F2C4AB35@WSMSG2103V.srv.dir.telstra.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: X-Spam-Score: -2.6 (--) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de James: >8. Appendix A. Are the modules names supposed to end with "..SAN88" and >"..SAN93", or is it supposed to be "..ASN88" and "..ASN93"? I was thinking "Subject Alt Name" when I used "SAN" in the name. Russ From owner-ietf-pkix@mail.imc.org Tue Jun 27 16:29:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKBT-00088j-CC for pkix-archive@lists.ietf.org; Tue, 27 Jun 2006 16:29:19 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvKBT-0006HY-Al for pkix-archive@lists.ietf.org; Tue, 27 Jun 2006 16:29:19 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvKBO-0006SX-OH for pkix-archive@lists.ietf.org; Tue, 27 Jun 2006 16:29:18 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5RJSOWS097003; Tue, 27 Jun 2006 12:28:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5RJSOoq097002; Tue, 27 Jun 2006 12:28:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k5RJSMlQ096985 for ; Tue, 27 Jun 2006 12:28:22 -0700 (MST) (envelope-from housley@vigilsec.com) Received: (qmail 18734 invoked by uid 0); 27 Jun 2006 19:28:13 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.241.252.242) by woodstock.binhost.com with SMTP; 27 Jun 2006 19:28:13 -0000 Message-Id: <7.0.0.16.2.20060627152438.076b2240@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 27 Jun 2006 15:25:39 -0400 To: "Stefan Santesson" , "Manger, James H" , From: Russ Housley Subject: RE: SRV Name: draft-ietf-pkix-srvsan-02.txt: typos, examples In-Reply-To: References: <6215401E01247448A306C54F499111F2C4AB35@WSMSG2103V.srv.dir.telstra.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: X-Spam-Score: -2.6 (--) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Stefan: >5. Why bother with the (SIZE (1..MAX)) restriction? Delete it. > > It seems to be the custom to use it. I don't feel enough of an >ASN.1 expert to have the correct answer. Someone else may have an >opinon. I'll be happy to remove it as long as it works. This is used to indicate that a string, set, or sequence cannot have zero elements. Russ From owner-ietf-pkix@mail.imc.org Tue Jun 27 16:38:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKKk-0008AV-VH for pkix-archive@lists.ietf.org; Tue, 27 Jun 2006 16:38:54 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvKKj-0007tO-Hp for pkix-archive@lists.ietf.org; Tue, 27 Jun 2006 16:38:54 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5RJoAud004825; Tue, 27 Jun 2006 12:50:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5RJoAg7004823; Tue, 27 Jun 2006 12:50:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5RJo9P2004782 for ; Tue, 27 Jun 2006 12:50:10 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5RJo11u030533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvJZR-0005FU-Lz; Tue, 27 Jun 2006 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-rfc3280bis-04.txt Message-Id: Date: Tue, 27 Jun 2006 15:50:01 -0400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.3 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile Author(s) : D. Cooper, et al. Filename : draft-ietf-pkix-rfc3280bis-04.txt Pages : 141 Date : 2006-6-27 This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model are provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-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-rfc3280bis-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-rfc3280bis-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: <2006-6-27110629.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-rfc3280bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-rfc3280bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-27110629.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix@mail.imc.org Fri Jun 30 11:17:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwKk3-0006g3-Ni for pkix-archive@lists.ietf.org; Fri, 30 Jun 2006 11:17:11 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwKk2-00058X-GS for pkix-archive@lists.ietf.org; Fri, 30 Jun 2006 11:17:11 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5UE2CSa005531; Fri, 30 Jun 2006 07:02:12 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5UE2CJ5005530; Fri, 30 Jun 2006 07:02:12 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp103.biz.mail.re2.yahoo.com (smtp103.biz.mail.re2.yahoo.com [68.142.229.217]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k5UE2B7W005477 for ; Fri, 30 Jun 2006 07:02:11 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 10559 invoked from network); 30 Jun 2006 14:02:05 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@70.18.246.246 with login) by smtp103.biz.mail.re2.yahoo.com with SMTP; 30 Jun 2006 14:02:05 -0000 Reply-To: From: "Turner, Sean P." To: "'David A. Cooper'" Cc: "'pkix'" Subject: RE: I-D ACTION:draft-ietf-pkix-rfc3280bis-03.txt Date: Fri, 30 Jun 2006 10:03:50 -0400 Organization: IECA, Inc. Message-ID: <009001c69c4e$0395d110$0201a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcaZXgqSbReSfl2KSFCNZ8IwEMFH0QC6M3SQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <44A041A2.8000808@nist.gov> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 David comments in-line. I snipped out the ones that you accepted or you resolved. ------------------ > >4. Sec 4 1st para last sentence: remove required to support > a PKI. All > >of the internet defined extensions are optional so they can't be > >required to support a PKI for the internet community. > > > > > The full sentence is "This section also defines private > extensions required to support a PKI for the Internet > community." These extensions (authorityInfoAccess an > subjectInfoAccess) are needed even though it is not necessary > to include them in all certificates. Exactly - they are needed but not required. I still think the sentence ought to read: This section also defines extension to support the PKI for the internet community. There's no need to say required. > >6. Sec 4.2.1.2: Can we suggest using something other than > SHA-1 for key > >id generation? How about striking SHA-1 from the methods and > adding the > >new sentence to both: The hash algorithm employed can be the same > >algorithm paired with the signature algorithm (e.g., SHA-1, > SHA-256, SHA-384). > > > > > Section 4.2.1.2 simply states that the two methods described > are two common methods for generating key identifiers. The > text explicitly does not restrict CAs to using these methods. This one didn't come across very well. I know there's no security issue and there are just examples but sometimes people just implement the examples and we end up getting stuck with those. Further I'm trying to avoid silly things like somebody saying I won't use a spec that has SHA1 and they don't understand that they're only examples. > It is also not clear why one would want to use SHA-256, SHA-384, etc. > instead of SHA-1. There are no security issues associated > with key identifiers, so it would seem that using a hash > algorithm with a longer output would just make the > certificates larger. I wasn't clear with the use any hash algorithm part. I think the example should still indicate that a 160bit output is used with whatever hash algorithm is used. So for logner hash outputs they only use 160bits of it. It doesn't matter which bits as long as the CA is consistent. > >7. Sec 4.2.1.6/4.1.2.6: The 2nd paragraph of 4.2.1.6 points out that > >since the SAN is bound to the public key that the CA MUST verify the > >each part of the SAN. I think a similar statement ought to > be added to > >the subject section (4.1.2.6) to indicate that "All parts of the > >subject name MUST be verified by the CA as it is bound to > the public key". > > > > > It is my understanding the the statement in 4.2.1.6 was added > because there were cases in which CAs were verifying the name > they included in the subject field but not names included in > the subjectAltName extension. Are you aware of a similar > problem with the subject field? No. It was a motherhood and apple pie statement. > >8. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT impose name > >constraints on ediPartyName or registeredID but the 14th > para (the one > >before the ASN.1) indicates that ediPartyName and > registeredId are not > >defined in this spec but MAY be defined in another spec. > Sounds to me > >like it would be hard to convince a customer that you could write a > >name constraints that can ever be 3280bis compliant since > whatever you > >wrote MUST NOT be imposed/implemented. It's not clear that the name > >constraints shouldn't be imposed because they're not defined in the > >spec or whether they should never ever be imposed. > > > > > 3280bis states: > > The syntax and semantics for name constraints for otherName, > ediPartyName, and registeredID are not defined by this > specification, > however syntax and semantics for name constraints for other name > forms may be specified in other documents. > > A CA conforming to 3280bis MUST NOT impose name constraints > on the x400Address, ediPartyName, or registeredID name forms. > Period. > However, just as [SRVSAN] specifies the syntax and semantics > for name constraints on the SRVName name form, other > documents could specify the syntax and semantics for name > constraints on other name forms. Given that 3280bis forbids > conforming CAs from imposing name constraints on the > x400Address, ediPartyName, or registeredID name forms, it > would seem to be inappropriate for another PKIX (or even > IETF) document to specify syntax and semantics for name > constraints on ediPartyName or registeredID name forms, but > 3280bis is just one profile of X.509. A different profile of > X.509 may permit the specification of name constraints on > these name forms and may specify the syntax and semantics for > imposing constraints on those name forms. While 3280bis > states that conforming CAs MUST NOT impose name constraints > on these name forms, conforming relying parties are permitted > to implement the ability to process name constraints on these > name forms since conforming relying parties are not > restricted to only accepting certificates that are issued in > conformance with 3280bis. I don't understand why these name forms were specifically picked out. For x400Address I assume it's that nobody cares, but you could easily write a rule that said the OR Address attributes (just like DNs) must be within the ones included. I write the rules if we decide we need them. For registeredId I get that it's an OID so there's structure to it so it's imposible to write rules but why couldn't somebody decide to carve up an OID tree and say something like make sure the 1st 6 components of the OID are present in all names. For the ediPartyName you could say the nameAssigner must be present in all PKCs. If there is no way I can say with a straight face that a CA that requires a name constraints for x400Address, ediPartyName, or registeredID is compliant, I've got a problem with this what it says because being compliant with RFC3280 is the gold standard; besides I think the rules are easy enough to write I don't understand why these particular name forms were omitted (there may be good reasons I'm unaware of). > >9. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT impose name > >constraints on x400Address name forms but the last sentence > in the 10th > >para last says X400Address MUST be applied to x.400 > addresses. See #8. > > > > > While a conforming CA MUST not impose name constraints on the > x400Address name form, a conforming relying party MAY > implement the ability to process such constraints. As with > any other name form, if a certificate includes name > constraint on the x400Address name form and a subsequent > certificate in the certification path includes a > subjectAltName extension with an x400Address name, the > relying party MUST either process the constraint or reject > the certification path. See above. > >13. Sec 5.2.5 8th para (one before the ASN.1): The sentence > about the > >onlyContainsAttributeCerts seems to hang. Recommend adding > "In either case" > >to the beginning of the sentence to address the case when either > >onlyContainsUserCerts or onlyContainsCACerts is set to TRUE. > >Additionally, recommend adding the following for > completeness as a new > >last paragraph: "If the scope of the CRL only includes attribute > >certificates then the onlyContainsAttributeCerts MUST be set to TRUE > >and both onlyContainsUserCerts and onlyContainsCACerts MUST > be set to FALSE." > > > > > This sentence was really meant to say that > onlyContainsAttributeCerts MUST be set to FALSE in all cases, > not just when either onlyContainsUserCerts or > onlyContainsCACerts is set to TRUE. In order to make this > more clear, the sentence about onlyContainsAttributeCerts has > been moved to the end of the paragraph and now reads: > > Conforming CRLs issuers MUST set the > onlyContainsAttributeCerts boolean > to FALSE. Are we not addressing the case when the CRL is only for attribute certificates? > >16. Sec 4.2.1.6 1st para: r These identities may be included in > >addition to or in the place of the identity/These identities may be > >included in addition to or in the place of, in the case of > non-CAs, the > >identity. The paragraph mixes SAN and IAN, but assumed the > 2nd sentence addressed SAN. > > > > > Section 4.1.2.6 already very clearly states under what > circumstances a non-empty DN is required. I don't think that > information needs to be repeated here. I'm only hoping to clarify the 1st paragraph. It's unclear whether the "these" refers to SAN or IAN after a couple of reads of the 1st para since IAN is thrown in later in the paragraph. If you add the ", in the case of non-CAs," it's clear that the 2nd sentence refers to the SAN. > >17. Sec 4.2.1.6: Add the following to clarify that there is no > >dependency in this spec between SAN and IAN: This > specification places > >no requirement on CAs, whose certificate includes Issuer Alterative > >name, to include Subject Alternative names in certificates > issued by the CA. > > > > > While this statement is certainly true, I don't understand > the need to include it in section 4.2.1.6. Is there any > reason that readers of 3280bis would believe that any > certificate that includes an issuerAltName extension would > also need to include a subjectAltName extension? I'm only trying to protect against something silly like somebody who assumes that the issuer/subject fields are in all PKCs then IAN/SAN ought to be in all certificate too. An explicit indication that there is no requirement to include one if the other is present removes any doubt. spt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5UE2CSa005531; Fri, 30 Jun 2006 07:02:12 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5UE2CJ5005530; Fri, 30 Jun 2006 07:02:12 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp103.biz.mail.re2.yahoo.com (smtp103.biz.mail.re2.yahoo.com [68.142.229.217]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k5UE2B7W005477 for ; Fri, 30 Jun 2006 07:02:11 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 10559 invoked from network); 30 Jun 2006 14:02:05 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@70.18.246.246 with login) by smtp103.biz.mail.re2.yahoo.com with SMTP; 30 Jun 2006 14:02:05 -0000 Reply-To: From: "Turner, Sean P." To: "'David A. Cooper'" Cc: "'pkix'" Subject: RE: I-D ACTION:draft-ietf-pkix-rfc3280bis-03.txt Date: Fri, 30 Jun 2006 10:03:50 -0400 Organization: IECA, Inc. Message-ID: <009001c69c4e$0395d110$0201a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcaZXgqSbReSfl2KSFCNZ8IwEMFH0QC6M3SQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <44A041A2.8000808@nist.gov> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: David comments in-line. I snipped out the ones that you accepted or you resolved. ------------------ > >4. Sec 4 1st para last sentence: remove required to support > a PKI. All > >of the internet defined extensions are optional so they can't be > >required to support a PKI for the internet community. > > > > > The full sentence is "This section also defines private > extensions required to support a PKI for the Internet > community." These extensions (authorityInfoAccess an > subjectInfoAccess) are needed even though it is not necessary > to include them in all certificates. Exactly - they are needed but not required. I still think the sentence ought to read: This section also defines extension to support the PKI for the internet community. There's no need to say required. > >6. Sec 4.2.1.2: Can we suggest using something other than > SHA-1 for key > >id generation? How about striking SHA-1 from the methods and > adding the > >new sentence to both: The hash algorithm employed can be the same > >algorithm paired with the signature algorithm (e.g., SHA-1, > SHA-256, SHA-384). > > > > > Section 4.2.1.2 simply states that the two methods described > are two common methods for generating key identifiers. The > text explicitly does not restrict CAs to using these methods. This one didn't come across very well. I know there's no security issue and there are just examples but sometimes people just implement the examples and we end up getting stuck with those. Further I'm trying to avoid silly things like somebody saying I won't use a spec that has SHA1 and they don't understand that they're only examples. > It is also not clear why one would want to use SHA-256, SHA-384, etc. > instead of SHA-1. There are no security issues associated > with key identifiers, so it would seem that using a hash > algorithm with a longer output would just make the > certificates larger. I wasn't clear with the use any hash algorithm part. I think the example should still indicate that a 160bit output is used with whatever hash algorithm is used. So for logner hash outputs they only use 160bits of it. It doesn't matter which bits as long as the CA is consistent. > >7. Sec 4.2.1.6/4.1.2.6: The 2nd paragraph of 4.2.1.6 points out that > >since the SAN is bound to the public key that the CA MUST verify the > >each part of the SAN. I think a similar statement ought to > be added to > >the subject section (4.1.2.6) to indicate that "All parts of the > >subject name MUST be verified by the CA as it is bound to > the public key". > > > > > It is my understanding the the statement in 4.2.1.6 was added > because there were cases in which CAs were verifying the name > they included in the subject field but not names included in > the subjectAltName extension. Are you aware of a similar > problem with the subject field? No. It was a motherhood and apple pie statement. > >8. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT impose name > >constraints on ediPartyName or registeredID but the 14th > para (the one > >before the ASN.1) indicates that ediPartyName and > registeredId are not > >defined in this spec but MAY be defined in another spec. > Sounds to me > >like it would be hard to convince a customer that you could write a > >name constraints that can ever be 3280bis compliant since > whatever you > >wrote MUST NOT be imposed/implemented. It's not clear that the name > >constraints shouldn't be imposed because they're not defined in the > >spec or whether they should never ever be imposed. > > > > > 3280bis states: > > The syntax and semantics for name constraints for otherName, > ediPartyName, and registeredID are not defined by this > specification, > however syntax and semantics for name constraints for other name > forms may be specified in other documents. > > A CA conforming to 3280bis MUST NOT impose name constraints > on the x400Address, ediPartyName, or registeredID name forms. > Period. > However, just as [SRVSAN] specifies the syntax and semantics > for name constraints on the SRVName name form, other > documents could specify the syntax and semantics for name > constraints on other name forms. Given that 3280bis forbids > conforming CAs from imposing name constraints on the > x400Address, ediPartyName, or registeredID name forms, it > would seem to be inappropriate for another PKIX (or even > IETF) document to specify syntax and semantics for name > constraints on ediPartyName or registeredID name forms, but > 3280bis is just one profile of X.509. A different profile of > X.509 may permit the specification of name constraints on > these name forms and may specify the syntax and semantics for > imposing constraints on those name forms. While 3280bis > states that conforming CAs MUST NOT impose name constraints > on these name forms, conforming relying parties are permitted > to implement the ability to process name constraints on these > name forms since conforming relying parties are not > restricted to only accepting certificates that are issued in > conformance with 3280bis. I don't understand why these name forms were specifically picked out. For x400Address I assume it's that nobody cares, but you could easily write a rule that said the OR Address attributes (just like DNs) must be within the ones included. I write the rules if we decide we need them. For registeredId I get that it's an OID so there's structure to it so it's imposible to write rules but why couldn't somebody decide to carve up an OID tree and say something like make sure the 1st 6 components of the OID are present in all names. For the ediPartyName you could say the nameAssigner must be present in all PKCs. If there is no way I can say with a straight face that a CA that requires a name constraints for x400Address, ediPartyName, or registeredID is compliant, I've got a problem with this what it says because being compliant with RFC3280 is the gold standard; besides I think the rules are easy enough to write I don't understand why these particular name forms were omitted (there may be good reasons I'm unaware of). > >9. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT impose name > >constraints on x400Address name forms but the last sentence > in the 10th > >para last says X400Address MUST be applied to x.400 > addresses. See #8. > > > > > While a conforming CA MUST not impose name constraints on the > x400Address name form, a conforming relying party MAY > implement the ability to process such constraints. As with > any other name form, if a certificate includes name > constraint on the x400Address name form and a subsequent > certificate in the certification path includes a > subjectAltName extension with an x400Address name, the > relying party MUST either process the constraint or reject > the certification path. See above. > >13. Sec 5.2.5 8th para (one before the ASN.1): The sentence > about the > >onlyContainsAttributeCerts seems to hang. Recommend adding > "In either case" > >to the beginning of the sentence to address the case when either > >onlyContainsUserCerts or onlyContainsCACerts is set to TRUE. > >Additionally, recommend adding the following for > completeness as a new > >last paragraph: "If the scope of the CRL only includes attribute > >certificates then the onlyContainsAttributeCerts MUST be set to TRUE > >and both onlyContainsUserCerts and onlyContainsCACerts MUST > be set to FALSE." > > > > > This sentence was really meant to say that > onlyContainsAttributeCerts MUST be set to FALSE in all cases, > not just when either onlyContainsUserCerts or > onlyContainsCACerts is set to TRUE. In order to make this > more clear, the sentence about onlyContainsAttributeCerts has > been moved to the end of the paragraph and now reads: > > Conforming CRLs issuers MUST set the > onlyContainsAttributeCerts boolean > to FALSE. Are we not addressing the case when the CRL is only for attribute certificates? > >16. Sec 4.2.1.6 1st para: r These identities may be included in > >addition to or in the place of the identity/These identities may be > >included in addition to or in the place of, in the case of > non-CAs, the > >identity. The paragraph mixes SAN and IAN, but assumed the > 2nd sentence addressed SAN. > > > > > Section 4.1.2.6 already very clearly states under what > circumstances a non-empty DN is required. I don't think that > information needs to be repeated here. I'm only hoping to clarify the 1st paragraph. It's unclear whether the "these" refers to SAN or IAN after a couple of reads of the 1st para since IAN is thrown in later in the paragraph. If you add the ", in the case of non-CAs," it's clear that the 2nd sentence refers to the SAN. > >17. Sec 4.2.1.6: Add the following to clarify that there is no > >dependency in this spec between SAN and IAN: This > specification places > >no requirement on CAs, whose certificate includes Issuer Alterative > >name, to include Subject Alternative names in certificates > issued by the CA. > > > > > While this statement is certainly true, I don't understand > the need to include it in section 4.2.1.6. Is there any > reason that readers of 3280bis would believe that any > certificate that includes an issuerAltName extension would > also need to include a subjectAltName extension? I'm only trying to protect against something silly like somebody who assumes that the issuer/subject fields are in all PKCs then IAN/SAN ought to be in all certificate too. An explicit indication that there is no requirement to include one if the other is present removes any doubt. spt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5SFX1mL012521; Wed, 28 Jun 2006 08:33:01 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5SFX1Fv012520; Wed, 28 Jun 2006 08:33:01 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from karoshi.com ([212.32.88.102]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5SFWv2k012476 for ; Wed, 28 Jun 2006 08:32:58 -0700 (MST) (envelope-from bmanning@karoshi.com) Message-Id: <200606281532.k5SFWv2k012476@balder-227.proper.com> From: bmanning@karoshi.com To: ietf-pkix@imc.org Subject: foecyfzpo muaym Date: Wed, 28 Jun 2006 16:32:57 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0012_94DF94B0.895253EE" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: 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_0012_94DF94B0.895253EE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ¢c­–Õûus)—)vS_&ra¹Åùg%ú¤‚×û,çå7‘?Ó¬º§3—ò>χJâꮎß1ÆÁÚ–Q¥íö; hHQ‡PR_ ­As–º°ä!³ä«¦ó½¬ÝŠY„–›ÛRôüÝŠ2¢çñ9ÁäΗU¥o ý\¤Á›"B]•q¡î—ª¶î›š®Ëû¥.g¦ƒ‡R¾ðe3O›[Œ«ëð„è©%ÙØB¸ÂËÅ×AL.å0ÌTþwº›®zs"e#ÎnÇþ.š9”?ˆ94&ä3%žr,[Uibçþ˜â%”žÈébÉKY§Jã¾#U§úaÄ´Õ}‚P´ÄqOxzD5Ðï©Fö(µ8Gs/·V›†§RC‡±›B…ÊÒQöHAxàxµXäꃤC\SPi£Á5bCQŠËÚξ Û_û¦YÞåu¸Ì›Nìé/f„ö×ëþ8]-!æ4¨žËŸµå«A;ÍtLE¾Qño4$åKívy¹Þ³X¨š1Ä$Ð*Krg×”äFQ›Ê>ó‹¨ô‰£¶`׶`QT…Hʼn6Îe1UàÏ‹­A_!ÕÈFÈfí¦cÖ»«ÎÜDx«Ç.)‘ñU„]nqàðº]QMo„œ[œe9QCý9ÅTK"wô?‰xì9!‡»‘¢‘~ UÇû ü'NýÛZ?9(¦B)¹Å¬ýؤêÛXüIAz uÏ%CÁoC¬nxSú.ãáÒä󬺃µn®ßì?$—nuÇOKù'&‹¼ò’\ A7OÙcÅ©*x­3hm3P "?OºÙ‚,þƒÞ¬þNîq©…•ÑS&`˜Èé­bˆµlh—ð»D¦é-V;ßuo.Úù Æøw¯º2у(]ÖÞ”Xá2®YœÏšƒßí’ŸÈ8§XÁèÂOª´·½à¥éOl¿ñ¶OùQÈyÍ:ÊÕ›¡þõ™H?—oAža/“¶ýx ×Ãæ4°|Ÿ.£À?[cÝLdÓÁõÔgž¿!†;tåP£ÝW)µªøŒÓJ«|½© L™×sBàêq ÒPø¡ÇM~²†•F`QVFËœvmÍG»˜…«$„†Ý  íuýt$☻‰nË1 yD…#8I(O­"L¹ ‡üõ|qeÞi¬ ‘§êE »Ê¥ÔwñALB²v—BŽVž!ŸUÞ²‚ÛÍâLÍ ¢yî!„Ú'ÊŽãÙ['äØ‹¤&þS˜ïÜ\ÓFdæñ2x–ë1W?0úy¬kix ‚ûÈgdZÞ‡j9VDR D™üƒ|©–†½8Ç^0­oò‚:|¶[I:K²0“Š¬w|ÀªÎÛÖùh±6í¤bz“*{ ÞNósÔ†ÞiµƒˆÕR>¾“lq„áÈf®HÈÉ™Ÿ§¨ÑÚãyhŒÀ‘rpî‡ã7nDg«ÕÊ!qË:š8iP_v’,ëïP‰ÑFhcœ§ÔKÉzmËÕPyÊ Ð±#™4mæД˜V,nwä[É)¬ý­ïöa2O䘊>Ýl÷¸»¥rl²ü„?ÅŸÍÉO°X|ÇååÍkÖ­—B“„N­6²Ä|ê'%!"›1&ELÆ`CXà(ÖÒûoŸâyeüÚ/aŒ'ø ‚´œÅ…ŽÚ3žnÜG~%çß©á–àfíWÈ̦:1 DÑ%*OæQ´þÌFz1öI}]|SZïê¦Æî.qˆn®œöDãðÔdÉÃÊ0íº¨ŸÄÎ1¥ñ1IiâÇ-Rt_`šÚ‘îZæ¢<<ºL BoMŽi0UƒúÌâ××&¾æ"<’Îyaï}ÜàØTï¢G¢MÀDJH0ŸzW"åàR¨ásòB&`Äè\ˆª„¼þWt˜Š×E§C½k‚Äb2r¥KÙ6£V,Ò¢î%Jè®%cŠéÙ¬éE´TŒJš±>|–VA†ip#ÂÏ›§bfÕPdjbƒâXj¾<–Ö$ö™ûê!Ô¤£…ûŒ·pcC»¶dKžü­; Tue, 27 Jun 2006 12:50:10 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5RJo11u030533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvJZR-0005FU-Lz; Tue, 27 Jun 2006 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-rfc3280bis-04.txt Message-Id: Date: Tue, 27 Jun 2006 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 : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile Author(s) : D. Cooper, et al. Filename : draft-ietf-pkix-rfc3280bis-04.txt Pages : 141 Date : 2006-6-27 This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model are provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-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-rfc3280bis-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-rfc3280bis-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: <2006-6-27110629.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-rfc3280bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-rfc3280bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-27110629.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5RJSOZU097004; Tue, 27 Jun 2006 12:28:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5RJSO22097001; Tue, 27 Jun 2006 12:28:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k5RJSML3096986 for ; Tue, 27 Jun 2006 12:28:22 -0700 (MST) (envelope-from housley@vigilsec.com) Received: (qmail 18744 invoked by uid 0); 27 Jun 2006 19:28:15 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.241.252.242) by woodstock.binhost.com with SMTP; 27 Jun 2006 19:28:15 -0000 Message-Id: <7.0.0.16.2.20060627152724.0766c500@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 27 Jun 2006 15:28:15 -0400 To: "Manger, James H" , From: Russ Housley Subject: RE: SRV Name: draft-ietf-pkix-srvsan-02.txt: typos, examples In-Reply-To: References: <6215401E01247448A306C54F499111F2C4AB35@WSMSG2103V.srv.dir.telstra.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: James: >8. Appendix A. Are the modules names supposed to end with "..SAN88" and >"..SAN93", or is it supposed to be "..ASN88" and "..ASN93"? I was thinking "Subject Alt Name" when I used "SAN" in the name. Russ Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5RJSOWS097003; Tue, 27 Jun 2006 12:28:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5RJSOoq097002; Tue, 27 Jun 2006 12:28:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k5RJSMlQ096985 for ; Tue, 27 Jun 2006 12:28:22 -0700 (MST) (envelope-from housley@vigilsec.com) Received: (qmail 18734 invoked by uid 0); 27 Jun 2006 19:28:13 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.241.252.242) by woodstock.binhost.com with SMTP; 27 Jun 2006 19:28:13 -0000 Message-Id: <7.0.0.16.2.20060627152438.076b2240@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 27 Jun 2006 15:25:39 -0400 To: "Stefan Santesson" , "Manger, James H" , From: Russ Housley Subject: RE: SRV Name: draft-ietf-pkix-srvsan-02.txt: typos, examples In-Reply-To: References: <6215401E01247448A306C54F499111F2C4AB35@WSMSG2103V.srv.dir.telstra.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: Stefan: >5. Why bother with the (SIZE (1..MAX)) restriction? Delete it. > > It seems to be the custom to use it. I don't feel enough of an >ASN.1 expert to have the correct answer. Someone else may have an >opinon. I'll be happy to remove it as long as it works. This is used to indicate that a string, set, or sequence cannot have zero elements. Russ Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5QMo9Mj014645; Mon, 26 Jun 2006 15:50:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5QMo9uI014644; Mon, 26 Jun 2006 15:50:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5QMo8ZV014615 for ; Mon, 26 Jun 2006 15:50:08 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5QMo1UA011331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Jun 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fuzu5-0007zX-Oy; Mon, 26 Jun 2006 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-scvp-27.txt Message-Id: Date: Mon, 26 Jun 2006 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 : Server-based Certificate Validation Protocol (SCVP) Author(s) : A. Malpani, et al. Filename : draft-ietf-pkix-scvp-27.txt Pages : 84 Date : 2006-6-26 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-27.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-27.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-27.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: <2006-6-26162737.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-scvp-27.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-scvp-27.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-26162737.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5QKL4Mq064595; Mon, 26 Jun 2006 13:21:04 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5QKL417064594; Mon, 26 Jun 2006 13:21:04 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5QKL2nY064578 for ; Mon, 26 Jun 2006 13:21:03 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k5QKKqM5014974; Mon, 26 Jun 2006 16:20:53 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.6/8.13.6) with ESMTP id k5QKK2K1024833; Mon, 26 Jun 2006 16:20:07 -0400 (EDT) Message-ID: <44A041A2.8000808@nist.gov> Date: Mon, 26 Jun 2006 16:20:50 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: turners@ieca.com CC: pkix Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-03.txt References: <02e701c69544$d53fc9c0$0301a8c0@Wylie> In-Reply-To: <02e701c69544$d53fc9c0$0301a8c0@Wylie> 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: Turner, Sean P. wrote: >Comments as follows (r=replace): > >1. Abstract: To the sentence beginning with "The X.509 v3 CRL format is >described in detail," add "an Internet specific extension is defined,". AIA >is an internet specific extension. > > Modified abstract to note that both standard and Internet-specific CRL extensions are described. >2. Sec 1 para 7 last sentence: replace a conforming certificate/conforming >certificates. There are three cert examples in Appendix C. > > Done. >3. Sec 1 last *, Sec 8, and Sec 10: r RFC 2510/RFC 4210 > > Done. >4. Sec 4 1st para last sentence: remove required to support a PKI. All of >the internet defined extensions are optional so they can't be required to >support a PKI for the internet community. > > The full sentence is "This section also defines private extensions required to support a PKI for the Internet community." These extensions (authorityInfoAccess an subjectInfoAccess) are needed even though it is not necessary to include them in all certificates. >5. Sec 4.1.2.4 last para penultimate and last sentence: r section >7.1/section 7.1 and 7.3. 7.3 needs to be added as issuer names can be >expressed using the domainComponent attribute. > > Section 7.1 has been modified to note that domainComponent attributes in DNs MUST be compared as specified in section 7.3. >6. Sec 4.2.1.2: Can we suggest using something other than SHA-1 for key id >generation? How about striking SHA-1 from the methods and adding the new >sentence to both: The hash algorithm employed can be the same algorithm >paired with the signature algorithm (e.g., SHA-1, SHA-256, SHA-384). > > Section 4.2.1.2 simply states that the two methods described are two common methods for generating key identifiers. The text explicitly does not restrict CAs to using these methods. It is also not clear why one would want to use SHA-256, SHA-384, etc. instead of SHA-1. There are no security issues associated with key identifiers, so it would seem that using a hash algorithm with a longer output would just make the certificates larger. >7. Sec 4.2.1.6/4.1.2.6: The 2nd paragraph of 4.2.1.6 points out that since >the SAN is bound to the public key that the CA MUST verify the each part of >the SAN. I think a similar statement ought to be added to the subject >section (4.1.2.6) to indicate that "All parts of the subject name MUST be >verified by the CA as it is bound to the public key". > > It is my understanding the the statement in 4.2.1.6 was added because there were cases in which CAs were verifying the name they included in the subject field but not names included in the subjectAltName extension. Are you aware of a similar problem with the subject field? >8. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT impose name >constraints on ediPartyName or registeredID but the 14th para (the one >before the ASN.1) indicates that ediPartyName and registeredId are not >defined in this spec but MAY be defined in another spec. Sounds to me like >it would be hard to convince a customer that you could write a name >constraints that can ever be 3280bis compliant since whatever you wrote MUST >NOT be imposed/implemented. It's not clear that the name constraints >shouldn't be imposed because they're not defined in the spec or whether they >should never ever be imposed. > > 3280bis states: The syntax and semantics for name constraints for otherName, ediPartyName, and registeredID are not defined by this specification, however syntax and semantics for name constraints for other name forms may be specified in other documents. A CA conforming to 3280bis MUST NOT impose name constraints on the x400Address, ediPartyName, or registeredID name forms. Period. However, just as [SRVSAN] specifies the syntax and semantics for name constraints on the SRVName name form, other documents could specify the syntax and semantics for name constraints on other name forms. Given that 3280bis forbids conforming CAs from imposing name constraints on the x400Address, ediPartyName, or registeredID name forms, it would seem to be inappropriate for another PKIX (or even IETF) document to specify syntax and semantics for name constraints on ediPartyName or registeredID name forms, but 3280bis is just one profile of X.509. A different profile of X.509 may permit the specification of name constraints on these name forms and may specify the syntax and semantics for imposing constraints on those name forms. While 3280bis states that conforming CAs MUST NOT impose name constraints on these name forms, conforming relying parties are permitted to implement the ability to process name constraints on these name forms since conforming relying parties are not restricted to only accepting certificates that are issued in conformance with 3280bis. >9. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT impose name >constraints on x400Address name forms but the last sentence in the 10th para >last says X400Address MUST be applied to x.400 addresses. See #8. > > While a conforming CA MUST not impose name constraints on the x400Address name form, a conforming relying party MAY implement the ability to process such constraints. As with any other name form, if a certificate includes name constraint on the x400Address name form and a subsequent certificate in the certification path includes a subjectAltName extension with an x400Address name, the relying party MUST either process the constraint or reject the certification path. >10. Sec 4.2.2.1 4th to last para: r HTTP or LDAP URI/HTTP [RFC 1738] or LDAP >[RFC 2255] URI. Makes it consistent with AIA in CRL section. > >11. Sec 4.2.2.2 3rd to last para: r HTTP or LDAP URI/HTTP [RFC 1738] or LDAP >[RFC 2255] URI. Makes it consistent with AIA sections. > > Done. Although 2255 was replaced with 4516. >12. Sec 5 3rd to last para: r This profile does not define any private >Internet CRL extensions or CRL entry extensions/This profiles defines one >CRL extension and no CRL entry extensions. AIA is defined in this spec. > > The sentence was replaced with the following: This profile defines one private Internet CRL extension but does not define any private CRL entry extensions. >13. Sec 5.2.5 8th para (one before the ASN.1): The sentence about the >onlyContainsAttributeCerts seems to hang. Recommend adding "In either case" >to the beginning of the sentence to address the case when either >onlyContainsUserCerts or onlyContainsCACerts is set to TRUE. Additionally, >recommend adding the following for completeness as a new last paragraph: "If >the scope of the CRL only includes attribute certificates then the >onlyContainsAttributeCerts MUST be set to TRUE and both >onlyContainsUserCerts and onlyContainsCACerts MUST be set to FALSE." > > This sentence was really meant to say that onlyContainsAttributeCerts MUST be set to FALSE in all cases, not just when either onlyContainsUserCerts or onlyContainsCACerts is set to TRUE. In order to make this more clear, the sentence about onlyContainsAttributeCerts has been moved to the end of the paragraph and now reads: Conforming CRLs issuers MUST set the onlyContainsAttributeCerts boolean to FALSE. >14. Sec 5.2.7: Remove ASN.1. It's already referenced in the 1st para, >duplication leads to errors, and the other sections that reused ASN.1 from >certificate sections did not duplicate the ASN.1 (see AKI/IAN). > > Done. >15. Sec 5.3.1: Can we add an ASN.1 comment to say the enumerated value #7 is >never used? > > Done. >16. Sec 4.2.1.6 1st para: r These identities may be included in addition to >or in the place of the identity/These identities may be included in addition >to or in the place of, in the case of non-CAs, the identity. The paragraph >mixes SAN and IAN, but assumed the 2nd sentence addressed SAN. > > Section 4.1.2.6 already very clearly states under what circumstances a non-empty DN is required. I don't think that information needs to be repeated here. >17. Sec 4.2.1.6: Add the following to clarify that there is no dependency in >this spec between SAN and IAN: This specification places no requirement on >CAs, whose certificate includes Issuer Alterative name, to include Subject >Alternative names in certificates issued by the CA. > > While this statement is certainly true, I don't understand the need to include it in section 4.2.1.6. Is there any reason that readers of 3280bis would believe that any certificate that includes an issuerAltName extension would also need to include a subjectAltName extension? >18. Sec 4.2.1.7: Add the following three sentences to be explicit about the >checks not made: Issuer Alternative names are not constrained by name >constraints. If a CA certificate has a Subject Alternative name, the >specification does not require CAs to populate the Issuer Alternative name >in certificates issued by the CA. Further, the chain of Issuer Alternative >and Subject Alternative names, as is done with issuer and subject names, is >not checked during the certificate path validation algorithm in section 6. > > The following was added to section 4.2.1.7: Issuer alternative names are not processed as part of the certification path validation algorithm in section 6. (That is, issuer alternative names are not used in name chaining and name constraints are not enforced.) >19. Sec 5.2.2: Add the following: Issuer Alternative names are not >constrained by name constraints. If a CA certificate has a Subject >Alternative name, this specification does not require CAs to populate the >Issuer Alternative name in CRLs issued by the CA. > > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5QJLwXj044656; Mon, 26 Jun 2006 12:21:58 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5QJLwXK044649; Mon, 26 Jun 2006 12:21:58 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5QJLveT044642 for ; Mon, 26 Jun 2006 12:21:57 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k5QJLpEQ012258 for ; Mon, 26 Jun 2006 15:21:52 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.6/8.13.6) with ESMTP id k5QJL4VP000441 for ; Mon, 26 Jun 2006 15:21:05 -0400 (EDT) Message-ID: <44A033D0.1080503@nist.gov> Date: Mon, 26 Jun 2006 15:21:52 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pkix Subject: draft-ietf-pkix-rfc3280bis-04.txt 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, On Friday, I submitted draft 4 of 3280bis for posting. A diff file highlighting the changes between drafts 3 and 4 is available at http://csrc.nist.gov/pki/documents/PKIX/draft3280bis-03todraft3280bis-04_diff.html. Draft 4 includes the following changes: 1. References to RFCs were updated as follows: RFC 2247 replaced with RFC 4519 RFC 2253 replaced with RFC 4514 RFC 2252 replaced with RFC 4512 RFC 2255 replaced with RFC 4516 RFC 2510 replaced with RFC 4210 RFC 2587 replaced with RFC 4523 draft-ietf-ldapbis-strprep-07.txt replaced with RFC 4518 2. All references to RFC 3279 now mention RFC 4055 and RFC 4491 as well. (All three RFCs are listed as informative references.) 3. Section 4.2.1.6 (subjectAltName): Reference to section 7.5 clarified to note that the section addresses email addresses that contain internationalized domain names rather than internationalized email addresses. 4. Section 4.2.1.7 (issuerAltName): Text added to clarify that the issuerAltName extension is not processed during certification path validation (i.e., it is not used in name chaining and name constraints are not enforced). 5. Section 4.2.1.10 (nameConstraints): Clarified that for DNS names, "host.example.com" is a match for the constraint "host.example.com". Also clarified that constraints of on the directoryName name form are not applied to the subject field if the subject contains an empty DN. 6. Section 7 (Processing Rules for Internationalized Names): made changes based on comments from Kurt Zeilenga. 7. Numerous minor typographic and syntactic errors were corrected. Dave Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5QIp1TV035088; Mon, 26 Jun 2006 11:51:01 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5QIp1Oe035087; Mon, 26 Jun 2006 11:51:01 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5QIoxNC035063 for ; Mon, 26 Jun 2006 11:51:00 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k5QIop7k026704 for ; Mon, 26 Jun 2006 14:50:51 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.6/8.13.6) with ESMTP id k5QIoLq2017145 for ; Mon, 26 Jun 2006 14:50:21 -0400 (EDT) Message-ID: <44A02C9C.7050501@nist.gov> Date: Mon, 26 Jun 2006 14:51:08 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pkix Subject: draft-ietf-pkix-scvp-27.txt References: <449AE234.6060303@nist.gov> In-Reply-To: <449AE234.6060303@nist.gov> 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, On Friday, I submitted draft 27 of SCVP for posting. It contains the updated references mentioned below, but no other changes. A diff file comparing drafts 26 and 27 is available at http://csrc.nist.gov/pki/documents/PKIX/wdiff_draft-ietf-pkix-scvp-26_to_27.html. Dave David A. Cooper wrote: > Seth Hitchings wrote: > >> Should the CMS reference in section 11.1 be updated to RFC 3852? >> > Seth, > > Yes. I believe that the [CMS] reference should be updated from 3369 > to 3852. Also, the [UTF8] reference should be updated from 2279 to > 3629 and the [IKE] reference should be updated from 2409 to 4306. > > Updating the [UTF8] and [IKE] should only affect the References section. > > Updating the [CMS] reference will also require changing the ASN.1 in > section 8 so that ContentInfo is imported from the > CryptographicMessageSyntax2004 module rather than the > CryptographicMessageSyntax, but I don't think that should cause any > problems. > > Dave Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5OC9xq4027774; Sat, 24 Jun 2006 05:09:59 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5OC9xds027773; Sat, 24 Jun 2006 05:09:59 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5OC9uGD027749 for ; Sat, 24 Jun 2006 05:09:57 -0700 (MST) (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); Sat, 24 Jun 2006 13:09:56 +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: last call for 3280bis - escape clause Date: Sat, 24 Jun 2006 13:09:53 +0100 Message-ID: In-Reply-To: <200606232202.51448.bradh@frogmouth.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: last call for 3280bis - escape clause thread-index: AcaWxUtSUooUAJ+sTSCg55Dpx2HUugAwUwtQ From: "Stefan Santesson" To: "Brad Hards" , "Sharon Boeyen" Cc: X-OriginalArrivalTime: 24 Jun 2006 12:09:56.0039 (UTC) FILETIME=[1B42F570:01C69787] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k5OC9vGD027754 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Personally I feel positive about such initiative even though I fear the volume of debates it might cause. I would like to hear the rest of the WG on this. I do acknowledge that we are facing practical problems out there that the standard can't solve today. Stefan Santesson Senior Program Manager Windows Security, Standards -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Brad Hards Sent: den 23 juni 2006 14:03 To: Sharon Boeyen Cc: ietf-pkix@imc.org Subject: Re: last call for 3280bis - escape clause On Friday 23 June 2006 21:12 pm, Sharon Boeyen wrote: > There should not be any escape clause in 3280bis for any non-conformant > behavior. 3280bis is a profile of X.509 - it is not a narrative to describe > various types of non-conformant behavior, regardless of what it is. Perhaps there might be a role for an Informational RFC that explains the various issues that are a source of concern. Ideally it would provide some guidance on how to deal with the non-conformant behaviour. At the very least it could explain the consequences of particular courses of action. Brad Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5OC4vDm026309; Sat, 24 Jun 2006 05:04:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5OC4vCJ026308; Sat, 24 Jun 2006 05:04:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5OC4sXM026284 for ; Sat, 24 Jun 2006 05:04:55 -0700 (MST) (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); Sat, 24 Jun 2006 13:04:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69786.668350C3" Subject: RE: last call for 3280bis - escape clause Date: Sat, 24 Jun 2006 13:04:50 +0100 Message-ID: In-Reply-To: <7A3E1242FA9989439AD1F9B2D71C287F09EAD1B5@sottmxs05.entrust.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: last call for 3280bis - escape clause thread-index: AcaWtewXOniEh36LRe+695QhbjS9hQA0Esgw From: "Stefan Santesson" To: "Sharon Boeyen" , "Santosh Chokhani" , X-OriginalArrivalTime: 24 Jun 2006 12:04:53.0184 (UTC) FILETIME=[66BEF400:01C69786] 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_01C69786.668350C3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sharon, =20 I fully agree. We should not describe any non conformant behavior. I hope you haven't interpreted my question in that manner. =20 Stefan Santesson Senior Program Manager Windows Security, Standards ________________________________ From: Sharon Boeyen [mailto:sharon.boeyen@entrust.com]=20 Sent: den 23 juni 2006 13:12 To: Stefan Santesson; Santosh Chokhani; ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause =20 There should not be any escape clause in 3280bis for any non-conformant behavior. 3280bis is a profile of X.509 - it is not a narrative to describe various types of non-conformant behavior, regardless of what it is.=20 -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Friday, June 23, 2006 5:28 AM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause Santosh, =20 Yes, you are correct that the path will validate without any error in your example.=20 It will also have an empty set of valid policies. So accepting the EE certificate policies as valid (using that path) do require some kind of non-conformant policy checking. =20 I agree on your conclusion. However I have experienced implementers not feeling sure about this principle. Especially when it comes to configuration options enabled by an administrative UI and not just some mode switch in the OS. The escape clause in pki4ipsic was driven by this uncertainty. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =09 ________________________________ From: Santosh Chokhani [mailto:chokhani@orionsec.com]=20 Sent: den 23 juni 2006 02:48 To: Stefan Santesson; ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause =20 Stefan, =20 On disagree with you on 2. You seem to be asking for 2 and then saying that it is not valid. =20 A path validation profile (assuming we agree to ignore "require explicit policy") with setting acceptable policy set to anyPolicy is valid X.509 and 3280 configuration. In that case, there will not be a policy failure and relying party can always make additional checks. I encourage you to look at Section J.3 in Annex J of X.509. If you see any errors in Annex J, please let me know. =20 As to Standard compliant implementation putting itself in non-compliant mode, that is always acceptable. In that mode it will NOT be standard compliant; that is all. =09 ________________________________ From: Stefan Santesson [mailto:stefans@microsoft.com]=20 Sent: Thursday, June 22, 2006 8:39 PM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause =20 Santosh, =20 There are 2 distinct reasons why your approach is not a generic solution to the problem. =20 1) The problem is generic and does not only apply to policy processing. The pki4ipsec issue was e.g. motivated from problems with EKU settings in existing certificates that does not satisfy new applications and usages. 2) If you need to test for a policy in the end certificate, that policy will not be valid unless supported by the path, regardless if policy constraints was set or not. =20 In the perfect world, compliant path processing will always do the job. In the real world, you may need to tweak the rules to make a new application fit into an existing infrastructure- =20 The question is still: Can a standards compliant implementation allow configuration of non conformant modifications to the validation process, or does that make the implementation as a whole non-conformant. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =09 ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: den 22 juni 2006 22:59 To: ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause =20 Stefan, =20 I agree with sentiments voiced by Steve, Rich, and Sharon. =20 I have a simple solution to your concern from the relying party viewpoint. This observation is made with a long-held view of mine (and no one had provided a convincing logical or business argument) that the require explicit policy setting is a useless field. A relying party can always set acceptable policies to none. In that scenario, (require explicit policy) flag not withstanding, path validation will succeed. Now, the user can examine the end certificate policy. =20 You and I have had this discussion in another context. The basic premise is that if some field in the last certificate only is of interest and the "state" in the path validation process does not impact it, that need not be path of path validation engine. =20 Thus, you can judiciously use the 3280 Engine and obtain the result you seek. =09 ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Guida, Richard [JJCUS] Sent: Thursday, June 22, 2006 2:48 PM To: Sharon Boeyen; 'Stefan Santesson'; ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause =20 Stefan - perhaps I am missing something, but there is nothing that stops a relying party from writing software that would perform processing extensions only on CA certs as you propose. As Sharon properly notes, that would not be RFC3280 compliant - but a relying party can choose to be non-compliant if it wishes. And such non-compliance only puts the relying party at risk, not others - so that is a "good thing" relatively speaking. But in the final analysis, seems to me that Sharon is absolutely correct (assuming she and I are interpreting your proposal properly) - unless X.509 is redefined, this would remain a circumstance of non-compliance. And so it should be treated as such. Very best regards -- Rich =20 =20 =20 Richard A. Guida=20 Director, Information Security=20 Johnson & Johnson=20 Room GS8217=20 410 George Street=20 New Brunswick, New Jersey 08901=20 Phone: 732 524 3785=20 -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon Boeyen Sent: Thursday, June 22, 2006 1:57 PM To: 'Stefan Santesson'; ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause Stefan, if I understand your comment correctly I strongly believe such an escape clause cannot possibly be added because this would render 3280bis non-compliant with X.509.=20 =20 My understanding of your comment is that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found in EE certificates. Is that a correct understanding?=20 =20 If it is a correct understanding, then any such implementation is non-conformant to X.509. 3280 is a profile of X.509 and as such can mandate certain optional elements or exclude optional elements but cannot reverse the mandatory processing from X.509. =20 Apologies if I've misunderstood your question. =20 Cheers, Sharon -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Wednesday, June 21, 2006 5:23 PM To: ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause As a last call comment on RFC 3280bis I would like to raise the question whether RFC 3280bis should include an escape clause clearly allowing relying parties to select what validation logic they deploy on certificate validation. =20 The background is the fact that many deployed PKIs are misconfigured.2 One such common misconfiguration is assignment of certificate policies and their inclusion in CA certificates. X.509 path processing requires policies in CA certificates to reflect the list of EE certificate policies that are valid for a path. Yet many deployments have included pure CA certificate policies in CA certificates, policies that are not included in any EE certificates and as such, policy processing is not possible in such PKIs. =20 Application wanting to use certificate policies in such PKI are simply forced to either fail or selectively neglect certain path processing rules. For a relying party such modification could be reasonable if the security implications has been well though through. However it is not clear if an implementation allowing such local configuration could be regarded as standard compliant. =20 There are more examples where deploying applications in misconfigured PKIs would need similar measures to work. =20 The pki4ipsec WG recently came to this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX WG. =20 The result was that the pki4ipsec profile included an escape clause as follows: =20 4.1. X.509 Certificates =20 Users deploying IKE and IPsec with certificates have often had little control over the capabilities of CAs available to them. Implementations of this specification may include configuration knobs to disable checks required by this specification in orde! r t o permit use with inflexible and/or noncompliant CAs. However, all checks on certificates exist for a specific reason involving the security of the entire system. Therefore, all checks MUST be enabled by default. Administrators and users ought to understand the security purpose for the various checks, and be clear on what security will be lost by disabling the check. =20 =20 I'm basically asking if RFC 3280bis path validation needs a similar escape clause or corresponding clarification that clearly allows local configuration of the validation logic. At least I think it is necessary to clearly allow such configuration of standards compliant applications as long as this is not the default functionality. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =09 ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: den 16 juni 2006 22:42 To: ietf-pkix@imc.org Subject: last call for 3280bis =20 Folks, =20 Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt ) =20 The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th. =20 Steve ------_=_NextPart_001_01C69786.668350C3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Sharon,

 

I fully agree. We should not = describe any non conformant behavior. I hope you haven’t interpreted my = question in that manner.

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: = Sharon Boeyen [mailto:sharon.boeyen@entrust.com]
Sent: den 23 juni 2006 = 13:12
To: Stefan Santesson; = Santosh Chokhani; ietf-pkix@imc.org
Subject: RE: last call = for 3280bis - escape clause

 

There should not be any escape = clause in 3280bis for any non-conformant behavior. 3280bis is a profile of X.509 - = it is not a narrative to describe various types of non-conformant behavior, regardless of what it is.

-----Original = Message-----
From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson
Sent: Friday, June 23, = 2006 5:28 AM
To: Santosh Chokhani; ietf-pkix@imc.org
Subject: RE: last call = for 3280bis - escape clause

Santosh,

 

Yes, you are correct that the path = will validate without any error in your example. =

It will also have an empty set of = valid policies. So accepting the EE certificate policies as valid (using that = path) do require some kind of non-conformant policy = checking.

 

I agree on your conclusion. However = I have experienced implementers not feeling sure about this principle. = Especially when it comes to configuration options enabled by an administrative UI and = not just some mode switch in the OS.

The escape clause in pki4ipsic was = driven by this uncertainty.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: = Santosh Chokhani [mailto:chokhani@orionsec.com]
Sent: den 23 juni 2006 = 02:48
To: Stefan Santesson; ietf-pkix@imc.org
Subject: RE: last call = for 3280bis - escape clause

 

Stefan,

=

 

On disagree with you on 2. =  You seem to be asking for 2 and then saying that it is not = valid.

 

A path validation profile (assuming = we agree to ignore "require explicit policy") with setting = acceptable policy set to anyPolicy is valid X.509 and 3280 configuration.  In that = case, there will not be a policy failure and relying party can always make = additional checks.  I encourage you to look at Section J.3 in Annex J of = X.509.  If you see any errors in Annex J, please let me = know.

 

As to Standard compliant = implementation putting itself in non-compliant mode, that is always acceptable. =  In that mode it will NOT be standard compliant; that is = all.

From: = Stefan Santesson [mailto:stefans@microsoft.com]
Sent: Thursday, June 22, = 2006 8:39 PM
To: Santosh Chokhani; ietf-pkix@imc.org
Subject: RE: last call = for 3280bis - escape clause

 

Santosh,

 

There are 2 distinct reasons why = your approach is not a generic solution to the = problem.

 

1)       = The problem is generic and does not only apply to policy processing. The pki4ipsec issue was e.g. motivated from problems with = EKU settings in existing certificates that does not satisfy new applications = and usages.

2)       = If you need to test for a policy in the end certificate, = that policy will not be valid unless supported by the path, regardless if = policy constraints was set or not.

 

In the perfect world, compliant = path processing will always do the job. In the real world, you may need to = tweak the rules to make a new application fit into an existing = infrastructure-

 

The question is still: Can a = standards compliant implementation allow configuration of non conformant = modifications to the validation process, or does that make the implementation as a whole = non-conformant.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Santosh Chokhani
Sent: den 22 juni 2006 = 22:59
To: ietf-pkix@imc.org
Subject: RE: last call = for 3280bis - escape clause

 

Stefan,

=

 

I agree with sentiments voiced by = Steve, Rich, and Sharon.

 

I have a simple solution to your = concern from the relying party viewpoint.  This observation is made with a long-held view of mine (and no one had provided a convincing logical or business argument) that the require explicit policy setting is a useless = field.  A relying party can always set acceptable policies to none. =  In that scenario, (require explicit policy) flag not withstanding, path = validation will succeed.  Now, the user can examine the end certificate = policy.

 

You and I have had this discussion = in another context.  The basic premise is that if some field in the = last certificate only is of interest and the "state" in the path validation process does not impact it, that need not be path of path = validation engine.

 

Thus, you can judiciously use the = 3280 Engine and obtain the result you seek.

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Guida, Richard = [JJCUS]
Sent: Thursday, June 22, = 2006 2:48 PM
To: Sharon Boeyen; = 'Stefan Santesson'; ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

 

Stefan - perhaps I am missing = something, but there is nothing that stops a relying party from writing software = that would perform processing extensions only on CA certs as you = propose.  As Sharon properly notes, that would not be RFC3280 compliant - but a relying = party can choose to be non-compliant if it wishes.  And such non-compliance = only puts the relying party at risk, not others - so that is a = "good thing" relatively speaking.  But in the final analysis, seems = to me that Sharon is absolutely correct (assuming she and I are interpreting your proposal properly) - unless X.509 is redefined, this would remain a = circumstance of non-compliance.  And so it should be treated as such.  = Very best regards -- Rich

 

 

 

Richard A. Guida
Director, Information Security =

Johnson & = Johnson
Room GS8217
410 George Street
New Brunswick, = New Jersey  08901
Phone:  732 524 3785

-----Original = Message-----
From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon Boeyen
Sent: Thursday, June 22, = 2006 1:57 PM
To: 'Stefan Santesson'; ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

Stefan, if I understand your = comment correctly I strongly believe such an escape clause cannot possibly be = added because this would render 3280bis non-compliant with X.509. =

 

My understanding of your comment is = that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found = in EE certificates. Is that a correct understanding? =

 

If it is a correct understanding, = then any such implementation is non-conformant to X.509. 3280 is a profile of = X.509 and as such can mandate certain optional elements or exclude optional = elements but cannot reverse the mandatory processing from = X.509.

 

Apologies if I've misunderstood = your question.

 

Cheers,

=

Sharon

-----Original = Message-----
From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson
Sent: Wednesday, June 21, = 2006 5:23 PM
To: ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

As a last call comment on RFC = 3280bis I would like to raise the question whether RFC 3280bis should include an = escape clause clearly allowing relying parties to select what validation logic = they deploy on certificate validation.

 

The background is the fact that = many deployed PKIs are misconfigured.2

One such common misconfiguration is assignment of certificate policies and their inclusion in CA = certificates.

X.509 path processing requires = policies in CA certificates to reflect the list of EE certificate policies that are = valid for a path. Yet many deployments have included pure CA certificate = policies in CA certificates, policies that are not included in any EE certificates = and as such, policy processing is not possible in such = PKIs.

 

Application wanting to use = certificate policies in such PKI are simply forced to either fail or selectively = neglect certain path processing rules. For a relying party such modification = could be reasonable if the security implications has been well though = through.

However it is not clear if an implementation allowing such local configuration could be regarded as = standard compliant.

 

There are more examples where = deploying applications in misconfigured PKIs would need similar measures to = work.

 

The pki4ipsec WG recently came to = this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX = WG.

 

The result was that the pki4ipsec = profile included an escape clause as follows:

 

4.1.  X.509 =
Certificates
 
   Users deploying IKE and IPsec =
with certificates have often had =
little
   control over the capabilities of =
CAs available to them.
   Implementations of this =
specification may include configuration =
knobs
   to disable checks required by =
this specification in orde!
 r =
t
 o =
permit
   use with inflexible and/or =
noncompliant CAs.  However, all checks =
on
   certificates exist for a =
specific reason involving the security =
of
   the entire system.  =
Therefore, all checks MUST be enabled by =
default.
   Administrators and users ought =
to understand the security purpose =
for
   the various checks, and be clear =
on what security will be lost =
by
   disabling the =
check.

 

 

I'm basically asking if RFC 3280bis = path validation needs a similar escape clause or corresponding clarification = that clearly allows local configuration of the validation = logic.

At least I think it is necessary to clearly allow such configuration of standards compliant applications as = long as this is not the default functionality.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Stephen Kent
Sent: den 16 juni 2006 = 22:42
To: ietf-pkix@imc.org
Subject: last call for = 3280bis

 

Folks,

 

Based on the latest message from David Cooper, I am initiating = last call on "Internet X.509 Public Key Infrastructure, Certificate and = Certificate Revocation List (CRL) Profile" = (http://ietf.org/internet-drafts/draft-ietf-pki= x-rfc3280bis-03.txt)

 

The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many = folks), all comments must be received by July 5th.

 

Steve

------_=_NextPart_001_01C69786.668350C3-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5NC3e1F069973; Fri, 23 Jun 2006 05:03:40 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5NC3e7g069972; Fri, 23 Jun 2006 05:03:40 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from omta05ps.mx.bigpond.com (omta05ps.mx.bigpond.com [144.140.83.195]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5NC3dAY069950 for ; Fri, 23 Jun 2006 05:03:40 -0700 (MST) (envelope-from bradh@frogmouth.net) Received: from prionotes.cuneata.net ([61.9.204.42]) by omta05ps.mx.bigpond.com with ESMTP id <20060623120328.PCOK16234.omta05ps.mx.bigpond.com@prionotes.cuneata.net>; Fri, 23 Jun 2006 12:03:28 +0000 From: Brad Hards To: Sharon Boeyen Subject: Re: last call for 3280bis - escape clause Date: Fri, 23 Jun 2006 22:02:43 +1000 User-Agent: KMail/1.9.1 Cc: ietf-pkix@imc.org References: <7A3E1242FA9989439AD1F9B2D71C287F09EAD1B5@sottmxs05.entrust.com> In-Reply-To: <7A3E1242FA9989439AD1F9B2D71C287F09EAD1B5@sottmxs05.entrust.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart8723954.v22oNSQp9r"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200606232202.51448.bradh@frogmouth.net> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --nextPart8723954.v22oNSQp9r Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 23 June 2006 21:12 pm, Sharon Boeyen wrote: > There should not be any escape clause in 3280bis for any non-conformant > behavior. 3280bis is a profile of X.509 - it is not a narrative to descri= be > various types of non-conformant behavior, regardless of what it is. Perhaps there might be a role for an Informational RFC that explains the=20 various issues that are a source of concern. Ideally it would provide some= =20 guidance on how to deal with the non-conformant behaviour. At the very leas= t=20 it could explain the consequences of particular courses of action. Brad --nextPart8723954.v22oNSQp9r Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBEm9hrGwwszQ/PZzgRAsYHAJ97yDRdQCj1Tsw6xGL+ZiJGZDCDMACfRt3k kVrwNyKjMIhq92lvDgd2xdU= =o2Dn -----END PGP SIGNATURE----- --nextPart8723954.v22oNSQp9r-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5NBiOrt065702; Fri, 23 Jun 2006 04:44:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5NBiOb2065701; Fri, 23 Jun 2006 04:44:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5NBiNHZ065677 for ; Fri, 23 Jun 2006 04:44:24 -0700 (MST) (envelope-from chokhani@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C696BA.DCDC9215" Subject: RE: last call for 3280bis - escape clause Date: Fri, 23 Jun 2006 04:44:17 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C8790359DB6E@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: last call for 3280bis - escape clause Thread-Index: AcaWNVMoloaBo6PDT0CPPD74liD0jQAB/dsAAAeBmuAAAJmXEAAN+MPwAAkZyFA= From: "Santosh Chokhani" To: 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_01C696BA.DCDC9215 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stefan, =20 We seem to be converging. =20 The way the relying party should see it and that is why I find the path processing to be compliant with X.509 and 3280 is as follows: =20 The path is good for no policies. The relying party accepts a path that is not good for any policy and makes an additional check (which the standards permit) to see if the end certificate has the desired policy. =20 I hope this clarifies the standard compliance. ________________________________ From: Stefan Santesson [mailto:stefans@microsoft.com]=20 Sent: Friday, June 23, 2006 5:28 AM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause =20 Santosh, =20 Yes, you are correct that the path will validate without any error in your example.=20 It will also have an empty set of valid policies. So accepting the EE certificate policies as valid (using that path) do require some kind of non-conformant policy checking. =20 I agree on your conclusion. However I have experienced implementers not feeling sure about this principle. Especially when it comes to configuration options enabled by an administrative UI and not just some mode switch in the OS. The escape clause in pki4ipsic was driven by this uncertainty. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards ________________________________ From: Santosh Chokhani [mailto:chokhani@orionsec.com]=20 Sent: den 23 juni 2006 02:48 To: Stefan Santesson; ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause =20 Stefan, =20 On disagree with you on 2. You seem to be asking for 2 and then saying that it is not valid. =20 A path validation profile (assuming we agree to ignore "require explicit policy") with setting acceptable policy set to anyPolicy is valid X.509 and 3280 configuration. In that case, there will not be a policy failure and relying party can always make additional checks. I encourage you to look at Section J.3 in Annex J of X.509. If you see any errors in Annex J, please let me know. =20 As to Standard compliant implementation putting itself in non-compliant mode, that is always acceptable. In that mode it will NOT be standard compliant; that is all. ________________________________ From: Stefan Santesson [mailto:stefans@microsoft.com]=20 Sent: Thursday, June 22, 2006 8:39 PM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause =20 Santosh, =20 There are 2 distinct reasons why your approach is not a generic solution to the problem. =20 1) The problem is generic and does not only apply to policy processing. The pki4ipsec issue was e.g. motivated from problems with EKU settings in existing certificates that does not satisfy new applications and usages. 2) If you need to test for a policy in the end certificate, that policy will not be valid unless supported by the path, regardless if policy constraints was set or not. =20 In the perfect world, compliant path processing will always do the job. In the real world, you may need to tweak the rules to make a new application fit into an existing infrastructure- =20 The question is still: Can a standards compliant implementation allow configuration of non conformant modifications to the validation process, or does that make the implementation as a whole non-conformant. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: den 22 juni 2006 22:59 To: ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause =20 Stefan, =20 I agree with sentiments voiced by Steve, Rich, and Sharon. =20 I have a simple solution to your concern from the relying party viewpoint. This observation is made with a long-held view of mine (and no one had provided a convincing logical or business argument) that the require explicit policy setting is a useless field. A relying party can always set acceptable policies to none. In that scenario, (require explicit policy) flag not withstanding, path validation will succeed. Now, the user can examine the end certificate policy. =20 You and I have had this discussion in another context. The basic premise is that if some field in the last certificate only is of interest and the "state" in the path validation process does not impact it, that need not be path of path validation engine. =20 Thus, you can judiciously use the 3280 Engine and obtain the result you seek. ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Guida, Richard [JJCUS] Sent: Thursday, June 22, 2006 2:48 PM To: Sharon Boeyen; 'Stefan Santesson'; ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause =20 Stefan - perhaps I am missing something, but there is nothing that stops a relying party from writing software that would perform processing extensions only on CA certs as you propose. As Sharon properly notes, that would not be RFC3280 compliant - but a relying party can choose to be non-compliant if it wishes. And such non-compliance only puts the relying party at risk, not others - so that is a "good thing" relatively speaking. But in the final analysis, seems to me that Sharon is absolutely correct (assuming she and I are interpreting your proposal properly) - unless X.509 is redefined, this would remain a circumstance of non-compliance. And so it should be treated as such. Very best regards -- Rich =20 =20 =20 Richard A. Guida=20 Director, Information Security=20 Johnson & Johnson=20 Room GS8217=20 410 George Street=20 New Brunswick, New Jersey 08901=20 Phone: 732 524 3785=20 -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon Boeyen Sent: Thursday, June 22, 2006 1:57 PM To: 'Stefan Santesson'; ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause Stefan, if I understand your comment correctly I strongly believe such an escape clause cannot possibly be added because this would render 3280bis non-compliant with X.509.=20 =20 My understanding of your comment is that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found in EE certificates. Is that a correct understanding?=20 =20 If it is a correct understanding, then any such implementation is non-conformant to X.509. 3280 is a profile of X.509 and as such can mandate certain optional elements or exclude optional elements but cannot reverse the mandatory processing from X.509. =20 Apologies if I've misunderstood your question. =20 Cheers, Sharon -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Wednesday, June 21, 2006 5:23 PM To: ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause As a last call comment on RFC 3280bis I would like to raise the question whether RFC 3280bis should include an escape clause clearly allowing relying parties to select what validation logic they deploy on certificate validation. =20 The background is the fact that many deployed PKIs are misconfigured.2 One such common misconfiguration is assignment of certificate policies and their inclusion in CA certificates. X.509 path processing requires policies in CA certificates to reflect the list of EE certificate policies that are valid for a path. Yet many deployments have included pure CA certificate policies in CA certificates, policies that are not included in any EE certificates and as such, policy processing is not possible in such PKIs. =20 Application wanting to use certificate policies in such PKI are simply forced to either fail or selectively neglect certain path processing rules. For a relying party such modification could be reasonable if the security implications has been well though through. However it is not clear if an implementation allowing such local configuration could be regarded as standard compliant. =20 There are more examples where deploying applications in misconfigured PKIs would need similar measures to work. =20 The pki4ipsec WG recently came to this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX WG. =20 The result was that the pki4ipsec profile included an escape clause as follows: =20 4.1. X.509 Certificates =20 Users deploying IKE and IPsec with certificates have often had little control over the capabilities of CAs available to them. Implementations of this specification may include configuration knobs to disable checks required by this specification in orde! r t o permit use with inflexible and/or noncompliant CAs. However, all checks on certificates exist for a specific reason involving the security of the entire system. Therefore, all checks MUST be enabled by default. Administrators and users ought to understand the security purpose for the various checks, and be clear on what security will be lost by disabling the check. =20 =20 I'm basically asking if RFC 3280bis path validation needs a similar escape clause or corresponding clarification that clearly allows local configuration of the validation logic. At least I think it is necessary to clearly allow such configuration of standards compliant applications as long as this is not the default functionality. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =09 ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: den 16 juni 2006 22:42 To: ietf-pkix@imc.org Subject: last call for 3280bis =20 Folks, =20 Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt ) =20 The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th. =20 Steve ------_=_NextPart_001_01C696BA.DCDC9215 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Stefan,

=

 

We seem to be = converging.

 

The way the relying party should = see it and that is why I find the path processing to be compliant with X.509 = and 3280 is as follows:

 

The path is good for no = policies.  The relying party accepts a path that is not good for any policy and makes = an additional check (which the standards permit) to see if the end = certificate has the desired policy.

 

I hope this clarifies the standard compliance.

From: = Stefan Santesson [mailto:stefans@microsoft.com]
Sent: Friday, June 23, = 2006 5:28 AM
To: Santosh Chokhani; ietf-pkix@imc.org
Subject: RE: last call = for 3280bis - escape clause

 

Santosh,

 

Yes, you are correct that the path = will validate without any error in your example. =

It will also have an empty set of = valid policies. So accepting the EE certificate policies as valid (using that = path) do require some kind of non-conformant policy = checking.

 

I agree on your conclusion. However = I have experienced implementers not feeling sure about this principle. = Especially when it comes to configuration options enabled by an administrative UI and = not just some mode switch in the OS.

The escape clause in pki4ipsic was = driven by this uncertainty.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: = Santosh Chokhani [mailto:chokhani@orionsec.com]
Sent: den 23 juni 2006 = 02:48
To: Stefan Santesson; ietf-pkix@imc.org
Subject: RE: last call = for 3280bis - escape clause

 

Stefan,

=

 

On disagree with you on 2. =  You seem to be asking for 2 and then saying that it is not = valid.

 

A path validation profile (assuming = we agree to ignore “require explicit policy”) with setting = acceptable policy set to anyPolicy is valid X.509 and 3280 configuration.  In = that case, there will not be a policy failure and relying party can always = make additional checks.  I encourage you to look at Section J.3 in Annex = J of X.509.  If you see any errors in Annex J, please let me = know.

 

As to Standard compliant = implementation putting itself in non-compliant mode, that is always acceptable. =  In that mode it will NOT be standard compliant; that is = all.

From: = Stefan Santesson [mailto:stefans@microsoft.com]
Sent: Thursday, June 22, = 2006 8:39 PM
To: Santosh Chokhani; ietf-pkix@imc.org
Subject: RE: last call = for 3280bis - escape clause

 

Santosh,

 

There are 2 distinct reasons why = your approach is not a generic solution to the = problem.

 

1)       = The problem is generic and does not only apply to policy processing. The pki4ipsec issue was e.g. motivated from problems with = EKU settings in existing certificates that does not satisfy new applications = and usages.

2)       = If you need to test for a policy in the end certificate, = that policy will not be valid unless supported by the path, regardless if = policy constraints was set or not.

 

In the perfect world, compliant = path processing will always do the job. In the real world, you may need to = tweak the rules to make a new application fit into an existing = infrastructure-

 

The question is still: Can a = standards compliant implementation allow configuration of non conformant = modifications to the validation process, or does that make the implementation as a whole non-conformant.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Santosh Chokhani
Sent: den 22 juni 2006 = 22:59
To: ietf-pkix@imc.org
Subject: RE: last call = for 3280bis - escape clause

 

Stefan,

=

 

I agree with sentiments voiced by = Steve, Rich, and Sharon.

 

I have a simple solution to your = concern from the relying party viewpoint.  This observation is made with a = long-held view of mine (and no one had provided a convincing logical or business argument) that the require explicit policy setting is a useless field. =  A relying party can always set acceptable policies to none.  In that scenario, (require explicit policy) flag not withstanding, path = validation will succeed.  Now, the user can examine the end certificate = policy.

 

You and I have had this discussion = in another context.  The basic premise is that if some field in the = last certificate only is of interest and the “state” in the path validation process does not impact it, that need not be path of path = validation engine.

 

Thus, you can judiciously use the = 3280 Engine and obtain the result you seek.

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Guida, Richard = [JJCUS]
Sent: Thursday, June 22, = 2006 2:48 PM
To: Sharon Boeyen; = 'Stefan Santesson'; ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

 

Stefan - perhaps I am missing = something, but there is nothing that stops a relying party from writing software = that would perform processing extensions only on CA certs as you = propose.  As Sharon properly notes, that would not be RFC3280 compliant - but a relying = party can choose to be non-compliant if it wishes.  And such non-compliance = only puts the relying party at risk, not others - so that is a = "good thing" relatively speaking.  But in the final analysis, seems = to me that Sharon is absolutely correct (assuming she and I are interpreting your proposal properly) - unless X.509 is redefined, this would remain a = circumstance of non-compliance.  And so it should be treated as such.  = Very best regards -- Rich

 

 

 

Richard A. Guida
Director, Information Security =

Johnson & = Johnson
Room GS8217
410 George Street
New Brunswick, = New Jersey  08901
Phone:  732 524 3785

-----Original = Message-----
From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon Boeyen
Sent: Thursday, June 22, = 2006 1:57 PM
To: 'Stefan Santesson'; ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

Stefan, if I understand your = comment correctly I strongly believe such an escape clause cannot possibly be = added because this would render 3280bis non-compliant with X.509. =

 

My understanding of your comment is = that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found = in EE certificates. Is that a correct understanding? =

 

If it is a correct understanding, = then any such implementation is non-conformant to X.509. 3280 is a profile of = X.509 and as such can mandate certain optional elements or exclude optional = elements but cannot reverse the mandatory processing from = X.509.

 

Apologies if I've misunderstood = your question.

 

Cheers,

=

Sharon

-----Original = Message-----
From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson
Sent: Wednesday, June 21, = 2006 5:23 PM
To: ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

As a last call comment on RFC = 3280bis I would like to raise the question whether RFC 3280bis should include an = escape clause clearly allowing relying parties to select what validation logic = they deploy on certificate validation.

 

The background is the fact that = many deployed PKIs are misconfigured.2

One such common misconfiguration is assignment of certificate policies and their inclusion in CA = certificates.

X.509 path processing requires = policies in CA certificates to reflect the list of EE certificate policies that are = valid for a path. Yet many deployments have included pure CA certificate = policies in CA certificates, policies that are not included in any EE certificates = and as such, policy processing is not possible in such = PKIs.

 

Application wanting to use = certificate policies in such PKI are simply forced to either fail or selectively = neglect certain path processing rules. For a relying party such modification = could be reasonable if the security implications has been well though = through.

However it is not clear if an implementation allowing such local configuration could be regarded as = standard compliant.

 

There are more examples where = deploying applications in misconfigured PKIs would need similar measures to = work.

 

The pki4ipsec WG recently came to = this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX = WG.

 

The result was that the pki4ipsec = profile included an escape clause as follows:

 

4.1.  X.509 =
Certificates
 
   Users deploying IKE and IPsec =
with certificates have often had =
little
   control over the capabilities of =
CAs available to them.
   Implementations of this =
specification may include configuration =
knobs
   to disable checks required by =
this specification in orde!
 r =
t
 o =
permit
   use with inflexible and/or =
noncompliant CAs.  However, all checks =
on
   certificates exist for a =
specific reason involving the security =
of
   the entire system.  =
Therefore, all checks MUST be enabled by =
default.
   Administrators and users ought =
to understand the security purpose =
for
   the various checks, and be clear =
on what security will be lost =
by
   disabling the =
check.

 

 

I'm basically asking if RFC 3280bis = path validation needs a similar escape clause or corresponding clarification = that clearly allows local configuration of the validation = logic.

At least I think it is necessary to clearly allow such configuration of standards compliant applications as = long as this is not the default functionality.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Stephen Kent
Sent: den 16 juni 2006 = 22:42
To: ietf-pkix@imc.org
Subject: last call for = 3280bis

 

Folks,

 

Based on the latest message from David Cooper, I am initiating = last call on "Internet X.509 Public Key Infrastructure, Certificate and = Certificate Revocation List (CRL) Profile" = (http://ietf.org/internet-drafts/draft-ietf-pki= x-rfc3280bis-03.txt)

 

The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many = folks), all comments must be received by July 5th.

 

Steve

------_=_NextPart_001_01C696BA.DCDC9215-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5NBCRZN058181; Fri, 23 Jun 2006 04:12:27 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5NBCRoe058180; Fri, 23 Jun 2006 04:12:27 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sottsym2.entrust.com (sottsym2.entrust.com [216.191.252.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5NBCPir058132 for ; Fri, 23 Jun 2006 04:12:25 -0700 (MST) (envelope-from sharon.boeyen@entrust.com) Received: from sottmxsecs3.entrust.com (unknown [216.191.252.14]) by sottsym2.entrust.com (Symantec Mail Security) with SMTP id D0D1811F6 for ; Fri, 23 Jun 2006 07:12:19 -0400 (EDT) Received: (qmail 28716 invoked from network); 23 Jun 2006 11:12:19 -0000 Received: from sharon.boeyen@entrust.com by sottmxsecs3.entrust.com with EntrustECS-Server-7.4;23 Jun 2006 11:12:19 -0000 Received: from sottmxs00.entrust.com (10.4.61.22) by sottmxsecs3.entrust.com with SMTP; 23 Jun 2006 11:12:17 -0000 Received: by sottmxs00.entrust.com with Internet Mail Service (5.5.2657.72) id ; Fri, 23 Jun 2006 07:12:18 -0400 Message-ID: <7A3E1242FA9989439AD1F9B2D71C287F09EAD1B5@sottmxs05.entrust.com> From: Sharon Boeyen To: "'Stefan Santesson'" , Santosh Chokhani , ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause Date: Fri, 23 Jun 2006 07:12:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C696B5.8CC0B636" X-Brightmail-Tracker: AAAAAA== Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C696B5.8CC0B636 Content-Type: text/plain There should not be any escape clause in 3280bis for any non-conformant behavior. 3280bis is a profile of X.509 - it is not a narrative to describe various types of non-conformant behavior, regardless of what it is. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Friday, June 23, 2006 5:28 AM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause Santosh, Yes, you are correct that the path will validate without any error in your example. It will also have an empty set of valid policies. So accepting the EE certificate policies as valid (using that path) do require some kind of non-conformant policy checking. I agree on your conclusion. However I have experienced implementers not feeling sure about this principle. Especially when it comes to configuration options enabled by an administrative UI and not just some mode switch in the OS. The escape clause in pki4ipsic was driven by this uncertainty. Stefan Santesson Senior Program Manager Windows Security, Standards _____ From: Santosh Chokhani [mailto:chokhani@orionsec.com] Sent: den 23 juni 2006 02:48 To: Stefan Santesson; ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause Stefan, On disagree with you on 2. You seem to be asking for 2 and then saying that it is not valid. A path validation profile (assuming we agree to ignore "require explicit policy") with setting acceptable policy set to anyPolicy is valid X.509 and 3280 configuration. In that case, there will not be a policy failure and relying party can always make additional checks. I encourage you to look at Section J.3 in Annex J of X.509. If you see any errors in Annex J, please let me know. As to Standard compliant implementation putting itself in non-compliant mode, that is always acceptable. In that mode it will NOT be standard compliant; that is all. _____ From: Stefan Santesson [mailto:stefans@microsoft.com] Sent: Thursday, June 22, 2006 8:39 PM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause Santosh, There are 2 distinct reasons why your approach is not a generic solution to the problem. 1) The problem is generic and does not only apply to policy processing. The pki4ipsec issue was e.g. motivated from problems with EKU settings in existing certificates that does not satisfy new applications and usages. 2) If you need to test for a policy in the end certificate, that policy will not be valid unless supported by the path, regardless if policy constraints was set or not. In the perfect world, compliant path processing will always do the job. In the real world, you may need to tweak the rules to make a new application fit into an existing infrastructure- The question is still: Can a standards compliant implementation allow configuration of non conformant modifications to the validation process, or does that make the implementation as a whole non-conformant. Stefan Santesson Senior Program Manager Windows Security, Standards _____ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: den 22 juni 2006 22:59 To: ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause Stefan, I agree with sentiments voiced by Steve, Rich, and Sharon. I have a simple solution to your concern from the relying party viewpoint. This observation is made with a long-held view of mine (and no one had provided a convincing logical or business argument) that the require explicit policy setting is a useless field. A relying party can always set acceptable policies to none. In that scenario, (require explicit policy) flag not withstanding, path validation will succeed. Now, the user can examine the end certificate policy. You and I have had this discussion in another context. The basic premise is that if some field in the last certificate only is of interest and the "state" in the path validation process does not impact it, that need not be path of path validation engine. Thus, you can judiciously use the 3280 Engine and obtain the result you seek. _____ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Guida, Richard [JJCUS] Sent: Thursday, June 22, 2006 2:48 PM To: Sharon Boeyen; 'Stefan Santesson'; ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause Stefan - perhaps I am missing something, but there is nothing that stops a relying party from writing software that would perform processing extensions only on CA certs as you propose. As Sharon properly notes, that would not be RFC3280 compliant - but a relying party can choose to be non-compliant if it wishes. And such non-compliance only puts the relying party at risk, not others - so that is a "good thing" relatively speaking. But in the final analysis, seems to me that Sharon is absolutely correct (assuming she and I are interpreting your proposal properly) - unless X.509 is redefined, this would remain a circumstance of non-compliance. And so it should be treated as such. Very best regards -- Rich Richard A. Guida Director, Information Security Johnson & Johnson Room GS8217 410 George Street New Brunswick, New Jersey 08901 Phone: 732 524 3785 -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon Boeyen Sent: Thursday, June 22, 2006 1:57 PM To: 'Stefan Santesson'; ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause Stefan, if I understand your comment correctly I strongly believe such an escape clause cannot possibly be added because this would render 3280bis non-compliant with X.509. My understanding of your comment is that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found in EE certificates. Is that a correct understanding? If it is a correct understanding, then any such implementation is non-conformant to X.509. 3280 is a profile of X.509 and as such can mandate certain optional elements or exclude optional elements but cannot reverse the mandatory processing from X.509. Apologies if I've misunderstood your question. Cheers, Sharon -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Wednesday, June 21, 2006 5:23 PM To: ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause As a last call comment on RFC 3280bis I would like to raise the question whether RFC 3280bis should include an escape clause clearly allowing relying parties to select what validation logic they deploy on certificate validation. The background is the fact that many deployed PKIs are misconfigured.2 One such common misconfiguration is assignment of certificate policies and their inclusion in CA certificates. X.509 path processing requires policies in CA certificates to reflect the list of EE certificate policies that are valid for a path. Yet many deployments have included pure CA certificate policies in CA certificates, policies that are not included in any EE certificates and as such, policy processing is not possible in such PKIs. Application wanting to use certificate policies in such PKI are simply forced to either fail or selectively neglect certain path processing rules. For a relying party such modification could be reasonable if the security implications has been well though through. However it is not clear if an implementation allowing such local configuration could be regarded as standard compliant. There are more examples where deploying applications in misconfigured PKIs would need similar measures to work. The pki4ipsec WG recently came to this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX WG. The result was that the pki4ipsec profile included an escape clause as follows: 4.1. X.509 Certificates Users deploying IKE and IPsec with certificates have often had little control over the capabilities of CAs available to them. Implementations of this specification may include configuration knobs to disable checks required by this specification in orde! r t o permit use with inflexible and/or noncompliant CAs. However, all checks on certificates exist for a specific reason involving the security of the entire system. Therefore, all checks MUST be enabled by default. Administrators and users ought to understand the security purpose for the various checks, and be clear on what security will be lost by disabling the check. I'm basically asking if RFC 3280bis path validation needs a similar escape clause or corresponding clarification that clearly allows local configuration of the validation logic. At least I think it is necessary to clearly allow such configuration of standards compliant applications as long as this is not the default functionality. Stefan Santesson Senior Program Manager Windows Security, Standards _____ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: den 16 juni 2006 22:42 To: ietf-pkix@imc.org Subject: last call for 3280bis Folks, Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" ( http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt) The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th. Steve ------_=_NextPart_001_01C696B5.8CC0B636 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message
There should not be any escape clause in 3280bis for any non-conformant = behavior.=20 3280bis is a profile of X.509 - it is not a narrative to describe = various types=20 of non-conformant behavior, regardless of what it is.
-----Original = Message-----
From:=20 owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf=20 Of Stefan Santesson
Sent: Friday, June 23, 2006 5:28=20 AM
To: Santosh Chokhani; ietf-pkix@imc.org
Subject: = RE: last=20 call for 3280bis - escape clause

Santosh,

 

Yes, you = are correct=20 that the path will validate without any error in your example.=20

It will = also have an=20 empty set of valid policies. So accepting the EE certificate policies = as valid=20 (using that path) do require some kind of non-conformant policy=20 checking.

 

I agree on = your=20 conclusion. However I have experienced implementers not feeling sure = about=20 this principle. Especially when it comes to configuration options = enabled by=20 an administrative UI and not just some mode switch in the=20 OS.

The escape = clause in=20 pki4ipsic was driven by this = uncertainty.

 

 

Stefan=20 Santesson

Senior = Program=20 Manager

Windows = Security,=20 Standards

From: Santosh=20 Chokhani [mailto:chokhani@orionsec.com]
Sent: den 23 juni 2006 = 02:48
To: Stefan Santesson;=20 ietf-pkix@imc.org
Subject:=20 RE: last call for 3280bis - escape = clause

 

Stefan,

 

On = disagree with you=20 on 2.  You seem to be asking for 2 and then saying that it is = not=20 valid.

 

A path = validation=20 profile (assuming we agree to ignore "require explicit policy") with = setting=20 acceptable policy set to anyPolicy is valid X.509 and 3280 = configuration.=20  In that case, there will not be a policy failure and relying = party can=20 always make additional checks.  I encourage you to look at = Section J.3 in=20 Annex J of X.509.  If you see any errors in Annex J, please let = me=20 know.

 

As to = Standard=20 compliant implementation putting itself in non-compliant mode, that = is always=20 acceptable.  In that mode it will NOT be standard compliant; = that is=20 all.

From: Stefan=20 Santesson [mailto:stefans@microsoft.com]
Sent: Thursday, June 22, 2006 = 8:39=20 PM
To: Santosh = Chokhani;=20 ietf-pkix@imc.org
Subject:=20 RE: last call for 3280bis - escape = clause

 

Santosh,

 

There are = 2 distinct=20 reasons why your approach is not a generic solution to the=20 problem.

 

1)      =20 The=20 problem is generic and does not only apply to policy processing. The = pki4ipsec=20 issue was e.g. motivated from problems with EKU settings in existing=20 certificates that does not satisfy new applications and=20 usages.

2)      =20 If you=20 need to test for a policy in the end certificate, that policy will = not be=20 valid unless supported by the path, regardless if policy constraints = was set=20 or not.

 

In the = perfect world,=20 compliant path processing will always do the job. In the real world, = you may=20 need to tweak the rules to make a new application fit into an = existing=20 infrastructure-

 

The = question is=20 still: Can a standards compliant implementation allow configuration = of non=20 conformant modifications to the validation process, or does that make = the=20 implementation as a whole = non-conformant.

 

 

Stefan=20 Santesson

Senior = Program=20 Manager

Windows = Security,=20 Standards

From:=20 owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Santosh = Chokhani
Sent: den 22 juni 2006 = 22:59
To: = ietf-pkix@imc.org
Subject: RE: last call for = 3280bis -=20 escape clause

 

Stefan,

 

I agree = with=20 sentiments voiced by Steve, Rich, and = Sharon.

 

I have a = simple=20 solution to your concern from the relying party viewpoint.  This = observation is made with a long-held view of mine (and no one had = provided a=20 convincing logical or business argument) that the require explicit = policy=20 setting is a useless field.  A relying party can always set = acceptable=20 policies to none.  In that scenario, (require explicit policy) = flag not=20 withstanding, path validation will succeed.  Now, the user can = examine=20 the end certificate policy.

 

You and I = have had=20 this discussion in another context.  The basic premise is that = if some=20 field in the last certificate only is of interest and the "state" in = the path=20 validation process does not impact it, that need not be path of path=20 validation engine.

 

Thus, you = can=20 judiciously use the 3280 Engine and obtain the result you=20 seek.

From:=20 owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Guida, Richard=20 [JJCUS]
Sent: = Thursday, June=20 22, 2006 2:48 PM
To: Sharon=20 Boeyen; 'Stefan Santesson'; ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call for = 3280bis -=20 escape clause

 

Stefan - = perhaps I am=20 missing something, but there is nothing that stops a relying party = from=20 writing software that would perform processing extensions only = on CA=20 certs as you propose.  As Sharon properly notes, that would = not be=20 RFC3280 compliant - but a relying party can choose to be = non-compliant if it=20 wishes.  And such non-compliance only puts the relying party at = risk, not=20 others - so that is a "good thing" relatively speaking.  = But in the=20 final analysis, seems to me that Sharon is absolutely correct = (assuming she=20 and I are interpreting your proposal properly) - unless X.509 is = redefined, this would remain a circumstance of non-compliance.  = And so it=20 should be treated as such.  Very best regards --=20 Rich

 

 

 

Richard A.=20 Guida
Director,=20 Information Security

Johnson=20 & Johnson
Room = GS8217=20
410 George Street=20
New Brunswick, = New Jersey  08901 =
Phone:  732 524=20 3785

-----Original=20 Message-----
From:=20 owner-ietf-pkix@mail.imc.org = [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon = Boeyen
Sent: Thursday, June 22, = 2006 1:57=20 PM
To: 'Stefan = Santesson';=20 ietf-pkix@imc.org
Cc:=20 Stephen Kent
Subject: RE:=20 last call for 3280bis - escape clause

Stefan, = if I=20 understand your comment correctly I strongly believe such an escape = clause=20 cannot possibly be added because this would render 3280bis = non-compliant=20 with X.509.

 

My = understanding of=20 your comment is that the escape clause would enable a path = validation engine=20 to process the certificate policy OIDs found in CA certificates but = ignore=20 those found in EE certificates. Is that a correct understanding?=20

 

If it is = a correct=20 understanding, then any such implementation is non-conformant to = X.509. 3280=20 is a profile of X.509 and as such can mandate certain optional = elements or=20 exclude optional elements but cannot reverse the mandatory = processing from=20 X.509.

 

Apologies if I've=20 misunderstood your question.

 

Cheers,

Sharon

-----Original=20 Message-----
From:=20 owner-ietf-pkix@mail.imc.org = [mailto:owner-ietf-pkix@mail.imc.org]=20 On Behalf Of = Stefan=20 Santesson
Sent:=20 Wednesday, June 21, 2006 5:23 PM
To: = ietf-pkix@imc.org
Cc: Stephen = Kent
Subject: RE: last call for = 3280bis -=20 escape clause

As a = last call=20 comment on RFC 3280bis I would like to raise the question whether = RFC=20 3280bis should include an escape clause clearly allowing relying = parties=20 to select what validation logic they deploy on certificate=20 validation.

 

The = background is=20 the fact that many deployed PKIs are=20 misconfigured.2

One = such common=20 misconfiguration is assignment of certificate policies and their = inclusion=20 in CA certificates.

X.509 = path=20 processing requires policies in CA certificates to reflect the = list of EE=20 certificate policies that are valid for a path. Yet many = deployments have=20 included pure CA certificate policies in CA certificates, = policies that=20 are not included in any EE certificates and as such, policy = processing is=20 not possible in such PKIs.

 

Application=20 wanting to use certificate policies in such PKI are simply forced = to=20 either fail or selectively neglect certain path processing rules. = For a=20 relying party such modification could be reasonable if the = security=20 implications has been well though = through.

However it is not=20 clear if an implementation allowing such local configuration = could be=20 regarded as standard compliant.

 

There = are more=20 examples where deploying applications in misconfigured PKIs would = need=20 similar measures to work.

 

The = pki4ipsec WG=20 recently came to this conclusion in their PKI profile and this = lead to an=20 intense debate which included core participants from the PKIX=20 WG.

 

The = result was=20 that the pki4ipsec profile included an escape clause as=20 follows:

 

4.1.  X.509 =
Certificates
 
   Users =
deploying IKE and IPsec with certificates have often had =
little
   control over the =
capabilities of CAs available to =
them.
   Implementations =
of this specification may include configuration =
knobs
   to disable checks =
required by this specification in =
orde!
 r =
t
 o =
permit
   use with =
inflexible and/or noncompliant CAs.  However, all checks =
on
   certificates =
exist for a specific reason involving the security =
of
   the entire =
system.  Therefore, all checks MUST be enabled by =
default.
   Administrators =
and users ought to understand the security purpose =
for
   the various =
checks, and be clear on what security will be lost =
by
   disabling the =
check.

 

 

I'm = basically=20 asking if RFC 3280bis path validation needs a similar escape = clause or=20 corresponding clarification that clearly allows local = configuration of the=20 validation logic.

At = least I think=20 it is necessary to clearly allow such configuration of standards = compliant=20 applications as long as this is not the default=20 functionality.

 

 

Stefan=20 Santesson

Senior Program=20 Manager

Windows=20 Security, = Standards

From:=20 owner-ietf-pkix@mail.imc.org = [mailto:owner-ietf-pkix@mail.imc.org]=20 On Behalf Of = Stephen=20 Kent
Sent: den = 16 juni=20 2006 22:42
To: = ietf-pkix@imc.org
Subject: last call for=20 3280bis

 

Folks,

 

Based on the latest message from David = Cooper, I=20 am initiating last call on "Internet X.509 Public Key = Infrastructure,=20 Certificate and Certificate Revocation List (CRL)=20 Profile" (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt<= /SPAN>)

 

The last call will last for two weeks. = In=20 deference to the U.S. Independence Dya holiday (which means July = 3rd is a=20 holiday for many folks), all comments must be received by July=20 5th.

 

Steve

= ------_=_NextPart_001_01C696B5.8CC0B636-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5N9sWww039358; Fri, 23 Jun 2006 02:54:32 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5N9sWSq039357; Fri, 23 Jun 2006 02:54:32 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5N9sUv1039334 for ; Fri, 23 Jun 2006 02:54:31 -0700 (MST) (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); Fri, 23 Jun 2006 10:54:27 +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: SRV Name: draft-ietf-pkix-srvsan-02.txt: typos, examples Date: Fri, 23 Jun 2006 10:54:26 +0100 Message-ID: In-Reply-To: <6215401E01247448A306C54F499111F2C4AB35@WSMSG2103V.srv.dir.telstra.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SRV Name: draft-ietf-pkix-srvsan-02.txt: typos, examples thread-index: AcaWWVJxh0AAs+BBSLGoi/jkDBS2aQAEuBXgAA8httA= From: "Stefan Santesson" To: "Manger, James H" , X-OriginalArrivalTime: 23 Jun 2006 09:54:27.0346 (UTC) FILETIME=[03C51720:01C696AB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k5N9sVv1039352 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Thanks for the review James, Comments in-line, Stefan Santesson Senior Program Manager Windows Security, Standards -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Manger, James H Sent: den 23 juni 2006 06:50 To: ietf-pkix@imc.org Subject: SRV Name: draft-ietf-pkix-srvsan-02.txt: typos, examples Comments on draft-ietf-pkix-srvsan-02.txt 1. Abstract, page 1, typo: "filed" -> "field" Will be fixed 2. It would be nice if the full value of the id-on-dnsSRV object identifier was provided in this document, without requiring a separate lookup of RFC 3280. Add the following ASN.1 comment just above the id-on definition in Appendix A.1 (page 8), Appendix A.2 (page 8) and section 2 "Name Definitions" (page 3): -- id-pkix OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7} OK 3. Include an example with an IDN so it is immediately obvious that punycode is not used in an SRVName value. Add the following after the current example in section 2, page 4: Example: The "mail" service at nave.net (an IDN, which becomes xn--nave-6pa.net when encoded as an IDNA) would use the following 15-character SRVName value: _mail.nave.net Its 16-byte UTF-8 encoding is (in hex): 5F 6D 61 69 6C 2E 6E 61 C3 AF 76 65 2E 6E 65 74 Thanks for providing the sample. Looks fine to me. 4. Appendix A.2 (page 9), glitch: "permanentIdentifier" -> "srvName" OK I'm caught. Yes I borrowed some constructions from the PI draft. Thought I got that fixed. 5. Why bother with the (SIZE (1..MAX)) restriction? Delete it. It seems to be the custom to use it. I don't feel enough of an ASN.1 expert to have the correct answer. Someone else may have an opinon. I'll be happy to remove it as long as it works. 6. SRVName is defined (in section 2) to have the form _Service.Name. The very next section violates that definition by allowing SRVName to hold just a service name or just a domain name. The syntax to hold a name is not necessarily the same syntax required to hold a matching rule for that name. This is a general fault with the construction of the nameConstraints extension so it does not need to be fixed in this specification (I am just having a rant). Yes, as you state yourself. The actual name in SAN and matching data in name constraints have different syntax rules. Simply to avoid definition of wildcards. I think its fin as it is. 7. Appendix A, page 7: "augmented with 1993 the UNIVERSAL Type" -> "augmented with the 1993 UNIVERSAL Type" OK 8. Appendix A. Are the modules names supposed to end with "..SAN88" and "..SAN93", or is it supposed to be "..ASN88" and "..ASN93"? The current names are the names assigned by Russ, -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Internet-Drafts@ietf.org Sent: Friday, 23 June 2006 8:50 AM To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org Subject: I-D ACTION:draft-ietf-pkix-srvsan-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure Subject Alternative Name for expression of service name Author(s) : S. Santesson Filename : draft-ietf-pkix-srvsan-02.txt Pages : 11 Date : 2006-6-22 This document defines a new name form for inclusion in the otherName filed of an X.509 Subject Alternative Name extension which allows a certificate subject to be associated with the service name and domain name components of a DNS Service Resource Record. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-srvsan-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-srvsan-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-srvsan-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. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5N9SV1o033764; Fri, 23 Jun 2006 02:28:31 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5N9SVIA033763; Fri, 23 Jun 2006 02:28:31 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5N9STHA033741 for ; Fri, 23 Jun 2006 02:28:29 -0700 (MST) (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); Fri, 23 Jun 2006 10:28:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C696A7.5F1E4C4B" Subject: RE: last call for 3280bis - escape clause Date: Fri, 23 Jun 2006 10:28:21 +0100 Message-ID: In-Reply-To: <82D5657AE1F54347A734BDD33637C8790359DA0E@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: last call for 3280bis - escape clause thread-index: AcaWNVMoloaBo6PDT0CPPD74liD0jQAB/dsAAAeBmuAAAJmXEAAN+MPw From: "Stefan Santesson" To: "Santosh Chokhani" , X-OriginalArrivalTime: 23 Jun 2006 09:28:23.0153 (UTC) FILETIME=[5F702E10:01C696A7] 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_01C696A7.5F1E4C4B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Santosh, =20 Yes, you are correct that the path will validate without any error in your example.=20 It will also have an empty set of valid policies. So accepting the EE certificate policies as valid (using that path) do require some kind of non-conformant policy checking. =20 I agree on your conclusion. However I have experienced implementers not feeling sure about this principle. Especially when it comes to configuration options enabled by an administrative UI and not just some mode switch in the OS. The escape clause in pki4ipsic was driven by this uncertainty. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards ________________________________ From: Santosh Chokhani [mailto:chokhani@orionsec.com]=20 Sent: den 23 juni 2006 02:48 To: Stefan Santesson; ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause =20 Stefan, =20 On disagree with you on 2. You seem to be asking for 2 and then saying that it is not valid. =20 A path validation profile (assuming we agree to ignore "require explicit policy") with setting acceptable policy set to anyPolicy is valid X.509 and 3280 configuration. In that case, there will not be a policy failure and relying party can always make additional checks. I encourage you to look at Section J.3 in Annex J of X.509. If you see any errors in Annex J, please let me know. =20 As to Standard compliant implementation putting itself in non-compliant mode, that is always acceptable. In that mode it will NOT be standard compliant; that is all. ________________________________ From: Stefan Santesson [mailto:stefans@microsoft.com]=20 Sent: Thursday, June 22, 2006 8:39 PM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause =20 Santosh, =20 There are 2 distinct reasons why your approach is not a generic solution to the problem. =20 1) The problem is generic and does not only apply to policy processing. The pki4ipsec issue was e.g. motivated from problems with EKU settings in existing certificates that does not satisfy new applications and usages. 2) If you need to test for a policy in the end certificate, that policy will not be valid unless supported by the path, regardless if policy constraints was set or not. =20 In the perfect world, compliant path processing will always do the job. In the real world, you may need to tweak the rules to make a new application fit into an existing infrastructure- =20 The question is still: Can a standards compliant implementation allow configuration of non conformant modifications to the validation process, or does that make the implementation as a whole non-conformant. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: den 22 juni 2006 22:59 To: ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause =20 Stefan, =20 I agree with sentiments voiced by Steve, Rich, and Sharon. =20 I have a simple solution to your concern from the relying party viewpoint. This observation is made with a long-held view of mine (and no one had provided a convincing logical or business argument) that the require explicit policy setting is a useless field. A relying party can always set acceptable policies to none. In that scenario, (require explicit policy) flag not withstanding, path validation will succeed. Now, the user can examine the end certificate policy. =20 You and I have had this discussion in another context. The basic premise is that if some field in the last certificate only is of interest and the "state" in the path validation process does not impact it, that need not be path of path validation engine. =20 Thus, you can judiciously use the 3280 Engine and obtain the result you seek. ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Guida, Richard [JJCUS] Sent: Thursday, June 22, 2006 2:48 PM To: Sharon Boeyen; 'Stefan Santesson'; ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause =20 Stefan - perhaps I am missing something, but there is nothing that stops a relying party from writing software that would perform processing extensions only on CA certs as you propose. As Sharon properly notes, that would not be RFC3280 compliant - but a relying party can choose to be non-compliant if it wishes. And such non-compliance only puts the relying party at risk, not others - so that is a "good thing" relatively speaking. But in the final analysis, seems to me that Sharon is absolutely correct (assuming she and I are interpreting your proposal properly) - unless X.509 is redefined, this would remain a circumstance of non-compliance. And so it should be treated as such. Very best regards -- Rich =20 =20 =20 Richard A. Guida=20 Director, Information Security=20 Johnson & Johnson=20 Room GS8217=20 410 George Street=20 New Brunswick, New Jersey 08901=20 Phone: 732 524 3785=20 -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon Boeyen Sent: Thursday, June 22, 2006 1:57 PM To: 'Stefan Santesson'; ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause Stefan, if I understand your comment correctly I strongly believe such an escape clause cannot possibly be added because this would render 3280bis non-compliant with X.509.=20 =20 My understanding of your comment is that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found in EE certificates. Is that a correct understanding?=20 =20 If it is a correct understanding, then any such implementation is non-conformant to X.509. 3280 is a profile of X.509 and as such can mandate certain optional elements or exclude optional elements but cannot reverse the mandatory processing from X.509. =20 Apologies if I've misunderstood your question. =20 Cheers, Sharon -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Wednesday, June 21, 2006 5:23 PM To: ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause As a last call comment on RFC 3280bis I would like to raise the question whether RFC 3280bis should include an escape clause clearly allowing relying parties to select what validation logic they deploy on certificate validation. =20 The background is the fact that many deployed PKIs are misconfigured.2 One such common misconfiguration is assignment of certificate policies and their inclusion in CA certificates. X.509 path processing requires policies in CA certificates to reflect the list of EE certificate policies that are valid for a path. Yet many deployments have included pure CA certificate policies in CA certificates, policies that are not included in any EE certificates and as such, policy processing is not possible in such PKIs. =20 Application wanting to use certificate policies in such PKI are simply forced to either fail or selectively neglect certain path processing rules. For a relying party such modification could be reasonable if the security implications has been well though through. However it is not clear if an implementation allowing such local configuration could be regarded as standard compliant. =20 There are more examples where deploying applications in misconfigured PKIs would need similar measures to work. =20 The pki4ipsec WG recently came to this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX WG. =20 The result was that the pki4ipsec profile included an escape clause as follows: =20 4.1. X.509 Certificates =20 Users deploying IKE and IPsec with certificates have often had little control over the capabilities of CAs available to them. Implementations of this specification may include configuration knobs to disable checks required by this specification in orde! r t o permit use with inflexible and/or noncompliant CAs. However, all checks on certificates exist for a specific reason involving the security of the entire system. Therefore, all checks MUST be enabled by default. Administrators and users ought to understand the security purpose for the various checks, and be clear on what security will be lost by disabling the check. =20 =20 I'm basically asking if RFC 3280bis path validation needs a similar escape clause or corresponding clarification that clearly allows local configuration of the validation logic. At least I think it is necessary to clearly allow such configuration of standards compliant applications as long as this is not the default functionality. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =09 ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: den 16 juni 2006 22:42 To: ietf-pkix@imc.org Subject: last call for 3280bis =20 Folks, =20 Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt ) =20 The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th. =20 Steve ------_=_NextPart_001_01C696A7.5F1E4C4B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Santosh,

 

Yes, you are correct that the path = will validate without any error in your example.

It will also have an empty set of = valid policies. So accepting the EE certificate policies as valid (using that = path) do require some kind of non-conformant policy = checking.

 

I agree on your conclusion. However = I have experienced implementers not feeling sure about this principle. = Especially when it comes to configuration options enabled by an administrative UI and = not just some mode switch in the OS.

The escape clause in pki4ipsic was = driven by this uncertainty.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: = Santosh Chokhani [mailto:chokhani@orionsec.com]
Sent: den 23 juni 2006 = 02:48
To: Stefan Santesson; ietf-pkix@imc.org
Subject: RE: last call = for 3280bis - escape clause

 

Stefan,

=

 

On disagree with you on 2. =  You seem to be asking for 2 and then saying that it is not = valid.

 

A path validation profile (assuming = we agree to ignore “require explicit policy”) with setting = acceptable policy set to anyPolicy is valid X.509 and 3280 configuration.  In = that case, there will not be a policy failure and relying party can always = make additional checks.  I encourage you to look at Section J.3 in Annex = J of X.509.  If you see any errors in Annex J, please let me = know.

 

As to Standard compliant = implementation putting itself in non-compliant mode, that is always acceptable. =  In that mode it will NOT be standard compliant; that is = all.

From: = Stefan Santesson [mailto:stefans@microsoft.com]
Sent: Thursday, June 22, = 2006 8:39 PM
To: Santosh Chokhani; ietf-pkix@imc.org
Subject: RE: last call = for 3280bis - escape clause

 

Santosh,

 

There are 2 distinct reasons why = your approach is not a generic solution to the = problem.

 

1)       = The problem is generic and does not only apply to policy processing. The pki4ipsec issue was e.g. motivated from problems with = EKU settings in existing certificates that does not satisfy new applications = and usages.

2)       = If you need to test for a policy in the end certificate, = that policy will not be valid unless supported by the path, regardless if = policy constraints was set or not.

 

In the perfect world, compliant = path processing will always do the job. In the real world, you may need to = tweak the rules to make a new application fit into an existing = infrastructure-

 

The question is still: Can a = standards compliant implementation allow configuration of non conformant = modifications to the validation process, or does that make the implementation as a whole non-conformant.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Santosh Chokhani
Sent: den 22 juni 2006 = 22:59
To: ietf-pkix@imc.org
Subject: RE: last call = for 3280bis - escape clause

 

Stefan,

=

 

I agree with sentiments voiced by = Steve, Rich, and Sharon.

 

I have a simple solution to your = concern from the relying party viewpoint.  This observation is made with a long-held view of mine (and no one had provided a convincing logical or business argument) that the require explicit policy setting is a useless = field.  A relying party can always set acceptable policies to none. =  In that scenario, (require explicit policy) flag not withstanding, path = validation will succeed.  Now, the user can examine the end certificate = policy.

 

You and I have had this discussion = in another context.  The basic premise is that if some field in the = last certificate only is of interest and the “state” in the path validation process does not impact it, that need not be path of path = validation engine.

 

Thus, you can judiciously use the = 3280 Engine and obtain the result you seek.

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Guida, Richard = [JJCUS]
Sent: Thursday, June 22, = 2006 2:48 PM
To: Sharon Boeyen; = 'Stefan Santesson'; ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

 

Stefan - perhaps I am missing = something, but there is nothing that stops a relying party from writing software = that would perform processing extensions only on CA certs as you = propose.  As Sharon properly notes, that would not be RFC3280 compliant - but a relying = party can choose to be non-compliant if it wishes.  And such non-compliance = only puts the relying party at risk, not others - so that is a = "good thing" relatively speaking.  But in the final analysis, seems = to me that Sharon is absolutely correct (assuming she and I are interpreting your proposal properly) - unless X.509 is redefined, this would remain a = circumstance of non-compliance.  And so it should be treated as such.  = Very best regards -- Rich

 

 

 

Richard A. Guida
Director, Information Security =

Johnson & = Johnson
Room GS8217
410 George Street
New Brunswick, = New Jersey  08901
Phone:  732 524 3785

-----Original = Message-----
From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon Boeyen
Sent: Thursday, June 22, = 2006 1:57 PM
To: 'Stefan Santesson'; ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

Stefan, if I understand your = comment correctly I strongly believe such an escape clause cannot possibly be = added because this would render 3280bis non-compliant with X.509. =

 

My understanding of your comment is = that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found = in EE certificates. Is that a correct understanding? =

 

If it is a correct understanding, = then any such implementation is non-conformant to X.509. 3280 is a profile of = X.509 and as such can mandate certain optional elements or exclude optional = elements but cannot reverse the mandatory processing from = X.509.

 

Apologies if I've misunderstood = your question.

 

Cheers,

=

Sharon

-----Original = Message-----
From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson
Sent: Wednesday, June 21, = 2006 5:23 PM
To: ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

As a last call comment on RFC = 3280bis I would like to raise the question whether RFC 3280bis should include an = escape clause clearly allowing relying parties to select what validation logic = they deploy on certificate validation.

 

The background is the fact that = many deployed PKIs are misconfigured.2

One such common misconfiguration is assignment of certificate policies and their inclusion in CA = certificates.

X.509 path processing requires = policies in CA certificates to reflect the list of EE certificate policies that are = valid for a path. Yet many deployments have included pure CA certificate = policies in CA certificates, policies that are not included in any EE certificates = and as such, policy processing is not possible in such = PKIs.

 

Application wanting to use = certificate policies in such PKI are simply forced to either fail or selectively = neglect certain path processing rules. For a relying party such modification = could be reasonable if the security implications has been well though = through.

However it is not clear if an implementation allowing such local configuration could be regarded as = standard compliant.

 

There are more examples where = deploying applications in misconfigured PKIs would need similar measures to = work.

 

The pki4ipsec WG recently came to = this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX = WG.

 

The result was that the pki4ipsec = profile included an escape clause as follows:

 

4.1.  X.509 =
Certificates
 
   Users deploying IKE and IPsec =
with certificates have often had =
little
   control over the capabilities of =
CAs available to them.
   Implementations of this =
specification may include configuration =
knobs
   to disable checks required by =
this specification in orde!
 r =
t
 o =
permit
   use with inflexible and/or =
noncompliant CAs.  However, all checks =
on
   certificates exist for a =
specific reason involving the security =
of
   the entire system.  =
Therefore, all checks MUST be enabled by =
default.
   Administrators and users ought =
to understand the security purpose =
for
   the various checks, and be clear =
on what security will be lost =
by
   disabling the =
check.

 

 

I'm basically asking if RFC 3280bis = path validation needs a similar escape clause or corresponding clarification = that clearly allows local configuration of the validation = logic.

At least I think it is necessary to clearly allow such configuration of standards compliant applications as = long as this is not the default functionality.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Stephen Kent
Sent: den 16 juni 2006 = 22:42
To: ietf-pkix@imc.org
Subject: last call for = 3280bis

 

Folks,

 

Based on the latest message from David Cooper, I am initiating = last call on "Internet X.509 Public Key Infrastructure, Certificate and = Certificate Revocation List (CRL) Profile" = (http://ietf.org/internet-drafts/draft-ietf-pki= x-rfc3280bis-03.txt)

 

The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many = folks), all comments must be received by July 5th.

 

Steve

------_=_NextPart_001_01C696A7.5F1E4C4B-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5N4o15Q071649; Thu, 22 Jun 2006 21:50:01 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5N4o1dm071648; Thu, 22 Jun 2006 21:50:01 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailipbo.ntcif.telstra.com.au (mailipbo.ntcif.telstra.com.au [202.12.233.29]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5N4nwH9071620 for ; Thu, 22 Jun 2006 21:49:59 -0700 (MST) (envelope-from James.H.Manger@team.telstra.com) Received: from webi.ntcif.telstra.com.au (HELO mailbi.ntcif.telstra.com.au) ([202.12.162.19]) by mailipbo.ntcif.telstra.com.au with ESMTP; 23 Jun 2006 14:49:57 +1000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.ntcif.telstra.com.au (Postfix) with ESMTP id 2A2B5FF82 for ; Fri, 23 Jun 2006 14:49:57 +1000 (EST) Received: from wsmsg2902.srv.dir.telstra.com (wsmsg2902.srv.dir.telstra.com [172.49.40.51]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id OAA25844 for ; Fri, 23 Jun 2006 14:49:56 +1000 (EST) Received: from WSMSG2103V.srv.dir.telstra.com ([172.49.40.20]) by wsmsg2902.srv.dir.telstra.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jun 2006 14:49:52 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Subject: SRV Name: draft-ietf-pkix-srvsan-02.txt: typos, examples Date: Fri, 23 Jun 2006 14:49:51 +1000 Message-ID: <6215401E01247448A306C54F499111F2C4AB35@WSMSG2103V.srv.dir.telstra.com> Thread-Topic: SRV Name: draft-ietf-pkix-srvsan-02.txt: typos, examples Thread-Index: AcaWWVJxh0AAs+BBSLGoi/jkDBS2aQAEuBXg From: "Manger, James H" To: X-OriginalArrivalTime: 23 Jun 2006 04:49:52.0590 (UTC) FILETIME=[772A9EE0:01C69680] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id k5N4o0H9071633 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Comments on draft-ietf-pkix-srvsan-02.txt 1. Abstract, page 1, typo: "filed" -> "field" 2. It would be nice if the full value of the id-on-dnsSRV object identifier was provided in this document, without requiring a separate lookup of RFC 3280. Add the following ASN.1 comment just above the id-on definition in Appendix A.1 (page 8), Appendix A.2 (page 8) and section 2 "Name Definitions" (page 3): -- id-pkix OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7} 3. Include an example with an IDN so it is immediately obvious that punycode is not used in an SRVName value. Add the following after the current example in section 2, page 4: Example: The "mail" service at nave.net (an IDN, which becomes xn--nave-6pa.net when encoded as an IDNA) would use the following 15-character SRVName value: _mail.nave.net Its 16-byte UTF-8 encoding is (in hex): 5F 6D 61 69 6C 2E 6E 61 C3 AF 76 65 2E 6E 65 74 4. Appendix A.2 (page 9), glitch: "permanentIdentifier" -> "srvName" 5. Why bother with the (SIZE (1..MAX)) restriction? Delete it. 6. SRVName is defined (in section 2) to have the form _Service.Name. The very next section violates that definition by allowing SRVName to hold just a service name or just a domain name. The syntax to hold a name is not necessarily the same syntax required to hold a matching rule for that name. This is a general fault with the construction of the nameConstraints extension so it does not need to be fixed in this specification (I am just having a rant). 7. Appendix A, page 7: "augmented with 1993 the UNIVERSAL Type" -> "augmented with the 1993 UNIVERSAL Type" 8. Appendix A. Are the modules names supposed to end with "..SAN88" and "..SAN93", or is it supposed to be "..ASN88" and "..ASN93"? -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Internet-Drafts@ietf.org Sent: Friday, 23 June 2006 8:50 AM To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org Subject: I-D ACTION:draft-ietf-pkix-srvsan-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure Subject Alternative Name for expression of service name Author(s) : S. Santesson Filename : draft-ietf-pkix-srvsan-02.txt Pages : 11 Date : 2006-6-22 This document defines a new name form for inclusion in the otherName filed of an X.509 Subject Alternative Name extension which allows a certificate subject to be associated with the service name and domain name components of a DNS Service Resource Record. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-srvsan-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-srvsan-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-srvsan-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. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5N0lfAd007868; Thu, 22 Jun 2006 17:47:41 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5N0lfct007867; Thu, 22 Jun 2006 17:47:41 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5N0leg9007832 for ; Thu, 22 Jun 2006 17:47:41 -0700 (MST) (envelope-from chokhani@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6965F.1CC1663D" Subject: RE: last call for 3280bis - escape clause Date: Thu, 22 Jun 2006 17:47:35 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C8790359DA0E@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: last call for 3280bis - escape clause Thread-Index: AcaWNVMoloaBo6PDT0CPPD74liD0jQAB/dsAAAeBmuAAAJmXEA== From: "Santosh Chokhani" To: "Stefan Santesson" , 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_01C6965F.1CC1663D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stefan, =20 On disagree with you on 2. You seem to be asking for 2 and then saying that it is not valid. =20 A path validation profile (assuming we agree to ignore "require explicit policy") with setting acceptable policy set to anyPolicy is valid X.509 and 3280 configuration. In that case, there will not be a policy failure and relying party can always make additional checks. I encourage you to look at Section J.3 in Annex J of X.509. If you see any errors in Annex J, please let me know. =20 As to Standard compliant implementation putting itself in non-compliant mode, that is always acceptable. In that mode it will NOT be standard compliant; that is all. ________________________________ From: Stefan Santesson [mailto:stefans@microsoft.com]=20 Sent: Thursday, June 22, 2006 8:39 PM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause =20 Santosh, =20 There are 2 distinct reasons why your approach is not a generic solution to the problem. =20 1) The problem is generic and does not only apply to policy processing. The pki4ipsec issue was e.g. motivated from problems with EKU settings in existing certificates that does not satisfy new applications and usages. 2) If you need to test for a policy in the end certificate, that policy will not be valid unless supported by the path, regardless if policy constraints was set or not. =20 In the perfect world, compliant path processing will always do the job. In the real world, you may need to tweak the rules to make a new application fit into an existing infrastructure- =20 The question is still: Can a standards compliant implementation allow configuration of non conformant modifications to the validation process, or does that make the implementation as a whole non-conformant. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: den 22 juni 2006 22:59 To: ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause =20 Stefan, =20 I agree with sentiments voiced by Steve, Rich, and Sharon. =20 I have a simple solution to your concern from the relying party viewpoint. This observation is made with a long-held view of mine (and no one had provided a convincing logical or business argument) that the require explicit policy setting is a useless field. A relying party can always set acceptable policies to none. In that scenario, (require explicit policy) flag not withstanding, path validation will succeed. Now, the user can examine the end certificate policy. =20 You and I have had this discussion in another context. The basic premise is that if some field in the last certificate only is of interest and the "state" in the path validation process does not impact it, that need not be path of path validation engine. =20 Thus, you can judiciously use the 3280 Engine and obtain the result you seek. ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Guida, Richard [JJCUS] Sent: Thursday, June 22, 2006 2:48 PM To: Sharon Boeyen; 'Stefan Santesson'; ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause =20 Stefan - perhaps I am missing something, but there is nothing that stops a relying party from writing software that would perform processing extensions only on CA certs as you propose. As Sharon properly notes, that would not be RFC3280 compliant - but a relying party can choose to be non-compliant if it wishes. And such non-compliance only puts the relying party at risk, not others - so that is a "good thing" relatively speaking. But in the final analysis, seems to me that Sharon is absolutely correct (assuming she and I are interpreting your proposal properly) - unless X.509 is redefined, this would remain a circumstance of non-compliance. And so it should be treated as such. Very best regards -- Rich =20 =20 =20 Richard A. Guida=20 Director, Information Security=20 Johnson & Johnson=20 Room GS8217=20 410 George Street=20 New Brunswick, New Jersey 08901=20 Phone: 732 524 3785=20 -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon Boeyen Sent: Thursday, June 22, 2006 1:57 PM To: 'Stefan Santesson'; ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause Stefan, if I understand your comment correctly I strongly believe such an escape clause cannot possibly be added because this would render 3280bis non-compliant with X.509.=20 =20 My understanding of your comment is that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found in EE certificates. Is that a correct understanding?=20 =20 If it is a correct understanding, then any such implementation is non-conformant to X.509. 3280 is a profile of X.509 and as such can mandate certain optional elements or exclude optional elements but cannot reverse the mandatory processing from X.509. =20 Apologies if I've misunderstood your question. =20 Cheers, Sharon -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Wednesday, June 21, 2006 5:23 PM To: ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause As a last call comment on RFC 3280bis I would like to raise the question whether RFC 3280bis should include an escape clause clearly allowing relying parties to select what validation logic they deploy on certificate validation. =20 The background is the fact that many deployed PKIs are misconfigured.2 One such common misconfiguration is assignment of certificate policies and their inclusion in CA certificates. X.509 path processing requires policies in CA certificates to reflect the list of EE certificate policies that are valid for a path. Yet many deployments have included pure CA certificate policies in CA certificates, policies that are not included in any EE certificates and as such, policy processing is not possible in such PKIs. =20 Application wanting to use certificate policies in such PKI are simply forced to either fail or selectively neglect certain path processing rules. For a relying party such modification could be reasonable if the security implications has been well though through. However it is not clear if an implementation allowing such local configuration could be regarded as standard compliant. =20 There are more examples where deploying applications in misconfigured PKIs would need similar measures to work. =20 The pki4ipsec WG recently came to this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX WG. =20 The result was that the pki4ipsec profile included an escape clause as follows: =20 4.1. X.509 Certificates =20 Users deploying IKE and IPsec with certificates have often had little control over the capabilities of CAs available to them. Implementations of this specification may include configuration knobs to disable checks required by this specification in orde! r t o permit use with inflexible and/or noncompliant CAs. However, all checks on certificates exist for a specific reason involving the security of the entire system. Therefore, all checks MUST be enabled by default. Administrators and users ought to understand the security purpose for the various checks, and be clear on what security will be lost by disabling the check. =20 =20 I'm basically asking if RFC 3280bis path validation needs a similar escape clause or corresponding clarification that clearly allows local configuration of the validation logic. At least I think it is necessary to clearly allow such configuration of standards compliant applications as long as this is not the default functionality. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =09 ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: den 16 juni 2006 22:42 To: ietf-pkix@imc.org Subject: last call for 3280bis =20 Folks, =20 Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt ) =20 The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th. =20 Steve ------_=_NextPart_001_01C6965F.1CC1663D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Stefan,

=

 

On disagree with you on 2. =  You seem to be asking for 2 and then saying that it is not = valid.

 

A path validation profile (assuming = we agree to ignore “require explicit policy”) with setting = acceptable policy set to anyPolicy is valid X.509 and 3280 configuration.  In = that case, there will not be a policy failure and relying party can always make = additional checks.  I encourage you to look at Section J.3 in Annex J of = X.509.  If you see any errors in Annex J, please let me = know.

 

As to Standard compliant = implementation putting itself in non-compliant mode, that is always acceptable. =  In that mode it will NOT be standard compliant; that is = all.

From: = Stefan Santesson [mailto:stefans@microsoft.com]
Sent: Thursday, June 22, = 2006 8:39 PM
To: Santosh Chokhani; ietf-pkix@imc.org
Subject: RE: last call = for 3280bis - escape clause

 

Santosh,

 

There are 2 distinct reasons why = your approach is not a generic solution to the = problem.

 

1)       = The problem is generic and does not only apply to policy processing. The pki4ipsec issue was e.g. motivated from problems with = EKU settings in existing certificates that does not satisfy new applications = and usages.

2)       = If you need to test for a policy in the end certificate, = that policy will not be valid unless supported by the path, regardless if = policy constraints was set or not.

 

In the perfect world, compliant = path processing will always do the job. In the real world, you may need to = tweak the rules to make a new application fit into an existing = infrastructure-

 

The question is still: Can a = standards compliant implementation allow configuration of non conformant = modifications to the validation process, or does that make the implementation as a whole non-conformant.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Santosh Chokhani
Sent: den 22 juni 2006 = 22:59
To: ietf-pkix@imc.org
Subject: RE: last call = for 3280bis - escape clause

 

Stefan,

=

 

I agree with sentiments voiced by = Steve, Rich, and Sharon.

 

I have a simple solution to your = concern from the relying party viewpoint.  This observation is made with a long-held view of mine (and no one had provided a convincing logical or = business argument) that the require explicit policy setting is a useless field. =  A relying party can always set acceptable policies to none.  In that scenario, (require explicit policy) flag not withstanding, path = validation will succeed.  Now, the user can examine the end certificate = policy.

 

You and I have had this discussion = in another context.  The basic premise is that if some field in the = last certificate only is of interest and the “state” in the path validation process does not impact it, that need not be path of path = validation engine.

 

Thus, you can judiciously use the = 3280 Engine and obtain the result you seek.

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Guida, Richard = [JJCUS]
Sent: Thursday, June 22, = 2006 2:48 PM
To: Sharon Boeyen; = 'Stefan Santesson'; ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

 

Stefan - perhaps I am missing = something, but there is nothing that stops a relying party from writing software = that would perform processing extensions only on CA certs as you = propose.  As Sharon properly = notes, that would not be RFC3280 compliant - but a relying party can choose to = be non-compliant if it wishes.  And such non-compliance only puts the = relying party at risk, not others - so that is a "good thing" = relatively speaking.  But in the final analysis, seems to me that Sharon is absolutely correct = (assuming she and I are interpreting your proposal properly) - unless X.509 is redefined, this would remain a circumstance of non-compliance.  And = so it should be treated as such.  Very best regards -- = Rich

 

 

 

Richard A. Guida
Director, Information Security =

Johnson & = Johnson
Room GS8217
410 George Street
New Brunswick, = New Jersey  08901
Phone:  732 524 3785

-----Original = Message-----
From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon Boeyen
Sent: Thursday, June 22, = 2006 1:57 PM
To: 'Stefan Santesson'; ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

Stefan, if I understand your = comment correctly I strongly believe such an escape clause cannot possibly be = added because this would render 3280bis non-compliant with X.509. =

 

My understanding of your comment is = that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found = in EE certificates. Is that a correct understanding? =

 

If it is a correct understanding, = then any such implementation is non-conformant to X.509. 3280 is a profile of = X.509 and as such can mandate certain optional elements or exclude optional = elements but cannot reverse the mandatory processing from = X.509.

 

Apologies if I've misunderstood = your question.

 

Cheers,

=

Sharon

-----Original = Message-----
From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson
Sent: Wednesday, June 21, = 2006 5:23 PM
To: ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

As a last call comment on RFC = 3280bis I would like to raise the question whether RFC 3280bis should include an = escape clause clearly allowing relying parties to select what validation logic = they deploy on certificate validation.

 

The background is the fact that = many deployed PKIs are misconfigured.2

One such common misconfiguration is assignment of certificate policies and their inclusion in CA = certificates.

X.509 path processing requires = policies in CA certificates to reflect the list of EE certificate policies that are = valid for a path. Yet many deployments have included pure CA certificate = policies in CA certificates, policies that are not included in any EE certificates = and as such, policy processing is not possible in such = PKIs.

 

Application wanting to use = certificate policies in such PKI are simply forced to either fail or selectively = neglect certain path processing rules. For a relying party such modification = could be reasonable if the security implications has been well though = through.

However it is not clear if an implementation allowing such local configuration could be regarded as = standard compliant.

 

There are more examples where = deploying applications in misconfigured PKIs would need similar measures to = work.

 

The pki4ipsec WG recently came to = this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX = WG.

 

The result was that the pki4ipsec = profile included an escape clause as follows:

 

4.1.  X.509 =
Certificates
 
   Users deploying IKE and IPsec =
with certificates have often had =
little
   control over the capabilities of =
CAs available to them.
   Implementations of this =
specification may include configuration =
knobs
   to disable checks required by =
this specification in orde!
 r =
t
 o =
permit
   use with inflexible and/or =
noncompliant CAs.  However, all checks =
on
   certificates exist for a =
specific reason involving the security =
of
   the entire system.  =
Therefore, all checks MUST be enabled by =
default.
   Administrators and users ought =
to understand the security purpose =
for
   the various checks, and be clear =
on what security will be lost =
by
   disabling the =
check.

 

 

I'm basically asking if RFC 3280bis = path validation needs a similar escape clause or corresponding clarification = that clearly allows local configuration of the validation = logic.

At least I think it is necessary to clearly allow such configuration of standards compliant applications as = long as this is not the default functionality.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Stephen Kent
Sent: den 16 juni 2006 = 22:42
To: ietf-pkix@imc.org
Subject: last call for = 3280bis

 

Folks,

 

Based on the latest message from David Cooper, I am initiating = last call on "Internet X.509 Public Key Infrastructure, Certificate and = Certificate Revocation List (CRL) Profile" = (http://ietf.org/internet-drafts/draft-ietf-pki= x-rfc3280bis-03.txt)

 

The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many = folks), all comments must be received by July 5th.

 

Steve

------_=_NextPart_001_01C6965F.1CC1663D-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5N0dKtR005820; Thu, 22 Jun 2006 17:39:20 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5N0dKwu005818; Thu, 22 Jun 2006 17:39:20 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5N0dIFd005796 for ; Thu, 22 Jun 2006 17:39:18 -0700 (MST) (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); Fri, 23 Jun 2006 01:39:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6965D.732C5B0F" Subject: RE: last call for 3280bis - escape clause Date: Fri, 23 Jun 2006 01:39:12 +0100 Message-ID: In-Reply-To: <82D5657AE1F54347A734BDD33637C8790359D724@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: last call for 3280bis - escape clause thread-index: AcaWNVMoloaBo6PDT0CPPD74liD0jQAB/dsAAAeBmuA= From: "Stefan Santesson" To: "Santosh Chokhani" , X-OriginalArrivalTime: 23 Jun 2006 00:39:14.0040 (UTC) FILETIME=[737DFF80:01C6965D] 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_01C6965D.732C5B0F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Santosh, =20 There are 2 distinct reasons why your approach is not a generic solution to the problem. =20 1) The problem is generic and does not only apply to policy processing. The pki4ipsec issue was e.g. motivated from problems with EKU settings in existing certificates that does not satisfy new applications and usages. 2) If you need to test for a policy in the end certificate, that policy will not be valid unless supported by the path, regardless if policy constraints was set or not. =20 In the perfect world, compliant path processing will always do the job. In the real world, you may need to tweak the rules to make a new application fit into an existing infrastructure- =20 The question is still: Can a standards compliant implementation allow configuration of non conformant modifications to the validation process, or does that make the implementation as a whole non-conformant. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: den 22 juni 2006 22:59 To: ietf-pkix@imc.org Subject: RE: last call for 3280bis - escape clause =20 Stefan, =20 I agree with sentiments voiced by Steve, Rich, and Sharon. =20 I have a simple solution to your concern from the relying party viewpoint. This observation is made with a long-held view of mine (and no one had provided a convincing logical or business argument) that the require explicit policy setting is a useless field. A relying party can always set acceptable policies to none. In that scenario, (require explicit policy) flag not withstanding, path validation will succeed. Now, the user can examine the end certificate policy. =20 You and I have had this discussion in another context. The basic premise is that if some field in the last certificate only is of interest and the "state" in the path validation process does not impact it, that need not be path of path validation engine. =20 Thus, you can judiciously use the 3280 Engine and obtain the result you seek. ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Guida, Richard [JJCUS] Sent: Thursday, June 22, 2006 2:48 PM To: Sharon Boeyen; 'Stefan Santesson'; ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause =20 Stefan - perhaps I am missing something, but there is nothing that stops a relying party from writing software that would perform processing extensions only on CA certs as you propose. As Sharon properly notes, that would not be RFC3280 compliant - but a relying party can choose to be non-compliant if it wishes. And such non-compliance only puts the relying party at risk, not others - so that is a "good thing" relatively speaking. But in the final analysis, seems to me that Sharon is absolutely correct (assuming she and I are interpreting your proposal properly) - unless X.509 is redefined, this would remain a circumstance of non-compliance. And so it should be treated as such. Very best regards -- Rich =20 =20 =20 Richard A. Guida=20 Director, Information Security=20 Johnson & Johnson=20 Room GS8217=20 410 George Street=20 New Brunswick, New Jersey 08901=20 Phone: 732 524 3785=20 -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon Boeyen Sent: Thursday, June 22, 2006 1:57 PM To: 'Stefan Santesson'; ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause Stefan, if I understand your comment correctly I strongly believe such an escape clause cannot possibly be added because this would render 3280bis non-compliant with X.509.=20 =20 My understanding of your comment is that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found in EE certificates. Is that a correct understanding?=20 =20 If it is a correct understanding, then any such implementation is non-conformant to X.509. 3280 is a profile of X.509 and as such can mandate certain optional elements or exclude optional elements but cannot reverse the mandatory processing from X.509. =20 Apologies if I've misunderstood your question. =20 Cheers, Sharon -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Wednesday, June 21, 2006 5:23 PM To: ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause As a last call comment on RFC 3280bis I would like to raise the question whether RFC 3280bis should include an escape clause clearly allowing relying parties to select what validation logic they deploy on certificate validation. =20 The background is the fact that many deployed PKIs are misconfigured.2 One such common misconfiguration is assignment of certificate policies and their inclusion in CA certificates. X.509 path processing requires policies in CA certificates to reflect the list of EE certificate policies that are valid for a path. Yet many deployments have included pure CA certificate policies in CA certificates, policies that are not included in any EE certificates and as such, policy processing is not possible in such PKIs. =20 Application wanting to use certificate policies in such PKI are simply forced to either fail or selectively neglect certain path processing rules. For a relying party such modification could be reasonable if the security implications has been well though through. However it is not clear if an implementation allowing such local configuration could be regarded as standard compliant. =20 There are more examples where deploying applications in misconfigured PKIs would need similar measures to work. =20 The pki4ipsec WG recently came to this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX WG. =20 The result was that the pki4ipsec profile included an escape clause as follows: =20 4.1. X.509 Certificates =20 Users deploying IKE and IPsec with certificates have often had little control over the capabilities of CAs available to them. Implementations of this specification may include configuration knobs to disable checks required by this specification in orde! r t o permit use with inflexible and/or noncompliant CAs. However, all checks on certificates exist for a specific reason involving the security of the entire system. Therefore, all checks MUST be enabled by default. Administrators and users ought to understand the security purpose for the various checks, and be clear on what security will be lost by disabling the check. =20 =20 I'm basically asking if RFC 3280bis path validation needs a similar escape clause or corresponding clarification that clearly allows local configuration of the validation logic. At least I think it is necessary to clearly allow such configuration of standards compliant applications as long as this is not the default functionality. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =09 ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: den 16 juni 2006 22:42 To: ietf-pkix@imc.org Subject: last call for 3280bis =20 Folks, =20 Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt ) =20 The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th. =20 Steve ------_=_NextPart_001_01C6965D.732C5B0F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Santosh,

 

There are 2 distinct reasons why = your approach is not a generic solution to the = problem.

 

1)       = The problem is generic and does not only apply to policy processing. The pki4ipsec issue was e.g. motivated from problems with = EKU settings in existing certificates that does not satisfy new applications = and usages.

2)       = If you need to test for a policy in the end certificate, = that policy will not be valid unless supported by the path, regardless if = policy constraints was set or not.

 

In the perfect world, compliant = path processing will always do the job. In the real world, you may need to = tweak the rules to make a new application fit into an existing = infrastructure-

 

The question is still: Can a = standards compliant implementation allow configuration of non conformant = modifications to the validation process, or does that make the implementation as a whole = non-conformant.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Santosh Chokhani
Sent: den 22 juni 2006 = 22:59
To: ietf-pkix@imc.org
Subject: RE: last call = for 3280bis - escape clause

 

Stefan,

=

 

I agree with sentiments voiced by = Steve, Rich, and Sharon.

 

I have a simple solution to your = concern from the relying party viewpoint.  This observation is made with a = long-held view of mine (and no one had provided a convincing logical or business argument) that the require explicit policy setting is a useless field. =  A relying party can always set acceptable policies to none.  In that scenario, (require explicit policy) flag not withstanding, path = validation will succeed.  Now, the user can examine the end certificate = policy.

 

You and I have had this discussion = in another context.  The basic premise is that if some field in the = last certificate only is of interest and the “state” in the path validation process does not impact it, that need not be path of path = validation engine.

 

Thus, you can judiciously use the = 3280 Engine and obtain the result you seek.

From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Guida, Richard [JJCUS]
Sent: Thursday, June 22, = 2006 2:48 PM
To: Sharon Boeyen; = 'Stefan Santesson'; ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

 

Stefan - perhaps I am missing = something, but there is nothing that stops a relying party from writing software = that would perform processing extensions only on CA certs as you = propose.  As Sharon properly notes, that would not be RFC3280 compliant - but a relying = party can choose to be non-compliant if it wishes.  And such non-compliance = only puts the relying party at risk, not others - so that is a = "good thing" relatively speaking.  But in the final analysis, seems = to me that Sharon is absolutely correct (assuming she and I are interpreting your proposal properly) - unless X.509 is redefined, this would remain a = circumstance of non-compliance.  And so it should be treated as such.  = Very best regards -- Rich

 

 

 

Richard A. Guida
Director, Information Security =

Johnson & = Johnson
Room GS8217
410 George Street
New Brunswick, = New Jersey  08901
Phone:  732 524 3785

-----Original = Message-----
From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon Boeyen
Sent: Thursday, June 22, = 2006 1:57 PM
To: 'Stefan Santesson'; ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

Stefan, if I understand your = comment correctly I strongly believe such an escape clause cannot possibly be = added because this would render 3280bis non-compliant with X.509. =

 

My understanding of your comment is = that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found = in EE certificates. Is that a correct understanding? =

 

If it is a correct understanding, = then any such implementation is non-conformant to X.509. 3280 is a profile of = X.509 and as such can mandate certain optional elements or exclude optional = elements but cannot reverse the mandatory processing from = X.509.

 

Apologies if I've misunderstood = your question.

 

Cheers,

=

Sharon

-----Original = Message-----
From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson
Sent: Wednesday, June 21, = 2006 5:23 PM
To: ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

As a last call comment on RFC = 3280bis I would like to raise the question whether RFC 3280bis should include an = escape clause clearly allowing relying parties to select what validation logic they = deploy on certificate validation.

 

The background is the fact that = many deployed PKIs are misconfigured.2

One such common misconfiguration is = assignment of certificate policies and their inclusion in CA = certificates.

X.509 path processing requires = policies in CA certificates to reflect the list of EE certificate policies that are = valid for a path. Yet many deployments have included pure CA certificate = policies in CA certificates, policies that are not included in any EE certificates = and as such, policy processing is not possible in such = PKIs.

 

Application wanting to use = certificate policies in such PKI are simply forced to either fail or selectively = neglect certain path processing rules. For a relying party such modification = could be reasonable if the security implications has been well though = through.

However it is not clear if an implementation allowing such local configuration could be regarded as = standard compliant.

 

There are more examples where = deploying applications in misconfigured PKIs would need similar measures to = work.

 

The pki4ipsec WG recently came to = this conclusion in their PKI profile and this lead to an intense debate which = included core participants from the PKIX WG.

 

The result was that the pki4ipsec = profile included an escape clause as follows:

 

4.1.  X.509 =
Certificates
 
   Users deploying IKE and IPsec =
with certificates have often had =
little
   control over the capabilities of =
CAs available to them.
   Implementations of this =
specification may include configuration =
knobs
   to disable checks required by =
this specification in orde!
 r =
t
 o =
permit
   use with inflexible and/or =
noncompliant CAs.  However, all checks =
on
   certificates exist for a =
specific reason involving the security =
of
   the entire system.  =
Therefore, all checks MUST be enabled by =
default.
   Administrators and users ought =
to understand the security purpose =
for
   the various checks, and be clear =
on what security will be lost =
by
   disabling the =
check.

 

 

I'm basically asking if RFC 3280bis = path validation needs a similar escape clause or corresponding clarification = that clearly allows local configuration of the validation = logic.

At least I think it is necessary to clearly allow such configuration of standards compliant applications as = long as this is not the default functionality.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Stephen Kent
Sent: den 16 juni 2006 = 22:42
To: ietf-pkix@imc.org
Subject: last call for = 3280bis

 

Folks,

 

Based on the latest message from David Cooper, I am initiating = last call on "Internet X.509 Public Key Infrastructure, Certificate and = Certificate Revocation List (CRL) Profile" = (http://ietf.org/internet-drafts/draft-ietf-pki= x-rfc3280bis-03.txt)

 

The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many = folks), all comments must be received by July 5th.

 

Steve

------_=_NextPart_001_01C6965D.732C5B0F-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MNgqXo091713; Thu, 22 Jun 2006 16:42:52 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MNgqwJ091712; Thu, 22 Jun 2006 16:42:52 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MNgps6091705 for ; Thu, 22 Jun 2006 16:42:52 -0700 (MST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (24-205-218-53.dhcp.crcy.nv.charter.com [24.205.218.53] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id k5MNgobs029939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Jun 2006 23:42:50 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <7.0.1.0.0.20060622153640.040ef5d8@OpenLDAP.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 22 Jun 2006 16:43:12 -0700 To: Tim Polk From: "Kurt D. Zeilenga" Subject: Re: stringprep in 3280bis Cc: ietf-pkix@imc.org In-Reply-To: <5.1.0.14.2.20060622102208.02f3ffb0@email.nist.gov> References: <5.1.0.14.2.20060622102208.02f3ffb0@email.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tim, As far as nameprep goes, yes, AllowUnassigned is all about "stored" v. "query" strings. So, as you note, domain label preparation is mostly okay. (see below comments). However, I do note that 7.1 says nothing about "stored" v. "query" strings. In this case, as one implementation is preparing both strings in the comparison, treating both as "stored" should be fine. -- Kurt At 02:52 PM 6/22/2006, Tim Polk wrote: >>To accommodate >> internationalized domain names in the current structure, conforming >> implementations MUST convert internationalized domain names to the >> ASCII Compatible Encoding (ACE) format as specified in section 4 of >> RFC 3490 before storage in the dNSName field. Specifically, >> conforming implementations MUST perform the conversion operation >> specified in section 4 of RFC 3490 as follows: >> >> * in step 1, the domain name SHALL be considered a "stored >> string"; > (additional steps deleted) You might want to add: , hence the AllowUnassigned SHALL NOT be set. since nameprep uses this flag to indicate the string has "stored" handling. Likewise in subsequent bullet set in this section. >In section 7.3, we did not specify "stored" versus "query", because it does not seem to apply. In this section 7.3, the domain component attribute contains only a single label, so we only perform the "ToASCII" operation. It does (via AllowUnassigned). >>To represent a label from an IDN in the distinguished >> name, the implementation MUST perform the "ToASCII" label conversion >> specified in section 4.1 of RFC 3490. > >As I said, the "ToASCII" operation doesn't seem to care about "stored" versus "query" so we didn't specify it. However, the "ToASCII" operation does require specification of two additional inputs: the AllowUnassigned flag, and the UseSTD3ASCIIRules flag. We dropped the ball here. We should have specified that the UseSTD3ASCIIRules flag should be set, and that AllowUassigned flag is *not* set. (That works out to be the same as "stored" anyway, doesn't it?) Yes. >(1) How about the following revision to that sentence in 7.3: > >To represent a label from an IDN in the distinguished name, the implementation MUST perform the "ToASCII" label conversion specified in section 4.1 of RFC 3490, where the STD3ASCIIRules flag is set but AllowUnassigned flag is not set. >(2) If I misinterpreted the specification of "ToASCII", and we do need to specify "stored" vs. "query", we could use this alternate text: > >To represent a label from an IDN in the distinguished name, the implementation MUST perform the "ToASCII" label conversion specified in section 4.1 of RFC 3490, where the string preparation is performed as a "stored" string. I prefer language that explicitly says that the string is to be regarded as "stored" and (hence) the AllowUnassigned flag is not set (see my comment regarding 7.2 text). -- Kurt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MMoDqL078475; Thu, 22 Jun 2006 15:50:13 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MMoDPb078474; Thu, 22 Jun 2006 15:50:13 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MMoCcK078444 for ; Thu, 22 Jun 2006 15:50:13 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5MMo2Hp029345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Jun 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FtXzu-0007u6-Dt; Thu, 22 Jun 2006 18:50:02 -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-srvsan-02.txt Message-Id: Date: Thu, 22 Jun 2006 18:50:02 -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 : Internet X.509 Public Key Infrastructure Subject Alternative Name for expression of service name Author(s) : S. Santesson Filename : draft-ietf-pkix-srvsan-02.txt Pages : 11 Date : 2006-6-22 This document defines a new name form for inclusion in the otherName filed of an X.509 Subject Alternative Name extension which allows a certificate subject to be associated with the service name and domain name components of a DNS Service Resource Record. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-srvsan-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-srvsan-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-srvsan-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: <2006-6-22162653.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-srvsan-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-srvsan-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-22162653.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MM4Afg067280; Thu, 22 Jun 2006 15:04:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MM4ABT067279; Thu, 22 Jun 2006 15:04:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MM48wG067236 for ; Thu, 22 Jun 2006 15:04:09 -0700 (MST) (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, 22 Jun 2006 23:04:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69647.C3E2A6F5" Subject: RE: last call for 3280bis - escape clause Date: Thu, 22 Jun 2006 23:03:58 +0100 Message-ID: In-Reply-To: <8C9266D8DEC7B3439D3A49E5706844100AFAB931@jjcusnbexs4.na.jnj.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: last call for 3280bis - escape clause thread-index: AcaWLJScwSTyVxSgTKS7ldtF72iXKAAGcqWw From: "Stefan Santesson" To: "Guida, Richard [JJCUS]" , "Sharon Boeyen" , Cc: "Stephen Kent" X-OriginalArrivalTime: 22 Jun 2006 22:04:00.0569 (UTC) FILETIME=[C43B1A90:01C69647] 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_01C69647.C3E2A6F5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think my initial statement was a bit misinterpreted. =20 I suggest no changes to RFC 3280 path processing. And of course, skipping mandatory checks would make the path processing non-conformant. =20 However. I have noticed that it is not clear to some people weather a conformant implementation are forced to always do conformant path processing, or if a conformant implementation can allow administrators to turn of certain checking. =20 What I say is mainly two things; 1) Misconfigured PKIs may sometimes force relying parties to do non conformant path processing or fail altogether. 2) A conformant implementation should be allowed to support also non-conformant processing as long as this is not the default behavior. =20 I think this is already allowed, but some implementers may not read it that way and therefore I'm asking if we should add a clarification like pki4ipsec did. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards ________________________________ From: Guida, Richard [JJCUS] [mailto:RGuida@CORUS.JNJ.com]=20 Sent: den 22 juni 2006 20:48 To: Sharon Boeyen; Stefan Santesson; ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause =20 Stefan - perhaps I am missing something, but there is nothing that stops a relying party from writing software that would perform processing extensions only on CA certs as you propose. As Sharon properly notes, that would not be RFC3280 compliant - but a relying party can choose to be non-compliant if it wishes. And such non-compliance only puts the relying party at risk, not others - so that is a "good thing" relatively speaking. But in the final analysis, seems to me that Sharon is absolutely correct (assuming she and I are interpreting your proposal properly) - unless X.509 is redefined, this would remain a circumstance of non-compliance. And so it should be treated as such. Very best regards -- Rich =20 =20 =20 Richard A. Guida=20 Director, Information Security=20 Johnson & Johnson=20 Room GS8217=20 410 George Street=20 New Brunswick, New Jersey 08901=20 Phone: 732 524 3785=20 -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon Boeyen Sent: Thursday, June 22, 2006 1:57 PM To: 'Stefan Santesson'; ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause Stefan, if I understand your comment correctly I strongly believe such an escape clause cannot possibly be added because this would render 3280bis non-compliant with X.509.=20 =20 My understanding of your comment is that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found in EE certificates. Is that a correct understanding?=20 =20 If it is a correct understanding, then any such implementation is non-conformant to X.509. 3280 is a profile of X.509 and as such can mandate certain optional elements or exclude optional elements but cannot reverse the mandatory processing from X.509. =20 Apologies if I've misunderstood your question. =20 Cheers, Sharon -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Wednesday, June 21, 2006 5:23 PM To: ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause As a last call comment on RFC 3280bis I would like to raise the question whether RFC 3280bis should include an escape clause clearly allowing relying parties to select what validation logic they deploy on certificate validation. =20 The background is the fact that many deployed PKIs are misconfigured.2 One such common misconfiguration is assignment of certificate policies and their inclusion in CA certificates. X.509 path processing requires policies in CA certificates to reflect the list of EE certificate policies that are valid for a path. Yet many deployments have included pure CA certificate policies in CA certificates, policies that are not included in any EE certificates and as such, policy processing is not possible in such PKIs. =20 Application wanting to use certificate policies in such PKI are simply forced to either fail or selectively neglect certain path processing rules. For a relying party such modification could be reasonable if the security implications has been well though through. However it is not clear if an implementation allowing such local configuration could be regarded as standard compliant. =20 There are more examples where deploying applications in misconfigured PKIs would need similar measures to work. =20 The pki4ipsec WG recently came to this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX WG. =20 The result was that the pki4ipsec profile included an escape clause as follows: =20 4.1. X.509 Certificates =20 Users deploying IKE and IPsec with certificates have often had little control over the capabilities of CAs available to them. Implementations of this specification may include configuration knobs to disable checks required by this specification in orde! r t o permit use with inflexible and/or noncompliant CAs. However, all checks on certificates exist for a specific reason involving the security of the entire system. Therefore, all checks MUST be enabled by default. Administrators and users ought to understand the security purpose for the various checks, and be clear on what security will be lost by disabling the check. =20 =20 I'm basically asking if RFC 3280bis path validation needs a similar escape clause or corresponding clarification that clearly allows local configuration of the validation logic. At least I think it is necessary to clearly allow such configuration of standards compliant applications as long as this is not the default functionality. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =09 ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: den 16 juni 2006 22:42 To: ietf-pkix@imc.org Subject: last call for 3280bis =20 Folks, =20 Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt ) =20 The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th. =20 Steve ------_=_NextPart_001_01C69647.C3E2A6F5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

I think my initial statement was a = bit misinterpreted.

 

I suggest no changes to RFC 3280 = path processing. And of course, skipping mandatory checks would make the path processing non-conformant.

 

However. I have noticed that it is = not clear to some people weather a conformant implementation are forced to = always do conformant path processing, or if a conformant implementation can allow administrators to turn of certain checking.

 

What I say is mainly two = things;

1)       = Misconfigured PKIs may sometimes force relying parties to do = non conformant path processing or fail = altogether.

2)       = A conformant implementation should be allowed to support = also non-conformant processing as long as this is not the default = behavior.

 

I think this is already allowed, = but some implementers may not read it that way and therefore I’m asking if = we should add a clarification like pki4ipsec = did.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: = Guida, Richard [JJCUS] [mailto:RGuida@CORUS.JNJ.com]
Sent: den 22 juni 2006 = 20:48
To: Sharon Boeyen; Stefan Santesson; ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

 

Stefan - perhaps I am missing = something, but there is nothing that stops a relying party from writing software = that would perform processing extensions only on CA certs as you = propose.  As Sharon properly notes, that would not be RFC3280 compliant - but a relying = party can choose to be non-compliant if it wishes.  And such non-compliance = only puts the relying party at risk, not others - so that is a = "good thing" relatively speaking.  But in the final analysis, seems = to me that Sharon is absolutely correct (assuming she and I are interpreting your proposal properly) - unless X.509 is redefined, this would remain a = circumstance of non-compliance.  And so it should be treated as such.  = Very best regards -- Rich

 

 

 

Richard A. Guida
Director, Information Security =

Johnson & = Johnson
Room GS8217
410 George Street
New Brunswick, = New Jersey  08901
Phone:  732 524 3785

-----Original = Message-----
From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon Boeyen
Sent: Thursday, June 22, = 2006 1:57 PM
To: 'Stefan Santesson'; ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

Stefan, if I understand your = comment correctly I strongly believe such an escape clause cannot possibly be added = because this would render 3280bis non-compliant with X.509. =

 

My understanding of your comment is = that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found = in EE certificates. Is that a correct understanding? =

 

If it is a correct understanding, = then any such implementation is non-conformant to X.509. 3280 is a profile of = X.509 and as such can mandate certain optional elements or exclude optional = elements but cannot reverse the mandatory processing from = X.509.

 

Apologies if I've misunderstood = your question.

 

Cheers,

=

Sharon

-----Original = Message-----
From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson
Sent: Wednesday, June 21, = 2006 5:23 PM
To: ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

As a last call comment on RFC = 3280bis I would like to raise the question whether RFC 3280bis should include an = escape clause clearly allowing relying parties to select what validation logic = they deploy on certificate validation.

 

The background is the fact that = many deployed PKIs are misconfigured.2

One such common misconfiguration is assignment of certificate policies and their inclusion in CA = certificates.

X.509 path processing requires = policies in CA certificates to reflect the list of EE certificate policies that are = valid for a path. Yet many deployments have included pure CA certificate = policies in CA certificates, policies that are not included in any EE certificates = and as such, policy processing is not possible in such = PKIs.

 

Application wanting to use = certificate policies in such PKI are simply forced to either fail or selectively = neglect certain path processing rules. For a relying party such modification = could be reasonable if the security implications has been well though = through.

However it is not clear if an = implementation allowing such local configuration could be regarded as standard = compliant.

 

There are more examples where = deploying applications in misconfigured PKIs would need similar measures to = work.

 

The pki4ipsec WG recently came to = this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX = WG.

 

The result was that the pki4ipsec = profile included an escape clause as follows:

 

4.1.  X.509 =
Certificates
 
   Users deploying IKE and IPsec =
with certificates have often had =
little
   control over the capabilities of =
CAs available to them.
   Implementations of this =
specification may include configuration =
knobs
   to disable checks required by =
this specification in orde!
 r =
t
 o =
permit
   use with inflexible and/or =
noncompliant CAs.  However, all checks =
on
   certificates exist for a =
specific reason involving the security =
of
   the entire system.  =
Therefore, all checks MUST be enabled by =
default.
   Administrators and users ought =
to understand the security purpose =
for
   the various checks, and be clear =
on what security will be lost =
by
   disabling the =
check.

 

 

I'm basically asking if RFC 3280bis = path validation needs a similar escape clause or corresponding clarification = that clearly allows local configuration of the validation = logic.

At least I think it is necessary to clearly allow such configuration of standards compliant applications as = long as this is not the default functionality.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Stephen Kent
Sent: den 16 juni 2006 = 22:42
To: ietf-pkix@imc.org
Subject: last call for = 3280bis

 

Folks,

 

Based on the latest message from David Cooper, I am initiating = last call on "Internet X.509 Public Key Infrastructure, Certificate and = Certificate Revocation List (CRL) Profile" = (http://ietf.org/internet-drafts/draft-ietf-pki= x-rfc3280bis-03.txt)

 

The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many = folks), all comments must be received by July 5th.

 

Steve

------_=_NextPart_001_01C69647.C3E2A6F5-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MLq9fZ064809; Thu, 22 Jun 2006 14:52:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MLq9C7064808; Thu, 22 Jun 2006 14:52:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MLq8rC064801 for ; Thu, 22 Jun 2006 14:52:08 -0700 (MST) (envelope-from tim.polk@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k5MLpv3O017927; Thu, 22 Jun 2006 17:51:57 -0400 Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.13.6/8.13.6) with ESMTP id k5MLpHrc004380; Thu, 22 Jun 2006 17:51:18 -0400 (EDT) Message-Id: <5.1.0.14.2.20060622102208.02f3ffb0@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 22 Jun 2006 17:52:56 -0400 To: "Kurt D. Zeilenga" , ietf-pkix@imc.org From: Tim Polk Subject: Re: stringprep in 3280bis In-Reply-To: <7.0.1.0.0.20060621232234.0422a5d8@OpenLDAP.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: Kurt, To be fair, the I-D does address stored strings in a couple of places, although we may have missed a reference. Please review the quotes below, along with a couple of alternatives for one update, to see if we have it right... Section 7.2 of this I-D includes the following text: >To accommodate > internationalized domain names in the current structure, conforming > implementations MUST convert internationalized domain names to the > ASCII Compatible Encoding (ACE) format as specified in section 4 of > RFC 3490 before storage in the dNSName field. Specifically, > conforming implementations MUST perform the conversion operation > specified in section 4 of RFC 3490 as follows: > > * in step 1, the domain name SHALL be considered a "stored > string"; (additional steps deleted) Sections 7.5 includes a reference to the text in 7.2. From 7.5: > Where the host-part (the domain of the addr-spec) contains an > internationalized name, the domain name MUST be converted from an IDN > to the ASCII Compatible Encoding (ACE) format as specified in section > 7.2. > > Two email addresses are considered to match if: > > 1) the local-part of each name is an exact match, AND > 2) the host-part of each name matches using a case-insensitive > ASCII comparison. I am probably missing some nuance, but this would seem to be sufficient for sections 7.2 and 7.5. In section 7.3, we did not specify "stored" versus "query", because it does not seem to apply. In this section 7.3, the domain component attribute contains only a single label, so we only perform the "ToASCII" operation. >To represent a label from an IDN in the distinguished > name, the implementation MUST perform the "ToASCII" label conversion > specified in section 4.1 of RFC 3490. As I said, the "ToASCII" operation doesn't seem to care about "stored" versus "query" so we didn't specify it. However, the "ToASCII" operation does require specification of two additional inputs: the AllowUnassigned flag, and the UseSTD3ASCIIRules flag. We dropped the ball here. We should have specified that the UseSTD3ASCIIRules flag should be set, and that AllowUassigned flag is *not* set. (That works out to be the same as "stored" anyway, doesn't it?) (1) How about the following revision to that sentence in 7.3: To represent a label from an IDN in the distinguished name, the implementation MUST perform the "ToASCII" label conversion specified in section 4.1 of RFC 3490, where the STD3ASCIIRules flag is set but AllowUnassigned flag is not set. (2) If I misinterpreted the specification of "ToASCII", and we do need to specify "stored" vs. "query", we could use this alternate text: To represent a label from an IDN in the distinguished name, the implementation MUST perform the "ToASCII" label conversion specified in section 4.1 of RFC 3490, where the string preparation is performed as a "stored" string. Am I correct that 7.2 and 7.5 are okay? What do you think of the alternatives for 7.3? Thanks, Tim At 11:39 PM 6/21/2006 -0700, Kurt D. Zeilenga wrote: >For various values, this I-D discusses how strings are to be >prepared using various profiles of the StringPrep algorithm. >However, the I-D fails to discuss whether the strings should >be prepared as "stored" or "query" strings (see Section 4 >of RFC 3490). The I-D should be revised so as to be clear >which strings are to be treated as "stored" strings and which >are to be treated as "query" strings. > >Off the cuff, I suspect the right thing to do is: > 1) requiring each prepared string in a certificate/CRL be > treated as "stored", and > 2) prepared strings to be compared against prepared strings > in a certificate/CRL to be treated as either "query" or "stored". >This assures that each comparison between prepared strings >involves at least one "stored" string. > >-- Kurt > >At 01:42 PM 6/16/2006, Stephen Kent wrote: > >Folks, > > > >Based on the latest message from David Cooper, I am initiating last call > on "Internet X.509 Public Key Infrastructure, Certificate and Certificate > Revocation List (CRL) Profile" > (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt) > > > >The last call will last for two weeks. In deference to the U.S. > Independence Dya holiday (which means July 3rd is a holiday for many > folks), all comments must be received by July 5th. > > > >Steve Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MKwe5t051373; Thu, 22 Jun 2006 13:58:40 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MKwegx051372; Thu, 22 Jun 2006 13:58:40 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MKwdiS051342 for ; Thu, 22 Jun 2006 13:58:39 -0700 (MST) (envelope-from chokhani@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6963F.1D4C93BD" Subject: RE: last call for 3280bis - escape clause Date: Thu, 22 Jun 2006 13:58:32 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C8790359D724@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: last call for 3280bis - escape clause Thread-Index: AcaWNVMoloaBo6PDT0CPPD74liD0jQAB/dsA From: "Santosh Chokhani" To: 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_01C6963F.1D4C93BD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stefan, =20 I agree with sentiments voiced by Steve, Rich, and Sharon. =20 I have a simple solution to your concern from the relying party viewpoint. This observation is made with a long-held view of mine (and no one had provided a convincing logical or business argument) that the require explicit policy setting is a useless field. A relying party can always set acceptable policies to none. In that scenario, (require explicit policy) flag not withstanding, path validation will succeed. Now, the user can examine the end certificate policy. =20 You and I have had this discussion in another context. The basic premise is that if some field in the last certificate only is of interest and the "state" in the path validation process does not impact it, that need not be path of path validation engine. =20 Thus, you can judiciously use the 3280 Engine and obtain the result you seek. ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Guida, Richard [JJCUS] Sent: Thursday, June 22, 2006 2:48 PM To: Sharon Boeyen; 'Stefan Santesson'; ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause =20 Stefan - perhaps I am missing something, but there is nothing that stops a relying party from writing software that would perform processing extensions only on CA certs as you propose. As Sharon properly notes, that would not be RFC3280 compliant - but a relying party can choose to be non-compliant if it wishes. And such non-compliance only puts the relying party at risk, not others - so that is a "good thing" relatively speaking. But in the final analysis, seems to me that Sharon is absolutely correct (assuming she and I are interpreting your proposal properly) - unless X.509 is redefined, this would remain a circumstance of non-compliance. And so it should be treated as such. Very best regards -- Rich =20 =20 =20 Richard A. Guida=20 Director, Information Security=20 Johnson & Johnson=20 Room GS8217=20 410 George Street=20 New Brunswick, New Jersey 08901=20 Phone: 732 524 3785=20 -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon Boeyen Sent: Thursday, June 22, 2006 1:57 PM To: 'Stefan Santesson'; ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause Stefan, if I understand your comment correctly I strongly believe such an escape clause cannot possibly be added because this would render 3280bis non-compliant with X.509.=20 =20 My understanding of your comment is that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found in EE certificates. Is that a correct understanding?=20 =20 If it is a correct understanding, then any such implementation is non-conformant to X.509. 3280 is a profile of X.509 and as such can mandate certain optional elements or exclude optional elements but cannot reverse the mandatory processing from X.509. =20 Apologies if I've misunderstood your question. =20 Cheers, Sharon -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Wednesday, June 21, 2006 5:23 PM To: ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause As a last call comment on RFC 3280bis I would like to raise the question whether RFC 3280bis should include an escape clause clearly allowing relying parties to select what validation logic they deploy on certificate validation. =20 The background is the fact that many deployed PKIs are misconfigured.2 One such common misconfiguration is assignment of certificate policies and their inclusion in CA certificates. X.509 path processing requires policies in CA certificates to reflect the list of EE certificate policies that are valid for a path. Yet many deployments have included pure CA certificate policies in CA certificates, policies that are not included in any EE certificates and as such, policy processing is not possible in such PKIs. =20 Application wanting to use certificate policies in such PKI are simply forced to either fail or selectively neglect certain path processing rules. For a relying party such modification could be reasonable if the security implications has been well though through. However it is not clear if an implementation allowing such local configuration could be regarded as standard compliant. =20 There are more examples where deploying applications in misconfigured PKIs would need similar measures to work. =20 The pki4ipsec WG recently came to this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX WG. =20 The result was that the pki4ipsec profile included an escape clause as follows: =20 4.1. X.509 Certificates =20 Users deploying IKE and IPsec with certificates have often had little control over the capabilities of CAs available to them. Implementations of this specification may include configuration knobs to disable checks required by this specification in orde! r t o permit use with inflexible and/or noncompliant CAs. However, all checks on certificates exist for a specific reason involving the security of the entire system. Therefore, all checks MUST be enabled by default. Administrators and users ought to understand the security purpose for the various checks, and be clear on what security will be lost by disabling the check. =20 =20 I'm basically asking if RFC 3280bis path validation needs a similar escape clause or corresponding clarification that clearly allows local configuration of the validation logic. At least I think it is necessary to clearly allow such configuration of standards compliant applications as long as this is not the default functionality. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =09 ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: den 16 juni 2006 22:42 To: ietf-pkix@imc.org Subject: last call for 3280bis =20 Folks, =20 Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt ) =20 The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th. =20 Steve ------_=_NextPart_001_01C6963F.1D4C93BD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Stefan,

=

 

I agree with sentiments voiced by = Steve, Rich, and Sharon.

 

I have a simple solution to your = concern from the relying party viewpoint.  This observation is made with a long-held view of mine (and no one had provided a convincing logical or business argument) that the require explicit policy setting is a useless = field.  A relying party can always set acceptable policies to none. =  In that scenario, (require explicit policy) flag not withstanding, path = validation will succeed.  Now, the user can examine the end certificate = policy.

 

You and I have had this discussion = in another context.  The basic premise is that if some field in the = last certificate only is of interest and the “state” in the path validation process does not impact it, that need not be path of path = validation engine.

 

Thus, you can judiciously use the = 3280 Engine and obtain the result you seek.

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Guida, Richard = [JJCUS]
Sent: Thursday, June 22, = 2006 2:48 PM
To: Sharon Boeyen; = 'Stefan Santesson'; ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

 

Stefan - perhaps I am missing = something, but there is nothing that stops a relying party from writing software = that would perform processing extensions only on CA certs as you = propose.  As Sharon properly notes, that would not be RFC3280 compliant - but a relying = party can choose to be non-compliant if it wishes.  And such non-compliance = only puts the relying party at risk, not others - so that is a = "good thing" relatively speaking.  But in the final analysis, seems = to me that Sharon is absolutely correct (assuming she and I are interpreting your proposal properly) - unless X.509 is redefined, this would remain a = circumstance of non-compliance.  And so it should be treated as such.  = Very best regards -- Rich

 

 

 

Richard A. Guida
Director, Information Security =

Johnson & = Johnson
Room GS8217
410 George Street
New Brunswick, = New Jersey  08901
Phone:  732 524 3785

-----Original = Message-----
From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon Boeyen
Sent: Thursday, June 22, = 2006 1:57 PM
To: 'Stefan Santesson'; ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

Stefan, if I understand your = comment correctly I strongly believe such an escape clause cannot possibly be added = because this would render 3280bis non-compliant with X.509. =

 

My understanding of your comment is = that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found = in EE certificates. Is that a correct understanding? =

 

If it is a correct understanding, = then any such implementation is non-conformant to X.509. 3280 is a profile of = X.509 and as such can mandate certain optional elements or exclude optional = elements but cannot reverse the mandatory processing from = X.509.

 

Apologies if I've misunderstood = your question.

 

Cheers,

=

Sharon

-----Original = Message-----
From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson
Sent: Wednesday, June 21, = 2006 5:23 PM
To: ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call = for 3280bis - escape clause

As a last call comment on RFC = 3280bis I would like to raise the question whether RFC 3280bis should include an = escape clause clearly allowing relying parties to select what validation logic = they deploy on certificate validation.

 

The background is the fact that = many deployed PKIs are misconfigured.2

One such common misconfiguration is assignment of certificate policies and their inclusion in CA = certificates.

X.509 path processing requires = policies in CA certificates to reflect the list of EE certificate policies that are = valid for a path. Yet many deployments have included pure CA certificate = policies in CA certificates, policies that are not included in any EE certificates = and as such, policy processing is not possible in such = PKIs.

 

Application wanting to use = certificate policies in such PKI are simply forced to either fail or selectively = neglect certain path processing rules. For a relying party such modification = could be reasonable if the security implications has been well though = through.

However it is not clear if an implementation allowing such local configuration could be regarded as = standard compliant.

 

There are more examples where = deploying applications in misconfigured PKIs would need similar measures to = work.

 

The pki4ipsec WG recently came to = this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX = WG.

 

The result was that the pki4ipsec = profile included an escape clause as follows:

 

4.1.  X.509 =
Certificates
 
   Users deploying IKE and IPsec =
with certificates have often had =
little
   control over the capabilities of =
CAs available to them.
   Implementations of this =
specification may include configuration =
knobs
   to disable checks required by =
this specification in orde!
 r =
t
 o =
permit
   use with inflexible and/or =
noncompliant CAs.  However, all checks =
on
   certificates exist for a =
specific reason involving the security =
of
   the entire system.  =
Therefore, all checks MUST be enabled by =
default.
   Administrators and users ought =
to understand the security purpose =
for
   the various checks, and be clear =
on what security will be lost =
by
   disabling the =
check.

 

 

I'm basically asking if RFC 3280bis = path validation needs a similar escape clause or corresponding clarification = that clearly allows local configuration of the validation = logic.

At least I think it is necessary to clearly allow such configuration of standards compliant applications as = long as this is not the default functionality.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Stephen Kent
Sent: den 16 juni 2006 = 22:42
To: ietf-pkix@imc.org
Subject: last call for = 3280bis

 

Folks,

 

Based on the latest message from David Cooper, I am initiating = last call on = "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation = List (CRL) Profile" (http://ietf.org/internet-drafts/draft-ietf-pki= x-rfc3280bis-03.txt)

 

The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many = folks), all comments must be received by July 5th.

 

Steve

------_=_NextPart_001_01C6963F.1D4C93BD-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MImdSa019852; Thu, 22 Jun 2006 11:48:39 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MImdJ6019851; Thu, 22 Jun 2006 11:48:39 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from ncsusraimge01.jnj.com (ncsusraimge01.jnj.com [148.177.2.21]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MImcx2019827 for ; Thu, 22 Jun 2006 11:48:38 -0700 (MST) (envelope-from RGuida@CORUS.JNJ.com) Received: from ncsusrawsa2.na.jnj.com ([10.4.21.2]) by ncsusraimge01.jnj.com (Switch-3.1.8/Switch-3.1.7) with SMTP id k5MIm87C010502; Thu, 22 Jun 2006 14:48:09 -0400 (EDT) Received: from (10.4.20.168) by ncsusrawsa2.na.jnj.com via smtp id 2901_8ebc393a_0221_11db_8f25_0002b3ec9bcc; Thu, 22 Jun 2006 15:01:48 -0400 Received: by NCSUSRAEXIMS1.na.jnj.com with Internet Mail Service (5.5.2658.3) id ; Thu, 22 Jun 2006 14:48:08 -0400 Message-ID: <8C9266D8DEC7B3439D3A49E5706844100AFAB931@jjcusnbexs4.na.jnj.com> From: "Guida, Richard [JJCUS]" To: Sharon Boeyen , "'Stefan Santesson'" , ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause Date: Thu, 22 Jun 2006 14:48:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.3) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6962C.6413C4C6" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C6962C.6413C4C6 Content-Type: text/plain Stefan - perhaps I am missing something, but there is nothing that stops a relying party from writing software that would perform processing extensions only on CA certs as you propose. As Sharon properly notes, that would not be RFC3280 compliant - but a relying party can choose to be non-compliant if it wishes. And such non-compliance only puts the relying party at risk, not others - so that is a "good thing" relatively speaking. But in the final analysis, seems to me that Sharon is absolutely correct (assuming she and I are interpreting your proposal properly) - unless X.509 is redefined, this would remain a circumstance of non-compliance. And so it should be treated as such. Very best regards -- Rich Richard A. Guida Director, Information Security Johnson & Johnson Room GS8217 410 George Street New Brunswick, New Jersey 08901 Phone: 732 524 3785 -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon Boeyen Sent: Thursday, June 22, 2006 1:57 PM To: 'Stefan Santesson'; ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause Stefan, if I understand your comment correctly I strongly believe such an escape clause cannot possibly be added because this would render 3280bis non-compliant with X.509. My understanding of your comment is that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found in EE certificates. Is that a correct understanding? If it is a correct understanding, then any such implementation is non-conformant to X.509. 3280 is a profile of X.509 and as such can mandate certain optional elements or exclude optional elements but cannot reverse the mandatory processing from X.509. Apologies if I've misunderstood your question. Cheers, Sharon -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Wednesday, June 21, 2006 5:23 PM To: ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause As a last call comment on RFC 3280bis I would like to raise the question whether RFC 3280bis should include an escape clause clearly allowing relying parties to select what validation logic they deploy on certificate validation. The background is the fact that many deployed PKIs are misconfigured.2 One such common misconfiguration is assignment of certificate policies and their inclusion in CA certificates. X.509 path processing requires policies in CA certificates to reflect the list of EE certificate policies that are valid for a path. Yet many deployments have included pure CA certificate policies in CA certificates, policies that are not included in any EE certificates and as such, policy processing is not possible in such PKIs. Application wanting to use certificate policies in such PKI are simply forced to either fail or selectively neglect certain path processing rules. For a relying party such modification could be reasonable if the security implications has been well though through. However it is not clear if an implementation allowing such local configuration could be regarded as standard compliant. There are more examples where deploying applications in misconfigured PKIs would need similar measures to work. The pki4ipsec WG recently came to this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX WG. The result was that the pki4ipsec profile included an escape clause as follows: 4.1. X.509 Certificates Users deploying IKE and IPsec with certificates have often had little control over the capabilities of CAs available to them. Implementations of this specification may include configuration knobs to disable checks required by this specification in order t o permit use with inflexible and/or noncompliant CAs. However, all checks on certificates exist for a specific reason involving the security of the entire system. Therefore, all checks MUST be enabled by default. Administrators and users ought to understand the security purpose for the various checks, and be clear on what security will be lost by disabling the check. I'm basically asking if RFC 3280bis path validation needs a similar escape clause or corresponding clarification that clearly allows local configuration of the validation logic. At least I think it is necessary to clearly allow such configuration of standards compliant applications as long as this is not the default functionality. Stefan Santesson Senior Program Manager Windows Security, Standards _____ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: den 16 juni 2006 22:42 To: ietf-pkix@imc.org Subject: last call for 3280bis Folks, Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" ( http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt) The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th. Steve ------_=_NextPart_001_01C6962C.6413C4C6 Content-Type: text/html Message
Stefan - perhaps I am missing something, but there is nothing that stops a relying party from writing software that would perform processing extensions only on CA certs as you propose.  As Sharon properly notes, that would not be RFC3280 compliant - but a relying party can choose to be non-compliant if it wishes.  And such non-compliance only puts the relying party at risk, not others - so that is a "good thing" relatively speaking.  But in the final analysis, seems to me that Sharon is absolutely correct (assuming she and I are interpreting your proposal properly) - unless X.509 is redefined, this would remain a circumstance of non-compliance.  And so it should be treated as such.  Very best regards -- Rich
 
 

Richard A. Guida
Director, Information Security

Johnson & Johnson
Room GS8217
410 George Street
New Brunswick, New Jersey  08901
Phone:  732 524 3785

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Sharon Boeyen
Sent: Thursday, June 22, 2006 1:57 PM
To: 'Stefan Santesson'; ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call for 3280bis - escape clause

Stefan, if I understand your comment correctly I strongly believe such an escape clause cannot possibly be added because this would render 3280bis non-compliant with X.509.
 
My understanding of your comment is that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found in EE certificates. Is that a correct understanding?
 
If it is a correct understanding, then any such implementation is non-conformant to X.509. 3280 is a profile of X.509 and as such can mandate certain optional elements or exclude optional elements but cannot reverse the mandatory processing from X.509.
 
Apologies if I've misunderstood your question.
 
Cheers,
Sharon
-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson
Sent: Wednesday, June 21, 2006 5:23 PM
To: ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call for 3280bis - escape clause

As a last call comment on RFC 3280bis I would like to raise the question whether RFC 3280bis should include an escape clause clearly allowing relying parties to select what validation logic they deploy on certificate validation.

 

The background is the fact that many deployed PKIs are misconfigured.2

One such common misconfiguration is assignment of certificate policies and their inclusion in CA certificates.

X.509 path processing requires policies in CA certificates to reflect the list of EE certificate policies that are valid for a path. Yet many deployments have included pure CA certificate policies in CA certificates, policies that are not included in any EE certificates and as such, policy processing is not possible in such PKIs.

 

Application wanting to use certificate policies in such PKI are simply forced to either fail or selectively neglect certain path processing rules. For a relying party such modification could be reasonable if the security implications has been well though through.

However it is not clear if an implementation allowing such local configuration could be regarded as standard compliant.

 

There are more examples where deploying applications in misconfigured PKIs would need similar measures to work.

 

The pki4ipsec WG recently came to this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX WG.

 

The result was that the pki4ipsec profile included an escape clause as follows:

 

4.1.  X.509 Certificates
 
   Users deploying IKE and IPsec with certificates have often had little
   control over the capabilities of CAs available to them.
   Implementations of this specification may include configuration knobs
   to disable checks required by this specification in orde!
 r t
 o permit
   use with inflexible and/or noncompliant CAs.  However, all checks on
   certificates exist for a specific reason involving the security of
   the entire system.  Therefore, all checks MUST be enabled by default.
   Administrators and users ought to understand the security purpose for
   the various checks, and be clear on what security will be lost by
   disabling the check.

 

 

I'm basically asking if RFC 3280bis path validation needs a similar escape clause or corresponding clarification that clearly allows local configuration of the validation logic.

At least I think it is necessary to clearly allow such configuration of standards compliant applications as long as this is not the default functionality.

 

 

Stefan Santesson

Senior Program Manager

Windows Security, Standards

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent
Sent: den 16 juni 2006 22:42
To: ietf-pkix@imc.org
Subject: last call for 3280bis

 

Folks,

 

Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt)

 

The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th.

 

Steve

------_=_NextPart_001_01C6962C.6413C4C6-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MIW2AL015867; Thu, 22 Jun 2006 11:32:02 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MIW2E7015866; Thu, 22 Jun 2006 11:32:02 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MIW1k2015847 for ; Thu, 22 Jun 2006 11:32:02 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k5MIVtNr002537; Thu, 22 Jun 2006 14:31:56 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.6/8.13.6) with ESMTP id k5MIVh7Q004261; Thu, 22 Jun 2006 14:31:43 -0400 (EDT) Message-ID: <449AE234.6060303@nist.gov> Date: Thu, 22 Jun 2006 14:32:20 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Seth Hitchings CC: pkix Subject: Re: draft-ietf-pkix-scvp-26.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: Seth Hitchings wrote: >Should the CMS reference in section 11.1 be updated to RFC 3852? > > Seth, Yes. I believe that the [CMS] reference should be updated from 3369 to 3852. Also, the [UTF8] reference should be updated from 2279 to 3629 and the [IKE] reference should be updated from 2409 to 4306. Updating the [UTF8] and [IKE] should only affect the References section. Updating the [CMS] reference will also require changing the ASN.1 in section 8 so that ContentInfo is imported from the CryptographicMessageSyntax2004 module rather than the CryptographicMessageSyntax, but I don't think that should cause any problems. Dave Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MIV3Ts015703; Thu, 22 Jun 2006 11:31:03 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MIV2Ds015702; Thu, 22 Jun 2006 11:31:02 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from imx2.tcd.ie (imx2.tcd.ie [134.226.1.156]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MIV1NV015673 for ; Thu, 22 Jun 2006 11:31:02 -0700 (MST) (envelope-from stephen.farrell@cs.tcd.ie) Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id AF4C06807D; Thu, 22 Jun 2006 19:30:55 +0100 (IST) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A05076A3367; Thu, 22 Jun 2006 19:30:55 +0100 Received: from [134.226.144.16] (unknown [134.226.144.16]) by imx2.tcd.ie (Postfix) with ESMTP id 847E16807D; Thu, 22 Jun 2006 19:30:55 +0100 (IST) Message-ID: <449AE1F9.6010007@cs.tcd.ie> Date: Thu, 22 Jun 2006 19:31:21 +0100 From: Stephen Farrell User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Sharon Boeyen Cc: "'Stefan Santesson'" , ietf-pkix@imc.org Subject: Re: last call for 3280bis - escape clause References: <7A3E1242FA9989439AD1F9B2D71C287F09EAD1B2@sottmxs05.entrust.com> In-Reply-To: <7A3E1242FA9989439AD1F9B2D71C287F09EAD1B2@sottmxs05.entrust.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A15076A3367 X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.56.3 VDF=8.1230) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I guess I'd agree with Sharon's conclusion but for slightly different reasons. If people need such a different profile of x.509 or 3280bis then a different RFC is required IMO - given that 3280 exists it would be wrong for 3280bis to include such a change since you'd potentially punish 3280 implementers for being compliant. Stephen. Sharon Boeyen wrote: > Stefan, if I understand your comment correctly I strongly believe such > an escape clause cannot possibly be added because this would render > 3280bis non-compliant with X.509. > > My understanding of your comment is that the escape clause would enable > a path validation engine to process the certificate policy OIDs found in > CA certificates but ignore those found in EE certificates. Is that a > correct understanding? > > If it is a correct understanding, then any such implementation is > non-conformant to X.509. 3280 is a profile of X.509 and as such can > mandate certain optional elements or exclude optional elements but > cannot reverse the mandatory processing from X.509. > > Apologies if I've misunderstood your question. > > Cheers, > Sharon > > -----Original Message----- > *From:* owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] *On Behalf Of *Stefan Santesson > *Sent:* Wednesday, June 21, 2006 5:23 PM > *To:* ietf-pkix@imc.org > *Cc:* Stephen Kent > *Subject:* RE: last call for 3280bis - escape clause > > As a last call comment on RFC 3280bis I would like to raise the > question whether RFC 3280bis should include an escape clause clearly > allowing relying parties to select what validation logic they deploy > on certificate validation. > > > > The background is the fact that many deployed PKIs are misconfigured.2 > > One such common misconfiguration is assignment of certificate > policies and their inclusion in CA certificates. > > X.509 path processing requires policies in CA certificates to > reflect the list of EE certificate policies that are valid for a > path. Yet many deployments have included pure CA certificate > policies in CA certificates, policies that are not included in any > EE certificates and as such, policy processing is not possible in > such PKIs. > > > > Application wanting to use certificate policies in such PKI are > simply forced to either fail or selectively neglect certain path > processing rules. For a relying party such modification could be > reasonable if the security implications has been well though through. > > However it is not clear if an implementation allowing such local > configuration could be regarded as standard compliant. > > > > There are more examples where deploying applications in > misconfigured PKIs would need similar measures to work. > > > > The pki4ipsec WG recently came to this conclusion in their PKI > profile and this lead to an intense debate which included core > participants from the PKIX WG. > > > > The result was that the pki4ipsec profile included an escape clause > as follows: > > > > 4.1. X.509 Certificates > > > > Users deploying IKE and IPsec with certificates have often had little > > control over the capabilities of CAs available to them. > > Implementations of this specification may include configuration knobs > > to disable checks required by this specification in order t > o permit > > use with inflexible and/or noncompliant CAs. However, all checks on > > certificates exist for a specific reason involving the security of > > the entire system. Therefore, all checks MUST be enabled by default. > > Administrators and users ought to understand the security purpose for > > the various checks, and be clear on what security will be lost by > > disabling the check. > > > > > > I'm basically asking if RFC 3280bis path validation needs a similar > escape clause or corresponding clarification that clearly allows > local configuration of the validation logic. > > At least I think it is necessary to clearly allow such configuration > of standards compliant applications as long as this is not the > default functionality. > > > > > > **Stefan Santesson** > > Senior Program Manager > > **Windows Security, Standards** > > ------------------------------------------------------------------------ > > *From:* owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] *On Behalf Of *Stephen Kent > *Sent:* den 16 juni 2006 22:42 > *To:* ietf-pkix@imc.org > *Subject:* last call for 3280bis > > > > Folks, > > > > Based on the latest message from David Cooper, I am initiating last > call on "Internet X.509 Public Key Infrastructure, Certificate and > Certificate Revocation List (CRL) Profile" > (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt) > > > > The last call will last for two weeks. In deference to the U.S. > Independence Dya holiday (which means July 3rd is a holiday for many > folks), all comments must be received by July 5th. > > > > Steve > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MHv9q0006884; Thu, 22 Jun 2006 10:57:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MHv9eN006883; Thu, 22 Jun 2006 10:57:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sottsym2.entrust.com (sottsym2.entrust.com [216.191.252.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MHv8Bc006854 for ; Thu, 22 Jun 2006 10:57:08 -0700 (MST) (envelope-from sharon.boeyen@entrust.com) Received: from sottmxsecs3.entrust.com (unknown [216.191.252.14]) by sottsym2.entrust.com (Symantec Mail Security) with SMTP id 10202240002 for ; Thu, 22 Jun 2006 13:57:02 -0400 (EDT) Received: (qmail 26259 invoked from network); 22 Jun 2006 17:57:01 -0000 Received: from sharon.boeyen@entrust.com by sottmxsecs3.entrust.com with EntrustECS-Server-7.4;22 Jun 2006 17:57:01 -0000 Received: from sottmxs00.entrust.com (10.4.61.22) by sottmxsecs3.entrust.com with SMTP; 22 Jun 2006 17:57:00 -0000 Received: by sottmxs00.entrust.com with Internet Mail Service (5.5.2657.72) id ; Thu, 22 Jun 2006 13:57:01 -0400 Message-ID: <7A3E1242FA9989439AD1F9B2D71C287F09EAD1B2@sottmxs05.entrust.com> From: Sharon Boeyen To: "'Stefan Santesson'" , ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause Date: Thu, 22 Jun 2006 13:56:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69624.D29D3652" X-Brightmail-Tracker: AAAAAA== Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C69624.D29D3652 Content-Type: text/plain Stefan, if I understand your comment correctly I strongly believe such an escape clause cannot possibly be added because this would render 3280bis non-compliant with X.509. My understanding of your comment is that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found in EE certificates. Is that a correct understanding? If it is a correct understanding, then any such implementation is non-conformant to X.509. 3280 is a profile of X.509 and as such can mandate certain optional elements or exclude optional elements but cannot reverse the mandatory processing from X.509. Apologies if I've misunderstood your question. Cheers, Sharon -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Wednesday, June 21, 2006 5:23 PM To: ietf-pkix@imc.org Cc: Stephen Kent Subject: RE: last call for 3280bis - escape clause As a last call comment on RFC 3280bis I would like to raise the question whether RFC 3280bis should include an escape clause clearly allowing relying parties to select what validation logic they deploy on certificate validation. The background is the fact that many deployed PKIs are misconfigured.2 One such common misconfiguration is assignment of certificate policies and their inclusion in CA certificates. X.509 path processing requires policies in CA certificates to reflect the list of EE certificate policies that are valid for a path. Yet many deployments have included pure CA certificate policies in CA certificates, policies that are not included in any EE certificates and as such, policy processing is not possible in such PKIs. Application wanting to use certificate policies in such PKI are simply forced to either fail or selectively neglect certain path processing rules. For a relying party such modification could be reasonable if the security implications has been well though through. However it is not clear if an implementation allowing such local configuration could be regarded as standard compliant. There are more examples where deploying applications in misconfigured PKIs would need similar measures to work. The pki4ipsec WG recently came to this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX WG. The result was that the pki4ipsec profile included an escape clause as follows: 4.1. X.509 Certificates Users deploying IKE and IPsec with certificates have often had little control over the capabilities of CAs available to them. Implementations of this specification may include configuration knobs to disable checks required by this specification in order to permit use with inflexible and/or noncompliant CAs. However, all checks on certificates exist for a specific reason involving the security of the entire system. Therefore, all checks MUST be enabled by default. Administrators and users ought to understand the security purpose for the various checks, and be clear on what security will be lost by disabling the check. I'm basically asking if RFC 3280bis path validation needs a similar escape clause or corresponding clarification that clearly allows local configuration of the validation logic. At least I think it is necessary to clearly allow such configuration of standards compliant applications as long as this is not the default functionality. Stefan Santesson Senior Program Manager Windows Security, Standards _____ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: den 16 juni 2006 22:42 To: ietf-pkix@imc.org Subject: last call for 3280bis Folks, Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" ( http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt) The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th. Steve ------_=_NextPart_001_01C69624.D29D3652 Content-Type: text/html Message
Stefan, if I understand your comment correctly I strongly believe such an escape clause cannot possibly be added because this would render 3280bis non-compliant with X.509.
 
My understanding of your comment is that the escape clause would enable a path validation engine to process the certificate policy OIDs found in CA certificates but ignore those found in EE certificates. Is that a correct understanding?
 
If it is a correct understanding, then any such implementation is non-conformant to X.509. 3280 is a profile of X.509 and as such can mandate certain optional elements or exclude optional elements but cannot reverse the mandatory processing from X.509.
 
Apologies if I've misunderstood your question.
 
Cheers,
Sharon
-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson
Sent: Wednesday, June 21, 2006 5:23 PM
To: ietf-pkix@imc.org
Cc: Stephen Kent
Subject: RE: last call for 3280bis - escape clause

As a last call comment on RFC 3280bis I would like to raise the question whether RFC 3280bis should include an escape clause clearly allowing relying parties to select what validation logic they deploy on certificate validation.

 

The background is the fact that many deployed PKIs are misconfigured.2

One such common misconfiguration is assignment of certificate policies and their inclusion in CA certificates.

X.509 path processing requires policies in CA certificates to reflect the list of EE certificate policies that are valid for a path. Yet many deployments have included pure CA certificate policies in CA certificates, policies that are not included in any EE certificates and as such, policy processing is not possible in such PKIs.

 

Application wanting to use certificate policies in such PKI are simply forced to either fail or selectively neglect certain path processing rules. For a relying party such modification could be reasonable if the security implications has been well though through.

However it is not clear if an implementation allowing such local configuration could be regarded as standard compliant.

 

There are more examples where deploying applications in misconfigured PKIs would need similar measures to work.

 

The pki4ipsec WG recently came to this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX WG.

 

The result was that the pki4ipsec profile included an escape clause as follows:

 

4.1.  X.509 Certificates
 
   Users deploying IKE and IPsec with certificates have often had little
   control over the capabilities of CAs available to them.
   Implementations of this specification may include configuration knobs
   to disable checks required by this specification in order t
 o permit
   use with inflexible and/or noncompliant CAs.  However, all checks on
   certificates exist for a specific reason involving the security of
   the entire system.  Therefore, all checks MUST be enabled by default.
   Administrators and users ought to understand the security purpose for
   the various checks, and be clear on what security will be lost by
   disabling the check.

 

 

I'm basically asking if RFC 3280bis path validation needs a similar escape clause or corresponding clarification that clearly allows local configuration of the validation logic.

At least I think it is necessary to clearly allow such configuration of standards compliant applications as long as this is not the default functionality.

 

 

Stefan Santesson

Senior Program Manager

Windows Security, Standards

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent
Sent: den 16 juni 2006 22:42
To: ietf-pkix@imc.org
Subject: last call for 3280bis

 

Folks,

 

Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt)

 

The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th.

 

Steve

------_=_NextPart_001_01C69624.D29D3652-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MEUiIZ054214; Thu, 22 Jun 2006 07:30:44 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MEUiZa054213; Thu, 22 Jun 2006 07:30:44 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from csexchange1.corestreet.com (host200.58.41.216.conversent.net [216.41.58.200]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MEUh9C054176 for ; Thu, 22 Jun 2006 07:30:43 -0700 (MST) (envelope-from shitchings@corestreet.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: draft-ietf-pkix-scvp-26.txt Date: Thu, 22 Jun 2006 10:30:33 -0400 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0AB8_01C695E6.E4331ED0" Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-pkix-scvp-26.txt Thread-Index: AcaRfvKveO66k8aZRGyMmcjJ6nlwlgEiVwPA From: "Seth Hitchings" To: "David A. Cooper" , "pkix" 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_0AB8_01C695E6.E4331ED0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Should the CMS reference in section 11.1 be updated to RFC 3852? -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of David A. Cooper Sent: Friday, June 16, 2006 3:38 PM To: pkix Subject: draft-ietf-pkix-scvp-26.txt All, I have just submitted draft 26 of SCVP for posting. The draft should be available soon, but in the meantime, I have posted a diff file highlighting the differences between drafts 24 and 26 (the only difference between drafts 24 and 25 was the correction of a typographical error in section 3.6). The diff file is available at http://csrc.nist.gov/pki/documents/PKIX/wdiff_draft-ietf-pkix-scvp-24_to_26. html. Drafts 24 and 26 differ in the following places: 1) Section 3: corrected cross-reference ("3.10" replaced by "3.11"). 2) Section 3.2.4.2.3 (Name Validation Algorithm): Matching rules for use with id-kp-serverAuth are now specified in the document rather than referring to the matching rules in RFC 2818 [HTTP-TLS]. (RFC 2818 is an Informational RFC and so SCVP could not include a normative reference to that document). 3) Section 3.6: "requestorName" replaced with "responderName". (This was the typographical error that was corrected in draft 25.) 4) Section 4: A new sentence was added to clarify that when a protected response is required, the SCVP server must use SignedData or AuthenticatedData even if the response is being sent over a protected transport (e.g., TLS). 5) Section 11.1 (Normative References): The reference to RFC 2818 was deleted. None of these changes to the document result in any changes to the protocol. Dave ------=_NextPart_000_0AB8_01C695E6.E4331ED0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIVzCCAoIw ggHroAMCAQICAQQwDQYJKoZIhvcNAQEEBQAwUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0VxdWlm YXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0xMB4X DTk5MDYyMTA0MDAwMFoXDTIwMDYyMTA0MDAwMFowUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0Vx dWlmYXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0x MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOLxm8F7d33pOpX1oNF080GgyY9CLZWdTEaEbw tDXFhQMgxq9FpSFRRUHrFlg2Mm/iUGJk+f1RnKok2fSdgyqHCiHTEjg0bI0Ablqg2ULuGiGV+VJM VVrFDzhPRvpt+C411h186+LwsHWAyKkTrL6I7zpuq18qOGICsBJ7/o+mAwIDAQABo2YwZDARBglg hkgBhvhCAQEEBAMCAAcwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRKeDJSEdtZFjZe38EU NkBqR3xMoTAdBgNVHQ4EFgQUSngyUhHbWRY2Xt/BFDZAakd8TKEwDQYJKoZIhvcNAQEEBQADgYEA dVuomwMR5ulWTM35qUzADZrzzGVp5iV2zFm31lTDHc2ZrBndtIXV4D38YiCnhEtYZfHi+ZUhP/XU flgeR4dUPlihtbX4Ku9x57zD9rFJRuLXoGvlVnqaJ5h8RmIU58n8bgMSeYA4HUiCjfwX/iqWK7Vi pqY9vX+SWc1aKoKyN3kwggK8MIICJaADAgECAgIA2DANBgkqhkiG9w0BAQUFADBTMQswCQYDVQQG EwJVUzEcMBoGA1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1 cmUgZUJ1c2luZXNzIENBLTEwHhcNMDQwNjAyMTk1NzQyWhcNMjAwNjIxMDQwMDAwWjBSMQswCQYD VQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENl cnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr0HhHsWZ2xkS 6BbojMXvdGPoRJLcAs2nUBSZ6XnJvnHxBwVvRUkqrCSBwKBurhjqGqe3oOxh6tC6wUuGhwLdhyWT BSYO469PJUx02lyiohqUZ8u0yshCL35/lA+MkZubcmFxHsLlTPCkS/+A7PZwzIjKrLAUT0VmwNTL TYEg1F8CAwEAAaOBnzCBnDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFNjsf5MYxWYDwxBsPAT2 d4U+/wu2MB8GA1UdIwQYMBaAFEp4MlIR21kWNl7fwRQ2QGpHfEyhMA8GA1UdEwEB/wQFMAMBAf8w OQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5nZW90cnVzdC5jb20vY3Jscy9lYml6Y2ExLmNy bDANBgkqhkiG9w0BAQUFAAOBgQDCHD9PBDwPPDktSLC/jRpe9Crdpj8Cj7GB1od44j1D+5IJji+w rhuJ3tlR3p5MlzXGUEj8eFBtZymYBiWdLvIVqwMz2nYWBeFWXou6T+n4akcF708jM3MhFXP82ove f/xJzw9IzlVmI9DjDrkL2wXXw/IR5XTP2iQYPcbxento6zCCAw0wggJ2oAMCAQICAXwwDQYJKoZI hvcNAQEFBQAwUjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEpMCcGA1UE AxMgQ29yZVN0cmVldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDUwODI5MTQyNTQwWhcNMDYw OTEyMTQyNTQwWjBqMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMRcwFQYD VQQDEw5TZXRoIEhpdGNoaW5nczEoMCYGCSqGSIb3DQEJARYZc2hpdGNoaW5nc0Bjb3Jlc3RyZWV0 LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzZOhlCd/KDWl33RR6dW+YKFd8Kof1Uz8 9wJ3EevLEK73npZfKDj66mL6fQOL1Cv1RaQrucsm8ZB2bMvUDRvoeC1Te4xsHvxNyV8AoEbxYWsK QciJCNM5bd6kkpfgummUBCgUs7nze+FNhIzWGerlMUjcc37diSOD+FP24WXU+zUCAwEAAaOB2jCB 1zAOBgNVHQ8BAf8EBAMCBeAwPAYDVR0fBDUwMzAxoC+gLYYraHR0cDovL2NybC5nZW90cnVzdC5j b20vY3Jscy9jb3Jlc3RyZWV0LmNybDAkBgNVHREEHTAbgRlzaGl0Y2hpbmdzQGNvcmVzdHJlZXQu Y29tMB8GA1UdIwQYMBaAFNjsf5MYxWYDwxBsPAT2d4U+/wu2MEAGCCsGAQUFBwEBBDQwMjAwBggr BgEFBQcwAYYkaHR0cDovL2dlb3RydXN0LW9jc3AuY29yZXN0cmVldC5jb20vMA0GCSqGSIb3DQEB BQUAA4GBAHPT6HnJxaWD8+WdUL//eXEekqR0rio7r2OdTJ4VSrWZQRHMkWmOzG8aPvgGX7SMh0QZ TvcSBNY7h43m5fPNk7Jaxy+F3LbdwHu02NM/IiUBsLyn8XXi03Xekni5PT6aDuP/Egux3nnlKjej mMjDOVTNBwKwF/QfjP+QViQTO6hoMYICmTCCApUCAQEwVzBSMQswCQYDVQQGEwJVUzEYMBYGA1UE ChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENlcnRpZmljYXRlIEF1dGhv cml0eQIBfDAJBgUrDgMCGgUAoIIBmDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wNjA2MjIxNDMwMzNaMCMGCSqGSIb3DQEJBDEWBBQtWddj/xhrUQO1v6jY5Q4kqZJc STBmBgkrBgEEAYI3EAQxWTBXMFIxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9Db3JlU3RyZWV0IEx0 ZC4xKTAnBgNVBAMTIENvcmVTdHJlZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AgF8MGcGCSqGSIb3 DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO AwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMGgGCyqGSIb3DQEJEAILMVmg VzBSMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3Jl U3RyZWV0IENlcnRpZmljYXRlIEF1dGhvcml0eQIBfDANBgkqhkiG9w0BAQEFAASBgH1TCj1VuI07 8+CN5yRAxYcc8qlNy7o9wqd3yPaigGJyYSuStaeOog+1ElheaWUMnp/iNf9EjLvv8w6bqwvN1WWg YhPUDaoR9yoF7/k/fdl4G/FvRE62N2hWNs/fbIAi70hLJjQJCGd4OMbHrJ0rYXNZ16hvpbb74pPT ftihee9+AAAAAAAA ------=_NextPart_000_0AB8_01C695E6.E4331ED0-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MCqUGK031868; Thu, 22 Jun 2006 05:52:30 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MCqUcf031867; Thu, 22 Jun 2006 05:52:30 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MCqSuq031849 for ; Thu, 22 Jun 2006 05:52:29 -0700 (MST) (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, 22 Jun 2006 13:52:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C695FA.B565663B" Subject: RE: last call for 3280bis - references Date: Thu, 22 Jun 2006 13:52:22 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: last call for 3280bis - references thread-index: AcaRi3NPpHbHqjJkRuqLU85fpb+OdAEbxWwQ From: "Stefan Santesson" To: "Stephen Kent" , X-OriginalArrivalTime: 22 Jun 2006 12:52:24.0838 (UTC) FILETIME=[B5A35260:01C695FA] 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_01C695FA.B565663B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In general we need a work through of the reference section to get the references up to date. =20 Stefan Santesson Senior Program Manager Windows Security, Standards ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: den 16 juni 2006 22:42 To: ietf-pkix@imc.org Subject: last call for 3280bis =20 Folks, =20 Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt ) =20 The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th. =20 Steve ------_=_NextPart_001_01C695FA.B565663B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable last call for 3280bis

In general we need a work through = of the reference section to get the references up to = date.

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Stephen Kent
Sent: den 16 juni 2006 = 22:42
To: ietf-pkix@imc.org
Subject: last call for = 3280bis

 

Folks,

 

Based on the latest message from David Cooper, I am initiating = last call on "Internet X.509 Public Key Infrastructure, Certificate and = Certificate Revocation List (CRL) Profile" = (http://ietf.org/internet-drafts/draft-ietf-pki= x-rfc3280bis-03.txt)

 

The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many = folks), all comments must be received by July 5th.

 

Steve

------_=_NextPart_001_01C695FA.B565663B-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5M6dWLT052137; Wed, 21 Jun 2006 23:39:32 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5M6dW19052136; Wed, 21 Jun 2006 23:39:32 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5M6dVUJ052130 for ; Wed, 21 Jun 2006 23:39:31 -0700 (MST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (24-205-218-53.dhcp.crcy.nv.charter.com [24.205.218.53] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id k5M6dUTj062145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 22 Jun 2006 06:39:30 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <7.0.1.0.0.20060621232234.0422a5d8@OpenLDAP.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 21 Jun 2006 23:39:58 -0700 To: ietf-pkix@imc.org From: "Kurt D. Zeilenga" Subject: stringprep in 3280bis In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: For various values, this I-D discusses how strings are to be prepared using various profiles of the StringPrep algorithm. However, the I-D fails to discuss whether the strings should be prepared as "stored" or "query" strings (see Section 4 of RFC 3490). The I-D should be revised so as to be clear which strings are to be treated as "stored" strings and which are to be treated as "query" strings. Off the cuff, I suspect the right thing to do is: 1) requiring each prepared string in a certificate/CRL be treated as "stored", and 2) prepared strings to be compared against prepared strings in a certificate/CRL to be treated as either "query" or "stored". This assures that each comparison between prepared strings involves at least one "stored" string. -- Kurt At 01:42 PM 6/16/2006, Stephen Kent wrote: >Folks, > >Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt) > >The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th. > >Steve Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5LLN2ow006867; Wed, 21 Jun 2006 14:23:02 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5LLN2jN006866; Wed, 21 Jun 2006 14:23:02 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5LLN0EY006837 for ; Wed, 21 Jun 2006 14:23:00 -0700 (MST) (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, 21 Jun 2006 22:22:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69578.DB4D2429" Subject: RE: last call for 3280bis - escape clause Date: Wed, 21 Jun 2006 22:22:53 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: last call for 3280bis - escape clause thread-index: AcaRi3NPpHbHqjJkRuqLU85fpb+OdADywY5Q From: "Stefan Santesson" To: Cc: "Stephen Kent" X-OriginalArrivalTime: 21 Jun 2006 21:22:54.0165 (UTC) FILETIME=[DBB9F850:01C69578] 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_01C69578.DB4D2429 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As a last call comment on RFC 3280bis I would like to raise the question whether RFC 3280bis should include an escape clause clearly allowing relying parties to select what validation logic they deploy on certificate validation. =20 The background is the fact that many deployed PKIs are misconfigured.2 One such common misconfiguration is assignment of certificate policies and their inclusion in CA certificates. X.509 path processing requires policies in CA certificates to reflect the list of EE certificate policies that are valid for a path. Yet many deployments have included pure CA certificate policies in CA certificates, policies that are not included in any EE certificates and as such, policy processing is not possible in such PKIs. =20 Application wanting to use certificate policies in such PKI are simply forced to either fail or selectively neglect certain path processing rules. For a relying party such modification could be reasonable if the security implications has been well though through. However it is not clear if an implementation allowing such local configuration could be regarded as standard compliant. =20 There are more examples where deploying applications in misconfigured PKIs would need similar measures to work. =20 The pki4ipsec WG recently came to this conclusion in their PKI profile and this lead to an intense debate which included core participants from the PKIX WG. =20 The result was that the pki4ipsec profile included an escape clause as follows: =20 4.1. X.509 Certificates =20 Users deploying IKE and IPsec with certificates have often had little control over the capabilities of CAs available to them. Implementations of this specification may include configuration knobs to disable checks required by this specification in order to permit use with inflexible and/or noncompliant CAs. However, all checks on certificates exist for a specific reason involving the security of the entire system. Therefore, all checks MUST be enabled by default. Administrators and users ought to understand the security purpose for the various checks, and be clear on what security will be lost by disabling the check. =20 =20 I'm basically asking if RFC 3280bis path validation needs a similar escape clause or corresponding clarification that clearly allows local configuration of the validation logic. At least I think it is necessary to clearly allow such configuration of standards compliant applications as long as this is not the default functionality. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: den 16 juni 2006 22:42 To: ietf-pkix@imc.org Subject: last call for 3280bis =20 Folks, =20 Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt ) =20 The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th. =20 Steve ------_=_NextPart_001_01C69578.DB4D2429 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable last call for 3280bis

As a last call comment on RFC = 3280bis I would like to raise the question whether RFC 3280bis should include an = escape clause clearly allowing relying parties to select what validation logic = they deploy on certificate validation.

 

The background is the fact that = many deployed PKIs are misconfigured.2

One such common misconfiguration is assignment of certificate policies and their inclusion in CA = certificates.

X.509 path processing requires = policies in CA certificates to reflect the list of EE certificate policies that are = valid for a path. Yet many deployments have included pure CA certificate = policies in CA certificates, policies that are not included in any EE certificates = and as such, policy processing is not possible in such = PKIs.

 

Application wanting to use = certificate policies in such PKI are simply forced to either fail or selectively = neglect certain path processing rules. For a relying party such modification = could be reasonable if the security implications has been well though = through.

However it is not clear if an implementation allowing such local configuration could be regarded as = standard compliant.

 

There are more examples where = deploying applications in misconfigured PKIs would need similar measures to = work.

 

The pki4ipsec WG recently came to = this conclusion in their PKI profile and this lead to an intense debate which included = core participants from the PKIX WG.

 

The result was that the pki4ipsec = profile included an escape clause as follows:

 

4.1.  X.509 =
Certificates
 
   Users deploying IKE and IPsec =
with certificates have often had =
little
   control over the capabilities of =
CAs available to them.
   Implementations of this =
specification may include configuration =
knobs
   to disable checks required by =
this specification in order to =
permit
   use with inflexible and/or =
noncompliant CAs.  However, all checks =
on
   certificates exist for a =
specific reason involving the security =
of
   the entire system.  =
Therefore, all checks MUST be enabled by =
default.
   Administrators and users ought =
to understand the security purpose =
for
   the various checks, and be clear =
on what security will be lost =
by
   disabling the =
check.

 

 

I’m basically asking if RFC = 3280bis path validation needs a similar escape clause or corresponding = clarification that clearly allows local configuration of the validation = logic.

At least I think it is necessary to = clearly allow such configuration of standards compliant applications as long as = this is not the default functionality.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Stephen Kent
Sent: den 16 juni 2006 = 22:42
To: ietf-pkix@imc.org
Subject: last call for = 3280bis

 

Folks,

 

Based on the latest message from David Cooper, I am initiating = last call on "Internet X.509 Public Key Infrastructure, Certificate and = Certificate Revocation List (CRL) Profile" = (http://ietf.org/internet-drafts/draft-ietf-pki= x-rfc3280bis-03.txt)

 

The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many = folks), all comments must be received by July 5th.

 

Steve

------_=_NextPart_001_01C69578.DB4D2429-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5LFBC2t098753; Wed, 21 Jun 2006 08:11:12 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5LFBBXE098747; Wed, 21 Jun 2006 08:11:11 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp106.biz.mail.re2.yahoo.com (smtp106.biz.mail.re2.yahoo.com [206.190.52.175]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k5LFBACi098716 for ; Wed, 21 Jun 2006 08:11:10 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 17028 invoked from network); 21 Jun 2006 15:11:04 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@70.17.105.223 with login) by smtp106.biz.mail.re2.yahoo.com with SMTP; 21 Jun 2006 15:11:04 -0000 Reply-To: From: "Turner, Sean P." To: Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-03.txt Date: Wed, 21 Jun 2006 11:10:28 -0400 Organization: IECA, Inc. Message-ID: <02e701c69544$d53fc9c0$0301a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaVRNSF7z4+d1M7Q42pTFUyTJy++g== Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Comments as follows (r=replace): 1. Abstract: To the sentence beginning with "The X.509 v3 CRL format is described in detail," add "an Internet specific extension is defined,". AIA is an internet specific extension. 2. Sec 1 para 7 last sentence: replace a conforming certificate/conforming certificates. There are three cert examples in Appendix C. 3. Sec 1 last *, Sec 8, and Sec 10: r RFC 2510/RFC 4210 4. Sec 4 1st para last sentence: remove required to support a PKI. All of the internet defined extensions are optional so they can't be required to support a PKI for the internet community. 5. Sec 4.1.2.4 last para penultimate and last sentence: r section 7.1/section 7.1 and 7.3. 7.3 needs to be added as issuer names can be expressed using the domainComponent attribute. 6. Sec 4.2.1.2: Can we suggest using something other than SHA-1 for key id generation? How about striking SHA-1 from the methods and adding the new sentence to both: The hash algorithm employed can be the same algorithm paired with the signature algorithm (e.g., SHA-1, SHA-256, SHA-384). 7. Sec 4.2.1.6/4.1.2.6: The 2nd paragraph of 4.2.1.6 points out that since the SAN is bound to the public key that the CA MUST verify the each part of the SAN. I think a similar statement ought to be added to the subject section (4.1.2.6) to indicate that "All parts of the subject name MUST be verified by the CA as it is bound to the public key". 8. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT impose name constraints on ediPartyName or registeredID but the 14th para (the one before the ASN.1) indicates that ediPartyName and registeredId are not defined in this spec but MAY be defined in another spec. Sounds to me like it would be hard to convince a customer that you could write a name constraints that can ever be 3280bis compliant since whatever you wrote MUST NOT be imposed/implemented. It's not clear that the name constraints shouldn't be imposed because they're not defined in the spec or whether they should never ever be imposed. 9. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT impose name constraints on x400Address name forms but the last sentence in the 10th para last says X400Address MUST be applied to x.400 addresses. See #8. 10. Sec 4.2.2.1 4th to last para: r HTTP or LDAP URI/HTTP [RFC 1738] or LDAP [RFC 2255] URI. Makes it consistent with AIA in CRL section. 11. Sec 4.2.2.2 3rd to last para: r HTTP or LDAP URI/HTTP [RFC 1738] or LDAP [RFC 2255] URI. Makes it consistent with AIA sections. 12. Sec 5 3rd to last para: r This profile does not define any private Internet CRL extensions or CRL entry extensions/This profiles defines one CRL extension and no CRL entry extensions. AIA is defined in this spec. 13. Sec 5.2.5 8th para (one before the ASN.1): The sentence about the onlyContainsAttributeCerts seems to hang. Recommend adding "In either case" to the beginning of the sentence to address the case when either onlyContainsUserCerts or onlyContainsCACerts is set to TRUE. Additionally, recommend adding the following for completeness as a new last paragraph: "If the scope of the CRL only includes attribute certificates then the onlyContainsAttributeCerts MUST be set to TRUE and both onlyContainsUserCerts and onlyContainsCACerts MUST be set to FALSE." 14. Sec 5.2.7: Remove ASN.1. It's already referenced in the 1st para, duplication leads to errors, and the other sections that reused ASN.1 from certificate sections did not duplicate the ASN.1 (see AKI/IAN). 15. Sec 5.3.1: Can we add an ASN.1 comment to say the enumerated value #7 is never used? 16. Sec 4.2.1.6 1st para: r These identities may be included in addition to or in the place of the identity/These identities may be included in addition to or in the place of, in the case of non-CAs, the identity. The paragraph mixes SAN and IAN, but assumed the 2nd sentence addressed SAN. 17. Sec 4.2.1.6: Add the following to clarify that there is no dependency in this spec between SAN and IAN: This specification places no requirement on CAs, whose certificate includes Issuer Alterative name, to include Subject Alternative names in certificates issued by the CA. 18. Sec 4.2.1.7: Add the following three sentences to be explicit about the checks not made: Issuer Alternative names are not constrained by name constraints. If a CA certificate has a Subject Alternative name, the specification does not require CAs to populate the Issuer Alternative name in certificates issued by the CA. Further, the chain of Issuer Alternative and Subject Alternative names, as is done with issuer and subject names, is not checked during the certificate path validation algorithm in section 6. 19. Sec 5.2.2: Add the following: Issuer Alternative names are not constrained by name constraints. If a CA certificate has a Subject Alternative name, this specification does not require CAs to populate the Issuer Alternative name in CRLs issued by the CA. Feel free to wordsmith any of the suggested text. spt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5KNV91j075511; Tue, 20 Jun 2006 16:31:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5KNV9cb075510; Tue, 20 Jun 2006 16:31:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5KNV8SF075503 for ; Tue, 20 Jun 2006 16:31:08 -0700 (MST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (24-205-218-53.dhcp.crcy.nv.charter.com [24.205.218.53] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id k5KNV781069208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jun 2006 23:31:07 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <7.0.1.0.0.20060620160757.0414c9d0@OpenLDAP.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 20 Jun 2006 16:31:02 -0700 To: Michael Ströder From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-03.txt Cc: ietf-pkix@imc.org In-Reply-To: <4497B56B.6080500@stroeder.com> References: <4497B56B.6080500@stroeder.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 01:44 AM 6/20/2006, Michael Ströder wrote: >Reference to RFC 2253 should be updated since it >was obsoleted by RFC 4514 recently. In the same vein... The document's reference to RFC 2247 should be replaced with a reference RFC 4419. RFC 4419 replaces that portion of RFC 2247 referenced. The document's reference to draft-ietf-ldapbis-strprep-07.txt should be updated to RFC 4518. The document's reference to RFC 2255 should be replaced with RFC 4516. THe document's reference to RFC 2587 should be replaced with RFC 4523. The document's reference to RFC 1778 should be removed (not used). The document's reference to RFC 2252 should be replaced with RFC 4512, which now specifies the syntax. The document's reference to RFC 2279 should be replaced with a reference to RFC 3629. Regarding the included ASN.1 modules, it might be appropriate to add a copyright comment, e.g.: -- Copyright (C) The Internet Society (2006). This version of -- this ASN.1 module is part of RFC XXXX; see the RFC itself -- for full legal notices. >Ciao, Michael. > >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 : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile >> Author(s) : D. Cooper, et al. >> Filename : draft-ietf-pkix-rfc3280bis-03.txt >> Pages : 141 >> Date : 2006-5-24 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5KCMxIS039828; Tue, 20 Jun 2006 05:22:59 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5KCMxdY039827; Tue, 20 Jun 2006 05:22:59 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5KCMv2K039812 for ; Tue, 20 Jun 2006 05:22:57 -0700 (MST) (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); Tue, 20 Jun 2006 13:22:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69464.4267ACF2" Subject: PKXIX draft agenda Date: Tue, 20 Jun 2006 13:22:55 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PKXIX draft agenda thread-index: AcaT9zRONeDYsIOCRrmh/diZJYCbnQAZ+Ybg From: "Stefan Santesson" To: Cc: "Stephen Kent" X-OriginalArrivalTime: 20 Jun 2006 12:22:56.0365 (UTC) FILETIME=[42B841D0:01C69464] 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_01C69464.4267ACF2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 Here is the draft PKIX agenda for the 66th IETF. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =20 =20 --------------------------------------------- =20 PKIX WG (pkix-wg) http://ietf.org/html.charters/pkix-charter.html =20 =20 MONDAY, July 10, 2006 1520-1720 (Room 519b) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 CHAIR: Stephen Kent , Stefan Santesson =20 AGENDA: =20 1. WG Status and Direction =20 1.1 Document Status Review (5 min.) Stefan Santesson (WG co-chair) =20 Some WG documents are with the Ads, some are in RFC editors queue=20 and a few are still within the WG development process. (10 min.) =20 2. PKIX WG Specifications=20 =20 2.1 Simple Certificate Validation Protocol (SCVP) (10 min.) David Cooper (NIST) http://ietf.org/internet-drafts/draft-ietf-pkix-scvp-25.txt =20 This document is in AD evaluation state with some final issues still under discussion =20 2.2 3280bis (15 min.) David Cooper (NIST) =20 http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt =20 A new draft 03 was recently posted and WG last call has been initiated. =20 2.3 Algorithm IDs for Elliptic Curve Cryptography in PKIX (10 min.) Daniel Brown (Certicom) =20 http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-pkalgs-02.txt =20 Some issues concerning algorithm identifiers are yet to be determined =20 2.5 Subject Identification Method (SIM) [Agneda item not decided yet] (5 min.) Tim Polk (NIST) http://ietf.org/internet-drafts/draft-ietf-pkix-sim-07.txt =20 Past IETF last Call. A new draft is requested by IESG. =20 2.6 Additional Algorithms and Identifiers for DSA and ECDSA (5 min.) Tim Polk (NIST) =20 http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha2-dsa-ecdsa-00.tx t =20 A new -00 draft has just been posted. =20 =20 3. Related Specifications & Liaison Presentations =20 Time allowing, liaison presentations will be accommodated to ensure the PKIX WG is aware of related specifications currently progressing as individual drafts. =20 3.1 Including the AIA extension in attribute certificates (10 min) David Chadwick (University of Kent) =20 A presentation about including the AIA extension in attribute certificates,=20 and the requirement to find the superior AA of the AC issuer, as well as the=20 signing certificate of the issuer of the AC =20 =20 4. Joint PKIX/SIDR Meeting http://ietf.org/html.charters/sidr-charter.html =20 4.1 Address Space & As Number PKI (60 min.) Stephen Kent (BBN) =20 This presentation will review the current plans and status for creating a PKI that reflects the allocation of resources through Regional Internet Registries. The motivation for creation this PKI is to enable better security for Internet routing (BGP). =20 =20 =20 =20 ------_=_NextPart_001_01C69464.4267ACF2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

Here is the draft PKIX agenda for = the 66th IETF.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

 

 

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

 

PKIX WG = (pkix-wg)

http://ietf.org/= html.charters/pkix-charter.html

 

 

MONDAY, July 10, 2006 1520-1720 (Room = 519b)

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

 

CHAIR: Stephen Kent <kent@bbn.com>, = Stefan Santesson <stefans@microsoft.com>

 

AGENDA:

 

1. WG Status and = Direction

 

1.1 Document Status Review (5 = min.)

      Stefan = Santesson (WG co-chair)

 

      Some WG = documents are with the Ads, some are in RFC editors queue =

      and a few are = still within the WG development process. (10 = min.)

 

2. PKIX WG = Specifications

 

  2.1 Simple Certificate Validation Protocol (SCVP) (10 min.)

      David Cooper = (NIST)

        htt= p://ietf.org/internet-drafts/draft-ietf-pkix-scvp-25.txt

 

      This document = is in AD evaluation state with some final issues still under = discussion

 

  2.2 3280bis (15 = min.)

      David Cooper = (NIST)

        http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt<= o:p>

 

      A new draft 03 = was recently posted and WG last call has been = initiated.

 

  2.3 Algorithm IDs for Elliptic Curve Cryptography in PKIX (10 min.)

     Daniel Brown = (Certicom)

       http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-pkalgs-02.= txt

 

     Some issues = concerning algorithm identifiers are yet to be determined

 

  2.5 Subject Identification Method = (SIM) [Agneda item not decided yet] (5 min.)

      Tim Polk = (NIST)

        http= ://ietf.org/internet-drafts/draft-ietf-pkix-sim-07.txt

 

      Past IETF last = Call. A new draft is requested by IESG.

 

  2.6 Additional Algorithms and = Identifiers for DSA and ECDSA (5 min.)

      Tim Polk = (NIST)

       http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha2-dsa-ec= dsa-00.txt

 

     A new -00 draft = has just been posted.

 

 

3. Related Specifications & Liaison = Presentations

 

      Time allowing, liaison presentations will be accommodated to ensure = the

      PKIX WG is = aware of related specifications currently progressing = as

      individual = drafts.

 

  3.1 Including the AIA extension in = attribute certificates (10 min)

      David Chadwick = (University of = Kent)

 

      A presentation = about including the AIA extension in attribute certificates, =

      and the = requirement to find the superior AA of the AC issuer, as well as the =

      signing = certificate of the issuer of the AC

 

 

4. Joint PKIX/SIDR = Meeting

   http://ietf.org/= html.charters/sidr-charter.html

 

  4.1 Address Space & As Number = PKI (60 min.)

      Stephen Kent = (BBN)

 

     This = presentation will review the current plans and status for creating a = PKI

     that reflects the allocation of resources through Regional Internet = Registries.

     The motivation for = creation this PKI is to enable better security for = Internet

     routing = (BGP).

 

 

 

 

------_=_NextPart_001_01C69464.4267ACF2-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5K8k5pS099958; Tue, 20 Jun 2006 01:46:05 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5K8k5rT099957; Tue, 20 Jun 2006 01:46:05 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from srv1.int.stroeder.com (60-17-124-83.dsl.3u.net [83.124.17.60]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5K8k3F2099927 for ; Tue, 20 Jun 2006 01:46:04 -0700 (MST) (envelope-from michael@stroeder.com) Received: from localhost (localhost [127.0.0.1]) by srv1.int.stroeder.com (Postfix) with ESMTP id D3F6C4166 for ; Tue, 20 Jun 2006 10:45: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 27429-08 for ; Tue, 20 Jun 2006 10:44:31 +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 did not present a certificate) by srv1.int.stroeder.com (Postfix) with ESMTP id B45734163 for ; Tue, 20 Jun 2006 10:44:30 +0200 (CEST) Message-ID: <4497B56B.6080500@stroeder.com> Date: Tue, 20 Jun 2006 10:44:27 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-03.txt References: In-Reply-To: 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: Reference to RFC 2253 should be updated since it was obsoleted by RFC 4514 recently. Ciao, Michael. 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 : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile > Author(s) : D. Cooper, et al. > Filename : draft-ietf-pkix-rfc3280bis-03.txt > Pages : 141 > Date : 2006-5-24 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5JNBWkZ089463; Mon, 19 Jun 2006 16:11:32 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5JNBWCZ089462; Mon, 19 Jun 2006 16:11:32 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp102.biz.mail.re2.yahoo.com (smtp102.biz.mail.re2.yahoo.com [68.142.229.216]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k5JNBVaj089447 for ; Mon, 19 Jun 2006 16:11:31 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 10786 invoked from network); 19 Jun 2006 23:11:26 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@70.17.105.223 with login) by smtp102.biz.mail.re2.yahoo.com with SMTP; 19 Jun 2006 23:11:25 -0000 Reply-To: From: "Turner, Sean P." To: Subject: RE: I-D ACTION:draft-ietf-pkix-sha2-dsa-ecdsa-00.txt Date: Mon, 19 Jun 2006 19:10:58 -0400 Organization: IECA, Inc. Message-ID: <003401c693f5$a0039de0$0301a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaT4IUABkN6z3lrQc+Oiw9MAORuagADOfjA Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: A couple of comments: General: What is the relationship of this and the ECC PKALGS ID? Is the text that is common going to be removed? Is the other ID dead (it has expired but it's not clear that it won't be resurrected)? Is another draft being prepared for the Key Agreement Schemes? Keys/Parameters: The document only addresses the signatureAlgorithm/signatureVale/signature fields and points to RFC3279 for the ECDSA Public Key Encodings...but it seems like there ought to be an explicit indication of the algorithm the key can be used with in the subjectPublicKeyInfo field along with its parameters? They do this with DSA/RSA why not with ECDSA? Specific Sec 3 1st para last sentence: r field/fields Sec 3 4th para last sentence: r should/SHOULD Sec 3.1 1st para 2nd sentence r SHA2/SHA-2 Sec 3.2 bullets 1, 2, 3: r may/MAY Sec 3.2.1 1st para: r SHA 512/SHA512 spt -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, June 19, 2006 3:50 PM To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org Subject: I-D ACTION:draft-ietf-pkix-sha2-dsa-ecdsa-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA Author(s) : Q. Dang, et al. Filename : draft-ietf-pkix-sha2-dsa-ecdsa-00.txt Pages : Date : 2006-6-19 This document supplements RFC 3279. It specifies algorithm identifiers, and ASN.1 encoding rules for the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures when using SHA-224, SHA-256, 384 or SHA-512 as hashing algorithm. This specification applies to the Internet X.509 Public Key Infrastructure (PKI) when digital signatures are used to sign certificates and certificate revocation list (CRLs). The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha2-dsa-ecdsa-00.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-sha2-dsa-ecdsa-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-sha2-dsa-ecdsa-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5JKnFKT060472; Mon, 19 Jun 2006 13:49:15 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5JKnFAu060471; Mon, 19 Jun 2006 13:49:15 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from csexchange1.corestreet.com (host200.58.41.216.conversent.net [216.41.58.200]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5JKnELS060441 for ; Mon, 19 Jun 2006 13:49:14 -0700 (MST) (envelope-from shitchings@corestreet.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: I-D ACTION:draft-ietf-pkix-sha2-dsa-ecdsa-00.txt Date: Mon, 19 Jun 2006 16:49:07 -0400 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_03AF_01C693C0.47A81700" Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-pkix-sha2-dsa-ecdsa-00.txt Thread-Index: AcaT26+2MLXK1X5zRxO2IesgECCEswABbr5A From: "Seth Hitchings" To: 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_03AF_01C693C0.47A81700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Section 3.1 (DSA Signature Algorithm) lists both id-dsa-with-sha224 and id-dsa-with-sha256 as: joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101) csor(3) algorithms(4) id-dsa-with-sha2(3) 1 They're correctly identified (I think) in the ASN.1 module as 3.1 and 3.2, respectively. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, June 19, 2006 3:50 PM To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org Subject: I-D ACTION:draft-ietf-pkix-sha2-dsa-ecdsa-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA Author(s) : Q. Dang, et al. Filename : draft-ietf-pkix-sha2-dsa-ecdsa-00.txt Pages : Date : 2006-6-19 This document supplements RFC 3279. It specifies algorithm identifiers, and ASN.1 encoding rules for the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures when using SHA-224, SHA-256, 384 or SHA-512 as hashing algorithm. This specification applies to the Internet X.509 Public Key Infrastructure (PKI) when digital signatures are used to sign certificates and certificate revocation list (CRLs). The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha2-dsa-ecdsa-00.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-sha2-dsa-ecdsa-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-sha2-dsa-ecdsa-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_03AF_01C693C0.47A81700 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIVzCCAoIw ggHroAMCAQICAQQwDQYJKoZIhvcNAQEEBQAwUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0VxdWlm YXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0xMB4X DTk5MDYyMTA0MDAwMFoXDTIwMDYyMTA0MDAwMFowUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0Vx dWlmYXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0x MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOLxm8F7d33pOpX1oNF080GgyY9CLZWdTEaEbw tDXFhQMgxq9FpSFRRUHrFlg2Mm/iUGJk+f1RnKok2fSdgyqHCiHTEjg0bI0Ablqg2ULuGiGV+VJM VVrFDzhPRvpt+C411h186+LwsHWAyKkTrL6I7zpuq18qOGICsBJ7/o+mAwIDAQABo2YwZDARBglg hkgBhvhCAQEEBAMCAAcwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRKeDJSEdtZFjZe38EU NkBqR3xMoTAdBgNVHQ4EFgQUSngyUhHbWRY2Xt/BFDZAakd8TKEwDQYJKoZIhvcNAQEEBQADgYEA dVuomwMR5ulWTM35qUzADZrzzGVp5iV2zFm31lTDHc2ZrBndtIXV4D38YiCnhEtYZfHi+ZUhP/XU flgeR4dUPlihtbX4Ku9x57zD9rFJRuLXoGvlVnqaJ5h8RmIU58n8bgMSeYA4HUiCjfwX/iqWK7Vi pqY9vX+SWc1aKoKyN3kwggK8MIICJaADAgECAgIA2DANBgkqhkiG9w0BAQUFADBTMQswCQYDVQQG EwJVUzEcMBoGA1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1 cmUgZUJ1c2luZXNzIENBLTEwHhcNMDQwNjAyMTk1NzQyWhcNMjAwNjIxMDQwMDAwWjBSMQswCQYD VQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENl cnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr0HhHsWZ2xkS 6BbojMXvdGPoRJLcAs2nUBSZ6XnJvnHxBwVvRUkqrCSBwKBurhjqGqe3oOxh6tC6wUuGhwLdhyWT BSYO469PJUx02lyiohqUZ8u0yshCL35/lA+MkZubcmFxHsLlTPCkS/+A7PZwzIjKrLAUT0VmwNTL TYEg1F8CAwEAAaOBnzCBnDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFNjsf5MYxWYDwxBsPAT2 d4U+/wu2MB8GA1UdIwQYMBaAFEp4MlIR21kWNl7fwRQ2QGpHfEyhMA8GA1UdEwEB/wQFMAMBAf8w OQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5nZW90cnVzdC5jb20vY3Jscy9lYml6Y2ExLmNy bDANBgkqhkiG9w0BAQUFAAOBgQDCHD9PBDwPPDktSLC/jRpe9Crdpj8Cj7GB1od44j1D+5IJji+w rhuJ3tlR3p5MlzXGUEj8eFBtZymYBiWdLvIVqwMz2nYWBeFWXou6T+n4akcF708jM3MhFXP82ove f/xJzw9IzlVmI9DjDrkL2wXXw/IR5XTP2iQYPcbxento6zCCAw0wggJ2oAMCAQICAXwwDQYJKoZI hvcNAQEFBQAwUjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEpMCcGA1UE AxMgQ29yZVN0cmVldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDUwODI5MTQyNTQwWhcNMDYw OTEyMTQyNTQwWjBqMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMRcwFQYD VQQDEw5TZXRoIEhpdGNoaW5nczEoMCYGCSqGSIb3DQEJARYZc2hpdGNoaW5nc0Bjb3Jlc3RyZWV0 LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzZOhlCd/KDWl33RR6dW+YKFd8Kof1Uz8 9wJ3EevLEK73npZfKDj66mL6fQOL1Cv1RaQrucsm8ZB2bMvUDRvoeC1Te4xsHvxNyV8AoEbxYWsK QciJCNM5bd6kkpfgummUBCgUs7nze+FNhIzWGerlMUjcc37diSOD+FP24WXU+zUCAwEAAaOB2jCB 1zAOBgNVHQ8BAf8EBAMCBeAwPAYDVR0fBDUwMzAxoC+gLYYraHR0cDovL2NybC5nZW90cnVzdC5j b20vY3Jscy9jb3Jlc3RyZWV0LmNybDAkBgNVHREEHTAbgRlzaGl0Y2hpbmdzQGNvcmVzdHJlZXQu Y29tMB8GA1UdIwQYMBaAFNjsf5MYxWYDwxBsPAT2d4U+/wu2MEAGCCsGAQUFBwEBBDQwMjAwBggr BgEFBQcwAYYkaHR0cDovL2dlb3RydXN0LW9jc3AuY29yZXN0cmVldC5jb20vMA0GCSqGSIb3DQEB BQUAA4GBAHPT6HnJxaWD8+WdUL//eXEekqR0rio7r2OdTJ4VSrWZQRHMkWmOzG8aPvgGX7SMh0QZ TvcSBNY7h43m5fPNk7Jaxy+F3LbdwHu02NM/IiUBsLyn8XXi03Xekni5PT6aDuP/Egux3nnlKjej mMjDOVTNBwKwF/QfjP+QViQTO6hoMYICmTCCApUCAQEwVzBSMQswCQYDVQQGEwJVUzEYMBYGA1UE ChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENlcnRpZmljYXRlIEF1dGhv cml0eQIBfDAJBgUrDgMCGgUAoIIBmDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wNjA2MTkyMDQ5MDdaMCMGCSqGSIb3DQEJBDEWBBTFSBrGrSbb7ZipPU03Yc9KG39m ZjBmBgkrBgEEAYI3EAQxWTBXMFIxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9Db3JlU3RyZWV0IEx0 ZC4xKTAnBgNVBAMTIENvcmVTdHJlZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AgF8MGcGCSqGSIb3 DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO AwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMGgGCyqGSIb3DQEJEAILMVmg VzBSMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3Jl U3RyZWV0IENlcnRpZmljYXRlIEF1dGhvcml0eQIBfDANBgkqhkiG9w0BAQEFAASBgG8HPFCgVDNY rbDTRiwM90zZSSHPqapmTpKHK2bY7bfA0ZEF7ZJ7eM0jq/EGfYqy754xQrK92hvsUGdFvKVQjoZB c699cXA/LyOqJ9/XlPWQT6MJCn3wp0tYNf9qstF1m9Dvq1tOu9hkqbmXMuE7m5V6hHCeG1oM2Qb8 jIX9aMRXAAAAAAAA ------=_NextPart_000_03AF_01C693C0.47A81700-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5JJoBBr048015; Mon, 19 Jun 2006 12:50:11 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5JJoBIO048014; Mon, 19 Jun 2006 12:50:11 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5JJoA5J047974 for ; Mon, 19 Jun 2006 12:50:11 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5JJo2Hp007634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FsPl4-0007Zm-3w; Mon, 19 Jun 2006 15:50:02 -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-sha2-dsa-ecdsa-00.txt Message-Id: Date: Mon, 19 Jun 2006 15:50:02 -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 : Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA Author(s) : Q. Dang, et al. Filename : draft-ietf-pkix-sha2-dsa-ecdsa-00.txt Pages : Date : 2006-6-19 This document supplements RFC 3279. It specifies algorithm identifiers, and ASN.1 encoding rules for the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures when using SHA-224, SHA-256, 384 or SHA-512 as hashing algorithm. This specification applies to the Internet X.509 Public Key Infrastructure (PKI) when digital signatures are used to sign certificates and certificate revocation list (CRLs). The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha2-dsa-ecdsa-00.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-sha2-dsa-ecdsa-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-sha2-dsa-ecdsa-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-19134118.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-sha2-dsa-ecdsa-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-sha2-dsa-ecdsa-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-19134118.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5JJo9En047998; Mon, 19 Jun 2006 12:50:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5JJo9jU047997; Mon, 19 Jun 2006 12:50:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5JJo8ia047973 for ; Mon, 19 Jun 2006 12:50:08 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5JJo2WR003167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FsPl3-0007ZO-V3; Mon, 19 Jun 2006 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-26.txt Message-Id: Date: Mon, 19 Jun 2006 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 : Server-based Certificate Validation Protocol (SCVP) Author(s) : A. Malpani, et al. Filename : draft-ietf-pkix-scvp-26.txt Pages : 84 Date : 2006-6-19 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-26.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-26.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-26.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: <2006-6-19130822.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-scvp-26.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-scvp-26.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-19130822.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5JCvXCa067152; Mon, 19 Jun 2006 05:57:33 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5JCvXrX067151; Mon, 19 Jun 2006 05:57:33 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5JCvWQl067144 for ; Mon, 19 Jun 2006 05:57:32 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.192.42.43]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FsJJm-0008Bo-3O for ietf-pkix@imc.org; Mon, 19 Jun 2006 08:57:26 -0400 Mime-Version: 1.0 Message-Id: Date: Mon, 19 Jun 2006 02:27:46 -0400 To: ietf-pkix@imc.org From: Stephen Kent Subject: slight whoops Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As you may have noticed, Stefan and I independently sent out last call notices for 3820bis, with slightly different closing dates. We have agreed to go with my date, so July 5th is the close of last call for 3280bis. Steve Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5GKgf0e086321; Fri, 16 Jun 2006 13:42:41 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5GKgfwq086320; Fri, 16 Jun 2006 13:42:41 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5GKge9K086292 for ; Fri, 16 Jun 2006 13:42:41 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.136.89]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FrL9G-0008Sj-5H for ietf-pkix@imc.org; Fri, 16 Jun 2006 16:42:34 -0400 Mime-Version: 1.0 Message-Id: Date: Fri, 16 Jun 2006 16:42:28 -0400 To: ietf-pkix@imc.org From: Stephen Kent Subject: last call for 3280bis Content-Type: multipart/alternative; boundary="============_-1061631940==_ma============" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --============_-1061631940==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Folks, Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt) The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th. Steve --============_-1061631940==_ma============ Content-Type: text/html; charset="us-ascii" last call for 3280bis
Folks,

Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt)
 
The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th.

Steve
--============_-1061631940==_ma============-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5GJcbOv069992; Fri, 16 Jun 2006 12:38:37 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5GJcbdD069991; Fri, 16 Jun 2006 12:38:37 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5GJcaRN069976 for ; Fri, 16 Jun 2006 12:38:37 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k5GJcWBo019756 for ; Fri, 16 Jun 2006 15:38:32 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.6/8.13.6) with ESMTP id k5GJbiOB028565 for ; Fri, 16 Jun 2006 15:37:44 -0400 (EDT) Message-ID: <4493089C.4040701@nist.gov> Date: Fri, 16 Jun 2006 15:38:04 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pkix Subject: draft-ietf-pkix-scvp-26.txt 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, I have just submitted draft 26 of SCVP for posting. The draft should be available soon, but in the meantime, I have posted a diff file highlighting the differences between drafts 24 and 26 (the only difference between drafts 24 and 25 was the correction of a typographical error in section 3.6). The diff file is available at http://csrc.nist.gov/pki/documents/PKIX/wdiff_draft-ietf-pkix-scvp-24_to_26.html. Drafts 24 and 26 differ in the following places: 1) Section 3: corrected cross-reference ("3.10" replaced by "3.11"). 2) Section 3.2.4.2.3 (Name Validation Algorithm): Matching rules for use with id-kp-serverAuth are now specified in the document rather than referring to the matching rules in RFC 2818 [HTTP-TLS]. (RFC 2818 is an Informational RFC and so SCVP could not include a normative reference to that document). 3) Section 3.6: "requestorName" replaced with "responderName". (This was the typographical error that was corrected in draft 25.) 4) Section 4: A new sentence was added to clarify that when a protected response is required, the SCVP server must use SignedData or AuthenticatedData even if the response is being sent over a protected transport (e.g., TLS). 5) Section 11.1 (Normative References): The reference to RFC 2818 was deleted. None of these changes to the document result in any changes to the protocol. Dave Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5GHdun2040251; Fri, 16 Jun 2006 10:39:56 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5GHdug5040250; Fri, 16 Jun 2006 10:39:56 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5GHdsu8040236 for ; Fri, 16 Jun 2006 10:39:55 -0700 (MST) (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); Fri, 16 Jun 2006 18:39:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6916B.E03064F2" Subject: WG Last Call: RFC3280bis Date: Fri, 16 Jun 2006 18:39:52 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Last Call: RFC3280bis thread-index: AcaRa9/PSg6uKi45SZ+HHXAxZPazQA== From: "Stefan Santesson" To: X-OriginalArrivalTime: 16 Jun 2006 17:39:53.0711 (UTC) FILETIME=[E049F7F0:01C6916B] 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_01C6916B.E03064F2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, =20 This message initiates working group last call for "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" This document is currently available at: http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt. =20 =20 The last call will be two weeks. That is, Last Call for this document closes on or after July 3rd, 2006. =20 Since I'm co-editor, Steve Kent will determine WG consensus. =20 Thanks, =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =20 ------_=_NextPart_001_01C6916B.E03064F2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

This message initiates working group last =
call for "Internet X.509 Public Key Infrastructure, Certificate and =
Certificate Revocation List (CRL) =
Profile”

This document is = currently available at: http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt.&= nbsp;

 

The last call will = be two weeks.  That is, Last Call for this document closes on or after = July 3rd, 2006.

 

Since I’m = co-editor, Steve Kent will determine WG consensus.

 

Thanks,

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

 

------_=_NextPart_001_01C6916B.E03064F2-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5GH8jtq032776; Fri, 16 Jun 2006 10:08:45 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5GH8jLf032775; Fri, 16 Jun 2006 10:08:45 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5GH8hdc032768 for ; Fri, 16 Jun 2006 10:08:44 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k5GH8U3X009701; Fri, 16 Jun 2006 13:08:31 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.6/8.13.6) with ESMTP id k5GH8BOM021775; Fri, 16 Jun 2006 13:08:11 -0400 (EDT) Message-ID: <4492E58E.9030501@nist.gov> Date: Fri, 16 Jun 2006 13:08:30 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: yquenechdu@linagora.com CC: pkix Subject: Re: [Fwd: draft-ietf-pkix-scvp-25.txt] References: <2047.10.0.0.1.1149092463.squirrel@tomate.linagora.lan> In-Reply-To: <2047.10.0.0.1.1149092463.squirrel@tomate.linagora.lan> 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: This was a typographical error. The text should have referred to section 3.11 (SCVP Request Authentication), which defines the id-kp-scvpClient OID, but the cross-reference did not get updated when a new subsection was added to section 3. yannick quenechdu wrote: >Hi, > >I would wish a clarification about section 3 : > >"If the extended key usage extension is present, it MUST contain either >the SCVP client OID (see Section 3.10) or another OID acceptable to the >SCVP server." > >I do not see the relation with section 3.10. It is necessary to use the >field RequestorText to indicate a OID for SCVP client ? > > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5GBlNGR064551; Fri, 16 Jun 2006 04:47:23 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5GBlNG8064550; Fri, 16 Jun 2006 04:47:23 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5GBlMUB064530 for ; Fri, 16 Jun 2006 04:47:22 -0700 (MST) (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); Fri, 16 Jun 2006 12:47:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6913A.9D1E621C" Subject: RE: Request for agenda items for next IETF in Montreal Date: Fri, 16 Jun 2006 12:47:15 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request for agenda items for next IETF in Montreal thread-index: AcaGi5FVe42aNExIS2mEBuVUe7WsrQKrr3DA From: "Stefan Santesson" To: X-OriginalArrivalTime: 16 Jun 2006 11:47:15.0913 (UTC) FILETIME=[9D423390:01C6913A] 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_01C6913A.9D1E621C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would appreciate if editors of each wg document could send me a note about whether any of the editors will be at the PKIX meeting and how much time they need to make a status report. =20 Thanks =20 Stefan Santesson Senior Program Manager Windows Security, Standards ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: den 2 juni 2006 23:29 To: ietf-pkix@imc.org Subject: Request for agenda items for next IETF in Montreal =20 At next IETF in Montreal we are going to have two PKIX sessions. =20 One PKIX only session, in the traditional form, and one joint session with the SIDR WG (Secure Inter-Domain Routing) At the joint PKIX/SIDR meeting, Steve Kent will give a 1 hour presentation on a PKI proposal. =20 I will however only manage the agenda for the PKIX only session. =20 Please let me know if you want to request a time slot for this meeting. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =20 ------_=_NextPart_001_01C6913A.9D1E621C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would appreciate if editors of = each wg document could send me a note about whether any of the editors will be = at the PKIX meeting and how much time they need to make a status = report.

 

Thanks

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Stefan Santesson
Sent: den 2 juni 2006 = 23:29
To: ietf-pkix@imc.org
Subject: Request for = agenda items for next IETF in Montreal

 

At next IETF in Montreal we are going to have two PKIX sessions.

 

One PKIX only session, in the traditional form, and = one joint session with the SIDR WG (Secure Inter-Domain = Routing)

At the joint PKIX/SIDR meeting, Steve Kent will give = a 1 hour presentation on a PKI proposal.

 

I will however only manage the agenda for the PKIX = only session.

 

Please let me know if you want to request a time slot = for this meeting.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

 

------_=_NextPart_001_01C6913A.9D1E621C-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5FEDPf0085845; Thu, 15 Jun 2006 07:13:25 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5FEDPWe085844; Thu, 15 Jun 2006 07:13:25 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5FEDOQX085803 for ; Thu, 15 Jun 2006 07:13:25 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5FEDIRx004082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Jun 2006 14:13:18 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fqsb0-0006sq-0Y; Thu, 15 Jun 2006 10:13:18 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Subject: Last Call: 'Lightweight OCSP Profile for High Volume Environments' to Informational RFC (draft-ietf-pkix-lightweight-ocsp-profile) Reply-to: iesg@ietf.org CC: Message-Id: Date: Thu, 15 Jun 2006 10:13:18 -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: - 'Lightweight OCSP Profile for High Volume Environments ' as an Informational RFC 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 2006-06-29. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pkix-lightweight-ocsp-profile-05.txt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k52LT6BS029392; Fri, 2 Jun 2006 14:29:06 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k52LT6wW029391; Fri, 2 Jun 2006 14:29:06 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k52LT4hd029384 for ; Fri, 2 Jun 2006 14:29:05 -0700 (MST) (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); Fri, 2 Jun 2006 22:29:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6868B.922D5A85" Subject: Request for agenda items for next IETF in Montreal Date: Fri, 2 Jun 2006 22:29:02 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request for agenda items for next IETF in Montreal Thread-Index: AcaGi5FVe42aNExIS2mEBuVUe7WsrQ== From: "Stefan Santesson" To: X-OriginalArrivalTime: 02 Jun 2006 21:29:03.0526 (UTC) FILETIME=[9208BC60:01C6868B] 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_01C6868B.922D5A85 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At next IETF in Montreal we are going to have two PKIX sessions. =20 One PKIX only session, in the traditional form, and one joint session with the SIDR WG (Secure Inter-Domain Routing) At the joint PKIX/SIDR meeting, Steve Kent will give a 1 hour presentation on a PKI proposal. =20 I will however only manage the agenda for the PKIX only session. =20 Please let me know if you want to request a time slot for this meeting. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =20 ------_=_NextPart_001_01C6868B.922D5A85 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At next IETF in Montreal we are going to have two PKIX sessions.

 

One PKIX only session, in the traditional form, and = one joint session with the SIDR WG (Secure Inter-Domain = Routing)

At the joint PKIX/SIDR meeting, Steve Kent will give = a 1 hour presentation on a PKI proposal.

 

I will however only manage the agenda for the PKIX = only session.

 

Please let me know if you want to request a time slot = for this meeting.

 

 

Stefan = Santesson

Senior = Program Manager

Windows = Security, Standards

 

------_=_NextPart_001_01C6868B.922D5A85--